Subject: Re: Last call for <draft-aboba-dhc-domsearch-05.txt>

From: Stuart Cheshire <[email-masked]>
Date: Fri, 24 Aug 2001 18:31:39 -0700

Excluding boilerplate and references, a one-page specification. Truly 
remarkable!

I hate to have to add text to such a succinct specification, but there 
are a couple of things I think should be clarified:

1. Compression offsets

>For use in this specification, the pointer refers to the offset
>within the SearchString portion of the option. If multiple
>searchlist options are present, then the SearchString portion of
>all the options are concatenated and the pointer refers to the
>offset within the concatenated SearchString.

In the diagram, there are *two* SearchString portions shown in the 
example option. Which does the text refer to?

I suggest:

   For use in this specification, the pointer refers to the
   offset within the data portion of the DHCP option (not
   including the preceding DHCP option code byte or DHCP option
   length byte). If multiple Domain Search Options are present,
   then the data portions of all the Domain Search Options are
   concatenated together as specified in "Encoding Long DHCP
   Options" [7] and the pointer indicates an offset within
   the complete aggregate block of data.

2. Null root label

The draft does not state explicitly that every search domain name MUST 
end with the null root label, otherwise, all the search domains run 
together into one long domain name. As described in my example in my 
previous mail about draft-ietf-dhc-concat-01.txt, naive implementers may 
assume they can put each search domain in its own search option, and use 
option boundaries to indicate the boundaries between names.

I think a diagram showing example encoding would clarify use of 
concatenation, compression offsets, and the requirement for a null root 
label at the end of every name.

I suggest:

   Example encoding of a search list consisting of
   "eng.apple.com." and "marketing.apple.com.":

   +---+---+---+---+---+---+---+---+---+---+---+
   |TBD| 9 | 3 |'e'|'n'|'g'| 5 |'a'|'p'|'p'|'l'|
   +---+---+---+---+---+---+---+---+---+---+---+

   +---+---+---+---+---+---+---+---+---+---+---+
   |TBD| 9 |'e'| 3 |'c'|'o'|'m'| 0 | 9 |'m'|'a'|
   +---+---+---+---+---+---+---+---+---+---+---+

   +---+---+---+---+---+---+---+---+---+---+---+
   |TBD| 9 |'r'|'k'|'e'|'t'|'i'|'n'|'g'|xC0|x04|
   +---+---+---+---+---+---+---+---+---+---+---+

   Note:

   (i)  The encoding of has been split (for this example) into
        three Domain Search Options. All Domain Search Options
        are logically concatenated into one block of data
        before being interpreted by the client.
   
   (ii) The encoding of "eng.apple.com." ends with a zero, the null
        root label, to mark the end of the name, as required by RFC 1035.
   
   (iii)The encoding of "marketing" (for "marketing.apple.com.")
        ends with the two-octet compression pointer C004 (hex),
        which points to offset 4 in the complete aggregated block of
        Domain Search Option data, where another validly encoded domain
        name can be found to complete the name ("apple.com.").

   Every search domain name must end either with a zero or with
   a two-octet compression pointer. If the receiver is part-way
   through decoding a search domain name when it reaches the end
   of the complete aggregated block of searchlist option data,
   without finding a zero or a valid two-octet compression pointer,
   then the partially read name must be discarded as invalid.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org