Last Call Review of draft-ietf-6man-uri-zoneid-05
review-ietf-6man-uri-zoneid-05-genart-lc-thomson-2012-11-16-00
Request | Review of | draft-ietf-6man-uri-zoneid |
---|---|---|
Requested revision | No specific revision (document currently at 06) | |
Type | Last Call Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2012-11-26 | |
Requested | 2012-11-15 | |
Authors | Brian E. Carpenter , Stuart Cheshire , Bob Hinden | |
I-D last updated | 2012-11-16 | |
Completed reviews |
Genart Last Call review of -05
by Martin Thomson
(diff)
Genart Telechat review of -?? by Martin Thomson Secdir Last Call review of -05 by Radia Perlman (diff) |
|
Assignment | Reviewer | Martin Thomson |
State | Completed | |
Request | Last Call review on draft-ietf-6man-uri-zoneid by General Area Review Team (Gen-ART) Assigned | |
Reviewed revision | 05 (document currently at 06) | |
Result | Ready | |
Completed | 2012-11-16 |
review-ietf-6man-uri-zoneid-05-genart-lc-thomson-2012-11-16-00
Try again, this time with the right recipients. On 16 November 2012 12:22, Martin Thomson <martin.thomson at gmail.com> 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.