Re: Dnsdir telechat review of draft-ietf-httpbis-rfc6265bis-19

> On Feb 17, 2025, at 8:12 AM, Petr Špaček via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Petr Špaček
> Review result: Almost Ready
> 
> I was assigned as the dnsdir reviewer for draft-ietf-httpbis-rfc6265bis-19.
> For more information about the DNS Directorate, please see
> https://wiki.ietf.org/en/group/dnsdir
> 
> The primary problem of this draft is inconsistent handling of host/name
> identifiers with implicit assumptions. Instructions for handling domain names
> between the lines assume the underlying technology is DNS. Consequently, the
> protocol as specified does not work for alternative naming systems like mDNS
> (RFC 6762) for reasons described in RFC 8222. Please note: mDNS is just an
> example. RFC 6055 page 7 gives more examples.
> 
> The same underlying problem seems to be present in wider HTTP spec ecosystem:
> - [FETCH] spec section 2.5 states DNS is only one example of a naming system
> - ORIGIN] talks only about DNS
> - [URL] hardcodes rules for DNS and IDNA "compatibility" as currently employed
> by DNS (but not mDNS). A trivial test which demonstrates this problem in
> practice with "curl" was already posted to
> https://lists.w3.org/Archives/Public/ietf-http-wg/2025JanMar/0136.html
> 
> Considering the prevalence of this problem in the HTTP specs, I'm not against
> keeping the statut quo if authors decide to do so, but I think it should be
> acknowledged at the beginning of the document.
> 
> Suggested course of action: Remove most of name specifications and replacing it
> with an established spec, e.g. [URL], to avoid yet another fracture in the
> ecosystem.

Umm, no. You appear to be confusing the use of UTF-8 hostnames in
documents and display elements with the use of hostnames in protocol
elements that do not allow UTF-8. Browsers convert from one form to
the other when using references as data for the protocols. curl, in contrast,
expects a URL-specific parameter to be in URI format with the host already
encoded as such (unless you tell it to expect something else). No big deal.

For HTTP, any reference to an origin is already in ASCII (or punycode) form.
HTTP does not do any conversion to other label forms because that conversion
has already been performed prior to using HTTP. Hence, Set-Cookie and Cookie
are entirely based on "normal" ASCII DNS-looking domains, with name handling
that has a lot of hand-wavy algorithmic stuff loosely based on DNS due to the
Cookie-specific history of subdomain authority rules (which have no basis in
IETF standards, yet exist anyway because that's how they implemented it).

Referencing some other "established spec" doesn't work because Cookies
are not, and never have been, implemented in a way that sensible people
would add to a standard. Therefore, rfc6265bis has to define its own version,
even if that means it would be wrong in the general case.

Of course, this doesn't mean the current text is right. If it can be improved
within the scope of an HTTP field handler, please do identify those problems
so that they can be fixed.

....Roy

Received on Tuesday, 18 February 2025 01:02:17 UTC