On 18. 02. 25 2:02, Roy T. Fielding wrote:
On Feb 17, 2025, at 8:12 AM, Petr Špaček via Datatracker <noreply@xxxxxxxx> 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
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
