Try again, this time with the right recipients. On 16 November 2012 12:22, Martin Thomson wrote: > 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.