Re: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt

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

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=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: [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
>> --------------------------------------------------------------------
> 
>