REM@Mit-Mc.ARPA (Robert Elton Maas) (04/23/84)
The concensus seems to be that MsgGroup is the correct place to discuss differences between the heirarchial naming method being adopted by the Internet community and the non-heirarchial naming method being proposed to CCITT by IFIP WG 6.5. It has been suggested that the IFIP proposal would permit heirarchial domains of naming authority, but I fail to see it. Could somebody explain it to me? After that is cleared up, perhaps we who have seen both the IFIP proposal and the Internet plan could discuss the differences and debate the merits? Personally I like the explicit heirarchial nature of the Internet plan, and would like something like that incorporated into the IFIP proposal, unless it's already there somewhere.
julian@deepthot.UUCP (Julian Davies) (04/26/84)
------------------------------------- From: REM@Mit-Mc.ARPA (Robert Elton Maas) Sender: ka@hou3c.UUCP (Kenneth Almquist) It has been suggested that the IFIP proposal would permit heirarchial domains of naming authority, but I fail to see it. Could somebody explain it to me? -------------------------------------- I wonder which version of the IFIP proposal you are looking at. The latest one I have is "A User-friendly Naming Convention for Public data Networks", Version 2, November 183, arising from the IFIP WG6.5 NASE Subgroup meeting, Ottawa, July 1983. The need is seen for the naming process to be 'user friendly'; that is it should not depend on knowledge of things which humans are unlikely to know routinely. Perhaps an important source of confusion would be to not distinguish between "names" and "addresses". Names are to be expressed in terms of things people can remember easily. Addresses on the other hand are 'machine-oriented'. The systems for identifying people in practically all current message systems, including the ARPAnet 'internet' style, are what would be called 'machine oriented' in this context. The domain names and host names appearing in addresses are closely tied to the hardware config- urations of the networks. It is anticipated that one of the purposes of the directories to be provided in future will be translating from 'names' to 'addresses'. As an example, my university has several machines with mail boxes and mail software; this is not unusual. My address would identify inter alia which machine *my* mail box is on, and which network(s) it can be reached by. My *name* however, would be something like (Canada, University of Western Ontario, Julian Davies) as a fairly minimal version, or I could be named by a more elaborate specification which also mentioned the Province, my department, and maybe a nickname or telephone number to be sure of avoiding ambiguity. The structure of *names* is defined, now, by a directed labelled graph structure. However, the structure is not arbitrary, and the First Guideline is: The dominant structure of the Graph should be hierarchical. That is, the graph will be 'almost' a tree. A tree would be a perfect hierarchy, but here we allow for some flexibility, that in some cases a person may be reachable via several different routes through the directory structure. For instance, it may be that multi-nationals such as IBM would be represented at the top level of the hierarchy, and someone in IBM Bulgaria (for instance) could be reached either starting with the Bulgaria National directory database, or with the IBM top-level database, in either case ending up looking in database provided by that particular organization. The graph also allows for certain links to 'skip a level'; but the graph should certainly be cycle-free. Someone who happens to know the *address* for a person (e.g. an internet address as they now exist) is free to use it. Some people might even remember X.121 numbers they way we have to remember telephone numbers, for a person's personal workstation. But the object is to provide a system at least as good as the telephone directory, and use the power of the computer to help people figure out how to contact each other when they do NOT know the particular networks etc that are involved. -------------------------------------------- After that is cleared up, perhaps we who have seen both the IFIP proposal and the Internet plan could discuss the differences and debate the merits? Personally I like the explicit heirarchial nature of the Internet plan, and would like something like that incorporated into the IFIP proposal, unless it's already there somewhere. -------------------------------------------- In short, the hierarchy is there, but disguised because that seems more likely to be useful. Especially when the message systems get really widespread. But the Differences between the Internet plan and the IFIP proposal are a result of one being a scheme for addresses and the other a proposal for names. The directories will mediate when required. In reality, the name form *has* to have a hierarchy somewhere, because it would be quite impractical otherwise to implement the directory servers. The database will be far too large to put all in one place, or to search without a good search strategy and indexing scheme (say, 10 or 20 years from now). Julian Davies UUCP !uwo!julian ENVOY DJ.DAVIES
SIRBU@Mit-Mc.ARPA ("Marvin A. Sirbu, Jr.") (05/12/84)
The domain style names are no more "addresses" than are IFIP style 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@deepthot.UUCP (Julian Davies) (05/17/84)
I gather this is quite a controversial topic in some USA circles.
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-hobbit.MLNET@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!julianREM@Mit-Mc.ARPA (Robert Elton Maas) (05/21/84)
In-Reply-To:deepthot!julian@seismo.ARPA Perhaps we shouldn't think in terms of a dichotomy between addresses and routes, nor even a trichotomy between names addresses and routes, but rather in terms of a whole continuem of names&addresses&routes from the most verbose nieve database query (even more verbose and/or sloppy than the IFIP proposal) to the most momentarily-optimum route. We can then think of a whole series of resolvers at each stage in this continuum, some of which are sticky (the answer is cached, like you jot down the phone number so you don't have to call 411 or 555-1212 again for the same number) while others are dynamic (it doesn't do much good to remember which IMP a packet passed through since due to varying loads the next packet may find that IMP constipated and take a more efficient route that avoids that IMP). Even stickiness may be a contimuum. Phone numbers change once every several years. Hops on USENET change every few weeks. Hops between Arpanet IMPs change on a minute by minute basis. Perhaps everything can be sticky for some time period, then recomputed after that? General database query: somebody who is interested in space exploration and has futuristic views, who has access to electronic mail. Unstructured name: Jerry Pournelle, science-fiction writer. IFIP name: Name=(Pournelle, Jerry), Country=USA, State=MA, City=Boston/Cambridge, Company=MIT, Dept=MC. Domain name: POURNE@MC.MIT.ARPA.DOD.USA Host address: ARPA 10.3.0.44 POURNE Possible route from here: DIALUP:(<secret phone number>, Bell212, <secret login JCL>, PCNET), USER#10.0.0.11 IMP#11,56,43,32,2, 21,34,4,25,24,12,55,47,14,18,10,44 SERVER#10.3.0.44 RCPT:POURNE (Sorry of those hops are out of date, I have 1980 Arpanet directory)