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

On 13. 10. 25 16:12, Steven Bingler wrote:
> Thank you for your thorough review. My apologies for the long delayed
> response, I had to take a hiatus.

Hello,

and I apologize for the delay as well, last weeks were turbulent. Too 
bad we could not meet at IETF venue, pen and paper might be useful for 
some of these :-)

> 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.

Happy to answer any questions (if I know answers...)!

Perhaps this older e-mail could serve as an illustration of the problem 
at hand with different naming systems and their different encoding rules 
for names:

https://mailarchive.ietf.org/arch/msg/last-call/bruydK32zq7pIep1VprdRwujcEo/

>>> (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.

With my software developer hat on, it makes me mad that the document 
lays out a formal grammar and then free form text elsewhere says "ya 
know, ignore the grammar and do this". It kind of defeats purpose of 
formal grammar!

I think it would lower risk of misunderstandings if grammar itself was 
absolutely clear. Something along those lines:

GENERATOR syntax:
domain-av         = "Domain" BWS "=" BWS domain-value

CONSUMER syntax:
domain-av         = "Domain" BWS "=" BWS [.]domain-value

(or some other suitable form)

Or just rename the section to 'Syntax for generators' (or producers or 
whatever term you find descriptive) to make it clear it does not apply 
to consumers.

This ties to my complaint at the end of your reaction - difference 
between allowed behavior of generator vs. consumer.


>>> 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.

Apologies, that was a typo. I meant RFC 5890 page 10 (the same number as 
in previous paragraph).


>>> 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.

Perhaps add a sentence like "weird inputs will be rejected because they 
will not match" or something?


>>> 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?

See above about the difference between producer and consumer grammar. 
It's an illustration of the problem I had I mind, I guess, but it is 
half a year ago so I might be misremembering things.

-- 
Petr Špaček

Received on Monday, 10 November 2025 03:32:50 UTC