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 protected] [mailto:[email protected]] On Behalf Of > Dave Thaler > Sent: Monday, July 16, 2012 2:56 PM > To: Brian E Carpenter; [email protected] > 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 protected] [mailto:[email protected]] On Behalf > > Of Brian E Carpenter > > Sent: Sunday, July 15, 2012 12:58 AM > > To: [email protected] > > 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 protected] > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
