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 --------------------------------------------------------------------
