Re: more on binary labels and longest match

["Matt Crawford" <crawdad@fnal.gov>]

(Collected reply to >= 3 messages ...)

Robert:  No, I see no need, other than time-saving, for longest-match
backtracking to stop at a binary/traditional boundary.

Jerry:  I'm glad we have closue on the matter of 0/0.  I did have one
commenter (by private mail, I think) request that even without 0/0
allowed, he'd rather see N->N+1 as the interpretation of the count
byte rather than N -> N ? N : 256.  Does anyone else feel that way?

Sure, I can drop the longest match description and the notion
of "binary ancestor" from binary-labels, no problem.  It will then
become quite thin.  (Although a bit more exemplary material was
requested and will be added.)

Paul: No, binary labels are still useful without longest-match.  In
fact, with an additional restriction on DNAME usage (in zone files,
not in the spec), I think the IPv6 needs could be met even without
longest match.  But if there's no WG imedpiment to LM in EDNS,
there's no need to make that determination certain.

> ... unless he can make reference to the LM bit and the behaviour of
> QUERY in the presence of that bit.  Therefore I recommend that he do
> that if nec'y.

Feel free to hijack text from my binary-labels-01, section 4, which I can
then point to.


Now the DNAME draft makes at least as big an impact on query processing,
and you mentioned that you might do a broader updating of some of 1034.
Do you have your sights on 1034's sections 4.3.2 and/or 5.3.3?

				Matt