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

[Dave Thaler <[e-mail]>]

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
> --------------------------------------------------------------------