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

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.

Just my two cents, of course,

Ted

On Mon, Jul 5, 2021 at 10:33 AM Nico Schottelius <
nico.schottelius@ungleich.ch> 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 <brian.e.carpenter@gmail.com> 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, <ted.ietf@gmail.com> 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 <
> >> brian.e.carpenter@gmail.com> 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 (still live but
> >>> officially closed WONTFIX) and
> >>> 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
> >>>
> >>> 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: internet-drafts@ietf.org
> >>> Reply-To: internet-drafts@ietf.org
> >>> To: i-d-announce@ietf.org
> >>>
> >>>
> >>> 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/
> >>>
> >>> There is also an HTML version available at:
> >>>
> 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/
> >>>
> >>>
> >>> _______________________________________________
> >>> I-D-Announce mailing list
> >>> I-D-Announce@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/i-d-announce
> >>> Internet-Draft directories: http://www.ietf.org/shadow.html
> >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>>
> >>> --------------------------------------------------------------------
> >>> IETF IPv6 working group mailing list
> >>> ipv6@ietf.org
> >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> >>>
> >>
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
>
> --
> Sustainable and modern Infrastructures by ungleich.ch
>