From nobody Sun Mar 26 11:56:07 2023 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15031C15256B; Sun, 26 Mar 2023 11:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vf8tZskmBsc; Sun, 26 Mar 2023 11:56:00 -0700 (PDT) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BACBC1524DE; Sun, 26 Mar 2023 11:56:00 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id eg48so27207635edb.13; Sun, 26 Mar 2023 11:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679856958; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=INumD8UZ29MYNG9sfajMLfETPTItulS8Ra7nggVZP1s=; b=omUpZHPcDHeSQ896YG3BveMm73EM+QPkT17eh1haNSUW/g3PHF48jgujBNz628Rmb9 mCqFS6Hy1LHXLWZwvqAiUxBo8WsJ9qfmsmQAWZRsY/quGf7HlYMjaQMCFbnZJqMS9IJK kpjOnsyvULyxYLkDbC7X3fRlfCYuDSHoeDXANDRbNKmgHIoUqhvwNXBWHXvBDTggL2Kr ibGk0LhVLWF14ChkSNdOWT7Ggb9ezmOtxoECqhOuvW06uWrStohOw0uZ9jsa3xbtW6Gw CScygXJo8gD7xZW0Afc2h8E+WRCzs9KeGcTdmRAOEePv5sKOz1iZA1UKkL3rV06xQhN1 MVwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679856958; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=INumD8UZ29MYNG9sfajMLfETPTItulS8Ra7nggVZP1s=; b=w8Hwy71ZBBW4nO6rQkdpkcGnNKYTKDNccIqKbfMihBzfBLQ8s/k8QSCBP3SYDFSuFq vwJUGNN1k3E57vaJpLEZffTa6ET2DxQbFIC6vp04zfsd6fFeaN/T5cqiAmDHTvZ5Qpq6 fAerHmdA6fW5fUPFiilddG8m3FPxAwN20XGmCNFX2mp1KAbDAiuR1k8QT6rqCxwKrI4I STbPEaM2ah/w3o1OS9HI0+vAn82t5e/2LIFESF0Xq0+us2lLqihhv7tCDgJOggUG1iid 6kMruKC1N5Qa4DruxcyBm3JljOenoWMPreh7Fso8PZDCUF0TR4nNg/DCQRE2M/XPjt72 rGog== X-Gm-Message-State: AAQBX9d5tv416TA05SIwhxCinBaCTKmSYx4SCwiFnduPeMzg1Puq15iQ 8AcVQ2yumO+z9mA9c4W/SPuRRg7EZ5SupzdyrYs= X-Google-Smtp-Source: AKy350aK06GOFjDY/wPcOGfo8z95hRVmpURigVKIohwVMbLaRBqMX7AivXOQQ/C/VLdRxn2rF5R3mtSTdwQUD/PhxTw= X-Received: by 2002:a17:907:d687:b0:93d:a14f:c9b4 with SMTP id wf7-20020a170907d68700b0093da14fc9b4mr4394041ejc.2.1679856957619; Sun, 26 Mar 2023 11:55:57 -0700 (PDT) MIME-Version: 1.0 References: <259300D0-A0D5-47B8-935E-DD2A140A139E@msweet.org> In-Reply-To: From: Rob Sayre Date: Sun, 26 Mar 2023 11:55:46 -0700 Message-ID: To: Larry Masinter Cc: Michael Sweet , Brian E Carpenter , =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , Martin Thomson , Francesca Palombini , art@ietf.org, ipv6@ietf.org Content-Type: multipart/alternative; boundary="0000000000003b820705f7d22df9" Archived-At: Subject: Re: [art] [IPv6] [Last-Call] Artart last call review of draft-ietf-6man-rfc6874bis-02 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2023 18:56:05 -0000 --0000000000003b820705f7d22df9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: an_underscore 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=E2=80=AFAM Larry Masinter 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) > > If I had do-overs (in another universe) I would have pushed harder > The Compatibility Dilemma (ietf.org) > > > On Sun, Mar 26, 2023 at 5:10=E2=80=AFAM Michael Sweet = wrote: > >> Another point: there are other URI schemes that benefit from this work, >> not the least of which are =E2=80=9Cipp=E2=80=9D and =E2=80=9Cipps=E2=80= =9D, 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 hostname= s) >> is not available. >> >> So I really don=E2=80=99t want and don=E2=80=99t support pushing for new= URI schemes. >> >> ____________________ >> Michael Sweet >> >> > On Mar 26, 2023, at 2:34 AM, Brian E Carpenter < >> brian.e.carpenter@gmail.com> wrote: >> > >> > =EF=BB=BFIt'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=C3=BCrst 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 possibili= ty >> >> 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=E2=80=AFPM Brian E Carpenter >> >>>> > >> 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=E2=80=AFPM Martin Thomson >> >>>> >> >>>> >> wrote: >> >>>> > >> >>>> > Despite sessions being busy, my extrasessionary schedule >> is >> >>>> light. >> >>>> > >> >>>> > Would 16:30 Tuesday work for people? A side meeting roo= m >> >>>> is presently available at that time. >> >>>> > >> >>>> > On Sun, Mar 26, 2023, at 11:36, Martin J. D=C3=BCrst wro= te: >> >>>> > > I just happened to bump into Martin Thomson at the IE= TF >> >>>> hackathon in >> >>>> > > Yokohama. We discussed this draft, and thought we mig= ht >> >>>> 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 i= s >> >>>> interested; >> >>>> > > that's the reason for cross-posting. Martin Thomson i= s >> >>>> 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 you= r >> >>>> 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=E2=80=99s question: Do any of the communities rejecting it h= ave 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/ >> >>>> > > >> >>>> > >>>> > >> >> >>>> > >> >> >>>> > >> From: last-call > >>>> > last-call-bounces@ietf.org >> >>>> >> on behalf of Martin Thomson >> via >> >>>> Datatracker >> >>>> >> >> >>>> > >> Date: Friday, 16 September 2022 at 21:32 >> >>>> > >> To: art@ietf.org >> >>>> > > >>>> >> >> >>>> > >> Cc: draft-ietf-6man-rfc6874bis.all@ietf.org >> >>>> >> >>>> > >>>> > >> >>>> > >>>> >> >>>> > >>>> >>, ipv6@ietf.org >> >>>> = > >> >>>> > >>>> >>, last-call@ietf.org >> >>>> > >>>> > > >>>> > >>>> >> >> >>>> > >> 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 specificati= on >> >>>> is not just something >> >>>> > >> that they don't want to implement, but that it is no= t >> >>>> good for the Web. Public >> >>>> > >> communications from them will be somewhat more polit= e >> >>>> and circumspect, but it >> >>>> > >> has been made clear to me that this change is not >> wanted. >> >>>> > >> >> >>>> > >> The IETF does occasionally publish specifications th= at >> >>>> don't end up being >> >>>> > >> implemented, but we usually look for signals that a >> >>>> protocol might be >> >>>> > >> implemented before even starting work. Here, we hav= e >> 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 hi= s >> >>>> 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 IET= F >> >>>> 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 sens= e >> >>>> 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 Orig= in >> >>>> 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 add= ed >> >>>> to a component that is >> >>>> > >> critical to web security. >> >>>> > >> >> >>>> > >> For instance (2), in HTTP and several other protocol= s, >> >>>> 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 serve= rs >> >>>> to information that they >> >>>> > >> need to filter out. Some might not be prepared to d= o >> >>>> 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 398= 6. >> >>>> The only issue related >> >>>> > >> to this that is addressed in the draft is the questi= on >> >>>> 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. Th= is >> >>>> 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 entrop= y >> >>>> 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 i= s >> >>>> sufficient for current >> >>>> > >> names), but the implication is that Zone IDs could b= e >> >>>> arbitrary length. >> >>>> > >> >> >>>> > >> Though percent-decoding is not likely to be a concer= n >> >>>> from a specification >> >>>> > >> perspective (the operative specification from the >> >>>> browser perspective does not >> >>>> > >> apply pct-decoding to a v6 address [2]), what work h= as >> >>>> been done to verify that >> >>>> > >> a zone ID won't break existing software? >> >>>> > >> >> >>>> > >> [1] >> >>>> >> https://mailarchive.ietf.org/arch/msg/last-call/4vEKZosvKvqJ9cufSm5ivsCh= o_A/ >> < >> https://mailarchive.ietf.org/arch/msg/last-call/4vEKZosvKvqJ9cufSm5ivsCh= o_A/> >> < >> https://mailarchive.ietf.org/arch/msg/last-call/4vEKZosvKvqJ9cufSm5ivsCh= o_A/ >> < >> https://mailarchive.ietf.org/arch/msg/last-call/4vEKZosvKvqJ9cufSm5ivsCh= o_A/ >> >> >> >>>> > >> [2] >> >>>> >> https://protect2.fireeye.com/v1/url?k=3D31323334-501cfaf3-313273af-45444= 5554331-cb4f75973d92a246&q=3D1&e=3D1a8ad5bf-5551-4142-b354-2f4d049e530a&u= =3Dhttps%3A%2F%2Furl.spec.whatwg.org%2F%23concept-host-parser >> < >> https://protect2.fireeye.com/v1/url?k=3D31323334-501cfaf3-313273af-45444= 5554331-cb4f75973d92a246&q=3D1&e=3D1a8ad5bf-5551-4142-b354-2f4d049e530a&u= =3Dhttps%3A%2F%2Furl.spec.whatwg.org%2F%23concept-host-parser> >> < >> https://protect2.fireeye.com/v1/url?k=3D31323334-501cfaf3-313273af-45444= 5554331-cb4f75973d92a246&q=3D1&e=3D1a8ad5bf-5551-4142-b354-2f4d049e530a&u= =3Dhttps%3A%2F%2Furl.spec.whatwg.org%2F%23concept-host-parser >> < >> https://protect2.fireeye.com/v1/url?k=3D31323334-501cfaf3-313273af-45444= 5554331-cb4f75973d92a246&q=3D1&e=3D1a8ad5bf-5551-4142-b354-2f4d049e530a&u= =3Dhttps%3A%2F%2Furl.spec.whatwg.org%2F%23concept-host-parser >> >> >> >>>> > >> >> >>>> > >> >> >>>> > >> -- >> >>>> > >> last-call mailing list >> >>>> > >> last-call@ietf.org >> >>>> > >> >>>> > >> https://www.ietf.org/mailman/listinfo/last-call >> >>>> >> >>>> > >>>> > >> >>>> > >> >> >>>> > >> >> >>>> > >> _______________________________________________ >> >>>> > >> art mailing list >> >>>> > >> art@ietf.org > art@ietf.org >> >>>> > >> >>>> > >> https://www.ietf.org/mailman/listinfo/art >> >>>> >> >>>> > >>>> > >> >>>> > > >> >>>> > > -- >> >>>> > > Prof. Dr.sc. Martin J. D=C3=BCrst >> >>>> > > 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 >> >>>> > art@ietf.org > >>>> > >> >>>> > https://www.ietf.org/mailman/listinfo/art >> >>>> >> >>>> > >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> > -- >> >>>> > https://LarryMasinter.net >> >>>> > >> >>>> https://interlisp.org > >>>> > >> >>>> > >> >>>> > >> >>>> -------------------------------------------------------------------= - >> >>>> > IETF IPv6 working group mailing list >> >>>> > ipv6@ietf.org >> >>>> > Administrative Requests: >> >>>> https://www.ietf.org/mailman/listinfo/ipv6 >> >>>> >> >>>> > >> >>>> -------------------------------------------------------------------= - >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> https://LarryMasinter.net >> >>>> https://interlisp.org >> > -------------------------------------------------------------------- >> > IETF IPv6 working group mailing list >> > ipv6@ietf.org >> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> > -------------------------------------------------------------------- >> >> > > -- > https://LarryMasinter.net https://interlisp.org > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art > --0000000000003b820705f7d22df9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

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

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

