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

[Dave Thaler <[e-mail]>]

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