[Last-Call] Re: Dnsdir telechat review of draft-ietf-httpbis-rfc6265bis-19

[Petr Špaček <[e-mail]>]

On 18. 02. 25 2:02, Roy T. Fielding wrote:
>> On Feb 17, 2025, at 8:12 AM, Petr Špaček via Datatracker <[e-mail]> 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

I'm indeed confused! I still don't understand what you are saying...

Please, can you give me examples how to encode these two domains into 
URLs (or Host or Set-Cookie headers)?

1. DNS with IDNA2008 seems clear:
http://háčkyčárky.cz/ -> http://xn--hkyrky-ptac70bc.cz/

2. mDNS (bare UTF-8):
http://háčkyčárky.local/ -> ???


I've naively tried 'http://h%C3%A1%C4%8Dky%C4%8D%C3%A1rky.local/' but 
curl (understandably) converts this into Unicode and _then_ does 
punycode, which is incorrect for this particular case with mDNS:

$ curl http://h%C3%A1%C4%8Dky%C4%8D%C3%A1rky.local/
curl: (6) Could not resolve host: xn--hkyrky-ptac70bc.local


Can you set me straight, please? How "háčkyčárky.local" gets converted 
into the ASCII form you mentioned in your response?

Thank you for your time.
Petr Špaček



> 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