New topic, name domains vs. IFIP "user-friendly" non-domain names
Marvin A. Sirbu, Jr.
names. It is perfectly plausible for there to be domain style names
of the form "Julian_Davies.University_of_Western_Ontario.Canada."
All that is required is a top level domain named Canada that contains a
subdomain named University_of_Western_Ontario, etc. This domain name
would then map into a mail forwarder or host where you read your mail.
The differences have to do not with what is a name and what is an
address, but rather what is the object that the two types of names are
in fact names of. Domain style names are names of host computers. IFIP
style names are names of "User Agents" which are mail processes running on
either a personal workstation or a shared host. To fully identify a
mail process using domain style domains, one has to say something like,
Davies@Julian_Davies.University_of_Western_Ontario.Canada in order to
identify the process on the host
Julian_Davies.University_of_Western_Ontario.Canada.
The other difference has to do with attaching a specific semantics to
the various components. In domain style names, there is no semantics
associated with the subdomain University_of_Western_Ontario. In IFIP
style names, this would be specified as a locale or an organziation.
What is the value of specifying some semantics? It might make it easier
to guess. It also forces databases to be organized by the particular
semantics chosen, instead of whatever happened to be convenient. For
example, there is no reason why Internet_protocol_czar.ARPA couldn't be
a valid name for Jon's personal workstation; indeed this might even be a
sensible thing to do from a Hamming code point of view if Jon gets lots
of messages. The IFIP proposal doesn't provide a semantic category for
Internet_protocol_czar and thus could not accept a name of that form.
For implementation reasons, the semantic categories must be arranged in
a hierarchy. This then leads to the requirement that the top layer in
the hierarchy must have entries for ALL valid values of the next
semantic level. This imposes constraints on the ability to agregate
levels on the basis of administrative or operational performance reasons
as opposed to for reasons of name structure. Thus, if semantic
categories are country, city, address, person, that works fine for
France.Paris.Kennedy_Blvd.John_Doe, but not for
USA.Paris.Kennedy_Blvd.John_Doe, because you need another level of
hierarchy -- State names -- to CONVENIENTLY disambiguate, at least in
the US. Domain names give you more flexibility to define categories as
you please.
Marvin Sirbu
Julian Davies
A response to Marvin Sirbu, which doesn't claim to settle
the question...
Regarding the idea that the IFIP naming scheme identifies User
Agents, which are 'mail processes' rather than some kind of
arbitrary machine specifier...
I do see the distinction between 'names' and 'addresses' as crucial
to making sense of this. The Directory Service is supposed to
provide a translation from 'names' to 'addresses'; The address will
be something on the nature of a Session Service Access Point, and
could be a process identifier or a specific machine address (e.g.
X.121) with extra protocol identifier specifications. IFIP names
do not (as yet) have an agreed format for being typed. The
name
Canada, University_of_Western_Ont, Julian_Davies
is suposed to be something that is guessable and/or easy to remember.
It is up to the directory server to remember that that name is
associated with an address which currently could look like
djmdavies%uwo-hobb...@uwo.UUCP
or 302031500076.FTMAIL.djmdavies {these are both slightly
invented}
or could be an .ARPA address, or something else which includes
specific machine and userid codes. The point is not that my
mailbox "process" floats around, but that other people don't need
to remember exactly where it is. For users at MIT, IFIP names
could look like
USA, MIT, <personal name>
and never mind whether the mailbox is on MIT-MULTICS, or MIT-AI, or
MIT-whatever (maybe somewhere down on a LAN).
---------------
Domains regarded as not having specific semantics, or more precisely
not having 'types', while IFIP name components are 'typed':
This is a fair comment. I think only trying it out will settle
the matter of what is "best", which presumably means easiest to
manage and use. The IFIP name I quoted for myself should perhaps
have been given as
C="Canada", O="Univ of Western Ont", PN=("Julian", "Davies")
to make the infrastructure clearer. Showing the types of the
attributes or components involved means that the elements do not
have to be given in any specific order, whereas the domain-oriented
name/address makes order significant. It is a matter of personal
taste perhaps. The typed structuring does lend itself to being
represented within the scheme of X.409 (Presentation Transfer Syntax
and Notation) for representing typed data structures in messages.
Some people think that it will be easier for ordinary people to
use. Anyone who does not like it could presumably keep on typing
addresses directly, and ARPA-style domain-based names count as
addresses in my view. A lot will depend on the quality of the user
interfaces and of the directory service.
UUCP: ..watmath!deepthot!julian