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

Hello Petr,

Thank you for your thorough review. My apologies for the long delayed
response, I had to take a hiatus.

I'm still working through the issues that you've highlighted. I'm not
as familiar as I'd like to be with name resolution systems so I have
some further discussions about the issues.

> > (Note that a leading %x2E ("."), if present, is ignored even though that
character is not permitted.)
> Should this be mentioned in the 4.1.1. Syntax? This inconsistency makes me
> wince.

It's my understanding that the `domain-value      = <subdomain>`
syntax already diallows the leading '.', but that for historical
reasons some servers will still produce it, hence the note.

> > 5.1.2. Canonicalized Host Names
> This algorithm does not handle all possible inputs.
> Using teminology from RFC 5890 sec. 2.3.1: DNS name (RFC 1035) > LDH host
name (RFC 1123) > R-LDH Label (RFC5890) > XN-label > Fake A-label vs. A-label

Is the issue here that the current algorithm will, incorrectly,
instruct to convert a reserved LDH label into an (fake) A-label which
is invalid?

> According to diagram in RFC 5860 page 10,
I can't find the diagram you're referring to.

> > 5.6.3. The Domain Attribute
> The preamble of section 5.6
explicitly states weird inputs are to be expected
> > 5.7. Storage Model

What this algorithm is relying on is that this domain attribute's
value must match up with the request url which would mean that any
"weird" character inputs, "~bla!.example.com", would cause that
matching to fail and the cookie to be discarded.

> > 5.8.3. Retrieval Algorithm
> Sections 5.7 Storage Model and 5.8 Retrieval Model sort of ignore the role of
> 'generator', i.e. the server which needs to properly form cookies. Perhaps it
> is okay, but it has surprised me. In DNS spec we often have 'server' and
> 'client' parts in the spec, but here we seem to have only 'client'.

Sorry, I don't follow. Could you rephrase the issue?

Thanks,
- Steven

Received on Monday, 13 October 2025 20:12:59 UTC