This draft has been updated following IETF Last Call and IESG comments. The various A-Ds are happy with the changes, but some of changes are non-trivial so should be reviewed by the WG.
The draft is at https://datatracker.ietf.org/doc/draft-ietf-6man-uri-zoneid/ and the diffs are at http://tools.ietf.org/rfcdiff?url2=draft-ietf-6man-uri-zoneid-06.txt This rest of this note discusses the changes between -05 and -06 that are not simple editorial corrections or clarifications. They are arranged according to the reviewer who brought each issue up. Martin Thomson (Gen-ART review): >> we also recommend that URI parsers accept bare "%" signs >> (i.e., a "%" not followed by two valid hexadecimal characters). This >> makes it easy for a user to copy and paste a string such as >> "fe80::a%en1" from the output of a "ping" command and have it work. >> >> Even though 01 is " two valid hexadecimal characters", U+01 is not a >> valid URI character at that position. Thus, the range of inferred >> zone IDs is (potentially) larger than the text implies. s/valid/valid and meaningful/ Martin also suggested >> Software that accepts URIs with unescaped portions can permit the >> entry of IPv6 addresses with an unescaped zone separator. but that doesn't seem to be clear for tricky cases like %ee. Radia Perlman (Security directorate review): >> And also, with my preference for specifying mandatory behavior rather than >> recommendation... >> perhaps saying something like >> >> " A <zone_id> MUST NOT contain ASCII characters classified >> in RFC 3986 <http://tools.ietf.org/html/rfc3986> as "reserved". MUST NOT doesn't work because of pre-existing implementations that allow reserved characters. Reworded for clarity, and added However, the syntax below does allow such characters to be percent-encoded, for compatibility with existing devices that use them. >> Again, >> "The rules in [RFC5952 <http://tools.ietf.org/html/rfc5952>] SHOULD be >> applied in producing URIs." >> Why not MUST be applied? RFC 5952 itself is one long SHOULD, so we don't think that saying MUST makes sense. >> similarly >> >> "To limit this risk, implementations SHOULD NOT allow use of this >> format except for well-defined usages such as sending to link local >> addresses under prefix fe80::/10." >> >> I'd think it would be better to say MUST NOT, and also, to specify what it >> should >> do if it receives such a thing. Agree on this MUST NOT. The problem with specifying receiver behaviour, according to Yves Lafon, is that filtering incoming URIs "would be a significant change to implementations". His advice is to strip the ZoneID from outgoing HTTP requests. This is now a MUST. Radia again: > I think it would be good to have an explicit discussion in the WG, not on > the entire draft, but on specifically, whether the syntax should be > standardized so that the same syntax works the same on all implementations, > or whether there is some reason why it's important for implementers to have > flexibility in how they interpret the string, and it's not so important > that URIs work differently with different implementations. I'd be more > convinced that people want it this way if there was discussion on the > mailing list, focusing people exactly on this issue. (and I'm also curious > about why the flexibility is important). It isn't that flexibility is important; it's that this flexibility exists de facto in the real world of browsers. The problem is that browser behaviour in interpreting the user input string is not standardised by anybody. To hammer on that particular screw, the tool we have available is the URI syntax. This is not ideal. We've changed the text of section 3 to try and make this clear. Stephen Farrell (IESG): > - 2nd para of section 3 says that browsers "should" accept a > bare % as input. I don't know if you mean that "should" as a > 2119 SHOULD or not. > > - Same place: Do you need to say that the browser MUST properly > escape that if it sends the URI anywhere, that is, that the URI > emitted MUST conform to this spec and include e.g., "%25eth0" > and not just "%eth0"? That section has been reworded to avoid any normative language, because we cannot realistically give instructions to browser writers. Also (see above) we now clarify that such URIs should never be *sent* anywhere. > - Idle curiosity: anyone know if its possible to use a % > character in an interface name on any common OS? We've made it clear that if this case happens, it has to be escaped as %25. Yves Lafon (Apps Area review): > Does it mean that such URIs can be present in an HTML document or that > they MAY allow bare "%" signs when the URI is pasted in the address bar? > (Those are two different use cases, and browsers may have different code > paths for both). Both cases now mentioned. > An HTTP server or proxy MUST ignore any ZoneID attached to an > incoming URI, as it only has local significance at the sending host. > > A proxy can be considered as a sending host, so does it mean that a the > receiving end MUST strip all ZoneID before processing the request? (and it > would be a significant change to implementations), or could this be resolved > by mandating Web browser to strip ZoneID prior to sending the request as it > is only significant for the sending host and as it is the implementation that > needs to be updated to recognize the new syntax? Good point, we switched the responsibility to the sender. Barry Leiba (IESG): > -- Section 3, second paragraph -- > As discussed in the AppsDir review thread, maybe it would help to add > something like this at the end of the paragraph?: > > Such bare "%" signs are for user interface convenience, and must be > turned into properly escaped characters ("%25" encodes "%" in URIs) > before the URI is used in any protocol. Yes > I think it would be useful to also say something about what happens if, > say, instead of "en1", there's a ZoneID called "ee1". A URI parser > encountering "fe80::a%ee1" would have to decide whether to interpret the > "%" as "%25", or whether to interpret "%ee" as a percent-escaped 0xEE > character. Advice would be useful; lacking useful advice, a warning that > this could happen would at least help a little. Called out the %ee1 example for clarity. Brian + co-authors -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
