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, PAUSE, SETUP, SET_PARAMETER, and TEARDOWN. Encoding considerations: IRIs in this scheme are defined and needs to be encoded as RTSP URIs when used within the RTSP protocol. That encoding is done according to RFC 3987. Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 2326), RTSP 2.0 (RFC XXXX) Schulzrinne, et al. Expires September 13, 2012 [Page 222] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) March 2012 Interoperability considerations: The change in URI syntax performed between RTSP 1.0 and 2.0 can create interoperability issues. Security considerations: All the security threats identified in Section 7 of RFC 3986 applies also to this scheme. They need to be reviewed and considered in any implementation utilizing this scheme. Contact: Magnus Westerlund, magnus.westerlund&lt; at &gt;ericsson.com Author/Change controller: IETF References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX 22.14.2. The rtsps URI Scheme URI scheme name: rtsps Status: Permanent URI scheme syntax: See Section 20.2.1 of RFC XXXX. URI scheme semantics: The rtsps scheme is used to indicate resources accessible through the usage of the Real-time Streaming Protocol (RTSP) over TLS. 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, PAUSE, SETUP, SET_PARAMETER, and TEARDOWN. Encoding considerations: IRIs in this scheme are defined and needs to be encoded as RTSP URIs when used within the RTSP protocol. That encoding is done according to RFC 3987. Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 2326), RTSP 2.0 (RFC XXXX) Interoperability considerations: The change in URI syntax performed between RTSP 1.0 and 2.0 can create interoperability issues. Security considerations: All the security threats identified in Section 7 of RFC 3986 applies also to this scheme. They need to be reviewed and considered in any implementation utilizing this scheme. Schulzrinne, et al. Expires September 13, 2012 [Page 223] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) March 2012 Contact: Magnus Westerlund, magnus.westerlund&lt; at &gt;ericsson.com Author/Change controller: IETF References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX 22.14.3. The rtspu URI Scheme URI scheme name: rtspu Status: Permanent URI scheme syntax: See Section 3.2 of RFC 2326. URI scheme semantics: The rtspu scheme is used to indicate resources accessible through the usage of the Real-time Streaming Protocol (RTSP) over unreliable datagram transport. 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, PAUSE, SETUP, SET_PARAMETER, and TEARDOWN. Encoding considerations: IRIs in this scheme are not defined. Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 2326) Interoperability considerations: The definition of the transport mechanism of RTSP over UDP has interoperability issues. That makes the usage of this scheme problematic. Security considerations: All the security threats identified in Section 7 of RFC 3986 applies also to this scheme. They needs to be reviewed and considered in any implementation utilizing this scheme. Contact: Magnus Westerlund, magnus.westerlund&lt; at &gt;ericsson.com Author/Change controller: IETF References: RFC 2326 </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 following additional constraints for the sip6 URI scheme are not broken, by implementing them inasfar as it concerns their processing: * All SIP, media descriptive and media traffic that follows from a sip6 URI scheme MUST be communicated over IPv6, and describe IPv6-capable resources. * All RTP traffic that follows from a a sip6 URI MUST support ZRTP [RFC6189] and actively attempt to establish ZRTP. Descriptions of such RTP communications SHOULD offer ZRTP. These additional requirements describe a method of deploying SIP that brings it nearer to its ideal configuration; namely, without any need for an intermediate party in the media path. There are advantages to deploying configurations that only work within these constraints, but with only a sip URI scheme such configurations would not be discovered until a call setup was being attempted, leading to potential end-user experiences of broken calls. The sip6 URI scheme is intended to avoid that problematic behavior. Applications/protocols that use this URI scheme name. The Session Initiation Protocol can be used with the sip6 URI scheme. With the exception that the aforementioned additional requirements apply, the processing is not in any way different. Specifically, the protocol continues to be named SIP in transport descriptions, and _sip._udp continues to be used a DNS name for SRV records. The syntactic declaration of support of this scheme can help to make an early selection of the proper tools, either by an end-user who can be properly informed, or by generic browsing tools that start different handling agents for the sip and sip6 URI schemes. A SIP phone that dials a sip6 URI can be certain that IPv6-only communication suffices; the phone can refuse attempts to dial such a number if IPv6 is not available, and prefer a sip URI alternative if it is available. On the other hand, current SIP phones that only support IPv4 will not recognise the sip6: URI scheme, and as a result skip attempts to contact them. There is no prohibition on translating proxies that map the sip6 URI sphere to the sip URI sphere, provided that the sip6 side of such proxies conceals the parts of the sip side that are not compliant to the additional requirements on the sip6 side. Interoperability considerations. The sip URI suggests a capability to communicate over IPv4 and IPv6, but in practice these protocols are incompatible. The result of having both address schemes under the same URI scheme can lead to interoperability problems. The introduction of a separate URI scheme for SIP over IPv6 improves this situation, by reflecting the incompability of the IPv4 and IPv6 spaces in an easily processed form. The required support for ZRTP implies that any implementations that use RTP but do not implement ZRTP facilities are inoperable with the sip6 URI format. This too is a deliberate choice that leads to more certainty to be derived from the connections being setup. Security considerations. The usual security considerations for SIP apply, with the exception that the requirement of ZRTP support reduces the risks of phone tapping and man-in-the-middle attacks. Contact. Rick van Rein &lt;rick&lt; at &gt;openfortress.nl&gt; Author/Change controller. Rick van Rein &lt;rick&lt; at &gt;openfortress.nl&gt; References. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC6189] Zimmermann, P., Zfone Project, Johnston, E., Ayaya and Calls, J., "ZRTP: Media Path Key Agreement for Unicast Secure RTP", April 2011. _______________________________________________ Uri-review mailing list Uri-review&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/uri-review </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 in time. Open Mobile Alliance is using this on multiple network enablers, to allow anonymous access to API's Any advice would be helpful. :) BR Sune Jakobsson </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 for mobile, ubiquitous printing with generic drivers. The following versions of IPP are currently defined: - 1.0 in [RFC2566] (obsolete) - 1.1 in [RFC2911] - 2.0 in [PWG5100.12] - 2.1 in [PWG5100.12] - 2.2 in [PWG5100.12] Cheers, - Ira McDonald (Co-Chair of IPP WG in IEEE-ISTO PWG) References: [IPPEVE] McDonald, I. and M. Sweet, "PWG IPP Everywhere 1.0", work-in-progress, August 2011. &lt;http://www.pwg.org/ipp&gt; [PWG5100.12] Bergman, R., Lewis, H., McDonald, I., and M. Sweet, "Internet Printing Protocol Version 2.0 Second Edition (IPP/2.0 SE)", PWG 5100.12, February 2011. &lt;http://www.pwg.org/standards.html&gt; [RFC2911] Hastings, T., Ed., Herriot, R., deBry, R., Isaacson, S., and P. Powell, "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, September 2000. ----------------------------------------------------------------- Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG IETF Designated Expert - IPP &amp; Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic&lt; at &gt;gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 _______________________________________________ Uri-review mailing list Uri-review&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/uri-review </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 own conventions for passing the method and query parameters into the application. Encoding considerations. The scheme and method portions of this proposed URI avoid encoding issues by limiting itself to a subset of ASCII. The query portion of a com-eventbrite-attendee URI shall be encoded according to the rules in RFC 3986. Applications/protocols that use this URI scheme name. - Eventbrite Attendee for iOS - Eventbrite Attendee for Android Interoperability considerations. none. Security considerations. Against recommendations in RFC 3986 section 7.5 a com-eventbrite-attendee: URI may be used to transmit sensitive information. For example, it may be used to communicate a password reset token in email for a user following a "Forgot your password" flow. Though this token may have transmitted over insecure channels on its way to the application care must still be taken by application developers to not divulge this secret. RFC 3986 sections 7.2 and 7.5 apply Contact. Bob Van Zant Eventbrite 651 Brannan St San Francisco, CA 94103 USA EMail: bob&lt; at &gt;eventbrite.com Author/Change controller. Bob Van Zant References. Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. </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. http://pwg-wiki.wikispaces.com/IPP+Everywhere IPP/1.1 [RFC2911] is now ubiquitous (i.e., supported by all network printers shipped in the last decade). IPP/2.0 (workgroup), IPP/2.1 (enterprise), and IPP/2.2 (datacenter), all defined in [PWG5100.12], are now being deployed. However, many IPP implementations don't support the TLS upgrade (OPTIONAL for conformance in RFC 2910/2911). And some IPP implementations don't immediately upgrade at connection startup (which is non-conforming). This situation has discouraged the use of IPP over public Internet connections. The IPP Everywhere project [IPPEVE] of the IEEE-ISTO PWG mandates the use of TLS for *all* connections. Therefore, a given 'ipps' URI is translated by identity (over port 631) into an 'https' URI (RFC 2818) - see section 3.2 of this memo. 'ipps' URI values also must use UTF-8 (RFC 3629). The 'ipps' URI scheme has been deployed for many years in [CUPS] - the most widely deployed implementation of an IPP print service - CUPS is the default print spooler on Mac OS X, Linux, and most UNIX versions and is also available on Windows and other operating systems. Cheers, - Ira McDonald (Co-Chair of IPP WG in IEEE-ISTO PWG) References: [CUPS] &lt;http://www.cups.org&gt; [IPPEVE] McDonald, I. and M. Sweet, "PWG IPP Everywhere First Edition", work-in-progress, August 2011. &lt;ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve10-20110803.pdf&gt; [PWG5100.12] Bergman, R., Lewis, H., McDonald, I., and M. Sweet, "Internet Printing Protocol Version 2.0 Second Edition (IPP/2.0 SE)", PWG 5100.12, February 2011. &lt; ftp://ftp.pwg.org/pub/pwg/candidates/cs-ipp20-20110214-5100.12.pdf&gt; [RFC2910] Herriot, R., Ed., Butler, S., Moore, P., Turner, R., and J. Wenn, "Internet Printing Protocol/1.1: Encoding and Transport", RFC 2910, September 2000. [RFC2911] Hastings, T., Ed., Herriot, R., deBry, R., Isaacson, S., and P. Powell, "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, September 2000. Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Co-Chair - IEEE-ISTO PWG IPP WG Chair - TCG Embedded Systems Hardcopy SWG IETF Designated Expert - IPP &amp; Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic&lt; at &gt;gmail.com Christmas through April: 579 Park Place Saline, MI 48176 734-944-0094 May to Christmas: PO Box 221 Grand Marais, MI 49839 906-494-2434 _______________________________________________ Uri-review mailing list Uri-review&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/uri-review </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: The generic and overall URI syntax is specified in STD 66, anything else (not limited to pack:) is no URI and could cause havoc, compare &lt;http://www.kb.cert.org/vuls/id/358017&gt;. Contact: &lt;uri-review&lt; at &gt;ietf.org&gt; and &lt;uri&lt; at &gt;w3.org&gt; mailing lists. Author/Change controller: IESG (the transition from a "provisional" to "historical" status is not covered by BCP 35 section 5.3; maybe the pack: scheme could be simply identified as "non-URI" and removed from the scheme registry). References: STD 66 (RFC 3986), I-D.shur-pack-uri-scheme-05 (same as -03 and -04). </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 though it is actually PS). They're probably the only two schemes (not considering 'afs', but it's in provisional regsitry) that are listed at IANA registry, in the Permanent category, with a reference to obsoleted RFC (maybe, 'fax' can be considered to be so as well; but is it de facto deprecated and hsitorical). 'ftp' and 'file' schemes are quite widely-used; obsolete RFC 1738 is an actual specification for them. There has been an effort to specify this schemes in separate docs. (https://datatracker.ietf.org/doc/draft-hoffman-ftp-uri/, https://datatracker.ietf.org/doc/draft-hoffman-file-uri/), but they resulted in nothing (unlike eg. RFC 4248, as a part of the same effort, if I'm right). Considering this, should an attempt to provide these schemes an up-to-date specification be undertaken? 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-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 _______________________________________________ Uri-review mailing list Uri-review&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/uri-review </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