Candidate draft-ietf-6man-uri-zoneid-02

[Brian E Carpenter <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
>>> Dave Thaler
>>> Sent: Friday, July 6, 2012 10:33 AM
>>> To: Brian E Carpenter; Bob Hinden
>>> Cc: [e-mail] Chairs; draft-ietf-6man-uri-
>>> [e-mail]; [e-mail] 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:[e-mail]]
>>>> Sent: Friday, July 06, 2012 9:57 AM
>>>> To: Bob Hinden
>>>> Cc: Dave Thaler; [e-mail] Chairs;
>>>> draft-ietf-6man-uri- [e-mail]; [e-mail] 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: [e-mail] [mailto:[e-mail]] On
>>>>>>>> Behalf Of Ole Trøan
>>>>>>>> Sent: Wednesday, June 13, 2012 5:18 AM
>>>>>>>> To: [e-mail] Mailing List
>>>>>>>> Cc: [e-mail] Chairs; draft-ietf-6man-uri-
>>>>>>>> [e-mail]
>>>>>>>> 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 [e-mail]
>>>>>>>> Administrative
>>>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>>> -----------------------------------------------------------------
>>>>>>>> --
>>>>>>>> -
>>>>>>> ------------------------------------------------------------------
>>>>>>> -- IETF IPv6 working group mailing list [e-mail]
>>>>>>> Administrative
>>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>> ------------------------------------------------------------------
>>>>>>> --
>>>>>>>
>>>>>> -------------------------------------------------------------------
>>>>>> - IETF IPv6 working group mailing list [e-mail] Administrative
>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>> -------------------------------------------------------------------
>>>>>> -
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
> 
>