I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-6man-uri-zoneid-05 Reviewer: Martin Thomson Review Date: 2012-11-16 IETF LC End Date: 2012-11-26 IESG Telechat date: not scheduled Summary: This document is ready for publication as Proposed Standard, with nits. Nits/editorial comments: The document could be made shorter by removing: We now present the necessary formal syntax. The 6man WG discussed and rejected an alternative in which the existing syntax of IPv6address would be extended by an option to add the ZoneID only for the case of link-local addresses. It was felt that the present solution offers more flexibility for future uses and is more straightforward to implement. This latter text might be put in the appendix, if it is necessary at all. The text in the security considerations is probably adequate. The following statement implies "special" processing for zone IDs at user input: This document implies that all browsers should recognise a ZoneID preceded by an escaped "%". In the spirit of "be liberal with what you accept", 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. Browsers frequently accept (and display) URIs with unescaped parts. This is just another example of that common logic. Thus, this might be phrased more simply as: Software that accepts URIs with unescaped portions can permit the entry of IPv6 addresses with an unescaped zone separator. This allows implementations to infer behaviour, which is probably OK in this context. s/proxy/intermediary/ In the appendix, it might be worth noting that option 3 was selected. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
