http://blog.gmane.org/gmane.ietf.uri-review hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.uri-review/928 <pre> Hi, We have a draft [1] that requests two new URI schemes. The core WG are likely to want to use these we think and possibly decade, but they're intended to be generally useful as well. Barry Leiba is planning to AD sponsor this and Alexey Melnikov will be shepherding so if you can cc them ase well as the authors on any questions or comments that'd be good. I hope the plan is to IETF LC this soon, once this review and the .well-known registration review are done. Thanks, Stephen. [1] http://tools.ietf.org/html/draft-farrell-decade-ni-05 </pre> Stephen Farrell 2012-04-30T15:56:52 http://comments.gmane.org/gmane.ietf.uri-review/923 <pre>Hi, There is currently an ongoing WG last call on RTSP 2.0. The WGLC ends on May 16th, 2012. https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/ 22.14. URI Schemes This specification defines two URI schemes ("rtsp" and "rtsps") and reserves a third one ("rtspu"). These URI schemes are defined in existing registries which are not created by RTSP. Registrations are following RFC 4395[RFC4395]. 22.14.1. The rtsp URI Scheme URI scheme name: rtsp Status: Permanent URI scheme syntax: See Section 20.2.1 of RFC XXXX. URI scheme semantics: The rtsp scheme is used to indicate resources accessible through the usage of the Real-time Streaming Protocol (RTSP). RTSP allows different operations on the resource identified by the URI, but the primary purpose is the streaming delivery of the resource to a client. However, the operations that are currently defined are: DESCRIBE, GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY</pre> Magnus Westerlund 2012-04-26T15:14:37 http://comments.gmane.org/gmane.ietf.uri-review/912 <pre>Hello, I am developing to get better support for SIP over IPv6. One of the problems that I have encountered is the interoperability between endpoints that run only IPv4 or IPv6. To solve this situations prior to call setup, I am proposing a sip6 URI scheme. Using this, end users and their tools should have an easier time deciding whether or not to use the URI. A similar thing applies to enforced ZRTP --being sure before calling that the call will be private-- and I combined that with the URI scheme proposal, so as not to register more URI schemes than required. Your feedback is kindly welcomed. Best wishes, Rick van Rein OpenFortress URI scheme name. sip6 Status. permanent URI scheme syntax. sip6:&lt;user&gt;[:&lt;password&gt;]&lt; at &gt;&lt;host&gt;[:&lt;port&gt;][;&lt;uri-parameters&gt;][?&lt;headers&gt;] The scheme is the same as for sip: with the exception of the URI scheme. URI scheme semantics. SIP entities [RFC3261] that process the sip6 scheme URI ensure that the follow</pre> Rick van Rein 2012-04-26T09:27:25 http://comments.gmane.org/gmane.ietf.uri-review/911 <pre>Dear all. I would like to bring your attention the http://tools.ietf.org/html/draft-uri-acr-extension-04 submission. Technical summary: This URI scheme is intended as an extension to the "tel:" scheme but without disclosing the true identity of a reference or a user. The "acr" URI describes an anonymous reference, that can be mapped to a resource or a user. There are multiple situations where the true identity of a user or a resources can not be disclosed. The "acr" URI is a globally unique identifier ( "name" ) only; it does not describe the steps necessary to reach the user or the device. However it can contain a parameter indication what body or organisation that could resolve it. It is intended for privacy protection, where a user trusts a translating party, that can route or forward the request or message to the true user or resource. This is an individual contribution, so I need help to bring this to a working group, and hopefully convert it to a permanent RFC i</pre> sune.jakobsson< at >telenor.com 2012-03-02T13:05:28 http://comments.gmane.org/gmane.ietf.uri-review/908 <pre>http://tools.ietf.org/html/draft-masinter-dated-uri-10 This has been kicking around for more than 10 years as an Internet Draft. I was asked at least for something more stable, and I want to take this off my queue. The URI scheme registry doesn't have an 'experimental' section, so I think these should be noted as 'provisional'. Larry _______________________________________________ Uri-review mailing list Uri-review&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/uri-review </pre> Larry Masinter 2012-01-21T21:04:18 http://comments.gmane.org/gmane.ietf.uri-review/907 <pre>Hi, I was wondering if the 'jar' scheme could be defined in an hour or so, and so I experimented a bit, comparing the implementation in Firefox and the Sun Java implementation I had laying around, and they are nothing a- like when it comes to parsing; simple example `jar:...!/...?example`; in this case, Firefox ignores the "?example" string while Java treats it as part of the file name. At best one could define a tiny profile that does not allow any "special" cases like that without creating some ficition, or for that matter simply refer to the Java documentation which does not address these things and leave it at that. regards, </pre> Bjoern Hoehrmann 2011-11-28T18:08:22 http://comments.gmane.org/gmane.ietf.uri-review/906 <pre>Hi, Please review and send us comments on the IPP over HTTPS Transport Binding and 'ipps' URI Scheme available at: http://tools.ietf.org/id/draft-mcdonald-ipps-uri-scheme-04.txt Many thanks to the IPP WG members of the IEEE-ISTO PWG for their careful review of the previous draft (see Change History appendix). Abstract: This memo defines the Internet Printing Protocol (IPP) over HTTPS transport binding and the corresponding 'ipps' URI scheme, that is used to designate the access to the network location of a secure IPP print service or a network resource (for example, a print job) managed by such a service. This memo is published by the IETF on behalf of the Internet Printing Protocol Working Group of the IEEE-ISTO Printer Working Group. This memo updates RFC 2910 and RFC 2911. Background: This memo is published by IETF on behalf of the Internet Printing Protocol Working Group of the IEEE-ISTO Printer Working Group, as part of their IPP Everywhere [IPPEVE] project fo</pre> Ira McDonald 2011-11-22T22:18:49 http://comments.gmane.org/gmane.ietf.uri-review/887 <pre>It looks like most URI schemes like this one are never registered with IANA. It seems like The Right Thing to do and so I present to the list the URI scheme com-eventbrite-attendee. URI scheme name. com-eventbrite-attendee Status. provisional URI scheme syntax. uri = "com-eventbrite-attendee:" method [ "?" query ] method = "resetpassword" / "tickets" Example: com-eventbrite-attendee:resetpassword?email=user%40domain.com&amp;token=DEADBEEF URI scheme semantics. This scheme is intended to be used by operating systems that have the Eventbrite Attendee application installed. When a URI with this scheme is encountered it is expected that the operating system launches the Eventbrite Attendee application with the method and query parameters specified in the URI. The exact semantics for how URL information is communicated to the Eventbrite Attendee app may vary on an operating system basis. The expectation is simply that the operating system follows its</pre> Bob Van Zant 2011-10-10T23:30:52 http://comments.gmane.org/gmane.ietf.uri-review/885 <pre>Hi, I've seen 'udp' URIs before for a number of times and can see it in front of my eyes right now, in uTorrent, listed along with 'http' URIs in the trackers list. I have the URI like &lt;udp://tracker.somehost.com:80/announce&gt;, and such URI makes me think that it's in some way related to HTTP, as port 80 is used. OTOH, one may also think it's related to UDP, which seems to be obvious from the scheme name. Official IANA registry says nothing about it; neither does Wikipedia (http://en.wikipedia.org/wiki/URI_scheme). I've found the 1999 draft, though, proposing two schemes for HTTP-over-UDP: http://tools.ietf.org/html/draft-goland-http-udp-01. So does anybody know how is it related to 'udp' scheme and what the latter stands for at all? Mykyta Yevstifeyev </pre> Mykyta Yevstifeyev 2011-08-28T15:14:03 http://comments.gmane.org/gmane.ietf.uri-review/884 <pre>Hi, Please review and send us comments on the IPP over HTTPS Transport Binding and 'ipps' URI Scheme and available at: http://tools.ietf.org/id/draft-mcdonald-ipps-uri-scheme-03.txt Many thanks again to Mykyta Yevstifeyev for his helpful comments on the previous draft. Abstract: This memo defines the Internet Printing Protocol (IPP) over HTTPS transport binding and the corresponding 'ipps' URI scheme, that is used to designate the access to the network location of a secure IPP print service or a network resource (for example, a print job) managed by such a service. This memo is published by the IETF on behalf of the Internet Printing Protocol Working Group of the IEEE-ISTO Printer Working Group. This memo updates RFC 2910 and RFC 2911. Background: This memo is published by IETF on behalf of the Internet Printing Protocol Working Group of the IEEE-ISTO Printer Working Group, as part of their IPP Everywhere [IPPEVE] project for mobile, driverless, ubiquitous printing. ht</pre> Ira McDonald 2011-08-26T20:32:36 http://comments.gmane.org/gmane.ietf.uri-review/878 <pre>URI scheme name: pack Status: historical URI scheme syntax: There was no pack: syntax compatible with STD 66, cf. &lt;http://www.ietf.org/mail-archive/web/uri-review/current/msg00678.html&gt;, &lt;http://www.ietf.org/mail-archive/web/uri-review/current/msg00548.html&gt;. URI scheme semantics: n/a due to a lack of STD 66 syntax. Encoding considerations: The pack: encoding assumed US-ASCII after un-escaping percent-encoded characters in an encapsulated &lt;authority&gt; (4.c in the expired drafts) and case-insensitive US-ASCII in the &lt;path&gt; (5.c in the expired drafts). Applications/protocols that use this URI scheme name: The pack: scheme could not be used as an URI scheme in applications or protocols. Other uses of pack: are noted in the expired drafts. Interoperability considerations: All URI schemes have to follow the generic STD 66 syntax, as that was not the case for pack: any "interoperability" would be by the chance of similarly broken implementations. Security considerations: </pre> Frank Ellermann 2011-08-20T07:25:42 http://comments.gmane.org/gmane.ietf.uri-review/877 <pre>Hello, draft-mcdonald-ipps-uri-scheme will expire on 28 August, and could you please notify whether you're planning to continue work on it, and, explicitly, incorporate my comments from [1] and [2]? The last activity with respect to this draft, I recall, was in the beginning of 2011, and no new versions of the draft appeared. Mykyta [1]http://www.ietf.org/mail-archive/web/uri-review/current/msg01368.html [2]http://www.ietf.org/mail-archive/web/uri-review/current/msg01370.html </pre> Mykyta Yevstifeyev 2011-08-20T05:04:41 http://comments.gmane.org/gmane.ietf.uri-review/876 <pre>Hello all, I uploaded new version of draft-yevstifeyev-ftp-uri-scheme several days ago: Also see http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme-06. Please let me know if you have any further comments. Thanks, Mykyta Yevstifeyev </pre> Mykyta Yevstifeyev 2011-08-15T09:37:09 http://comments.gmane.org/gmane.ietf.uri-review/858 <pre>Hello, Skype(tm) is known to use 'skype' and 'callto' URI schemes. There is no any clear specification of the schemes on the Skype site, nor can I find it on the Net. However, the syntax is known; it is said to be (transforming into ABNF): The operations of 'callto' URIs are to open a Skype call to &lt;name&gt;; 'skype' URI provide richer semantics, per &lt;params&gt;. Documentation for Skype operations is available from share.skype.com/media/1.2_api_doc_en.pdf (this document says it is confidential ;-). The 'skype' URIs are known to be widely used; 'callto' are also used, but not as often as 'skype'. Currently, the schemes are not officially registered with IANA; so my questions is: Can (should?) an effort to specify these two schemes be undertaken? Any thoughts are welcome. Mykyta Yevstifeyev </pre> Mykyta Yevstifeyev 2011-07-17T08:49:49 http://comments.gmane.org/gmane.ietf.uri-review/836 <pre>Hello, Any comments are still welcome. Mykyta Yevstifeyev </pre> Mykyta Yevstifeyev 2011-06-28T03:42:05 http://comments.gmane.org/gmane.ietf.uri-review/827 <pre>Hello, After working on the document a bit, I've submitted a new version of draft-yevstifeyev-ftp-uri-scheme-02: http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme-02 The differences from -01 are at http://tools.ietf.org/rfcdiff?url2=draft-yevstifeyev-ftp-uri-scheme-02.txt I personally believe the document is almost ready, yet, I'd like to seek more community comments (if any) on it. Thanks, Mykyta Yevstifeyev </pre> Mykyta Yevstifeyev 2011-06-19T05:05:30 http://comments.gmane.org/gmane.ietf.uri-review/819 <pre>Hello, Please see http://tools.ietf.org/html/draft-yevstifeyev-xri-uri-rsrv-00. The document is currently under OASIS XRI TC (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xri) review; however I'd like to ask whether anybody has concerns with regard to it. Thanks, Mykyta Yevstifeyev </pre> Mykyta Yevstifeyev 2011-06-11T04:44:49 http://comments.gmane.org/gmane.ietf.uri-review/812 <pre>Hi all, I've just posted draft-yevstifeyev-ftp-uri-scheme-01; please find it here: http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme-01 The new revision tries to address comments from Daniel as well as from John. It also incorporates various editorial improvements. The diffs can be found here: http://tools.ietf.org/rfcdiff?url2=draft-yevstifeyev-ftp-uri-scheme-01. Please, if you have any comments and suggestions, feel free to express them. Considering the necessity of wide community involvement, I'd like to ask to adopt this draft as the ftpext2 WG item. I am copying this message to WG chairs to let them know and decide if it is OK. All the best, Mykyta Yevstifeyev _______________________________________________ Uri-review mailing list Uri-review&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/uri-review </pre> Mykyta Yevstifeyev 2011-05-27T08:31:58 http://comments.gmane.org/gmane.ietf.uri-review/802 <pre>Hello all, I'm writing to ask people to comment my draft draft-yevstifeyev-ftp-uri-scheme, that may be found here: http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme-00 This document removes uncertainty with the 'ftp' URI scheme, currently specified by obsolete RFC 1738 (see my message: http://www.ietf.org/mail-archive/web/uri-review/current/msg01442.html). RFC 4395 says that 4 weeks review-and-comment period is fine for permanent registration, so please feel free to provide your comments on my document during these 4 weeks. {I understand that ftpext list isn't the most appropriate list, but I think posting this message there will allow FTP experts read and express their thoughts on this document.} Please, when responding, keep all "To:" and "Cc:" addresses in the message. Thanks, Mykyta Yevstifeyev _______________________________________________ Uri-review mailing list Uri-review&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/uri-review </pre> Mykyta Yevstifeyev 2011-05-22T05:07:36 http://comments.gmane.org/gmane.ietf.uri-review/798 <pre>Hello all, The first mention of 'ftp' URI scheme in the IETF document is probably RFC 1738 (http://tools.ietf.org/html/rfc1738), if I'm right. As far as you can see, this RFC is formally obsoleted by RFC 4248 and RFC 4266, but in fact RFC 2396 et seq., meaning RFC 3986 (formally they updated RFC 1738), replaced it. Among other, RFC 1738 document specified several URI schemes, such as widely-used 'http', 'mailto' etc. This table summarizes the state of schemes specified by RFC 1738. ("Specification" is the most current RFC defining some scheme). /Scheme name / /Protocol / /Specification / http HTTP (RFC2616) RFC 2616 gopher Gopher (RFC1436) RFC 4266 mailto N/A RFC 6068 news NNTP (RFC 3977) RFC 5538 nntp NNTP (RFC 3977) RFC 5538 telnet Telnet (RFC 854) RFC 4248 wais WAIS (RFC 1625) RFC 4156 file N/A *RFC 1738* prospero Propsero (non-IETF) RFC 4157 ftp FTP (RFC 959) *RFC 1738 * : You may see, there are two schemes in this list specified by formally obsoleted RFC 1738 (even t</pre> Mykyta Yevstifeyev 2011-05-15T05:14:05 http://comments.gmane.org/gmane.ietf.uri-review/766 <pre>Hello, I'm writing to request the review of my draft-yevstifeyev-view-source-uri-01, that can be found at http://tools.ietf.org/html/draft-yevstifeyev-view-source-uri-01 This document specifies the 'view-source' URI scheme, that refers to the source code of the resource identified by it.It has long been used without any formal specification and mention at the IANA registry. My document removes this uncertainty and gives the scheme an official formal definition and registers it in the Provisional category of IANA registry. All requirements of RFC 4395 for Provisional registrations (http://tools.ietf.org/html/rfc4395#section-3) are suited in the registration template. Whereas Section 5.2 of RFC 4395 outlines that the review period of 4 weeks is OK for permanent registrations, it says nothing about Provisional ones. I suppose 2 weeks should be fine. After this period I'll upload a new version of the document (if there are any issues with it) and notify you. All the best, Mykyta Yevstifeyev </pre> Mykyta Yevstifeyev 2011-04-23T09:29:30 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.uri-review