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

From: Brian Haberman <[email-masked]>
Date: Mon, 05 Mar 2012 16:05:21 -0500

All,
      This message starts a two-week 6MAN Working Group Last Call on 
advancing:

      Title     : Representing IPv6 Zone Identifiers in Uniform
                  Resource Identifiers
      Author(s) : Brian Carpenter
                  Robert M. Hinden
      Filename  : draft-ietf-6man-uri-zoneid-00.txt
      Pages     : 7
      Date      : 2012-02-17

as a Proposed Standard.  Substantive comments should be directed to the 
mailing list or the co-chairs.  Editorial suggestions can be sent to the 
authors.  This last call will end on March 19, 2012.

Regards,
Brian, Bob, & Ole

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 5 Mar 2012 23:15:41 +0100

This leaves me thoroughly confused.

While the text seems to indicate the contrary, the ABNF makes it clear that

coap://[fe80::a%25en1]/.well-known/core

is intended to indicate the zone ID of "25en1".

This is the only place in a URI where a percent is proposed to be used in stand-alone fashion -- everywhere else it occurs as part of pct-encoded.  For a good reason.

E.g., this works perfectly to talk to localhost in Safari and Chrome:
http://[%3a%3a1]/

Any other character but % (or []A-Fa-f0-9:] of course) would be less confusing for indicating zone-ids.  I'd recommend choosing one from sub-delims, such as * or &.

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 Mar 2012 12:00:37 +1300

No, I think it's exactly *not* confused on this point. There's
a distinction between the idealised URI and the produced URI;
in the produced URI, "%25" stands for "%" in the idealised URI.

We have no real choice but to use % since that was chosen years
ago, and that means that the produced URI contains %25.

   Brian

On 2012-03-06 11:15, Carsten Bormann wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 6 Mar 2012 00:22:54 +0100

> in the produced URI, "%25" stands for "%" in the idealised URI.

Ah, so the ABNF is wrong and the (vague) text is meant as I read it first (it can be read in other ways).

Replace

      IPv6addrz = IPv6address [ "%" ZoneID ]

by

      IPv6addrz = IPv6address [ "%25" ZoneID ]

> ago, and that means that the produced URI contains %25.

I don't know that.  You could use "percent" and that would work, too.

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 Mar 2012 13:15:43 +1300

Carsten,

On 2012-03-06 12:22, Carsten Bormann wrote:
> Ah, so the ABNF is wrong 

I don't believe so. The ABNF does not describe the produced (encoded)
URI. I have read sections 2.2 and 2.4 of RFC 3986 several times
before asserting this. Of course I could be wrong, but we are waiting
for a review from [email-masked] who will hopefully give a
definitive answer.

> and the (vague) text is meant as I read it first (it can be read in other ways).

Please indicate exactly which part of the text is ambiguous, and we'll
change it.

>       IPv6addrz = IPv6address [ "%25" ZoneID ]

No. In the encoded URI that would end up as %2525. That's exactly the
trap that RFC 3986 warns against.

> I don't know that.  You could use "percent" and that would work, too.

We could use any unreserved symbol, but that would need translation from
the RFC 4007 format. For example we could just use Z, as in
http://[fe80::aZen1].
Or we could use ~: http://[fe80::a~en1].

Would that be less confusing?

    Brian

---

From: Bill Fenner <[email-masked]>
Date: Tue, 6 Mar 2012 07:08:51 -0500

> Would that be less confusing?

Previous joint work between the ipv6 working group and the W3C URI
working group resulted in a decision that did not change the ABNF at
all, in 2 ways:

1. It used the IPvFuture extension mechanism;
2. It used a non-percent character for the separator.

At the time, the URI working group was very concerned about the change
in the ABNF and the use of percent where percent had not previously
been allowed.  Have they changed their position here, or have they not
had a chance to comment on this change yet?

This work was accepted as an ipv6 wg work item around IETF63 (Paris,
2005), but the authors never pushed the document forward due to a lack
of interest in the broader community.  The draft that was adopted by
the wg was

http://tools.ietf.org/html/draft-fenner-literal-zone-01

  Bill

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 07 Mar 2012 11:08:22 +1300

Hi Bill,

> 1. It used the IPvFuture extension mechanism;

Hmm. I'm not sure that was a good choice. It certainly doesn't
seem natural to me. Also it seems like more work for implementors
than a small extension to the existing ABNF. What's so sacred?

> 2. It used a non-percent character for the separator.

Yes, and I have almost convinced myself that is better. The % is
certainly the worst possible choice from a clarity viewpoint.

> had a chance to comment on this change yet?

It's been sent for URI review but no reply so far.

> http://tools.ietf.org/html/draft-fenner-literal-zone-01

Recently there's been definite interest in this as an operational
convenience. I was pretty much unaware of the 2005 work, since that was
just when I joined the IESG and life was too busy, especially
during the first Paris IETF.

Was there a real reason that you went for this?
  IPv6zone-id = 1*( unreserved / sub-delims / ":" )

We have
  ZoneID = 1*( unreserved / pct-encoded )
