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

Kerry,

On 2012-04-29 23:50, Kerry Lynn wrote:
> On Sun, Apr 29, 2012 at 3:54 AM, Brian E Carpenter <
> brian.e.carpenter@gmail.com> wrote:
> 
>> Hi,
>>
>> 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.
> 
> 
> "Purely" may be overly strong here.  When I mentioned in Paris that
> my mom might like to configure her spanking new IPv6 homenet router
> using http://[fe80::1%eth0] the way she currently uses http://192.168.1.1,
> it was met with much ROTFL'ing.  But hey, my mom is no slouch.
> 
> In a more immediate case, people are currently using browsers to connect
> to embedded 6LoWPAN web servers.  (Imagine a host with a 6LoWPAN
> link on one interface and ethernet on another.)  I use Firefox 3.2x for
> this,
> because it supports the syntax above just fine.
> 
> Are such cases included in the "diagnostic" designation?  It seems not.

Fair enough, this can easily be wordsmithed.

> 
> 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.
>>
>> Well, this may be a case of "do what we mean, not what we say".   I agree
> that "%" is the first octet of pct-encoded, but it's not clear that
> pct-encoded
> is permissible in all productions.  To wit, ( unreserved / sub-delims / ":"
> ) and
> ( unreserved / pct-encoded / sub-delims / ":" ) are apparently not
> equivalent.
> The basis of some comments in Paris was that escaped chars are currently
> not permitted within IP-literal.  But I agree, in the end this may be an un-
> winnable battle.

Exactly. I don't claim to understand every nook and cranny of the syntax,
but in practice it's unwinnable.

> 
>> 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.
>>
>> And doesn't allow browsing; see above.  So I don't like this option.

Yes, I overlooked that rather obvious disadvantage...

> 
> 
>> 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.
>>
>> Well, if we took a purely *user-centric* approach, then we'd use a
> consistent syntax for all utilities.  We have an existence proof (Firefox
> 3.2x) that demonstrates the desired syntax is possible (and parsible).
> This option is just ugly.  If we have to map symbols, I'd rather use a
> 1:1 mapping than a 1:3 mapping.

If only we hadn't picked % in the first place...

> 
> 3) With alternative separator such as _
>>   http://[fe80::a_en1]
>>
>> Advantage: allows use of browser.
>> Disadvantage: doesn't allow simple cut and paste.
>>
>> This is the simplest of the four alternatives.  It seems at this point we
> could just discuss whether "_" is the best alternative.
> 
> 
>> 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.
>>
>> Yikes!  This one just screams OVERSIGHT.  I would frankly prefer
> option 1 over having two ways to represent IPv6address.
> 
> Thanks, Brian and Bob, for taking this on.

No problem.

   Brian

> 
> -K-
> 
> 
>> Thus, the WG has to choose between options 1), 2), 3) and 4).
>>
>> Opinions welcome!
>>
>>    Brian Carpenter
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> 