I'd be happy with that, or a small appendix. Dave, is it documented anywhere?
Regards Brian On 2012-07-06 15:00, Bob Hinden wrote: > With my co-author hat on, would it help to include a description of what IE > supports in Section 3. Web Browsers? > > Bob > > > On Jul 6, 2012, at 6:01 AM, Brian E Carpenter wrote: > >> Dave, >> >> 1) FYI, the deadline we gave the URI list to comment on this has just >> passed, with only one (positive) reply. >> >> 2) It's for the WG Chairs to say if they want another version >> in view of your comments. >> >> 3) I don't see how the % format is currently legal. There's >> no provision for any characters after the IPv6 address, whether >> percent-encoded or not. We heard of browsers that previously >> allowed full RFC 4007 syntax (% *not* treated as an escape) >> but this is the first I've heard of IE allowing a zone index >> at all. >> >> Regards >> Brian >> >> On 2012-07-06 02:28, Dave Thaler wrote: >>> I know it's after the designated end of WGLC, but here's my feedback... >>> >>> The document appears to call out existing practice in several places, such >>> as in section 1: >>>> Some versions of some browsers accept the RFC 4007 syntax for scoped >>>> IPv6 addresses embedded in URIs, i.e., they have been coded to >>>> interpret the "%" sign according to RFC 4007 instead of RFC 3986. >>> and in Appendix A point 1: >>>> Advantage: works today. >>> However, it's missing discussion of other alternatives already in common >>> practice. >>> For example alternative 3 (escaping the escape character as allowed by RFC >>> 3986) has: >>>> Advantage: allows use of browser. >>>> >>>> Disadvantage: ugly and confusing, doesn't allow simple cut and >>>> paste. >>> The disadvantage is certainly true. However the main advantage are notably >>> lacking, which is that it's already in common practice in many places (to >>> the extent >>> that using a zone id at all is common practice anyway). >>> >>> You'll see at >>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa385325(v=vs.85).aspx >>> that alternative 3 is what is supported in IE7 and above, and the APIs are >>> generally >>> available to Windows applications (i.e. not just IE7). >>> >>> The document does not state whether the existing legal use is suddenly >>> declared to be illegal, or just another legal way of doing the same thing. >>> >>> If you're telling existing applications and OS's that use alternative 3 >>> that they >>> have to change, that doesn't sound like a good thing. That's because many >>> apps >>> want to be OS-version-independent and use URI parsing libraries provided by >>> the OS. We don't want apps to code their own URI parsing (it's very easy >>> to >>> get wrong, especially when you add various internationalization issues). >>> As a result, apps will tend to code to the lowest common denominator of >>> OS's they want to work on. That means I expect to see apps coding to >>> alternative 3 for the foreseeable future. When they don't use them in >>> edit boxes, the disadvantage of not being able to cut and paste is not a >>> real disadvantage. >>> >>> Personally I don't have an issue with allowing both formats if the WG feels >>> strongly that a cut-and-paste-friendly format is needed in addition to >>> what's existing practice, though having two does affect the rules for >>> comparison (see draft-iab-identifier-comparison section 3.1.2) but not >>> noticeably. >>> >>> Finally, the stated disadvantage of alternative 3 is only a disadvantage if >>> the >>> specified scheme in section 2 *does* allow cut-and-paste. For that to >>> happen, it means the zone id separator has to work outside the context of >>> URIs. That is, section 2 says: >>>> Thus, the scoped address fe80::a%en1 would appear in a URI as >>>> http://[fe80::a-en1]. >>> To support cut-and-paste, that means that >>> "ping fe80::a-en1" >>> needs to work. But this document is titled >>> " Representing IPv6 Zone Identifiers in Uniform Resource Identifiers" >>> and similarly the abstract limits its scope to URIs. >>> >>> Hence section 2 is in contradiction with the analysis of alternative 3. >>> The document already says it "updates 4007" so it seems that what's >>> lacking is a section specifically updating RFC 4007 section 11 which would >>> declare that both '%' and '-' are acceptable separators in the textual >>> representation. >>> >>> -Dave >>> >>>> -----Original Message----- >>>> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of >>>> Ole Trøan >>>> Sent: Wednesday, June 13, 2012 5:18 AM >>>> To: ipv6@ietf.org Mailing List >>>> Cc: 6man-cha...@tools.ietf.org Chairs; draft-ietf-6man-uri- >>>> zon...@tools.ietf.org >>>> Subject: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt >>>> >>>> All, >>>> >>>> This message starts a one-week 6MAN Working Group Last Call on advancing: >>>> Title : Representing IPv6 Zone Identifiers in Uniform >>>> Resource Identifiers >>>> Author(s) : Brian Carpenter >>>> Robert M. Hinden >>>> Filename : draft-ietf-6man-uri-zoneid-01.txt >>>> Pages : 9 >>>> Date : 2012-05-29 >>>> >>>> >>>> as a Proposed Standard. Substantive comments should be directed to the >>>> mailing list or the co-chairs. Editorial suggestions can be sent to the >>>> authors. >>>> This last call will end on June 20, 2012. >>>> Regards, >>>> Bob, & Ole >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
