Re: [IPv6] [Last-Call] Artart last call review of draft-ietf-6man-rfc6874bis-02
Rob Sayre <[email protected]>
| Newsgroups | gmane.ietf.apps-discuss,gmane.ietf.ipv6 |
|---|---|
| Message-ID | <CAChr6Sxzn5dcXTmn5RNxWJ5_he-LORAkPvsFM7NvtFL6=vvaRQ@mail.gmail.com> |
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 <[email protected]> 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 <[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 > _______________________________________________ art mailing list [email protected] https://www.ietf.org/mailman/listinfo/art