Dave, we do of course make the point that it's only locally significant, but a reference to that paragraph of 3986 would complete the story.
Regards Brian On 09/07/2012 19:54, Dave Thaler wrote: > One additional gap that I think SHOULD be addressed. RFC 3986 says: > > URIs have a global scope and are interpreted consistently regardless > of context, though the result of that interpretation may be in > relation to the end-user's context. For example, "http://localhost/"; > has the same interpretation for every user of that reference, even > though the network interface corresponding to "localhost" may be > different for each end-user: interpretation is independent of access. > However, an action made on the basis of that reference will take > place in relation to the end-user's context, which implies that an > action intended to refer to a globally unique thing must use a URI > that distinguishes that resource from all other things. URIs that > identify in relation to the end-user's local context should only be > used when the context itself is a defining aspect of the resource, > such as when an on-line help manual refers to a file on the end- > user's file system (e.g., "file:///etc/hosts"). > > It should be pointed out in the zoneid document that adding a zone id > changes the scope to be localhost rather than the scope of the address. > > So "http://[fe80::1]/blah"; is valid anywhere on the same link. > But "http://[fe80::1-id]/blah"; is valid only within the same host. > > -Dave > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Dave Thaler >> Sent: Friday, July 6, 2012 10:33 AM >> To: Brian E Carpenter; Bob Hinden >> Cc: [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 >> >> 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 >> -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
