It's documented on the page in my original email. However it's not sufficient. Remember my second piece of feedback was that the document contradicts itself, implying the specified syntax supports cut and paste, but then doesn't provide a section updating RFC 4007 section 11.
If the document both mentions that alternative 3 is used by many things today (IE, Windows, applications) within APIs that take URI-like strings, and also adds a section updating RFC 4007 section 11, then I'd be happy with it. -Dave > -----Original Message----- > From: Brian E Carpenter [mailto:[email protected]] > Sent: Friday, July 06, 2012 9:57 AM > To: Bob Hinden > Cc: Dave Thaler; [email protected] Chairs; draft-ietf-6man-uri- > [email protected]; [email protected] Mailing List > Subject: Re: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt > > 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=v > >>> s.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: [email protected] [mailto:[email protected]] On > >>>> Behalf Of Ole Trøan > >>>> Sent: Wednesday, June 13, 2012 5:18 AM > >>>> To: [email protected] Mailing List > >>>> Cc: [email protected] Chairs; draft-ietf-6man-uri- > >>>> [email protected] > >>>> 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 [email protected] Administrative > >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>>> ------------------------------------------------------------------- > >>>> - > >>> > >>> -------------------------------------------------------------------- > >>> IETF IPv6 working group mailing list [email protected] Administrative > >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>> -------------------------------------------------------------------- > >>> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> [email protected] > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
