Re: I-D Action: draft-carpenter-6man-rfc6874bis-00.txt

[Nico Schottelius <[e-mail]>]

While copy & paste won't work with this proposal, I believe the %25
escape should be "good enough" for most daily usage.

I think we don't need to aim for a "perfect solution", which we will not
be able to achieve anyway, but a solution for reality.

In this regard, as a network operator, I can support this direction to
better have a, rather than no solution.

In a perfect world, the [...%] syntax would have been introduced (and
accepted) prior to % escape in URLs.

Another direction, which is probably also very unlikely to achieve,
would be to change the delimiter on OS basis and harmonise it with the
browser.

Best regards,

Nico

Brian E Carpenter <[e-mail]> writes:

> Ted,
>
> On 05-Jul-21 22:08, Ted Hardie wrote:
>> Hi Nico,
>>
>> Essentially, the % symbol in a URI is an indicator that what follows is
> percent encoded; see RFC 3986, section 2.1.  Section 2.4 also says:
>>
>>    Because the percent ("%") character serves as the indicator for
>>    percent-encoded octets, it must be percent-encoded as "%25" for that
>>    octet to be used as data within a URI.
>>
>>  This proposal treats the % which starts a scope identifier as "data within a URI" and so it percent-encodes the percent symbol.  Other approaches, such as a bare percent symbol within the square brackets have been rejected (see the long Mozilla bug thread Brian posted).
>>
>> I think that taking this approach is worth trying, but I believe that consistency is needed.  Making this the valid form but accepting the bare % in some circumstances seems likely to me result in lack of interoperability.  If I can paste when going into browser 1 but not browser
> 2, the result is confusing for the user.
>
> Yes, that is a fairly persuasive argument.
>
> Just to play devil's advocate for a moment, once consequence of the % escape is that
> the user could execute
>    ping6  fe80::80b2:5c79:2266:e431%eth0
> but in a browser window would have to type
>    https://[fe80::80b2:5c79:2266:e431%25eth0]
> so a simple cut-and-paste won't do it.
>
> Appendix A of the draft, which is unchanged from RFC6874, summarizes the options considered the previous time round.
>
> Regards
>    Brian
>
>>
>> Just my two cents, of course,
>>
>> Ted
>>
>> On Mon, Jul 5, 2021 at 10:33 AM Nico Schottelius <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>
>>     I am bit puzzled about the interface ID discussion. While I understand
>>     that % inside square brackets is treated differently than outside, the
>>     overall complexity still seems to be low, isn't it?
>>
>>             On encountering "[ + valid IPv6 address" browsers should (must?)
>>             accept an interface identifier of the form of "%string]".
>>
>>     This covers automatically the integer case as well as the named network
>>     interfaces. Or am I missing something?
>>
>>
>>
>>     Brian Carpenter <[e-mail] <mailto:[e-mail]>> writes:
>>
>>     > Ted, I agree about the complexity. otoh I believe that at least one browser
>>     > used to do this. How about saying that such a mechanism is not forbidden?
>>     >
>>     > Regards,
>>     >     Brian Carpenter
>>     >     (via tiny screen & keyboard)
>>     >
>>     > On Mon, 5 Jul 2021, 20:06 Ted Hardie, <[e-mail] <mailto:[e-mail]>> wrote:
>>     >
>>     >> Hi Brian, Bob,
>>     >>
>>     >> Your draft says:
>>     >>
>>     >>    In the spirit of "be liberal with what you
>>     >>    accept", we also suggest that URI parsers accept bare "%" signs when
>>     >>    possible (i.e., a "%" not followed by two valid and
> meaningful
>>     >>    hexadecimal characters).  This would make it possible 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.  On the other
> hand, "%ee1" would
>>     >>    need to be manually rewritten to "fe80::a%25ee1" to
> avoid any risk of
>>     >>    misinterpretation.
>>     >>
>>     >> I would prefer the document without this suggestion, as I think the
>>     >> resulting logic for a uri parser is a good bit harder than the "
> %s are
>>     >> handled differently within IPv6 literals" approach.  This requires the
>>     >> parser to treat %s  differently within IPv6 literals except
> when the result
>>     >> would be a "valid and meaningful" pair of hexadecimal characters.  If I
>>     >> follow your logic correctly, that would mean not simply checking
> to be sure
>>     >> that these are hex but also checking to be sure that the resulting
>>     >> characters are within the syntax for the ZoneID production.
>>     >>
>>     >> I think the proposal is much cleaner without this, and I encourage you to
>>     >> reconsider including it.
>>     >>
>>     >> regards,
>>     >>
>>     >> Ted Hardie
>>     >>
>>     >>
>>     >> On Mon, Jul 5, 2021 at 3:41 AM Brian E Carpenter <
>>     >> [e-mail] <mailto:[e-mail]>> wrote:
>>     >>
>>     >>> Hi,
>>     >>>
>>     >>> In case people aren't aware, no web browser that we know of supports
>>     >>> RFC6874, i.e. the extension to URI/URL syntax for a link-local
>>     >>> zone index in literal IPv6 addresses. This is annoying in several
>>     >>> use cases.
>>     >>>
>>     >>> This new draft tackles what seems to be the main objection from
>>     >>> the browser community, namely that RFC6874 requires browsers to
>>     >>> remove the zone index before sending the URL out in a standard
>>     >>> HTTP message. That's a coding annoyance and it also breaks HTTP/1.1
>>     >>> rules for the "Host" header according to RFC7230.
>>     >>>
>>     >>> There's background to this issue at:
>>     >>> https://bugzilla.mozilla.org/show_bug.cgi?id=700999 <https://bugzilla.mozilla.org/show_bug.cgi?id=700999> (still live but
>>     >>> officially closed WONTFIX) and
>>     >>> https://github.com/whatwg/url/issues/392 <https://github.com/whatwg/url/issues/392>
>>     >>>
>>     >>> The new draft proposes to update the RFC accordingly. The changes
>>     >>> are relatively small but significant. There's a diff between the
>>     >>> RFC and this draft at:
>>     >>>
>>     >>> https://www.cs.auckland.ac.nz/~brian/Diff-rfc6874-draft-carpenter-6man-rfc6874bis-00.html <https://www.cs.auckland.ac.nz/~brian/Diff-rfc6874-draft-carpenter-6man-rfc6874bis-00.html>
>>     >>>
>>     >>> Comments welcome. If we want to go ahead with this fix, we will
> need to
>>     >>> reach out to the URI specialists and the browser community, to be sure
>>     >>> it isn't a waste of time.
>>     >>>
>>     >>> Regards
>>     >>>      Brian & Bob
>>     >>>
>>     >>>
>>     >>> -------- Forwarded Message --------
>>     >>> Subject: I-D Action: draft-carpenter-6man-rfc6874bis-00.txt
>>     >>> Date: Sun, 04 Jul 2021 19:10:13 -0700
>>     >>> From: [e-mail] <mailto:[e-mail]>
>>     >>> Reply-To: [e-mail] <mailto:[e-mail]>
>>     >>> To: [e-mail] <mailto:[e-mail]>
>>     >>>
>>     >>>
>>     >>> A New Internet-Draft is available from the on-line Internet-Drafts
>>     >>> directories.
>>     >>>
>>     >>>
>>     >>>         Title
>    : Representing IPv6 Zone Identifiers in Address
>>     >>> Literals and Uniform Resource Identifiers
>>     >>>         Authors         : Brian Carpenter
>>     >>>                           Robert M. Hinden
>>     >>>         Filename        : draft-carpenter-6man-rfc6874bis-00.txt
>>     >>>         Pages
>    : 10
>>     >>>         Date
>     : 2021-07-04
>>     >>>
>>     >>> Abstract:
>>     >>>    This document describes how the zone identifier of
> an IPv6 scoped
>>     >>>    address, defined as <zone_id> in the IPv6 Scoped Address Architecture
>>     >>>    (RFC 4007), can be represented in a literal IPv6 address and in a
>>     >>>    Uniform Resource Identifier that includes such a literal address.  It
>>     >>>    updates the URI Generic Syntax specification (RFC 3986) accordingly,
>>     >>>    and obsoletes RFC 6874.
>>     >>>
>>     >>>
>>     >>> The IETF datatracker status page for this draft is:
>>     >>> https://datatracker.ietf.org/doc/draft-carpenter-6man-rfc6874bis/ <https://datatracker.ietf.org/doc/draft-carpenter-6man-rfc6874bis/>
>>     >>>
>>     >>> There is also an HTML version available at:
>>     >>> https://www.ietf.org/archive/id/draft-carpenter-6man-rfc6874bis-00.html <https://www.ietf.org/archive/id/draft-carpenter-6man-rfc6874bis-00.html>
>>     >>>
>>     >>>
>>     >>> Internet-Drafts are also available by anonymous FTP at:
>>     >>> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>>     >>>
>>     >>>
>>     >>> _______________________________________________
>>     >>> I-D-Announce mailing list
>>     >>> [e-mail] <mailto:[e-mail]>
>>     >>> https://www.ietf.org/mailman/listinfo/i-d-announce <https://www.ietf.org/mailman/listinfo/i-d-announce>
>>     >>> Internet-Draft directories: http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>
>>     >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>>     >>>
>>     >>> --------------------------------------------------------------------
>>     >>> IETF IPv6 working group mailing list
>>     >>> [e-mail] <mailto:[e-mail]>
>>     >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>>     >>> --------------------------------------------------------------------
>>     >>>
>>     >>
>>     > --------------------------------------------------------------------
>>     > IETF IPv6 working group mailing list
>>     > [e-mail] <mailto:[e-mail]>
>>     > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>>     > --------------------------------------------------------------------
>>
>>
>>     --
>>     Sustainable and modern Infrastructures by ungleich.ch <http://ungleich.ch>
>>


--
Sustainable and modern Infrastructures by ungleich.ch