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

[Carsten Bormann <[e-mail]>]

On Mar 7, 2012, at 15:22, Bill Fenner wrote:

>> RFC 3986 is not sacred.
> 
> Of course it's not sacred.  

Not sacred, but is is also not open for gratuitous changes.

I don't see a technical reason to do anything else than what you proposed (i.e., not to stay within the confines of the standard).

> On the concern of hosts using a
> scope ID that does not fit in the IPvFuture grammar, RFC4007 says that
> you SHOULD support a fully-numeric scope ID, so hopefully users will
> be able to use the fully-numeric form.  (Again, this goes to the rare
> use case to me.)

We could spec that fe80::1%foo\/bar
is translated into
fe80::1_foo_5c_2fbar
if that is a real concern (i.e., do our own hex coding of unsupported characters [and "_" then of course]).
(I hope it isn't.)

<rant>
People who think they can build a URI with printf() are in for a surprise in any case...
</rant>

> (Just a note about the use of "v6": the intent was to actually use
> "v1"; the change log at the end of -02 claims that it changed from
> "v6" to "v1" but the text didn't actually change.  The version number
> is meant to be the version of the IPvFuture, not the version of the
> address inside it.)

(I like v6 much better...  (Would be v0, anyway, otherwise :-))
There doesn't seem to be a registry for these things, which should be created in the process; IANA can allocate that number then, which would move it out of the bike shed cycle.

To make this all more concrete: The address:

	fe80::1%en1

becomes part of a URI like this:

	coap://[v6.fe80::1_en1]/...

which is really easy to explain and document.

Grüße, Carsten

PS.: unfortunately, it also is cOAp://[V6.fe80::1_en1]/...
Add a copy of 3986 3.1
   An implementation
   should accept uppercase letters as equivalent to lowercase in ___
   names (e.g., allow "HTTP" as well as "http") for the sake of
   robustness but should only produce lowercase scheme names for
   consistency.
for good measure.