--On Wednesday, 27 September, 2006 08:09 -0700 Dave Crocker
<dhc2@xxxxxxxxxxxx> wrote:
>
>
> John C Klensin wrote:
>> Dave, unfortunately, if "suffix" is formally defined, I
>> haven't been able to find it.
>
> Right.
>
> I was not intending to suggest that the specification was
> acceptable, and apologize for not making that clear.
>
> I was merely noting that the construct only made sense in
> terms of an organization "base" domain name, rather than a TLD.
>
> So it is a number of anchored right-hand fields, rather than
> only containing the single, right-most-field.
>
> As you and other note, the specification is critically flawed.
>
> At the least:
>
> 1. It fails to define the semantics of "suffix".
>
> 2. It does not specify any syntactic detail for the <domain
> suffix> field of the DHCP option. Is it a dotted ascii
> string? Some other encoding?
Actually, I believe that the document does specify this,
although the definition involves two levels of indirection and
is convoluted. Personally, I don't find two levels of
indirection acceptable when sorter and clear paths exist but, if
that were the only problem with this document, I believe it
would be acceptable as a Proposed Standard.
Specifically, in section 2, we have
The domain suffix in the 'domain suffix' field MUST
include only one item, and MUST be encoded as specified
in the section of RFC3315 titled "Representation and use
of domain names".
The relevant section of RFC 3315, Section 8, points to Section
3.1 of RFC 1035, which specifies representation of a domain name
as a set of {length string} pairs, one for each label. 3315
also prohibits use of the compressed form, but, since that form
is not discussed in 1035 (3.1), the statement is largely
gratuitous.
Whether that syntax form is wise or optimal or not is, of
course, dependent on intended use, which we don't have.
Certainly if one intends to use it to construct FQDNs for any
purpose other than immediately feeding back into the DNS, there
is a case to be made that dotted-ASCII would be better. But, of
course, this document does not provide enough information for us
to figure that out.
After reading your question, it also occurs to me that this
specification should be required to include an
"Internationalization Considerations" that notes that, if the
label(s) in the "suffix" are IDNs, the punycode form MUST be the
form returned and perhaps justifies that in terms of intended
use.
That, of course, is just another chapter in support of
"critically flawed".
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf