Subject: RE: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt]

From: Dave Thaler <[email-masked]>
Date: Tue, 7 Aug 2012 22:44:07 +0000

FYI, as another data point that might be added to the appendix of alternatives
and things that are already out there, would be using 's' as the separator rather
than '-'.

That's the character that's used by ipv6-literal.net names.
See http://ipv6-literal.com/ for a converter, and
http://technet.microsoft.com/en-us/library/bb726965.aspx for one place the
syntax is doc'ed.  You'll have to search for it on the page though, but to save
you the trouble I'll quote it here:

> An ipv6-literal.net name can be used in services or applications that do not
> recognize the syntax of normal IPv6 addresses. 
> 
> To specify an IPv6 address within the ipv6-literal.net name, convert the 
> colons (:) in the address to dashes (-). For example, for the IPv6 address 
> 2001:db8:28:3:f98a:5b31:67b7:67ef, the corresponding ipv6-literal.net 
> name is 2001-db8-28-3-f98a-5b31-67b7-67ef.ipv6-literal.net. To specify a
> zone ID (also known as a scope ID), replace the "%" used to separate the
> IPv6 address from the zone ID with an "s". For example to specify the
> destination fe80::218:8bff:fe17:a226%4, the name is
>  fe80--218-8bff-fe17-a226s4.ipv6-literal.net.

The above syntax was designed to be usable even by applications that didn't
support [] syntax in URIs.

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Dave Thaler
> Sent: Monday, July 16, 2012 2:56 PM
> To: Brian E Carpenter; [email-masked]
> Subject: RE: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt]
> 
> I'm ok with the updated text Brian posted.
> 
> To comment on the other points others raised:
> 
> * I agree that we should define either '%' or '-' as being the canonical form.
>    RFC 5952 covers issues with not having one, and defines a canonical form
>    for IPv6 literals, but does not mention the zone id at all.   If we want safe
>    cut-and-paste, then '-' needs to be defined as canonical (i.e., what you
>    output).   However, you won't get cut-and-paste to things that haven't
>    been updated to support it.   So one conclusion you might draw is that
>    you can't get cut-and-paste *everywhere* within our lifetime, and you
> should
>    just get used to it.  And if you're one of the people who draws that
> conclusion
>    then you might even go so far as to question the whole document, which
>    seems to be where Juergen is coming from.
> 
> * Brian writes: "What we do *not* say is to recommend or suggest that all
>    tools that support RFC 4007 should be updated. Should we also add that?"
> 
>    If we really care about cut-and-paste, then yes.   Which is why this
> document
>    is so difficult to get benefit from, since it requires changing so many things.
>    (See last paragraph of [RFC5218] section 2.1.1.)
> 
> * Juergen writes: "Changing all our standards to support "-" and then waiting
>     years for this to be supported by all the system tools is from a users'
>     perspective pretty much a disaster."
> 
>    I'm actually fairly sympathetic to that point of view.
> 
>    The status quo without this document is basically that you cannot use
>    zone IDs in URIs, although some apps and OSs support URI-like strings
>    that do allow them but it may vary by app and OS.   With this document,
>    the story is that you can use them in some (updated) applications and
>    thus sometimes you can get cut-and-paste.   That sounds like a small
>    benefit to get from requiring changes to all IPv6 literal (including in URIs)
>    parsers/generators.   This doesn't seem to bode well from an RFC 5218
>    analysis standpoint.
> 
> * Juergen writes: " If it were that simple, we could simply recommend that
>     browsers should be lenient and accept the %en1 format. The question is
>     really whether Internet Explorer people would do so and whether Firefox
>     people would go back to support what they apparently did before."
> 
>    As I mentioned in my original email, it's not just IE 7 and up, it's also the
>    OS APIs so it's pretty pervasive (again, not on the wire just in APIs within
>    the host) so I think you mean "whether IE and Windows people would do
> so".
>    I think it's probably safe to assume the answer is "No" because it may result
>    in breaking applications.   That's not something that's worth it just to get
>    "cut-and-paste" which is nowhere near as important as app compat.
> 
> -Dave
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Brian E Carpenter
> > Sent: Sunday, July 15, 2012 12:58 AM
> > To: [email-masked]
> > Subject: Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt]
> >
> > Without consulting my co-author, here's my personal suggestion for a
> > change to the draft. There's just time to submit an update before the
> > cutoff, if people respond immediately.
> >
> > OLD
> >    In recent years, web browsers have evolved considerably and now
> >    accept and parse many forms of input that are not a formal URI.
> >    Examples of this include host names, search items, bookmarks, search
> >    history, etc.  For example the Google Chrome browser now calls the
> >    "address bar" the "omnibox" [chrome].  The authors believe it is
> >    feasible, and very convenient for users, if browsers also allow (in
> >    addition to the formal URI syntax defined in this document) a syntax
> >    that will enable cut and paste.  For example:
> >
> >      http://[fe80::a%en1]
> >
> >    It seems that modern browsers can be adapted to parse this because it
> >    is inside of the "[" "]"'s.  This would permit the output of commands
> >    like ping6 -w ff02::1%en1 to be "cut and pasted" into a browser
> >    address bar.  Consequently this document recommends that browsers
> >    support this syntax in addition to the formal URI syntax defined
> >    above.
> >
> > NEW
> >
> >    In recent years, web browsers have evolved considerably and now
> >    accept and parse many forms of input that are not a formal URI.
> >    Examples of this include host names, search items, bookmarks, search
> >    history, etc.  For example the Google Chrome browser now calls the
> >    "address bar" the "omnibox" [chrome]. Thus, it seems that browsers
> >    can take a pragmatic approach to literal addresses including ZoneIDs.
> >    Unfortunately there is no way to resolve the discrepancy between
> >    the two approaches mentioned above (raw "%" versus "%25") and
> >    therefore we recommend general implementation of the new "-" syntax
> >    defined by this document. This will allow simple "cut and paste"
> >    between tools such as "ping6" and browser address bars.
> >
> >  Brian
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [email-masked]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------