Subject: Re: Options for draft-ietf-6man-uri-zoneid

From: t.petch <[email-masked]>
Date: Fri, 4 May 2012 09:47:58 +0200

Brian

To me, Option 3 is the clear, right way to go.

Percent escaping is the purist answer, fine for URI experts who deal with
percent escaping all the time.  Most of the world is completely comfortable with
URIs as long as they look like
www.example.com/user/sample.html
Some get confused even by the addition of http: and most would be completely
thrown by the appearance of a percent sign (even if they are always appearing on
the Internet Explorer address bar, which most people either do not look at or
have turned off).

I believe that the audience for this feature is widespread, not just limited to
URI experts.  IPv6 is horribly complicated, it will often go wrong, so I see
help desks asking users to key this in as a common use case.  In which case, you
need a simple to locate on the keyboard, simple to refer to in 'English',
character to separate the two fields.  %25 is not it.

Anything else would do but I think that underscore is the worst choice, because
it vanishes.
http://[fe80::a_en1
on my Microsoft MUA displays, underlined in blue, as
f e 8 0 : : a [space] e n 1
so that is what I know it is; except of course I am a URI expert so I know that
if it were really a space, the e n 1 would not be underlined in blue so there is
a invisible underline there!

tilde is nice, but too hard to find on the keyboard, so, of unreserved, that
leaves period or hyphen; I would go for hyphen.

--- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: "6man" <[email-masked]>
Sent: Sunday, April 29, 2012 9:54 AM

> In the IETF 83 discussion of draft-ietf-6man-uri-zoneid-00,
> there was no clear consensus on the approach to pursue. In fact,
> almost the same discussion occurred around draft-fenner-literal-zone
> several years ago, but at that time the topic was simply dropped.
>
> This note summarises the main options. As a reminder, the problem to
> be solved is how to tell a browser which interface to use when sending
> packets to a literal link-local address. The reason for doing this is
> purely for diagnostic purposes, since the Zone ID that identifies an
> interface has no significance outside the sending host. For more details,
> see the two drafts mentioned above.
>
> What we have today: link local address with no Zone ID
>    http://[fe80::a]
>
> The user cannot select the outgoing interface if there is more than one.
>
> The obvious solution would be to use the RFC4007 syntax (for an
> example Zone ID of en1):
>
>    http://[fe80::a%en1]
>
> However, this is impossible because % is *always* an escape character in
> URI syntax [RFC3986]. There is no chance of the URI community accepting
> such a hack to the syntax, so it isn't an option for us.
>
> The available options are therefore
>
> 1) Leave the problem unsolved.
>
> This would mean that per-interface diagnostics would still have to be
> performed using ping or ping6
>
>    ping fe80::a%en1
>
> Advantage: works today.
>
> Disadvantage: less convenient than using a browswer.
>
> 2) Escaping the escape character as allowed by RFC 3986:
>
>    http://[fe80::a%25en1]
>
> Advantage: allows use of browser.
> Disadvantage: ugly and confusing, doesn't allow simple cut and paste.
>
> 3) With alternative separator such as _
>
>    http://[fe80::a_en1]
>
> Advantage: allows use of browser.
> Disadvantage: doesn't allow simple cut and paste.
>
> 4) With the "IPvFuture" syntax left open in RFC 3986:
>
>    http://[v6.fe80::a_en1]
>
> Advantage: allows use of browser.
> Disadvantage: ugly and redundant, doesn't allow simple cut and paste.
>
> Thus, the WG has to choose between options 1), 2), 3) and 4).
>
> Opinions welcome!
>
>     Brian Carpenter

---

From: Ole Trøan <[email-masked]>
Date: Fri, 4 May 2012 12:39:58 +0200

> Disadvantage: ugly and confusing, doesn't allow simple cut and paste.

if we went with option 2; considering that most browsers accept other inputs than URIs,
could the UI input be as today (fe80::a%en1) and the URI representation as (fe80::a%25en1)?

presumably also with other characters in the interface name escaped.
e.g. if I input "interface Dot11Radio0/0/0" in Chrome's address bar I get
"interface+Dot11Radio0%2F0%2F0"

cheers,
Ole

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 4 May 2012 08:29:11 -0500

+1 for option 3 with hyphen. 

I like to be able to read the URI without having to put my glasses on.

