Robert.Ullmann@en-c06.x400.prime.COM (07/19/89)
Hi, [just to correct the record: > As we have discussed privately, I believe that your spec is > unworkable. I sent a draft to Mr Kille, whose reply began by dismissing my premise as "nonsense". I filed the response appropriately. This does not, to my mind, constitute "discussion"] To get on to actual discussion therefore: <grin> > I agree with you that the maintenace of tables is a pain. However, it is a > reality that the X.400 and 822 domain worlds are not under a single control. Okay, it is a problem. How about we fix it? The X.400 authority has already decreed that there will be a small number of X.400 ADMDs, in Europe it will typically be only one per country. So the necessary coordination consists of ensuring that: 1) 2nd level internet domains within top-level ISO-3166 ALPHA-2 domains do not use the ADMD names within that country. 2) that the proper MX record(s) be set up for the X.400 ADMDs at the positions in the DNS IN class that will be available because of (1) 3) the remaining top-level internet domains are mapped into an ISO-3166 code not used by the ADMDs, i.e. one of the extension codes. How do we accomplish this? It requires no action by the CCITT or ISO, it has been designed to require action only by the Internet. What is the proper procedure to propose such an action? Answer: prototype it, make sure it works, and submit an RFC. Which is exactly what I am doing. [I now resist the temptation to bash the rest of the note ...] Please consider: The internet is fully interconnected; mail can be routed between any two points without leaving the internet (I am including uucp systems that use domain names). If a local "pocket" of X.400 systems is connected by only one gate (or several under one administration), it can reasonably be using a table mapping; since there is no other route out. If all of X.400 consists only of such local pockets, connected by the internet, it continues to work. But, presumably, the intent is that X.400 will be as well self connected as the internet. This in turn means that there will be many thousands of contact points between the two, each one a gate that may pass traffic for any given target system. And only some of the mail directed to a given target will transit the gate(s) under that local administration. Most will go via the gate belonging to the sender. Another person on this list [whom I will not identify unless he gives me permission to reference private mail] has pointed out that the mapping(s) will not be "local": the tables will be shared throughout Europe. Let me point out that to the other 3 and 1/2 thousand million people on our planet, something used only in Europe is *local*! <wide grin> [enough for one note] Best Regards, Robert Ullmann Prime Computer
Stef@NRTC.NORTHROP.COM (Einar Stefferud) (07/19/89)
I can see that we are going to have a difficult time dealing with this proposal, mostly because the author has not done all the necessary homework, but is in a mood to bash all critical comment. Reminds me of the good old days of MsgGroup back in 1976-77, before we gained some measure of maturity in the matter of netmail discussion. Ther eis a basic fact that cannot be ignored: The X.400 domains and the Internet Domains are not under any kind of common central management control, and they are not likely to become so in any foreseeable future. In the US alone, we have not yet found an authoritative agent to deal with registration of ADMD/PRMD names, let alone found a way to get this unidentified authority to negotiate with the Internet, which has not even begun to come to grips with the issues of X.400 domain naming for its own PRMD segments. We don't enven know whther we have one or more than one PRMD in the Internet! So, if your proposal is based on the assumption that we only need to first estabish a single control point for all names, world wide, to resolve the mapping problem of the Internet=>X.400, I vote to stop discussing this whole thing right now! That ain't gonna happen folks! Now, having said that, I need to find some time to read the whole proposal to see if it is as unworkable as its author suggests by his energetic comments. Best...\Stef
piet@cwi.nl (Piet Beertema) (07/19/89)
The X.400 authority has already decreed "The" authority? Which authority? So the necessary coordination consists of ensuring that: 1) 2nd level internet domains within top-level ISO-3166 ALPHA-2 domains do not use the ADMD names within that country. It must be ensured that ADMD names within that country do not coincide with 2nd level internet domains already registered and in use in that country. X.400 is a newcomer that shouldn't interfere with the operation of a vast network (or set of networks) with which they'll desperately need to communicate. Piet
S.Kille@CS.UCL.AC.UK (Steve Kille) (07/19/89)
Robert, I believe your approach to be unworkable. In this context, it is difficult to formulate a positive reply. I sent you a longish message analysing the problems. I am sorry to hear that you simply "filed the response appropriately". The Domain hiearchies around the world are being populated rapidly, and in a pragmatic fashion. They tend to be research and communication oriented companies. The 3166 top level domains are (mostly) being used to build national services. They are not being left as a "bucket" for algorithmically derived X.400 addresses. More importantly, many parts of the "real domain" namespace will move to X.400, and wish to do so transparently. For this reason, you should not be able to tell whether an address maps to an 822 or X.400 UA. X.400 hierarchies are being allocated by PTTs and RPOAs. It is happening more slowly, and in a very differnet and ad hoc fashion. X.400 administrations will not in general look much to the domain namespace. You say "But, presumably, the intent is that X.400 will be as well self connected as the internet". I put it to you, that this is fundamental to X.400. More important, most of the X.400 world (providers at least) will not be interested in the Internet, and will not want to know about C=XA. Co-ordination of tables is a problem, and we have set up some initial mechanisms in Europe. The administration is hierarchical, and so it is easy to extend. If the tables get too large, the syntax is designed so that it can be easily supported by DNS. It is all quite workable. I note that a mapping very similar to what you propose is appropriate for SOME PARTS OF THE ADDRESS SPACE. For example, in the UK, under domain GB, we have (currenlty) defined: GOLD-400.GB <-> /ADMD=Gold 400/C=GB/ TMAILUK.GB <-> /ADMD=TMAILUK/C=GB/ AC.UK <-> /PRMD=UK.AC/ADMD=Gold 400/C=GB/ This will lead to algorithmic assignments for all of the new commercial stuff, but with a more natural mapping for the UK AC stuff. For some commercial orgs, we might define mappings onto the existing space. NPL.CO.UK <-> /O=NPL/PRMD=N-Net/ADMD= /C=GB/ Thus, there are "nice" mappings where the worlds overlap (at the cost of maintaining a few bindings), and algorithmic for the rest. If there are not MX records for this lot, there should be! But this is all caterd for in 987, and does not need a new spec! regards Steve
mark@cblpf.att.COM (Mark R Horton) (07/19/89)
I found Ariel's proposal interesting. It's technically fairly clean. However, it does seem to assume that the X.400 world will cooperate with it, and that the Internet is a fantasy network different from the real network today. I don't believe there is a GB Internet domain. I don't believe there are ADMD's in the US called MA and the other state names. I don't believe the X.400 world will honor requests from the XA country to be routed to the Internet. I don't believe that all countries have set up their Internet domain name spaces to look like OU.Org.PRMD.ADMD.Co . (In fact, I am not aware of any country that has done so.) And I don't believe that this gatewaying method has already been tested for years and found to work well in practice on the existing networks as a pragmatic solution. If all of these were true, and we didn't mind the funny "XA" country code, this proposal could be very nice. However, I'm not holding my breath for the assumptions to become true. Mark
GRZ027@DBNGMD21.BITNET (Peter Sylvester +49 228 8199645) (07/20/89)
> I don't believe that all countries have set up their Internet domain > name spaces to look like OU.Org.PRMD.ADMD.Co . (In fact, I am not > aware of any country that has done so.) > Well, one did. (there is a DBP.DE). This simply kind of mapping creates some semantical conflicts. X.400 management domains are routing hints: It seems that a better mapping of X400 addresses should be: @PRMD.ADMD.Co:user@Ou.Org.Co or @ADMD.Co:user@Ou.Org.PRMD.Co This is heretic, and I don't really hang on that. Peter Sylvester
Stef@NRTC.NORTHROP.COM (Einar Stefferud) (07/21/89)
Hi Peter -- You should not omit the fact that dbp.de also chooses on the X.400 side to omit the Org= attribute, so ... lt really looks like OU..PRMD.ADMD.Co .. /c=de/admd=dbp/prmd=organization/ou=suborg/ou=suborg/... How would this new proposal handle the missign ORG= attribute? Best...\Stef
GRZ027@DBNGMD21.BITNET (Peter Sylvester +49 228 8199645) (07/21/89)
> Hi Peter -- You should not omit the fact that dbp.de also chooses on the > X.400 side to omit the Org= attribute, so ... > > lt really looks like OU..PRMD.ADMD.Co .. > > /c=de/admd=dbp/prmd=organization/ou=suborg/ou=suborg/... > > How would this new proposal handle the missign ORG= attribute? After years it seems that I was beginning to believe what is constantly told here: the mapping choosen by DFN would allow a simple one to one mapping of attributes and domains. As long as you only look into one direction... - RFC987 handles the mapping problem in the appropriate way: If there is some "e-mail domain" connected to two different protocold worlds, then this "domain" gets two independant set of names/attributes and the fact that these two names define the mapping that has to be used in ALL gateways. - The internet domain space is supposed to be a hierarchical name space and routing should not be done just by looking at one component (well I know .BITNET and .UUCP .CSNET etc) In X.400 the admd may be usable as a "routing hint", at least in countries with more than one admd it makes sense to allow delivery either via the expensive and fast xyz or... A comparable functionality in the internet is source routing. Summary: Simple mapping - no way. Peter