Sorry - thought I'd deleted the cc to the list. Regards Brian Carpenter
On 10/07/2012 14:54, Brian E Carpenter wrote: > Bob (as co-author) and Dave (as reviewer), > > Here's a proposed update and a diff file. > > Please let me know ASAP if this is OK for you, as the cutoff is approaching. > > Regards > Brian > > On 10/07/2012 08:13, Brian E Carpenter wrote: >> 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: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of >>>> Dave Thaler >>>> Sent: Friday, July 6, 2012 10:33 AM >>>> To: Brian E Carpenter; Bob Hinden >>>> Cc: 6man-cha...@tools.ietf.org Chairs; draft-ietf-6man-uri- >>>> zon...@tools.ietf.org; ipv6@ietf.org 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:brian.e.carpen...@gmail.com] >>>>> Sent: Friday, July 06, 2012 9:57 AM >>>>> To: Bob Hinden >>>>> Cc: Dave Thaler; 6man-cha...@tools.ietf.org Chairs; >>>>> draft-ietf-6man-uri- zon...@tools.ietf.org; ipv6@ietf.org 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: 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 >>>> -------------------------------------------------------------------- >> -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
