Hi Ted, On 2012-03-08 09:06, Ted Hardie wrote: > Howdy, > > Jumping a bit late on this, my apologies. I've tried to keep the > attributions below, but if I got them wrong, please correct them. > My own text is prefaced with <th> > > Brian Carpenter wrote: >> Bill Fenner wrote: >> >> Previous joint work between the ipv6 working group and the W3C URI > > <th>Just as a side note, the URI mailing list is hosted by the W3C, but the > working group was an IETF working group and that list is still used by the > IETF > and W3C jointly for discussions in this area. > >> working group resulted in a decision that did not change the ABNF at >> all, in 2 ways: >> >> 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? > <th> > This actually doesn't turn out to be a small change. The draft gives > this production > > IPv6addrz = IPv6address [ "%" ZoneID ] > > but the use of a "%" that is not used in escaping is contrary to the basic URI > syntax--this is made clear in Section 2.4 of RFC 3986; changing that would > require a major re-write to URI parsers.
I am probably stupid, but that wasn't clear to me when reading 3986. Of course it's clear that an actual URI on the wire needs to contain %25. Anyway, I am completely convinced that the downside of using %25 is much greater than the upside, so I believe we should revert to "_" as in Bill's draft. > > >> 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. > >> 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? > > It's been sent for URI review but no reply so far. > > <th> > I'm on the relevant list ([email protected]) and I have not seen this > document > there. Can you resend the request for review? It has presumably never been released by the list moderator. But in any case, I suggest delaying the review until we have a new version after the recent discussion. > >> 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 > > 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. > > <th> If there is a fundamental change in the limitations which are set out in > Bill's draft's section 3, it would be useful to set them out. As it stands, > I haven't seen any changes that would cause a change, but this would be > useful to describe them if they have happened. No, I think that is still exactly true, and the Security Considerations in the recent draft intend to say much the same thing. It's clear that the next draft needs to include all salient points from the 2005 draft, not to mention the authors of that draft if they want, but we need to conclude on the IPvFuture issue first. I don't think we'll have a new draft before the cutoff. Thanks Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