which allows anything, having noted that some operating systems use all
sorts of characters in interface names.

Thanks

     Brian

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 6 Mar 2012 23:26:06 +0100

>  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.

I think the 2005 work hit the mark.  Resurrect, publish, done.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 6 Mar 2012 23:43:20 +0100

Given Bill's draft, we may not have to argue this, but:

On Mar 6, 2012, at 01:15, Brian E Carpenter wrote:

> The ABNF does not describe the produced (encoded)
> URI.

That is certainly *not* my understanding of RFC 3986.

(It is true that a number of real-word implementations allow pct-encoded in more places than the ABNF does.  But being liberal in what you accept is a rather usual way of non-compliance.  Challenge: Find a real-world URI not matched by the 3986 ABNF!)

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 07 Mar 2012 11:44:35 +1300

> So you can't go outside that space without updating RFC3986.

That inserts a very ugly v6. at the front, which is definitely not
what people want. The point is practical: we want to stick a zone ID
on the end of an IPv6 literal.

RFC 3986 is not sacred.

   Brian

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 6 Mar 2012 16:25:52 -0800

> (It is true that a number of real-word implementations allow pct-encoded in more places than the ABNF does.  But being liberal in what you accept is a rather usual way of non-compliance.  Challenge…
Not sure what you mean by a "real-world URI", but
http://[fe80::206:98ff:fe00:232%tap0]
*used* to work in Firefox, and probably still does in 3.6.x.  They
ripped out the capability
specifically because it wasn't supported by the ABNF in 3986.

-K-

---

From: Bill Fenner <[email-masked]>
Date: Wed, 7 Mar 2012 09:22:45 -0500

On Mar 6, 2012, at 5:44 PM, Brian E Carpenter
<[email-masked]> wrote:

> what people want.

You're not going to give people what they want.  What people want is
to use http://[v6addr%foo0]/, which I think we all agree is right out.
 Once you've strayed from that, you're not giving people what they
want.

> The point is practical: we want to stick a zone ID

Yup.  We wanted to do that in 2004 too.

> RFC 3986 is not sacred.

Of course it's not sacred.  That doesn't mean we should change it
without fully considering the ramifications.

I think there are two issues here:

1. Should we use "%", "%25" or "something else"?  These were the 3
options in http://tools.ietf.org/html/draft-fenner-literal-zone-01,
and between the ipv6 working group and the URI working group we came
to rough consensus on the "something else" side.

2. Should we use the IPvFuture ABNF or modify the IPv6address ABNF?  I
think there are much weaker feelings here - obviously it's easier to
do something that matches a Full Standard rather than modify it, and
for me personally the use case for this is so narrow (e.g.,
configuring a home gateway for the first time via HTTP) that it is not
worth spending lots of cycles on it.  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.)

(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.)

  Bill

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 7 Mar 2012 16:11:25 +0100

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

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>

> is meant to be the version of the IPvFuture, not the version of the

(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.

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 7 Mar 2012 06:47:45 -0800

> to rough consensus on the "something else" side.
What about "%%"? At least it's very close to the user's intention and
models other ESC_ESC patterns (as in the C string "An escape sequence
begins with a backslash \\").

> be able to use the fully-numeric form.  (Again, this goes to the rare
It's perhaps not as rare as you believe going forward.  We're supposed
to be adding 50B (pick your favorite number) devices to the Internet in
the next ten years (pick your favorite timeframe) and not all of them will
have, nor be configurable through, a global IPv6 address.

-K-

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 7 Mar 2012 07:29:09 -0800

> 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).
Apparently this is why we all still use QWERTY keyboards :-)

>        coap://[v6.fe80::1_en1]/...
And hopefully coap://[v6.fdfd::1]/... would work as well?

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 7 Mar 2012 17:50:17 +0100

> And hopefully coap://[v6.fdfd::1]/... would work as well?

Oh.  That may be a reason to go with v1, not v6...

I don't think the idea is to *replace* IPv6address with IPvFuture.
So I was thinking that this version of IPvFuture would be specifically done for the zone_id case.  So the v6 (or v1) serves as a kind of advance warning "there will be a zone_id later).

Grüße, Carsten

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 7 Mar 2012 09:03:44 -0800

On Wed, Mar 7, 2012 at 8:50 AM, Carsten Bormann <[email-masked]> wrote:
> So I was thinking that this version of IPvFuture would be specifically done for the zone_id case.
> So the v6 (or v1) serves as a kind of advance warning "there will be a zone_id later).
>
As an implementor, I'd prefer a solution that works for all legal IPv6
addresses going forward.  It's not outside the realm of possibility that
these URIs may be constructed by constrained devices with multiple
interfaces (maybe that begins to test the definition of "constrained")
and I'd prefer not to have to special case link-local addresses.

My $0.02, -K-

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 7 Mar 2012 18:07:08 +0100

> 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:

  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.)

/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: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Mar 2012 08:26:48 +1300

>   sub-delims  = "!" / "$" / "&" / "'" / "(" / ")"

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