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