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

[t.petch <[e-mail]>]

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" <[e-mail]>
To: "6man" <[e-mail]>
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