Cheers,
Rajiv

Sent from my Phone

On May 4, 2012, at 3:50 AM, "t.petch" <[email-masked]> wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 4 May 2012 15:44:11 +0200

> I like to be able to read the URI without having to put my glasses on.

Interface names can contain other fancy characters and hence this one
will simply not work in the general case.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Simon Perreault <[email-masked]>
Date: Fri, 04 May 2012 09:54:36 -0400

> will simply not work in the general case.

The character just after the address is "special". We know it is special 
because it is just after the address. It can never be confused with the 
interface name itself. We could even choose something ridiculous, e.g. 
"x", as the special character and there would be no possibility of conflict.

+1 for hyphen

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: t.petch <[email-masked]>
Date: Fri, 4 May 2012 15:02:32 +0200

---- Original Message ----- 
From: "Simon Perreault" <[email-masked]>
To: <[email-masked]>
Sent: Friday, May 04, 2012 3:54 PM
Subject: Re: Options for draft-ietf-6man-uri-zoneid

> "x", as the special character and there would be no possibility of conflict.

Yes, it is a bit like Microsoft and their use of 
\
\\
\\\
which, because of the context, can safely be parsed.  Ditto some URI such as
file:///
file:////

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 4 May 2012 16:10:59 +0200

On Fri, May 04, 2012 at 09:54:36AM -0400, Simon Perreault wrote:
> The character just after the address is "special". We know it is
> special because it is just after the address. It can never be
> confused with the interface name itself. We could even choose
> something ridiculous, e.g. "x", as the special character and there
> would be no possibility of conflict.

My understanding is that URI formats place restrictions on the set of
allowed unquoted characters. Some vendors (e.g. Juniper) use interface
names that even contain slashes, e.g. fe-0/0/0. While replacing the %
separating the zone identifier (typically an interface name) solves
one problem, it does not solve the problems with fancy characters in
the zone identifier.

/js

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 4 May 2012 10:31:00 -0400

On Fri, May 4, 2012 at 10:10 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> Or even '%'.  Oops... never mind.

> If you look at the draft, you see that Brian has defined
ZoneID = 1*( unreserved / pct-encoded )
so any "fancy" characters would need to be pct-encoded in the URI
representation, but not in the UI.

Do we want to take this one step further and update RFC 5952 with some
sort of canonical representation for link-local addresses?  I'm thinking
that
in the fullness of time it would certainly be nice to have cut-and-paste
compatibility across IPv6 utilities.  We could certainly retrofit e.g. ping6
to use either '%' or '-'.  The folks who use it now (wizards) could continue
to use the old separator or do the mental gymnastics in their heads (they
are wizards, after all).  Folks like my mom wouldn't even have to be aware
that '%' was ever used (unless they're history of technology majors).

-K-

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 04 May 2012 16:52:23 +0100

Juergen, that is a defect in RFC 4007, which left the character set
undefined. We can't get that toothpaste back in the tube, but by using
the ABNF construct
  ZoneID = 1*( unreserved / pct-encoded )
we can get round these cases; we can't fix them I'm afraid.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 May 2012 15:26:20 +0100

> could the UI input be as today (fe80::a%en1) and the URI representation as (fe80::a%25en1)?

As far as I can tell, current browsers have dropped this, even if
Kerry still uses it in an ancient Firefox. IMHO this is not a viable
option for the browser folk.

> "interface+Dot11Radio0%2F0%2F0"

There seems to be no way out of that whatever we do.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 May 2012 15:33:07 +0100

I'm not exactly seeing overwhelming consensus, but the loudest
virtual hum was for

   http://[fe80::a-en1]

There was a suggestion to encourage a fix to ping (and traceroute?) to
allow the "-" separator, and we must note that in any case, strange
characters in the interface ID will always have to be %-encoded.

Regards
   Brian

On 2012-04-29 08:54, Brian E Carpenter wrote:
> Hi,

---

From: Ole Trøan <[email-masked]>
Date: Tue, 8 May 2012 16:35:32 +0200

> option for the browser folk.

perhaps I'm missing something, but this is what on the bleeding edge Chrome does too.

> There seems to be no way out of that whatever we do.

if the string has to be escaped regardless, and that UI's may handle this for the end user, what would be the reason to not go with an escaped '%' (%25)?

cheers,
Ole

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 8 May 2012 16:41:44 +0200

>   http://[fe80::a-en1]

Of the proposals that require changing RFC 3986, this is clearly the best one.

(My personal favorite is still hijacking IPvFuture, as in http://[v6.fe80::a-en1], but I can understand when people don't like that.)

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 May 2012 15:42:35 +0100

> perhaps I'm missing something, but this is what on the bleeding edge Chrome does too.

I suppose it depends on the religious convictions of the people who
write the URI parsers. The only clean solution is to get what we want
into the formal syntax, and there I feel no hope whatever.

> if the string has to be escaped regardless, and that UI's may handle this for the end user, what would be the reason to not go with an escaped '%' (%25)?

Well, I'm not sure the UIs can be relied on for that. As above, it
depends whether the parsers are strict or sloppy about following
the ABNF.

   Brian

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 May 2012 19:34:53 +0200

> characters in the interface ID will always have to be %-encoded.

I am concerned that the long-term result of this might be that we will
have to live with both % and - used as separators in various tools and
interfaces and that this might at the end even cause changes to other
tools and specifications that currently are just fine with using % as
a separator. Perhaps I am overly anxious but only future will tell.

/js

---

From: t.petch <[email-masked]>
Date: Thu, 10 May 2012 12:39:45 +0200

---- Original Message ----- 
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>
Cc: "6man" <[email-masked]>
Sent: Tuesday, May 08, 2012 7:34 PM
> a separator. Perhaps I am overly anxious but only future will tell.

Yes, over the long term I could well see the use of % fading away,
but I would regard that as a good thing:-)

Tom Petch

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 May 2012 07:56:43 +0100

> but I would regard that as a good thing:-)

