Re: [IPv6] [Last-Call] Artart last call review of draft-ietf-6man-rfc6874bis-02
Larry Masinter <[email protected]>
| Newsgroups | gmane.ietf.apps-discuss,gmane.ietf.ipv6 |
|---|---|
| Message-ID | <CAKq15vdzesGxCdt+DOJkdceVcZx=Ar2fAD=MYP-8tyoZFf-BGA@mail.gmail.com> |
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 <[email protected]> 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 < > [email protected]> 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 > >>>> <[email protected] <mailto:[email protected]>> > 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 > >>>> <[email protected] <mailto:[email protected]> > >>>> <mailto:[email protected] <mailto:[email protected]>>> 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 <[email protected] > >>>> <mailto:[email protected]> <mailto: > [email protected] > >>>> <mailto:[email protected]>>> on behalf of Martin Thomson via > >>>> Datatracker <[email protected] <mailto:[email protected]> > >>>> <mailto:[email protected] <mailto:[email protected]>>> > >>>> > >> Date: Friday, 16 September 2022 at 21:32 > >>>> > >> To: [email protected] <mailto:[email protected]> > >>>> <mailto:[email protected] <mailto:[email protected]>> <[email protected] > >>>> <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> > >>>> > >> Cc: [email protected] > >>>> <mailto:[email protected]> > >>>> <mailto:[email protected] > >>>> <mailto:[email protected]>> > >>>> <[email protected] > >>>> <mailto:[email protected]> > >>>> <mailto:[email protected] > >>>> <mailto:[email protected]>>>, [email protected] > >>>> <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> > >>>> <[email protected] <mailto:[email protected]> <mailto:[email protected] > >>>> <mailto:[email protected]>>>, [email protected] > >>>> <mailto:[email protected]> <mailto:[email protected] > >>>> <mailto:[email protected]>> <[email protected] > >>>> <mailto:[email protected]> <mailto:[email protected] > >>>> <mailto:[email protected]>>> > >>>> > >> 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 > >>>> > >> [email protected] <mailto:[email protected]> > >>>> <mailto:[email protected] <mailto:[email protected]>> > >>>> > >> 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 > >>>> > >> [email protected] <mailto:[email protected]> <mailto: > [email protected] > >>>> <mailto:[email protected]>> > >>>> > >> 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 > >>>> > [email protected] <mailto:[email protected]> <mailto:[email protected] > >>>> <mailto:[email protected]>> > >>>> > 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 > >>>> > [email protected] <mailto:[email protected]> > >>>> > 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 > > [email protected] > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -- https://LarryMasinter.net https://interlisp.org _______________________________________________ art mailing list [email protected] https://www.ietf.org/mailman/listinfo/art