This is a stretch. RFC 3986= (or STD 66) was not exactly a fast-moving effort, for good reason. This te= xt makes it sound like there was an unforeseeable=C2=A0problem due to concu= rrent 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=3D"https://ietf.org= ">an_underscore</a>

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

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

thank= s,
Rob


On Sun, Mar 26, 2023 at 8:5= 8=E2=80=AFAM Larry Masinter <LMM@acm.org<= /a>> wrote:

On Sun, Mar 26, 2023 at = 5:10=E2=80=AFAM Michael Sweet <msweet@msweet.org> wrote:
= Another point: there are other URI schemes that benefit from this work, not= the least of which are =E2=80=9Cipp=E2=80=9D and =E2=80=9Cipps=E2=80=9D, w= hich are used by billions of printers and client devices worldwide. This is= really an edge case for supporting access to devices when the preferred me= chanism (mDNS hostnames) is not available.

So I really don=E2=80=99t want and don=E2=80=99t support pushing for new UR= I schemes.

____________________
Michael Sweet

> On Mar 26, 2023, at 2:34 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>
> =EF=BB=BFIt's simply irrelevant to the use cases, which are all we= ll-established uses of http: and https:. Nobody has any need of a new schem= e for these use cases.
>
> Also, the URI will still have to be parsed. I don't see how it cha= nges 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
>=C2=A0 =C2=A0Brian Carpenter
>
>> On 26-Mar-23 18:10, Martin J. D=C3=BCrst 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 possib= ility
>> 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,=C2=A0 =C2=A0Martin.
>>> Regards
>>>=C2=A0 =C2=A0 =C2=A0Brian 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 t= o 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=E2=80=AFPM Brian E Carpenter<= br> >>>> <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0Larry,
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0In a word, the use cases are HTTP and H= TTPS use cases.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0Regards
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Brian Carpenter
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0On 26-Mar-23 16:33, Larry Masinter wrot= e:
>>>>=C2=A0 =C2=A0 =C2=A0 > I haven't been following clos= ely, 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?
>>>>=C2=A0 =C2=A0 =C2=A0 >
>>>>=C2=A0 =C2=A0 =C2=A0 > On Sat, Mar 25, 2023 at 7:57=E2= =80=AFPM Martin Thomson
>>>> <mt@lowentropy.net <mailto:mt@lowentropy.net>
>>>> <mailto:mt@lowentropy.net <mailto:mt@lowentropy.net>>> wrote:
>>>>=C2=A0 =C2=A0 =C2=A0 >
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Despite sessio= ns being busy, my extrasessionary schedule is
>>>> light.
>>>>=C2=A0 =C2=A0 =C2=A0 >
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Would 16:30 Tu= esday work for people?=C2=A0 A side meeting room
>>>> is presently available at that time.
>>>>=C2=A0 =C2=A0 =C2=A0 >
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On Sun, Mar 26= , 2023, at 11:36, Martin J. D=C3=BCrst wrote:
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > I just h= appened to bump into Martin Thomson at the IETF
>>>> hackathon in
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Yokohama= . We discussed this draft, and thought we might
>>>> be able to
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > organize= a little side meeting to discuss the issues and
>>>> hopefully also
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > make som= e progress. We know that Brian is remote, but we
>>>> will try to
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > have a s= etup where he can participate remotely.
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > We welco= me everybody from the IPv6 and URI side who is
>>>> interested;
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > that'= ;s the reason for cross-posting. Martin Thomson is
>>>> way more busy
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > than me,= so I'm letting him (or anybody else) propose
>>>> some time slots.
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Regards,= =C2=A0 =C2=A0Martin.
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > On 2023-= 03-16 22:54, Francesca Palombini wrote:
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> Mart= in: thank you very much for this review. I have
>>>> looked at the following responses as well, and I am not su= re that
>>>> there was ever a conclusion to the mail thread, although I= can see
>>>> that Brian did try to make modifications and clarification= s in the
>>>> text as much as possible. Murray has balloted DISCUSS foll= owing your
>>>> review and subsequent discussion, and I support his DISCUS= S in my
>>>> ballot (1). We will talk about it today. If you have any i= nsight about
>>>> Murray=E2=80=99s question: Do any of the communities rejec= ting it have a
>>>> preferred alternative for achieving the stated goal? It wo= uld be helpful.
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> Than= ks,
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> Fran= cesca
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2= =A0 =C2=A0 1.
>>>> https://datatrac= ker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ballot/
>>>> <https://data= tracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ballot/>
>>>> <https://data= tracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ballot/
>>>> <https://data= tracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ballot/>>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> From= : last-call <last-call-bounces@ietf.org
>>>> <mailto:last-call-bounces@ietf.org> <mailto:last-call-bounces@ietf.= org
>>>> <mailto:last-call-bounces@ietf.org>>> on behalf of Ma= rtin Thomson via
>>>> Datatracker <noreply@ietf.org <mailto:noreply@ietf.org>
>>>> <mailto:noreply@ietf.org <mailto:noreply@ietf.org>>>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> Date= : Friday, 16 September 2022 at 21:32
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> To: = art@ietf.org <mail= to:art@ietf.org> >>>> <mailto:art@ietf.org <mailto:art@ietf.org>> <art@ietf.org
>>>> <mailto:art@ietf.org> <mailto:art@ietf.org <mailto:art@ietf.org>>>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> Cc: = draft-ietf-6man-rfc6874bis.all@ietf.org
>>>> <mailto:draft-ietf-6man-rfc6874bis.all@ietf.org&g= t;
>>>> <mailto:draft-ietf-6man-rfc6874bis.all@ietf.org >>>> <mailto:draft-ietf-6man-rfc6874bis.all@ietf.org&g= t;>
>>>> <draft-ietf-6man-rfc6874bis.all@ietf.org
>>>> <mailto:draft-ietf-6man-rfc6874bis.all@ietf.org&g= t;
>>>> <mailto:draft-ietf-6man-rfc6874bis.all@ietf.org >>>> <mailto:draft-ietf-6man-rfc6874bis.all@ietf.org&g= t;>>, ipv6@ietf.or= g
>>>> <mailto:ipv6@ietf.org> <mailto:ipv6@ietf.org <mailto:ipv6@ietf.org>>
>>>> <ipv= 6@ietf.org <mailto:ipv6@ietf.org> <mailto:ipv6@ietf.org
>>>> <mailto:ipv6@ietf.org>>>, last-call@ietf.org
>>>> <mailto:last-call@ietf.org> <mailto:last-call@ietf.org
>>>> <mailto:last-call@ietf.org>> <last-call@ietf.org
>>>> <mailto:last-call@ietf.org> <mailto:last-call@ietf.org
>>>> <mailto:last-call@ietf.org>>>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> Subj= ect: [Last-Call] Artart last call review of
>>>> draft-ietf-6man-rfc6874bis-02
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> Revi= ewer: Martin Thomson
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> Revi= ew result: Not Ready
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> As a= bit of a preface here, I've been aware of this
>>>> work for some time, but
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> have= refrained from offering opinion.=C2=A0 As liaison to
>>>> the W3C, I felt like my
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> resp= onsibility was to facilitate the conversation.
>>>> However, as Barry has asked
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> me t= o do a review, I feel obligated to set that attempt
>>>> at neutrality aside.
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> The = biggest issue here is that this document is very
>>>> much unwanted by its
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> targ= et audience, as is its antecedent, RFC 6874.=C2=A0 I
>>>> share that concern.
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> I ha= ve clear, strong indications from folks at three
>>>> major browsers
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> (con= veniently, I am at W3C TPAC this week and so was
>>>> able to talk with a few
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> peop= le directly on this topic; inconveniently, I've not
>>>> had a lot of time for
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> this= review) that this change to the URI specification
>>>> is not just something
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> that= they don't want to implement, but that it is not
>>>> good for the Web.=C2=A0 Public
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> comm= unications from them will be somewhat more polite
>>>> and circumspect, but it
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> has = been made clear to me that this change is not wanted.
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> The = IETF does occasionally publish specifications that
>>>> don't end up being
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> impl= emented, but we usually look for signals that a
>>>> protocol might be
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> impl= emented before even starting work.=C2=A0 Here, we have a
>>>> strong signal that a
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> spec= ification won't be implemented.=C2=A0 Mark Nottingham
>>>> asks the same question as
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> well= as point 1 in [1].=C2=A0 (I don't personally find his
>>>> second and third points
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> to b= e especially problematic given adequate
>>>> consultation, but even there, there
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> are = a few concerns that I will outline below.)
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> I do= want to give due credit to the authors - Brian in
>>>> particular - for being
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> very= open and forthright in their consultation with the
>>>> affected constituency.
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> They= have been proactive and responsive in a nearly
>>>> exemplary fashion.
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> Over= all, I think that it would be better for the IETF
>>>> to declare RFC 6874 as
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> Hist= oric(al).=C2=A0 There might be some residual value in
>>>> RFC 4007 from a diagnostic
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> pers= pective, but the use of zone identifiers in URIs
>>>> seems fundamentally
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> inco= mpatible with the goals of URIs.
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> I do= recognize that the Web and HTTP is not the only
>>>> protocol affected by this
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> sort= of change.=C2=A0 The goal is to change all URI types.
>>>> However, I believe that
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> HTTP= is pretty important here and I have a fair sense
>>>> that the sort of concerns
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> I ra= ise with respect to HTTP apply (or should apply) to
>>>> other schemes.
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> ---<= br> >>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> Ther= e are a few technical concerns I have based on
>>>> reviewing the draft.=C2=A0 Some
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> of t= hese - on their own - are significant enough to
>>>> justify not publishing this
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> docu= ment.
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> Incl= usion of purely local information in the
>>>> *universal* identity of a resource
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> runs= directly counter to the point of having a URI.
>>>> This creates some very
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> diff= icult questions that the draft does not address.
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> For = instance (1), the Web security model depends on
>>>> having a clear definition
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> for = the origin of resources.=C2=A0 The definition of Origin
>>>> depends on the
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> repr= esentation of the hostname and it relies heavily
>>>> both on uniqueness
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> (som= ething a zone ID potentially contributes toward)
>>>> and consistency across
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> cont= exts (which a zone ID works directly against).
>>>> Now, arguably the identity
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> of r= esources that are accessed by link-local URIs don't
>>>> need and cannot
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> guar= antee either property, but this is an example of
>>>> the sorts of problem that
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> need= s to be dealt with when local information is added
>>>> to a component that is
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> crit= ical to web security.
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> For = instance (2), in HTTP and several other protocols,
>>>> servers depends on the
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> host= component - as it appears in the URI - to
>>>> determine authority.=C2=A0 If there
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> is n= o rule for stripping the zone ID from URIs, servers
>>>> hostname checks will
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> depe= nd on the client.=C2=A0 That exposes link-local servers
>>>> to information that they
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> need= to filter out.=C2=A0 Some might not be prepared to do
>>>> that.=C2=A0 Hostname checks
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> are = critical for security, especially the consistent
>>>> treatment of the field
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> acro= ss different components like serving
>>>> infrastructure, web application
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> fire= walls, access control modules, and other components.
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> This= is a non-backwards-compatible change to RFC 3986.
>>>> The only issue related
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> to t= his that is addressed in the draft is the question
>>>> of document management -
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> this= updates RFC 3986 - but surely there are other
>>>> concerns that might need to
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> be a= ddressed.=C2=A0 I see some effort to address software
>>>> backwards-compatibility in
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> disc= ussion threads, but I found very little in the
>>>> draft itself.
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> The = configuration of zones on a machine is could be
>>>> private information, but
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> this= information is being broadcast to servers.=C2=A0 In
>>>> HTTP, that is in Host
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> head= er fields; on the Web, in document.location.=C2=A0 This
>>>> information might
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> cont= ribute significant amounts of information toward a
>>>> fingerprint.=C2=A0 I
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> appr= eciate that the stripping of zone ID was never
>>>> implemented, but it is a
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> usef= ul feature.
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> Argu= ments in Section 5 depend on the zone IDs being
>>>> hard to guess, but that
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> isn&= #39;t true.=C2=A0 Zone IDs are - in practice - low entropy
>>>> fields.=C2=A0 More critically,
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> they= are fields that are sent to servers.
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> Zone= ID size is not bounded - most implementations will
>>>> have a size limit on
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> the = authority or host portion of a URI (256 octets is
>>>> sufficient for current
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> name= s), but the implication is that Zone IDs could be
>>>> arbitrary length.
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> Thou= gh percent-decoding is not likely to be a concern
>>>> from a specification
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> pers= pective (the operative specification from the
>>>> browser perspective does not
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> appl= y pct-decoding to a v6 address [2]), what work has
>>>> been done to verify that
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> a zo= ne ID won't break existing software?
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> [1]<= br> >>>> https:/= /mailarchive.ietf.org/arch/msg/last-call/4vEKZosvKvqJ9cufSm5ivsCho_A/ &= lt;https://mailarchive.i= etf.org/arch/msg/last-call/4vEKZosvKvqJ9cufSm5ivsCho_A/> <https://mailarchive.ietf.org/ar= ch/msg/last-call/4vEKZosvKvqJ9cufSm5ivsCho_A/ <https://mailarchive.ietf.org/arch/msg/last-ca= ll/4vEKZosvKvqJ9cufSm5ivsCho_A/>>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> [2]<= br> >>>> https://protect= 2.fireeye.com/v1/url?k=3D31323334-501cfaf3-313273af-454445554331-cb4f75973d= 92a246&q=3D1&e=3D1a8ad5bf-5551-4142-b354-2f4d049e530a&u=3Dhttps= %3A%2F%2Furl.spec.whatwg.org%2F%23concept-host-parser <https://protect2.fireeye.com/v1/url?k=3D31323= 334-501cfaf3-313273af-454445554331-cb4f75973d92a246&q=3D1&e=3D1a8ad= 5bf-5551-4142-b354-2f4d049e530a&u=3Dhttps%3A%2F%2Furl.spec.whatwg.org%2= F%23concept-host-parser> <https://protect2.fireeye.com/v1/url?k=3D31323334-501cfaf3-313273af-454= 445554331-cb4f75973d92a246&q=3D1&e=3D1a8ad5bf-5551-4142-b354-2f4d04= 9e530a&u=3Dhttps%3A%2F%2Furl.spec.whatwg.org%2F%23concept-host-parser <https://protect2.fireeye.= com/v1/url?k=3D31323334-501cfaf3-313273af-454445554331-cb4f75973d92a246&= ;q=3D1&e=3D1a8ad5bf-5551-4142-b354-2f4d049e530a&u=3Dhttps%3A%2F%2Fu= rl.spec.whatwg.org%2F%23concept-host-parser>>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> -- >>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> last= -call mailing list
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> last-call@ietf.org = <mailto:last-cal= l@ietf.org>
>>>> <mailto:last-call@ietf.org <mailto:last-call@ietf.org>>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> https://www.ietf.org/mailman/listinfo/last-call
>>>> <https://www.ietf.org/mailman/lis= tinfo/last-call>
>>>> <https://www.ietf.org/mailman/lis= tinfo/last-call
>>>> <https://www.ietf.org/mailman/lis= tinfo/last-call>>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> ____= ___________________________________________
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> art = mailing list
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> art@ietf.org <mailto:<= a href=3D"mailto:art@ietf.org" target=3D"_blank">art@ietf.org> <m= ailto:art@ietf.org >>>> <mailto:art@ietf.org>>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> 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>>
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > --
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Prof. Dr= .sc. Martin J. D=C3=BCrst
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Departme= nt of Intelligent Information Technology
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > College = of Science and Engineering
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Aoyama G= akuin University
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Fuchinob= e 5-1-10, Chuo-ku, Sagamihara
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > 252-5258= Japan
>>>>=C2=A0 =C2=A0 =C2=A0 >
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0______________= _________________________________
>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0art mailing li= st
>>>>=C2=A0 =C2=A0 =C2=A0 > art@ietf.org <mailto:art@ietf.org> <mailto:art@ietf.org
>>>> <mailto:art@ietf.org>>
>>>>=C2=A0 =C2=A0 =C2=A0 > 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>>
>>>>=C2=A0 =C2=A0 =C2=A0 >
>>>>=C2=A0 =C2=A0 =C2=A0 >
>>>>=C2=A0 =C2=A0 =C2=A0 >
>>>>=C2=A0 =C2=A0 =C2=A0 > --
>>>>=C2=A0 =C2=A0 =C2=A0 > https://LarryMasinter.net <= ;https://LarryMasinter.net>
>>>> <https://LarryMasinter.net <https://LarryMasinte= r.net>>
>>>> https://interlisp.org <https://interlisp.org> <https:= //interlisp.org
>>>> <https://interlisp.org>>
>>>>=C2=A0 =C2=A0 =C2=A0 >
>>>>=C2=A0 =C2=A0 =C2=A0 >
>>>> ----------------------------------------------------------= ----------
>>>>=C2=A0 =C2=A0 =C2=A0 > IETF IPv6 working group mailing l= ist
>>>>=C2=A0 =C2=A0 =C2=A0 > ipv6@ietf.org <mailto:ipv6@ietf.org>
>>>>=C2=A0 =C2=A0 =C2=A0 > Administrative Requests:
>>>> https://www.ietf.org/mailman/listinfo/ipv= 6
>>>> <https://www.ietf.org/mailman/listinfo= /ipv6>
>>>>=C2=A0 =C2=A0 =C2=A0 >
>>>> ----------------------------------------------------------= ----------
>>>>
>>>>
>>>>
>>>> --
>>>> https://LarryMasinter.net <https://LarryMasinter.ne= t>
>>>> https://interlisp.org <https://interlisp.org>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
> --------------------------------------------------------------------


--
_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art
--0000000000003b820705f7d22df9--