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/1040 <pre>We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. _______________________________________________ Uri-review mailing list Uri-review&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/uri-review </pre> hammondjohnson< at >hushmail.com 2013-04-27T17:53:33 http://comments.gmane.org/gmane.ietf.uri-review/1026 <pre>Hi, This is a request for registration of an URI scheme, dchub. The scheme can be viewed at &lt;http://nmdc.sourceforge.net/nmdc-uri-scheme.txt&gt;. The URI scheme should meet the necessary requirements for a Permanent URI scheme, as indicating in RFC 4395. The scheme specifies encoding, interoperability and security aspects (and more). If the scheme should not provide enough information for a Permanent scheme, please specify what is lacking or at least consider a Provisional request instead. </pre> Fredrik Ullner 2013-02-20T20:26:31 http://comments.gmane.org/gmane.ietf.uri-review/1011 <pre> hello, in accordance with section "5.2. Registration Procedures" of RFC 4395 "Guidelines and Registration Procedures for New URI Schemes", I respectfully request a review for our planned permanent registration request of the PKCS#11 URI as specified in the following I-D: http://tools.ietf.org/html/draft-pechanec-pkcs11uri-08 the registration template is attached. best regards, Jan Pechanec </pre> Jan Pechanec 2013-01-26T22:38:01 http://comments.gmane.org/gmane.ietf.uri-review/1010 <pre>This message constitutes a request for review of the proposed 'acct' URI scheme, specified in draft-ietf-appsawg-acct-uri-02. The completed registration template follows (copied from the IANA Considerations of the aforementioned I-D). Peter ### 4. IANA Considerations In accordance with the guidelines and registration procedures for new URI schemes [RFC4395], this section provides the information needed to register the 'acct' URI scheme. 4.1. URI Scheme Name acct 4.2. Status permanent 4.3. URI Scheme Syntax The 'acct' URI syntax is defined here in Augmented Backus-Naur Form (ABNF) [RFC5234], borrowing the 'host', 'pct-encoded', 'sub-delims', 'unreserved' rules from [RFC3986]: acctURI = "acct" ":" userpart "&lt; at &gt;" host userpart = 1*( unreserved / pct-encoded / sub-delims ) 4.4. URI Scheme Semantics The 'acct' URI scheme identifies accounts hosted at service providers. It is used only for identification, not interaction. A protocol that employs the 'acct' URI scheme is responsible for specifying how an 'acct' URI is dereferenced in the context of that protocol. There is no media type associated with the 'acct' URI scheme. 4.5. Encoding Considerations The 'acct' URI scheme allows any character from the Unicode repertoire [UNICODE] encoded as UTF-8 [RFC3629] and then percent- encoded into valid ASCII [RFC20] as specified in [RFC3986]. Note that domain labels need to be encoded as A-labels (see [RFC5890]) in order to support internationalized domain names (IDNs). 4.6. Applications/Protocols That Use This URI Scheme Name At the time of this writing, only the WebFinger protocol uses the 'acct' URI scheme. However, use is not restricted to the WebFinger protocol, and the scheme might be considered for use in other protocols, such as Simple Web Discovery. 4.7. Interoperability Considerations There are no known interoperability concerns related to use of the 'acct' URI scheme. 4.8. Security Considerations See Section 5 of RFCXXXX. [Note to RFC Editor: please replace XXXX with the number issued to this document.] 4.9. Contact Peter Saint-Andre, psaintan&lt; at &gt;cisco.com 4.10. Author/Change Controller This scheme is registered under the IETF tree. As such, the IETF maintains change control. 4.11. References None. ### </pre> Peter Saint-Andre 2013-01-10T03:32:46 http://comments.gmane.org/gmane.ietf.uri-review/967 <pre>Dear uri-review, Some time ago, I published a rather 'light' I-D which documents the dvb: URI scheme, as used by cable, satellite and terrestrial TVs, PVRs and set-top boxes which adhere to the DVB[1][2] standard (and some more besides). Since then, I've collaborated with Alexander Adolf, who chairs the Generic Data Broadcasting &amp; Service Information Protocols working group[3] of the DVB Project, to flesh out the draft into something which is a little more useful without referring back to the canonical reference for the scheme, ETSI TS 102 851. As we are both relatively satisfied that the draft can be considered stable, we are looking to move from provisional to permanent registration of the scheme at IANA, and publication of the draft as an RFC. As a step towards that, we're putting out this call for comments here. It's probably worth stressing that the intent of the I-D is to document (and codify within the Internet, rather than broadcasting, community) the existing behaviour and design of the scheme; as retrospective documentation goes, this one's covering a scheme which is pretty well-baked. That said, I'm sure Alexander will be more than happy to feed back any constructive criticism of the scheme itself via the DVB TM-GBS group to help shape future editions of the standards. Please do CC: Alexander and me in any replies as we're not subscribed to the list. Many thanks, Mo. [1] http://www.dvb.org [2] http://en.wikipedia.org/wiki/Digital_Video_Broadcasting [3] http://www.dvb.org/groups_modules/technical_module/tmgbs/index.xml?groupID=5 -- Mo McRoberts - Technical Lead - The Space 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E, Zone 1.08, BBC Scotland, Pacific Quay, Glasgow, G51 1DA Project Office: Room 7083, BBC Television Centre, London W12 7RJ ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ----------------------------- </pre> Mo McRoberts 2012-10-28T23:30:21 http://comments.gmane.org/gmane.ietf.uri-review/962 <pre>Hi, On yesterday's telcon[1], the CSS WG resolved to mint about:invalid, which is now defined in CSS3 Values and Units as "a URI [that points] to a non-existent document with a generic error condition."[2] I don't think "The 'about' URI scheme" needs to change as a result. Thanks, Ted 1. http://lists.w3.org/Archives/Public/www-style/2012Jul/0109.html 2. http://dev.w3.org/csswg/css3-values/#attr-notation </pre> Edward O'Connor 2012-07-05T18:43:13 http://comments.gmane.org/gmane.ietf.uri-review/962 <pre>Hi, On yesterday's telcon[1], the CSS WG resolved to mint about:invalid, which is now defined in CSS3 Values and Units as "a URI [that points] to a non-existent document with a generic error condition."[2] I don't think "The 'about' URI scheme" needs to change as a result. Thanks, Ted 1. http://lists.w3.org/Archives/Public/www-style/2012Jul/0109.html 2. http://dev.w3.org/csswg/css3-values/#attr-notation </pre> Edward O'Connor 2012-07-05T18:43:13 http://comments.gmane.org/gmane.ietf.uri-review/961 <pre>URI Reviewers, We are progressing work in the IETF on WebFinger.  As a component of that work, we have defined the “acct” URI scheme that we would like to register.  The “acct” URI scheme was first proposed several years ago in the Internet community and already adopted in some implementations (including Google+), etc.  The specification attempts to formalize and finalize the WebFinger specification, including the “acct” URI scheme. The URI scheme registration template  can be found in Section 12.1 of this draft: http://tools.ietf.org/id/draft-jones-appsawg-webfinger-06.txt We kindly request that you review the proposed URI scheme. We look forward to your feedback. Thanks! Paul </pre> Paul E. Jones 2012-06-18T05:46:19 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 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.uri-review