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

[t.petch <[e-mail]>]

----- Original Message -----
From: "Brian E Carpenter" <[e-mail]>
To: "Bob Hinden" <[e-mail]>
Cc: <[e-mail]>;
<[e-mail]>; <[e-mail]>; "Dave
Thaler" <[e-mail]>
Sent: Friday, July 06, 2012 5:56 PM
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?
>

Non-normative Appendix, Please.

Tom Petch

> 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
>
>> --------------------------------------------------------------------
> >
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>