Re: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt

[Brian E Carpenter <[e-mail]>]

On 2012-03-08 06:07, Juergen Schoenwaelder wrote:
> On Tue, Mar 06, 2012 at 11:26:06PM +0100, Carsten Bormann wrote:
>> On Mar 6, 2012, at 23:08, Brian E Carpenter wrote:
>>
>>> Was there a real reason that you went for this?
>>>  IPv6zone-id = 1*( unreserved / sub-delims / ":" )
>> I'm not Bill, but RFC 3986 says:
>>
>>       IPvFuture  = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
>>
>> So you can't go outside that space without updating RFC3986.
>>
> 
> At least Juniper boxes use interface names such as fe-0/0/1 (that is
> they include forward slashes) and my understanding is that those names
> won't fit into IPvFuture:
> 
>   IPvFuture  = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
> 
>   unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"
> 
>   sub-delims  = "!" / "$" / "&" / "'" / "(" / ")"
>                     / "*" / "+" / "," / ";" / "="
> 
> RFC 4007 does not really restrict the characters allowed in zone
> identifiers and hence it seems to me that we can't simply assume zone
> identifiers are always consistent with IPvFuture. (But I might as
> well be missing something.)

What this discussion seems to be missing is that normal, sane
operational people do not want one format for literal addresses
without a zone index and another format for literal addresses
with a zone index.

I fully agree to replacing the ugly %25 with _. But I can't
see a single argument from the user point of view for the
IPvFuture construct. This change is for users (specialists,
but they are still users), not for URI theorists.

I'm not sure we can accommodate names such as the Juniper ones
without including pct-encoded.

   Brian