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

[Dave Thaler <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
> Dave Thaler
> Sent: Monday, July 16, 2012 2:56 PM
> To: Brian E Carpenter; [e-mail]
> 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: [e-mail] [mailto:[e-mail]] On Behalf
> > Of Brian E Carpenter
> > Sent: Sunday, July 15, 2012 12:58 AM
> > To: [e-mail]
> > 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
> > [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
> --------------------------------------------------------------------