Would you want this to be stated as a formal update to RFC 4007?

   Brian

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 11 May 2012 09:43:22 +0200

> Would you want this to be stated as a formal update to RFC 4007?

There are other specifications that use "%" because they follow RFC
4007 such as RFC 6021 or RFC 4001 (I am sure there is more but I pick
these because I know them well ;-). If we do something to the
separator, I think not only an update to RFC 4007 needs to be
declared, I think there also needs to be a plan what we do with
documents such as RFC 6021 or RFC 4001. Is the idea to deprecate all
those definitions, create new ones, have ripple effects on documents
using those definitions? RFC 4001, for example, is referenced by 61
other RFCs - pretty much any recent MIB module representing an IP
address.

The idea that "%" fades away anytime soon is most likely an illusion.
If we add "-" as a speparator, all we do is create a situation where
there are two separators deployed and a situation lasting for many
many years where some parts only understand "%", some only understand
"-" and some do both.  The question is whether we are all willing to
pay this price for enabling zone indexes in URLs and complying to URN
syntax purity rules.

My understanding is that browsers were able to do what people wanted
with "%" as a separator - its just that we can standardize this due to
URL purity rules. Perhaps the real solution here is jump over the URL
fence and find a way to standardize what browsers were able to do and
what allowed people to cut and paste. Changing all occurances of "%"
as a separator in our standards just to comply to URL purity rules may
get the cost / benefit thing wrong.

/js

---

From: t.petch <[email-masked]>
Date: Fri, 11 May 2012 09:08:31 +0200

---- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>; "Benoit Claise"
<[email-masked]>
Cc: "t.petch" <[email-masked]>; "6man" <[email-masked]>
Sent: Friday, May 11, 2012 9:43 AM
> get the cost / benefit thing wrong.

For me, it comes in the category of let the market place decide.  I would not
update RFC4007 at this point in time, but if, a few years down the track,
the percent sign has been largely superseded, then yes, I would at that time,
but not before.

Equally, inserting what I take to be a missing 'not' into the paragraph of
Juergen's, it may be that the market place decides that it does not care about
URL purity rules and gives people what they want, what is obviously right to all
but URL purists.  In which case, we update RC3986 in a few years time:-)

So I would go ahead with the I-D in question making Option 3 Normative,
explaining the rejected options in a non-Normative appendix; I see this as the
technically correct, not so user friendly approach, which, having gotten
ourselves to where we are, is the best we can do.  Then the marketplace will
make its choice.  We will, at least, have deprecated what could be worse
options, which might arise if we do nothing.

Tom Petch