Re: WG Last Call for for draft-ietf-6man-rfc6874bis

[Ted Lemon <[e-mail]>]

>
> The URI syntax specification [RFC3986
> <https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-01.html#RFC3986>
> ] states that URIs have a global scope, but that in some cases their
> interpretation depends on the end-user's context. URIs including a zone
> identifier are to be interpreted only in the context of the host at which
> they originate, since the zone identifier is of local significance only.


Does this mean that when a browser loads a web page, and that web page
contains IPv6 address literal URIs with zone identifiers, and the source of
the web page was not the local host, the URIs are un-interpretable? That
is, what does "at which they originate" mean?

It is desirable for all URI parsers to recognise a zone identifier
> according to the syntax defined in Section 3
> <https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-01.html#spec>.
> Any code handling percent-encoding or percent-decoding must be aware that
> the "%" character preceding the zone identifier is never itself
> percent-encoded, as specified by ABNF above. In terms of Section 2.4 of [
> RFC3986
> <https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-01.html#RFC3986>
> ], this "%" character is acting as a delimiter, not as data.


Would it be correct to say that the text within an IPv6 address literal
never contains percent-encodings? If so, then it might be less complicated
to just say that. I think a parser that follows this rule would be more
regular than one that doesn't make this restriction and does allow percent
encoding within the literal except in the case of the stated exception.

The various use cases for the zone identifier syntax will cause it to be
> entered in a browser's input dialogue box.


Do you mean "the zone identifier syntax is only expected to be entered in
the browser's dialog box: there is no use case for such a URI appearing
elsewhere?" Or at least "The various use cases for the zone identifier
syntax all involve entering it in the browser's input dialogue box?" I feel
very uncomfortable with "cause" in this sentence.

In the security considerations section, I think if the syntax were only
allowed in the case of input into the browser's dialog box, then most of
the possible attacks would go away. If there is no anticipated use case
other than manual input (perhaps a scripted input would also count) then
unless the script would be allowed to open the URI but not otherwise probe
IPv6 address literals, it's hard to see what additional vulnerability this
would create.

Anyway, overall I think the document is good and the above are all nits,
not reasons not to publish. So I support publishing the document. Thanks
for doing the work!