in the MDRS project my group works on to support multilingual
distributed referential systems we use the concept of Usage Level
Domain which may have a problem with your usage of "suffix". "suffix"
the usual/legal term used for the TLD in many non technical/general
languages. I tend to think that by way of usage ULD will be
translated also by many as "suffix", while I suggest "affix" to be
used. We experimented this concept for two years through the dot-root
test bed.
An ULD is the "TLD" that the user enters, which may be transformed in
different ways depending on the kind of access. Chinese
Names, New.net, DNAMEd IDN.IDN use ULDs. ULDs are made of what the
user will type and of all the different suffixes or affixes that can
replace it depending on the ISP, plug-in, DNAME, etc. for a proper resolution.
jfc
At 10:44 27/09/2006, Stig Venaas wrote:
>John C Klensin wrote:
>>--On Wednesday, 27 September, 2006 09:19 +0200 Stig Venaas
>><stig.venaas@xxxxxxxxxx> wrote:
>>
>>>Frank Ellermann wrote:
>>>
>>>>Fred Baker wrote:
>>>>
>>>>["domain suffix"]
>>>>
>>>>
>>>>>It is the new-speak for use when all us ancient geeky types
>>>>>would prefer "TLD".
>>>
>>>It's what a client might add to it's hostname to form an FQDN.
>>>Typically also used as domain search path by many systems if
>>>no explicit search path is specified. Often also called
>>>"domain name".
>>
>>Whoops. It is what a client might add to a hostname to form an
>>FQDN if, and only if, that hostname appears as a second level
>>domain. But hostnames as registrations in TLD zones are not
>>especially common, MX records for mail and short forms for web
>>servers notwithstanding. The typical host name looks more like
>>abc.example.com or xyz.example.co.uk.
>
>Right. In the context of this draft, the term domain suffix is
>not meant to be just the TLD. If "domain suffix" generally means,
>or is thought of as, just the TLD, then the draft should use some
>other term instead.
>
>>For example, note that to get an FQDN from Frank's hostname
>>("xyzzy") one needs to add "claranet.de", and not "de", but the
>>latter is all that is permitted by this proposal. If software
>>Frank was running assumed it could use this DHCP option to
>>construct an FQDN from Frank's hostname, Frank would end up with
>>xyzzy.de, which is probably not what is intended.
>
>Right, I understand what you mean, provided that "domain suffix"
>generally just means the TLD or the last label in the FQDN.
>
>>
>>>>I thought it's some new kind of DHCP builtin DynDNS service.
>>>>
>>>>If it's a TLD I'm perplexed why that would ever change for a
>>>>given DHCP server. And for clients of different servers the
>>>>TLD isn't enough to know where they are.
>>>
>>>For a given DHCP server and a given client, this would
>>>normally not change. The draft doesn't say that it might
>>>change either. However, a given server might give different
>>>domain suffices to different clients.
>>
>>But, if your guess as to what this is for -- providing
>>information for completing an FQDN given a host name -- is
>>correct, then the option should be returning all of the FQDN
>>after the first component, "claranet.de" in Frank's case or
>>"bogus.domain.name" for a host FQDN of
>
>Yes
>
>>"silly.bogus.domain.name". But that use is prohibited: the
>>specification says that the option value may contain only one
>>"item" (presumably a DNS label).
>
>"One item" is intended to say that there is just one "domain name".
>So you can specify "claranet.de" so that you get xyzzy.claranet.de,
>but it can not have two values/items, like both "claranet.de" and
>"bogus.domain.name". Clearly the text could be improved here.
>
>>The only thing I can think of that this option, as specified,
>>would support is not FQDN completion but the setting and
>>implementation of policy options on an TLD basis. An example of
>>such a policy option would be the idea of interpreting IDNs
>>differently depending on what top-level domain they appeared in
>>that floated around some years ago. That whole family of
>>policies strikes me as bad ideas, bordering on horrible, given
>>the nature of the DNS administrative structure.
>
>Right, this is not at all what is intended.
>
>Stig
>
>>I have sent a somewhat longer note to the IESG list.
>> john
>>
>>_______________________________________________
>>Ietf mailing list
>>Ietf@xxxxxxxx
>>https://www1.ietf.org/mailman/listinfo/ietf
>
>
>_______________________________________________
>Ietf mailing list
>Ietf@xxxxxxxx
>https://www1.ietf.org/mailman/listinfo/ietf
>
>
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf