> > > On Wednesday, September 27, 2006 08:49:19 AM -0400 John C Klensin > <john-ietf@xxxxxxx> wrote: > > > Sure. But that isn't what the term means in common (non-IETF) > > practice and the document is quite specific that the return > > value contain exactly one label (er, "item") with no provision > > at all for two. > > Except it doesn't say "label"; that's your interpretation. I grant it is > an entirely reasonable interpretation, and in fact the alternate > interpretation that was suggested is not one that would have occurred to me. Well for this option to encode a TLD it would have to encode 2 label. As for "domain name suffix" while I can't remember seeing a formal definition. In the DNS world it is any domain name appended to a unqualified or partially qualified domain name to create a fully qualified domain name. Now the DNS RFC's always talk about both wire and presentation formats. The option itself is a domain name in uncompress DNS wire format. > > IMO, this document should be rejected, and should stay rejected > > until the authors clean up their terminology, explain how the > > capability is intended to be used, and then explain why the > > Internet needs it. Once it reaches that point, a Last Call > > review will make sense > > I agree. As it stands, this document refers to DNS concepts using terms > other than those normally used, and in particular the term "domain suffix", > while not having any formal meaning I am aware of, has at least one > commonly-used meaning which is different than that apparently intended by > the authors. > > In short, I believe this document currently lacks the precision appropriate > for an IETF specification. > > > , but I would suggest that the proposal > > should still be rejected unless the return value can be an > > all-but-hostname FQDN, not a single-label "suffix". > > I agree with this also, given that the latter seems fairly useless. > Fortunately, I suspect the document authors also agree, and are simply > using poor terminology to say what they mean. > > -- Jeff > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DHCP. Email training@xxxxxxxx -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@xxxxxxx _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf