Re: [art] [IPv6] [Last-Call] Artart last call review of draft-ietf-6man-rfc6874bis-02

[Rob Sayre <[e-mail]>]

Hi,

I think the introduction should be changed a little bit. The document hurts
its own credibility right at the start:

"The Uniform Resource Identifier (URI) syntax specification [RFC3986]
defined how a literal IPv6 address can be represented in the "host"
part of a URI.  Two months later, the IPv6 Scoped Address
Architecture specification [RFC4007]..."

This is a stretch. RFC 3986 (or STD 66) was not exactly a fast-moving
effort, for good reason. This text makes it sound like there was an
unforeseeable problem due to concurrent work, but I don't think that is
true.

I don't understand many of the rationales in Appendix A. For example, the
one about the underscore just isn't true. Try something like this:
<a href="https://ietf.org">an_underscore</a>

Additionally, copy/paste of URLs is usually incredibly complicated in all
situations (not a "simple copy/paste"). So, I'm not sure I buy a lot of the
other bullet points.

But what I think I'm reading between the lines here is that someone has
already shipped this. If that's the case, well what can you do? :)

thanks,
Rob


On Sun, Mar 26, 2023 at 8:58 AM Larry Masinter <[e-mail]> wrote:

> I asked for a brief explanation. The response explains, albeit not
> directly.
>
> I regret going down this path with RFC 2732: Format for Literal IPv6
> Addresses in URL's (rfc-editor.org)
> <https://www.rfc-editor.org/rfc/rfc2732>
> If I had do-overs (in another universe) I would have pushed harder
> The Compatibility Dilemma (ietf.org)
> <https://www.ietf.org/proceedings/47/slides/idn-url-00mar/sld003.htm>
>
> On Sun, Mar 26, 2023 at 5:10 AM Michael Sweet <[e-mail]> wrote:
>
>> Another point: there are other URI schemes that benefit from this work,
>> not the least of which are “ipp” and “ipps”, which are used by billions of
>> printers and client devices worldwide. This is really an edge case for
>> supporting access to devices when the preferred mechanism (mDNS hostnames)
>> is not available.
>>
>> So I really don’t want and don’t support pushing for new URI schemes.
>>
>> ____________________
>> Michael Sweet
>>
>> > On Mar 26, 2023, at 2:34 AM, Brian E Carpenter <
>> [e-mail]> wrote:
>> >
>> > It's simply irrelevant to the use cases, which are all
>> well-established uses of http: and https:. Nobody has any need of a new
>> scheme for these use cases.
>> >
>> > Also, the URI will still have to be parsed. I don't see how it changes
>> anything, unless you imagine that browser implementers will write new
>> parsers just for this.
>> >
>> > There's running code proof that by adding the appropriate case to an
>> existing parser, the proposal just works. At this point I am baffled by
>> this new suggestion.
>> >
>> > My question at the moment is a simple one: which of the points raised
>> in the ART review are not answered in the latest posted draft?
>> >
>> > Regards
>> >   Brian Carpenter
>> >
>> >> On 26-Mar-23 18:10, Martin J. Dürst wrote:
>> >> Hello Brian, others,
>> >>> On 2023-03-26 13:54, Brian E Carpenter wrote:
>> >>> We seem to be in different universes here.
>> >> Good to know. Actually, Martin Thomson and me discussed the possibility
>> >> of (a) dedicated scheme(s) as an alternative just this morning. It
>> might
>> >> be possible to avoid quite a bit of the issues that Martin brought up
>> in
>> >> his review.
>> >> Regards,   Martin.
>> >>> Regards
>> >>>     Brian Carpenter
>> >>>
>> >>> On 26-Mar-23 17:21, Larry Masinter wrote:
>> >>>> i don't understand the use cases that wouldn't use httpv6 and
>> httpsv6.
>> >>>> If you get a URL with a new scheme, you either know what to do with
>> it
>> >>>> or you don't, but in the latter case you know that you don't know.
>> >>>> Unlike all of the plans to extend http and https to have a new
>> syntax.
>> >>>>
>> >>>> On Sat, Mar 25, 2023 at 9:07 PM Brian E Carpenter
>> >>>> <[e-mail] <mailto:[e-mail]>>
>> wrote:
>> >>>>
>> >>>>     Larry,
>> >>>>
>> >>>>     In a word, the use cases are HTTP and HTTPS use cases.
>> >>>>
>> >>>>     Regards
>> >>>>          Brian Carpenter
>> >>>>
>> >>>>     On 26-Mar-23 16:33, Larry Masinter wrote:
>> >>>>      > I haven't been following closely, but perhaps someone might
>> >>>> take a moment to explain why defining a new scheme isn't preferable
>> to
>> >>>> changing the parsing rules for old schemes?
>> >>>>      >
>> >>>>      > On Sat, Mar 25, 2023 at 7:57 PM Martin Thomson
>> >>>> <[e-mail] <mailto:[e-mail]>
>> >>>> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>> >>>>      >
>> >>>>      >     Despite sessions being busy, my extrasessionary schedule
>> is
>> >>>> light.
>> >>>>      >
>> >>>>      >     Would 16:30 Tuesday work for people?  A side meeting room
>> >>>> is presently available at that time.
>> >>>>      >
>> >>>>      >     On Sun, Mar 26, 2023, at 11:36, Martin J. Dürst wrote:
>> >>>>      >      > I just happened to bump into Martin Thomson at the IETF
>> >>>> hackathon in
>> >>>>      >      > Yokohama. We discussed this draft, and thought we might
>> >>>> be able to
>> >>>>      >      > organize a little side meeting to discuss the issues
>> and
>> >>>> hopefully also
>> >>>>      >      > make some progress. We know that Brian is remote, but
>> we
>> >>>> will try to
>> >>>>      >      > have a setup where he can participate remotely.
>> >>>>      >      >
>> >>>>      >      > We welcome everybody from the IPv6 and URI side who is
>> >>>> interested;
>> >>>>      >      > that's the reason for cross-posting. Martin Thomson is
>> >>>> way more busy
>> >>>>      >      > than me, so I'm letting him (or anybody else) propose
>> >>>> some time slots.
>> >>>>      >      >
>> >>>>      >      > Regards,   Martin.
>> >>>>      >      >
>> >>>>      >      > On 2023-03-16 22:54, Francesca Palombini wrote:
>> >>>>      >      >> Martin: thank you very much for this review. I have
>> >>>> looked at the following responses as well, and I am not sure that
>> >>>> there was ever a conclusion to the mail thread, although I can see
>> >>>> that Brian did try to make modifications and clarifications in the
>> >>>> text as much as possible. Murray has balloted DISCUSS following your
>> >>>> review and subsequent discussion, and I support his DISCUSS in my
>> >>>> ballot (1). We will talk about it today. If you have any insight
>> about
>> >>>> Murray’s question: Do any of the communities rejecting it have a
>> >>>> preferred alternative for achieving the stated goal? It would be
>> helpful.
>> >>>>      >      >>
>> >>>>      >      >> Thanks,
>> >>>>      >      >> Francesca
>> >>>>      >      >>
>> >>>>      >      >>
>> >>>>      >      >>    1.
>> >>>> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ballot/
>> >>>> <https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ballot/
>> >
>> >>>> <https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ballot/
>> >>>> <https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ballot/
>> >>
>> >>>>      >      >>
>> >>>>      >      >> From: last-call <[e-mail]
>> >>>> <mailto:[e-mail]> <mailto:
>> [e-mail]
>> >>>> <mailto:[e-mail]>>> on behalf of Martin Thomson
>> via
>> >>>> Datatracker <[e-mail] <mailto:[e-mail]>
>> >>>> <mailto:[e-mail] <mailto:[e-mail]>>>
>> >>>>      >      >> Date: Friday, 16 September 2022 at 21:32
>> >>>>      >      >> To: [e-mail] <mailto:[e-mail]>
>> >>>> <mailto:[e-mail] <mailto:[e-mail]>> <[e-mail]
>> >>>> <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
>> >>>>      >      >> Cc: [e-mail]
>> >>>> <mailto:[e-mail]>
>> >>>> <mailto:[e-mail]
>> >>>> <mailto:[e-mail]>>
>> >>>> <[e-mail]
>> >>>> <mailto:[e-mail]>
>> >>>> <mailto:[e-mail]
>> >>>> <mailto:[e-mail]>>>, [e-mail]
>> >>>> <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>> >>>> <[e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>> >>>> <mailto:[e-mail]>>>, [e-mail]
>> >>>> <mailto:[e-mail]> <mailto:[e-mail]
>> >>>> <mailto:[e-mail]>> <[e-mail]
>> >>>> <mailto:[e-mail]> <mailto:[e-mail]
>> >>>> <mailto:[e-mail]>>>
>> >>>>      >      >> Subject: [Last-Call] Artart last call review of
>> >>>> draft-ietf-6man-rfc6874bis-02
>> >>>>      >      >> Reviewer: Martin Thomson
>> >>>>      >      >> Review result: Not Ready
>> >>>>      >      >>
>> >>>>      >      >> As a bit of a preface here, I've been aware of this
>> >>>> work for some time, but
>> >>>>      >      >> have refrained from offering opinion.  As liaison to
>> >>>> the W3C, I felt like my
>> >>>>      >      >> responsibility was to facilitate the conversation.
>> >>>> However, as Barry has asked
>> >>>>      >      >> me to do a review, I feel obligated to set that
>> attempt
>> >>>> at neutrality aside.
>> >>>>      >      >>
>> >>>>      >      >> The biggest issue here is that this document is very
>> >>>> much unwanted by its
>> >>>>      >      >> target audience, as is its antecedent, RFC 6874.  I
>> >>>> share that concern.
>> >>>>      >      >>
>> >>>>      >      >> I have clear, strong indications from folks at three
>> >>>> major browsers
>> >>>>      >      >> (conveniently, I am at W3C TPAC this week and so was
>> >>>> able to talk with a few
>> >>>>      >      >> people directly on this topic; inconveniently, I've
>> not
>> >>>> had a lot of time for
>> >>>>      >      >> this review) that this change to the URI specification
>> >>>> is not just something
>> >>>>      >      >> that they don't want to implement, but that it is not
>> >>>> good for the Web.  Public
>> >>>>      >      >> communications from them will be somewhat more polite
>> >>>> and circumspect, but it
>> >>>>      >      >> has been made clear to me that this change is not
>> wanted.
>> >>>>      >      >>
>> >>>>      >      >> The IETF does occasionally publish specifications that
>> >>>> don't end up being
>> >>>>      >      >> implemented, but we usually look for signals that a
>> >>>> protocol might be
>> >>>>      >      >> implemented before even starting work.  Here, we have
>> a
>> >>>> strong signal that a
>> >>>>      >      >> specification won't be implemented.  Mark Nottingham
>> >>>> asks the same question as
>> >>>>      >      >> well as point 1 in [1].  (I don't personally find his
>> >>>> second and third points
>> >>>>      >      >> to be especially problematic given adequate
>> >>>> consultation, but even there, there
>> >>>>      >      >> are a few concerns that I will outline below.)
>> >>>>      >      >>
>> >>>>      >      >> I do want to give due credit to the authors - Brian in
>> >>>> particular - for being
>> >>>>      >      >> very open and forthright in their consultation with
>> the
>> >>>> affected constituency.
>> >>>>      >      >> They have been proactive and responsive in a nearly
>> >>>> exemplary fashion.
>> >>>>      >      >>
>> >>>>      >      >> Overall, I think that it would be better for the IETF
>> >>>> to declare RFC 6874 as
>> >>>>      >      >> Historic(al).  There might be some residual value in
>> >>>> RFC 4007 from a diagnostic
>> >>>>      >      >> perspective, but the use of zone identifiers in URIs
>> >>>> seems fundamentally
>> >>>>      >      >> incompatible with the goals of URIs.
>> >>>>      >      >>
>> >>>>      >      >> I do recognize that the Web and HTTP is not the only
>> >>>> protocol affected by this
>> >>>>      >      >> sort of change.  The goal is to change all URI types.
>> >>>> However, I believe that
>> >>>>      >      >> HTTP is pretty important here and I have a fair sense
>> >>>> that the sort of concerns
>> >>>>      >      >> I raise with respect to HTTP apply (or should apply)
>> to
>> >>>> other schemes.
>> >>>>      >      >>
>> >>>>      >      >> ---
>> >>>>      >      >>
>> >>>>      >      >> There are a few technical concerns I have based on
>> >>>> reviewing the draft.  Some
>> >>>>      >      >> of these - on their own - are significant enough to
>> >>>> justify not publishing this
>> >>>>      >      >> document.
>> >>>>      >      >>
>> >>>>      >      >> Inclusion of purely local information in the
>> >>>> *universal* identity of a resource
>> >>>>      >      >> runs directly counter to the point of having a URI.
>> >>>> This creates some very
>> >>>>      >      >> difficult questions that the draft does not address.
>> >>>>      >      >>
>> >>>>      >      >> For instance (1), the Web security model depends on
>> >>>> having a clear definition
>> >>>>      >      >> for the origin of resources.  The definition of Origin
>> >>>> depends on the
>> >>>>      >      >> representation of the hostname and it relies heavily
>> >>>> both on uniqueness
>> >>>>      >      >> (something a zone ID potentially contributes toward)
>> >>>> and consistency across
>> >>>>      >      >> contexts (which a zone ID works directly against).
>> >>>> Now, arguably the identity
>> >>>>      >      >> of resources that are accessed by link-local URIs
>> don't
>> >>>> need and cannot
>> >>>>      >      >> guarantee either property, but this is an example of
>> >>>> the sorts of problem that
>> >>>>      >      >> needs to be dealt with when local information is added
>> >>>> to a component that is
>> >>>>      >      >> critical to web security.
>> >>>>      >      >>
>> >>>>      >      >> For instance (2), in HTTP and several other protocols,
>> >>>> servers depends on the
>> >>>>      >      >> host component - as it appears in the URI - to
>> >>>> determine authority.  If there
>> >>>>      >      >> is no rule for stripping the zone ID from URIs,
>> servers
>> >>>> hostname checks will
>> >>>>      >      >> depend on the client.  That exposes link-local servers
>> >>>> to information that they
>> >>>>      >      >> need to filter out.  Some might not be prepared to do
>> >>>> that.  Hostname checks
>> >>>>      >      >> are critical for security, especially the consistent
>> >>>> treatment of the field
>> >>>>      >      >> across different components like serving
>> >>>> infrastructure, web application
>> >>>>      >      >> firewalls, access control modules, and other
>> components.
>> >>>>      >      >>
>> >>>>      >      >> This is a non-backwards-compatible change to RFC 3986.
>> >>>> The only issue related
>> >>>>      >      >> to this that is addressed in the draft is the question
>> >>>> of document management -
>> >>>>      >      >> this updates RFC 3986 - but surely there are other
>> >>>> concerns that might need to
>> >>>>      >      >> be addressed.  I see some effort to address software
>> >>>> backwards-compatibility in
>> >>>>      >      >> discussion threads, but I found very little in the
>> >>>> draft itself.
>> >>>>      >      >>
>> >>>>      >      >> The configuration of zones on a machine is could be
>> >>>> private information, but
>> >>>>      >      >> this information is being broadcast to servers.  In
>> >>>> HTTP, that is in Host
>> >>>>      >      >> header fields; on the Web, in document.location.  This
>> >>>> information might
>> >>>>      >      >> contribute significant amounts of information toward a
>> >>>> fingerprint.  I
>> >>>>      >      >> appreciate that the stripping of zone ID was never
>> >>>> implemented, but it is a
>> >>>>      >      >> useful feature.
>> >>>>      >      >>
>> >>>>      >      >> Arguments in Section 5 depend on the zone IDs being
>> >>>> hard to guess, but that
>> >>>>      >      >> isn't true.  Zone IDs are - in practice - low entropy
>> >>>> fields.  More critically,
>> >>>>      >      >> they are fields that are sent to servers.
>> >>>>      >      >>
>> >>>>      >      >> Zone ID size is not bounded - most implementations
>> will
>> >>>> have a size limit on
>> >>>>      >      >> the authority or host portion of a URI (256 octets is
>> >>>> sufficient for current
>> >>>>      >      >> names), but the implication is that Zone IDs could be
>> >>>> arbitrary length.
>> >>>>      >      >>
>> >>>>      >      >> Though percent-decoding is not likely to be a concern
>> >>>> from a specification
>> >>>>      >      >> perspective (the operative specification from the
>> >>>> browser perspective does not
>> >>>>      >      >> apply pct-decoding to a v6 address [2]), what work has
>> >>>> been done to verify that
>> >>>>      >      >> a zone ID won't break existing software?
>> >>>>      >      >>
>> >>>>      >      >> [1]
>> >>>>
>> https://mailarchive.ietf.org/arch/msg/last-call/4vEKZosvKvqJ9cufSm5ivsCho_A/
>> <
>> https://mailarchive.ietf.org/arch/msg/last-call/4vEKZosvKvqJ9cufSm5ivsCho_A/>
>> <
>> https://mailarchive.ietf.org/arch/msg/last-call/4vEKZosvKvqJ9cufSm5ivsCho_A/
>> <
>> https://mailarchive.ietf.org/arch/msg/last-call/4vEKZosvKvqJ9cufSm5ivsCho_A/
>> >>
>> >>>>      >      >> [2]
>> >>>>
>> https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-cb4f75973d92a246&q=1&e=1a8ad5bf-5551-4142-b354-2f4d049e530a&u=https%3A%2F%2Furl.spec.whatwg.org%2F%23concept-host-parser
>> <
>> https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-cb4f75973d92a246&q=1&e=1a8ad5bf-5551-4142-b354-2f4d049e530a&u=https%3A%2F%2Furl.spec.whatwg.org%2F%23concept-host-parser>
>> <
>> https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-cb4f75973d92a246&q=1&e=1a8ad5bf-5551-4142-b354-2f4d049e530a&u=https%3A%2F%2Furl.spec.whatwg.org%2F%23concept-host-parser
>> <
>> https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-cb4f75973d92a246&q=1&e=1a8ad5bf-5551-4142-b354-2f4d049e530a&u=https%3A%2F%2Furl.spec.whatwg.org%2F%23concept-host-parser
>> >>
>> >>>>      >      >>
>> >>>>      >      >>
>> >>>>      >      >> --
>> >>>>      >      >> last-call mailing list
>> >>>>      >      >> [e-mail] <mailto:[e-mail]>
>> >>>> <mailto:[e-mail] <mailto:[e-mail]>>
>> >>>>      >      >> https://www.ietf.org/mailman/listinfo/last-call
>> >>>> <https://www.ietf.org/mailman/listinfo/last-call>
>> >>>> <https://www.ietf.org/mailman/listinfo/last-call
>> >>>> <https://www.ietf.org/mailman/listinfo/last-call>>
>> >>>>      >      >>
>> >>>>      >      >>
>> >>>>      >      >> _______________________________________________
>> >>>>      >      >> art mailing list
>> >>>>      >      >> [e-mail] <mailto:[e-mail]> <mailto:
>> [e-mail]
>> >>>> <mailto:[e-mail]>>
>> >>>>      >      >> https://www.ietf.org/mailman/listinfo/art
>> >>>> <https://www.ietf.org/mailman/listinfo/art>
>> >>>> <https://www.ietf.org/mailman/listinfo/art
>> >>>> <https://www.ietf.org/mailman/listinfo/art>>
>> >>>>      >      >
>> >>>>      >      > --
>> >>>>      >      > Prof. Dr.sc. Martin J. Dürst
>> >>>>      >      > Department of Intelligent Information Technology
>> >>>>      >      > College of Science and Engineering
>> >>>>      >      > Aoyama Gakuin University
>> >>>>      >      > Fuchinobe 5-1-10, Chuo-ku, Sagamihara
>> >>>>      >      > 252-5258 Japan
>> >>>>      >
>> >>>>      >     _______________________________________________
>> >>>>      >     art mailing list
>> >>>>      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>> >>>> <mailto:[e-mail]>>
>> >>>>      > https://www.ietf.org/mailman/listinfo/art
>> >>>> <https://www.ietf.org/mailman/listinfo/art>
>> >>>> <https://www.ietf.org/mailman/listinfo/art
>> >>>> <https://www.ietf.org/mailman/listinfo/art>>
>> >>>>      >
>> >>>>      >
>> >>>>      >
>> >>>>      > --
>> >>>>      > https://LarryMasinter.net <https://LarryMasinter.net>
>> >>>> <https://LarryMasinter.net <https://LarryMasinter.net>>
>> >>>> https://interlisp.org <https://interlisp.org> <https://interlisp.org
>> >>>> <https://interlisp.org>>
>> >>>>      >
>> >>>>      >
>> >>>> --------------------------------------------------------------------
>> >>>>      > 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>
>> >>>>      >
>> >>>> --------------------------------------------------------------------
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> https://LarryMasinter.net <https://LarryMasinter.net>
>> >>>> https://interlisp.org <https://interlisp.org>
>> > --------------------------------------------------------------------
>> > IETF IPv6 working group mailing list
>> > [e-mail]
>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > --------------------------------------------------------------------
>>
>>
>
> --
> https://LarryMasinter.net  https://interlisp.org
> _______________________________________________
> art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/art
>