> -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > Brian E Carpenter > Sent: Saturday, August 11, 2012 3:40 AM > To: Dave Thaler > Cc: Bob Hinden; ipv6@ietf.org > Subject: Re: draft-ietf-6man-uri-zoneid-02 > > Dave, > > On 11/08/2012 03:59, Dave Thaler wrote: > > Brian Carpenter writes: > >> On 09/08/2012 22:31, Stuart Cheshire wrote: > >>> At the meeting in Vancouver, Dave Thaler made a point that I found > >>> convincing: > >>> > >>> Where is the character set for IPv6 zone IDs specified? > >> RFC 4007 doesn't do so, but can be read to imply ASCII. > > > > How? RFC 4007 says: > >> An implementation MAY support other kinds of non-null strings as > >> <zone_id>. However, the strings must not conflict with the delimiter > >> character. The precise format and semantics of additional strings is > >> implementation dependent. > > Yes, it says that, but the context to me implies ASCII. We could argue about > that for a long time, so let's not bother... > > > So it's completely implementation dependent, the only restriction > > being that % and null are disallowed. > > > >> draft-ietf-6man-uri-zoneid-02 is explicit that it refers to the URI > >> character set, which is ASCII: > >> > >> A <zone_id> SHOULD contain only ASCII characters classified > >> in RFC 3986 as "unreserved". > > The draft isn't clear enough (yet) but my idea was that this was part of the > update to RFC 4007.
During the Vancouver meeting, the chairs called the question of whether to Update 4007 or not. The clear sense of the room was not to do so. Assuming that consensus continues to hold on the list, I believe this means the sentence you quote needs to be removed, and we cannot place any restrictions on zone_id that aren't in 4007. -Dave > >> But it allows percent encoding in a URI, which is necessary because > >> of the SHOULD: > >> > >> ZoneID = 1*( unreserved / pct-encoded ) > > > > ZoneID needs to allow (including via percent-encoding) the same > > characters as are allowed in <zone_id> in RFC 4007. For example the ']' > > character would be legal in RFC 4007 but would have to be percent > > encoded in a URI. > > Yes > > > > >>> If we accept > >>> that future interface names might include non-roman characters, then > >>> we have to assume that to allow safe unambiguous use in URIs, > >>> interface names have to undergo escaping. > >> If we want to internationalise the ZoneID, that would be a whole > >> other discussion. > > > > It's already allowed by RFC 4007 as far as I know. > > Well, again, it's a matter of interpretation; the question is simply not > addressed, which is a defect in the document IMHO. > > > > > Stuart's email is an accurate summary of my position. > > Yes, but that doesn't help with the %251 problem, which is where we got > stuck some months ago and came to the initial decision to add a new > delimiter. If people don't want to solve that problem, i.e. accept that %251 > in > a URI is %1 in ping, and that %251 in ping is %25251 in a URI, then we're > done. > > I'm here as a document editor, looking for guidance. > > Brian > > Brian > > > > > -Dave > > > >>> And if the interface name itself is going to be escaped using URI "%xx" > >>> notation, then why not escape the '%' the same way? > >> My impression is that this WG has already objected to that, which is > >> why we ended up with the current proposal. I leave the next step to the > WG Chair. > >> > >> Brian > >> > >>> This argues in support of what Microsoft already did: Encode '%' as > "%25". > >>> > >>> It's not my favourite outcome, but based on Dave Thaler's comment, > >>> it's the one that gets my vote. > >>> > >>> In the spirit of "be liberal with what you accept" the doc should > >>> also advocate that URI parsers are forgiving about accepting bare > >>> '%' signs > >>> -- i.e. a '%' not followed by two valid hex characters is left > >>> untouched. This lets a human user copy-and-paste "fe80::a%en1" from > >>> a "ping" command and have it work, though the strictly correct form > >>> (which URI generators should output) remains "fe80::a%25en1". > >>> > >>> Stuart Cheshire > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
