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.