From hagens Mon Feb 12 17:40:15 1990 Message-Id: <9002122340.AA17286@janeb.cs.wisc.edu> Received: from localhost by janeb.cs.wisc.edu; Mon, 12 Feb 90 17:40:15 -0600 To: pv@Eng.Sun.COM (Peter Vanderbilt) Cc: Stef@nrtc.northrop.com, ietf-osi-or, mhsig@nrtc.northrop.com, rasig@nrtc.northrop.com Subject: Re: MHS MD at Sonoma? In-Reply-To: Your message of Sat, 10 Feb 90 16:05:35 -0800. <9002110005.AA11511@polya.Eng.Sun.COM> Date: Mon, 12 Feb 90 17:40:10 CST From: hagens Status: O > There was also some discussion for the "ADMD name must match" rule that > ADMDs require of PRMDs. I suspect that the eventual outcome will be > that the P1 ADMD names must be "fixed" at the PRMD/ADMD boundary. This > would apply to the P1.originator ORName and possibly to those other P1 > ORNames that refer to the originating PRMD. P2 ORNames will probably > be left alone. It's not clear whether the responsibility for fixing > the names belongs to the ADMD or the PRMD. Yikes! This worries me. The problem is with a reply to such a message. I don't think one can rely on the UA using the P1.originator as the recipient of a reply. If I send a message from /PRMD=X/ADMD= /, and the ADMD sets the ADMD field to foobar in the P1 header, but does not munge the P2 header, then when the recipient builds a reply to my message, and they use the P2 originator as the reply-recipient, the message may be unreplyable due to the blank ADMD! Munging at P1 without munging at P2 may lead to some serious problems! Has anyone thought this out carefully? Disclaimer: I am not suggesting that we munge P2! Rather, I question the practice of munging P1 with a furrowed brow, Rob From stef@nma.com Tue Feb 13 04:16:52 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Tue, 13 Feb 90 04:16:52 -0600 Received: from nrtc.northrop.com by cs.wisc.edu; Tue, 13 Feb 90 04:16:39 -0600 Received: from nma.com by nrtc.nrtc.northrop.com id af04202; 13 Feb 90 2:16 PST Received: from localhost by nma.com id aa03209; 13 Feb 90 2:12 PST To: Khiem Ho Cc: hagens, pv@eng.sun.com, ietf-osi-or, mhsig@nrtc.northrop.com, rasig@nrtc.northrop.com Subject: Re: MHS MD at Sonoma? In-Reply-To: Your message of Mon, 12 Feb 90 16:51:15 -0800. <9002130051.AA07944@hpinddm.HP.COM> Reply-To: Stef@nrtc.northrop.com From: Einar Stefferud Date: Tue, 13 Feb 90 02:12:14 -0800 Message-Id: <3205.634903934@nma.com> Sender: stef@nma.com Status: RO >It's very clear in the IAOG Guidelines (IAOG consisting of international >ADMDs) that PRMD must make sure the P1.originator name contains the >ADMD/PRMD names of the ADMD/PRMD boundary. This is a real unfortunate >burden on the PRMD connecting to multiple ADMDs, given that ADMDs are >not all interconnected. Delivery Reports and replies will get lost. > >I am curious whether the PRMD community can do anything to remove this >constraint. Any suggestions? > >Khiem Ho Hewlett-Packard khiem@hpinddm.HP.COM This is the kind of result that we obtain from letting the ADMDs dictate all the rules for the combined PRMD/ADMD MTS in /C=US/. The IAOG has put forth what they want, for their own private reasons. It is time for the PRMDs to put forth what they want for their own private reasons. We are all in this together, and we need a compromise that will work in real operations. What the ADMDs have put into the IAOG scheme is not going to work in the real world, so we better do something about it. On the other hand, those ADMDs that hold tough on this issue are going to find themselves doing less business than those who yield to reality. And, if the ADMDs hold tough, they may just find that the PRMDs will organize a PRMD to bypass them all, sicne they don't seem to want to provide the services they are supposed to offer -- Namely Roting and Switching. It should be obvious that the PRMDs can find alternatives! All we need is for some ADMD class operator to offer PRMD-to-PRMD tranfer service as a PRMD. I can think i\of several that will be pleased to have the ADMDs hold out and leave them with a market to tap. In other words, if we cannot work with them, we will have to work without them. In the end, the MARKET will decide in any case. Them as refuse to serve will get what they want -- the opportunity to not serve. Cheers...\Stef From S.Kille@cs.ucl.ac.uk Tue Feb 13 07:20:49 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Tue, 13 Feb 90 07:20:49 -0600 Received: from bells.cs.ucl.ac.uk by cs.wisc.edu; Tue, 13 Feb 90 07:19:33 -0600 Received: from lion.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id aa10276; Tue, 13 Feb 90 13:18:05 +0000 To: hagens Cc: Peter Vanderbilt , Stef@nrtc.northrop.com, ietf-osi-or, mhsig@nrtc.northrop.com, rasig@nrtc.northrop.com Subject: Re: MHS MD at Sonoma? Phone: +44-1-380-7294 In-Reply-To: Your message of Mon, 12 Feb 90 17:40:10 -0600. <9002122340.AA17286@janeb.cs.wisc.edu> Date: Tue, 13 Feb 90 13:19:14 +0000 Message-Id: <1171.634915154@UK.AC.UCL.CS> From: Steve Kille Status: O I agree with Rob. Having P1 and P2 different is bound to cause problems. I think that there are times when it is correct to alter the MTA O/R Address (the extension number is a unique reference, and so you should be able to do this safely, even tho ADMDs such as Atlas object). So, lets design a strategy where this is not needed too much. In passing, note that the P2 addresses cannot in general be changed, as they may be end to end encrypted. Whilst I'm writing, let me comment on the "+" convention for PRMD. I think that this is a hack. Effectively, you are trying to introduce a hierarchy into PRMD. This would be better done by a separate attribute. Why not introduce a DD attribute (e.g., Sub-PRMD) to achieve this. Do we need this at all? One of the nastiest bits of X.400 addressing is all this user hostile PRMD stuff. We should be trying to have as little MD type addressing as possible. Steve From pv@Eng.Sun.COM Tue Feb 13 20:48:56 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Tue, 13 Feb 90 20:48:56 -0600 Received: from Sun.COM by cs.wisc.edu; Tue, 13 Feb 90 20:48:31 -0600 Received: from Eng.Sun.COM (exodus-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA22695; Tue, 13 Feb 90 18:48:22 PST Received: from polya.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA27089; Tue, 13 Feb 90 18:48:29 PST Received: by polya.Eng.Sun.COM (4.0/SMI-4.0-MHS-6.0) id AA14732; Tue, 13 Feb 90 18:48:06 PST Date: Tue, 13 Feb 90 18:48:06 PST From: pv@Eng.Sun.COM (Peter Vanderbilt) Message-Id: <9002140248.AA14732@polya.Eng.Sun.COM> To: hagens Subject: Re: MHS MD at Sonoma? Cc: ietf-osi-or, mhsig@nrtc.northrop.com, rasig@nrtc.northrop.com Status: O > From: hagens@cs.wisc.edu > > There was also some discussion for the "ADMD name must match" rule that > > ADMDs require of PRMDs. [...] > > Yikes! This worries me. Me too. That's why I brought it up. > Disclaimer: I am not suggesting that we munge P2! Rather, I question > the practice of munging P1 with a furrowed brow, I too suspect this munging of addresses has not been thought out and may lead to all sorts of problems. It's not clear to me that munging of addresses is even permitted by the standards. I'm probably going to regret this, but let me give you my interpretation of one ADMD operator's reason for the "ADMD name must match" rule: They (1) need to bill the originating PRMD and (2) they want to be sure non-delivery reports are returned to the sender. They see the blank ADMD as meaning "any ADMD" and may be willing to have complete PRMD tables for the US, so the ADMD name matching rule does not come from wanting simpler routing tables. To see (1), assume mail goes from PRMD P1 to ADMD A1 to ADMD A2 to PRMD P2. A2 doesn't have a contract with P1 so he has to bill A1 (which will bill P1). Thus when mail goes from A1 to A2, the originator's ADMD field must be right so that on delivery to P2, A2 knows who to send the bill to. To see (2), assume that a non-delivery occurs at P2. If there's no ADMD name for the originator, there's no guarantee that the non-delivery report will come back to A1. If it goes to some other ADMD, (say A3) the non-delivery might be dropped (like if P1's contract with A3 has expired). Even if the non-delivery is sent on to P1 correctly, A3 gets stuck with the cost of transferring the NDN (the ADMDs have agreed not to charge each other for service reports, like NDNs). Thus they want the ADMD name in the originator ORAddress as a kind of reverse path. I may have this wrong, but it gives us something to think about. Let me continue to play devil's advocate. > The problem is with a reply to such a message. > I don't think one can rely on the UA using the P1.originator as the > recipient of a reply. They don't expect this. > If I send a message from /PRMD=X/ADMD= /, and the ADMD sets the ADMD > field to foobar in the P1 header, but does not munge the P2 header, > then when the recipient builds a reply to my message, and they use the > P2 originator as the reply-recipient, the message may be unreplyable > due to the blank ADMD! Of course, if you don't munge the P1, the same problem exists. An ADMD in another country interprets the " " ADMD as meaning "any ADMD" and passes the message on to his favorite ADMD in the US. As long as the US ADMDs are interconnected and have complete tables for all PRMDs that use the ADMD " ", the message will eventually get to its destination and the originator will be correctly billed. > From: Khiem Ho > I am curious whether the PRMD community can do anything to remove this > constraint. Any suggestions? Back to my own opinions: I'd like to see a PRMD consortium that provides for interconnectivity with requiring the use of ADMDs. The ADMDs would not be excluded, just not required. The consortium would provide a list of PRMDs, their X.400 domain name, addressing info and MTA name/password. This list would be accessable using FTAM, X.400 (as a mailing list) and other protocols as appropriate. Thus any member of the group could communicate with any other member without any fancy bilateral agreements or the use of ADMDs. Of course, there are lot's of details to work out... Pete From S.Kille@cs.ucl.ac.uk Fri Feb 16 05:52:34 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Fri, 16 Feb 90 05:52:34 -0600 Received: from bells.cs.ucl.ac.uk by cs.wisc.edu; Fri, 16 Feb 90 05:52:24 -0600 Received: from lion.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id aa27832; Fri, 16 Feb 90 11:50:23 +0000 To: Stef@nrtc.northrop.com Cc: hagens, Peter Vanderbilt , ietf-osi-or, mhsig@nrtc.northrop.com, rasig@nrtc.northrop.com Subject: Re: MHS MD at Sonoma? Phone: +44-1-380-7294 In-Reply-To: Your message of Tue, 13 Feb 90 11:46:08 -0800. <3863.634938368@nma.com> Date: Fri, 16 Feb 90 11:51:23 +0000 Message-Id: <964.635169083@UK.AC.UCL.CS> From: Steve Kille Status: O I'd like to see a model where PRMDs are large - corresponding to large Organisations and communities of Interest. Acme Brush Co should not be in the business of running an MD. It should pay someone to do it. An MD should be a message service provider, and not a second representation of the Organisation. Given this model, the number of MDs (ADMD or PRMD) is managable - even for alarg country , and a simple flat registration can be used. Steve From stef@nma.com Fri Feb 16 10:36:46 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Fri, 16 Feb 90 10:36:46 -0600 Received: from nrtc.northrop.com by cs.wisc.edu; Fri, 16 Feb 90 10:36:37 -0600 Received: from nma.com by nrtc.nrtc.northrop.com id aa07340; 16 Feb 90 8:36 PST Received: from localhost by nma.com id aa09109; 16 Feb 90 8:33 PST To: Steve Kille Cc: hagens, Peter Vanderbilt , ietf-osi-or, mhsig@nrtc.northrop.com, rasig@nrtc.northrop.com Subject: Re: MHS MD at Sonoma? In-Reply-To: Your message of Fri, 16 Feb 90 11:51:23 +0000. <964.635169083@UK.AC.UCL.CS> Reply-To: Stef@nrtc.northrop.com From: Einar Stefferud Date: Fri, 16 Feb 90 08:32:52 -0800 Message-Id: <9104.635185972@nma.com> Sender: stef@nma.com Status: O >Given this model, the number of MDs (ADMD or PRMD) is managable - even >for alarg country , and a simple flat registration can be used. Steve If there is only a small need for the construction syntax, then there will not be many names with the +sign in them, but for the few that need it will have it available to them. The problem is that if it is not available, even a small need (10-50% perhaps) becomes excruciating. Constraining the number of PRMDs by avoiding a way for anyone who wants one to get one, because of the difficulties on name registration is the wrong place to put the constraints. Best...\Stef From karl@asylum.sf.ca.us Fri Feb 16 13:32:54 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Fri, 16 Feb 90 13:32:54 -0600 Received: from GENBANK.BIO.NET by cs.wisc.edu; Fri, 16 Feb 90 13:32:35 -0600 Received: from asylum.UUCP by genbank.bio.net (5.61/1.15) with UUCP id AA16352; Fri, 16 Feb 90 11:32:25 -0800 Received: by asylum.sf.ca.us (smail2.5x) id AA08188; 16 Feb 90 10:53:50 PST (Fri) To: S.Kille@cs.ucl.ac.uk Cc: Stef@nrtc.northrop.com, hagens, pv@eng.sun.com, ietf-osi-or, mhsig@nrtc.northrop.com, rasig@nrtc.northrop.com In-Reply-To: Steve Kille's message of Fri, 16 Feb 90 11:51:23 +0000 <964.635169083@UK.AC.UCL.CS> Subject: Little MDs, Was: MHS MD at Sonoma? Message-Id: <9002161053.AA08175@asylum.sf.ca.us> Date: 16 Feb 90 10:53:44 PST (Fri) From: karl@asylum.sf.ca.us (Karl Auerbach) Status: O > I'd like to see a model where PRMDs are large - corresponding to large > Organisations and communities of Interest. Acme Brush Co should not be > in the business of running an MD. It should pay someone to do it. "They" used to say the same thing about telephone systems. But now, at least here in the US, it is quite common even for relatively small companies to internalize systems of this nature. (The reasons given are typically "control", security, "we're doing a technology pilot", "it's my empire and I'll do what I want to", etc. In other words, the basic economics may have little to do with the decision.) Many small domains ought to be expected. --karl-- From karl@asylum.sf.ca.us Fri Feb 16 13:33:05 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Fri, 16 Feb 90 13:33:05 -0600 Received: from GENBANK.BIO.NET by cs.wisc.edu; Fri, 16 Feb 90 13:32:52 -0600 Received: from asylum.UUCP by genbank.bio.net (5.61/1.15) with UUCP id AA16343; Fri, 16 Feb 90 11:32:23 -0800 Received: by asylum.sf.ca.us (smail2.5x) id AA08175; 16 Feb 90 10:53:44 PST (Fri) To: S.Kille@cs.ucl.ac.uk Cc: Stef@nrtc.northrop.com, hagens, pv@eng.sun.com, ietf-osi-or, mhsig@nrtc.northrop.com, rasig@nrtc.northrop.com In-Reply-To: Steve Kille's message of Fri, 16 Feb 90 11:51:23 +0000 <964.635169083@UK.AC.UCL.CS> Subject: Little MDs, Was: MHS MD at Sonoma? Message-Id: <9002161053.AA08175@asylum.sf.ca.us> Date: 16 Feb 90 10:53:44 PST (Fri) From: karl@asylum.sf.ca.us (Karl Auerbach) Status: O > I'd like to see a model where PRMDs are large - corresponding to large > Organisations and communities of Interest. Acme Brush Co should not be > in the business of running an MD. It should pay someone to do it. "They" used to say the same thing about telephone systems. But now, at least here in the US, it is quite common even for relatively small companies to internalize systems of this nature. (The reasons given are typically "control", security, "we're doing a technology pilot", "it's my empire and I'll do what I want to", etc. In other words, the basic economics may have little to do with the decision.) Many small domains ought to be expected. --karl-- From S.Kille@cs.ucl.ac.uk Wed Feb 21 03:08:44 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 21 Feb 90 03:08:44 -0600 Received: from bells.cs.ucl.ac.uk by cs.wisc.edu; Wed, 21 Feb 90 03:08:28 -0600 Received: from lion.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id aa05869; Wed, 21 Feb 90 9:03:23 +0000 To: Karl Auerbach Cc: Stef@nrtc.northrop.com, hagens, pv@eng.sun.com, ietf-osi-or, mhsig@nrtc.northrop.com, rasig@nrtc.northrop.com Subject: Re: Little MDs, Was: MHS MD at Sonoma? Phone: +44-1-380-7294 In-Reply-To: Your message of Fri, 16 Feb 90 10:53:44 -0800. <9002161053.AA08175@asylum.sf.ca.us> Date: Wed, 21 Feb 90 09:04:26 +0000 Message-Id: <620.635591066@UK.AC.UCL.CS> From: Steve Kille Status: O This is a very good point you make. It is quite conceivable that the world could go this way. The real problem is how to provide MHS service in small organisations. Let me show a slightly different scenario to yours (one MD per org, with small MDs using ADMD swtiching). ADMDs are in the business of international message switching. These will be big oprations, and not so many of them. Some large Organisations will choose to operate PRMDs, just as some choose to operate telephone networks. This will give them the flexibilty of private interconnects and avoiding ADMDs as they choose. Most PRMDs will be run by MHS providing organisations. They will provide national and closed community message switching services. They will compete with ADMDs for national traffic, whilst not engaging in (general) international switching. An organisation will still be able to have an internal and autonomous message service (this is not any nonsense about centralised mailboxes). The PRMD will provide routing services, quite likely by private download or routing tables to the organisation. They will be able to undercut ADMD services for private interconnect. I think that this is a much more useful scenario, rather than having the PRMD equivalent to the Organisation. This concludes back to my orignal point. The number of PRMDs will be managable, and the "+" convention is not needed. Steve From stef@nma.com Wed Feb 21 13:57:29 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 21 Feb 90 13:57:29 -0600 Received: from nrtc.northrop.com by cs.wisc.edu; Wed, 21 Feb 90 13:57:14 -0600 Received: from nma.com by nrtc.nrtc.northrop.com id aa14943; 21 Feb 90 11:55 PST Received: from localhost by nma.com id aa16049; 21 Feb 90 11:41 PST To: Steve Kille Cc: Karl Auerbach , hagens, pv@eng.sun.com, ietf-osi-or, mhsig@nrtc.northrop.com, rasig@nrtc.northrop.com Subject: Re: Little MDs, Was: MHS MD at Sonoma? In-Reply-To: Your message of Wed, 21 Feb 90 09:04:26 +0000. <620.635591066@UK.AC.UCL.CS> Reply-To: Stef@nrtc.northrop.com From: Einar Stefferud Date: Wed, 21 Feb 90 11:40:44 -0800 Message-Id: <16044.635629244@nma.com> Sender: stef@nma.com Status: O Hi Steve -- Yoru model has some real difficulties in realization in the real world of the USA. Your conclusion seems to be that we should avoid the +sign construction rules because demand for +sign constructed names SHOULD be small. This means that we SHOULD agree to avoid facilitation of easy anming for small MHS MDs, and thus promote only large MHS MDs that are able to abtain national names. Thus, because of naming difficulties, using organizations should find ways to band together to form larger MHD MDs! This is entirely theto do is ceate an unnatural monopoly for PRMDs that can get national names. Now, of course, anyone with enough invetniveness can get a national name, as long as they don't necessarily have to use the name they have already established in a non-national locality. But, why should us techies be imposing such monopolistic obstacles on the world, just because the CCITT gave us a set of addressing rules for INTERNATION mail transfers which screw up lots of things in sub-national localities. As I view this whole situation, what I see happening is that the PRMD operators will come to realize that they do not really need the ADMDs, since they can always form alliances of PRMDs, and can even form a RELAYING PRMD which only provides relay services for other PRMDs, with connection to ADMDs for transfers that require ADMD carriage. Moves along this line are already in motion. Indeed, the INTERENT is exactly one such operation, and it is going to be an internetional PRMD (in reality). I only wish there was some way for the INTERNET to obtian the same PRMD name in every country. Unfortunately, there is no supra-national agency that can facilitate such a thing. I do note however, that the IAOG blessed the idea of the Supra-PRMD, though tey did not explain any of how it will actually work. So, my bottom line, after all these words, is that we should enable the +sign construction rules to ease the pain of naming problems and let the market decide how things should be organized. Best...\Stef From hpda!hplabs!khiem%hpinddm.hp.com@uunet.UU.NET Wed Feb 21 21:10:44 1990 Received: from spool.cs.wisc.edu by janeb.cs.wisc.edu; Wed, 21 Feb 90 21:10:44 -0600 Received: from uunet.UU.NET by spool.cs.wisc.edu; Wed, 21 Feb 90 21:10:16 -0600 Received: from hpda.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA24119; Wed, 21 Feb 90 22:09:39 -0500 Received: by hpda.HP.COM; Mon, 12 Feb 90 19:16:37 pst Received: from hplabs with uucp; Mon, 12 Feb 90 16:50:13 Received: from hpda.cup.hp.com by hplabs.hpl.hp.com with SMTP (15.11.1.3/15.5+IOS 3.14) id AA21254; Mon, 12 Feb 90 16:50:13 pst Received: from hpinddm.HP.COM by hpda.HP.COM; Mon, 12 Feb 90 16:46:42 pst Received: by hpinddm.HP.COM; Mon, 12 Feb 90 16:51:15 pst Date: Mon, 12 Feb 90 16:51:15 pst From: Khiem Ho Message-Id: <9002130051.AA07944@hpinddm.HP.COM> To: hagens@spool.cs.wisc.edu, pv@Eng.Sun.com Subject: Re: MHS MD at Sonoma? Cc: Stef@nrtc.northrop.com, ietf-osi-or@spool.cs.wisc.edu, mhsig@nrtc.northrop.com, rasig@nrtc.northrop.com Status: O >> There was also some discussion for the "ADMD name must match" rule that >> ADMDs require of PRMDs. I suspect that the eventual outcome will be >> that the P1 ADMD names must be "fixed" at the PRMD/ADMD boundary. This >> would apply to the P1.originator ORName and possibly to those other P1 >> ORNames that refer to the originating PRMD. P2 ORNames will probably >> be left alone. It's not clear whether the responsibility for fixing >> the names belongs to the ADMD or the PRMD. > >Yikes! This worries me. The problem is with a reply to such a message. I don't >think one can rely on the UA using the P1.originator as the recipient of a reply. It's very clear in the IAOG Guidelines (IAOG consisting of international ADMDs) that PRMD must make sure the P1.originator name contains the ADMD/PRMD names of the ADMD/PRMD boundary. This is a real unfortunate burden on the PRMD connecting to multiple ADMDs, given that ADMDs are not all interconnected. Delivery Reports and replies will get lost. I am curious whether the PRMD community can do anything to remove this constraint. Any suggestions? Khiem Ho Hewlett-Packard khiem@hpinddm.HP.COM From stef@nma.com Wed Feb 21 23:36:20 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 21 Feb 90 23:36:20 -0600 Received: from nrtc.northrop.com by cs.wisc.edu; Wed, 21 Feb 90 23:36:11 -0600 Received: from nma.com by nrtc.nrtc.northrop.com id ab18192; 21 Feb 90 21:35 PST Received: from localhost by nma.com id aa17047; 21 Feb 90 20:26 PST To: rasig@nrtc.northrop.com, mhsig@nrtc.northrop.com Subject: March 12-13 Options for MHS MD Working Group Meeting at NIST Reply-To: Stef@nrtc.northrop.com From: Einar Stefferud Date: Tue, 20 Feb 90 15:40:45 -0800 Message-Id: <14967.635557245@nma.com> Sender: stef@nma.com Resent-To: ietf-osi-or Resent-Date: Wed, 21 Feb 90 20:26:00 -0800 Resent-Message-Id: <17044.635660760@nma.com> Resent-From: Einar Stefferud Status: O Per various mentions of plans for an MHS MFrom stef@nma.com Wed Feb 21 23:36:09 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 21 Feb 90 23:36:09 -0600 Received: from nrtc.northrop.com by cs.wisc.edu; Wed, 21 Feb 90 23:35:58 -0600 Received: from nma.com by nrtc.nrtc.northrop.com id aa18192; 21 Feb 90 21:35 PST Received: from localhost by nma.com id aa16992; 21 Feb 90 20:14 PST To: Khiem Ho Cc: hagens, pv@eng.sun.com, ietf-osi-or, mhsig@nrtc.northrop.com, rasig@nrtc.northrop.com Subject: Re: MHS MD at Sonoma? In-Reply-To: Your message of Mon, 12 Feb 90 16:51:15 -0800. <9002130051.AA07944@hpinddm.HP.COM> Reply-To: Stef@nrtc.northrop.com From: Einar Stefferud Date: Wed, 21 Feb 90 20:13:51 -0800 Message-Id: <16988.635660031@nma.com> Sender: stef@nma.com It is my understanding that the IAOG positon on this matter ... >It's very clear in the IAOG Guidelines (IAOG consisting of >international ADMDs) that PRMD must make sure the P1.originator name >contains the ADMD/PRMD names of the ADMD/PRMD boundary. This is a real >unfortunate burden on the PRMD connecting to multiple ADMDs, given that >ADMDs are not all interconnected. Delivery Reports and replies will get >lost. ... is only binding in the default case where there is no bilateral or multilateral agreement among two or more ADMDs to accept mail from each other with a different value for the /ADMD=/ attribute. Also, the referenced IAOG default requirement only speaks to the ADMD-ADMD transfers, adn does not speak to any PRMD-ADMD transfers, although it is hard to see how any ADMD without an alternative agreement with other ADMDs can handle acceptance of mail with any other /ADMD=/ attribute. >I am curious whether the PRMD community can do anything to remove this >constraint. Any suggestions? Khiem Ho Hewlett-Packard One idea I have is to work on ways to explain to the ADMDs how they can achive their goals without the IAOG default constraints. I know that some ADMDs have coem around to rtealizing that they really don't require that "the P1.originator name contains the ADMD/PRMD names of the (originator's) ADMD/PRMD boundary" becasue the problem can be solved with shared routing tables. Another suggestion is that the PRMDs organize to form a Relaying-PRMD that will deal with all their inter-PRMD mail, and so bypass the ADMDs umtil the ADMDs learn to deal with things in a more reasonable way. I know that a fair number of PRMDs already think that they need to do this, since they have had such bad experiences with the US based ADMDs. So, lets put pressure on the ADMD community to accept the reality that making "the P1.originator name contains the ADMD/PRMD names of the (originator's) ADMD/PRMD boundary" when the originator's PRMD is attached to more than one ADMD is a very bad idea. Among the bad effects is that every user subject to such treatment will then have as many different addresses as their PRMD has connections to ADMDs! UGH! Best...\Stef From stef@nma.com Wed Feb 21 23:37:28 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 21 Feb 90 23:37:28 -0600 Received: from nrtc.northrop.com by cs.wisc.edu; Wed, 21 Feb 90 23:37:16 -0600 Received: from nma.com by nrtc.nrtc.northrop.com id ac18192; 21 Feb 90 21:35 PST Received: from localhost by nma.com id aa17054; 21 Feb 90 20:26 PST To: rasig@nrtc.northrop.com, mhsig@nrtc.northrop.com Subject: Draft Text for MHS MD Meeting at NIST OIW in March, 1990 Reply-To: Stef@nrtc.northrop.com From: Einar Stefferud Date: Tue, 20 Feb 90 21:09:47 -0800 Message-Id: <15349.635576987@nma.com> Sender: stef@nma.com Resent-To: ietf-osi-or Resent-Date: Wed, 21 Feb 90 20:26:29 -0800 Resent-Message-Id: <17051.635660789@nma.com> Resent-From: Einar Stefferud Status: O This is the formal mailing of our text to be considered at the MHS MD Meeting to be held at the NIST OIW Meeting on March 12-16. An MHS MD Working Group Meeting is tentatively planned for Mon-Tue, March 12-13. Further details will be posted to the MHSIG and RASIG mailing lists as plans develop. It currently appears that we will have a small group. Meeting Location: NIST Administration Building, Gaithersburg, MD MHS MD Group Meeting Room to be posted at the meeting. Meeting Fees: $180 for Weekly Registration AFTER Feb 23, 1990, or OnSite $120 for Daily Registration AFTER Feb 23, 1990, or OnSite $150 Weekly for PreRegistration BEFORE February 23, 1990 $120 Daily for PreRegistration BEFORE February 23, 1990 $25 for Wednesday Evening Plenary Banquet Hotel Accommodations: SHERATON POTOMAC, 3 Research Court Rockville, MD 20850 Double/Single FON: 800-638-8559 or 301-840-0200 $43.00/Night FAX: 301-258-0160 +++++++++++++++++++++++ TEXT FOR CONSIDERATION +++++++++++++++++++++++++++ PROPOSAL FOR CONSTRUCTION OF PRMD NAMES FROM ANSI REGISTERED OSI ORGANIZATIONAL NAMES Contribution to NIST MHSIG from MHSIG MHS MD Breakout Group. Prepared on 14 Dec 1989 by Stef. Edited on 26 Jan 1990 by P. Vanderbilt Edited on 10 Feb 1990 by P. Vanderbilt BACKGROUND ANSI is very close to positioning itself to register OSI Organization names in the United States of America. This US Register already has entries for the 50 States, the District of Columbia, and the Outlying Areas of the US, plus an entry for the US Govt and for ANSI itself. The US Register provides for registration of names for organizations that have national standing for the right to use the names for which applications to register are submitted. Organizations that are not yet registered may apply to register chosen OSI names under a procedure for requesting a name to be registered, with a waiting period for challenges of the right of the applicant to use the chosen name, and a challenge process for handling disputes regarding the right of any applicant to use any chosen name. These ANSI procedure documents are identified in the following citations. [1] The top-level document, Procedures for Registering Names in the United States of America, 5 December 1989. [2] Procedures for Registering Names for American National Standards, 5 December 1989. [3] Procedures for Registering Organization Names in the United States of America, 5 December 1989. [4] U.S. Register of Names, of ANSI, of the Federal Government and of the States, the District of Columbia, and the Outlying and Associated Areas of the United States for Information Interchange, September 27, 1989. The key result of these procedures is that there will now be a pool of registered OSI names for the US from which we may now draw unique names for use as ADMD and PRMD values in X.400 ORNames(84) and ORAddresses(88). It is important to recall here that the NIST 1987 agreements for X.400(84) call for all PRMD Names in /C=US/ to be unique over the entire United States of America, regardless of any ADMD with which the PRMD name may be registered. This is required to deal with the need for shared routing information in a country with more than one ADMD. The concept is also recommended by CCITT in the X.400(88) Bluebook. So, it would seem that all is in order, now that we have ANSI acting as a US Registration Authority to provide a pool of unique names for use as PRMD names. ANSI OSI Organization Names might well be used as X.400 ORName ORG values as well, but we do not have a mandatory requirement for this in any NIST or other agreements anywhere. But, we have a serious problem remaining where an applicant for a name does not have National Standing and cannot withstand the challenge procedures of ANSI for their chosen name. For example, a company that only has standing in one, or a few, of the 50 States. There are many more of these organizational entities than there are that have National Standing for the use of their names. Therefore, it seems that we must arrange some way for lesser standing organizations to obtain a PRMD name that is unique as required by the NIST 1987 X.400(84) Implementation Agreements. PROPOSAL It is therefore proposed that a "Construction Syntax" be defined, starting with registered OSI organization names under the US Register. The idea is that combinations (by concatenation) will be guaranteed to be unique, and thus be safely used as PRMD names. PRMD and ADMD names shall be constructed from the following Extended BNF grammar: ::= | ::= | | ::= "+" subject to all of the following rules: Rule 1. The entire or must not exceed 16 bytes and shall be composed entirely of PrintableString characters. Rule 2. shall be drawn from the numeric name forms registered by ANSI in the US Register. The number will be represented in decimal with no blanks and can encoded in ASN.1 as either a NumericString or PrintableString. Rule 3. shall be drawn from the alphanumeric names registered by ANSI in the US Register, shall contain at least one non-numeric character and shall not contain the plus sign (+) (which is used as a construction separator). Rule 4. The registered shall be certified to be unique under the (sub)authority. Rule 5. Whether a PRMD shall be named by only one PrivateDomainName is for further study. Rule 6. A PRMD's PrivateDomainIdentifier shall be the same as its PrivateDomainName. Note 1: The PRMD names resulting from the syntax (those having a "+" in them) are atomic values from the point of view of the MTA -- in particular, it is not permissible for the MTA to route on components of the PRMD name. Note 2: The construction rules are such that if ABC is a registered national organization name, then the owner of that name controls the space of domain names including "ABC" and "ABC+" but not "ABCD". Note 3: If the subauthority determined by so wishes, the can be constructed using rules similar to the above, resulting in a hierarchical naming structure separated by "+"s. In particular, the subauthority can maintain its own registry and define the using the syntax ::= | "+" where the is drawn from the subauthority's registry (and does not contain a "+"). Thus the subauthority can delegate the use of the prefix + to someone else. ------- END PROPOSAL FOR CONSTRUCTION OF PRMD NAMES -------- Contribution for Consideration at the March 1990 OIW at NIST From hagens Mon Mar 12 10:11:29 1990 Message-Id: <9003121611.AA18802@janeb.cs.wisc.edu> Received: from localhost by janeb.cs.wisc.edu; Mon, 12 Mar 90 10:11:29 -0600 To: ietf-osi-or Subject: Summary of Feb Meeting Date: Mon, 12 Mar 90 10:11:28 CST From: hagens Status: O CURRENT MEETING REPORT OSI-X.400 WORKING GROUP SUMMARY OF THE MEETING FEB 7, 1990 The meeting was convened by chairman Rob Hagens. An attendance list will be published with the Proceedings of the IETF. The group (much smaller than the last meeting) began the meeting by discussing the sort of address structure required when X.400/MHS is introduced into the Internet. The group concluded that there is no need to design or define an interm/transition address structure. RFC 987/1138 defines an acceptable transition structure: the RFC-822 domain defined attribute. There was some discussion about the lack of widespread support for DDAs. It appears that most ADMD providers support DDAs in their MTAs, however there may be user agents that do not support the entry of DDAs. The general feeling was that this was a shortcoming of the specific user agents; it could be corrected. It should not effect the organization of the NREN X.400/MHS service. After this, the group discussed the need for a PRMD authority for the NREN. Note: the group's definition of NREN is the US portion of the IP-connected Internet. Several points were discussed: + An NREN PRMD is a long term solution for certain organizations. + Organizations may "grow out" of the NREN PRMD and register elsewhere. + As X.400 software is deployed within the NREN, we need to organize a coherent MTS before chaos decends. + We must provide cheap and quick registration services for the NREN PRMD. + The NREN PRMD may negotiate with US ADMDs for international service. Such negotiations must be on the basis of originator keeps all revenue. + The NREN PRMD may relay traffic for other PRMDs + An NREN PRMD must provide a registration service as well as manage operational connectivity (i.e., routing). + The 'ole ADMD field question: there is a general desire to keep the ADMD field blank. Many ADMD providers require the ADMD field to contain the name of the ADMD. Should the NREN PRMD automatically fill in the ADMD field? One suggestion was that within the US, the ADMD field should be kept blank, but international traffic would have the ADMD field set as the message leaves the country. Some discussion of munging P1.originator vs. P2.originator ensued. Is that a protocol violation? How does it effect security? How does it effect a "reply"? + The question was raised as to whether the NREN could register itself as an ADMD. The answer was not known. + Creation of 987/1138 mapping tables for members of the NREN PRMD was considered a good thing. Non-members could relay traffic into and out of the PRMD via DDAs. + The operation of the NREN PRMD will not be free. There is a need to fund a few people who will organize and operate the PRMD. The group agreed that a document must be written which describes the responsibilities and operational aspects of the NREN PRMD. A tentative title for this document is "Transition and long term strategy for operation of X.400/MHS in the NREN". I hope to have a preliminary draft of this document by the end of March. James Galvin (of TIS), offered to draft an outline. At the end of the meeting, Professor Kirstein from UCL described his interest in promoting and experimenting with ODA. He has access to implementations of ODA that may be utilized by an Internet-ODA-X.400 experiment. There are no proposed experiments at this time. Any one interested in any Internet-ODA-X.400 experiments should contact Professor Kirstein or an OSI area director. From cargille@rivendell.cs.wisc.edu Wed Jun 13 13:08:44 1990 Received: from rivendell.cs.wisc.edu by janeb.cs.wisc.edu; Wed, 13 Jun 90 13:08:44 -0500 From: cargille@rivendell.cs.wisc.edu (Allan Cargille) Message-Id: <9006131808.AA03178@rivendell.cs.wisc.edu> Received: by rivendell.cs.wisc.edu; Wed, 13 Jun 90 13:08:42 -0500 Subject: Internet-style addresses for U.S. X.400 users To: ietf-osi-or (ietf osi o/r names) Date: Wed, 13 Jun 90 13:03:06 CDT X-Mailer: ELM [version 2.2 PL13] Status: O Hello, below is an issue that I would welcome comments on. The issue is summarized best by my email to Steve Kille (below). I enclose his response as well. We are hoping to make a preliminary decision for our pilot project soon to start to gain real-world experience. Of course, the approach taken for our project will not necessarily be adopted for the U.S. X.400 effort. This may bear discussion at the Vancouver IETF. Thanks! allan > Date: Wed, 13 Jun 90 16:02:46 +0200 > From: Allan Cargille > Subject: U.S. RFC987 mapping table entries > To: steve kille > Cc: "RARE R&D MHS Managers" , > "RARE WG1" > > Hello Steve, > > I'm doing X.400 work at the University of Wisconsin with Larry > Landweber and Rob Hagens. I've successfully established international > X.400 connections (over RFC1006/tcp/ip) with Norway, France, and > England (with Tony Bates). I've been reading your messages to > rare-wg1 and the rd-mhs-managers mailing list since last October. I > was hoping to get your input about an important question facing the U.S. > > My current task is to complete the U.S. documentation of our > experimental X.400 service for the RARE R&D MHS Managers, so that we > are officially part of the RARE project. I have completed the > documents just fine except for one part -- defining the national RFC987 > mapping tables. Of course you are aware that the RARE project is > registering what I call "pseudo-domains" in order to create > Internet-style addresses that actually map to X.400 addresses. The > U.S. needs to either subscribe to their policy and create new portions > of the DNS which will actually be MX records that point to RFC987 > mail-relays, or seek other solutions. This would mean creating a > domain like xnren.us or xnren.x400.us . > > Two other alternatives that I have considered seriously are > > 1. Every organization using X.400 must operate it's own RFC987 mail-relay. > I don't like this solution. It does not require creating any new DNS > domains, but it requires an entry in the RFC987 mapping tables for every > organization. I'm afraid that the tables may grow unmanageable large. > I also don't like to require each site to operate a RFC987 mail-relay. > > 2. Modify the DNS at the leaf nodes. For example, under cs.wisc.edu > we could create an MX record for x400.cs.wisc.edu. This would be an > MX record that points to a RFC987 mail-relay. Now the mapping tables > would have a special entry for x400.cs.wisc.edu to translate it to our > organizational x.400 name ou=cs; o=uw-madison; p=xnren; a= ; c=us. > The mapping tables would translate an RFC822 user address > user@cs.wisc.edu based on the current default mapping for the domain > ".edu". I'm not sure the mapping tables could handle this, and it > would require an RFC987 table entry for every organization using > X.400. Again I am concerned about the problem of scalability. > > Currently I prefer the solution of adding a top-level domain such as > xnren.us or xnren.x400.us because this would only require creating one > new domain. When a user switched from RFC822 to using X.400, their > old RFC822 address would still "work" by the use of system-wide > aliases or a .forward file. This would only require one entry in > RFC987 mapping tables, and avoids problems with scalability. > > What would you recommend? > > allan Steve's response: # Date: 13 Jun 90 18:09 +0100 # From: Steve Kille # Sender: S.Kille@cs.ucl.ac.uk # To: Allan Cargille # Cc: RARE R&D MHS Managers , # RARE WG1 # Subject: Re: U.S. RFC987 mapping table entries # # Phone: +44-71-380-7294 # # I'd recommend your solution 2. This has the big advantage that it # can preserve current domain names as organisations move to X.400. This # will facilitate a transparent transition, and lead to protocol independent # domain names. The tables will be quite big, but should be manageable. # It is one per orgnaisiton, and not on entyr per host. # # Steve -- Allan Cargille Computer Sciences Department Associate Researcher University of Wisconsin-Madison cargille@cs.wisc.edu 1210 West Dayton Street uwvax!cargille Madison, WI 53706 USA +1 (608) 262-5084 Fax +1 (608) 262-9777 From stef@nma.com Sun Jun 24 11:56:51 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Sun, 24 Jun 90 11:56:51 -0500 Received: from nrtc.northrop.com by cs.wisc.edu; Sun, 24 Jun 90 11:56:42 -0500 Received: from nma.com by nrtc.nrtc.northrop.com id ac08534; 24 Jun 90 9:55 PDT Received: from localhost by nma.com id aa22629; 24 Jun 90 9:22 PDT To: ORName Map , iso@nic.ddn.mil Subject: Forw: US National Decision on ADMD names and Operations Reply-To: Stef@nrtc.northrop.com From: Einar Stefferud Date: Sun, 24 Jun 90 09:22:11 -0700 Message-Id: <22627.646244531@nma.com> Sender: stef@nma.com Status: O ------- Forwarded Message From: Einar Stefferud Reply-to: Stef@nrtc To: mhsig@nrtc, RARE WG1 , rasig@nrtc Cc: "Ole J Jacobsen" Subject: US National Decision on ADMD names and Operations Date: Sun, 24 Jun 90 09:14:40 -0700 Report of June 21, 1990, Meeting with the US Department of State concerning Assignment of ADMD Names and Responsibilities. Prepared by Richard desJardins on June 22, 1990. Meeting Attended by Bob Christie, Northern Telecom, Ron Wheeler, PacTel, Einar Stefferud, Network Management Associates, Richard desJardins, INTEROP. Several people from the NIST OIW MHSIG (X.400) -- acting as individual experts -- met with Mr Gary Fereno, Deputy Chair of the US National Committee for CCITT, US Department of State, to discuss the US approach to assignment of names and responsibilities for US X.400 ADMDs (Administration Management Domains). We explained the problems of naming and routing responsibilities that need to be identified and resolved quickly to assure that X.400 worldwide service into and out of the US will meet the intent of the X.400 Recommendations for flexible ADMD support of PRMD interworking. Specifically, the US needs to establish a US "ADMD National Backbone" to assure universal interworking while allowing "No ADMD" and "Any ADMD" type services to be freely available. We provided Mr Fereno with a copy of "Draft British Standard Specification for Electronic Messaging Implementing ISO/IEC 10021 in the United Kingdom" (Issue 4.1, 9 June, 1990), which describes the UK approach to these same problems. In his turn, Mr Fereno recognized our concerns while pointing out the unique aspects of the US regulatory environment. He likened the X.400 problem to the problem of assigning US Credit Card Service Provider identifications and charter responsibilities. Following the exchange of views, Mr Fereno, speaking "on behalf of the State Department" concluded the meeting by proposing to set up a US National Committee under study Groups A and B. This committee would operate similar to the committee that assigns credit card numbers for the US and develops the charter of responsibilities for US credit card providers. He said he would take the necessary actions to begin the establishment of this committee under the aegis of the State Department, including the publication of an initial meeting announcement in the Federal Register, within two months time. Respectfully submitted by Ricahrd desJardins, Reporter and Einar Stefferud, Scribe ------- End of Forwarded Message From vcerf@NRI.Reston.VA.US Sun Jun 24 15:10:51 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Sun, 24 Jun 90 15:10:51 -0500 Received: from NRI.RESTON.VA.US by cs.wisc.edu; Sun, 24 Jun 90 15:10:47 -0500 Received: from [127.0.0.1] by NRI.NRI.Reston.VA.US id aa12444; 24 Jun 90 16:04 EDT To: Stef@nrtc.northrop.com Cc: ORName Map , iso@nic.ddn.mil, vcerf@NRI.Reston.VA.US Subject: Re: Forw: US National Decision on ADMD names and Operations In-Reply-To: Your message of Sun, 24 Jun 90 09:22:11 -0700. <22627.646244531@nma.com> Date: Sun, 24 Jun 90 16:04:53 -0400 From: vcerf@NRI.Reston.VA.US Message-Id: <9006241604.aa12444@NRI.NRI.Reston.VA.US> Status: O Stef, et al, what about PRMD registration??? Vint From stef@nma.com Wed Jul 4 22:15:09 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 4 Jul 90 22:15:09 -0500 Received: from nrtc.northrop.com by cs.wisc.edu; Wed, 4 Jul 90 22:14:56 -0500 Received: from nma.com by nrtc.nrtc.northrop.com id aa28453; 4 Jul 90 20:14 PDT Received: from localhost by nma.com id aa04219; 4 Jul 90 16:57 PDT To: Allan Cargille Cc: ietf osi o/r names Subject: Re: Internet-style addresses for U.S. X.400 users In-Reply-To: Your message of Wed, 13 Jun 90 13:03:06 -0500. <9006131808.AA03178@rivendell.cs.wisc.edu> Reply-To: Stef@nrtc.northrop.com From: Einar Stefferud Date: Wed, 04 Jul 90 16:56:54 -0700 Message-Id: <4214.647135814@nma.com> Sender: stef@nma.com Status: O Hi Allan, et al -- I am trying to catch up with things after 3 weeks of travel, including one week of backpacking in Yosemite (so ti was not all bad). I am plannign to be in Vancouver for an NIST OIW MHSIG Interim Meeting which happens to be there the same week as the IETF-OSI meetings, so I plan to attend the IETF-OSI-OR and other relevant IETF meetings while I am there. My problem is that I don't know when or where the IETF-OSI-?? meetings will be held. Can someone please supply the relevatn information? Thanks...\Stef From cargille@rivendell.cs.wisc.edu Thu Jul 5 10:48:58 1990 Received: from rivendell.cs.wisc.edu by janeb.cs.wisc.edu; Thu, 5 Jul 90 10:48:58 -0500 From: cargille@rivendell.cs.wisc.edu (Allan Cargille) Message-Id: <9007051548.AA04429@rivendell.cs.wisc.edu> Received: by rivendell.cs.wisc.edu; Thu, 5 Jul 90 10:48:44 -0500 Subject: Vancouver meeting of ietf-osi-or To: Stef@nrtc.northrop.com Date: Thu, 5 Jul 90 10:48:42 CDT Cc: ietf-osi-or@rivendell.cs.wisc.edu In-Reply-To: <4214.647135814@nma.com>; from "Einar Stefferud" at Jul 04, 90 4:56 pm X-Mailer: ELM [version 2.2 PL13] Status: O > Hi Allan, et al -- > > I am trying to catch up with things after 3 weeks of travel, including > one week of backpacking in Yosemite (so ti was not all bad). > > I am plannign to be in Vancouver for an NIST OIW MHSIG Interim Meeting > which happens to be there the same week as the IETF-OSI meetings, so I > plan to attend the IETF-OSI-OR and other relevant IETF meetings while I > am there. My problem is that I don't know when or where the IETF-OSI-?? > meetings will be held. > > Can someone please supply the relevatn information? Thanks...\Stef > -- Allan Cargille Computer Sciences Department Associate Researcher University of Wisconsin-Madison cargille@cs.wisc.edu 1210 West Dayton Street uwvax!cargille Madison, WI 53706 USA +1 (608) 262-5084 Fax +1 (608) 262-9777 From cargille@rivendell.cs.wisc.edu Thu Jul 5 11:10:38 1990 Received: from rivendell.cs.wisc.edu by janeb.cs.wisc.edu; Thu, 5 Jul 90 11:10:38 -0500 From: cargille@rivendell.cs.wisc.edu (Allan Cargille) Message-Id: <9007051610.AA04489@rivendell.cs.wisc.edu> Received: by rivendell.cs.wisc.edu; Thu, 5 Jul 90 11:10:27 -0500 Subject: Vancouver meeting of ietf-osi-or To: Stef@nrtc.northrop.com Date: Thu, 5 Jul 90 11:10:25 CDT Cc: ietf-osi-or@rivendell.cs.wisc.edu In-Reply-To: <4214.647135814@nma.com>; from "Einar Stefferud" at Jul 04, 90 4:56 pm X-Mailer: ELM [version 2.2 PL13] Status: RO Hello Stef and others, Sorry, my mailer and I disagreed about sending the previous message. The IETF-OSI-OR (X.400) working group will be meeting at the coming IETF in Vancouver. The final schedule has not been announced, but there is a good possibility that the group will meet during the Thursday morning session. Ross Callon or Rob Hagens will send out the finalized meeting schedule early next week. The meetings will be held at the UBC Campus in the Henry Angus Building. The meetings are open meetings and all are invited. Stef, do you know the agenda and schedule of the OIW meetings? Where are they being held? Are IETF'ers invited to drop in? It would be nice to meet some of the other players in the X.400 world. G'day, allan -- Allan Cargille Computer Sciences Department Associate Researcher University of Wisconsin-Madison cargille@cs.wisc.edu 1210 West Dayton Street uwvax!cargille Madison, WI 53706 USA +1 (608) 262-5084 Fax +1 (608) 262-9777 From epg@gateway.mitre.org Thu Jul 5 11:37:31 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Thu, 5 Jul 90 11:37:31 -0500 Received: from gateway.mitre.org by cs.wisc.edu; Thu, 5 Jul 90 11:37:25 -0500 Return-Path: Received: by gateway.mitre.org (5.54/SMI-2.2) id AA03790; Thu, 5 Jul 90 12:38:15 EDT Message-Id: <9007051638.AA03790@gateway.mitre.org> To: cargille (Allan Cargille) Cc: Stef@nrtc.northrop.com, ietf-osi-or, epg@gateway.mitre.org Subject: Re: Vancouver meeting of ietf-osi-or In-Reply-To: Your message of Thu, 05 Jul 90 11:10:25 -0500. <9007051610.AA04489@rivendell.cs.wisc.edu> Date: Thu, 05 Jul 90 12:38:13 -0400 From: epg@gateway.mitre.org Status: O Allan-- I sent mail to Barbara Nelson, chair of the X.400 SIG, and to Rob suggesting they consider a joint session but haven't heard back from them. Ella From stef@nma.com Thu Jul 5 16:35:32 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Thu, 5 Jul 90 16:35:32 -0500 Received: from nrtc.northrop.com by cs.wisc.edu; Thu, 5 Jul 90 16:35:15 -0500 Received: from nma.com by nrtc.nrtc.northrop.com id ab02252; 5 Jul 90 14:34 PDT Received: from localhost by nma.com id aa05630; 5 Jul 90 14:02 PDT To: Allan Cargille Cc: ietf-osi-or Subject: Re: Vancouver meeting of ietf-osi-or In-Reply-To: Your message of Thu, 05 Jul 90 11:10:25 -0500. <9007051610.AA04489@rivendell.cs.wisc.edu> Reply-To: Stef@nrtc.northrop.com From: Einar Stefferud Date: Thu, 05 Jul 90 14:02:33 -0700 Message-Id: <5625.647211753@nma.com> Sender: stef@nma.com Status: O Hi Allan -- I will protect Thursday AM for an IETF-OSI-OR meeting at UBC. Please let me know as soon as things are firm on this plan. I am not certain what the NIST OIW MHSIG agenda is, but it would indeed be good to have a bit of cross connect with IETF. I should note however that MHSIG is much more concerned with Implementor's Agreements on aspects of software implementation than on network operational issues. Typically, Thurdays are set aside for breakout meetings of MHSIG subgroups with a Friday AM plenary. Hopefuylly, Thursday AM will not be set for some MHSIG topic that I need to attend. Best...\Stef From hagens Tue Jul 10 15:06:08 1990 Message-Id: <9007102006.AA01690@janeb.cs.wisc.edu> Received: from localhost by janeb.cs.wisc.edu; Tue, 10 Jul 90 15:06:08 -0500 To: ietf-osi-or Subject: Vancouver meeting Date: Tue, 10 Jul 90 15:06:07 EDT From: hagens Status: O The IETF-OSI-OR meeting be held thursday morning at UBC. An agenda will follow shortly. Rob From cargille@rivendell.cs.wisc.edu Tue Jul 10 15:40:22 1990 Received: from rivendell.cs.wisc.edu by janeb.cs.wisc.edu; Tue, 10 Jul 90 15:40:22 -0500 From: cargille@rivendell.cs.wisc.edu (Allan Cargille) Message-Id: <9007102037.AA10925@rivendell.cs.wisc.edu> Received: by rivendell.cs.wisc.edu; Tue, 10 Jul 90 15:37:40 -0500 Subject: Re: U.S. RFC987 mapping table entries To: Stef@nrtc.northrop.com Date: Tue, 10 Jul 90 15:37:38 CDT Cc: Christian.Huitema@mirsa.inria.fr, vcerf@nri.reston.va.us, piet@cwi.nl, rare-wg1@switch.ch, ietf-osi-or (ietf osi o/r names) In-Reply-To: <13626.647622938@nma.com>; from "stef@nma.com" at Jul 10, 90 5:55 pm X-Mailer: ELM [version 2.2 PL13] Status: O > Christian and Vint -- > > Use of suffers badly in > the US at this point because there is no handy way to register > PRMD=NRI.Reston.VA anywhere in the US. Until we have a PRMD registry, > it is hard to just unilaterally "do" anything like that. > > We do have a scheme in development (in the NIST OIW MHSIG Agreements) to > allow such PRMD name generations, but it requires that the Sovereign > State of Virginia set up a registration Authority for OSI (and CCITT) > names. Also, the scheme requires that the US make a National Decision > (like the uK is doing), in order to impose the scheme on US ADMD and > PRMD operators. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > At this point in time, the Sercetary of State and the Legistature for > the State of Virginia (and all other US states) are blissfully unaware > of any aspect of this issue. I don't think we can wait for them to wake > up and take action before we can resolve this problem. > > We have initiated action in the US State Department (Study Groups A-D) > to create a proper committee to identify the needs for a US National > Decision and to begin the process of deciding. It is not possible to > predict how long the process will take. > > The first meeting is set for August 13, 1990...\Stef Hello Stef, Could you please enlarge on this scheme? What mailing lists is it being discussed on? Thanks, allan -- Allan Cargille Computer Sciences Department Associate Researcher University of Wisconsin-Madison cargille@cs.wisc.edu 1210 West Dayton Street uwvax!cargille Madison, WI 53706 USA +1 (608) 262-5084 Fax +1 (608) 262-9777 From stef@nma.com Wed Jul 11 12:08:29 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 11 Jul 90 12:08:29 -0500 Received: from nrtc.northrop.com by cs.wisc.edu; Wed, 11 Jul 90 12:08:22 -0500 Received: from nma.com by nrtc.nrtc.northrop.com id aa04362; 11 Jul 90 9:54 PDT Received: from localhost by nma.com id aa15049; 11 Jul 90 9:30 PDT To: hagens Cc: ietf-osi-or, Gerald Neufeld , Neil Koorland Subject: Re: Vancouver meeting In-Reply-To: Your message of Tue, 10 Jul 90 15:06:07 -0400. <9007102006.AA01690@janeb.cs.wisc.edu> Reply-To: Stef@nrtc.northrop.com From: Einar Stefferud Date: Wed, 11 Jul 90 09:30:02 -0700 Message-Id: <15041.647713802@nma.com> Sender: stef@nma.com Status: O What time on Thursday morning do you plan to hold the IETF-OSI-OR meeting? I have a conflict with an early morning meeting at UBC on another topic. It is critical that I get these two meeting to not collide. My other meeting would be very early, so it will help if the OSI-OR meeting is not early. Thanks...\Stef -------- To: ietf-osi-or@cs.wisc.edu Subject: Vancouver meeting Date: Tue, 10 Jul 90 15:06:07 EDT From: hagens@cs.wisc.edu The IETF-OSI-OR meeting be held thursday morning at UBC. An agenda will follow shortly. Rob ------- From stef@nma.com Wed Jul 11 21:55:35 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 11 Jul 90 21:55:35 -0500 Received: from nrtc.northrop.com by cs.wisc.edu; Wed, 11 Jul 90 21:55:19 -0500 Received: from nma.com by nrtc.nrtc.northrop.com id aa07768; 11 Jul 90 19:54 PDT Received: from localhost by nma.com id aa16193; 11 Jul 90 19:37 PDT To: Allan Cargille Cc: Christian.Huitema@mirsa.inria.fr, vcerf@nri.reston.va.us, piet@cwi.nl, rare-wg1@switch.ch, ietf osi o/r names Subject: Re: U.S. RFC987 mapping table entries In-Reply-To: Your message of Tue, 10 Jul 90 15:37:38 -0500. <9007102037.AA10925@rivendell.cs.wisc.edu> Reply-To: Stef@nrtc.northrop.com From: Einar Stefferud Date: Wed, 11 Jul 90 19:36:42 -0700 Message-Id: <16190.647750202@nma.com> Sender: stef@nma.com Status: O In the NIST OIW MHSIG we have developed some "construction rules" for using ANSI Registeered Orgainzational OSI names as roots for building MHS MD names (ADMD or PRMD) for use in the US X.400 MTS. I will have to dig out the text as it is now published in the OIW Working Agreeemnts documnet, and send it along to these lists. You all might find it interesting. It will be coming along later. Best...\Stef From hagens Mon Jul 16 09:46:23 1990 Message-Id: <9007161446.AA08340@janeb.cs.wisc.edu> Received: from localhost by janeb.cs.wisc.edu; Mon, 16 Jul 90 09:46:23 -0500 To: rare-wg1@switch.ch, ietf-osi-or, namedroppers@nic.ddn.mil Cc: cole Subject: Proposal for use of DNS to store RFC 987, etc mappings Date: Mon, 16 Jul 90 09:46:20 EDT From: hagens Status: O GentlePeople, I have enclosed a draft of a proposal that Bruce Cole and I have been working on. This proposal describes how the internet DNS can be used to aid in the storage/distribution of RFC 987, etc mapping tables. These tables will be important to the interoperation of RFC 822 based mail and OSI X.400 (MHS). We will be discussing the proposal as part of the X.400 WG meeting at the Vancouver IETF. The proposal has been implemented and tested on a trial basis at the University of Wisconsin. Rob Draft Proposal for the use of the Internet DNS to maintain RFC 987/RFC 1148 Address Mapping Tables Bruce Cole (cole@cs.wisc.edu) Robert Hagens (hagens@cs.wisc.edu) Draft RFC May 1990 1.0 Introduction RFC987 describes a set of mappings between the X.400 (1984) series of protocols and the RFC822 mail protocol, or protocols derived from RFC822. That document addresses conversion of services, addresses, message envelopes, and message bodies between the two mail systems. This draft RFC is concerned with one aspect of RFC987; the mechanism for mapping between X.400 O/R addresses and RFC822 domain names. As described in Appendix F of RFC987, implementation of the mappings requires a database which maps between X.400 O/R addresses and RFC822 addresses. A possible mechanism for use of the internet DNS to store, retrieve and maintain these mappings is proposed. This mechanism is of potential use to internet hosts acting as X.400/RFC822 gateways. Definitions dmn-orname: text encoding of O/R address as defined in section 4.1.3 of RFC987. This representation of X.400 O/R addresses allows storage and retrieval of O/R addresses by the Internet DNS, without syntactical extensions to the DNS. domain-name: text encoding of a domain name : Internet DNS encoding of a domain name, as defined in RFC1035, section 3.3. owner-name: The name of a particular node in the DNS namespace to which one or more resource records belong. Also known as the name field of a DNS resource record. 2.0 Motivation Implementations of RFC987 gateways require that a database store address mapping information for X.400 and RFC822. This information must be disseminated to all RFC987 gateways. In the internet community, the DNS has proven to be a practical means for providing a distributed nameservice. Advantages of using a DNS based system over a table based approach for mapping between O/R addresses and domain names are: 1. It avoids fetching and storing of entire mapping tables by every host that wishes to implement RFC987. 2. Modifications to the DNS based mapping information can be made available in a more timely manner than with a table driven approach. 3. Organizations avoid the administrative costs associated with maintaining mapping tables throughout their network. 4. Allows the specification of backup gateways (in case of failure) through the use of a priority field. Cole & Hagens [Page 1] Draft RFC May 1990 3.0 Proposed Resource Records Using RFC987's assumption of an asymmetric mapping between X.400 and RFC822 addresses, two separate relations are required to store the mapping database. We propose two new DNS resource record types, TO-X400 and TO-822, which are to be used to translate between X.400 and RFC822 addresses. The owner-name field of the new resource records can be thought of as keys used to reference the RFC987 mapping data. The data format and meaning of these new resource records is as follows: TO-822 (resource record type 20, decimal) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PREFERENCE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | WILDCARD-COUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / DOMAIN-NAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ TO-X400 (resource record type 21, decimal) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PREFERENCE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | WILDCARD-COUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / DMN-ORNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: PREFERENCE A 16 bit integer which specifies the preference given to this resource record among others of the same type and owner-name. Lower values are preferred. WILDCARD-COUNT A 16 bit integer. If the information being returned by this resource record is not derived from a wildcard resource record, then this field contains the value zero. Otherwise, this field indicates the number of components explicitly matched by a wildcard resource record. Specifically, a non-zero value N specifies that the rightmost N components of owner-name were used to find the wildcard resource record information. Note that the value of this field is computed by authoritative nameservers, and is not specified in a master file for a zone. Cole & Hagens [Page 2] Draft RFC May 1990 DOMAIN-NAME A which specifies the domain-name of a host willing to receive RFC822 mail. DMN-ORNAME A which specifies the dmn-orname of a host willing to receive X.400 mail. TO-X400: Given an owner-name representing an RFC-822 domain-name, return an X400 O/R address in dmn-orname syntax. There can be multiple TO-X400 records associated with one owner-name, indicating a set of X.400/RFC822 gateways for one domain name. The preference field is used to indicate the relative priorities of these multiple records. In the event of a delivery failure, an alternate X.400 gateway of equal or lesser priority can be chosen, such as is done with the DNS MX resource records. (see RFC974). TO-822: Given an owner-name representing an X.400 O/R address in dmn-orname syntax, return an RFC-822 domain-name. The preference and wildcard-count fields are interpreted in the same manner as for TO-X400 records. 4.0 Usage The RFC987 mapping information is stored in the DNS in a tree structure. The TO-X400 records occupy space within the already existent tree of domain names. The TO-822 records occupy a new tree whose nodes are domain names in dmn-orname syntax. O/R attributes are stored in the tree hierarchically with the most significant attributes occupying root domains, and the least significant attributes occupying leaf nodes of the DNS. The root nodes of this new tree represent O/R country attribute-value pairs. For example, C$US and C$UK are valid root domain names. The dmn-orname information associated with TO-X400 and TO-822 resource records do not represent full O/R address, they are merely templates which specify those fields of the O/R address that are used by the mapping algorithm. A subset of the possible X.400 O/R attributes are used when performing conversions between RFC822 and X.400 O/R addresses. The attribute names allowed in a dmn-orname, listed in descending order of significance are: Name Number that may be specified in dmn-orname Country Exactly 1 ADMD 0 or 1 PRMD 0 or 1 Organization 0 or 1 Organizational Unit 0 or more When an O/R address is written in dmn-orname syntax, the attributes are ordered from left to right in ascending order of significance. O/R attribute names not listed in the above table (such as the surname attribute) do not appear in dmn-ornames used by the mapping procedure. When an attribute is Cole & Hagens [Page 3] Draft RFC May 1990 omitted from the dmn-orname, no other attributes of less significance may be included. Dmn-ornames and domain-names are used as the lookup keys to retrieve RFC987 mapping information from the DNS. A non-existent domain response from the nameserver indicates that there is no RFC987 mapping information in the DNS for the given key, and the DNS search is complete. A non-error response also completes the DNS search. Wildcard resource records can be used to allow multiple keys to map to one node in the DNS namespace. (See also RFC1034, section 4.3.3, wildcards.) If the returned resource record contains a non-zero WILDCARD-COUNT field, then the longest possible match of the supplied lookup key does not include all components of that key. For a lookup key of M components and a WILDCARD-COUNT field with value N, a non-zero value for N indicates that the leftmost M-N components of the lookup key were not explicitly matched. Assumptions are made as to the mapping of the unmatched components. There are two cases: 1. RFC822->X.400 Map all remaining domain-name components to additional O/R attribute/value pairs. The next attribute assigned corresponds to the attribute of next lower priority than the lowest attribute type already assigned. The new attribute is assigned a value which is the same as the most significant unmapped domain-name component. If the last assigned attribute type was an OU (organizational unit), then any additional attribute assignments will be to OUs, with less significant attribute-value pairs written to the left of other attribute-values. Order and significance of domain-name components are preserved by this scheme. 2. X.400->RFC822 Of the remaining dmn-orname components, only those which correspond to attributes at least as significant as the OU attribute type are mapped. The attribute values from these components are added to the domain-name returned by the DNS lookup, and are mapped in the same order as they appear in the dmn-orname. Those attributes less significant than the OU attribute are used in the construction of the left hand side of the RFC822 address. The translation of the left hand side of the 822 address is specified by RFC987. Example: Assume DNS is populated with the following wildcard resource record: "*.OU$CS.O$UW-MADISON.PRMD$XNREN.ADMD$ .C$US." IN TO-822 0 cs.wisc.edu Given the O/R address /PRMD=XNREN/ADMD= /S=hagens/OU=DIP/OU=CS/O=UW-MADISON/C=US/ determine the corresponding RFC822 domain name. Step 1. The address is rewritten in dmn-orname syntax as: OU$DIP.OU$CS.O$UW-MADISON.PRMD$XNREN.ADMD$ .C$US (The /S=hagens attribute value pair is dropped since it is less significant Cole & Hagens [Page 4] Draft RFC May 1990 than an OU attribute. The attribute order is rewritten according to the dmn-orname restriction specifications.) Step 2. Perform the DNS lookup: "OU$DIP.OU$CS.O$UW-MADISON.PRMD$XNREN.ADMD$ .C$US." The nameserver returns the domain-name: cs.wisc.edu, with preference 0, and a wildcard-count of 5. Step 3. Since the wildcard-count field is non-zero, the nameserver response indicates that the dmn-orname component OU$DIP was not explicitly matched. The unmapped attribute value "DIP" is prepended to the domain-name returned by the DNS lookup to produce the domain-name "dip.cs.wisc.edu". RFC987 specifies that translation from one address space to another may occur in 2 ways. The above method of translation (lookup from the mapping database) is used when sub-trees of the different name spaces are associated via mapping information. The fall back method of translation (encoding in the other address space's format) is used when table lookup fails. However, in this case, the translation is less sophisticated. The fall back method amounts to encoding the address in the other system's format. RFC987 specifies default rules that may be used to perform this encoding. These rules specify the manner in which an RFC822 address may be encoded in X.400, and vice versa, by means of domain defined attributes. 5.0 Administration of mapping information Not all RFC987 gateways will be able to use the internet DNS to map between O/R addresses and RFC822 domain names. Hosts without access to the DNS are expected to obtain full mapping tables (in RFC987 Appendix F format) from a master table via RARE-WG1. Hosts with DNS access should be able to obtain full mapping information from the DNS namespace. This implies that there will be two separate copies of the mapping database, one in table form, and the other within the internet DNS namespace. Use by DNS sites: All TO-X400 and TO-822 records will be stored in DNS zones. The authoritative information for any particular zone may be delegated to any nameserver supporting the TO-X400 and TO-822 resource records. The root nameservers for the TO-X400 and TO-822 information delegate zones to the authoritative nameservers, and assume authority for those sections of the DNS tree that have not been delegated. Note that the root nameservers for these records are not necessarily the same nameservers which are root nameservers for the internet address class. (See next section). For zones not already delegated to a nameserver, the root nameservers will initialize these segments of the DNS tree with the mapping information obtained via RARE WG1. This allows DNS sites to receive up to date information for data which is not maintained by the DNS. Use by non DNS sites: Cole & Hagens [Page 5] Draft RFC May 1990 As mentioned, non DNS sites will obtain all their mapping information using RARE-WG1. In order for the master table-based version of the database to be up to date and complete, changes made to the DNS version must propagate into the table-based version. DNS sites could use a program to parse their zone files into tables formatted as in RFC987 Appendix F. The output could then be delivered to the site which maintains the master RARE-WG1 tables. 6.0 Which address class to use? It can be convenient for these records to be stored in the same DNS zones as other resource record types, such as internet address records. It seems reasonable to store these records in the internet address class since the TO-X400 records refer to owner-names which are already present in the internet address class. In our initial implementation of these new DNS records, the records are assigned to the internet address class. Conceivably, these records could be placed in a new address class such as an ISO address class. This would allow the zones containing TO-X400 and TO-822 records to be delegated independently of already existing DNS zones. This could be particularly useful if it is desired to keep the root nameservers for this mapping data separate from the current internet root nameservers. If these nameservers are not separate, then it is expected that the existing root nameservers will be given the new burden of loading RARE WG1 information into the DNS. Note that the scope of wildcard resource records are bounded by the presence of resource records that occupy subdomains of the wildcard record. If the scope of wildcard records is affected by resource records from different address classes, then wildcard records can be affected in non-intuitive ways. For example the records: *.B.A. IN MX 0 B.A. C.B.A. HS TXT "data" would cause internet address class MX queries for any domain name ending in C.B.A to not match the above wildcard record. If a separate address class is to be used for the TO-X400 and TO-822 records, it is preferable for wildcard records to not be affected by resource records from other address classes. 7.0 Summary Internet DNS nameservers wishing to provide this mapping information need to be modified to support two new resource record types, and possibly a new address class. Additional modifications are required to support the WILDCARD-COUNT field used by the new resource record types. Usage of these extensions provide RFC987 gateways with the advantages listed in the motivation section. These advantages are important for the administration of RFC987 gateways. The existence of two copies of the O/R address vs domain-name mapping database is proposed. Software to convert between the textual representation of DNS resource Cole & Hagens [Page 6] Draft RFC May 1990 records and RFC987 appendix F tables can be used to keep both copies of the database current. 8.0 References [CCITT] CCITT SG 5/VII, "Recommendation X.400," Message Handling Systems: System Model - Service Elements, October 1984. [PP] Kille, S., "PP Installation and Operation", Volume 1, December 1989. [RFC 974] Partridge, C., "Mail routing and the domain system", RFC 974, CSNET CIC BBN Labs, January 1986. [RFC 987] Kille, S., "Mapping Between X.400 and RFC 822", UK Academic Community Report (MG.19) / RFC 987, June 1986. [RFC 1026] Kille, S., "Addendum to RFC 987", UK Academic Community Report (MG.23) / RFC 1026, August 1987. [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, USC/Information Sciences Institute, November 1987. [RFC 1035] Mockapetris, P., "Domain names - Implementation and Specification", RFC 1035, USC/Information Sciences Institute, November 1987. [WG] OSI-X.400 Working Group Meeting, October 1989. Cole & Hagens [Page 7] From stef@nma.com Mon Jul 16 23:16:00 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Mon, 16 Jul 90 23:16:00 -0500 Received: from nrtc.northrop.com by cs.wisc.edu; Mon, 16 Jul 90 23:15:41 -0500 Received: from nma.com by nrtc.nrtc.northrop.com id aa05037; 16 Jul 90 21:15 PDT Received: from localhost by nma.com id aa24096; 16 Jul 90 20:47 PDT To: hagens Cc: rare-wg1@switch.ch, ietf-osi-or, namedroppers@nic.ddn.mil, cole Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings In-Reply-To: Your message of Mon, 16 Jul 90 09:46:20 -0400. <9007161446.AA08340@janeb.cs.wisc.edu> Reply-To: Stef@nrtc.northrop.com From: Einar Stefferud Date: Mon, 16 Jul 90 20:47:19 -0700 Message-Id: <24093.648186439@nma.com> Sender: stef@nma.com Status: O It may just be my inability to read these things with ease, but I did not see a clear cut distinction between the records used to identify (route to) gateways vs the records used to map TO-822 and TO-X400 in the RFC822 and P2 envelopes. It is not clear to me how an X400 MTA would use these records for P1 routing to a gateway. (Not that I think they should not! I absolutely think that we should find a way to do this, without resorting to source-routing hacks!) Could you clarify this in the text? Also, why do you want to orient the X400 addresses least significant element to the left, and most significant to the right, when most X400 texts tend to show them the other way around? (Or am I wrong in this perception?) Is there any non-arbitrary logic here? Next, is it reasonable to deal with the excess of DNS domain names in a mapping TO-X400 by just arbitrarily concatenating the excess into the lowest level OU on the X400 side? u@a.b.c.d.e.f.g => S$u.OU$a\.b\.c.OU$d.OU$e.OU$f.O$g.PRMD$NREN.ADMD$ .C$US And last, what is wrong with allowing mapping all the way down to the User Name (S$last.G$first)? Cheers...\Stef From huitema@jerry.inria.fr Tue Jul 17 06:11:26 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Tue, 17 Jul 90 06:11:26 -0500 Received: from jerry.inria.fr by cs.wisc.edu; Tue, 17 Jul 90 06:11:09 -0500 Received: by jerry.inria.fr (5.61+++/IDA-1.2.8) id AA01140; Tue, 17 Jul 90 13:12:20 +0200 Message-Id: <9007171112.AA01140@jerry.inria.fr> To: S.Kille@cs.ucl.ac.uk, hagens, cole Cc: rare-wg1@switch.ch, ietf-osi-or, namedroppers@nic.ddn.mil Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings In-Reply-To: Your message of 17 Jul 90 10:35:19 +0100. <1217.648201567@UK.AC.UCL.CS> Date: Tue, 17 Jul 90 13:12:11 +0200 From: Christian Huitema Status: O Rob, I read your note, and think that we should work towards its fast finalisation, perhaps clarifying a few points. My first remark concern the mapping ``towards X.400''. You follow-up the mechanism which was first introduced in RFC-987, to build up a hierarchical name as a sequence of ``typed'' tokens, e.g. a top level "C$FR", a second level "ADMD$ATLAS", etc. This has the advantage of precision, but it has also one serious disadvantage, i.e. requiring the setting up of a complete new tree. I feel that this kind of mapping is in fact contradictory with the whole philosophy of RFC-987/1048, where after some specific top levels (C, ADMD, PRMD) the next hierarchical tokens are mapped directly to DNS name parts. A specific start of the tree is certainly necessary, as the subdomains of e.g. "C=FR" bear few relations with those of ".FR". This could easily be provided by setting up a pseudo top domain for "x400", in much the same way as "in-addr". But then, there is no need to insist on the presence of the "C$" or "OU$" prefixes; one should rather try to use the aliasing mechanism already present in the DNS, in order to discover that e.g. "cea.cea.atlas.fr.x400" is in fact the same domain as "cea.fr". This has two advantages: * the same tree can be used at the lower levels, * there is no need for a specific "to-rfc" record. This can also introduce my second remark, regarding routing and the choice of gateways. If the naming heirarchies are in the same tree, there is no need of inventing new routing mechanisms; you can as well use the MX records! Indeed, there is at that point the need to support X.400, hence the need to define a PSAP record associated to the MX host, but this may be another matter... My other remarks are much in the same line as Steve. I don't see much need for a preference counter in the "to-x400" records, and I don't see why the wildcarding mechanism should be different from the one used for the MX records... Christian Huitema From S.Kille@cs.ucl.ac.uk Wed Jul 18 07:16:43 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 18 Jul 90 07:16:43 -0500 Received: from bells.cs.ucl.ac.uk by cs.wisc.edu; Wed, 18 Jul 90 07:16:31 -0500 Received: from hubris.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id ; Tue, 17 Jul 1990 08:59:32 +0000 To: hagens Cc: rare-wg1@switch.ch, ietf-osi-or, namedroppers@nic.ddn.mil, cole Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings Phone: +44-71-380-7294 In-Reply-To: Your message of Mon, 16 Jul 90 09:46:20 -0400. <9007161446.AA08340@janeb.cs.wisc.edu> Date: Tue, 17 Jul 90 08:59:27 +0100 Message-Id: <1217.648201567@UK.AC.UCL.CS> From: Steve Kille Status: O Rob, Thanks for this note. A few thoughts. 5.0 "This implies that there will be two separate copies of the mapping database, one in table form, and the other within the internet DNS Namespace". I agree that this is the case. If we go down this path, it is imperative that we have solid mechanisms to keep these two views consistent. I don't think that you have really addressed this. I think that the preference value is an interesting idea, however I don't see why it is really needed. Then 987 mappings are global. There should be no need to have alternate/preferred mappings. A preference mapping would be more appopriate when choosing a 987 gateway, but not for the base 987 mapping. It would be appropraite to add mechanisms to this spec to enable selection of 987 gateways. You may use 987 mappings to reformat a header containing a large number of addresses. It would seem reasonable to reformat the header in a single process. There might be problems with DNS timeouts for headers with a very large number of addresses. Overall, I have a lot of sympathy with the approach you propose. The format of Appendix F of 987 was not a co-incidence. However, I have a lot of concern that it is not the correct operational choice. Steve From hagens Wed Jul 18 12:05:40 1990 Message-Id: <9007181705.AA00309@janeb.cs.wisc.edu> Received: from localhost by janeb.cs.wisc.edu; Wed, 18 Jul 90 12:05:40 -0500 To: Stef@nrtc.northrop.com Cc: rare-wg1@switch.ch, ietf-osi-or, namedroppers@nic.ddn.mil, cole Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings In-Reply-To: Your message of "Mon, 16 Jul 90 20:47:19 PDT." <24093.648186439@nma.com> Date: Wed, 18 Jul 90 12:05:36 EDT From: hagens Status: O > > > It may just be my inability to read these things with ease, but I did > not see a clear cut distinction between the records used to identify > (route to) gateways vs the records used to map TO-822 and TO-X400 in the > RFC822 and P2 envelopes. It is not clear to me how an X400 MTA would > use these records for P1 routing to a gateway. (Not that I think they > should not! I absolutely think that we should find a way to do this, > without resorting to source-routing hacks!) We did not attempt to address the use of DNS for X.400 routing. Although I can justify requiring a 987... gateway to have resolver code, I can't imagine that many X.400 MTAs will have resolver code. I think we need to look to X.500/new OSI protocol for the X.400 routing problem. > Also, why do you want to orient the X400 addresses least significant > element to the left, and most significant to the right, when most X400 > texts tend to show them the other way around? (Or am I wrong in this > perception?) Is there any non-arbitrary logic here? The reason for this is that the DNS system expects to have the most significant bits on the right (cs.wisc.edu -- "edu" is on the right). > > Next, is it reasonable to deal with the excess of DNS domain names in a > mapping TO-X400 by just arbitrarily concatenating the excess into the > lowest level OU on the X400 side? > > u@a.b.c.d.e.f.g => S$u.OU$a\.b\.c.OU$d.OU$e.OU$f.O$g.PRMD$NREN.ADMD$ .C$US > > And last, what is wrong with allowing mapping all the way down to the > User Name (S$last.G$first)? On both these counts we followed the spirit of RFC 987 which has already defined an algorithmic mapping for personal name and OUs. Thanks for the comments! Rob From hagens Wed Jul 18 12:29:36 1990 Received: from parmesan.cs.wisc.edu by janeb.cs.wisc.edu; Wed, 18 Jul 90 12:29:36 -0500 Received: from janeb.cs.wisc.edu by parmesan.cs.wisc.edu; Wed, 18 Jul 90 12:29:20 -0500 Message-Id: <9007181728.AA00340@janeb.cs.wisc.edu> Received: from localhost by janeb.cs.wisc.edu; Wed, 18 Jul 90 12:28:57 -0500 To: Steve Kille Cc: hagens@parmesan.cs.wisc.edu, rare-wg1@switch.ch, ietf-osi-or@parmesan.cs.wisc.edu, namedroppers@nic.ddn.mil, cole@parmesan.cs.wisc.edu Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings In-Reply-To: Your message of "17 Jul 90 10:33:00 BST." <1217.648201567@UK.AC.UCL.CS> Date: Wed, 18 Jul 90 12:28:55 EDT From: hagens Status: O > 5.0 "This implies that there will be two separate copies of the > mapping database, one in table form, and the other within the internet > DNS Namespace". I agree that this is the case. If we go down this > path, it is imperative that we have solid mechanisms to keep these > two views consistent. I don't think that you have really addressed this. No, your right. We did not discuss the specifics for keeping the authoritative data for a specific DNS server and the table form consistent. At one level, it is simply a program that produces one form from the other. At a higher level, there are issues concerning the way in which the US collects its tables and disseminates them to the rest of the world (and vice versa). Another issue is how to deal with inconsistencies that may result if a site changes their DNS server configuration file before the change has been propagated to those gateways which do not have DNS access. In general tho, do you think the coordination of the tables and server config files is feasible? > > I think that the preference value is an interesting idea, however I > don't see why it is really needed. Then 987 mappings are global. There > should be no need to have alternate/preferred mappings. A preference > mapping would be more appopriate when choosing a 987 gateway, but not > for the base 987 mapping. In retrospect, I think the preference field is not going to work, for reasons you site above. I think that in the 822->X.400 direction, the preference field of MX records can be used to find the gateway. In the other direction, it is a matter for X.400 routing to solve. > > You may use 987 mappings to reformat a header containing a large number of > addresses. It would seem reasonable to reformat the header in a single > process. There might be problems with DNS timeouts for headers > with a very large number of addresses. Yes, this is a problem with the DNS today with RFC 822 mail! We need to make sure that back-up servers are distributed correctly. Of course, running the DNS over the OSI connection-less network will drastically improve connectivity and dependability! :^) > Overall, I have a lot of sympathy with the approach you propose. The format > of Appendix F of 987 was not a co-incidence. However, I have a lot of > concern that it is not the correct operational choice. Could you elaborate here? Thanks, Rob From hagens Wed Jul 18 12:33:06 1990 Message-Id: <9007181733.AA00361@janeb.cs.wisc.edu> Received: from localhost by janeb.cs.wisc.edu; Wed, 18 Jul 90 12:33:06 -0500 To: Christian Huitema Cc: S.Kille@cs.ucl.ac.uk, cole, rare-wg1@switch.ch, ietf-osi-or, namedroppers@nic.ddn.mil Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings In-Reply-To: Your message of "Tue, 17 Jul 90 13:12:11 +0100." <9007171112.AA01140@jerry.inria.fr> Date: Wed, 18 Jul 90 12:33:04 EDT From: hagens Status: O > > > Rob, > > I read your note, and think that we should work towards its fast > finalisation, perhaps clarifying a few points. > > My first remark concern the mapping ``towards X.400''. You follow-up > the mechanism which was first introduced in RFC-987, to build up a > hierarchical name as a sequence of ``typed'' tokens, e.g. a top > level "C$FR", a second level "ADMD$ATLAS", etc. This has the > advantage of precision, but it has also one serious disadvantage, > i.e. requiring the setting up of a complete new tree. I feel that > this kind of mapping is in fact contradictory with the whole > philosophy of RFC-987/1048, where after some specific top levels (C, > ADMD, PRMD) the next hierarchical tokens are mapped directly to DNS > name parts. Christian, Our basic assumption for this work is that we will need many specific mapping entries because the OR Address tree will not be directly derivable from the DNS tree. For example, in the pilot project here, my X.400 address has an Org of "uw-madison". The components "wisc" and "edu" do not appear in my address. Thus, I need a more specific mapping entry than just C and PRMD. If you assume that a few general mappings will work, then obviously you don't need our proposal... Lets discuss this more in Wisconsin! Have a good flight Rob From harald.alvestrand@elab-runit.sintef.no Thu Jul 19 04:55:52 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Thu, 19 Jul 90 04:55:52 -0500 Received: from tosca.er.sintef.no by cs.wisc.edu; Thu, 19 Jul 90 04:54:21 -0500 Received: from localhost by tosca.er.sintef.no (5.61+IDA/KTH/LTH/1.4) with SMTP id AAtosca01861; Thu, 19 Jul 90 11:54:04 +0200 Received: from /PRMD=uninett/ADMD=_/C=no/ by tosca.elab-runit.sintef.no with X.400 id tosca.648381250; relayed; Thu, 19 Jul 90 11:54:03 +0200 Date: Thu, 19 Jul 90 11:54:03 +0200 From: Harald Tveit Alvestrand In-Reply-To: <9007181733.AA00361@janeb.cs.wisc.edu> To: Cc: Christian Huitema , , , , , Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings Message-Id: <1191*harald.alvestrand@elab-runit.sintef.no> Status: O Rob et al: Your proposal requires (as far as I can see) the registration of new toplevel domains C$no, C$us and so on. Maybe we should follow Christian's proposal (I recognize the idea from the MAILWAY code....), and put a single toplevel domain with name "X400" or even "RFC987TABLE"????? The administrative authority for the subdomains of this descends naturally on the RARE MHS managers, since most of the national X.400 authorities (whatever that is) will probably not even know what a DNS is. Otherwise, I like your proposal. One note: You should perhaps include a statement that "when mapping information is not available due to DNS server downtime, the 987 gateway should WAIT until the mapping is available, or a LONG timeout, before non-delivering the message". Second note: I have never seen a DNS name with a space in it. The proposal (and RFC987 tables!) depend on $ and . being absent from the attributes (or escaped, see the troubles with uk.ac!). With X.400/88 we get every character under the sun into the addresses. Is this problem generally solved by using (numeric)? Does DNS handle a name of the form dom(number)dom.gurba . correctly? (parentheses and space!) I ask from ignorance of DNS.... Harald From root@nexus.yorku.ca Thu Jul 19 15:46:13 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Thu, 19 Jul 90 15:46:13 -0500 Received: from nexus.yorku.ca by cs.wisc.edu; Thu, 19 Jul 90 15:44:39 -0500 Received: from localhost (stdin) by nexus.yorku.ca with SMTP id 6196; Thu, 19 Jul 90 16:42:58 EDT To: S.Kille@cs.ucl.ac.uk, hagens, cole Cc: rare-wg1@switch.ch, ietf-osi-or, namedroppers@nic.ddn.mil Subject: Manually forwarded mail -- delayed during exposure-test. Date: Thu, 19 Jul 90 16:42:51 EDT From: root@nexus.yorku.ca Message-Id: <90Jul19.164258edt.6196@nexus.yorku.ca> Status: O The following message was placed in the York University dead-letter office in error, during testing of a new smtp server. The postmaster apologizes for the inconvenience! --dave --------- Received: from jerry.inria.fr by NIC.DDN.MIL with TCP; Tue, 17 Jul 90 04:11:47 PDT Received: by jerry.inria.fr (5.61+++/IDA-1.2.8) id AA01140; Tue, 17 Jul 90 13:12:20 +0200 Message-Id: <9007171112.AA01140@jerry.inria.fr> To: S.Kille@cs.ucl.ac.uk, hagens@cs.wisc.edu, cole@cs.wisc.edu Cc: rare-wg1@switch.ch, ietf-osi-or@cs.wisc.edu, namedroppers@nic.ddn.mil Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings In-Reply-To: Your message of 17 Jul 90 10:35:19 +0100. <1217.648201567@UK.AC.UCL.CS> Date: Tue, 17 Jul 90 13:12:11 +0200 From: Christian Huitema Rob, I read your note, and think that we should work towards its fast finalisation, perhaps clarifying a few points. My first remark concern the mapping ``towards X.400''. You follow-up the mechanism which was first introduced in RFC-987, to build up a hierarchical name as a sequence of ``typed'' tokens, e.g. a top level "C$FR", a second level "ADMD$ATLAS", etc. This has the advantage of precision, but it has also one serious disadvantage, i.e. requiring the setting up of a complete new tree. I feel that this kind of mapping is in fact contradictory with the whole philosophy of RFC-987/1048, where after some specific top levels (C, ADMD, PRMD) the next hierarchical tokens are mapped directly to DNS name parts. A specific start of the tree is certainly necessary, as the subdomains of e.g. "C=FR" bear few relations with those of ".FR". This could easily be provided by setting up a pseudo top domain for "x400", in much the same way as "in-addr". But then, there is no need to insist on the presence of the "C$" or "OU$" prefixes; one should rather try to use the aliasing mechanism already present in the DNS, in order to discover that e.g. "cea.cea.atlas.fr.x400" is in fact the same domain as "cea.fr". This has two advantages: * the same tree can be used at the lower levels, * there is no need for a specific "to-rfc" record. This can also introduce my second remark, regarding routing and the choice of gateways. If the naming heirarchies are in the same tree, there is no need of inventing new routing mechanisms; you can as well use the MX records! Indeed, there is at that point the need to support X.400, hence the need to define a PSAP record associated to the MX host, but this may be another matter... My other remarks are much in the same line as Steve. I don't see much need for a preference counter in the "to-x400" records, and I don't see why the wildcarding mechanism should be different from the one used for the MX records... Christian Huitema From cole@dip.cs.wisc.edu Thu Jul 19 22:36:24 1990 Received: from dip.cs.wisc.edu by janeb.cs.wisc.edu; Thu, 19 Jul 90 22:36:24 -0500 Date: Thu, 19 Jul 90 22:35:37 -0500 From: cole@dip.cs.wisc.edu (Bruce Cole) Message-Id: <9007200335.AA15529@dip.cs.wisc.edu> Received: by dip.cs.wisc.edu; Thu, 19 Jul 90 22:35:37 -0500 To: harald.alvestrand@elab-runit.sintef.no Cc: hagens@dip.cs.wisc.edu, Christian.Huitema@mirsa.inria.fr, S.Kille@cs.ucl.ac.uk, cole@dip.cs.wisc.edu, rare-wg1@switch.ch, ietf-osi-or@dip.cs.wisc.edu, namedroppers@nic.ddn.mil In-Reply-To: Harald Tveit Alvestrand's message of , 19 Jul 90 11:56 +0100 Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings Status: O > Rob et al: > Your proposal requires (as far as I can see) > the registration of new toplevel domains C$no, C$us and so on. > Maybe we should follow Christian's proposal (I recognize the idea from > the MAILWAY code....), and put a single toplevel domain with name "X400" > or even "RFC987TABLE"????? If a new address class is used for the RFC987 mapping data, then adding an extra level to the DNS tree seems unnecessary. In this case, root nameservers would be registered as authoritative for the new address class. These root nameservers do not need to be the same as the root nameservers for the internet address class. If the internet address class is used for the RFC987 mapping data, then storing the new domains within a dummy top level domain seems desirable from an administrative point of view. > The administrative authority for the subdomains of this descends naturally > on the RARE MHS managers, since most of the national X.400 authorities > (whatever that is) will probably not even know what a DNS is. And if a new address class is used, then the RARE MHS managers could also be authoritative for the root nameservers of the new address class. > Second note: I have never seen a DNS name with a space in it. > The proposal (and RFC987 tables!) depend on $ and . being absent from > the attributes (or escaped, see the troubles with uk.ac!). With > X.400/88 we get every character under the sun into the addresses. > Is this problem generally solved by using (numeric)? Section 3.3.3 of RFC987 defines how special characters within O/R addresses can be represented as (DNS safe) ascii characters for X.400/84. RFC1138 has a similar section which applies to X.400/88. In both, parenthesized numbers representing ascii codes are used to encode special characters. > Does DNS handle a name of the form > > dom(number)dom.gurba . > > correctly? (parentheses and space!) Yes, for example I can add a resource record to my BIND nameserver that looks like: example in mx 0 dom(number)dom.gur\ ba. or example in mx 0 "dom(number)dom.gur ba." and when I query my nameserver I get: dip(cole): host -a example Trying domain "cs.wisc.edu" rcode = 0 (Success), ancount=1 example.cs.wisc.edu 86400 IN MX 0 dom(number)dom.gur ba dip(cole): Bruce Cole Computer Sciences Dept. U. of Wisconsin - Madison From harald.alvestrand@elab-runit.sintef.no Fri Jul 20 05:17:57 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Fri, 20 Jul 90 05:17:57 -0500 Received: from tosca.er.sintef.no by cs.wisc.edu; Fri, 20 Jul 90 05:17:27 -0500 Received: from localhost by tosca.er.sintef.no (5.61+IDA/KTH/LTH/1.4) with SMTP id AAtosca09951; Fri, 20 Jul 90 12:16:58 +0200 Received: from /PRMD=uninett/ADMD=_/C=no/ by tosca.elab-runit.sintef.no with X.400 id tosca.648469023; relayed; Fri, 20 Jul 90 12:16:50 +0200 Date: Fri, 20 Jul 90 12:16:50 +0200 From: Harald Tveit Alvestrand In-Reply-To: <2511*Eppenberger@verw.switch.ch> To: "Urs Eppenberger" Cc: , , , , Subject: Proposal for use of DNS to store RFC 987, etc mappings Message-Id: <1199*harald.alvestrand@elab-runit.sintef.no> Status: O ad performance and nameserver queries: does it take modification of my local nameserver to cache the new-address- class/new-type records? if YES: who will take responsibility for updating NS SW & distributing fixed sources? From Eppenberger@verw.switch.ch Fri Jul 20 05:12:16 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Fri, 20 Jul 90 05:12:16 -0500 Received: from chx400.switch.ch by cs.wisc.edu; Fri, 20 Jul 90 05:12:02 -0500 Received: by chx400.switch.ch (5.61/Ultrix2.4-C) id AA05465; Fri, 20 Jul 90 11:27:42 +0200 Date: 20 Jul 90 9:06 +0100 From: "Urs Eppenberger" To: Cc: rare-wg1@verw.switch.ch, , , In-Reply-To: <9007161446.AA08340@janeb.cs.wisc.edu> Message-Id: <2511:Eppenberger@verw.switch.ch> Subject: Proposal for use of DNS to store RFC 987, etc mappings Status: O Dear Rob, It was important to start some thoughts on how the coordination problem for the RFC987 tables could be solved. Your porposal is a very valid input to that discussion, thanks a lot. (I'm the MHS coordinator for the Swiss X.400 academic network SWITCHmail, which includes several RFC987 gateways and I know personally the problems of keeping the tables up to date :-| .) Just let me do two comments: a) RARE WG1 does not coordinate the RFC987 tables. Actually it is done by the RARE MHS project team at Sintef in Norway. In the near future this job will be handed over to COSINE S2.1 or S2.2. I suggest therefore to delete the corresponding parts in your proposal und replace it with a 'neutral' term, i.e. RFC987 gateway table coordination group, ... Perhaps your proposal will getthe status of a standard and then it is important not to fix who will collect the tables. b) As we actually suffer from recource intensive gatewaying software (in terms of CPU power and maintenance) I'm very concerned about how performant an implementation following your proposal will be. I suggest you to add a small chapter which studies the performance issue. (The WG1 distribution list contains 60 addresses from ca 40 different domains which forces the gateway to collect 60 MX records from 40 different name servers. How long will it need to translate the message? A table driven mechanism will surely be faster.) (But clever implementation of your proposal could easily be faster than the software we use actually :-) :-( .) Kind regards, Urs. From S.Kille@cs.ucl.ac.uk Mon Jul 23 06:47:05 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Mon, 23 Jul 90 06:47:05 -0500 Received: from bells.cs.ucl.ac.uk by cs.wisc.edu; Mon, 23 Jul 90 06:46:45 -0500 Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id ; Mon, 23 Jul 1990 12:45:03 +0000 To: hagens Cc: rare-wg1@switch.ch, ietf-osi-or, namedroppers@nic.ddn.mil, cole Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings Phone: +44-71-380-7294 In-Reply-To: Your message of Wed, 18 Jul 90 12:28:55 -0400. <9007181728.AA00340@janeb.cs.wisc.edu> Date: Mon, 23 Jul 90 12:45:01 +0100 Message-Id: <715.648733501@UK.AC.UCL.CS> From: Steve Kille Status: O You ask: "In general tho, do you think the coordination of the tables and server config files is feasible?" I believe that the answer is no. My conclusion, regrettably, is that we should continue and evoklve the table based approach. Steve From hagens Mon Jul 23 10:18:53 1990 Message-Id: <9007231518.AA06251@janeb.cs.wisc.edu> Received: from localhost by janeb.cs.wisc.edu; Mon, 23 Jul 90 10:18:53 -0500 To: ietf-osi-or Subject: agenda Date: Mon, 23 Jul 90 10:18:52 EDT From: hagens Status: O PRELIMINARY AGENDA IETF-OSI-OR Meeting -- Thursday morning Vancouver IETF The meeting will focus on the review/discussion of three subjects: The Draft Proposal for the use of the Internet DNS to maintain RFC 987/RFC 1148 Address Mapping Tables. This document has been circulated on several mailing lists. A few copies will be available at the meeting. The structure of O/R Addresses used by the Wisconsin Pilot X.400 project; specifically, the mechanisms to be introduced that allow non-X.400 users (i.e., RFC 822 mail users) to address X.400 users. The proposed pilot activity using office document architecture facilities from University College London and the PODA project. Rob From vcerf@NRI.Reston.VA.US Tue Jul 24 15:36:12 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Tue, 24 Jul 90 15:36:12 -0500 Received: from NRI.RESTON.VA.US by cs.wisc.edu; Tue, 24 Jul 90 15:35:57 -0500 Received: from [127.0.0.1] by NRI.NRI.Reston.VA.US id aa10501; 24 Jul 90 16:27 EDT To: Steve Kille Cc: hagens, rare-wg1@switch.ch, ietf-osi-or, namedroppers@nic.ddn.mil, cole, vcerf@NRI.Reston.VA.US Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings In-Reply-To: Your message of Tue, 17 Jul 90 08:59:27 +0100. <1217.648201567@UK.AC.UCL.CS> Date: Tue, 24 Jul 90 16:27:40 -0400 From: vcerf@NRI.Reston.VA.US Message-Id: <9007241627.aa10501@NRI.NRI.Reston.VA.US> Status: O At the risk of injecting myself into this discussion late and without adequate preparation, it seems to me that the proposal that Rob makes has some of the features of the host.txt and DNS situation in the Internet. In that case, there are some (many?) hosts which the hosts.txt users cannot reach because there is no MX capability in the tables. Perhaps there are hosts in the tables which are not in DNS servers (because of local hacking on the tables?). In any event, the situation is fairly painful because the two sources of data (host.txt and DNS) are not fully aligned. I gather than Steve Kille is concerned that this could happen in the RFC987/DNS proposal as well if tables and DNS services are required. Steve Kille, who is here at CNRI for a couple of days, wandered into my office just a little while ago and made the observation that not all 987 gateways can reach DNS (hence the need for tables). Since I am reading old mail (away for a week without adequate connectivity...), this could be an issue you've already dealt with, but I thought I would echo what I surmise to be Steve K's concern. Vint From stef@nma.com Wed Jul 25 04:57:37 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 25 Jul 90 04:57:37 -0500 Received: from nrtc.northrop.com by cs.wisc.edu; Wed, 25 Jul 90 04:57:25 -0500 Received: from nma.com by nrtc.nrtc.northrop.com id af16133; 25 Jul 90 2:56 PDT Received: from localhost by nma.com id aa04267; 25 Jul 90 2:06 PDT To: vcerf@nri.reston.va.us Cc: Steve Kille , hagens, rare-wg1@switch.ch, ietf-osi-or, namedroppers@nic.ddn.mil, cole Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings In-Reply-To: Your message of Tue, 24 Jul 90 16:27:40 -0400. <9007241627.aa10501@NRI.NRI.Reston.VA.US> Reply-To: Stef@nrtc.northrop.com From: Einar Stefferud Date: Wed, 25 Jul 90 02:05:46 -0700 Message-Id: <4263.648896746@nma.com> Sender: stef@nma.com Status: O Your point (and Steve's) about synch between RFC987/1148 mappings in DNS and in the necessary TABLES around rthe world for those who do not have DNS access is indeed a well foudned problem and worthy of serious discussion. Question: Is it possible to devise some way to build the TABLES from the DNS records on some regular basis, rather than to just not really try (as seems to be the way we arrived at the current DNS vs NIC-TABLES situation). I fear that the only alernative so far advanced it for everyone to use the RFC987 TABLES, and forego use of DNS...\Stef From hagens Wed Jul 25 09:53:35 1990 Received: from parmesan.cs.wisc.edu by janeb.cs.wisc.edu; Wed, 25 Jul 90 09:53:35 -0500 Received: from janeb.cs.wisc.edu by parmesan.cs.wisc.edu; Wed, 25 Jul 90 09:53:29 -0500 Message-Id: <9007251452.AA09940@janeb.cs.wisc.edu> Received: from localhost by janeb.cs.wisc.edu; Wed, 25 Jul 90 09:52:19 -0500 To: Stef@nrtc.northrop.com Cc: vcerf@nri.reston.va.us, Steve Kille , hagens@parmesan.cs.wisc.edu, rare-wg1@switch.ch, ietf-osi-or@parmesan.cs.wisc.edu, namedroppers@nic.ddn.mil, cole@parmesan.cs.wisc.edu Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings In-Reply-To: Your message of "25 Jul 90 12:00:00 BST." <4263.648896746@nma.com> Date: Wed, 25 Jul 90 09:52:17 EDT From: hagens Status: O > > > Your point (and Steve's) about synch between RFC987/1148 mappings in DNS > and in the necessary TABLES around rthe world for those who do not have > DNS access is indeed a well foudned problem and worthy of serious > discussion. > > Question: Is it possible to devise some way to build the TABLES from > the DNS records on some regular basis, rather than to just not really > try (as seems to be the way we arrived at the current DNS vs NIC-TABLES > situation). The zone transfer operation was designed for just such a purpose. It allows one to snarf a piece of the DNS tree from a server. It is possible (although resource intensive) to have a single site snarf ALL the 987 mappings from the entire DNS system. Once this data was in hand, the mapping table could be built. If this site was the one responsible for the worldwide tables, I think table/DNS coordination would be minimized. Rob ps. obviously, such a resource intensive operation would run infrequently. From MAINTCMS@PUCC.BitNet Wed Jul 25 10:03:56 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 25 Jul 90 10:03:56 -0500 Received: from vms3.macc.wisc.edu by cs.wisc.edu; Wed, 25 Jul 90 10:03:26 -0500 Received: from PUCC.PRINCETON.EDU by WISCMACC.BitNet; Wed, 25 Jul 90 09:57 CDT Received: from PUCC by PUCC.PRINCETON.EDU (Mailer R2.08A) with BSMTP id 8829; Wed, 25 Jul 90 10:51:54 EDT Message-Id: <20072509574161@WISCMACC.BitNet> Date: Wed, 25 Jul 90 10:46:46 EDT From: John Wagner Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings To: Einar Stefferud , vcerf@nri.reston.va.US, stef@nma.com Cc: Steve Kille , hagens, rare-wg1@switch.CH, ietf-osi-or, namedroppers@nic.ddn.mil, cole In-Reply-To: Message of Wed, 25 Jul 90 02:05:46 -0700 from Status: O On Wed, 25 Jul 90 02:05:46 -0700 you said: >Your point (and Steve's) about synch between RFC987/1148 mappings in DNS >and in the necessary TABLES around rthe world for those who do not have >DNS access is indeed a well foudned problem and worthy of serious >discussion. >Question: Is it possible to devise some way to build the TABLES from >the DNS records on some regular basis, rather than to just not really >try (as seems to be the way we arrived at the current DNS vs NIC-TABLES >situation). >I fear that the only alernative so far advanced it for everyone to use >the RFC987 TABLES, and forego use of DNS...\Stef Will this synchronization problem be any worse than the problem caused by having multiple versions of the tables in use worldwide? My gut feeling is that the fewer copies of the table you have to distribute the better off you are. Wasn't the table distribution problem one of the justifications for domain name servers? From postel@venera.isi.edu Thu Jul 26 19:26:09 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Thu, 26 Jul 90 19:26:09 -0500 Received: from venera.isi.edu by cs.wisc.edu; Thu, 26 Jul 90 19:25:48 -0500 Received: from bel.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Thu, 26 Jul 90 17:22:16 -0700 Date: Thu, 26 Jul 90 17:26:37 PDT From: postel@venera.isi.edu Posted-Date: Thu, 26 Jul 90 17:26:37 PDT Message-Id: <9007270026.AA16028@bel.isi.edu> Received: by bel.isi.edu (4.1/4.0.3-4) id ; Thu, 26 Jul 90 17:26:37 PDT To: Stef@nrtc.northrop.com, hagens Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings Cc: S.Kille@cs.ucl.ac.uk, cole, ietf-osi-or, namedroppers@nic.ddn.mil, rare-wg1@switch.ch Status: O Hi. Say, i think something has gone off the track here. I thought that RFC-987 was for mapping between the Internet mail protocol as defined in RFCs 821 and 822, and the X.400 mail system. If that is the case then wouldn't any gateway that did RFC-987 be between the Internet and some part of the X.400 world? That is, won't any gateway that needs to do the RFC-987 mappings have one foot in the Internet, and therefore have access to the DNS? So why are we talking about hand crafted tables and all their problems? Why can't we use a distributes system like the DNS ??? [One could argue that we should use X.500 services to keep the mapping data since presumably the X.500 world is coextensive with the X.400 world, and all these gateways also have one foot in those worlds; but i won't make that arguement.] --jon. From pvm@venera.isi.edu Thu Jul 26 21:16:33 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Thu, 26 Jul 90 21:16:33 -0500 Received: from venera.isi.edu by cs.wisc.edu; Thu, 26 Jul 90 21:15:58 -0500 Posted-Date: Thu, 26 Jul 90 19:16:17 PDT Message-Id: <9007270211.AA02319@venera.isi.edu> Received: from poneria.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Thu, 26 Jul 90 19:11:51 -0700 To: hagens Cc: Stef@nrtc.northrop.com, vcerf@nri.reston.va.us, S.Kille@cs.ucl.ac.uk, rare-wg1%switch.ch%NIC.DDN.MIL@Cheeta.isi.edu, ietf-osi-or, namedroppers@nic.ddn.mil, cole Reply-To: pvm@venera.isi.edu Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings In-Reply-To: Your message of Wed, 25 Jul 90 09:52:17 -0400. <9007251452.AA09940@janeb.cs.wisc.edu> Date: Thu, 26 Jul 90 19:16:17 PDT From: Paul Mockapetris Status: O I must admit that I am very surprised at the direction this discussion has taken. For other applications, several of the participants have argued that the DNS lacks the power for various high-powered schemes and X.500 (or something else) was required. But now we seem to be hearing that the future belongs to fixed tables? Perhaps the tables should have line numbers in columns 73-80 as well? The main argument for fixed tables seems to be that they are required for some gateways without DNS access, hence they are always required, so why keep the data in two forms which can get out of synch and cause problems? [Extracting data for periodic table construction via DNS is possible at acceptable cost, modulo some transient inconsistencies, and these transient inconsistencies are the issue.] The main reason that the DNS is better than host tables is that it distributes the control of configuration data; if you lose a host, you can reconfigure your domain around it. The NIC delegates control of about 3000 domains today. The curve points up. The future is with distributed control. Any scheme that distributes control at an acceptable cost isn't atomic; it doesn't matter whether we are looking at X.500, DNS, or mail of update forms to a central table building organization. We should build robust mechanisms and learn to live with this now, rather than retreating. Some lower level comments: I would separate the function of translating between domain names and X.400 addresses from the function of binding a X.400 address to a list of MTAs or gateways. The preference field has proved useful in the Internet; I wouldn't discard it lightly. I would not muck with the DNS view of wildcards or add the level counting function to nameservers; the same function can be implemented using the existing system. One way to deal with the issue of component order is to just create a new syntax, using say "/" as a separator. Thus A.B would be just another way of saying B/A. The argument that says "MX shows that you cannot construct tables from the DNS" is not strictly correct. There were two things that happened: some hosts were listed in the DNS and not in HOSTS.TXT, and we added new functionality in MX. For the purposes of host name to address conversion, anyone could (or can) build scripts to make up a table of hosts, given the host names. The real problem is that we added new functionality which could not be expressed in HOSTS.TXT. Similarly, we could repeat the same backward compatibility problem here, but only if we add new bells an whistles. paul From stef@nma.com Thu Jul 26 23:36:40 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Thu, 26 Jul 90 23:36:40 -0500 Received: from nrtc.northrop.com by cs.wisc.edu; Thu, 26 Jul 90 23:36:25 -0500 Received: from nma.com by nrtc.nrtc.northrop.com id aa10843; 26 Jul 90 21:35 PDT Received: from localhost by nma.com id aa00158; 26 Jul 90 21:22 PDT To: pvm@venera.isi.edu, postel@venera.isi.edu Cc: hagens, vcerf@nri.reston.va.us, S.Kille@cs.ucl.ac.uk, rare-wg1%switch.ch%NIC.DDN.MIL@cheeta.isi.edu, ietf-osi-or, namedroppers@nic.ddn.mil, cole Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings In-Reply-To: Your message of Thu, 26 Jul 90 19:16:17 -0700. <9007270211.AA02319@venera.isi.edu> Reply-To: Stef@nrtc.northrop.com From: Einar Stefferud Date: Thu, 26 Jul 90 21:22:25 -0700 Message-Id: <154.649052545@nma.com> Sender: stef@nma.com Status: O Paul and Jon (One Msg to reply to you both) -- We have to recognize that we cannot build a system that requires full network connectivity for every gateway, cause we know full well that there will always be some significant set of hosts that will not have full network connectivity, hence we must provide for ways to provide the appropriate tables for the non-fully-network-connected hosts. Full Stop! Now that we have settled that point, what can or should we do to live with reality and keep our sanity too? One thing is to invent a table form of the information in the DNS that will carry its functionality (remember the MX problem that cannot be represented in HOSTS.TXT because HOSTS.TXT is not extensible). What is the problem with defining a table representation that has record types, ala DNS, so we can have one-for-one representation of the same information, and be as extensible in the tables as in the DNS? And, another thing to do is define a mapping of DNS information in an appropriate X.500 schema, which must likewise be just as extensible and facilitate one-for-one mapping of the same information in X.500 forms. Now, having said these relatively simple things, what am I missing here? What is wrong with my picture? (Aside from the fact that a little work must be done?) Best...\Stef;-) From Eppenberger@verw.switch.ch Fri Jul 27 02:45:08 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Fri, 27 Jul 90 02:45:08 -0500 Received: from chx400.switch.ch by cs.wisc.edu; Fri, 27 Jul 90 02:44:56 -0500 Received: by chx400.switch.ch (5.61/Ultrix2.4-C) id AA10951; Fri, 27 Jul 90 09:45:28 +0200 Date: 27 Jul 90 9:37 +0100 From: "Urs Eppenberger" To: postel@venera.isi.edu Cc: Stef@nrtc.northrop.com, hagens, S.Kille@cs.ucl.ac.uk, cole, ietf-osi-or, namedroppers@nic.ddn.mil, rare-wg1@switch.ch In-Reply-To: <9007270026.AA16028@bel.isi.edu> Message-Id: <2528:Eppenberger@verw.switch.ch> Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings Status: O Dear --jon. the use of RFC822 is not restriced to the Internet, there are SMTP networks without connection to Internet and they also need to have gateways between RFC822 and X.400. Urs. From piet@cwi.nl Fri Jul 27 11:21:43 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Fri, 27 Jul 90 11:21:43 -0500 Received: from piring.cwi.nl by cs.wisc.edu; Fri, 27 Jul 90 11:21:24 -0500 Received: by piring.cwi.nl with SMTP; Fri, 27 Jul 90 18:20:38 +0200 (MET) Message-Id: <9007271620.AA29144@piring.cwi.nl> To: postel@venera.isi.edu In-Reply-To: Your message of 27 Jul 90 2:27 +0100 . <9007270026.AA16028@bel.isi.edu> Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings Cc: S.Kille@cs.ucl.ac.uk, cole, ietf-osi-or, namedroppers@nic.ddn.mil, rare-wg1@switch.ch, Stef@nrtc.northrop.com, hagens Date: Fri, 27 Jul 90 18:20:37 +0200 From: Piet Beertema Status: O I thought that RFC-987 was for mapping between the Internet mail protocol as defined in RFCs 821 and 822, and the X.400 mail system. Correct. If that is the case then wouldn't any gateway that did RFC-987 be between the Internet and some part of the X.400 world? Definitely not: mapping between a protocol and some other world does not necessarily imply gatewaying between one particular network and some other world, even when that network happens to be the originator and largest user of that particular protocol. That is, won't any gateway that needs to do the RFC-987 mappings have one foot in the Internet, and therefore have access to the DNS? No. Gateways following RFC-987 may well operate between parts of the X.400 world and networks that are using the "Internet mail protocol as defined...." but that do not necessarily have access to the Internet and thus to the Internet-wide DNS. Piet From postel@venera.isi.edu Fri Jul 27 12:04:36 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Fri, 27 Jul 90 12:04:36 -0500 Received: from venera.isi.edu by cs.wisc.edu; Fri, 27 Jul 90 12:04:23 -0500 Received: from bel.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Fri, 27 Jul 90 10:00:00 -0700 Date: Fri, 27 Jul 90 10:04:18 PDT From: postel@venera.isi.edu Posted-Date: Fri, 27 Jul 90 10:04:18 PDT Message-Id: <9007271704.AA19586@bel.isi.edu> Received: by bel.isi.edu (4.1/4.0.3-4) id ; Fri, 27 Jul 90 10:04:18 PDT To: Stef@nrtc.northrop.com, piet@cwi.nl Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings Cc: S.Kille@cs.ucl.ac.uk, cole, hagens, ietf-osi-or, namedroppers@nic.ddn.mil, postel@venera.isi.edu, pvm@venera.isi.edu, rare-wg1%switch.ch%NIC.DDN.MIL@cheeta.isi.edu, vcerf@nri.reston.va.us Status: O Stef,Piet: I am sorry, but i really don't get it yet. Could some one tell me about these networks that use RFC-822 and are not part of the Internet, and don't have access to the DNS? I could imagine such a situation, but i don't know of any actually existing. I really don't understand at all what Stef is getting at by "we cannot build a system that requires full network connectivity for every gateway". It seems crazy to me to imagine that we can have a gateways that are not connected to the network. And if "there will always be some significant set of hosts that will not have full network connectivity", lets be sure not to use them as gateways, and lets be sure that while we provide for them we do not limit the connected hosts to the lowest common denominator of mechanisms and procedures. --jon. From hagens Fri Jul 27 14:49:23 1990 Message-Id: <9007271949.AA12925@janeb.cs.wisc.edu> Received: from localhost by janeb.cs.wisc.edu; Fri, 27 Jul 90 14:49:23 -0500 To: postel@venera.isi.edu Cc: Stef@nrtc.northrop.com, piet@cwi.nl, S.Kille@cs.ucl.ac.uk, cole, ietf-osi-or, namedroppers@nic.ddn.mil, pvm@venera.isi.edu, rare-wg1%switch.ch%NIC.DDN.MIL@cheeta.isi.edu, vcerf@nri.reston.va.us Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings In-Reply-To: Your message of "Fri, 27 Jul 90 10:04:18 PDT." <9007271704.AA19586@bel.isi.edu> Date: Fri, 27 Jul 90 14:49:20 EDT From: hagens Status: O > > > I really don't understand at all what Stef is getting at by "we cannot > build a system that requires full network connectivity for every gateway". > It seems crazy to me to imagine that we can have a gateways that are not > connected to the network. Jon, I also found this hard to accept at first. But may I suggest the following scenario: There may be RFC 822 users on a "small internet" somewhere in the world, whose only email path into the Internet we know is via an X.400 mail system. In this scenerio, the isolated RFC 822 users would require an RFC 987/... gateway to operate, but that gateway would not have DNS access. I really can't say how contrived this scenerio truly is. > And if "there will always be some significant > set of hosts that will not have full network connectivity", lets be sure > not to use them as gateways, and lets be sure that while we provide for > them we do not limit the connected hosts to the lowest common denominator > of mechanisms and procedures. I agree with your last sentence; I believe that the DNS can greatly assist the 987 gateways that are connected to it. It seems that this benefit outweighs the hassel of producing a "hosts.txt" on a periodic basis for those non-connected sites. This *will* be a discussion item for the IETF-OSI-OR WG at the Vancouver IETF. (Thursday AM). Rob From stef@nma.com Fri Jul 27 18:57:23 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Fri, 27 Jul 90 18:57:23 -0500 Received: from nrtc.northrop.com by cs.wisc.edu; Fri, 27 Jul 90 18:56:59 -0500 Received: from nma.com by nrtc.nrtc.northrop.com id ab14960; 27 Jul 90 16:55 PDT Received: from localhost by nma.com id aa01446; 27 Jul 90 16:31 PDT To: postel@venera.isi.edu Cc: piet@cwi.nl, S.Kille@cs.ucl.ac.uk, cole, hagens, ietf-osi-or, namedroppers@nic.ddn.mil, pvm@venera.isi.edu, rare-wg1%switch.ch%NIC.DDN.MIL@cheeta.isi.edu, vcerf@nri.reston.va.us Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings In-Reply-To: Your message of Fri, 27 Jul 90 10:04:18 -0700. <9007271704.AA19586@bel.isi.edu> Reply-To: Stef@nrtc.northrop.com From: Einar Stefferud Date: Fri, 27 Jul 90 16:30:54 -0700 Message-Id: <1443.649121454@nma.com> Sender: stef@nma.com Status: O I should have been a bit more explicit. There is a big distinction to be made between being IP connected and non-IP connected. DNS access requires IP connectivity, end-to-end. Fully-conneccted == IP Connected, and implies DNS access via IP. Not-Fully-Connected == UUCP, or MMDF/phnoenet, or BITNET or connected, and implies no DNS access. Are you really saying that we should outlaw all connections for mail other than those with IP and DNS access? I certainly hope not! Are you saying that we should outlaw all gateways out there beyond the edge of the IP connected main Internet? I certainly hope not! Best...\Stef From stef@nma.com Sun Jul 29 21:38:07 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Sun, 29 Jul 90 21:38:07 -0500 Received: from nrtc.northrop.com by cs.wisc.edu; Sun, 29 Jul 90 21:37:59 -0500 Received: from nma.com by nrtc.nrtc.northrop.com id ad27106; 29 Jul 90 19:36 PDT Received: from localhost by nma.com id aa00127; 29 Jul 90 16:43 PDT To: mhsig@nrtc.northrop.com, rasig@nrtc.northrop.com, ORName Map , Electronic Mail Association <0002544290@mcimail.com>, AIA -- Steve York , AIA -- Steve Farowich Subject: Study Group D Meeting Annoucnement Reply-To: Stef@nrtc.northrop.com From: Einar Stefferud Date: Sun, 29 Jul 90 16:43:29 -0700 Message-Id: <125.649295009@nma.com> Sender: stef@nma.com Status: O In the enclosed Study Group D Meeting announcement, there is a sentence: "A secondary purpose of the meeting on August 13 will be to discuss and set up procedures for creating a registration scheme for ADMD and PRMD names, including any rules necessary to the assignment of O/R addresses and arrangements to promote maximum interoperability of domestic and international MHS systems." It seems likely that both ADMD and PRMD service providers, implementors and users might be interested. Best Regards...\Stef +++++++++++++++++++++++++++++++++++++++++++++++++++++++ Received from Gary Fereno of the US Department of State and transcribed by by Einar Stefferud for various interested parties. +++++++++++ Billing # 4710-07 Department of State THE U.S. ORGANIZATION FOR THE INTERNATIONAL TELEGRAPH AND TELEPHONE CONSULTATIVE COMMITTEE (CCITT) STUDY GROUP D Notice of Meeting The Department of State announces that Study Group D of the U.S. Organization for the International Telegraph and Telephone Consultative Committee (CCITT) will meet on August 13, 1990 at 10:00 AM in Room 1406, Department of State, 2201 C Street, N.W., Washington, D.C. The purpose of the meeting will be to review and approve contributions for the September meeting of the CCITT Study Group VIII, the October meeting of Study Group XVII, as well as the planned November Meeting of Study Group VII. A secondary purpose of the meeting on August 13 will be to discuss and set up procedures for creating a registration scheme for ADMD and PRMD names, including any rules necessary to the assignment of O/R addresses and arrangements to promote maximum interoperability of domestic and international MHS systems. Any other issues relevant to the U.S. Study Group D, including contributions, or advice to the September meeting of the ad-hoc Resolution 18 committee may also be considered. Members of the general public may attend the meeting and join in the discussion, subject to the instructions of the Chairman. Admittance of public members will be limited to the seating available. In that regard, entrance to the Department of State building is controlled and individual building passes are required for each attendee. Entry will be facilitated if arrangements are made in advance of the meeting. Prior to the meeting, persons who plan to attend should so advise the office of Mr.#Earl Barbely, State Department, Washington, D.C., telephone (202) 647-5220. All attendees must use the C Street entrance to the building. Date: July 10, 1990 Original Signed by: Earl S. Barbely, Director Office of Telecommunications and Information Standards; Chairman U.S. CCITT National Committee Drafted:CIP/TIS:ESBarbely:esf Cleared:FMP/MP:STait Wang # 1553x From piet@cwi.nl Mon Jul 30 02:45:51 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Mon, 30 Jul 90 02:45:51 -0500 Received: from piring.cwi.nl by cs.wisc.edu; Mon, 30 Jul 90 02:45:30 -0500 Received: by piring.cwi.nl with SMTP; Mon, 30 Jul 90 09:44:04 +0200 (MET) Message-Id: <9007300744.AA06114@piring.cwi.nl> To: postel@venera.isi.edu In-Reply-To: Your message of Fri, 27 Jul 90 10:04:18 PDT . <9007271704.AA19586@bel.isi.edu> Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings Cc: S.Kille@cs.ucl.ac.uk, cole, hagens, ietf-osi-or, namedroppers@nic.ddn.mil, pvm@venera.isi.edu, rare-wg1%switch.ch%NIC.DDN.MIL@cheeta.isi.edu, vcerf@nri.reston.va.us, Stef@nrtc.northrop.com Date: Mon, 30 Jul 90 09:44:03 +0200 From: Piet Beertema Status: O Could some one tell me about these networks that use RFC-822 and are not part of the Internet, and don't have access to the DNS? There are lots of such networks here in Europe. And lots of them are connected to EUnet: for WAN communications they use uucp, but on their internal network(s) they use TCP/IP, RFC-822 etc. Obviously, since they use uucp for WAN communications, they don't have access to the DNS. Piet From piet@cwi.nl Mon Jul 30 02:54:57 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Mon, 30 Jul 90 02:54:57 -0500 Received: from piring.cwi.nl by cs.wisc.edu; Mon, 30 Jul 90 02:54:49 -0500 Received: by piring.cwi.nl with SMTP; Mon, 30 Jul 90 09:54:27 +0200 (MET) Message-Id: <9007300754.AA06204@piring.cwi.nl> To: Stef@nrtc.northrop.com In-Reply-To: Your message of Fri, 27 Jul 90 16:30:54 -0700 . <1443.649121454@nma.com> Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings Cc: S.Kille@cs.ucl.ac.uk, cole, hagens, ietf-osi-or, namedroppers@nic.ddn.mil, pvm@venera.isi.edu, rare-wg1%switch.ch%NIC.DDN.MIL@cheeta.isi.edu, vcerf@nri.reston.va.us, postel@venera.isi.edu Date: Mon, 30 Jul 90 09:54:26 +0200 From: Piet Beertema Status: O There is a big distinction to be made between being IP connected and non-IP connected. DNS access requires IP connectivity, end-to-end. Not necessarily: network A may have IP connection that doesn't go beyond some external network B; if [a host on] network B has Internet access, network A has access to the DNS without there being full end-to-end IP connectivity. Fully-connected == IP Connected, and implies DNS access via IP. Not-Fully-Connected == UUCP, or MMDF/phnoenet, or BITNET or connected, and implies no DNS access. The case I gave above I would call semi-connected. Piet From rick@uunet.uu.net Tue Jul 31 08:45:19 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Tue, 31 Jul 90 08:45:19 -0500 Received: from uunet.UU.NET by cs.wisc.edu; Tue, 31 Jul 90 08:45:11 -0500 Received: by uunet.uu.net (5.61/1.14) id AA12681; Tue, 31 Jul 90 09:44:46 -0400 Date: Tue, 31 Jul 90 09:44:46 -0400 From: rick@uunet.uu.net (Rick Adams) Message-Id: <9007311344.AA12681@uunet.uu.net> To: piet@cwi.nl, postel@venera.isi.edu Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings Cc: S.Kille@cs.ucl.ac.uk, Stef@nrtc.northrop.com, cole, hagens, ietf-osi-or, namedroppers@nic.ddn.mil, pvm@venera.isi.edu, rare-wg1%switch.ch%NIC.DDN.MIL@cheeta.isi.edu, vcerf@nri.reston.va.us Status: O There are even networks that use RFC822 *AND* SMTP *AND* DNS that are not connected to the internet (they are blocked for "political" reasons at the gateways. "Political" could be as simple as not meeting the aceptable use policies of NSF). Requiring connected status for domains listed in the root servers makes no sense and cuases a fair amount of problems. (Sure require the nameservers to have conmnected status, but there's nothing gained by requiring the addresses they serve to be connected) The current policies on what gets into a root server etc needs to be reworked in a major way --rick From vcerf@NRI.Reston.VA.US Sat Aug 4 05:29:19 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Sat, 4 Aug 90 05:29:19 -0500 Received: from NRI.RESTON.VA.US by cs.wisc.edu; Sat, 4 Aug 90 05:29:04 -0500 Received: from [127.0.0.1] by NRI.NRI.Reston.VA.US id aa01734; 4 Aug 90 6:18 EDT To: hagens Cc: postel@venera.isi.edu, Stef@nrtc.northrop.com, piet@cwi.nl, S.Kille@cs.ucl.ac.uk, cole, ietf-osi-or, namedroppers@nic.ddn.mil, pvm@venera.isi.edu, rare-wg1%switch.ch%NIC.DDN.MIL@cheeta.isi.edu, vcerf@NRI.Reston.VA.US, vcerf@NRI.Reston.VA.US Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings In-Reply-To: Your message of Fri, 27 Jul 90 14:49:20 -0400. <9007271949.AA12925@janeb.cs.wisc.edu> Date: Sat, 04 Aug 90 06:18:25 -0400 From: vcerf@NRI.Reston.VA.US Message-Id: <9008040618.aa01734@NRI.NRI.Reston.VA.US> Status: O The scenario is real. I have learned that a number of private TCP/IP local area networks use RFC822 email but then need to get out via X.400 public services to the commercial email worls. These nets at NOT on the Internet! Vint From huitema@jerry.inria.fr Tue Aug 7 04:08:50 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Tue, 7 Aug 90 04:08:50 -0500 Received: from jerry.inria.fr by cs.wisc.edu; Tue, 7 Aug 90 04:08:34 -0500 Received: by jerry.inria.fr (5.61+++/IDA-1.2.8) id AA24509; Tue, 7 Aug 90 11:09:20 +0200 Message-Id: <9008070909.AA24509@jerry.inria.fr> To: "Urs Eppenberger" Cc: postel@venera.isi.edu, Stef@nrtc.northrop.com, hagens, S.Kille@cs.ucl.ac.uk, cole, ietf-osi-or, namedroppers@nic.ddn.mil, rare-wg1@switch.ch Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings In-Reply-To: Your message of 27 Jul 90 09:53:33 +0100. <2528*Eppenberger@verw.switch.ch> Date: Tue, 07 Aug 90 11:09:11 +0200 From: Christian Huitema Status: O Jon, Urs, Steve, ... I understand Steve remark that having both a DNS distributed table and a text file bears a risk of incoherency. I also understand that we have gateways between several networks, i.e. not only X.400 and the TCP-IP Internet, but also X.400 and Janet, or X.400 and BITNET. These gateways dont need IP connectivity to perform their function, hence dont necessarily have DNS access. However, one should observe that: * Building the text file from the DNS is easy and automatic, whilst building the text file from a collection of national files is painful and slow. * The DNS based solution guaranties correct mappings for all Internet sites, whilst the current solution is based on the timely activation of new tables every second month -- which means incorrect mappings in between. * The installation of these new files is difficult, as it requires the presence of an operator at a very precise date (the manual collection procedure guarantees the presence of a couple of syntax errors). Automatisation is a progress. * Although the BITNET and JANET gateway dont need DNS access, the national gateways in practice operate on more than two networks. For example, the French BITNET gateway has access to both TCP-IP and X.400. In short, I vote for going on with the DNS solution, and will incorporate support of the final design in a next version of Mailway. Christian Huitema From harald.alvestrand@elab-runit.sintef.no Tue Aug 7 07:11:41 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Tue, 7 Aug 90 07:11:41 -0500 Received: from tosca.er.sintef.no by cs.wisc.edu; Tue, 7 Aug 90 07:10:29 -0500 Received: from localhost by tosca.er.sintef.no (5.61+IDA/KTH/LTH/1.4) with SMTP id AAtosca23629; Tue, 7 Aug 90 14:08:24 +0200 Received: from /PRMD=uninett/ADMD=_/C=no/ by tosca.elab-runit.sintef.no with X.400 id tosca.650030919; relayed; Tue, 7 Aug 90 14:08:15 +0200 Date: Tue, 7 Aug 90 14:08:15 +0200 From: Harald Tveit Alvestrand In-Reply-To: <9008070909.AA24509@jerry.inria.fr> To: Christian Huitema Cc: Urs Eppenberger , , , , , , , , Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings Message-Id: <1311*harald.alvestrand@elab-runit.sintef.no> Status: O Thie CC list on these messages is getting long.... I support Christian's comments. I suggest that the RARE WG1 consider the proposal at the next meeting, and that we take the following action: available as soon as possible. We will NEED: It would be nice for it to have official RFC status. to make the tables on a regular basis. The RARE MHS Project Team is a natural candidate to make the tables, and I am investigating whether or not UNINETT can make the resources that are required for the name server available. Harald Tveit Alvestrand RARE MHS project leader From cargille@rivendell.cs.wisc.edu Wed Aug 8 15:04:02 1990 Received: from parmesan.cs.wisc.edu by janeb.cs.wisc.edu; Wed, 8 Aug 90 15:04:02 -0500 Received: from rivendell.cs.wisc.edu by parmesan.cs.wisc.edu; Wed, 8 Aug 90 15:03:59 -0500 From: cargille@rivendell.cs.wisc.edu (Allan Cargille) Message-Id: <9008082002.AA06006@rivendell.cs.wisc.edu> Received: by rivendell.cs.wisc.edu; Wed, 8 Aug 90 15:02:38 -0500 Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings To: harald.alvestrand@elab-runit.sintef.no (Harald Tveit Alvestrand) Date: Wed, 8 Aug 90 15:02:35 CDT Cc: huitema@jerry.inria.fr, Eppenberger@verw.switch.ch, postel@venera.isi.edu, Stef@nrtc.northrop.com, hagens@parmesan.cs.wisc.edu, S.Kille@cs.ucl.ac.uk, cole@parmesan.cs.wisc.edu, ietf-osi-or@parmesan.cs.wisc.edu, namedroppers@nic.ddn.mil, rare-wg1@switch.ch In-Reply-To: <1311*harald.alvestrand@elab-runit.sintef.no>; from "Harald Tveit Alvestrand" at Aug 7, 90 2:10 pm X-Mailer: ELM [version 2.2 PL13] Status: O [from Harald Alvestrand] > We will NEED: > - A new version of the memo, with all the "maybe"s replaced by "is". > It would be nice for it to have official RFC status. > - An organization that is willing to run the initial name server and > to make the tables on a regular basis. > The RARE MHS Project Team is a natural candidate to make the tables, and > I am investigating whether or not UNINETT can make the resources that > are required for the name server available. Hello Harald (and everybody), I agree with the "Needs" listed above. Rob Hagens is on holidays through this weekend, but I can say (for him) that a new version of the memo is being prepared and it will be submitted for RFC status. Wisconsin is another possible location for a name server. Bruce Cole, the other author of the memo, modified an early beta version of PP to support this lookup as part of his research. Steve, would UCL be interested in distributing this support in PP? We could also consider the possibility of making the necessary changes publicly available for PP. Note that this would take additional work by Bruce or someone else, as PP has changed since Bruce's initial work. Another point is that the software must deal with queuing in the case that the DNS lookup times out -- we would not want to lose the message or block everything else in the queue behind that message. allan From callon@bigfut.enet.dec.com Fri Aug 10 10:18:44 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Fri, 10 Aug 90 10:18:44 -0500 Received: from decpa.pa.dec.com by cs.wisc.edu; Fri, 10 Aug 90 10:18:38 -0500 Received: by decpa.pa.dec.com; id AA17107; Fri, 10 Aug 90 08:08:37 -0700 Message-Id: <9008101508.AA17107@decpa.pa.dec.com> Received: from bigfut.enet; by decwrl.enet; Fri, 10 Aug 90 08:18:31 PDT Date: Fri, 10 Aug 90 08:18:31 PDT From: callon@bigfut.enet.dec.com To: hagens, "ietf-osi-or@cs.wisc.edu"@decwrl.dec.com Subject: multimedia that's needed now Status: O I was just sitting down to read my mail this morning, when I started thinking what a pain in the posterior bodypart it was to deal with received mail that includes Postscript. First I have to extract the message into a file, then edit it to remove the extraneous mail header and footer, and then print it out, and then walk all the way over to the printer to pick it up, all before I can look at the first few lines and decide whether I really want to be bothered reading it. The obvious solution would be a mail program which displays postscript directly on the CRT. However, for normal SMTP mail, this would require some way to figure out where the normal text ended and the postscript starts. For X400, it is simple, just put the postscript in its own bodypart. The moral: If we want X400 use to take off, a very desireable refinement would be public domain software which runs on common UNIX/ULTRIX workstations which includes the ability to display postscript bodyparts directly on the screen. This is something that I would really like to use today. Ross From lazear@gateway.mitre.org Wed Sep 5 14:32:19 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 5 Sep 90 14:32:19 -0500 Received: from gateway.mitre.org by cs.wisc.edu; Wed, 5 Sep 90 14:32:07 -0500 Received: from dockside.mitre.org by gateway.mitre.org (5.61/SMI-2.2) id AA02739; Wed, 5 Sep 90 15:31:24 -0400 Return-Path: Received: by dockside.mitre.org (5.54/SMI-2.2) id AA10154; Wed, 5 Sep 90 15:30:29 EDT Date: Wed, 5 Sep 90 15:30:29 EDT From: lazear@gateway.mitre.org Message-Id: <9009051930.AA10154@dockside.mitre.org> To: ietf-osi-or Subject: Routing to OSI 987 gateway Cc: lazear@gateway.mitre.org Status: O Something that came up at the Vancouver IETF meeting has bothered me. So let me ask it out loud. How does a message from an OSI user to a TCP user get routed to a 987 gateway? The answer I thought I heard was "it uses the domain-defined attribute DDA-822" or some such. This has bothered me, because it seems to be hand waving...let me explain why I think there needs to be more definition of the semantics. I'll ignore some of the O/R fields (like admd and prmd) for simplification. If I specify an O/R name of /c=us/o=acme/pn=JDSmith/dda-822=jds@acme.com/ my mailer can tell by inspection that I mean this to go through a gateway. Or can it? Is the fact that I specified a few extra characters of perhaps extraneous info (the dda-822 part) enough to force routing to the gateway MTA? *Must* I leave it off to get delivery to an X.400 mailbox? If I specify an O/R name as above, but without the dda-822 part, it is reasonable for my mailer to look up my Directory Service entry (to get NSAPs or other info). What if it notices the dda-822 info in my DS entry? Does the presence of dda-822 info in my DS entry mean that all mail messages should be routed to my TCP mailbox through a gateway MTA? Walt Lazear From pv@Eng.Sun.COM Wed Sep 5 19:53:20 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 5 Sep 90 19:53:20 -0500 Received: from Sun.COM by cs.wisc.edu; Wed, 5 Sep 90 19:53:13 -0500 Received: from Eng.Sun.COM (exodus-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA28149; Wed, 5 Sep 90 17:53:07 PDT Received: from polya.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA13396; Wed, 5 Sep 90 17:53:06 PDT Received: by polya.Eng.Sun.COM (4.1/SMI-4.0-MHS-6.0) id AA17450; Wed, 5 Sep 90 17:53:04 PDT Date: Wed, 5 Sep 90 17:53:04 PDT From: pv@Eng.Sun.COM (Peter Vanderbilt) Message-Id: <9009060053.AA17450@polya.Eng.Sun.COM> To: lazear@gateway.mitre.org Subject: Re: Routing to OSI 987 gateway Cc: ietf-osi-or Status: O > How does a message from an OSI user to a > TCP user get routed to a 987 gateway? For destination addresses that are behind an RFC 987 gateway, you'd use either an address with a personal name (PN) or one with a DDA but not both. Using your example, the addresses might be /c=us/o=acme/pn=J.D.Smith/ or /c=us/o=acme/dd.rfc-822=jds(a)acme.com/ . The first stage of routing will be driven by the high order fields like country admd, prmd and org. The mailers at this stage will not know (or care) that the mail is going to a gateway. Once the mail has reached the destination domain, the software there decides whether to deliver directly to an X.400 mailbox or pass the mail to the gateway Some currently available gateways (like SunNet MHS 6.0), do not support X.400 UAs and so all mail addressed to such a domain is passed to the gateway. In this case, an address in DDA form will have it's value component extracted ("jds@acme.com"). An address in PN form (J.D.Smith) will be looked up in a local directory and mapped to an 822 address (at least that's the way our software does it). For systems that support both X.400 and 822 mailboxes, the decision about which mailbox to use may be based based on directory and configuration information available at the destination domain and may be based on the form of the address (PN or DDA). However, IMHO, the form of address should be independent of mailbox type -- the two addresses above should name the same mailbox and only the addressed user knows whether the mailbox is X.400 or 822. I hope this answers your questions. Pete From Alf.Hansen@pilot.cs.wisc.edu Thu Sep 6 11:28:04 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Thu, 6 Sep 90 11:28:04 -0500 Received: from kwai.inria.fr by cs.wisc.edu; Thu, 6 Sep 90 11:27:57 -0500 X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/; Relayed; 06 Sep 90 18:29:33+0100 X400-Received: by /PRMD=xnren/ADMD=_/C=us/; Relayed; 06 Sep 90 11:26:18-0500 Date: 06 Sep 90 11:26:18-0500 From: Alf Hansen Message-Id: <900906112615*Alf.Hansen@pilot.cs.wisc.edu> To: Peter Vanderbilt Cc: Alf.Hansen@pilot.cs.wisc.edu, ietf-osi-or, lazear@GATEWAY.MITRE.org, rd-mhs-managers@rare.no In-Reply-To: References: Subject: Re: Routing to OSI 987 gateway Status: O > > How does a message from an OSI user to a > > TCP user get routed to a 987 gateway? > > For destination addresses that are behind an RFC 987 gateway, you'd use > either an address with a personal name (PN) or one with a DDA but not > both. Using your example, the addresses might be > > /c=us/o=acme/pn=J.D.Smith/ or > /c=us/o=acme/dd.rfc-822=jds(a)acme.com/ . > > The first stage of routing will be driven by the high order fields like > country admd, prmd and org. The mailers at this stage will not know > (or care) that the mail is going to a gateway. I would like to try to explain how this is handled in the R&D MHS Service. An X.400 initiated message is kept in the X.400 world as long as possible. When reaching the destination country, it is up to the X.400 managers in that country to find out if the message is routed to an X.400 site or via an RFC 987 gateway. Even if the message reaches the X.400 destination site (destination organisation), the organisation may operate its own RFC 987 gateway(s), and route the message to this gateway inside the organisation. Please remember that when talking about X.400/Internet Mail-mailboxes traffic between them MUST pass an RFC 987 gateway. Another thing is to have different USER INTERFACES. If you have a clever X.400 implementation the X.400 message can be presented to the user on RFC 822 form, and simular, a clever Internet Mail-mailer can present an RFC 822 address on X.400 SA form. The X.400 service and the Internet Mail service are two different services and we need an RFC 987 gateway between them in order to minimise the loss functionality seen from a user's point of view. > Some currently available gateways (like SunNet MHS 6.0), do not support > X.400 UAs and so all mail addressed to such a domain is passed to the > gateway. In this case, an address in DDA form will have it's value > component extracted ("jds@acme.com"). An address in PN form > (J.D.Smith) will be looked up in a local directory and mapped to an 822 > address (at least that's the way our software does it). > A local directory is not enough. Each RFC 987 gateway must know ALL EXISTING MAPPING DEFINITIONS both from RFC 822 to X.400 and the other way around. Making this mapping information available to all RFC 987 gateway operators is essencial. Today this is done by the RARE MHS project based on manual procedures. People are investigating if we can define more automated procedures. > For systems that support both X.400 and 822 mailboxes, the decision > about which mailbox to use may be based based on directory and > configuration information available at the destination domain and may > be based on the form of the address (PN or DDA). However, IMHO, the > form of address should be independent of mailbox type -- the two > addresses above should name the same mailbox and only the addressed > user knows whether the mailbox is X.400 or 822. > In my opinion, a mailbox IS of one or the other type. It is the user's choise to be an Internet Mail user or an X.400 user. It is the service manager's challange to integrate these services such that the users not need to know if an address is pointing to an X.400 system or an RFC 822 system. Of course you can program nice software implementing both capabilities in the same software package. But from a functional point of view for each message arriving, the software is processing an X.400 message (P2) or an Internet mail message (SMTP). The challange to integrate these services is a matter of cooperation between the Internet Mail - and the X.400 Service managements: Harmonisation of addresses using the same naming authority, service agreements, information exchange, etc. Best regards, Alf H. --------------------------------------------------------------- Alf Hansen Computer Sciences Department University of Wisconsin-Madison 1210 West Dayton Street Direct Phone: Madison, Wisconsin 53706, USA +1 608 262-5084 Fax +1 608 262-9777 C=us; ADMD= ; PRMD=xnren; O=uw-madison; OU=cs; S=Hansen; G=Alf; Alf.Hansen@pilot.cs.wisc.edu --------------------------------------------------------------- From stef@nma.com Sat Sep 8 13:16:48 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Sat, 8 Sep 90 13:16:48 -0500 Received: from nrtc.northrop.com by cs.wisc.edu; Sat, 8 Sep 90 13:16:37 -0500 Received: from nma.com by nrtc.nrtc.northrop.com id ad10503; 8 Sep 90 11:15 PDT Received: from localhost by nma.com id aa08650; 8 Sep 90 10:13 PDT To: ORName Map , ietf-osi, rasig@nrtc.northrop.com Cc: Lyman Chapin , Vint Cerf Subject: INTEROP BOF on "OSI Registration Authority Issues" Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Sat, 08 Sep 90 10:12:51 -0700 Message-Id: <8647.652813971@nma.com> Sender: stef@nma.com Status: O "OSI Registration Authority Issues" - Oct 11, 1990 at 8:15-10:15 PM, in Room B-1, with 50 person capacity. I see three topics to be covered in this Birds-of-a-Feather Session: 1. X.400 Management Domain Names for ORAddresses; 2. NSAP addresses; and 3. Object Identifiers. I can cover the X.400 topics well enough for a brief tutorial and explanation of the issues, with a progress report on where things stand, and what remains to be done. Also some of what INTERNET folks can and should be doing about X.400 Mangement Domain Names. I am looking for someone to talk about the NSAP situation, and someone to talk about Object Identifiers. There has been considerable work and discussion on NSAP issues, so there should be someone out there who is willing and able to talk about it. Object Identifiers are a bit less well discussed. I suspect that Lyman Chapin would be a very good choice, if he will do it. If not, I need to find someone else. I hesitate to ask Vint Cerf to be a principle presenter here (too), but I do hope he will join us for the discussion. I am hoping for this to be an interactive discussion BOF, and not a bunch of tutorial presentations. I will be at the NIST OIW all next week (Sept 10-14) and I expect to see many of you there, so we can discuss the session. Cheers...\Stef From vcerf@NRI.Reston.VA.US Sun Sep 9 07:25:20 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Sun, 9 Sep 90 07:25:20 -0500 Received: from NRI.RESTON.VA.US by cs.wisc.edu; Sun, 9 Sep 90 07:25:13 -0500 Received: from [127.0.0.1] by NRI.NRI.Reston.VA.US id aa10889; 9 Sep 90 8:14 EDT To: Stef@ics.uci.edu Cc: ORName Map , ietf-osi, rasig@nrtc.northrop.com, Lyman Chapin , Vint Cerf Subject: Re: INTEROP BOF on "OSI Registration Authority Issues" In-Reply-To: Your message of Sat, 08 Sep 90 10:12:51 -0700. <8647.652813971@nma.com> Date: Sun, 09 Sep 90 08:14:33 -0400 From: vcerf@NRI.Reston.VA.US Message-Id: <9009090814.aa10889@NRI.NRI.Reston.VA.US> Status: O Stef, I will be tied up in IAB meetings during the day on the 11th of Oct and have dinner plans which may interfere with attending the BOF you have planned. As to NSAP presentation, I would suggest Richard Colella from NIST or perhaps Ross Callon from Digital. Incidently, Lyman may be tied up for the same reasons I am. Vint From S.Kille@cs.ucl.ac.uk Tue Sep 11 07:15:55 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Tue, 11 Sep 90 07:15:55 -0500 Received: from bells.cs.ucl.ac.uk by cs.wisc.edu; Tue, 11 Sep 90 07:15:48 -0500 Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id ; Tue, 11 Sep 1990 13:14:20 +0100 To: hagens Cc: rare-wg1@switch.ch, ietf-osi-or, namedroppers@nic.ddn.mil, cole Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings Phone: +44-71-380-7294 In-Reply-To: Your message of Wed, 18 Jul 90 12:28:55 -0400. <9007181728.AA00340@janeb.cs.wisc.edu> Date: Tue, 11 Sep 90 13:14:17 +0100 Message-Id: <1251.653055257@UK.AC.UCL.CS> From: Steve Kille Status: O This conversation has flowed on whilst I've been out of circulation for quite a long while. Let me try to summarise, and make a few points. 1) It is agreed that there is a need to have a table representation of the information. 2) IF the table can be derived from the DNS representation, then the DNS route is desirable for a number of reasons cited (esp. distributed management). Having the table a bit out of date is not a problem. 3) The "IF" in 2) is critical. Christian Huitema and Paul Mockapetris say that it is strightforward. Zone transfer has been mentioned - I understood that this was primarily designed for replicating data between servers, not for dumping out portions of the tree. I think that a procedure which required traversing the whole DNS tree would be prohibitively expensive. I'd like to see the table dumping procedure worked out, so we can see clearly if it is tractable. 4) If we go for DNS, there has to be a commitment to load all existing tables into the DNS tree. 5) I'd like to see how X.500 fits into this picture, before we close on a final decision. I'm likely to argue X.500 as the master location. I'm working on a spec of this, but it is not at the top of my stack. Steve From HUIZER@SURFNET.NL Tue Sep 11 08:57:51 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Tue, 11 Sep 90 08:57:51 -0500 Received: from vms3.macc.wisc.edu by cs.wisc.edu; Tue, 11 Sep 90 08:57:35 -0500 Received: from HEARNVAX.nic.SURFnet.nl by WISCMACC.BitNet; Tue, 11 Sep 90 08:53 CDT Received: from SURFnet.NL by HEARNVAX.nic.SURFnet.nl; Tue, 11 Sep 90 15:32 MET Message-Id: <36FC2780487FA0CE3E@HEARNVAX.nic.SURFnet.nl> Date: Tue, 11 Sep 90 15:22 MET From: Erik.Huizer@SURFNET.NL Sender: "Erik Huizer - SURFnet B.V. - Network Development" Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings To: S.Kille@cs.ucl.ac.uk, Rare WG1 , ietf-osi-or, namedroppers@nic.ddn.mil, cole X-Vms-To: IN%"S.Kille@cs.ucl.ac.UK" X-Envelope-To: ietf-osi-or@cs.WISC.EDU, cole@cs.WISC.EDU Comments: EARN/BITnet: HUIZER@HUTSUR51 Status: O Steve, You really missed out on something. Aren't you on the WG1 list, or do you (out of principle) refuse to read what goes overt the list :-) The RARE WG1 has discussed using DNS and X.500 for RFC-987 data extensively on the last meeting (last week). A subgroup of WG1 has made a proposal how this (fixed table-dns-x.500) fits together. This has been written down and send to the list by Hannes Lubich. It is the intention that the proposal will be discussed next week at the WG3 meeting, so you'd better read it. If you didn't get it let me know. Hannes will be there too to clarify on the proposal if necessary. (You see Urs was right the W in WG1 stands for working :-) Erik From S.Kille@cs.ucl.ac.uk Wed Sep 12 14:01:47 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 12 Sep 90 14:01:47 -0500 Received: from bells.cs.ucl.ac.uk by cs.wisc.edu; Wed, 12 Sep 90 14:01:37 -0500 Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id ; Wed, 12 Sep 1990 11:38:23 +0100 To: Erik.Huizer@SURFNET.nl Cc: Rare WG1 , ietf-osi-or, namedroppers@nic.ddn.mil, cole Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings Phone: +44-71-380-7294 In-Reply-To: Your message of Tue, 11 Sep 90 15:22:00 +0700. <36FC2780487FA0CE3E@HEARNVAX.nic.SURFnet.nl> Date: Wed, 12 Sep 90 11:38:11 +0100 Message-Id: <659.653135891@UK.AC.UCL.CS> From: Steve Kille Status: O >From: Erik.Huizer@nl.SURFNET >To: S.Kille@uk.ac.ucl.cs, Rare WG1 , ietf-osi-or@edu.wisc.cs, namedroppers@mil.ddn.nic, cole@edu.wisc.cs >Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings >Date: Tue, 11 Sep 90 15:22 MET >Comments: EARN/BITnet: HUIZER@HUTSUR51 >Steve, > >You really missed out on something. Aren't you on the WG1 list, or do you >(out of principle) refuse to read what goes overt the list :-) > Erik, You should know me better than this. I replied to the collection of messaages which had been circulated on this set of lists. I replied separaately on Hannes's useful note, which was circulated to the WG1 list only. Steve From S.Kille@cs.ucl.ac.uk Fri Sep 14 07:58:46 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Fri, 14 Sep 90 07:58:46 -0500 Received: from bells.cs.ucl.ac.uk by cs.wisc.edu; Fri, 14 Sep 90 07:58:40 -0500 Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id ; Fri, 14 Sep 1990 13:58:02 +0100 To: ORName Map , ifip-gtwy@tis.llnl.gov Subject: Interop BOF on RFC 822 / X.400 Mappings Phone: +44-71-380-7294 Date: Fri, 14 Sep 90 13:58:00 +0100 Message-Id: <1337.653317080@UK.AC.UCL.CS> From: Steve Kille Status: O I will be leadiong a Birds of the Feather Session at Interop 90 on RFC 822 / X.400 mapping. This will be 18:00 - 20:00 on Thursday 11th October. Some possible topics are: Suggestions for Agenda items (preferaby from those planning to participate) are welcome. Steve From stef@ICS.UCI.EDU Sun Sep 16 12:06:18 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Sun, 16 Sep 90 12:06:18 -0500 Received: from ics.uci.edu by cs.wisc.edu; Sun, 16 Sep 90 12:06:10 -0500 Received: from ics.uci.edu by ICS.UCI.EDU id aa03802; 16 Sep 90 9:51 PDT To: Steve Kille Cc: ORName Map , ifip-gtwy@ICS.UCI.EDU, MHSnews@ICS.UCI.EDU, ietf-osi, Bob Lynch , rasig@nrtc.northrop.COM Subject: Re: Interop BOF on RFC 822 / X.400 Mappings In-Reply-To: Your message of Fri, 14 Sep 90 13:58:00 +0100. <1337.653317080@UK.AC.UCL.CS> Reply-To: Stef@ICS.UCI.EDU From: Einar Stefferud Date: Sun, 16 Sep 90 09:51:03 -0700 Message-Id: <3799.653503863@ics.uci.edu> Sender: stef@ICS.UCI.EDU Status: O I will be chairing a Birds of the Feather Session at Interop 90 on OSI Registration. This will be 20:15 - 22:15 (if we can last that long) on Thursday 11th October. It follows Steve Kille's BOF - See Below. We have 3 main topics: 1. Registration of Identifiers for NSAP addresses (GOSIP & non-GOSIP) 2. Registration of Object -Identifiers (Orgs, Objects, Entities). 3. Registration of MHS Management Domain Names. (US-MTS & INTERNET) Each of these three name spaces are entierly independent, except for our choice to arbitrarily link them, if we so choose. We will discuss the status of registration in each of these name spaces, and consider what actions might be taken to improve the situation. A report fo the BOF will follow after INTEROP. Although we may have difficulty holding our discussion to registration isses, because the use of registered numbers is also very interesting and important, we will try very hard to keep to the main business of resolving registration issues. Your contributions to the Registration BOF will be appreciated...\Stef -------- Begin To: ORName Map , ifip-gtwy@tis.llnl.gov Subject: Interop BOF on RFC 822 / X.400 Mappings Phone: +44-71-380-7294 Date: Fri, 14 Sep 90 13:58:00 +0100 Message-Id: <1337.653317080@UK.AC.UCL.CS> From: Steve Kille I will be leading a Birds of the Feather Session at Interop 90 on RFC 822 / X.400 mapping. This will be 18:00 - 20:00 on Thursday 11th October. Some possible topics are: Suggestions for Agenda items (preferaby from those planning to participate) are welcome. Steve From hagens Wed Sep 19 17:03:45 1990 Message-Id: <9009192203.AA00123@janeb.cs.wisc.edu> Received: from localhost by janeb.cs.wisc.edu; Wed, 19 Sep 90 17:03:45 -0500 To: Steve Kille Cc: ORName Map , ifip-gtwy@tis.llnl.gov Subject: Re: Interop BOF on RFC 822 / X.400 Mappings In-Reply-To: Your message of "Fri, 14 Sep 90 13:58:00 BST." <1337.653317080@UK.AC.UCL.CS> Date: Wed, 19 Sep 90 17:03:35 EDT From: hagens Status: O > > > I will be leadiong a Birds of the Feather Session at Interop 90 on > RFC 822 / X.400 mapping. This will be 18:00 - 20:00 on Thursday 11th > October. > Steve, Alf Hansen and I will be at your BOF. I would like to suggest an agenda item: Discussion of our proposal to use the DNS to support 987/... mappings. I am working on a new version of this proposal and can distribute it a week or so before the BOF. Rob From ADMVM@DFNGATE.xnren.us Thu Sep 27 05:14:30 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Thu, 27 Sep 90 05:14:30 -0500 Received: from chx400.switch.ch by cs.wisc.edu; Thu, 27 Sep 90 05:14:17 -0500 Received: by chx400.switch.ch (5.61/Ultrix2.4-C) id AA08980; Thu, 27 Sep 90 12:15:34 +0200 Date: 27 Sep 90 9:45 From: Alf Hansen To: mabogen@dfngate.bitnet Cc: Alf.Hansen@pilot.cs.wisc.edu, ietf-osi-or, lazear@GATEWAY.MITRE.org, rd-mhs-managers@rare.no In-Reply-To: <9009060053.AA17450@polya.Eng.Sun.com> Message-Id: <900906112615*Alf.Hansen@pilot.cs.wisc.edu> References: <9009060053.AA17450@polya.Eng.Sun.com> Subject: Re: Routing to OSI 987 gateway Status: O > > How does a message from an OSI user to a > > TCP user get routed to a 987 gateway? > > For destination addresses that are behind an RFC 987 gateway, you'd use > either an address with a personal name (PN) or one with a DDA but not > both. Using your example, the addresses might be > > /c=us/o=acme/pn=J.D.Smith/ or > /c=us/o=acme/dd.rfc-822=jds(a)acme.com/ . > > The first stage of routing will be driven by the high order fields like > country admd, prmd and org. The mailers at this stage will not know > (or care) that the mail is going to a gateway. I would like to try to explain how this is handled in the R&D MHS Service. An X.400 initiated message is kept in the X.400 world as long as possible. When reaching the destination country, it is up to the X.400 managers in that country to find out if the message is routed to an X.400 site or via an RFC 987 gateway. Even if the message reaches the X.400 destination site (destination organisation), the organisation may operate its own RFC 987 gateway(s), and route the message to this gateway inside the organisation. Please remember that when talking about X.400/Internet Mail-mailboxes traffic between them MUST pass an RFC 987 gateway. Another thing is to have different USER INTERFACES. If you have a clever X.400 implementation the X.400 message can be presented to the user on RFC 822 form, and simular, a clever Internet Mail-mailer can present an RFC 822 address on X.400 SA form. The X.400 service and the Internet Mail service are two different services and we need an RFC 987 gateway between them in order to minimise the loss functionality seen from a user's point of view. > Some currently available gateways (like SunNet MHS 6.0), do not support > X.400 UAs and so all mail addressed to such a domain is passed to the > gateway. In this case, an address in DDA form will have it's value > component extracted ("jds@acme.com"). An address in PN form > (J.D.Smith) will be looked up in a local directory and mapped to an 822 > address (at least that's the way our software does it). > A local directory is not enough. Each RFC 987 gateway must know ALL EXISTING MAPPING DEFINITIONS both from RFC 822 to X.400 and the other way around. Making this mapping information available to all RFC 987 gateway operators is essencial. Today this is done by the RARE MHS project based on manual procedures. People are investigating if we can define more automated procedures. > For systems that support both X.400 and 822 mailboxes, the decision > about which mailbox to use may be based based on directory and > configuration information available at the destination domain and may > be based on the form of the address (PN or DDA). However, IMHO, the > form of address should be independent of mailbox type -- the two > addresses above should name the same mailbox and only the addressed > user knows whether the mailbox is X.400 or 822. > In my opinion, a mailbox IS of one or the other type. It is the user's choise to be an Internet Mail user or an X.400 user. It is the service anager's challange to integrate these services such that the users not need to know if an address is pointing to an X.400 system or an RFC 822 system. Of course you can program nice software implementing both capabilities in the same software package. But from a functional point of view for each message arriving, the software is processing an X.400 message (P2) or an Internet mail message (SMTP). The challange to integrate these services is a matter of cooperation between the Internet Mail - and the X.400 Service managements: Harmonisation of addresses using the same naming authority, service agreements, information exchange, etc. Best regards, Alf H. --------------------------------------------------------------- Alf Hansen Computer Sciences Department University of Wisconsin-Madison 1210 West Dayton Street Direct Phone: Madison, Wisconsin 53706, USA +1 608 262-5084 Fax +1 608 262-9777 C=us; ADMD= ; PRMD=xnren; O=uw-madison; OU=cs; S=Hansen; G=Alf; Alf.Hansen@pilot.cs.wisc.edu --------------------------------------------------------------- From ADMVM@DFNGATE.xnren.us Thu Sep 27 05:14:12 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Thu, 27 Sep 90 05:14:12 -0500 Received: from chx400.switch.ch by cs.wisc.edu; Thu, 27 Sep 90 05:14:03 -0500 Received: by chx400.switch.ch (5.61/Ultrix2.4-C) id AA08975; Thu, 27 Sep 90 12:15:22 +0200 Date: 27 Sep 90 9:45 From: Alf Hansen To: koch@ddagmd11.bitnet Cc: Alf.Hansen@pilot.cs.wisc.edu, ietf-osi-or, lazear@GATEWAY.MITRE.org, rd-mhs-managers@rare.no In-Reply-To: <9009060053.AA17450@polya.Eng.Sun.com> Message-Id: <900906112615*Alf.Hansen@pilot.cs.wisc.edu> References: <9009060053.AA17450@polya.Eng.Sun.com> Subject: Re: Routing to OSI 987 gateway Status: O > > How does a message from an OSI user to a > > TCP user get routed to a 987 gateway? > > For destination addresses that are behind an RFC 987 gateway, you'd use > either an address with a personal name (PN) or one with a DDA but not > both. Using your example, the addresses might be > > /c=us/o=acme/pn=J.D.Smith/ or > /c=us/o=acme/dd.rfc-822=jds(a)acme.com/ . > > The first stage of routing will be driven by the high order fields like > country admd, prmd and org. The mailers at this stage will not know > (or care) that the mail is going to a gateway. I would like to try to explain how this is handled in the R&D MHS Service. An X.400 initiated message is kept in the X.400 world as long as possible. When reaching the destination country, it is up to the X.400 managers in that country to find out if the message is routed to an X.400 site or via an RFC 987 gateway. Even if the message reaches the X.400 destination site (destination organisation), the organisation may operate its own RFC 987 gateway(s), and route the message to this gateway inside the organisation. Please remember that when talking about X.400/Internet Mail-mailboxes traffic between them MUST pass an RFC 987 gateway. Another thing is to have different USER INTERFACES. If you have a clever X.400 implementation the X.400 message can be presented to the user on RFC 822 form, and simular, a clever Internet Mail-mailer can present an RFC 822 address on X.400 SA form. The X.400 service and the Internet Mail service are two different services and we need an RFC 987 gateway between them in order to minimise the loss functionality seen from a user's point of view. > Some currently available gateways (like SunNet MHS 6.0), do not support > X.400 UAs and so all mail addressed to such a domain is passed to the > gateway. In this case, an address in DDA form will have it's value > component extracted ("jds@acme.com"). An address in PN form > (J.D.Smith) will be looked up in a local directory and mapped to an 822 > address (at least that's the way our software does it). > A local directory is not enough. Each RFC 987 gateway must know ALL EXISTING MAPPING DEFINITIONS both from RFC 822 to X.400 and the other way around. Making this mapping information available to all RFC 987 gateway operators is essencial. Today this is done by the RARE MHS project based on manual procedures. People are investigating if we can define more automated procedures. > For systems that support both X.400 and 822 mailboxes, the decision > about which mailbox to use may be based based on directory and > configuration information available at the destination domain and may > be based on the form of the address (PN or DDA). However, IMHO, the > form of address should be independent of mailbox type -- the two > addresses above should name the same mailbox and only the addressed > user knows whether the mailbox is X.400 or 822. > In my opinion, a mailbox IS of one or the other type. It is the user's choise to be an Internet Mail user or an X.400 user. It is the service anager's challange to integrate these services such that the users not need to know if an address is pointing to an X.400 system or an RFC 822 system. Of course you can program nice software implementing both capabilities in the same software package. But from a functional point of view for each message arriving, the software is processing an X.400 message (P2) or an Internet mail message (SMTP). The challange to integrate these services is a matter of cooperation between the Internet Mail - and the X.400 Service managements: Harmonisation of addresses using the same naming authority, service agreements, information exchange, etc. Best regards, Alf H. --------------------------------------------------------------- Alf Hansen Computer Sciences Department University of Wisconsin-Madison 1210 West Dayton Street Direct Phone: Madison, Wisconsin 53706, USA +1 608 262-5084 Fax +1 608 262-9777 C=us; ADMD= ; PRMD=xnren; O=uw-madison; OU=cs; S=Hansen; G=Alf; Alf.Hansen@pilot.cs.wisc.edu --------------------------------------------------------------- From hagens Thu Sep 27 17:43:29 1990 Message-Id: <9009272243.AA07277@janeb.cs.wisc.edu> Received: from localhost by janeb.cs.wisc.edu; Thu, 27 Sep 90 17:43:29 -0500 To: ietf-osi-or Subject: name change Date: Thu, 27 Sep 90 17:43:28 EDT From: hagens Status: O The list exploder 'ietf-osi-or@cs.wisc.edu' has been renamed to 'ietf-osi-x400@cs.wisc.edu'. The old exploder will still work for a while. As the directory service recording would say, "Please make a note of it" Thanks, rob From Alf.Hansen@pilot.cs.wisc.edu Thu Sep 27 17:31:39 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Thu, 27 Sep 90 17:31:39 -0500 Received: from nac.no by cs.wisc.edu; Thu, 27 Sep 90 17:31:01 -0500 Received: from localhost by nac.no (5.64+IDA/Babel-1.6/6.0) with SMTP id AAnac26105; Fri, 28 Sep 1990 00:30:33 +0200 Received: from /PRMD=xnren/ADMD=_/C=us/ by nac.no with X.400 id ; Thu, 27 Sep 1990 17:09:28 -0500 Date: Thu, 27 Sep 1990 17:09:28 -0500 From: Alf Hansen Message-Id: <900927170926*Alf.Hansen@pilot.cs.wisc.edu> To: Cc: , , , Subject: The NSF X.400 Pilot Project. Status: O Madison, 09/27/1990. Alf Hansen ================================================================ The NSF X.400 Pilot Project, an offer to PP operators in the US. ================================================================ PP Version 5.0 has just been announced. This is an important step forward in the X.400/Internet mail integration. The new version of PP together with ISODE will be a basic building block in our striving for better user services. At the University of Wisconsin-Madison, we are working on an X.400 Pilot Project with a 2 year grant from NSF. The goal of this project is to support adoption of X.400 in the Internet. One of our main activities is to operate an experimental (1984) X.400 service with full connectivity to the Internet Mail world. Our X.400 service is participating in the "R&D MHS Service" coordinated by the RARE MHS Project in Europe. Today we are connected to more than 20 countries using the X.400 protocols. More than 100,000 real X.400 users are interconnected and RFC 987 gateways are used to communicate with the non-X.400 community. The RARE MHS Project has established procedures for the operation of the international R&D MHS Service, for example, how to document the international service, how a new networking organization can join the service, how RFC 987 address mapping tables are to be produced and exchanged, how an RFC 987 gateway should be operated, the definition of an X.400 "Well Known Entry Point" (WEP) and how a WEP should be operated. International R&D MHS Service requirements are defined and there is an agreement on a template for international traffic statistics reports. A full understanding of the operational aspects of an international X.400 service interconnected with existing E-mail-services, and with a growing connectivity to the up-coming public X.400 services, has been developed through several years of experimentation, coordinated on the international level by RARE WG1 and the RARE MHS Project. The Wisconsin team working on the NSF X.400 Pilot Project has been actively involved both in the international service development and at the national US level; we are now ready to offer users of X.400 systems in the Internet community some of the services they need for a smooth introduction of X.400 side-by-side with the Internet Mail service. The PP-software will be an important element in this service. The NSF X.400 Pilot Project will operate as a PRMD for an experimental X.400 service in the Internet. Our PRMD (XNREN) will: * operate an ad hoc Naming Authority; participating organizations can register their X.400 Organizations (O) and Organizational Units (OU) * provide guidelines for definition of address mapping between RFC 822 addresses and X.400 Standard Attribute Addresses * provide guidelines for deployment of RFC 987 gateways, and advise organizations on procedures that must be followed * operate a central RFC 987 gateway available for those participating organizations who do not want to operate their own gateway * serve as the US contact point to the RARE MHS Project and to similar projects in other parts of the world * operate an X.400 WEP connecting the XNREN PRMD to other PRMDs and ADMDs participating in the R&D MHS Service throughout the world * perform the necessary US coordination of national RFC 987 address mapping tables. The US tables will be included in the international tables and distributed to all RFC 987 gateway operators * establish service procedures for XNREN, ensuring full internal and external connectivity * help support the implementation of connectivity to commercial X.400 services under the leadership of CNRI * develop and experiment with internal and external routing strategies * maintain and distribute the ARGO X.400 software package, available to a limited number of non-profit organizations * incorporate technical innovations into the X.400 experiment using PRMD XNREN as testbed (topics include: an international X.400-based FAX service, migration to X.400 1988, multimedia extensions, use of directory services, operation of X.400 over ISO TP4/CLNP and security extensions) * collect other's opinions about the many aspects in introducing X.400 into the Internet An important long-term goal of our project is to produce a plan for the future NREN PRMD. We invite all X.400 users in the US Internet and in particular all PP operators to join in as participants in our experimental XNREN service. Contact points: --------------- The following persons are working on the project: Allan.Cargille@pilot.cs.wisc.edu C=us/ADMD=[ ]/PRMD=xnren/O=UW-Madison/OU=cs/PN=Allan.Cargille Alf Hansen@pilot.cs.wisc.edu C=us/ADMD=[ ]/PRMD=xnren/O=UW-Madison/OU=cs/PN=Alf.Hansen The NSF X.400 Pilot Project is under the supervision of Larry.Landweber@pilot.cs.wisc.edu C=us/ADMD=[ ]/PRMD=xnren/O=UW-Madison/OU=cs/PN=Larry.Landweber Rob Hagens@pilot.cs.wisc.edu C=us/ADMD=[ ]/PRMD=xnren/O=UW-Madison/OU=cs/PN=Rob.Hagens The following addresses have been established as a common contact point for the project (operational from 9/28/90): ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + + + xnren-postmaster@cs.wisc.edu + + C=no/ADMD=[ ]/PRMD=edu/O=wisc/OU=cs/PN=xnren-postmaster + + + + Phone: +1 (608) 262-5084 + + Fax: +1 (608) 262-9777 + + + + Computer Sciences Department + + University of Wisconsin-Madison + + 1210 W Dayton Street + + Wisconsin 53706 + + USA + + + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From braden@venera.isi.edu Thu Sep 27 18:30:36 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Thu, 27 Sep 90 18:30:36 -0500 Received: from venera.isi.edu by cs.wisc.edu; Thu, 27 Sep 90 18:30:31 -0500 Received: from braden.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Thu, 27 Sep 90 16:30:25 -0700 Date: Thu, 27 Sep 90 16:30:14 PDT From: braden@venera.isi.edu Posted-Date: Thu, 27 Sep 90 16:30:14 PDT Message-Id: <9009272330.AA14257@braden.isi.edu> Received: by braden.isi.edu (4.1/4.0.3-4) id ; Thu, 27 Sep 90 16:30:14 PDT To: Alf.Hansen@pilot.cs.wisc.edu Subject: Re: The NSF X.400 Pilot Project. Cc: ietf-osi-x400 Status: O Alf, I have a very naive question. I notice that everyone mentioned in your message seems to have two different email addresses, one for SMTP and one for X.400. Is this in fact a property of your proposed mechanism, to cause each of us to have dual addresses? Is this necessary? Thanks, Bob Braden From S.Kille@cs.ucl.ac.uk Tue Oct 2 06:11:26 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Tue, 2 Oct 90 06:11:26 -0500 Received: from CS.UCL.AC.UK by cs.wisc.edu; Tue, 2 Oct 90 06:11:21 -0500 Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id ; Tue, 2 Oct 1990 12:07:14 +0100 To: braden@venera.isi.edu Cc: ietf-osi-x400 Subject: Re: The NSF X.400 Pilot Project. Phone: +44-71-380-7294 In-Reply-To: Your message of Thu, 27 Sep 90 16:30:14 -0700. <9009272330.AA14257@braden.isi.edu> Date: Tue, 02 Oct 90 12:07:11 +0100 Message-Id: <1083.654865631@UK.AC.UCL.CS> From: Steve Kille My model is that each user has a SINGLE mailbox, which might be in the X.400 or SMTP world. This will have an SMTP (RFC 822) representation, which is likely to be familiar and an X.400 attribute structured representation which may be less familiar. RFC 1148 describes how you map between these. Steve From pvm@venera.isi.edu Tue Oct 2 11:12:08 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Tue, 2 Oct 90 11:12:08 -0500 Received: from venera.isi.edu by cs.wisc.edu; Tue, 2 Oct 90 11:12:00 -0500 Posted-Date: Tue, 02 Oct 90 09:10:14 PDT Message-Id: <9010021610.AA12584@venera.isi.edu> Received: from poneria.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Tue, 2 Oct 90 09:10:57 -0700 To: Steve Kille Cc: braden@venera.isi.edu, ietf-osi-x400 Reply-To: pvm@venera.isi.edu Subject: Re: The NSF X.400 Pilot Project. In-Reply-To: Your message of Tue, 02 Oct 90 12:07:11 +0100. <1083.654865631@UK.AC.UCL.CS> Date: Tue, 02 Oct 90 09:10:14 PDT From: Paul Mockapetris > My model is that each user has a SINGLE mailbox, which might be in the > X.400 or SMTP world. This will have an SMTP (RFC 822) representation, > which is likely to be familiar and an X.400 attribute structured > representation which may be less familiar. RFC 1148 describes how you > map between these. > > Steve Steve, Is that a single mailbox with a single destination name used to address mail or a single mailbox with multiple destination names used to reach it, depending on the mail method to be used? paul From Alf.Hansen@pilot.cs.wisc.edu Tue Oct 2 15:09:12 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Tue, 2 Oct 90 15:09:12 -0500 Received: from nac.no by cs.wisc.edu; Tue, 2 Oct 90 15:09:00 -0500 Received: from localhost by nac.no (5.64+IDA/Babel-1.6/6.0) with SMTP id AAnac23569; Tue, 2 Oct 1990 21:08:38 +0100 Received: from /PRMD=uninett/ADMD=_/C=no/ by nac.no with X.400 id ; Tue, 2 Oct 1990 21:08:31 +0100 Received: by /PRMD=xnren/ADMD=_/C=us/; Tue, 2 Oct 1990 15:01:23 -0500 Date: Tue, 2 Oct 1990 15:01:23 -0500 From: Alf Hansen Message-Id: <901002150121*Alf.Hansen@pilot.cs.wisc.edu> To: Subject: Delayed answer to Bob Braden's question. I suddenly noticed that my first answer to Bob was not sent to the whole list. My appologies. Here it is. Alf H. ======================================================== Message -- (encoded size: 1766 bytes) Delivery id: hansen654533537.53hermit.cs.uw Delivery time: Sep 28, 1990 09:52:17 Ip-msg-id: 900928095008 From: "Alf Hansen" To: c=no/prmd=edu/o=isi/ou=venera/pn=braden Subject: Re: The NSF X.400 Pilot Project. In-reply-to: 9009272330.AA14257(a)braden.isi.edu Cc: c=no/prmd=edu/o=wisc/ou=cs/ou=rivendell/pn=x400-project-team Cross-references: 9009272330.AA14257(a)braden.isi.edu > Alf, > > I have a very naive question. I notice that everyone mentioned in > your message seems to have two different email addresses, one for > SMTP and one for X.400. Is this in fact a property of your proposed > mechanism, to cause each of us to have dual addresses? Is this > necessary? Bob, We can not expect that all RFC 822 mail systems can express an X.400 address given on standard attribute form, therefore, if we want RFC 822 users to send messages to X.400, we must tell them how the X.400 address should be represnted in RFC 822 form. And the other way around: We can not expect that all X.400 mail systems can express an RFC 822 address. Therfore we must tell them (the X.400 users) how the RFC 822 address should be represented in X.400. The two addresses given is pointing to the SAME mailbox, but the address is given in two forms. I agree that this is not an ideal situation, but we have to live with it until the world can agree upon ONE common international mapping between X.400 and RFC 822 addresses. If we have ONE common well known mapping, the users could easily guess the other form from the one given. Directory services integrated in the user interface would also help a lot, but they are not there... yet.. I hope this was clearifying. Best regards, Alf H From S.Kille@cs.ucl.ac.uk Wed Oct 3 02:59:39 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 3 Oct 90 02:59:39 -0500 Received: from bells.cs.ucl.ac.uk by cs.wisc.edu; Wed, 3 Oct 90 02:59:34 -0500 Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id ; Wed, 3 Oct 1990 08:59:09 +0100 To: pvm@venera.isi.edu Cc: braden@venera.isi.edu, ietf-osi-x400 Subject: Re: The NSF X.400 Pilot Project. Phone: +44-71-380-7294 In-Reply-To: Your message of Tue, 02 Oct 90 09:10:14 -0700. <9010021610.AA12584@venera.isi.edu> Date: Wed, 03 Oct 90 08:57:24 +0100 Message-Id: <376.654940644@UK.AC.UCL.CS> From: Steve Kille >Is that a single mailbox with a single destination name used to >address mail or a single mailbox with multiple destination names used >to reach it, depending on the mail method to be used? The latter, as X.400 has a different naming structure to RFC 822. Steve From hagens Fri Oct 5 12:55:47 1990 Message-Id: <9010051755.AA20135@janeb.cs.wisc.edu> Received: from localhost by janeb.cs.wisc.edu; Fri, 5 Oct 90 12:55:47 -0500 To: ietf-osi-x400, RARE-WG1@switch.ch Subject: New version of 987/DNS paper Date: Fri, 05 Oct 90 12:55:41 EDT From: hagens Here is the next version of the 987/DNS paper. Comments are welcome. If possible, please read this before Steve's bof at Interop. I will bring a few copies to Interop. rob %!PS-Adobe-1.0 %%Creator: janeb:hagens (Robert Hagens,,2621017,2515517) %%Title: stdin (ditroff) %%CreationDate: Fri Oct 5 12:50:10 1990 %%EndComments % Start of psdit.pro -- prolog for ditroff translator % Copyright (c) 1985,1987 Adobe Systems Incorporated. All Rights Reserved. % GOVERNMENT END USERS: See Notice file in TranScript library directory % -- probably /usr/lib/ps/Notice % RCS: $Header: /src/misc/transcript/lib/RCS/psdit.pro,v 1.5 90/04/12 11:45:51 tim Exp $ /$DITroff 180 dict def $DITroff begin /DocumentInitState [ matrix currentmatrix currentlinewidth currentlinecap currentlinejoin currentdash currentgray currentmiterlimit ] cvx def %% Psfig additions /startFig { /SavedState save def userdict maxlength dict begin currentpoint transform DocumentInitState setmiterlimit setgray setdash setlinejoin setlinecap setlinewidth setmatrix itransform moveto /ury exch def /urx exch def /lly exch def /llx exch def /y exch 72 mul resolution div def /x exch 72 mul resolution div def currentpoint /cy exch def /cx exch def /sx x urx llx sub div def % scaling for x /sy y ury lly sub div def % scaling for y sx sy scale % scale by (sx,sy) cx sx div llx sub cy sy div ury sub translate /DefFigCTM matrix currentmatrix def /initmatrix { DefFigCTM setmatrix } def /defaultmatrix { DefFigCTM exch copy } def /initgraphics { DocumentInitState setmiterlimit setgray setdash setlinejoin setlinecap setlinewidth setmatrix DefFigCTM setmatrix } def /showpage { initgraphics } def } def % Args are llx lly urx ury (in figure coordinates) /clipFig { currentpoint 6 2 roll newpath 4 copy 4 2 roll moveto 6 -1 roll exch lineto exch lineto exch lineto closepath clip newpath moveto } def % doclip, if called, will always be just after a `startfig' /doclip { llx lly urx ury clipFig } def /endFig { end SavedState restore } def /globalstart { % Push details about the enviornment on the stack. fontnum fontsize fontslant fontheight % firstpage mh my resolution slotno currentpoint pagesave restore gsave } def /globalend { grestore moveto /slotno exch def /resolution exch def /my exch def /mh exch def % /firstpage exch def /fontheight exch def /fontslant exch def /fontsize exch def /fontnum exch def F /pagesave save def } def %% end XMOD additions /fontnum 1 def /fontsize 10 def /fontheight 10 def /fontslant 0 def /xi {0 72 11 mul translate 72 resolution div dup neg scale 0 0 moveto /fontnum 1 def /fontsize 10 def /fontheight 10 def /fontslant 0 def F /pagesave save def}def /xiG {0 72 14 mul translate 72 resolution div dup neg scale 0 0 moveto /fontnum 1 def /fontsize 10 def /fontheight 10 def /fontslant 0 def F /pagesave save def}def /xiL {90 rotate 72 resolution div dup neg scale 0 0 moveto /fontnum 1 def /fontsize 10 def /fontheight 10 def /fontslant 0 def F /pagesave save def}def /@manualfeed {statusdict /manualfeed true put}def /PB{save /psv exch def currentpoint translate resolution 72 div dup neg scale 0 0 moveto}def /PE{psv restore}def /m1 matrix def /m2 matrix def /m3 matrix def /oldmat matrix def /tan{dup sin exch cos div}bind def /point{resolution 72 div mul}bind def /dround {transform round exch round exch itransform}bind def /xT{/devname exch def}def /xr{/mh exch def /my exch def /resolution exch def}def /xp{}def /xs{docsave restore end}def /xt{}def /xf{/fontname exch def /slotno exch def fontnames slotno get fontname eq not {fonts slotno fontname findfont put fontnames slotno fontname put}if}def /xH{/fontheight exch def F}bind def /xS{/fontslant exch def F}bind def /s{/fontsize exch def /fontheight fontsize def F}bind def /f{/fontnum exch def F}bind def /F{fontheight 0 le {/fontheight fontsize def}if fonts fontnum get fontsize point 0 0 fontheight point neg 0 0 m1 astore fontslant 0 ne{1 0 fontslant tan 1 0 0 m2 astore m3 concatmatrix}if makefont setfont .04 fontsize point mul 0 dround pop setlinewidth}bind def /X{exch currentpoint exch pop moveto show}bind def /N{3 1 roll moveto show}bind def /Y{exch currentpoint pop exch moveto show}bind def /S /show load def /ditpush{}def/ditpop{}def /AX{3 -1 roll currentpoint exch pop moveto 0 exch ashow}bind def /AN{4 2 roll moveto 0 exch ashow}bind def /AY{3 -1 roll currentpoint pop exch moveto 0 exch ashow}bind def /AS{0 exch ashow}bind def /MX{currentpoint exch pop moveto}bind def /MY{currentpoint pop exch moveto}bind def /MXY /moveto load def /cb{pop}def % action on unknown char -- nothing for now /n{}def/w{}def /p{pop showpage pagesave restore /pagesave save def}def /abspoint{currentpoint exch pop add exch currentpoint pop add exch}def /dstroke{currentpoint stroke moveto}bind def /Dg{gsave}def /Dgi{rlineto}def /Dgl{stroke grestore moveto}def /Dl{2 copy gsave rlineto stroke grestore rmoveto}bind def /arcellipse{oldmat currentmatrix pop currentpoint translate 1 diamv diamh div scale /rad diamh 2 div def rad 0 rad -180 180 arc oldmat setmatrix}def /Dc{gsave dup /diamv exch def /diamh exch def arcellipse dstroke grestore diamh 0 rmoveto}def /De{gsave /diamv exch def /diamh exch def arcellipse dstroke grestore diamh 0 rmoveto}def /Da{currentpoint /by exch def /bx exch def /fy exch def /fx exch def /cy exch def /cx exch def /rad cx cx mul cy cy mul add sqrt def /ang1 cy neg cx neg atan def /ang2 fy fx atan def cx bx add cy by add 2 copy rad ang1 ang2 arcn stroke exch fx add exch fy add moveto}def /Barray 200 array def % 200 values in a wiggle /D~{mark}def /D~~{counttomark Barray exch 0 exch getinterval astore /Bcontrol exch def pop /Blen Bcontrol length def Blen 4 ge Blen 2 mod 0 eq and {Bcontrol 0 get Bcontrol 1 get abspoint /Ycont exch def /Xcont exch def Bcontrol 0 2 copy get 2 mul put Bcontrol 1 2 copy get 2 mul put Bcontrol Blen 2 sub 2 copy get 2 mul put Bcontrol Blen 1 sub 2 copy get 2 mul put /Ybi /Xbi currentpoint 3 1 roll def def 0 2 Blen 4 sub {/i exch def Bcontrol i get 3 div Bcontrol i 1 add get 3 div Bcontrol i get 3 mul Bcontrol i 2 add get add 6 div Bcontrol i 1 add get 3 mul Bcontrol i 3 add get add 6 div /Xbi Xcont Bcontrol i 2 add get 2 div add def /Ybi Ycont Bcontrol i 3 add get 2 div add def /Xcont Xcont Bcontrol i 2 add get add def /Ycont Ycont Bcontrol i 3 add get add def Xbi currentpoint pop sub Ybi currentpoint exch pop sub rcurveto }for dstroke}if}def end /ditstart{$DITroff begin /nfonts 60 def % NFONTS makedev/ditroff dependent! /fonts[nfonts{0}repeat]def /fontnames[nfonts{()}repeat]def /docsave save def }def % character outcalls /oc {/pswid exch def /cc exch def /name exch def /ditwid pswid fontsize mul resolution mul 72000 div def /ditsiz fontsize resolution mul 72 div def ocprocs name known{ocprocs name get exec}{name cb} ifelse}def /fractm [.65 0 0 .6 0 0] def /fraction {/fden exch def /fnum exch def gsave /cf currentfont def cf fractm makefont setfont 0 .3 dm 2 copy neg rmoveto fnum show rmoveto currentfont cf setfont(\244)show setfont fden show grestore ditwid 0 rmoveto} def /oce {grestore ditwid 0 rmoveto}def /dm {ditsiz mul}def /ocprocs 50 dict def ocprocs begin (14){(1)(4)fraction}def (12){(1)(2)fraction}def (34){(3)(4)fraction}def (13){(1)(3)fraction}def (23){(2)(3)fraction}def (18){(1)(8)fraction}def (38){(3)(8)fraction}def (58){(5)(8)fraction}def (78){(7)(8)fraction}def (sr){gsave .05 dm .16 dm rmoveto(\326)show oce}def (is){gsave 0 .15 dm rmoveto(\362)show oce}def (->){gsave 0 .02 dm rmoveto(\256)show oce}def (<-){gsave 0 .02 dm rmoveto(\254)show oce}def (==){gsave 0 .05 dm rmoveto(\272)show oce}def end % DIThacks fonts for some special chars 50 dict dup begin /FontType 3 def /FontName /DIThacks def /FontMatrix [.001 0.0 0.0 .001 0.0 0.0] def /FontBBox [-220 -280 900 900] def% a lie but ... /Encoding 256 array def 0 1 255{Encoding exch /.notdef put}for Encoding dup 8#040/space put %space dup 8#110/rc put %right ceil dup 8#111/lt put %left top curl dup 8#112/bv put %bold vert dup 8#113/lk put %left mid curl dup 8#114/lb put %left bot curl dup 8#115/rt put %right top curl dup 8#116/rk put %right mid curl dup 8#117/rb put %right bot curl dup 8#120/rf put %right floor dup 8#121/lf put %left floor dup 8#122/lc put %left ceil dup 8#140/sq put %square dup 8#141/bx put %box dup 8#142/ci put %circle dup 8#143/br put %box rule dup 8#144/rn put %root extender dup 8#145/vr put %vertical rule dup 8#146/ob put %outline bullet dup 8#147/bu put %bullet dup 8#150/ru put %rule dup 8#151/ul put %underline pop /DITfd 100 dict def /BuildChar{0 begin /cc exch def /fd exch def /charname fd /Encoding get cc get def /charwid fd /Metrics get charname get def /charproc fd /CharProcs get charname get def charwid 0 fd /FontBBox get aload pop setcachedevice 40 setlinewidth newpath 0 0 moveto gsave charproc grestore end}def /BuildChar load 0 DITfd put %/UniqueID 5 def /CharProcs 50 dict def CharProcs begin /space{}def /.notdef{}def /ru{500 0 rls}def /rn{0 750 moveto 500 0 rls}def /vr{20 800 moveto 0 -770 rls}def /bv{20 800 moveto 0 -1000 rls}def /br{20 770 moveto 0 -1040 rls}def /ul{0 -250 moveto 500 0 rls}def /ob{200 250 rmoveto currentpoint newpath 200 0 360 arc closepath stroke}def /bu{200 250 rmoveto currentpoint newpath 200 0 360 arc closepath fill}def /sq{80 0 rmoveto currentpoint dround newpath moveto 640 0 rlineto 0 640 rlineto -640 0 rlineto closepath stroke}def /bx{80 0 rmoveto currentpoint dround newpath moveto 640 0 rlineto 0 640 rlineto -640 0 rlineto closepath fill}def /ci{355 333 rmoveto currentpoint newpath 333 0 360 arc 50 setlinewidth stroke}def /lt{20 -200 moveto 0 550 rlineto currx 800 2cx s4 add exch s4 a4p stroke}def /lb{20 800 moveto 0 -550 rlineto currx -200 2cx s4 add exch s4 a4p stroke}def /rt{20 -200 moveto 0 550 rlineto currx 800 2cx s4 sub exch s4 a4p stroke}def /rb{20 800 moveto 0 -500 rlineto currx -200 2cx s4 sub exch s4 a4p stroke}def /lk{20 800 moveto 20 300 -280 300 s4 arcto pop pop 1000 sub currentpoint stroke moveto 20 300 4 2 roll s4 a4p 20 -200 lineto stroke}def /rk{20 800 moveto 20 300 320 300 s4 arcto pop pop 1000 sub currentpoint stroke moveto 20 300 4 2 roll s4 a4p 20 -200 lineto stroke}def /lf{20 800 moveto 0 -1000 rlineto s4 0 rls}def /rf{20 800 moveto 0 -1000 rlineto s4 neg 0 rls}def /lc{20 -200 moveto 0 1000 rlineto s4 0 rls}def /rc{20 -200 moveto 0 1000 rlineto s4 neg 0 rls}def end /Metrics 50 dict def Metrics begin /.notdef 0 def /space 500 def /ru 500 def /br 0 def /lt 250 def /lb 250 def /rt 250 def /rb 250 def /lk 250 def /rk 250 def /rc 250 def /lc 250 def /rf 250 def /lf 250 def /bv 250 def /ob 350 def /bu 350 def /ci 750 def /bx 750 def /sq 750 def /rn 500 def /ul 500 def /vr 0 def end DITfd begin /s2 500 def /s4 250 def /s3 333 def /a4p{arcto pop pop pop pop}def /2cx{2 copy exch}def /rls{rlineto stroke}def /currx{currentpoint pop}def /dround{transform round exch round exch itransform} def end end /DIThacks exch definefont pop ditstart (psc)xT 576 1 1 xr 1(Times-Roman)xf 1 f 2(Times-Italic)xf 2 f 3(Times-Bold)xf 3 f 4(Times-BoldItalic)xf 4 f 5(Helvetica)xf 5 f 6(Helvetica-Bold)xf 6 f 7(Courier)xf 7 f 8(Courier-Bold)xf 8 f 9(Symbol)xf 9 f 10(DIThacks)xf 10 f 10 s 1 f xi %%EndProlog %%Page: 1 1 10 s 10 xH 0 xS 1 f 3 f 576 474(Draft)N 3571(October)X 3872(1990)X 1 f 2059 762(Draft)N 2249(Proposal)X 1606 942(for)N 1720(the)X 1838(use)X 1965(of)X 2052(the)X 2170(Internet)X 2440(DNS)X 2620(to)X 2702(maintain)X 1560 1032(RFC)N 1730(987/RFC)X 2042(1148)X 2222(Address)X 2505(Mapping)X 2814(Tables)X 1796 1212(Bruce)N 2008(Cole)X 2179 0.1801(\(cole@cs.wisc.edu\))AX 1694 1302(Robert)N 1932(Hagens)X 2193 0.1678(\(hagens@cs.wisc.edu\))AX 3 f 576 1521(1.)N 676(Introduction)X 1 f 776 1644(RFC987)N 1070(describes)X 1394(a)X 1455(set)X 1569(of)X 1661(mappings)X 1997(between)X 2290(the)X 2413(X.400)X 2636(\(1984\))X 2875(series)X 3083(of)X 3175(protocols)X 3498(and)X 3639(the)X 3762(RFC822)X 576 1734(mail)N 759(protocol,)X 1087(or)X 1195(protocols)X 1534(derived)X 1816(from)X 2013(RFC822.)X 2363(That)X 2550(document)X 2906(addresses)X 3254(conversion)X 3646(of)X 3753(services,)X 576 1824(addresses,)N 924(message)X 1216(envelopes,)X 1577(and)X 1713(message)X 2005(bodies)X 2234(between)X 2522(the)X 2640(two)X 2780(mail)X 2942(systems.)X 776 1947(This)N 939(draft)X 1112(is)X 1186(concerned)X 1538(with)X 1701(one)X 1838(aspect)X 2061(of)X 2150(RFC987;)X 2464(the)X 2584(mechanism)X 2971(for)X 3087(mapping)X 3389(between)X 3679(X.400)X 3899(O/R)X 576 2037(addresses)N 915(and)X 1062(RFC822)X 1363(domain)X 1634(names.)X 1910(As)X 2030(described)X 2369(in)X 2462(Appendix)X 2809(F)X 2884(of)X 2982(RFC987,)X 3303(implementation)X 3836(of)X 3934(the)X 576 2127(mappings)N 909(requires)X 1190(a)X 1248(database)X 1547(which)X 1766(maps)X 1958(between)X 2249(X.400)X 2470(O/R)X 2626(addresses)X 2957(and)X 3096(RFC822)X 3389(addresses.)X 3760(A)X 3841(possi-)X 576 2217(ble)N 706(mechanism)X 1103(for)X 1229(use)X 1367(of)X 1465(the)X 1594(internet)X 1870(DNS)X 2061(to)X 2154(store,)X 2361(retrieve)X 2638(and)X 2785(maintain)X 3096(these)X 3292(mappings)X 3634(is)X 3718(proposed.)X 576 2307(This)N 738(mechanism)X 1123(is)X 1196(of)X 1283(potential)X 1583(use)X 1710(to)X 1792(internet)X 2057(hosts)X 2241(acting)X 2457(as)X 2544(X.400/RFC822)X 3054(gateways.)X 3 f 576 2493(1.1.)N 736(De\256nitions)X 1 f 10 f 576 2616(g)N 2 f 664(domain-name)X 1 f 776 2706(text)N 916(encoding)X 1230(of)X 1317(a)X 1373(domain)X 1633(name)X 10 f 576 2829(g)N 2 f 664()X 1 f 776 2919(Internet)N 1046(DNS)X 1226(encoding)X 1540(of)X 1627(a)X 1683(domain)X 1943(name,)X 2157(as)X 2244(de\256ned)X 2500(in)X 2582(RFC)X 2752(1035,)X 2952(section)X 3199(3.3)X 10 f 576 3042(g)N 2 f 664(owner-name)X 1 f 776 3132(The)N 922(name)X 1117(of)X 1205(a)X 1262(particular)X 1591(node)X 1768(in)X 1851(the)X 1970(DNS)X 2151(namespace)X 2525(to)X 2608(which)X 2826(one)X 2964(or)X 3053(more)X 3240(resource)X 3535(records)X 3794(belong.)X 776 3222(Also)N 947(known)X 1185(as)X 1272(the)X 1390(name)X 1584(\256eld)X 1746(of)X 1833(a)X 1889(DNS)X 2069(resource)X 2362(record.)X 10 f 576 3345(g)N 2 f 664(label)X 1 f 776 3435(A)N 855(set)X 965(of)X 1053(octets)X 1261(representing)X 1679(a)X 1736(domain)X 1997(name)X 2192(component,)X 2589(as)X 2677(introduced)X 3041(in)X 3124(RFC1035.)X 3495(\(A)X 3601(label)X 3779(consists)X 776 3525(of)N 870(a)X 933(one)X 1076(octet)X 1259(length)X 1485(\256eld)X 1653(followed)X 1964(by)X 2070(that)X 2216(number)X 2487(of)X 2580(octets.\))X 2860(Here,)X 3063(the)X 3187(allowable)X 3525(values)X 3756(for)X 3876(label)X 776 3615(octets)N 983(are)X 1102(extended)X 1412(to)X 1494(include)X 1750(all)X 1850(legal)X 2026(IA5)X 2171(characters.)X 10 f 576 3738(g)N 2 f 664(dmn-orname)X 1 f 776 3828(text)N 922(encoding)X 1242(of)X 1335(an)X 1437(O/R)X 1596(address)X 1863(represented)X 2260(by)X 2366(a)X 2428(series)X 2637(of)X 2730(labels,)X 2963(and)X 3105(terminated)X 3475(with)X 3644(a)X 3707(label)X 3890(with)X 776 3918(zero)N 959(length.)X 1223(This)X 1409(representation)X 1908(of)X 2019(X.400)X 2261(O/R)X 2438(addresses)X 2790(allows)X 3043(storage)X 3319(and)X 3478(retrieval)X 3789(of)X 3899(O/R)X 776 4008(addresses)N 1104(by)X 1204(the)X 1322(Internet)X 1592(DNS)X 1772(without)X 2036(syntactical)X 2399(extnesions)X 2757(to)X 2839(the)X 2957(DNS.)X 3 f 576 4194(2.)N 676(Motivation)X 1 f 776 4317(Implementations)N 1336(of)X 1425(RFC987)X 1717(gateways)X 2038(require)X 2289(that)X 2432(a)X 2491(database)X 2791(store)X 2970(address)X 3234(mapping)X 3537(information)X 3938(for)X 576 4407(X.400)N 797(and)X 936(RFC822.)X 1269(This)X 1434(information)X 1835(must)X 2013(be)X 2112(disseminated)X 2552(to)X 2636(all)X 2738(RFC987)X 3030(gateways.)X 3391(In)X 3480(the)X 3600(internet)X 3867(com-)X 576 4497(munity,)N 846(the)X 968(DNS)X 1152(has)X 1283(proven)X 1530(to)X 1616(be)X 1716(a)X 1776(practical)X 2077(means)X 2306(for)X 2424(providing)X 2759(a)X 2819(distributed)X 3186(nameservice.)X 3653(Advantages)X 576 4587(of)N 665(using)X 860(a)X 918(DNS)X 1100(based)X 1305(system)X 1549(over)X 1713(a)X 1770(table)X 1947(based)X 2151(approach)X 2467(for)X 2582(mapping)X 2883(between)X 3172(O/R)X 3326(addresses)X 3655(and)X 3792(domain)X 576 4677(names)N 801(are:)X 896 4800(1.)N 976(It)X 1045(avoids)X 1274(fetching)X 1557(and)X 1693(storing)X 1935(of)X 2022(entire)X 2225(mapping)X 2525(tables)X 2732(by)X 896 4890(every)N 1095(host)X 1248(that)X 1388(wishes)X 1626(to)X 1708(implement)X 2070(RFC987.)X 896 5070(2.)N 976(Modi\256cations)X 1440(to)X 1522(the)X 1640(DNS)X 1820(based)X 2023(mapping)X 2323(information)X 2721(can)X 2853(be)X 2949(made)X 896 5160(available)N 1206(in)X 1288(a)X 1344(more)X 1529(timely)X 1753(manner)X 2014(than)X 2172(with)X 2334(a)X 2390(table)X 2566(driven)X 2791(approach.)X 896 5340(3.)N 976(Table)X 1179(management)X 1609(is)X 1682(not)X 1804(necessarily)X 2181(required)X 2469(for)X 2583(DNS-based)X 2973(RFC987)X 896 5430(gateways.)N 896 5610(4.)N 976(One)X 1130(can)X 1262(determine)X 1603(the)X 1721(mappings)X 2052(in)X 2134(use)X 2261(by)X 2361(a)X 2417(remote)X 2660(gateway)X 2948(by)X 896 5700(querying)N 1201(the)X 1319(DNS)X 1499(\(remote)X 1769(debugging\).)X 3 f 576 6048(Cole&Hagens)N 3753([Page)X 3965(1])X 2 p %%Page: 2 2 10 s 10 xH 0 xS 3 f 576 474(Draft)N 3571(October)X 3872(1990)X 576 762(3.)N 676(Proposed)X 1016(Resource)X 1353(Records)X 1 f 776 885(Using)N 990(RFC987's)X 1341(assumption)X 1728(of)X 1818(an)X 1917(asymmetric)X 2314(mapping)X 2617(between)X 2908(X.400)X 3129(and)X 3268(RFC822)X 3561(addresses,)X 3912(two)X 576 975(separate)N 866(relations)X 1168(are)X 1292(required)X 1585(to)X 1672(store)X 1853(the)X 1976(mapping)X 2281(database.)X 2623(We)X 2760(propose)X 3039(two)X 3184(new)X 3343(DNS)X 3528(resource)X 3826(record)X 576 1065(types,)N 785(TO-X400)X 1117(and)X 1253(TO-822,)X 1547(which)X 1763(are)X 1882(to)X 1964(be)X 2060(used)X 2227(to)X 2309(translate)X 2602(between)X 2891(X.400)X 3110(and)X 3247(RFC822)X 3538(addresses.)X 3907(The)X 576 1155(owner-name)N 1009(\256eld)X 1182(of)X 1279(the)X 1407(new)X 1571(resource)X 1874(records)X 2141(can)X 2283(be)X 2389(thought)X 2663(of)X 2760(as)X 2857(keys)X 3034(used)X 3211(to)X 3303 0.4531(reference)AX 3634(the)X 3762(RFC987)X 576 1245(mapping)N 876(data.)X 1070(The)X 1215(data)X 1369(format)X 1603(and)X 1739(meaning)X 2035(of)X 2122(these)X 2307(new)X 2461(resource)X 2754(records)X 3011(is)X 3084(as)X 3171(follows:)X 576 1368(TO-822)N 850(\(resource)X 1170(record)X 1396(type)X 1554(20,)X 1674(decimal\))X 776 1458(The)N 932(TO-822)X 1217(RR)X 1354(is)X 1438(used)X 1616(during)X 1856(the)X 1985(mapping)X 2296(of)X 2394(an)X 2501(X.400)X 2730(O/R)X 2895(addresses)X 3235(to)X 3329(an)X 3437(RFC)X 3619(822)X 3771(address.)X 776 1548(Speci\256cally,)N 1207(the)X 1338(TO-822)X 1625(RR)X 1764(is)X 1849(used)X 2028(to)X 2122(map)X 2292(an)X 2400(X.400)X 2630(O/R)X 2795(addresses)X 3135(\(not)X 3296(including)X 3630(the)X 3760(personal)X 776 1638(name)N 978(\256eld\))X 1175(to)X 1265(a)X 1329(domain-name.)X 1818(The)X 1971(T0-822)X 2235(RR)X 2369(is)X 2451(retrieved)X 2766(by)X 2875(searching)X 3212(the)X 3339(DNS)X 3528(with)X 3699(an)X 3804(owner-)X 776 1728(name)N 970(that)X 1110(represents)X 1456(an)X 1552(X.400)X 1770(O/R)X 1923(address)X 2184(in)X 2266(dmn-orname)X 2696(syntax.)X 2945(The)X 3090(domain-name)X 3551(that)X 3691(is)X 3764(returned)X 776 1818(is)N 849(used)X 1016(to)X 1098(construct)X 1412(the)X 1530(complete)X 1844(822)X 1984(user)X 2138(address.)X 7 f 1288 2031(+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+)N 9 f 1288 2121(|)N 7 f 2072(WILDCARD-COUNT)X 9 f 3560(|)X 7 f 1288 2211(+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+)N 1288 2301(/)N 2152(DOMAIN-NAME)X 3592(/)X 1288 2391(/)N 3592(/)X 1288 2481(+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+)N 1 f 576 2727(TO-X400)N 908(\(resource)X 1228(record)X 1454(type)X 1612(21,)X 1732(decimal\))X 776 2817(The)N 928(TO-X400)X 1268(RR)X 1402(is)X 1483(used)X 1658(during)X 1895(the)X 2021(mapping)X 2329(of)X 2424(an)X 2528(RFC)X 2706(822)X 2854(address)X 3123(to)X 3213(an)X 3317(X.400)X 3543(O/R)X 3704(addresses.)X 776 2907(Speci\256cally,)N 1202(the)X 1328(TO-X400)X 1668(RR)X 1802(is)X 1883(used)X 2058(to)X 2148(map)X 2314(a)X 2378(domain-name)X 2847(into)X 2999(a)X 3063(partial)X 3296(O/R)X 3457(address.)X 3746(The)X 3898(TO-)X 776 2997(X400)N 992(RR)X 1136(is)X 1227(retrieved)X 1551(by)X 1669(searching)X 2015(the)X 2151(DNS)X 2349(with)X 2529(an)X 2643(owner-name)X 3084(that)X 3243(represents)X 3608(an)X 3723(RFC)X 3912(822)X 776 3087(domain-name.)N 1257(The)X 1402(dmn-orname)X 1832(that)X 1972(is)X 2045(returned)X 2333(is)X 2406(used)X 2573(to)X 2655(construct)X 2969(a)X 3025(partial)X 3250(O/R)X 3403(address.)X 7 f 1288 3300(+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+)N 9 f 1288 3390(|)N 7 f 2072(WILDCARD-COUNT)X 9 f 3560(|)X 7 f 1288 3480(+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+)N 1288 3570(/)N 2200(DMN-ORNAME)X 3592(/)X 1288 3660(/)N 3592(/)X 1288 3750(+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+)N 1 f 576 3996(WILDCARD-COUNT)N 776 4086(A)N 856(16)X 958(bit)X 1064(integer.)X 1349(For)X 1483(wildcard)X 1787(resource)X 2083(records,)X 2363(the)X 2484(value)X 2681(speci\256ed)X 2989(here)X 3151(should)X 3387(represent)X 3705(a)X 3764(count)X 3965(of)X 776 4176(the)N 895(number)X 1161(of)X 1249(labels)X 1457(in)X 1540(the)X 1659(fully)X 1831(quali\256ed)X 2132(owner-name,)X 2575(excluding)X 2912(the)X 3030(wildcard)X 3331(label.)X 3547(Otherwise,)X 3917(this)X 776 4266(\256eld)N 941(should)X 1177(be)X 1276(zero.)X 1479(This)X 1645(\256eld)X 1811(can)X 1947(be)X 2047(used)X 2218(by)X 2322(resolvers)X 2636(to)X 2722(determine)X 3067(the)X 3189(number)X 3458(of)X 3549(labels)X 3760(matched)X 776 4356(when)N 970(the)X 1088(received)X 1381(resource)X 1674(record)X 1900(was)X 2045(derived)X 2333(from)X 2509(a)X 2565(wildcard)X 2866(resource)X 3159(record.)X 576 4479(DOMAIN-NAME)N 776 4569(A)N 854(.)X 576 4692(DMN-ORNAME)N 776 4782(A)N 854(dmn-orname.)X 3 f 576 5001(4.)N 676(Usage)X 1 f 3 f 576 5187(4.1.)N 736(Representation)X 1277(of)X 1364(O/R)X 1526(addresses)X 1875(in)X 1961(the)X 2088(DNS)X 1 f 776 5310(The)N 929(RFC987)X 1227(mapping)X 1535(information)X 1941(is)X 2022(stored)X 2246(in)X 2336(the)X 2462(DNS)X 2650(in)X 2740(a)X 2804(tree)X 2953(structure.)X 3302(The)X 3455(TO-X400)X 3795(records)X 576 5400(occupy)N 835(space)X 1041(within)X 1272(the)X 1397(already)X 1661(existent)X 1937(tree)X 2085(of)X 2179(domain)X 2446(names.)X 2718(The)X 2870(TO-822)X 3151(records)X 3414(occupy)X 3672(a)X 3734(new)X 3894(sub-)X 576 5490(tree)N 726(\(within)X 986(the)X 1113(existent)X 1391(tree\))X 1568(whose)X 1802(nodes)X 2018(are)X 2146(domain)X 2415(names)X 2649(in)X 2740(dmn-orname)X 3179(syntax.)X 3437(This)X 3609(new)X 3773(sub-tree)X 576 5580(occupies)N 877(the)X 995(top)X 1117(level)X 1293(domain)X 1553("ORMAP")X 1923(\(i.e.,)X 2088("ORMAP")X 2458(is)X 2531(a)X 2587(new,)X 2761(top-level)X 3066(domain\).)X 776 5703(O/R)N 943(attributes)X 1275(are)X 1408(stored)X 1638(in)X 1734(the)X 1866(tree)X 2021(hierarchically)X 2497(with)X 2674(the)X 2807(most)X 2997(signi\256cant)X 3365(attributes)X 3698(occupying)X 576 5793(internal)N 847(nodes,)X 1080(and)X 1222(the)X 1346(least)X 1519(signi\256cant)X 1878(attributes)X 2202(occupying)X 2562(leaf)X 2708(nodes)X 2920(of)X 3012(the)X 3135(DNS.)X 3340(The)X 3490(root)X 3644(node)X 3825(of)X 3917(this)X 3 f 576 6048(Cole&Hagens)N 3753([Page)X 3965(2])X 3 p %%Page: 3 3 10 s 10 xH 0 xS 3 f 576 474(Draft)N 3571(October)X 3872(1990)X 1 f 576 762(tree)N 729(will)X 885(have)X 1069(the)X 1200(label)X 1389("ORMAP".)X 1792(The)X 1950(top)X 2085(subdomains)X 2500(of)X 2600("ORMAP")X 2983(will)X 3140(correspond)X 3530(to)X 3625(O/R)X 3791(address)X 576 852(country)N 841(attribute)X 1128(names.)X 1393(For)X 1524(example,)X 1836("US")X 2024(and)X 2160("UK")X 2362(are)X 2481(valid)X 2661(subdomains)X 3063(of)X 3150("ORMAP".)X 776 975(The)N 940(dmn-orname)X 1389(information)X 1806(associated)X 2175(with)X 2356(TO-X400)X 2707(and)X 2862(TO-822)X 3155(resource)X 3467(records)X 3743(does)X 3930(not)X 576 1065(represent)N 895(a)X 955(full)X 1090(O/R)X 1247(address.)X 1532(It)X 1605(is)X 1682(a)X 1742(template)X 2042(which)X 2262(speci\256es)X 2562(the)X 2684(\256elds)X 2881(of)X 2972(the)X 3094(O/R)X 3251(address)X 3516(that)X 3660(are)X 3782(used)X 3952(by)X 576 1155(the)N 699(mapping)X 1004(algorithm.)X 1380(A)X 1463(subset)X 1689(of)X 1782(the)X 1906(possible)X 2194(X.400)X 2418(O/R)X 2577(attributes)X 2901(are)X 3026(used)X 3199(when)X 3399(performing)X 3786(conver-)X 576 1245(sions)N 763(between)X 1054(RFC822)X 1347(and)X 1486(X.400)X 1707(O/R)X 1863(addresses.)X 2234(The)X 2382(attribute)X 2672(names)X 2900(allowed)X 3177(in)X 3262(a)X 3321(dmn-orname,)X 3774(listed)X 3970(in)X 576 1335(descending)N 957(order)X 1147(of)X 1234(signi\256cance)X 1637(are:)X 896 1458(Country)N 896 1548(ADMD)N 896 1638(PRMD)N 896 1728(Organization)N 896 1818(Organizational)N 1393(Unit)X 776 1974(When)N 988(an)X 1084(O/R)X 1237(address)X 1499(is)X 1573(written)X 1821(in)X 1904(dmn-orname)X 2335(syntax,)X 2585(the)X 2704(attributes)X 3023(are)X 3143(ordered)X 3410(from)X 3587(left)X 3715(to)X 3798(right)X 3970(in)X 576 2064(ascending)N 927(order)X 1127(of)X 1224(signi\256cance.)X 1677(O/R)X 1840(attribute)X 2137(names)X 2372(not)X 2504(listed)X 2707(in)X 2799(the)X 2927(above)X 3149(table)X 3334(\(such)X 3537(as)X 3633(the)X 3760(surname)X 576 2154(attribute\))N 890(do)X 990(not)X 1112(appear)X 1347(in)X 1429(dmn-ornames)X 1890(used)X 2057(by)X 2157(the)X 2275(mapping)X 2575(procedure.)X 776 2277(When)N 990(constructing)X 1408(a)X 1466(dmn-orname)X 1898(from)X 2076(an)X 2174(O/R)X 2329(address,)X 2612(missing)X 2882(O/R)X 3037(attributes)X 3357(are)X 3478(handled)X 3754(in)X 3839(a)X 3898(spe-)X 576 2367(cial)N 733(way.)X 948(If)X 1043(the)X 1182(missing)X 1471(O/R)X 1645(attribute)X 1953(is)X 2047(omitted)X 2332(from)X 2529(the)X 2668(dmn-orname,)X 3139(no)X 3260(other)X 3466(attributes)X 3805(of)X 3912(less)X 576 2457(signi\256cance)N 979(may)X 1137(be)X 1233(included.)X 776 2580(It)N 848(is)X 924(envisioned)X 1294(that)X 1437(the)X 1558(need)X 1733(may)X 1894(arise)X 2069(to)X 2154(construct)X 2472(a)X 2532(dmn-orname)X 2966(with)X 3132(a)X 3192(missing)X 3464(O/R)X 3621(attribute)X 2 f 3912(and)X 1 f 576 2670(include)N 834(other)X 1020(attributes)X 1339(of)X 1427(less)X 1568(signi\256cance.)X 2012(In)X 2100(this)X 2236(case,)X 2416(the)X 2535(absent)X 2761(attribute)X 3049(is)X 3123(included)X 3420(in)X 3503(the)X 3622(dmn-orname)X 576 2760(with)N 738(a)X 794(special)X 1037(encoding:)X 896 2883(Country)N 1178(-)X 1225(must)X 1400(always)X 1643(be)X 1739(present)X 896 2973(ADMD)N 1161(-)X 1208(absent)X 1433(value)X 1627(indicated)X 1941(with)X 2103('AbsentADMD')X 896 3063(PRMD)N 1142(-)X 1189(absent)X 1414(value)X 1608(indicated)X 1922(with)X 2084('AbsentPRMD')X 896 3153(Organization)N 1335(-)X 1382(absent)X 1607(value)X 1801(indicated)X 2115(with)X 2277('AbsentOrg')X 3 f 576 3372(4.2.)N 736(Example)X 1 f 776 3495(The)N 921(following)X 1252(example)X 1544(show)X 1733(the)X 1851(construction)X 2267(of)X 2354(a)X 2410(dmn-orname.)X 896 3618(/C=no/ADMD=telemax/O=teledir/)N 2034(->)X 896 3708(teledir.AbsentPRMD.telemax.no.ormap)N 896 3888(/C=no/ADMD=telemax/PRMD=teledir/)N 2202(->)X 896 3978(teledir.telemax.no.ormap)N 896 4158(/C=no/ADMD=)N 10 f 1408(`)X 1 f (/PRMD=teledir/)S 2008(->)X 896 4248(teledir.)N 10 f 1121(`)X 1 f (.no.ormap)S 896 4428(/C=no/PRMD=telemax/O=teledir/)N 2015(->)X 896 4518(teledir.telemax.AbsentADMD.no.ormap)N 896 4698(/C=no/PRMD=telemax/OU=teledir/)N 2073(->)X 896 4788 0.0909(teledir.AbsentOrg.telemax.AbsentADMD.no.ormap)AN 576 4911(where)N 797(")X 10 f 830(`)X 1 f (")S 947(represents)X 1297(a)X 1357(blank.)X 1579(The)X 1728(absent)X 1957(attribute)X 2248(encoding)X 2566(is)X 2643(unpleasant.)X 3030(However,)X 3370(one)X 3511(should)X 3749(note)X 3912(that)X 576 5001(this)N 716(form)X 897(of)X 989(the)X 1112(address)X 1378(will)X 2 f 1527(never)X 1 f 1731(be)X 1832(visible)X 2070(to)X 2157(the)X 2280(user.)X 2459(It)X 2533(is)X 2611(only)X 2778(used)X 2949(during)X 3182(communication)X 3704(between)X 3996(a)X 576 5091(987)N 716(gateway)X 1004(and)X 1140(the)X 1258(DNS.)X 3 f 576 5214(4.3.)N 736(Wildcards)X 1 f 776 5337(Dmn-ornames)N 1257(and)X 1395(domain-names)X 1889(are)X 2010(used)X 2179(as)X 2268(the)X 2388(lookup)X 2632(keys)X 2801(to)X 2886(retrieve)X 3155(RFC987)X 3448(mapping)X 3751(informa-)X 576 5427(tion)N 739(from)X 934(the)X 1071(DNS.)X 1310(A)X 1407(non-existent)X 1842(domain)X 2121(response)X 2441(from)X 2636(the)X 2772(nameserver)X 3181(indicates)X 3504(that)X 3662(there)X 3861(is)X 3952(no)X 576 5517(RFC987)N 867(mapping)X 1169(information)X 1569(in)X 1653(the)X 1773(DNS)X 1955(for)X 2071(the)X 2191(given)X 2391(key,)X 2549(and)X 2687(the)X 2807(DNS)X 2989(search)X 3217(is)X 3292(complete.)X 3648(A)X 3728(non-error)X 576 5607(response)N 880(also)X 1032(completes)X 1380(the)X 1501(DNS)X 1684(search.)X 1953(Wildcard)X 2274(resource)X 2569(records)X 2828(can)X 2962(be)X 3060(used)X 3229(to)X 3313(allow)X 3513(multiple)X 3801(keys)X 3970(to)X 576 5697(map)N 734(to)X 816(one)X 952(node)X 1128(in)X 1210(the)X 1328(DNS)X 1508(namespace.)X 1921(\(See)X 2084(also)X 2233(RFC1034,)X 2583(section)X 2830(4.3.3,)X 3030(wildcards.\))X 3 f 576 6048(Cole&Hagens)N 3753([Page)X 3965(3])X 4 p %%Page: 4 4 10 s 10 xH 0 xS 3 f 576 474(Draft)N 3571(October)X 3872(1990)X 1 f 776 762(If)N 850(the)X 968(returned)X 1256(resource)X 1549(record)X 1775(contains)X 2062(a)X 2118(non-zero)X 2425(WILDCARD-COUNT)X 3181(\256eld,)X 3364(then)X 3523(the)X 3642(longest)X 3894(pos-)X 576 852(sible)N 748(match)X 965(of)X 1053(the)X 1172(supplied)X 1464(lookup)X 1707(key)X 1844(does)X 2012(not)X 2135(include)X 2392(all)X 2493(components)X 2901(of)X 2989(that)X 3130(key.)X 3307(For)X 3439(a)X 3496(lookup)X 3738(key)X 3874(of)X 3961(M)X 576 942(components)N 985(and)X 1123(a)X 1181(WILDCARD-COUNT)X 1938(\256eld)X 2102(with)X 2266(value)X 2462(N,)X 2563(a)X 2622(non-zero)X 2931(value)X 3128(for)X 3245(N)X 3326(indicates)X 3634(that)X 3777(the)X 3898(left-)X 576 1032(most)N 761(M-N)X 946(components)X 1362(of)X 1458(the)X 1585(lookup)X 1836(key)X 1981(were)X 2167(not)X 2298(explicitly)X 2629(matched.)X 2970(Assumptions)X 3416(are)X 3544(made)X 3747(as)X 3843(to)X 3934(the)X 576 1122(mapping)N 876(of)X 963(the)X 1081(unmatched)X 1453(components.)X 1900(There)X 2108(are)X 2227(two)X 2367(cases:)X 576 1245(1\))N 663(RFC822->X.400)X 1223(\(domain-name)X 1711(->)X 1803(dmn-orname\))X 776 1335(Map)N 946(all)X 1049(remaining)X 1397(domain-name)X 1861(components)X 2271(to)X 2357(additional)X 2701(O/R)X 2858(attribute/value)X 3345(pairs.)X 3565(The)X 3714(next)X 3876(attri-)X 776 1425(bute)N 935(assigned)X 1232(corresponds)X 1641(to)X 1724(the)X 1843(attribute)X 2131(of)X 2219(next)X 2378(lower)X 2582(priority)X 2843(than)X 3002(the)X 3121(lowest)X 3350(attribute)X 3637(type)X 3795(already)X 776 1515(assigned.)N 1115(The)X 1263(new)X 1420(attribute)X 1710(is)X 1786(assigned)X 2085(a)X 2144(value)X 2341(which)X 2561(is)X 2638(the)X 2760(same)X 2949(as)X 3040(the)X 3162(most)X 3341(signi\256cant)X 3698(unmapped)X 776 1605(domain-name)N 1245(component.)X 1669(If)X 1751(the)X 1877(last)X 2016(assigned)X 2320(attribute)X 2615(type)X 2781(was)X 2934(an)X 3038(OU)X 3182(\(organizational)X 3696(unit\),)X 3894(then)X 776 1695(any)N 914(additional)X 1256(attribute)X 1545(assignments)X 1958(will)X 2104(be)X 2202(to)X 2286(OUs,)X 2475(with)X 2639(less)X 2781(signi\256cant)X 3136(attribute-value)X 3626(pairs)X 3805(written)X 776 1785(to)N 883(the)X 1026(left)X 1178(of)X 1290(other)X 1500(attribute-values.)X 2084(Order)X 2317(and)X 2478(signi\256cance)X 2906(of)X 3017(domain-name)X 3502(components)X 3933(are)X 776 1875(preserved)N 1109(by)X 1209(this)X 1344(scheme.)X 576 1998(2\))N 663(X.400->RFC822)X 1223(\(dmn-orname)X 1680(->)X 1772(domain-name\))X 776 2088(Of)N 894(the)X 1025(remaining)X 1383(dmn-orname)X 1826(components,)X 2266(only)X 2441(those)X 2643(which)X 2873(correspond)X 3264(to)X 3360(attributes)X 3692(at)X 3784(least)X 3965(as)X 776 2178(signi\256cant)N 1141(as)X 1240(the)X 1370(OU)X 1518(attribute)X 1817(type)X 1987(are)X 2117(mapped.)X 2442(The)X 2598(attribute)X 2896(values)X 3132(from)X 3319(these)X 3515(components)X 3933(are)X 776 2268(added)N 994(to)X 1082(the)X 1206(domain-name)X 1673(returned)X 1967(by)X 2073(the)X 2197(DNS)X 2383(lookup,)X 2651(and)X 2793(are)X 2918(mapped)X 3198(in)X 3286(the)X 3411(same)X 3603(order)X 3800(as)X 3894(they)X 776 2358(appear)N 1022(in)X 1115(the)X 1244(dmn-orname.)X 1725(Those)X 1952(attributes)X 2281(less)X 2432(signi\256cant)X 2796(than)X 2965(the)X 3093(OU)X 3239(attribute)X 3536(are)X 3665(used)X 3842(in)X 3934(the)X 776 2448(construction)N 1194(of)X 1283(the)X 1403(left)X 1532(hand)X 1710(side)X 1861(of)X 1950(the)X 2070(RFC822)X 2362(address.)X 2665(The)X 2812(translation)X 3172(of)X 3262(the)X 3383(left)X 3513(hand)X 3692(side)X 3844(of)X 3934(the)X 776 2538(822)N 916(address)X 1177(is)X 1250(speci\256ed)X 1555(by)X 1655(RFC987.)X 3 f 576 2724(4.4.)N 736(Example)X 1 f 776 2847(Assume)N 1054(DNS)X 1234(is)X 1307(populated)X 1643(with)X 1805(the)X 1923(following)X 2254(wildcard)X 2555(resource)X 2848(record:)X 896 2970(*.CS.UW-MADISON.XNREN.)N 10 f 1924(`)X 1 f (.US)S 2336(IN)X 2624(TO-822)X 2932(5)X 3220(cs.wisc.edu)X 776 3126(Given)N 992(the)X 1110(O/R)X 1263(address)X 896 3249(/C=US/ADMD=)N 10 f 1430(`)X 1 f (/PRMD=XNREN/O=UW-MADISON/OU=CS/OU=DIP/S=doe/)S 576 3372(determine)N 917(the)X 1035(corresponding)X 1514(RFC822)X 1804(domain)X 2064(name.)X 576 3495(Step)N 738(1)X 776 3585(The)N 921(address)X 1182(is)X 1255(rewritten)X 1565(in)X 1647(dmn-orname)X 2077(syntax)X 2306(as:)X 1096 3708(DIP.CS.UW-MADISON.XNREN.)N 10 f 2213(`)X 1 f (.US)S 776 3831(The)N 922(/S=doe/)X 1192(attribute)X 1480(value)X 1675(pair)X 1821(is)X 1895(dropped)X 2179(since)X 2366(it)X 2432(is)X 2507(less)X 2649(signi\256cant)X 3004(than)X 3164(an)X 3262(OU)X 3400(attribute.)X 3729(The)X 3876(attri-)X 776 3921(bute)N 934(order)X 1124(is)X 1197(rewritten)X 1507(according)X 1844(to)X 1926(the)X 2044(dmn-orname)X 2474(restrictions)X 2850(\(see)X 3000(section)X 3247(4.1\).)X 576 4044(Step)N 738(2)X 776 4134(Perform)N 1059(the)X 1177(DNS)X 1357(lookup:)X 1096 4257(DIP.CS.UW-MADISON.XNREN.)N 10 f 2213(`)X 1 f (.US)S 776 4380(The)N 921(nameserver)X 1312(returns)X 1555(the)X 1673(domain-name)X 2134("cs.wisc.edu")X 2590(and)X 2726(a)X 2782(wildcard-count)X 3288(of)X 3375(5.)X 576 4503(Step)N 738(3)X 776 4593(Since)N 981(the)X 1106(wildcard-count)X 1619(\256eld)X 1788(is)X 1868(non-zero,)X 2201(the)X 2327(nameserver)X 2726(response)X 3035(indicates)X 3348(that)X 3496(the)X 3622(dmn-orname)X 776 4683(component)N 1157("DIP")X 1377(was)X 1527(not)X 1654(explicitly)X 1981(matched.)X 2318(The)X 2468(unmapped)X 2826(attribute)X 3117(value)X 3315("DIP")X 3534(is)X 3611(prepended)X 3970(to)X 776 4773(the)N 894(domain-name)X 1355(returned)X 1643(by)X 1743(the)X 1861(DNS)X 2041(lookup)X 2283(to)X 2365(produce)X 2644(the)X 2762(domain-name)X 3223("dip.cs.wisc.edu".)X 3 f 576 4959(4.5.)N 736(Error)X 957(Recovery)X 1 f 776 5082(RFC987)N 1067(speci\256es)X 1364(that)X 1505(translation)X 1864(from)X 2041(one)X 2178(address)X 2440(space)X 2640(to)X 2723(another)X 2985(may)X 3144(occur)X 3344(in)X 3427(2)X 3488(ways.)X 3694(The)X 3840(above)X 576 5172(method)N 846(of)X 943(translation)X 1311(\(lookup)X 1590(from)X 1776(the)X 1904(mapping)X 2214(database\))X 2548(is)X 2631(used)X 2807(when)X 3010(sub-trees)X 3329(of)X 3425(the)X 3552(different)X 3858(name)X 576 5262(spaces)N 809(are)X 931(associated)X 1284(via)X 1405(mapping)X 1708(information.)X 2149(The)X 2297(fall)X 2427(back)X 2602(method)X 2865(of)X 2955(translation)X 3316(\(encoding)X 3660(in)X 3745(the)X 3867(other)X 576 5352(address)N 852(space's)X 1124(format\))X 1400(is)X 1487(used)X 1668(when)X 1876(table)X 2066(lookup)X 2322(fails.)X 2534(However,)X 2883(in)X 2979(this)X 3128(case,)X 3321(the)X 3453(translation)X 3825(is)X 3912(less)X 576 5442(sophisticated.)N 1074(The)X 1239(fall)X 1386(back)X 1578(method)X 1858(amounts)X 2170(to)X 2273(encoding)X 2608(the)X 2747(address)X 3029(in)X 3132(the)X 3271(other)X 3477(system's)X 3798(format.)X 576 5532(RFC987)N 869(speci\256es)X 1168(default)X 1414(rules)X 1593(that)X 1736(may)X 1897(be)X 1996(used)X 2166(to)X 2251(perform)X 2532(this)X 2669(encoding.)X 3025(These)X 3239(rules)X 3417(specify)X 3671(the)X 3791(manner)X 576 5622(in)N 661(which)X 880(an)X 979(RFC822)X 1272(address)X 1536(may)X 1697(be)X 1796(encoded)X 2088(in)X 2174(X.400,)X 2416(and)X 2556(vice)X 2714(versa,)X 2928(by)X 3032(means)X 3261(of)X 3352(domain)X 3616(de\256ned)X 3876(attri-)X 576 5712(butes.)N 785(This)X 947(fall)X 1074(back)X 1246(method)X 1506(of)X 1593(translation)X 1951(is)X 2024(referred)X 2300(to)X 2382(as)X 2469("default)X 2745(translation".)X 3 f 576 6048(Cole&Hagens)N 3753([Page)X 3965(4])X 5 p %%Page: 5 5 10 s 10 xH 0 xS 3 f 576 474(Draft)N 3571(October)X 3872(1990)X 1 f 776 762(A)N 854(query)X 1057(of)X 1144(the)X 1262(DNS)X 1442(can)X 1574(result)X 1772(in)X 1854(one)X 1990(of)X 2077(the)X 2195(following)X 2526(response)X 2827(codes.)X 10 f 576 885(g)N 2 f 664(Ok)X 1 f 776(No)X 894(error)X 1071(condition.)X 10 f 576 1008(g)N 2 f 664(Format)X 924(error)X 1 f 776 1098(The)N 921(name)X 1115(server)X 1332(was)X 1477(unable)X 1711(to)X 1793(interpret)X 2085(the)X 2203(query.)X 10 f 576 1221(g)N 2 f 664(Server)X 894(failure)X 1 f 776 1311(The)N 921(name)X 1115(server)X 1332(was)X 1477(unable)X 1711(to)X 1793(process)X 2054(this)X 2189(query)X 2392(due)X 2528(to)X 2610(a)X 2666(problem)X 2953(with)X 3115(the)X 3233(name)X 3427(server.)X 10 f 576 1434(g)N 2 f 664(Name)X 871(Error)X 1 f 776 1524(Meaningful)N 1172(only)X 1336(for)X 1452(responses)X 1786(from)X 1964(an)X 2062(authoritative)X 2489(name)X 2686(server,)X 2926(this)X 3064(code)X 3239(signi\256es)X 3528(that)X 3671(the)X 3792(domain)X 776 1614(name)N 970 0.4028(referenced)AX 1331(in)X 1413(the)X 1531(query)X 1734(does)X 1901(not)X 2023(exist.)X 10 f 576 1737(g)N 2 f 664(Not)X 799(Implemented)X 1 f 776 1827(The)N 921(name)X 1115(server)X 1332(does)X 1499(not)X 1621(support)X 1881(the)X 1999(requested)X 2327(kind)X 2489(of)X 2576(query.)X 10 f 576 1950(g)N 2 f 664(Refused)X 1 f 776 2040(The)N 923(name)X 1119(server)X 1338(refuses)X 1588(to)X 1672(perform)X 1953(the)X 2073(speci\256ed)X 2380(operation)X 2706(for)X 2823(policy)X 3046(reasons.)X 3350(For)X 3484(example,)X 3799(a)X 3858(name)X 776 2130(server)N 996(may)X 1157(not)X 1282(wish)X 1456(to)X 1541(provide)X 1809(the)X 1930(information)X 2331(to)X 2416(the)X 2537(particular)X 2868(requester,)X 3206(or)X 3296(a)X 3355(name)X 3551(server)X 3770(may)X 3930(not)X 776 2220(wish)N 956(to)X 1047(perform)X 1335(a)X 1400(particular)X 1737(operation)X 2069(\(e.g.,)X 2261(zone)X 2442(transfer\).)X 2765(This)X 2937(code)X 3119(may)X 3287(also)X 3446(be)X 3552(received)X 3855(if)X 3934(the)X 776 2310(nameserver)N 1167(is)X 1240(down)X 1438(\(i.e.,)X 1603(cannot)X 1837(connect\).)X 576 2433(After)N 781(receiving)X 1115(a)X 1186(response)X 1502(code)X 1689(from)X 1880(the)X 2013(server,)X 2265(the)X 2398(gateway)X 2701(software)X 3014(can)X 3162(take)X 3332(one)X 3484(of)X 3587(the)X 3721(following)X 576 2523(actions.)N 10 f 576 2646(g)N 2 f 664(Proceed)X 952(\(P\))X 1 f 776 2736(Use)N 921(the)X 1039(result)X 1237(of)X 1324(the)X 1442(DNS)X 1622(query)X 1825(to)X 1907(continue)X 2203(the)X 2321(address)X 2582(mapping)X 2882(process.)X 10 f 576 2859(g)N 2 f 664(Default)X 924(\(D\))X 1 f 776 2949(Use)N 921(the)X 1039(default)X 1282(translation)X 1640(and)X 1776(continue)X 2072(the)X 2190(mapping)X 2490(process.)X 10 f 576 3072(g)N 2 f 664(Abort)X 866(\(A\))X 1 f 776 3162(Abort)N 984(the)X 1103(mapping)X 1404(process)X 1666(because)X 1942(the)X 2061(mapping)X 2362(is)X 2436(impossible,)X 2823(or)X 2911(the)X 3030(default)X 3274(process)X 3536(is)X 3610(likely)X 3814(to)X 3898(lead)X 776 3252(to)N 858(an)X 954(error.)X 10 f 576 3375(g)N 2 f 664(Retry)X 858(\(R\))X 1 f 776 3465(Reschedule)N 1169(the)X 1290(DNS)X 1473(query)X 1679(for)X 1796(a)X 1855(later)X 2022(date)X 2180(\(i.e.,)X 2349(assume)X 2609(that)X 2753(the)X 2875(response)X 3180(is)X 3257(transient\).)X 3604(When)X 3820(a)X 3880(retry)X 776 3555(action)N 994(is)X 1069(taken,)X 1285(the)X 1405(entire)X 1610(message)X 1904(is)X 1978(delayed)X 2249(for)X 2364(a)X 2421(period)X 2647(of)X 2735(time.)X 2918(When)X 3131(the)X 3250(message)X 3543(is)X 3617(\256rst)X 3762(delayed,)X 776 3645(a)N 837("retry)X 1047(counter")X 1346(is)X 1424(attached)X 1717(to)X 1804(the)X 1927(message.)X 2244(If)X 2323(the)X 2446(retry)X 2623(action)X 2845(is)X 2924(taken)X 3124(a)X 3186(subsequent)X 3568(time,)X 3756(the)X 3880(retry)X 776 3735(counter)N 1040(is)X 1116(incremented.)X 1576(When)X 1791(the)X 1912(retry)X 2087(counter)X 2351(reaches)X 2616(the)X 2737("maximum)X 3117(retry)X 3291(threshold",)X 3664(a)X 3722("timeout")X 776 3825(event)N 978(is)X 1059(generated.)X 1420(Note:)X 1626(the)X 1752("maximum)X 2137(retry)X 2317(threshold")X 2676(is)X 2757(not)X 2887(related)X 3134(to)X 3224(the)X 3350(bind)X 3521(MAXRETRIES)X 776 3915(parameter.)N 576 4038(The)N 721(following)X 1052(state)X 1219(table)X 1395(describes)X 1714(the)X 1832(appropriate)X 2218(action)X 2435(for)X 2550(the)X 2669(mapping)X 2970(algorithm)X 3302(based)X 3506(upon)X 3687(the)X 3806(type)X 3965(of)X 576 4128(address)N 847(being)X 1055(mapped)X 1339(and)X 1485(the)X 1613(DNS)X 1803(response)X 2114(code.)X 2316(For)X 2456(the)X 2583(completeness,)X 3064(two)X 3213(additional)X 3562(DNS)X 3751(response)X 576 4218(codes)N 779(are)X 898(de\256ned.)X 10 f 576 4341(g)N 2 f 664(Other)X 1 f 776 4431(This)N 938(covers)X 1168(any)X 1304(other)X 1489(value)X 1683(for)X 1797(the)X 1915(DNS)X 2095(response)X 2396(code)X 2568(\256eld.)X 10 f 576 4554(g)N 2 f 664(Timeout)X 1 f 776 4644(This)N 940(event)X 1136(is)X 1211(generated)X 1546(when)X 1742(a)X 1800(message)X 2094(has)X 2223(been)X 2397(retried)X 2629(more)X 2816(times)X 3012(than)X 3173(the)X 3294("maximum)X 3674(retry)X 3849(thres-)X 776 4734(hold")N 971(allows.)X 1220(The)X 1365(generation)X 1724(of)X 1811(this)X 1946(event)X 2140(prevents)X 2432(a)X 2488(message)X 2780(from)X 2956(being)X 3154(retried)X 3384(inde\256nitely.)X 576 4857(The)N 723(state)X 892(table)X 1070(contains)X 1359(two)X 1501(axis.)X 1672(The)X 1819(vertical)X 2082(axis)X 2233(is)X 2308(indexed)X 2584(by)X 2686(the)X 2806(type)X 2966(of)X 3056(address)X 3320(that)X 3463(is)X 3539(being)X 3740(matched.)X 576 4947(Three)N 784(types)X 973(are)X 1092(de\256ned.)X 896 5070(From)N 1089(=)X 1154(822-P1)X 1405(return)X 1617(address)X 1878(<->)X 2015(P1.UMPDUEnvelope.originator)X 896 5160(Rcpt)N 1067(=)X 1132(822-P1)X 1383(recipient)X 1684(<->)X 1821(P1.RecipientInfo)X 896 5250(Other)N 1099(=)X 1164(Any)X 1322(other)X 1507(address)X 1768(found)X 1975(in)X 2057(the)X 2175(822)X 2315(or)X 2402(P2)X 2506(header)X 576 5373(The)N 721(horizontal)X 1066(axis)X 1215(is)X 1288(indexed)X 1562(by)X 1662(DNS)X 1842(response)X 2143(code.)X 2355(The)X 2500(same)X 2685(state)X 2852(table)X 3028(is)X 3101(used)X 3268(for)X 3382(both)X 3544(directions.)X 3 f 576 6048(Cole&Hagens)N 3753([Page)X 3965(5])X 6 p %%Page: 6 6 10 s 10 xH 0 xS 3 f 576 474(Draft)N 3571(October)X 3872(1990)X 1 f 896 795(Address)N 1351(Ok)X 1641(Format)X 2064(Server)X 2483(Name)X 2867(Not)X 3230(Refused)X 3685(Other)X 4060(Timeout)X 896 885(Type)N 1641(Error)X 2064(Failure)X 2483(Error)X 2867(Impl.)X 10 f 896 895(i)N 931(iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii)X 1 f 896 985(From)N 1351(P)X 1641(A\263)X 2064(R)X 2483(D)X 2867(A\263)X 3230(R\263)X 3685(A\263)X 4060(D)X 896 1075(Rcpt)N 1351(P)X 1641(A\262)X 2064(R)X 2483(A\262)X 2867(A\262)X 3230(R\262)X 3685(A\263)X 4060(A\262)X 896 1165(Other)N 1351(P)X 1641(D)X 2064(D)X 2483(D)X 2867(D)X 3230(D)X 3685(A\263)X 4060(D)X 576 1354(\263\))N 776(The)X 921(message)X 1213(is)X 1286(not)X 1408(delivered.)X 576 1477(\262\))N 776(The)X 921(recipient)X 1222(in)X 1304(question)X 1595(is)X 1668(not)X 1790(served.)X 3 f 576 1663(4.6.)N 742(Constants)X 1 f 1150(When)X 1368(a)X 1430(query)X 1639(is)X 1718(delayed,)X 2014(it)X 2084(shall)X 2261(not)X 2389(be)X 2491(retried)X 2727(for)X 2847(at)X 2931(least)X 3104()X 3395(minutes.)X 3715(The)X 3867(max-)X 576 1753(imum)N 782(retry)X 954(threshold)X 1272(shall)X 1443(be)X 1539(set)X 1648(to)X 1730(.)X 3 f 576 1939(5.)N 676(Administration)X 1220(of)X 1307(mapping)X 1628(information)X 1 f 776 2062(Not)N 922(all)X 1028(RFC987)X 1324(gateways)X 1650(will)X 1801(be)X 1904(able)X 2065(to)X 2154(use)X 2288(the)X 2413(internet)X 2685(DNS)X 2872(to)X 2961(map)X 3126(between)X 3421(O/R)X 3581(addresses)X 3916(and)X 576 2152(RFC822)N 874(domain)X 1142(names.)X 1415(Hosts)X 1624(without)X 1895(access)X 2128(to)X 2217(the)X 2342(DNS)X 2529(are)X 2655(expected)X 2968(to)X 3057(obtain)X 3284(full)X 3422(mapping)X 3729(tables)X 3943(\(in)X 576 2242(RFC987)N 875(Appendix)X 1220(F)X 1293(format\))X 1563(from)X 1748(a)X 1813(master)X 2056(table.)X 2281(Hosts)X 2492(with)X 2663(DNS)X 2852(access)X 3087(should)X 3329(be)X 3435(able)X 3599(to)X 3691(obtain)X 3921(full)X 576 2332(mapping)N 880(information)X 1282(from)X 1462(the)X 1584(DNS)X 1768(namespace.)X 2185(This)X 2351(implies)X 2610(that)X 2754(there)X 2939(will)X 3087(be)X 3186(two)X 3329(separate)X 3616(copies)X 3844(of)X 3934(the)X 576 2422(mapping)N 876(database,)X 1193(one)X 1329(in)X 1411(table)X 1587(form,)X 1783(and)X 1919(the)X 2037(other)X 2222(within)X 2446(the)X 2564(internet)X 2829(DNS)X 3009(namespace.)X 776 2545(The)N 921(master)X 1155(copy)X 1331(of)X 1418(the)X 1536(mapping)X 1836(database)X 2133(will)X 2277(be)X 2373(the)X 2491(copy)X 2667(stored)X 2883(in)X 2965(the)X 3083(DNS)X 3263(namespace.)X 3 f 576 2731(5.1.)N 736(Partitioning)X 1169(the)X 1296(mapping)X 1617(database)X 1939(into)X 2092(zones)X 1 f 776 2854(Name)N 991(servers)X 1242(are)X 1364(the)X 1485(repositories)X 1883(of)X 1974(information)X 2376(that)X 2520(make)X 2718(up)X 2822(the)X 2944(domain)X 3208(database.)X 3529(The)X 3678(database)X 3979(is)X 576 2944(divided)N 836(up)X 936(into)X 1080(sections)X 1358(called)X 1570(zones,)X 1793(which)X 2009(are)X 2128(distributed)X 2490(among)X 2728(the)X 2846(name)X 3040(servers)X 3288([RFC)X 3485(1034].)X 776 3067(All)N 906(TO-X400)X 1246(and)X 1390(TO-822)X 1672(records)X 1937(will)X 2089(be)X 2193(stored)X 2417(in)X 2507(DNS)X 2695(zones.)X 2946(The)X 3099(authoritative)X 3532(information)X 3938(for)X 576 3157(any)N 722(particular)X 1060(zone)X 1242(may)X 1410(be)X 1516(delegated)X 1854(to)X 1946(any)X 2092(nameserver)X 2492(supporting)X 2863(the)X 2990(TO-X400)X 3331(and)X 3476(TO-822)X 3759(resource)X 576 3247(records.)N 877(The)X 1026(root)X 1180(nameservers)X 1607(for)X 1726(the)X 1849(TO-X400)X 2186(and)X 2327(TO-822)X 2606(information)X 3009(delegate)X 3302(zones)X 3510(to)X 3597(the)X 3720(authorita-)X 576 3337(tive)N 716(nameservers,)X 1158(and)X 1294(assume)X 1550(authority)X 1859(for)X 1973(those)X 2162(sections)X 2440(of)X 2527(the)X 2645(DNS)X 2825(tree)X 2966(that)X 3106(have)X 3278(not)X 3400(been)X 3572(delegated.)X 776 3460(The)N 921(distribution)X 1309(of)X 1396(TO-X400)X 1728(records)X 1985(into)X 2129(zones)X 2332(is)X 2405(dependent)X 2755(on)X 2855(the)X 2973(organization)X 3394(of)X 3481(the)X 3599(existing)X 3872(DNS)X 576 3550(tree)N 724(into)X 875(zones.)X 1104(Since)X 1308(these)X 1499(zones)X 1708(already)X 1971(exist)X 2148(and)X 2290(are)X 2415(in)X 2503(operation,)X 2852(it)X 2922(is)X 3001(obvious)X 3280(where)X 3503(the)X 3627(authoritative)X 576 3640(information)N 974(must)X 1149(reside.)X 776 3763(The)N 922(TO-822)X 1197(records)X 1455(occupy)X 1708(a)X 1765(new)X 1921(subtree)X 2175(of)X 2264(the)X 2384(DNS.)X 2586(Care)X 2760(must)X 2937(be)X 3035(taken)X 3231(to)X 3315(organize)X 3614(this)X 3751(informa-)X 576 3853(tion)N 720(correctly.)X 776 3976(Each)N 961(second)X 1208(level)X 1389(domain)X 1654(with)X 1821(the)X 1944("ORMAP")X 2319(domain)X 2584(will)X 2733(reside)X 2950(in)X 3037(its)X 3137(own)X 3300(zone)X 3477(\(this)X 3644(corresponds)X 576 4066(to)N 670(each)X 850(country)X 1126(within)X 1361(the)X 1490(O/R)X 1654(address)X 1926(namespace\).)X 2377(Each)X 2569(country)X 2845(that)X 2996(has)X 3134(a)X 3201(Well)X 3388(Known)X 3655(Entry)X 3864(Point)X 576 4156(\(WEP\))N 825(connected)X 1177(to)X 1265(the)X 1390(DNS)X 1577(will)X 1728(be)X 1831(responsible)X 2223(for)X 2344(operating)X 2674(an)X 2777(authoritative)X 3209(name)X 3410(server)X 3634(for)X 3755(the)X 3880(zone)X 576 4246(corresponding)N 1068(to)X 1163(its)X 1271(country.)X 1569(Subtrees)X 1878(of)X 1977(the)X 2107(DNS)X 2299(within)X 2535(that)X 2687(country)X 2964(may)X 3134(be)X 3242(delegated)X 3582(to)X 3676(subsequent)X 576 4336(authoritative)N 1001(nameservers)X 1423(in)X 1505(order)X 1695(to)X 1777(distribute)X 2099(the)X 2217(maintainence)X 2665(of)X 2752(the)X 2870(TO-822)X 3144(record)X 3370(management.)X 776 4459(The)N 922(TO-822)X 1197(resource)X 1491(records)X 1749(of)X 1837(countries)X 2152(that)X 2294(do)X 2396(not)X 2520(have)X 2694(WEPs)X 2916(connected)X 3264(to)X 3348(the)X 3468(DNS)X 3650(will)X 3796(have)X 3970(to)X 576 4549(request)N 834(that)X 980(a)X 1042(neighbor)X 1353(volunteer)X 1682(to)X 1770(be)X 1872(authoritative)X 2303(for)X 2423(their)X 2596(zone.)X 2794(The)X 2945(nameservers)X 3373(which)X 3595(are)X 3720(authorita-)X 576 4639(tive)N 716(for)X 830(these)X 1015(zones)X 1218(are)X 1337(known)X 1575(as)X 1662("proxy")X 1935(nameservers.)X 776 4762(Sites)N 953(that)X 1095(do)X 1197(not)X 1321(connect)X 1593(to)X 1677(the)X 1798(DNS)X 1981(will)X 2128(be)X 2227(responsible)X 2615(for)X 2732(submitting)X 3096(their)X 3266(mapping)X 3569(information)X 3970(to)X 576 4852(their)N 743(proxy)X 950(nameserver)X 1341(in)X 1423(a)X 1479(timely)X 1703(manner.)X 776 4975(Proxy)N 992(nameservers)X 1419(will)X 1568(also)X 1722(be)X 1823(used)X 1995(to)X 2082(store)X 2263(TO-X400)X 2600(RRs)X 2762(for)X 2881(domains)X 3177(that)X 3322(do)X 3427(not)X 3554(have)X 3731(entries)X 3970(in)X 576 5065(the)N 694(DNS)X 874(\(e.g.,)X 1057(.bitnet\).)X 3 f 576 5251(5.2.)N 736(Generation)X 1143(of)X 1230(the)X 1357(table)X 1546(form)X 1736(of)X 1823(the)X 1950(mappings)X 1 f 776 5374(Periodically,)N 1212(the)X 1339(entire)X 1551(contents)X 1848(of)X 1945(all)X 2055(TO-822)X 2339(and)X 2485(TO-X400)X 2827(RRs)X 2994(in)X 3086(the)X 3214(DNS)X 3404(will)X 3558(be)X 3664(obtained)X 3970(in)X 576 5464(order)N 766(to)X 848(produce)X 1127(the)X 1245(table)X 1421(form)X 1597(of)X 1684(the)X 1802(mappings.)X 776 5587(This)N 939(operation)X 1263(will)X 1408(utilize)X 1629(the)X 1748(zone)X 1921(transfer)X 2188(mechanism.)X 2594(The)X 2740(operation)X 3064(assumes)X 3352(that)X 3494(the)X 3614(results)X 3845(of)X 3934(the)X 576 5677(previous)N 889(generation)X 1265(are)X 1401(available)X 1728(to)X 1827(be)X 1940(used)X 2124(as)X 2228(default)X 2488(information)X 2903(if)X 2988(the)X 3122(new)X 3292(information)X 3706(cannot)X 3956(be)X 576 5767(obtained.)N 918(The)X 1069(following)X 1406(algorithm)X 1743(de\256nes)X 1996(the)X 2120(manner)X 2387(in)X 2475(which)X 2697(the)X 2822(TO-822)X 3103(records)X 3367(will)X 3518(be)X 3621(retrieved.)X 3974(A)X 3 f 576 6048(Cole&Hagens)N 3753([Page)X 3965(6])X 7 p %%Page: 7 7 10 s 10 xH 0 xS 3 f 576 474(Draft)N 3571(October)X 3872(1990)X 1 f 576 762(similiar)N 840(mechansim)X 1225(can)X 1357(be)X 1453(used)X 1620(to)X 1702(retrieve)X 1968(the)X 2086(TO-X400)X 2418(RRs.)X 576 885(Step)N 738(1)X 776 975(Initialize)N 1084(the)X 1205(results)X 1437(\256le)X 1562(to)X 1647(the)X 1768(results)X 2000(of)X 2090(the)X 2211(previous)X 2510(generation.)X 2912(Initialize)X 3220(the)X 3341(dmn-orname)X 3774(pending)X 776 1065(list)N 576 1188(Step)N 738(2)X 776 1278(Initiate)N 1023(an)X 1119(AXFR)X 1352(request)X 1604(to)X 1686(the)X 1804(authoritative)X 2229(nameserver)X 2620(for)X 2734(the)X 2852(domain)X 3112(name)X 3306("ORMAP.".)X 576 1401(Step)N 738(3)X 776 1491(For)N 907(each)X 1075(record:)X 1096 1614(if)N 1165(type)X 1323(is)X 1396(NS)X 1518(and)X 1654(the)X 1772(owner-name)X 2194(is)X 2267(a)X 2323(subdomain)X 2694(of)X 1384 1704(the)N 1502(AXFR)X 1735(request)X 1987(name,)X 2201(add)X 2337(the)X 2455(owner-name)X 2877(to)X 2959(pending)X 3237(list)X 1096 1794(if)N 1165(type)X 1323(is)X 1396(TO-822,)X 1690(save)X 1853(to)X 1935(results)X 2164(\256le)X 2286(\(replacing)X 2632(the)X 1384 1884(existing)N 1657(information,)X 2075(if)X 2144(present.)X 576 2040(Step)N 738(4)X 776 2130(If)N 851(the)X 970(pending)X 1249(list)X 1367(is)X 1441(empty,)X 1682(stop.)X 1856(Otherwise,)X 2227(take)X 2382(the)X 2501(next)X 2661(dmn-orname)X 3093(from)X 3271(the)X 3391(pending)X 3671(list,)X 3810(initiate)X 776 2220(an)N 872(AXFR)X 1105(request)X 1357(to)X 1439(its)X 1534(authoritative)X 1959(nameserver,)X 2370(and)X 2506(goto)X 2668(step)X 2817(3.)X 776 2343(It)N 850(is)X 928(possible)X 1215(that)X 1360(sites)X 1527(will)X 1676(not)X 1803(allow)X 2006(a)X 2067(zone)X 2244(transfer.)X 2535(This)X 2702(must)X 2883(be)X 2985(discouraged.)X 3419(Perhaps)X 3699(if)X 3774(the)X 3898(TO-)X 576 2433(822)N 718(and)X 856(TO-X400)X 1190(RRs)X 1349(are)X 1470(placed)X 1702(into)X 1848(their)X 2017(own)X 2177(class)X 2355(\(ISO\),)X 2580(and)X 2718(the)X 2838(zone)X 3012(transfer)X 3280(granularity)X 3654(is)X 3728(increased)X 576 2523(to)N 658(be)X 754(class)X 930(speci\256c,)X 1215(this)X 1350(response)X 1651(can)X 1783(be)X 1879(avoided.)X 776 2646(The)N 939(algorithm)X 1288(will)X 1451(loop)X 1632(in\256nitely)X 1959(if)X 2047(the)X 2184(dmn-orname)X 2633(pending)X 2930(list)X 3066(is)X 3158(not)X 3299(empty)X 3538(and)X 3693(each)X 3880(zone)X 576 2736(described)N 904(by)X 1004(the)X 1122(dmn-orname)X 1552(pending)X 1830(list)X 1947(is)X 2020(unreachable.)X 2469(This)X 2631(condition)X 2953(must)X 3128(be)X 3224(detected.)X 3532(When)X 3744(detected,)X 576 2826(the)N 706(algorithm)X 1049(should)X 1294(be)X 1402(terminated.)X 1797(The)X 1954(information)X 2364(from)X 2552(the)X 2682(previous)X 2990(generation)X 3361(will)X 3518(be)X 3627(used)X 3807(for)X 3934(the)X 576 2916(non-reachable)N 1052(zones.)X 776 3039(Emperical)N 1138(evidence)X 1456(suggests)X 1759(that)X 1911(this)X 2058(process)X 2331(may)X 2501(take)X 2668(several)X 2929(days)X 3109(to)X 3204(complete.)X 3571(Thus,)X 3784(the)X 3915(fre-)X 576 3129(quency)N 828(should)X 1061(be)X 1157(low)X 1297(\(every)X 1523()X 1807(months\).)X 776 3252(The)N 921(table)X 1097(produced)X 1416(by)X 1516(this)X 1651(mechanism)X 2036(will)X 2180(be)X 2276(distributed)X 2638(to)X 2720(non)X 2860(DNS)X 3040(sites.)X 3 f 576 3438(6.)N 676(Which)X 922(address)X 1204(class)X 1384(to)X 1471(use?)X 1 f 776 3561(It)N 850(can)X 987(be)X 1088(convenient)X 1465(for)X 1584(these)X 1774(records)X 2036(to)X 2123(be)X 2224(stored)X 2445(in)X 2533(the)X 2657(same)X 2848(DNS)X 3034(zones)X 3243(as)X 3336(other)X 3527(resource)X 3826(record)X 576 3651(types,)N 793(such)X 968(as)X 1063(internet)X 1335(address)X 1603(records.)X 1907(It)X 1983(seems)X 2206(reasonable)X 2577(to)X 2666(store)X 2849(these)X 3041(records)X 3305(in)X 3394(the)X 3519(internet)X 3791(address)X 576 3741(class)N 760(since)X 953(the)X 1079(TO-X400)X 1419(records)X 1684(refer)X 1866(to)X 1957(owner-names)X 2419(which)X 2644(are)X 2772(already)X 3038(present)X 3299(in)X 3390(the)X 3517(internet)X 3791(address)X 576 3831(class.)N 804(In)X 903(our)X 1042(initial)X 1260(implementation)X 1793(of)X 1891(these)X 2087(new)X 2252(DNS)X 2443(records,)X 2731(the)X 2860(records)X 3128(are)X 3258(assigned)X 3565(to)X 3658(the)X 3787(internet)X 576 3921(address)N 837(class.)X 776 4044(However,)N 1120(these)X 1314(records)X 1580(should)X 1822(probably)X 2136(be)X 2241(placed)X 2480(in)X 2571(a)X 2636(new)X 2799(address)X 3069(class)X 3254(such)X 3430(as)X 3526(an)X 3632(ISO)X 3791(address)X 576 4134(class.)N 794(This)X 958(would)X 1180(allow)X 1380(the)X 1500(zones)X 1705(containing)X 2065(TO-X400)X 2399(and)X 2536(TO-822)X 2811(records)X 3069(to)X 3152(be)X 3249(delegated)X 3578(independently)X 576 4224(of)N 686(already)X 966(existing)X 1262(DNS)X 1465(zones.)X 1731(This)X 1916(could)X 2137(be)X 2256(particularly)X 2669(useful)X 2908(if)X 3000(it)X 3087(is)X 3183(desired)X 3459(to)X 3565(keep)X 3761(the)X 3903(root)X 576 4314(nameservers)N 1028(for)X 1172(this)X 1337(mapping)X 1667(data)X 1851(separate)X 2165(from)X 2371(the)X 2519(current)X 2797(internet)X 3092(root)X 3271(nameservers.)X 3763(If)X 3867(these)X 576 4404(nameservers)N 1003(are)X 1127(not)X 1254(separate,)X 1563(then)X 1726(it)X 1795(is)X 1874(expected)X 2186(that)X 2332(the)X 2456(existing)X 2735(root)X 2890(nameservers)X 3318(will)X 3468(be)X 3570(given)X 3774(the)X 3898(new)X 576 4494(burden)N 820(of)X 908(acting)X 1125(as)X 1213(proxy)X 1421(nameservers.)X 1864(In)X 1952(addition,)X 2255(the)X 2374(resolvers)X 2685(can)X 2818(be)X 2915(modi\256ed)X 3220(to)X 3302(make)X 3496(the)X 3614(zone)X 3786(transfer)X 576 4584(denial)N 792(to)X 874(be)X 970(class)X 1146(speci\256c.)X 776 4707(Note)N 960(that)X 1108(the)X 1234(scope)X 1445(of)X 1540(wildcard)X 1849(resource)X 2151(records)X 2417(are)X 2545(bounded)X 2850(by)X 2959(the)X 3086(presence)X 3397(of)X 3493(resource)X 3795(records)X 576 4797(that)N 724(occupy)X 984(subdomains)X 1394(of)X 1489(the)X 1615(wildcard)X 1924(record.)X 2198(If)X 2280(the)X 2406(scope)X 2617(of)X 2712(wildcard)X 3021(records)X 3285(is)X 3365(affected)X 3652(by)X 3759(resource)X 576 4887(records)N 842(from)X 1027(different)X 1333(address)X 1603(classes,)X 1875(then)X 2042(wildcard)X 2352(records)X 2618(can)X 2759(be)X 2864(affected)X 3153(in)X 3244(non-intuitive)X 3686(ways.)X 3921(For)X 576 4977(example)N 868(the)X 986(records:)X 976 5100(*.B.A.)N 1472(IN)X 1760(MX)X 2048(0)X 2148(B.A.)X 976 5190(C.B.A.)N 1472(HS)X 1760(TXT)X 2048("data")X 576 5403(would)N 805(cause)X 1013(internet)X 1288(address)X 1559(class)X 1745(MX)X 1904(queries)X 2166(for)X 2290(any)X 2436(domain)X 2706(name)X 2910(ending)X 3158(in)X 3250(C.B.A)X 3484(to)X 3576(not)X 3708(match)X 3934(the)X 576 5493(above)N 791(wildcard)X 1095(record.)X 1363(If)X 1439(a)X 1497(separate)X 1783(address)X 2046(class)X 2224(is)X 2299(to)X 2383(be)X 2481(used)X 2650(for)X 2766(the)X 2886(TO-X400)X 3220(and)X 3358(TO-822)X 3634(records,)X 3913(it)X 3979(is)X 576 5583(preferable)N 928(for)X 1047(wildcard)X 1353(records)X 1615(to)X 1702(not)X 1829(be)X 1930(affected)X 2215(by)X 2320(resource)X 2619(records)X 2882(from)X 3064(other)X 3255(address)X 3522(classes.)X 3811(This)X 3979(is)X 576 5673(considered)N 944(a)X 1000(bug,)X 1160(not)X 1282(a)X 1338(feature)X 1582(of)X 1669(the)X 1787(current)X 2035(DNS)X 2215(implementations.)X 3 f 576 6048(Cole&Hagens)N 3753([Page)X 3965(7])X 8 p %%Page: 8 8 10 s 10 xH 0 xS 3 f 576 474(Draft)N 3571(October)X 3872(1990)X 576 762(7.)N 676(Summary)X 1 f 776 885(Internet)N 1050(DNS)X 1234(nameservers)X 1660(wishing)X 1937(to)X 2023(provide)X 2292(this)X 2431(mapping)X 2735(information)X 3137(need)X 3313(to)X 3399(be)X 3499(modi\256ed)X 3807(to)X 3894(sup-)X 576 975(port)N 725(two)X 865(new)X 1019(resource)X 1312(record)X 1538(types,)X 1747(and)X 1883(possibly)X 2169(a)X 2225(new)X 2379(address)X 2640(class.)X 776 1098(Usage)N 1007(of)X 1104(these)X 1299(extensions)X 1667(provide)X 1942(RFC987)X 2242(gateways)X 2571(with)X 2743(the)X 2872(advantages)X 3260(listed)X 3464(in)X 3557(the)X 3686(motivation)X 576 1188(section.)N 863(These)X 1075(advantages)X 1452(are)X 1571(important)X 1902(for)X 2016(the)X 2134(administration)X 2616(of)X 2703(RFC987)X 2993(gateways.)X 3 f 576 1374(8.)N 676(References)X 1 f 896 1497([CCITT])N 1201(CCITT)X 1452(SG)X 1574(5/VII,)X 1788("Recommendation)X 2406(X.400,")X 2677(Message)X 896 1587(Handling)N 1214(Systems:)X 1522(System)X 1777(Model)X 2006(-)X 2053(Service)X 2314(Elements,)X 2652(October)X 2931(1984.)X 896 1767([PP])N 1058(Kille,)X 1258(S.,)X 1362("PP)X 1503(Installation)X 1883(and)X 2019(Operation",)X 2413(Volume)X 2691(1,)X 2771(December)X 3122(1989.)X 896 1947([RFC)N 1093(974])X 1260(Partridge,)X 1594(C.,)X 1707("Mail)X 1911(routing)X 2162(and)X 2298(the)X 2416(domain)X 2676(system",)X 896 2037(RFC)N 1066(974,)X 1226(CSNET)X 1499(CIC)X 1652(BBN)X 1836(Labs,)X 2032(January)X 2302(1986.)X 896 2217([RFC)N 1093(987])X 1280(Kille,)X 1480(S.,)X 1584("Mapping)X 1926(Between)X 2227(X.400)X 2445(and)X 2581(RFC)X 2751(822",)X 2964(UK)X 896 2307(Academic)N 1242(Community)X 1643(Report)X 1881(\(MG.19\))X 2184(/)X 2226(RFC)X 2396(987,)X 2556(June)X 2723(1986.)X 896 2487([RFC)N 1093(1026])X 1320(Kille,)X 1520(S.,)X 1624("Addendum)X 2033(to)X 2115(RFC)X 2285(987",)X 2478(UK)X 2614(Academic)X 2960(Community)X 896 2577(Report)N 1134(\(MG.23\))X 1437(/)X 1479(RFC)X 1649(1026,)X 1849(August)X 2100(1987.)X 896 2757([RFC)N 1093(1034])X 1320(Mockapetris,)X 1761(P.,)X 1865("Domain)X 2176(Names)X 2419(-)X 2466(Concepts)X 2784(and)X 896 2847(Facilities",)N 1262(RFC)X 1432(1034,)X 1632(USC/Information)X 2212(Sciences)X 2513(Institute,)X 2815(November)X 896 2937(1987.)N 896 3117([RFC)N 1093(1035])X 1320(Mockapetris,)X 1761(P.,)X 1865("Domain)X 2176(names)X 2401(-)X 2448(Implementation)X 2975(and)X 896 3207(Speci\256cation",)N 1387(RFC)X 1557(1035,)X 1757(USC/Information)X 2337(Sciences)X 2638(Institute,)X 896 3297(November)N 1255(1987.)X 896 3477([WG])N 1104(OSI-X.400)X 1478(Working)X 1783(Group)X 2008(Meeting,)X 2315(October)X 2594(1989.)X 3 f 576 6048(Cole&Hagens)N 3753([Page)X 3965(8])X 8 p %%Trailer xt xs From S.Kille@cs.ucl.ac.uk Mon Oct 8 05:25:29 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Mon, 8 Oct 90 05:25:29 -0500 Received: from bells.cs.ucl.ac.uk by cs.wisc.edu; Mon, 8 Oct 90 05:25:24 -0500 Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <9902-0@bells.cs.ucl.ac.uk>; Mon, 8 Oct 1990 11:21:41 +0100 To: Alf Hansen Cc: pp-people@cs.ucl.ac.uk, rare-wg1@switch.ch, mhsnews@ICS.UCI.edu, ietf-osi-x400, rd-mhs-managers@rare.no Subject: Re: The NSF X.400 Pilot Project. Phone: +44-71-380-7294 In-Reply-To: Your message of Thu, 27 Sep 90 17:09:28 -0500. <900927170926*@MHS> Date: Mon, 08 Oct 90 11:21:37 +0100 Message-Id: <802.655381297@UK.AC.UCL.CS> From: Steve Kille Alf, Thanks for this message. I hope that your piloting activities and PP will have a useful symbiosis. A few thoughts: 1) I find the Internet X.400 piloting discussions difficult, as they seem to occur in a policy vacuum (this statement is meant to be provocative). Your description is of laying out a pilot service, with transition to full service. However, I don't see this reflected in overall strategy for the Internet (e.g., as RFCs on overall plan or IETF minutes). 2) Your service model is very oriented to the "external view". This facilitates connection of other WEPs and external commercial services using X.400. There needs to be more focus on an "internal" view. I'd like to see: - Information as to benefits of joining the pilot (short term, strategic) - Model for an organisation to transition / join the pilot. This is non-trivial for any organisation with a serious commitment to local messaging services - managing links within the PRMD (X.400 is oriented to bilaterally agreed links), and intra-PRMD routing. I don't see how the external aspects can be tackled as any sort of service, until there is a coherent internal view. This needs to be considered in terms of overall message service for the organisation, and not just X.400. 3) On managing 987 /1148 mapping tables for PP. UCl provides PP format mapping tables derived from the international tables, which PP sites can pull on a regular basis. US PP sites should submit any mappings they need through you. This will ensure that the mapping is a genuinely global one. Steve From S.Kille@cs.ucl.ac.uk Mon Oct 8 12:59:08 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Mon, 8 Oct 90 12:59:08 -0500 Received: from bells.cs.ucl.ac.uk by cs.wisc.edu; Mon, 8 Oct 90 12:59:00 -0500 Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <26874-0@bells.cs.ucl.ac.uk>; Mon, 8 Oct 1990 18:56:36 +0100 To: ORName Map , ifip-gtwy@tis.llnl.gov Subject: Interop BOF on RFC 822 / X.400 Mappings Phone: +44-71-380-7294 In-Reply-To: Your message of Fri, 14 Sep 90 13:58:00 +0100. <1337.653317080@UK.AC.UCL.CS> Date: Mon, 08 Oct 90 18:56:33 +0100 Message-Id: <1898.655408593@UK.AC.UCL.CS> From: Steve Kille Just a brief note that this will be happening. The session will include, but not be restricted to: - A presentation by Alf Hansen on expereince with 1148/987 in the European MHS Pilot - Discussions on use of DNS (and possibly X.500) to support 1148 - What to do about "_" and RFC 1137 This should be plenty for two hours. Steve From S.Kille@cs.ucl.ac.uk Mon Oct 8 13:00:56 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Mon, 8 Oct 90 13:00:56 -0500 Received: from bells.cs.ucl.ac.uk by cs.wisc.edu; Mon, 8 Oct 90 13:00:51 -0500 Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <26929-0@bells.cs.ucl.ac.uk>; Mon, 8 Oct 1990 18:58:33 +0100 To: ORName Map , ifip-gtwy@tis.llnl.gov Subject: Re: Interop BOF on RFC 822 / X.400 Mappings Phone: +44-71-380-7294 In-Reply-To: Your message of Fri, 14 Sep 90 13:58:00 +0100. <1337.653317080@UK.AC.UCL.CS> Date: Mon, 08 Oct 90 18:58:31 +0100 Message-Id: <1903.655408711@UK.AC.UCL.CS> From: Steve Kille Forgot the most important thing! Meeting will be 18:00 - 20:00 on Thursday 11th October, at Interop 90: San Jose Convention and Cultural Center Steve From Eppenberger@verw.switch.ch Tue Oct 9 07:30:10 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Tue, 9 Oct 90 07:30:10 -0500 Received: from chx400.switch.ch by cs.wisc.edu; Tue, 9 Oct 90 07:30:03 -0500 Received: by chx400.switch.ch (5.61/Ultrix2.4-C) id AA07918; Tue, 9 Oct 90 13:29:55 +0100 Date: 9 Oct 90 13:29 +0100 From: "Urs Eppenberger" To: Cc: , In-Reply-To: <9010051755.AA20135@janeb.ch> Message-Id: <448*Eppenberger@verw.switch.ch> Subject: New version of 987/DNS paper Dear Rob, many thanks for the new version of your paper. Let me start with the comments concerning small items: - page 2 second paragraph T0-822 should read TO-822 - page 3 line 2: UK is not a valid country code, use GB instead. - Be aware of the fact that OR attributes may contain one or more dots, even at the beginning or at the end! This shouldn't give problems, but when the implementors start to code your proposal, they should be careful with the interpretation of the wildcard-count. It counts OR attributes, not fields concatenated with dots! You might wish to add somewhere a sentense addressing this issue. Now comes the major item: last sentence in chap 5 > The master copy of the mapping database will be the copy stored in the DNS > namespace. second last paragraph in chap 5.1 > Sites that do not connect the DNS will be responsible for submitting their > mapping information to their proxy nameserver in a timely manner. I think that these two sentences are the key issue of your paper, the rest are technical details which are addressed very carefully by you. Currently the master copy is managed by the RARE MHS project team. From the technical point of view it is clear that the DNS should be used for storing the master copy. But the fact that there IS already a master copy does not allow the simple statement in chap 5 without any comments or handover procedure! Please add a chapter for the transition phase. Keeping the master copy is related with responsibility and authority. - With DNS the responsibility is distributed. I would like to have this aspect also discussed. - Once the master copy is stored in DNS, also the authority is implicitely delegated to the people running DNS. Is it shure that also the DNS people hand over the master copy and the authority to a future X.500 based directory system? This point should be discussed also. Kind regards, Urs Eppenberger, SWITCH From hagens Tue Oct 9 10:08:15 1990 Message-Id: <9010091508.AA25017@janeb.cs.wisc.edu> Received: from localhost by janeb.cs.wisc.edu; Tue, 9 Oct 90 10:08:15 -0500 To: "Urs Eppenberger" Cc: ietf-osi-x400, RARE-WG1@switch.ch Subject: Re: New version of 987/DNS paper In-Reply-To: Your message of "09 Oct 90 13:29:00 BST." <448*Eppenberger@verw.switch.ch> Date: Tue, 09 Oct 90 10:08:05 EDT From: hagens > Now comes the major item: > last sentence in chap 5 > > The master copy of the mapping database will be the copy stored in the DNS > > namespace. > second last paragraph in chap 5.1 > > Sites that do not connect the DNS will be responsible for submitting their > > mapping information to their proxy nameserver in a timely manner. > > I think that these two sentences are the key issue of your paper, the rest I left these sections vague for the moment -- I hope that we can discuss appropriate strategies for this section via e-mail, and also at the next IETF WG meeting. Rob From stef@nma.com Mon Nov 5 17:57:35 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Mon, 5 Nov 90 17:57:35 -0600 Received: from NRTC.NORTHROP.COM by cs.wisc.edu; Mon, 5 Nov 90 17:57:25 -0600 Received: from nma.com by nrtc.nrtc.northrop.com id aa16978; 5 Nov 90 15:56 PST Received: from localhost by nma.com id aa09705; 5 Nov 90 15:11 PST To: Christian Huitema Cc: Steve Kille , hagens, Alf Hansen , rd-mhs-managers@nac.no, rare-wg1@switch.ch, pp-people@cs.ucl.ac.uk, ietf-osi-or Subject: Re: RFC 987 Procedures. In-Reply-To: Your message of Mon, 05 Nov 90 08:32:38 +0000. <9011050833.AA12144@jerry.inria.fr> Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Mon, 05 Nov 90 15:11:20 -0800 Message-Id: <9701.657846680@nma.com> Sender: stef@nma.com Hi All -- I have to agree with Christian about finding ways to let the 2nd level DNS names map to the ORAddress ORG= level. This is why I long ago proposed using NREN+GOV, NREN+ORG, NREN+COM, NREN+MIL, NREN+EDU, NREN+NET become defined NREN PRMD names in the US. This leaves the top level DNS domain of .US in the clear for other mappings as may be appropriate, and it provides a simple and memorable mapping for most users. I believe that the NSF has acted to trademark "NREN" and to register it with ANSI. ANSI is sitting on all registration applications, including the NREN application filed by NSF (I think) on behalf of the "NREN community" in the US. I recall hearing a rumor that ANSI resonded to suggest that NREN be trademarked. (This is the only known (rumored) case of ANSI responding in any way to any application request.) I suggest that the time may be at hand to start using the NREN name and constructing the names above (e.g., NREN+EDU...) to establish worldwide mapping between X.400<+>RFC-822 for the "US domains". By this I mean those pesky EDU, GOV, MIL, ORG, COM, NET domains in the DNS name system. However, the "construction syntax" plan that has been developed by the NIST OIW has not yet been considered by the new US Study Group D Subcommittee on MHS Management Domains, which has the requisite authority (to recommend to Study Group D) that the US use (or not use) such a construction syntax scheme (described below). The new MHSMD Subcommittee will hold its first meeting at the US Dept of State on December 17-18. I will separately forward a copy of the recently adopted charter and its annexes for your information. So, I would like to have this community consider and discuss how it wants to set things up and prepare a contribution to the new MHSMD Subcommittee to explain what the US NREN and Global INTERNET communities want. I propose the NREN+[GOV,COM,EDU,MIL,NET,ORG] for INTERNET PRMD names. In short, the new MHSMD Subcommittee is soliciting contributions! I would prepare something but it must represent more than just my opinons. Best...\Stef From sgoldste@cise.nsf.gov Mon Nov 5 18:52:22 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Mon, 5 Nov 90 18:52:22 -0600 Received: from cise.cise.nsf.gov by cs.wisc.edu; Mon, 5 Nov 90 18:52:12 -0600 Received: from ncri.cise.nsf.gov by cise.cise.nsf.gov id ; Mon, 5 Nov 90 19:39:41 -0500 Message-Id: <9011060039.AA05034@cise.cise.nsf.gov> To: Stef@ics.uci.edu Cc: huitema@mirsa.inria.fr, Steve Kille , hagens, Alf Hansen , rd-mhs-managers@nac.no, rare-wg1@switch.ch, pp-people@cs.ucl.ac.uk, ietf-osi-or Subject: Re: RFC 987 Procedures. In-Reply-To: Your message of "Mon, 05 Nov 90 15:11:20 PST." <9701.657846680@nma.com> Date: Mon, 05 Nov 90 19:39:36 EST From: Steven N. Goldstein--Ph 202-357-9717 Stef, et al., Re NSF and "trademarking" "NREN", please be advised that NSF has applied for a service mark with the US Patent and Trademark Office for both "NREN" and "National Research and Education Network" on behalf of the US Government's interest in the NREN. Please do not use "NREN" or "National Research and Education Network" in the name of any service offering without permission from, or in the absence of guidelines for allowable use from NSF. I would expect that in addition to consulting legal staff, NSF would bring the matter of requests to use "NREN", etc. to the Federal Network Council for resolution. I wish I could be more "legal" about the above statement, but, alas, I am not a lawyering type. Also, i am about to depart the country for about 10 days, and therefore cannot get any further resolution of the issue at this time. I will get back to you, soonest. Thanks, Steve G. > > >Hi All -- I have to agree with Christian about finding ways to let the >2nd level DNS names map to the ORAddress ORG= level. This is why I long >ago proposed using NREN+GOV, NREN+ORG, NREN+COM, NREN+MIL, NREN+EDU, >NREN+NET become defined NREN PRMD names in the US. This leaves the top >level DNS domain of .US in the clear for other mappings as may be >appropriate, and it provides a simple and memorable mapping for most >users. > >I believe that the NSF has acted to trademark "NREN" and to register it >with ANSI. ANSI is sitting on all registration applications, including >the NREN application filed by NSF (I think) on behalf of the "NREN >community" in the US. I recall hearing a rumor that ANSI resonded to >suggest that NREN be trademarked. (This is the only known (rumored) >case of ANSI responding in any way to any application request.) > >I suggest that the time may be at hand to start using the NREN name and >constructing the names above (e.g., NREN+EDU...) to establish worldwide >mapping between X.400<+>RFC-822 for the "US domains". By this I mean >those pesky EDU, GOV, MIL, ORG, COM, NET domains in the DNS name system. > >However, the "construction syntax" plan that has been developed by the >NIST OIW has not yet been considered by the new US Study Group D >Subcommittee on MHS Management Domains, which has the requisite >authority (to recommend to Study Group D) that the US use (or not use) >such a construction syntax scheme (described below). The new MHSMD >Subcommittee will hold its first meeting at the US Dept of State on >December 17-18. I will separately forward a copy of the recently >adopted charter and its annexes for your information. > >So, I would like to have this community consider and discuss how it >wants to set things up and prepare a contribution to the new MHSMD >Subcommittee to explain what the US NREN and Global INTERNET communities >want. I propose the NREN+[GOV,COM,EDU,MIL,NET,ORG] for INTERNET PRMD >names. > >In short, the new MHSMD Subcommittee is soliciting contributions! I >would prepare something but it must represent more than just my opinons. > >Best...\Stef From Alf.Hansen@pilot.cs.wisc.edu Tue Nov 6 01:43:20 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Tue, 6 Nov 90 01:43:20 -0600 Received: from nac.no by cs.wisc.edu; Tue, 6 Nov 90 01:42:46 -0600 Received: from localhost by nac.no (5.64+IDA/Babel-1.6/6.0) with SMTP id AAnac28581; Tue, 6 Nov 1990 08:42:30 +0100 Received: from /PRMD=xnren/ADMD=_/C=us/ by nac.no with X.400 id ; Mon, 5 Nov 1990 23:36:32 -0500 Date: Mon, 5 Nov 1990 23:36:32 -0500 From: Alf Hansen Message-Id: <901105233629*Alf.Hansen@pilot.cs.wisc.edu> To: , , , In-Reply-To: <9701.657846680@nma.com > References: , , , , <9011050833.AA12144@jerry.inria.fr>, <9701.657846680@nma.com> Subject: Re: RFC 987 Procedures. Dear Colleague, I am also very much in favour of the various proposals that have been put forward. I will now just make you aware of the danger to mix up things in this discussion. Rob Hagens started with a proposal for a mapping of RFC-822 addresses into X.400 addresses, for the domains .edu, etc. in the US. This means a definition of how the existing RFC-822 address space should look like seen from X.400. He did not propose an address structure for X.400 in the Internet. The future address structure for X.400 in the Internet is a separate discussion. If I understood Stef correctly, his comment was exactly starting on this separate discussion: The future structure of the X.400 address space in the Internet. (Please correct me if I am wrong). We should try to distinguish between these two related questions when we continue the discussion. Best regards, Alf H. From harald.alvestrand@elab-runit.sintef.no Tue Nov 6 04:54:48 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Tue, 6 Nov 90 04:54:48 -0600 Received: from tosca.er.sintef.no by cs.wisc.edu; Tue, 6 Nov 90 04:54:26 -0600 Received: from localhost by tosca.er.sintef.no (5.61+IDA/KTH/LTH/1.4) with SMTP id AAtosca08021; Tue, 6 Nov 90 11:50:31 +0100 Received: from /PRMD=uninett/ADMD=_/C=no/ by tosca.elab-runit.sintef.no with X.400 id ; Tue, 6 Nov 1990 11:50:27 +0100 Date: Tue, 6 Nov 1990 11:50:27 +0100 From: Harald Tveit Alvestrand In-Reply-To: <901105233629*Alf.Hansen@pilot.cs.wisc.edu> To: Alf Hansen Cc: , , , Subject: Re: RFC 987 Procedures. References: , , , , <9011050833.AA12144@jerry.inria.fr>, <9701.657846680@nma.com> Message-Id: <1869*harald.alvestrand@elab-runit.sintef.no> Hello all. Here I put my foot into it again: Like Alf, I think we should separate the concerns about mapping the current Internet and the future shape of US X.400 addresses. Unlike Christian, I think that C=us;PRMD=RFC822;O=FR is not an abomination, it is simply a way to give any user a way to act in the absence of information. (Recently, I saw a message listing top level domains saying: "no - do not know, perhaps the Nowhere network :-) Like Steven Goldstein, I think that defining this "mapping of the old Internet" using the characters N, R, E and N will probably delay its introduction. Back to the abominations: I think there are three things that I consider bad here: - Imposing mappings on other countries, like EAN does when it does not find a table entry: x@somewhere.MX -> C=MX;ADMD=somewhere;S=x C=tn;ADMD=tunisia;S=x -> x@tunisia.tn Neither the X.400 service "somewhere" in Mexico nor the top-level domain tn exist. (I think this was also done in MAILWAY 5.4. Is it modified?) - Requiring the user to keep the RFC987 tables in his head, all 1704 lines of them, like all interfaces that do not offer RFC-822 format input of SA addresses or vice versa do. - Requiring the user to keep in his head the address of the gateway between X.400 and RFC-822, like the use of DD.RFC822 does. - Allowing two different representations of a single address, as happens when C=no;PRMD=uninett;O=sintef;S=alvestrand becomes equal to C=us;PRMD=RFC822;O=no;OU=sintef;S=alvestrand. On the surface, the third bad thing should not be too bad, but practical experience (Christian and Steve, I believe) showed that it was. So, I think that of colera, black death, measles and flu, I prefer flu. I am able to tell that to my users in five sentences. Also, I support the idea of putting this into place after agreeing with ONE US ADMD about it. Sending data between PRMDs is always allowed, and we all know what PRMD=RFC822 means, don't we? (And of course, the US has taken the sensible position of unique PRMD names - have they?) My opinions.............. Harald Tveit Alvestrand From jh@funet.fi Tue Nov 6 10:48:08 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Tue, 6 Nov 90 10:48:08 -0600 Received: from funet.fi by cs.wisc.edu; Tue, 6 Nov 90 10:47:54 -0600 Received: by funet.fi; Tue, 6 Nov 90 18:47:06 +0200 Message-Id: <9011061647.AA13270@funet.fi> Date: Tue, 6 Nov 90 18:47:06 +0200 From: jh@funet.fi (Juha Heinanen) To: Alf.Hansen@pilot.cs.wisc.edu Cc: rare-wg1@switch.ch, pp-people@cs.ucl.ac.uk, ietf-osi-x400, rd-mhs-managers@rare.no In-Reply-To: Alf Hansen's message of Mon, 5 Nov 1990 23:36:32 -0500 <901105233629*@MHS> Subject: RFC 987 Procedures. It took quite a while before the RARE x.400 people realized that we can't keep on living long with these inofficial academic ADMD names or spaces as some prefer. When the commercial X.400 services mature, there is need for exchanging X.400 mail between the academic community and the commercial community. This will be difficult unless the X.400 addresses we are using are "real" ie. recognized by the various commercial ADMDs. In Finland we have taken steps into this direction by establishing a "real" ADMD for the academic community which has made official mail exchange agreements between the two commercial ADMDs in Finland. -- Juha From S.Kille@cs.ucl.ac.uk Tue Nov 6 11:40:21 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Tue, 6 Nov 90 11:40:21 -0600 Received: from bells.cs.ucl.ac.uk by cs.wisc.edu; Tue, 6 Nov 90 11:40:12 -0600 Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <9003-0@bells.cs.ucl.ac.uk>; Tue, 6 Nov 1990 17:36:43 +0000 To: Alf Hansen Cc: rare-wg1 , pp-people , ietf-osi-x400 , rd-mhs-managers Subject: Re: RFC 987 Procedures. Phone: +44-71-380-7294 In-Reply-To: Your message of Mon, 05 Nov 90 23:36:32 -0500. <901105233629*Alf.Hansen@pilot.cs.wisc.edu> Date: Tue, 06 Nov 90 17:36:41 +0000 Message-Id: <2036.657913001@UK.AC.UCL.CS> From: Steve Kille Just to summarise my view on this. I agree with Christian's overall analysis - where there is not connectivity, either a DDA or a "national" mapping needs to be made in order so source route the RFC 822 address from within X.400. I agree with the point about the need to specify a mechanism for optimising where the DDA is placed in the OR Address (national choice - registration of 987 gateways). There are two reasons why I prefer the DDA approach 1) Generation of replyable addresses (whilst this is not inherent to the DDA approach or excluded from the SA approach, in practice the SA approach often leads to unreplyable addresses, due to invention of non-existen OR Addresses) 2) Unnatural X.400 addresses. The form 1 variant 1 X.400 OR Addresses were designed to reflect organisational structure. I think that they should be used that way. A big reason for DDAs was to allow interconnection of existing mailsystems without having to abuse this structure. I dissaprove of Org=NREN-EDU in exactly the way I dissaprove of Surname=Joe%fubar.com . If the mapping isn't clean, DDAs are better. No-one has convinced me that this will not work, or of any reason why the SA approach is superior. The only practical argument for use of SAs is deficiencies in one X.400 implementation - I find this to be a poor reason. Steve From Alf.Hansen@pilot.cs.wisc.edu Tue Nov 6 11:47:41 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Tue, 6 Nov 90 11:47:41 -0600 Received: from nac.no by cs.wisc.edu; Tue, 6 Nov 90 11:47:26 -0600 Received: from localhost by nac.no (5.64+IDA/Babel-1.6/6.0) with SMTP id AAnac28775; Tue, 6 Nov 1990 18:47:15 +0100 Received: from /PRMD=xnren/ADMD=_/C=us/ by nac.no with X.400 id ; Tue, 6 Nov 1990 11:43:43 -0500 Date: Tue, 6 Nov 1990 11:43:43 -0500 From: Alf Hansen Message-Id: <901106114340*Alf.Hansen@pilot.cs.wisc.edu> To: Juha Heinanen Cc: , , , In-Reply-To: <9011061647.AA13270@funet.fi > References: , , , , , <901105233629*@MHS>, <9011061647.AA13270@funet.fi> Subject: Re: RFC 987 Procedures. > It took quite a while before the RARE x.400 people realized that we > can't keep on living long with these inofficial academic ADMD names or > spaces as some prefer. When the commercial X.400 services mature, > there is need for exchanging X.400 mail between the academic community > and the commercial community. This will be difficult unless the X.400 > addresses we are using are "real" ie. recognized by the various > commercial ADMDs. In Finland we have taken steps into this direction > by establishing a "real" ADMD for the academic community which has > made official mail exchange agreements between the two commercial > ADMDs in Finland. I think Finland can be used as an example of how "the RARE x.400 people" wanted the service to develop. We need real agreements between real entities, as soon as these entities become real. This is probably what R&D MHS managers are searching for in each country participating in the R&D MHS Service: Real cooperation with the local ADMDs. Until the ADMD entities become real and the services they provide are good and cheap, there is a need for the R&D MHS Service. So, keep up the good work, Juha. Best regard, Alf H From stef@nma.com Tue Nov 6 13:59:09 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Tue, 6 Nov 90 13:59:09 -0600 Received: from nrtc.northrop.com by cs.wisc.edu; Tue, 6 Nov 90 13:59:01 -0600 Received: from nma.com by nrtc.nrtc.northrop.com id ad21625; 6 Nov 90 11:57 PST Received: from localhost by nma.com id aa10515; 5 Nov 90 23:48 PST To: "Steven N. Goldstein--Ph 202-357-9717" Cc: huitema@mirsa.inria.fr, Steve Kille , hagens, Alf Hansen , rd-mhs-managers@nac.no, rare-wg1@switch.ch, pp-people@cs.ucl.ac.uk, ietf-osi-or Subject: Re: RFC 987 Procedures. In-Reply-To: Your message of Mon, 05 Nov 90 19:39:36 -0500. <9011060039.AA05034@cise.cise.nsf.gov> Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Mon, 05 Nov 90 23:47:22 -0800 Message-Id: <10510.657877642@nma.com> Sender: stef@nma.com Thanks Steve for clarifying the status of the NREN name. My proposal is not meant for instant adoption, but rather with consideration to be given to the status of the NREN name, or any other name that might be used in the proposed way. I do recall that one of the reasons for registering (and service marking) NREN was to use it as a Management Domain Name (X.400 ADMD or PRMD) so I figure that its use in this manner is still under consideration. I do not see any clear way to act on this until after the Sturdy Group D MHSMD situation has been resolved, which will hopefully become clearer at our Dec 17-18 meeting. Unfortunately, we might be faced with educating a large number of new players in the game who have not been thinking their way through the naming and addressing maze over the last 5 years. Best...\Stef PS: I forgot to include a bit of explanation on the MHSMD Construction Syntax that I mentioned in my previous message. I will find the actual NIST OIW MHSIG text and send it out to these lists. Best...\Stef From huitema@jerry.inria.fr Wed Nov 7 03:16:31 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 7 Nov 90 03:16:31 -0600 Received: from jerry.inria.fr by cs.wisc.edu; Wed, 7 Nov 90 03:15:45 -0600 Received: by jerry.inria.fr (5.61+++/IDA-1.2.8) id AA15099; Wed, 7 Nov 90 10:16:45 +0100 Message-Id: <9011070916.AA15099@jerry.inria.fr> To: Steve Kille Cc: Alf Hansen , "rare-wg1" , pp-people , "ietf-osi-x400" , rd-mhs-managers Subject: Re: RFC 987 Procedures. In-Reply-To: Your message of 06 Nov 90 20:22:52 +0100. <2036.657913001@UK.AC.UCL.CS> Date: Wed, 07 Nov 90 10:16:37 +0100 From: Christian Huitema To second Steve, I agree that using SA or using DDA does not make much difference. However, I insist that in whatever case the information carried in the standard attributes "PRMD", "ADMD" and "C" should be sufficient to perform "sensible" routing, i.e. one should be able to route towards the "nearest" (cost wise) gateway based on that information. The current "national" mappings meet to some extent this criteria, in so far that I can adapt my routing tables to route the mail bound to "PRMD=BITNET; ADMD=DBP; C=DE" through the French X400-to-BITNET gateway. However this can only be done with a high administrative cost; also, as Steve pointed out, some of the national mappings define "pseudo ORNAME" with fictitious ADMD names or unconnected PRMD names, which cannot be replied to from a public ADMD. The current "DDA" practice does not meet this criteria when the PRMD is just "that of the gateway". I have absolutely no reason not to route "DDA=whatever; O=UCL; PRMD=UK.AC; C=UK" through the same MTA than "S=Kille; O=UCL; PRMD=UK.AC; C=UK"; in fact, I may perhaps take the liberty to rewrite the address in the UA when issuing a reply because I have an understanding of the "DD.RFC822" attribute -- but a public ADMD would never do that. However, the DDA practice guarantees that ADMD users located in the same country can reply to the address. (DDA capability is present in many softwares, including ours; The proposition issued by Rob boils down to setting up a special PRMD, "RFC-822.US", which can be accessed through any gateway to "the INTERNET". This would indeed meet the criteria mentionned above, as we could set up the routing table accordingly; we could also reach agreements with public ADMDs so that they understand how to route through our gateways -- although the agreement would be easier to reach if we had considered "RFC-822.US" as an ADMD rather that a PRMD. The choice of using DDAs or standard attributes in that PRMD is mostly esthaetic. However, one should take steps to ensure that the "RFC-822" PRMD is NOT used when a regular mapping as been defined, and in particular is not used for accessing regular X.400 users. I suggest that if this notation is introduced, it is done as a replacement of current "nationally defined" mappings in the mapping tables for a limited set of "top domains", rather than as a modification of the RFC-1048 to introduce a default mapping. Christian Huitema PS. DDA capability is present in many softwares, including ours. Conformance to the CEN-CENELEC and NIST profiles does not require the capability to generate or interpret these attributes; it does however requires a capacity to "copy" all attributes, including those not supported by the local implementation, if they are present in an OR-Name when a message is relayed or when a report is issued. I dont know whether this particular service is tested by the current conformance test suites; in fact, I doubt it. Could somebody related to the OSTC clarify the point? From stef@nma.com Wed Nov 7 08:59:19 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 7 Nov 90 08:59:19 -0600 Received: from nrtc.northrop.com by cs.wisc.edu; Wed, 7 Nov 90 08:59:09 -0600 Received: from nma.com by nrtc.nrtc.northrop.com id aa24762; 7 Nov 90 6:57 PST Received: from localhost by nma.com id aa11712; 6 Nov 90 20:38 PST To: Steve Kille Cc: Alf Hansen , rare-wg1 , pp-people , ietf-osi-x400 , rd-mhs-managers Subject: Re: RFC 987 Procedures. In-Reply-To: Your message of Tue, 06 Nov 90 17:36:41 +0000. <2036.657913001@UK.AC.UCL.CS> Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Tue, 06 Nov 90 20:38:15 -0800 Message-Id: <11709.657952695@nma.com> Sender: stef@nma.com Hi Steve -- May I be so bold as to ask which implementation is deficient and is causing the push for SA mapping to Internet DNS names? I am deficient in knowledge of this situation. My summation on all this is that until the US can in fact determine what PRMD names and ADMD names (possibly blank) should be used for INTERNET addresses, that we should avoid use of anything in the interim. Various US ADMDs have made formal connection arrangement with the INTERNET, but only for trransfer to/from SMTP via gateways. We ahve no agreements that I know of regarding what X.400 names we might or might not use. It is a fine position to take (to wait for national decisions) as I see it, since it avoids becoming locked into yet another historical thing to grandfather when we finally do resolve the naming issues. I would commend this position to others in other countries as well, where national decisions have not yet been taken. But, the US is about to embark on taking national decisions on these matters. It would be very helpful if we could have some contributions from the internet community with regard to what the internet community wants to be arranged. We are going to have to consider all sorts of existing practices, and try to grandfather them all, out of simple fairness, so I think it is correct to get the US internet position on paper and place it before the new Study Group D MHSMD Subcommittee. Do we want to grandfather EDU, COM, GOV, MIL, NET, adn ORG as US PRMD Names? It is perfectly reasonable to ask for this, though I do npot know what opposition it might encounter. Perhaps none, if it does not impact the goals and objectives of anyone else. Per Alf's comment that my proposal was opening the wrong question, I suspect he is correct, though it was not my intent. According to the set of summations so far in this discussion, it is not a good idea to solve the first problem (what to do while waiting for a national decision) without first having a national decision. This leaves us with using the DD.RFC-822 mechanism until we have a US national decision. With some luck, we might have one in 6 months. Is that too long to wait? I do not think it is. Onward...\Stef From Alf.Hansen@pilot.cs.wisc.edu Wed Nov 7 12:49:32 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 7 Nov 90 12:49:32 -0600 Received: from nac.no by cs.wisc.edu; Wed, 7 Nov 90 12:46:39 -0600 Received: from localhost by nac.no (5.64+IDA/Babel-1.6/6.0) with SMTP id AAnac17042; Wed, 7 Nov 1990 19:46:11 +0100 Received: from /PRMD=xnren/ADMD=_/C=us/ by nac.no with X.400 id ; Wed, 7 Nov 1990 12:43:28 -0500 Date: Wed, 7 Nov 1990 12:43:28 -0500 From: Alf Hansen Message-Id: <901107124326*Alf.Hansen@pilot.cs.wisc.edu> To: , Cc: Subject: DDAs in the R&D MHS Service. Dear Colleague, I have tried to explain below what I think is urgent to discuss in order to continue a smooth operation of the R&D MHS Service. Introduction ------------ During the last few years, the RARE WG1 and the R&D MHS Managers has agreed to certain operational procedures regarding address mapping between RFC 822 and X.400. The following is a summary of some conflict areas that should be focused in order to continue the operation of a stable gateway service. A major basic user requirement. ------------------------------- A user in the R&D MHS Service should always be able to take a "group reply" to a received message without modification of any of the addresses, regardless of whether the message was origionated in the RFC-822 world or in the R&D MHS world. This basic requirement is valid for addresses under registered top level domains (edu, gov etc + country codes). The requirement is not valid for unregistered top level domains (like earn, uucp, uninett etc). There may also be some exeptions if the address contains source routing with % signs or bang notation (!). Group replies should always work in the R&D MHS Service when replying for legally registered addresses in the X.400 address space or in the RFC-822 address space. The need for a definition of RFC-822 to X.400 mapping. ------------------------------------------------------ If a country X does not define the mapping from RFC-822 to X.400, this means that the mapping using DD.RFC-822 as defined in RFC 987 should apply. The NIST and CEN-CENELEC functional standards do not require DDA- handling. This fact, and the user inconvenience with DDAs (X.400 users have to do source routing via a gateway), has lead to the following: - Other countries define their own mapping of the address space in country X, under their own country code, according to the agreed procedures described in [Grimm: Minimum Profile....(rev)]. The following is just an example. Consider the fact that there is no unique mapping defined from RFC-822 to X.400, for the top level domain edu. This leads to the following: When the international mapping tables are distributed, each national manager has to add a local mapping for .edu, i.e., in Norway they add edu#PRMD$edu.ADMD$ .C=no# In other countries they add similar entries for edu under the local country code. Consider the two alteratives: 1) Other countries define their own mapping of the address space in country X, under their own country code, according to the agreed procedures described in [Grimm: Minimum Profile....(rev)]. 2) Mapping is performed using DD.RFC-822 as described in RFC-987. Seen from a user's point of view the RFC-822 address lhl@cs.wisc.edu would seen from X.400 in Norway look like 1) C=no; ADMD= ; PRMD=edu; O=wisc; OU=cs; PN=lhl; 2) C=no; ADMD= ; PRMD=uninett; DD.RFC-822=lhl(a)cs.wisc.edu; Users in other countries will represent the address different than users in Norway in both cases. Thus it is not possible for the owner of the RFC-822 address to publish a unique X.400 representation of his address. If country X had defined the RFC-822 to X.400 mapping for its RFC-822 address space, the situation would have been different. Again, just as an example, say that the Internet Management in the US defines the following mapping for edu: edu#PRMD$RFC-822.ADMD= .C=us# This unique mapping definition would then have been included in the international mapping tables, and no additional manual action from the national managers is needed. Seen from a user's point of view the same RFC-822 address lhl@cs.wisc.edu would, seen from X.400 in any country, look like C=us; ADMD= ; PRMD=RFC-822; O=edu; OU=wisc; OU=cs; PN=lhl; which is not perfect either, but the big advantage is that the RFC-822 users can publish a unique X.400 representation of their RFC-822 addresses. So: The basic idea with the current R&D MHS Procedures is that: A. A user in either world (X.400 or RFC-822) should be able to present his E-mail address in two and only two forms: The X.400 form and the RFC-822 form. Each form is globally unique in its address space. B. By using either of the two forms, the message will reach its destination regardless of where it is sent from, as long as it is sent from the X.400 world or the RFC-822 world. C. The group reply function will allways work, also for third party traffic. Decision on DDAs on the R&D MHS Service. ---------------------------------------- Some countries in the R&D MHS Service are not able to handle DDAs. This means that X.400 messages with DDAs arriving at gateways in these countries, will be refused. Some countries insist in using DDAs outside their own "domain". We have to make up our minds regarding DDAs in the R&D MHS Service. I do not see that we can get around this without making one of the following decisions: A. All R&D MHS Participants must be able to handle DDAs as described in RFC 987. or B. In the R&D MHS Service, DDAs should not be seen outside the local national "domain". (The wording could be better, but something along these lines). I hope we can have a fruitful discussion and finally reach an agreement. If we do not make a decision, X.400 users in the R&D MHS Service will lose connectivity. Best regards, Alf H. From Alf.Hansen@pilot.cs.wisc.edu Wed Nov 7 15:14:17 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 7 Nov 90 15:14:17 -0600 Received: from nac.no by cs.wisc.edu; Wed, 7 Nov 90 15:14:03 -0600 Received: from localhost by nac.no (5.64+IDA/Babel-1.6/6.0) with SMTP id AAnac26930; Wed, 7 Nov 1990 22:13:54 +0100 Received: from /PRMD=uninett/ADMD=_/C=no/ by nac.no with X.400 id ; Wed, 7 Nov 1990 22:13:53 +0100 Received: by /PRMD=xnren/ADMD=_/C=us/; Wed, 7 Nov 1990 15:13:01 -0500 Date: Wed, 7 Nov 1990 15:13:01 -0500 From: Alf Hansen Message-Id: <901107151258*Alf.Hansen@pilot.cs.wisc.edu> To: Subject: A Minimum Profile for RFC-987: Mapping between addresses in RFC-822 format and X.400 Standard Attributes. Hi, In my last message I referenced a document in this way: [Grimm: Minimum Profile....(rev)]. This documenmt is 22 pages long and I am enclosing the introduction and abstract for your information. If you want the whole paper, I will be glad to E-mail it to you. I think this ducument is useful as a background for the RFC-822 <--> X.400 address mapping discussions going on. Best regards, Alf H ==================================================================== #H DOC=PROCEDURES/MIN-RFC987-PROFILE; RES=RARE MHS Project Team; DAT=90.07.29; # Responsible: RARE MHS Project Team # MHS-Project-Team@rare.no # C=NO;PRMD=uninett;O=rare;S=MHS-Project-Team; ---------------------------------------------------------------- A Minimum Profile for RFC-987: Mapping between addresses in RFC-822 format and X.400 Standard Attributes ===== Ruediger Grimm, GMD Darmstadt, 87-07-31 (obsolete) Darmstadt, 87-09-22 (obsolete) Darmstadt, 87-11-27 Updated by Steinar Haug, RARE MHS Project Team, 90.07.29 (Because local mappings should be excluded from the international RFC822 -> X.400 mapping table) ================================================================ --------- --------- ! -------------------------> ! ! X.400 ! (1) ! ! ! ! ! ! --------- --------- ! ! ! ! ! ! (2) ! RFC-822 ! ! <------------------------- ! --------- --------- (0) What it is about Scope of this Paper, Abstract, Restrictions (1) Mapping (1) from X.400 to RFC-822 (2) Mapping (2) from RFC-822 to X.400 (3) Note: Conversion of Representations (4) Note: Lack of Uniqueness and Full Service (5) RFC-822 Addresses (6) X.400 Standard Attributes (7) The Default Mapping Default Mapping (1) and (2), Local-Part and PersonalName (8) Default Mapping Controlled by Exceptions (9) The RFC-987 Conversion Tables (10) General Rules for Specification (11) Syntax Rules for Specification Strong Syntax, Original RFC-987 Syntax (12) Matching Rules and Address Transformation (13) Distribution of RFC-987 Conversion Tables in RARE (14) RFC-987 Conversion Tables (Short Version) (15) A Long Version of an RFC-987 Conversion Table (0): WHAT IT IS ABOUT Scope of this Paper This paper is a RARE-WG1-document (working group 1 on November 26, 1987). This paper tries to explain in simple words and examples one essential part of RFC-987. It describes the transformation of addresses, whereby only those X.400 attributes are considered which are marked other than "unsupported", by the international profiles CEN/CENELEC, CEPT or NBS. One aim of this paper is to help people to understand and learn this part of RFC-987. The other aim is to describe this part of RFC-987 address transformation as a functioning subset of a full RFC-987 implementation. A gateway at the level of this subset will cooperate with gateways at full RFC-987 without distortion of addresses. Addresses that are transformed by a gateway at the level of this subset will be transformed and retransformed in the same way by a gateway at any level between this subset and full RFC-987. Therefore, this paper describes a minimum profile of RFC-987, by recommending to implementors in RARE community: "Do not implement less than the level of this subset". There are three reasons for the choice of this subset: One reason is the belief, that this subset covers all but pathological cases. The other reason is that MHS products which keep to the lowest level of the international MHS profiles would not be able to use more than this subset at a gateway. Finally, a third reason is that this subset deals with the very part of RFC-987 that definitely needs international cooperation, namely the use of the RFC-987 Conversion Tables. Abstract: This paper describes transformations of mail addresses from X.400-ORName representation into RFC-822 representation and vice versa. Mail systems considered here would belong to one of these two address worlds. The transformations are described by two mappings. Mapping (1) transforms X.400 originated addresses into an RFC-822 representation. Mapping (1)-inverse will retransform X.400 originated addresses from their RFC-822 representation back into their original form. Mapping (2) transforms RFC-822 originated addresses into an X.400 representation. Mapping (2)-inverse will retransform RFC-822 originated addresses from their X.400 representation back into their original form of RFC-822 representation. Mapping (1) and Mapping (2)-inverse, although applied to addresses of different origin, will comply to the same rules. Also Mapping (2) and Mapping (1)-inverse will follow the same rules. The discussion about such transformations is based on the RFC-987 paper written by Steve Kille. RFC-987 solves the full bandwidth of problems which arise from protocol converting from RFC-822 to X.400, and vice versa. It also considers all theoretical cases of address forms in either address world. Inside RARE the discussion has been fruitfully influenced by experiences with the first implementations of RFC-822-X.400 gateways. During the RARE EUROPEAN NETWORKSHOP in Valencia 1987 some essential decisions were made: Mapping (1) and (2), as they will be described in this paper, must be accepted by all gateways in the world which wish to cooperate. Otherwise, different gateways would create different address representations from the same original address. This would lead to the nasty fact that users would have to learn as many address representations of the same original address as there are different mappings used. A certain form of "gateway addressing" is not avoidable: As an example, SurName=Peter; OrgUnit=SEISMO; OrgName=CSS; PrivateDomainName=GOV; AdminDomainName=DBP; CountryName=DE is the X.400 representation of the RFC-822 address peter@seismo.css.gov after transformation under mapping (2). While the addressed mailbox is in the U.S., the Country Name DE and the Management Domains DBP and GOV direct to the gateway sited in Germany, which relays between the X.400 address world and ARPA mail systems. It must be mentioned that this type of address can only be considered as temporary. Whenever the U.S. run their own RFC-987 gateways, THEIR addresses in both address worlds will be used for transformation. Users will address the national gateways of the target countries, and then the example above will probably be mapped onto something like SurName=Peter; OrgUnit=SEISMO; OrgName=CSS; PrivateDomainName=GOV; AdminDomainName=ATT; CountryName=US In general, some parts of a transformed address will carry elements of the gateway involved. This is because RFC-822 addresses consist of domains and subdomains which do not represent X.400-Country Codes or X.400-Management Domains. However, Country Codes and Management Domains cannot be filled by arbitrary strings but must represent real countries and real Management Domains in their countries. Therefore, Country Codes, Administration and Private Domain Names will belong to the gateway involved. The elements of the RFC-822 addresses will then be distributed among OrgName, OrgUnits and Surname of X.400 address representation. In Valencia it was also generally agreed that only X.400 Standard Attributes will be supported by the Mapping (1) and (2); in particular Domain Defined Attributes will not be supported by the gateways under the agreed rules of RARE. Domain Defined Attributes are not supported by the CEN/CENELEC, CEPT or NBS profile either. It is felt sufficient to agree on elements which are supported by the international standard organizations. Of course, single gateways are free to implement transformations with Domain Defined Attributes. However, these transformations will remain unsupported by other gateways. Restrictions: A gateway at the level of this subset will not be able to convert addresses of the following type in the same way as gateways at the level of full RFC-987 do: X.400 addresses which use DomainDefinedAttributes significantly for the purpose of conversion. RFC-822 addresses which use the "Basic Representation" of RFC-987 (4.1.1) in the local-part. What will happen at a subset gateway, when addresses of this type arrive? Where a from- or to-address is concerned, the gateway will refuse the message and inform the sender, if the sender address is interpretable. Where only CC-addresses are concerned, the gateway will accept the message and perform the conversion at these addresses as far as possible. Such a conversion would remain incomplete and leave the receiver with only limited information about the CC-addresses. This restriction is in fact not a restriction of this subset but of the international profiles themselves. A central node (like a gateway) must not demand more from the other installations than they can give, otherwise the central service will partly isolate its users. This is a strong hint for RARE to make the use of DomainDefinedAttributes never become a normal case. This is also a strong hint for all installations - if RARE or not - to leave not-generatable attributes insignificant for the addressing of their local site, otherwise they will be partly isolated themselves. Therefore, this restriction is neglectable, if only pathological cases are concerned. From stef@nma.com Thu Nov 8 00:15:38 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Thu, 8 Nov 90 00:15:38 -0600 Received: from nrtc.northrop.com by cs.wisc.edu; Thu, 8 Nov 90 00:15:25 -0600 Received: from nma.com by nrtc.nrtc.northrop.com id aa28586; 7 Nov 90 22:14 PST Received: from localhost by nma.com id aa01101; 7 Nov 90 21:36 PST To: Alf Hansen Cc: rare-wg1@switch.ch, ietf-osi-x400, rd-mhs-managers@rare.no Subject: Re: DDAs in the R&D MHS Service. In-Reply-To: Your message of Wed, 07 Nov 90 12:43:28 -0500. <901107124326*Alf.Hansen@pilot.cs.wisc.edu> Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Wed, 07 Nov 90 21:35:36 -0800 Message-Id: <1094.658042536@nma.com> Sender: stef@nma.com Teh introduction is certainly interesting and helpful in sorting out the issues, and I am disappointed that my predictions (issued at the NBS(NIST) in 1986-87) are coming to pass, where-in the lack of support for DDAs in the profiles is now causing widespread problems with the quality of service across the X.400 network. 1. Is it still an RD-MHS policy to depricate use of the DDA. 2. Is it possible to make a contribution to the profile generators (OIW, EWOS, AOS) that expalins the nature of the problem and proposing to adopt support for the DDA after all? Best...\Stef From stef@nma.com Thu Nov 8 11:44:58 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Thu, 8 Nov 90 11:44:58 -0600 Received: from nrtc.northrop.com by cs.wisc.edu; Thu, 8 Nov 90 11:44:46 -0600 Received: from nma.com by nrtc.nrtc.northrop.com id aa00749; 8 Nov 90 9:43 PST Received: from localhost by nma.com id aa01761; 8 Nov 90 9:13 PST Received: from nrtc.northrop.com by nma.com id aa01398; 8 Nov 90 1:35 PST Received: from janeb.cs.wisc.edu by nrtc.nrtc.northrop.com id aa29127; 8 Nov 90 1:13 PST Date: Thu, 8 Nov 90 01:05:02 -0600 From: Mail Delivery Subsystem Subject: Returned mail: Deferred: Bad file number Message-Id: <9011080705.AA11828@janeb.cs.wisc.edu> Received: by janeb.cs.wisc.edu; Thu, 8 Nov 90 01:05:02 -0600 To: stef@nma.com Mmdf-Warning: Parse error in original version of preceding line at nma.com To: hagens Resent-To: ietf-osi-x400 Resent-Date: Thu, 08 Nov 90 09:13:13 -0800 Resent-Message-Id: <1757.658084393@nma.com> Resent-From: Einar Stefferud ----- Transcript of session follows ----- 451 timeout waiting for input 451 hanks@twg.com,edward@twg.com... reply: Read error during MAIL wait 421 wnyosi2.nardac-dc.navy.mil.tcp... Deferred: Connection timed out during user open with wnyosi2.nardac-dc.navy.mil 421 gateway.mitre.org.tcp... Deferred: Connection refused by gateway.mitre.org 421 p3.amf.wpafb.af.mil.tcp... Deferred: Address family not supported by protocol family 550 DayJD@P3.AMF.WPAFB.AF.MIL... Host unknown: Address family not supported by protocol family 451 kellen@eglin.af.mil... reply: Read error during greeting wait ----- Unsent message follows ----- Received: from cs.wisc.edu by janeb.cs.wisc.edu; Thu, 8 Nov 90 00:15:38 -0600 Received: from nrtc.northrop.com by cs.wisc.edu; Thu, 8 Nov 90 00:15:25 -0600 Received: from nma.com by nrtc.nrtc.northrop.com id aa28586; 7 Nov 90 22:14 PST Received: from localhost by nma.com id aa01101; 7 Nov 90 21:36 PST To: Alf Hansen Cc: rare-wg1@switch.ch, ietf-osi-x400, rd-mhs-managers@rare.no Subject: Re: DDAs in the R&D MHS Service. In-Reply-To: Your message of Wed, 07 Nov 90 12:43:28 -0500. <901107124326*Alf.Hansen@pilot.cs.wisc.edu> Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Wed, 07 Nov 90 21:35:36 -0800 Message-Id: <1094.658042536@nma.com> Sender: stef@nma.com Teh introduction is certainly interesting and helpful in sorting out the issues, and I am disappointed that my predictions (issued at the NBS(NIST) in 1986-87) are coming to pass, where-in the lack of support for DDAs in the profiles is now causing widespread problems with the quality of service across the X.400 network. 1. Is it still an RD-MHS policy to depricate use of the DDA. 2. Is it possible to make a contribution to the profile generators (OIW, EWOS, AOS) that expalins the nature of the problem and proposing to adopt support for the DDA after all? Best...\Stef From hagens Thu Nov 8 19:05:39 1990 Message-Id: <9011090105.AA13880@janeb.cs.wisc.edu> Received: from localhost by janeb.cs.wisc.edu; Thu, 8 Nov 90 19:05:39 -0600 To: rare-wg1@switch.ch, pp-people@cs.ucl.ac.uk, ietf-osi-x400, rd-mhs-managers@rare.no Subject: Re: RFC 987 Procedures Date: Thu, 08 Nov 90 19:05:30 CST From: hagens I would like to briefly followup on a number of issues that have been raised. 1) When X.400 is deployed in the Internet, I think that standard attribute addresses that are meaningful to the organizations involved should be used. I see this as having at least two criteria: the /ORG/ attribute ought to be meaningful, and the /PRMD/ attribute ought to imply a reasonable service boundary. It is not clear that PRMDs with {com, net, gov, etc} in the name meet both critera. 2) The suggestion to define /PRMD=RFC-822/ is NOT intended to be a suggestion on how X.400 addresses should be structured in the US. It is intended as an alternative to the DD=RFC-822 for X.400 users who need to enter an RFC 822 address. 3) It seems to me that we need a consistent way for X.400 users to enter RFC-822 addresses. 4) The DD=RFC-822 approach has a number of benefits. It is a simple solution. However, it suffers from the fact that users must source route their messages to the gateway. The fact that users dislike source routing has lead to the nationally defined mappings which has lead to confusion (see item 3, above). A related disadvantage is that an X.400 management domain can't utilize any information within the DDA to make a smart routing decision towards an exit (987) gateway. Of course, it is possible to construct smart user agents that figure this all out. If this is acceptable to the community, fine. 5) The PRMD=RFC-822 approach has one assumption. Every ADMD/PRMD must agree to route any mail with the "RFC-822" PRMD field to an RFC 987 gateway. I don't understand why this is so difficult. All we have to do is get one ADMD to do this, and the rest will follow. 6) The PRMD=RFC-822 has three advantages that I can think of: a) The user does not need to source route to gateway. b) X.400 management domains can utilize information in the RFC 822 address (since it is now located in standard attributes) to route to more than one RFC 987 gateway. This routing decision is completely hidden from the user (which is good). c) Reply paths can be optimized (due to the fact that a reply is not source routed through the original gateway). Let me know if an example would help here... I look forward to continuing this discussion (and others) at the next IETF-X.400 WG meeting in Boulder. I plan to have a more refined version of the proposal incorporating the comments from all of you. Rob From vcerf@NRI.Reston.VA.US Fri Nov 9 05:04:45 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Fri, 9 Nov 90 05:04:45 -0600 Received: from NRI.RESTON.VA.US by cs.wisc.edu; Fri, 9 Nov 90 05:04:38 -0600 Received: from nri by NRI.NRI.Reston.VA.US id aa02138; 9 Nov 90 6:02 EST To: hagens Cc: rare-wg1@switch.ch, pp-people@cs.ucl.ac.uk, ietf-osi-x400, rd-mhs-managers@rare.no Subject: Re: RFC 987 Procedures In-Reply-To: Your message of Thu, 08 Nov 90 19:05:30 -0600. <9011090105.AA13880@janeb.cs.wisc.edu> Date: Fri, 09 Nov 90 06:02:03 -0500 From: vcerf@NRI.Reston.VA.US Message-Id: <9011090602.aa02138@NRI.NRI.Reston.VA.US> Rob, gee, what if we revise the RFC822 - then we would have to change the PRMD name.... (half-kidding, but tempted to suggest a PRMD string which would not be affected...). Vint From kaufmann@zpl.dfn.dbp.de Fri Nov 9 08:27:02 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Fri, 9 Nov 90 08:27:02 -0600 Received: from chx400.switch.ch by cs.wisc.edu; Fri, 9 Nov 90 08:26:52 -0600 Received: by chx400.switch.ch (5.61/Ultrix2.4-C) id AA08760; Fri, 9 Nov 90 15:26:59 +0100 From: kaufmann@zpl.dfn.dbp.de Date: 9 Nov 90 14:13 To: RARE-WG1@SWITCH.ch, ietf-osi-x400 , rd-mhs-managers Message-Id: <901109151258*> Subject: Use of SA/DDA I believe that the use of DDAs should still be limited as much as possible within X.400 addresses. Several reasons I see: 1) DDAs are not mandatory within certain profiles. This may lead to difficulties for some X400-users. One has to take into account this situation. -> a small pro for SAs 2) Both representations of RFC-addresses with DDAs and with SAs provide a gateway address using the upper attributes of the SA-address. Example: C=de; ADMD=dbp; PRMD=edu; O=wisv; S=name C=de; ADMD=dbp; PRMD=gateway; DDA=name@wisc.edu; The reply procedure leads in both ways to the same gateway (if properly fixed by the national MHS managers). Thus, no difference for the reply problem (point 1 from Steve). -> SA = DDA 3) There are "pathological" addresses which certainly must put into DDAs. If users cannot handle such addresses its bad luck and maybe a reason for owners of such addresses to put pressure to the right people for change ... -> a small pro for DDAs (for certain cases) 4) The BIG item is the user. One of the most ugly problem within the MHS area is the addressing problem. Users have BIG difficulties to understand all the necessary stuff. Within DFN we are using X400 for several years and with many users and we are really confronted with the problem of using ATTRIBUTES instead of BYTE STREAMS - and in DFN we are using often (not always) the attributes also on the user interface. With such experience it is really much better to reduce the number of attributes to the usual SAs which have all a similar "quality" instead of using DDAs which have an extra kind of quality and which have no advantage: the user needs in both ways a special rule to put an RFC822 address into X400 attributes. -> a big pro for SAs 5) I believe that all of us want to push the use of SA instead of DDAs, even if we have no agreement on how to proceed on the way to this goal. My "feeling" is that the use of DDAs produces more inertia to keep old addresses unchanged than the use of gateway addresses with SAs. Also some people may complain to put e.g. country=XY in a gateway address with SAs below country=ab. Both much more psychological/political reasons may create additional stimuli to develop valid X400-addresses and to define valid mapping tables between RFC822/X400. -> maybe a small pro for SAs 6) Within Europe we have succeeded over the last years to introduce valid X400 addresses and mappings for almost all countries. Each time a country introduced such mapping we have reduced the number of gateway addresses. I am sure that in the (near) future a lot of other countries will introduce X400 address schemes and mapping, too. Thus, to change e.g. an address with EDU from the current presentation at an X400 interface to something with DDAs and then to have onother change one year later (lets say) looks not very sensible (please have in mind that some of you are sitting on the RFC side of the game and that we are discussing about possible changes and interruptions only for the service of the X400 side of the same game with real users). Thus, I believe it is better to keep the current situation and hope that the US collegues will have a solution for their domains in the near future. -> a big pro to keep the current mappings Altogether: lets reduce the proliferation of DDAs the possible minimum. I would support very much the P=rfc822 approach as mail exchange for the german community with US is important and this would make life easier. However, I understand that the side effects must be discussed carefully and that it seems to be more useful to wait some further months for a good/stable solution. Peter Kaufmann From stef@nma.com Sun Nov 11 14:07:47 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Sun, 11 Nov 90 14:07:47 -0600 Received: from NRTC.NORTHROP.COM by cs.wisc.edu; Sun, 11 Nov 90 14:07:14 -0600 Received: from nma.com by nrtc.nrtc.northrop.com id ad12649; 11 Nov 90 12:06 PST Received: from localhost by nma.com id aa02486; 10 Nov 90 12:31 PST To: vcerf@nri.reston.va.us Cc: hagens, rare-wg1@switch.ch, pp-people@cs.ucl.ac.uk, ietf-osi-x400, rd-mhs-managers@rare.no Subject: Re: /PRMD=RFC-822/ - was RFC 987 Procedures In-Reply-To: Your message of Fri, 09 Nov 90 06:02:03 -0500. <9011090602.aa02138@NRI.NRI.Reston.VA.US> Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Sat, 10 Nov 90 12:30:55 -0800 Message-Id: <2481.658269055@nma.com> Sender: stef@nma.com I agree about /PRMD=RFC-822/ being a poor choice of name. In particular, the hyphen will cause great confusion as people will often omit it (or insert it if we decide to use /PRMD=RFC822 with no hyphen). So, I suggest that a better name should be chosen...\Stef From stef@nma.com Sun Nov 11 14:05:58 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Sun, 11 Nov 90 14:05:58 -0600 Received: from NRTC.NORTHROP.COM by cs.wisc.edu; Sun, 11 Nov 90 14:05:42 -0600 Received: from nma.com by nrtc.nrtc.northrop.com id aa12649; 11 Nov 90 12:04 PST Received: from localhost by nma.com id aa02418; 10 Nov 90 12:19 PST To: hagens Cc: rare-wg1@switch.ch, pp-people@cs.ucl.ac.uk, ietf-osi-x400, rd-mhs-managers@rare.no Subject: PRMD=RFC-822 -- was: RFC 987 Procedures In-Reply-To: Your message of Fri, 09 Nov 90 02:53:53 +0100. <9011090105.AA13880@janeb.cs.wisc.edu> Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Sat, 10 Nov 90 12:18:54 -0800 Message-Id: <2414.658268334@nma.com> Sender: stef@nma.com I see some issues that are not being explored, but need to be explored fully before people get locked into liking or disliking the idea. 1. Just how do we get any or all ADMDs in the US (or elsewhere in the world if need be) to honor (not-reject, route-on) /c=US/ADMD= /PRMD=RFC-822/. It is not a simple matter of getting one ADMD to do it, with the others falling in line automatically. /PRMD=RFC822/ will have to be directly registered with every current operating ADMD, or at least all that are connected to the INTERNET for X.400 transfers. (None are so connected at this time.) All INTERNET<=>ADMD connections are now between RFC-822 and old proprietary ADMD formats and protocols, with the possible exception of SPRINT and ATT FTS2000 systems. FTS2000 is a US Government Services Administration "private" system, and will not provide general relay services between the ADMDs and the INTERNET. As I see it, it is premature to expect this issue to be resolved before the new US Study-Group-D MHSMD Subcommittee develops an acceptable plan for naming of MHS Management Domains in /c=US/. Therefore, it is not sensible to say that "all we need to do is get one /c=US/ ADMD to agree and the problem is solved!" 2. How will /PRMD=RFC-822/ really work? 2.1. Does it put the entire burden of gatewaying all X.400<=>RFC-822 mail via /c=US/ ADMD attached gateways? 2.2. Are RD-MHS weps going to route mail addressed to /c=US/ADMD=ATT/PRMD=RFC-822/... to a local RFC987 gateway for local injection into the INTERNET, and thus bypass (or ignore) /ADMD=ATT/? In short, what are we really talking about doing here? My Summary at this point: I don't see how to proceed with anything until the US makes its decision on how MHS MD naming is going to be done in the US. After that, we should expect US MHS MDs to adopt names and subordinate naming schemes and provide RFC987 mappings as needed for their INTERNET DNS domains. I am open to further discussion, but I would like to see it focused on just what is really being proposed and how it will work. Best...\Stef From @twg.com:david@twg.com Mon Nov 12 11:35:13 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Mon, 12 Nov 90 11:35:13 -0600 Received: from TWG.COM by cs.wisc.edu; Mon, 12 Nov 90 11:33:59 -0600 Received: from Obelix.twg.com by twg.com with SMTP ; Mon, 12 Nov 90 09:31:08 PST Received: from obelix.twg.com by Obelix.TWG.COM id aa09508; 12 Nov 90 9:29 PST To: Stef@ics.uci.edu Cc: vcerf@nri.reston.va.us, hagens, rare-wg1@switch.ch, pp-people@cs.ucl.ac.uk, ietf-osi-x400, rd-mhs-managers@rare.no, david@TWG.COM Subject: Re: /PRMD=RFC-822/ - was RFC 987 Procedures In-Reply-To: Your message of Sat, 10 Nov 90 12:30:55 -0800. <2481.658269055@nma.com> Date: Mon, 12 Nov 90 09:29:47 -0800 From: David Herron Message-Id: <9011120929.aa09508@Obelix.TWG.COM> > I agree about /PRMD=RFC-822/ being a poor choice of name. In > particular, the hyphen will cause great confusion as people will often > omit it (or insert it if we decide to use /PRMD=RFC822 with no hyphen). I have another objection to the name -- since RFC-822 is a protocol, and not a naming hierarchy, then it is inappropriate to use it in this way. That is, what you're referring to with /PRMD=rfc{,-}822/ is the hierarchy of names stored in the Internet Domain Name System which is rooted at ns.nic.ddn.mil. There may well be, and probably are, other naming hierarchies which also use RFC-822 style protocols but which are not connected into this tree rooted at ns.nic.ddn.mil. Pick some other string of characters and things will be fine. And things are fairly `fine' anyway ... David From RAF@CU.NIH.GOV Mon Nov 12 13:38:18 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Mon, 12 Nov 90 13:38:18 -0600 Received: from alw.nih.gov by cs.wisc.edu; Mon, 12 Nov 90 13:38:09 -0600 Received: from cu.nih.gov by alw.nih.gov (5.61/alw-2.1) id AA12055; Mon, 12 Nov 90 14:33:22 -0500 Message-Id: <9011121933.AA12055@alw.nih.gov> To: david@TWG.COM, Stef@ics.uci.edu Cc: vcerf@nri.reston.va.us, hagens, rare-wg1@switch.ch, pp-people@cs.ucl.ac.uk, ietf-osi-x400, rd-mhs-managers@rare.no, david@TWG.COM From: "Roger Fajman" Date: Mon, 12 Nov 90 14:37:01 EST Subject: Re: /PRMD=RFC-822/ - was RFC 987 Procedures > I have another objection to the name -- since RFC-822 is a protocol, > and not a naming hierarchy, then it is inappropriate to use it in > this way. That is, what you're referring to with /PRMD=rfc{,-}822/ > is the hierarchy of names stored in the Internet Domain Name System > which is rooted at ns.nic.ddn.mil. There may well be, and probably > are, other naming hierarchies which also use RFC-822 style protocols > but which are not connected into this tree rooted at ns.nic.ddn.mil. That is certainly true of BITNET/EARN/NETNORTH/GULFNET. It uses RFC 822, but has its own name space. From Alf.Hansen@pilot.cs.wisc.edu Mon Nov 12 23:13:24 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Mon, 12 Nov 90 23:13:24 -0600 Received: from nac.no by cs.wisc.edu; Mon, 12 Nov 90 23:13:14 -0600 Received: from localhost by nac.no (5.64+IDA/Babel-1.6/6.0) with SMTP id AAnac29455; Tue, 13 Nov 1990 06:12:45 +0100 Received: from /PRMD=xnren/ADMD=_/C=us/ by nac.no with X.400 id ; Mon, 12 Nov 1990 23:11:21 -0500 Date: Mon, 12 Nov 1990 23:11:21 -0500 From: Alf Hansen Message-Id: <901112231118*Alf.Hansen@pilot.cs.wisc.edu> To: , , , , Subject: MHS discussions. ------------------------------------------------------------ Overview of available communication tools for MHS - discussions ------------------------------------------------------------ IETF-osi-x400: The IETF OSI X.400 working group is chartered to identify and provide solutions for problems encountered when introducing and operating X.400 in a dual protocol internet. The WG mailing list is an open list for discussions about X.400 in the Internet. Send articles to: ietf-osi-x400@cs.wisc.edu For list maintenance (add/delete/change), send messages to: ietf-osi-x400-request@cs.wisc.edu ------------------------------------------------------------------------ IFIP-Gtwy: The IFIP-Gtwy list is for the IFIP 6.5 Task Group on Gateways, which is concerned with gateways and interworking between X.400 and non-X.400 MHS environments and between 1984 and 1988 X.400 conformant systems. Participation is open to anyone with something to contribute. This list is also available via USENET as the moderated group comp.protocols.iso.x400.gateway. Mailing list messages and USENET group postings flow in both directions. USENET postings are subject to pre-screening. If your site gets a USENET feed, you may prefer to read the news group rather than become a member of the mailing list. For those with FTP access across the Internet, the archives are maintained on host ICS.UCI.EDU in directory internet/ifip-gtwy/; files can be accessed via ANONYMOUS FTP. Send articles to: ifip-gtwy@ics.uci.edu (or, on USENET, post to comp.protocols.iso.x400.gateway) For list maintenance (add/delete/change), send messages to: ifip-gtwy-request@ics.uci.edu ------------------------------------------------------------------------ MHSnews: The MHSnews list discusses different aspects of the CCITT X.400 (MHS) message handling protocols and gateways to these protocols. This list is also available on USENET as the moderated group comp.protocols.iso.x400. Mailing list messages and USENET group postings flow in both directions. USENET postings are subject to pre-screening. If your site gets a USENET feed, you may prefer to read the news group rather than become a member of the mailing list. For efficiency reasons, there are two halves to the MHSNews list that exchange messages: a "North American" half, and a "European" half. Contributors and subscribers to and MHSNews should use the net addresses nearest to them. For those with FTP access across the Internet, the archives are maintained on host ICS.UCI.EDU in directory internet/mhsnews/; files can be accessed via ANONYMOUS FTP. Contributions To MHSNews From Europe: mhsnews@uninett.no c=no; admd= ; prmd=uninett; o=uninett; s=mhsnews; Requests To Be Added/Deleted/Changed In The European Distribution List: mhsnews-request@uninett.no c=no; admd= ; prmd=uninett; o=uninett; s=mhsnews-request; Contributions To MHSNews From North America: mhsnews@ics.uci.edu (or, on USENET, post to comp.protocols.iso.x400) Requests To Be Added/Deleted/Changed In the North American Distribution List: mhsnews-request@ics.uci.edu ------------------------------------------------------------------------ RARE-WG1: This distribution-list is a forum for members of RARE WG1 (on MHS). One WG1 representative and one vice-representative should be nominated from each RARE-member body. If a wider distribution is wanted, each body is free to create and maintain local re-distribution lists. Countries and organizations in the process of establishing formal RARE membership may be represented in WG1 as "observers". In certain cases, experts are invited to participate in WG1 with the status of "invited experts". The RARE secretariat, CEC, iCPMU and the RARE MHS Project Team are also members. Send articles to: c=CH; admd=ARCOM; prmd=SWITCH; o=SWITCH; ou=VERW; s=RARE-WG1; RARE-WG1@verw.switch.ch To become a member: Contact your local RARE contact-person. Updates/Modifications should be sent to the chairman of WG1: c=CH; admd=ARCOM; prmd=SWITCH; o=SWITCH; ou=VERW; s=EPPENBERGER; eppenberger@verw.switch.ch ------------------------------------------------------------------------ RD-MHS-Managers: This distribution list is used by managers of national R&D MHS services to solve day-to-day problems in the operation of the global R&D MHS Service based on X.400, and its gateways to other mail services. Each R&D MHS management entity should have an address where the responsible persons can be reached, e.g. s=PRMD-manager;... This address should be the entry in the central list. Send articles to: c=no; admd= ; prmd=uninett; o=rare; s=RD-MHS-managers; RD-MHS-Managers@rare.no To Become A Member: Contact your local manager. New countries/management entities should contact: c=no; admd= ; prmd=uninett; o=rare; s=mhs-project-team; mhs-project-team@rare.no -------------------------------------------------------------------- AH/90.10.22/ -------------------------------------------------------------------- From lazear@gateway.mitre.org Wed Nov 14 09:27:12 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 14 Nov 90 09:27:12 -0600 Received: from gateway.mitre.org by cs.wisc.edu; Wed, 14 Nov 90 09:26:51 -0600 Return-Path: Received: by gateway.mitre.org (5.61/SMI-2.2) id AA22470; Wed, 14 Nov 90 10:25:10 -0500 Message-Id: <9011141525.AA22470@gateway.mitre.org> To: hagens, messing@gateway.mitre.org Cc: ietf-osi-or, AIKEN%OER.ESNET@esnmrg.nersc.gov, cargille, vcerf@nri.reston.va.us, dorman@dstl86.dnet.nasa.gov, rlfink@lbl.gov, dgale@nsf.gov, getchell@nersc.gov, epg@gateway.mitre.org, hansen, lhl, lazear@gateway.mitre.org, stef@nma.com, B32357@anlvm.ctd.anl.gov, yin@trident.arc.nasa.gov, callon@bigfut.enet.dec.com, pgross@nri.reston.va.us, rare-wg1@switch.ch, pp-people@cs.ucl.ac.uk, ietf-osi-x400, rd-mhs-managers@rare.no, gamma@mintaka.dca.mil, reichlen@gateway.mitre.org, gomberg@gateway.mitre.org Date: Wed, 14 Nov 90 10:08:38 -0500 From: lazear@gateway.mitre.org Subject: Naming Consistency Proposal -------- Rob (and others), This is the proposal Dave Gomberg and I mentioned on the phone the other day. It's a starting point for discussion about mapping in gateways vs. a consistent way for handling naming in mail systems. I think this has application to file transfer gateways, too, but the harder case is mail. I look forward to the ensuing discussion. Walt Lazear Internet: lazear@gateway.mitre.org FAX: 1-703/883-7142 Voice: 1-703/883-6515 [11/9/90 -- Since our mailer has delayed sending this, I also see that the topic is pertinent to recent discussions on the net about how to properly use the simple DD.RFC822 mechanism and to distinguish the various naming spaces (BITNET/EARN).... Walt] [11/14 -- mailer problem solved, sorry this is so late] ================================= cut here ================================ Note: The following is a proposal for a name handling scheme for application gateways that gives a consistent end-user view, scales well, and does not require the infrastructure of mapping tables in gateways. This proposal is offered as a strawman for open discussion. Comments should be directed to the author's (Internet) e-mail address: lazear@gateway.mitre.org This work was done under the sponsorship of the Defense Communications Agency. SECTION 1 INTRODUCTION The coexistence of Internet and OSI protocols required some mechanisms to allow interoperability between the two protocol suites, resulting in application-level, translating gateways covering electronic mail and file transfer. As these gateways were developed, implementors finessed (i.e., ignored) the problem of how a host running one protocol suite would discover it needed to use a gateway to interact with a host (running the other protocol suite). The selection of a gateway was also left to the end-user. A portion of the application's protocol was used to convey the real destination address through the connection made to the intermediate address. This rendezvous mechanism placed the burden of name resolution on the end user. Research and implementation efforts have sought to make the end-user less aware of the translation between protocol suites (see Kille RFCs 987, 1026, 1148, and Elvy RFC 915). This work has, in turn, created complex infrastructure mechanisms to support transparency. These efforts have limited usefulness and will create performance and end-user problems for the Defense Data Network, the Defense Message System, the Internet, and the OSI community. Further, they only address the interoperability of Internet and OSI, not the more general case of multiple suites and networks. They will complicate life for the user who moves from one application protocol to another (such as from an Internet connection at work to a USENET connection at home) and for the one who corresponds with people in many different mail systems. The material presented in this paper is not tutorial in nature. The reader is assumed to understand how name services function, how electronic mail is gathered and forwarded, how application level gateways operate, and how these activities are accomplished in both Internet and OSI terms. Background information can be found in Mockapetris' RFCs 1034, 1035, and Crocker's RFC 822, and MITRE/NIST's documentation of their FTP/FTAM gateways. The following sections present electronic mail scenarios, issue discussion, and recommendations for action. 1 1.1 TERMINOLOGY Before proceeding into examples of the two major approaches to name resolution in an electronic mail gateway, two terms must be defined. These terms will be used extensively in the ensuing discussions of the gateway approaches. Realm -- an application or protocol family that can be characterized by a name (e.g., G3FAX, X400, UUCP), a naming syntax (e.g., User@Host), and an interface gateway. A realm interfaces to other realms by using a translating gateway that interprets destination mail names and that maps mail services and message data between realms. Electronic mail realms, for example, might be X400, RFC822, XEROX400, MCIMAIL, and USENET. Bucket -- a realm-specific mechanism for passing uninterpreted (opaque) information. An X400 realm bucket, for example, might be a Domain Defined Attribute. An RFC 822 (Internet mail) realm bucket is a quoted string in the user portion of a mail name. 2 SECTION 2 GATEWAY APPROACHES 2.1 OVERVIEW The electronic mail gateway is in many ways a superset of other application gateways. Its approach to name resolution is applicable to the gateways for other, simpler protocols. The sections below present generic scenarios for name resolution within this kind of gateway. The names in question are those used to address individual users in different electronic mail realms. The main focus in the scenarios is the generality of each approach and how well it scales up in situations where several realms must interoperate. There are two extremes of name resolution philosophies. Either the meaning of foreign names is hidden (that is, kept private to a realm) or it is understood (through knowledge exported from a realm). The former philosophy requires no mapping of names between realms. The knowledge of name parsing and interpretation is kept inside the destination realm (like the postal service's use of zip-plus-four codes). A bucket is used to carry the foreign name within the source realm until the destination realm's gateway can interpret it. A gateway will be termed non-mapping if it implements this philosophy. The latter philosophy requires some database of mappings that must be maintained by the destination realm and imported by the source realm. Part of this support infrastructure is the cross-registration of one realm's users in the name service of another realm. A gateway will be termed mapping if it implements this philosophy. The sample scenarios have tried to minimize the use of specific mechanisms to perform functions. How an application queries a name service and what form the reply takes is immaterial to the concepts. How the user designates a realm name is implementation-specific and immaterial here. While the scenarios suggest that a program or user performs a lookup, in practice it does not matter which agent performs the action. 3 2.2 SIMILARITIES 2.2.1 Message Part Mapping Both approaches require the mapping of message parts from one realm's parts to the other realm's. This has to happen in any style of gateway. To ensure well-defined mappings of the message parts, some definition document should exist, such as RFC 987, for each pair of realms. 2.2.2 Gateway Cross-Registration Both approaches require the cross-registration of a realm's application gateway(s). Each realm must, in effect, execute a bilateral agreement with other realms it is willing to deal with. This agreement covers the names and locations of the gateways and may include policy issues related to the interaction of the realms. The gateway is the external interface for the realm. 2.3 SCENARIO DISCUSSIONS Table 1 shows the non-mapped and mapped scenarios. The subsections below discuss each numbered step of the scenarios. 2.3.1 Step 1. Cross-Register Information As discussed above in ``Similarities,'' the application gateways of each realm must be registered in the other realm's name service. In a mapping gateway approach, there is additional cross- registration that must take place. The knowledge of how to map one realm's names into the other's names must be installed in a gateway's mapping tables. The mechanism for maintaining these tables is not important for this discussion. Additionally, the recipient user or host system must be cross-registered so that the sender can use what appears to be a local name when composing a message. 2.3.2 Step 2. Determine Name and Realm As discussed above in ``Similarities,'' the sender must obtain the recipient's mail name from some source (business card, phone call, online source, offline documentation, or personal 4 Table 1. Gateway Approach Scenarios NON- STEP MAP MAP AGENT AND ACTION 1a. X X Destination realm cross-registers gateway in sender's name service 1b. X Destination realm cross-registers mapping tables 1c. X Recipient cross-registers in sender's name service 2. X X Sender determines recipient's mail name (including realm) 3. X X Sender composes and addresses message 4a. X Mailer uses name service to get recipient's cross-registered realm information 4b. X X Mailer uses realm name and name service to select destination realm gateway 5. X X Mailer routes message to destination realm gateway 6. X X Gateway converts message parts to destination realm format 7a. X Realm gateway uses mapping tables to translate sender-realm's mail name syntax 7b. X X Realm gateway forwards message using destination mail name syntax contact). This name may or may not have the realm associated with it. In the non-mapped approach, the user must also determine the realm of the recipient, to select the proper gateway later. In the mapped approach, the sender is unaware that different realms are involved. Cross-registration makes the use of another realm invisible to the user. 2.3.3 Step 3. Compose Message In both approaches, the sender composes the mail message body and addresses the message to the recipient. For the non-mapped approach, the mail name of the recipient is expressed in the recipient's syntax. This name must be transparently carried in a bucket until the gateway can act on it. The realm name must be entered with the recipient's mail name. 5 For the mapped approach, the recipient's mail name is expressed in the sender's syntax, since the recipient has cross-registered in the sender-realm's name service. 2.3.4 Step 4. Select Realm Gateway In the mapped approach, the sender is unaware of the actual destination realm, but the correct destination realm must be determined. The sender's name service is used to look up the recipient's real realm name in the recipient's cross- registration information. In both approaches, the real realm name is used to look up a cross-registered gateway for that realm. 2.3.5 Step 5. Route Message to Gateway The mail application routes the message to the realm gateway for translation and forwarding. 2.3.6 Step 6. Convert Message As discussed above in ``Similarities,'' the realm gateway converts the message parts according to rules agreed between realms. 2.3.7 Step 7. Forward Message As part of the process of normalizing a message for forwarding, the mapped approach uses local mapping tables and the recipient's name to translate the sender-realm's syntax into a recipient-realm's syntax. The non-mapped approach directly uses the information in the bucket. In both approaches, the realm gateway uses the recipient's name to forward the message to the recipient. 6 SECTION 3 ADVANTAGES AND DISADVANTAGES 3.1 CROSS-REGISTRATION The central advantage that the non-mapped approach has over the mapped approach is that there is no cross-registration of hosts or users. This is especially important when multiple realms are considered. There are no elaborate database maintenance schemes to keep cross-registration accurate. As the number of realms and the size of realms increases, this mapping database will grow exponentially. There are no large name-tree spaces to reserve for other realms' hosts and users. Cross-registration at the gateway level is all that is neccesary. There are no multiple-mailbox names for users to remember or advertise. A recipient is able to express a consistent mail address (i.e., name and realm) and all senders will be able to apply it directly. Cross-registration will never be a complete solution, since the entire population of one realm will not register in another realm. If one contemplates more than just a single pair of realms, the possibility of complete cross-registration becomes non-existent. There are always recipients who have not yet (or may never be) cross-registered, but with whom someone outside their realm wants to communicate. The generic approach of using the recipient's native syntax must always be available or only partial interoperation will be possible. 3.2 SCALING The mapped approach does not scale well, because of the cross-registration requirement discussed above. The numbers of users and hosts to be cross-registered rise as N-squared. This unwieldy mechanism will die of its own weight because the gateways will not be able to handle large numbers of maps, and name servers will be swamped by cross-registered users and hosts. The non-mapped gateway approach, on the other hand, scales well for large numbers of realms. Only a small number of gateways per realm need be cross-registered. 7 3.3 ROUTING OPTIMIZATION The main advantage of having cross-registration is that the selection of a gateway from a localized list can result in more efficient routing. The choice of a gateway from an unordered list, by its very nature, results in an inefficient selection. This can be mitigated perhaps by subdividing a realm into geographical areas, each with their own pool of gateways. Research may yet uncover a technique for optimal selection based on resource discovery work in progress (Schwartz, 1990). At any rate, this is not a problem unique to application gateway selection in the Internet. Cross-registration allows each organization to specify the closest, cheapest, or highest-bandwith gateway it has available. While localizing this decision is laudable, the effort to maintain this capability is significant and offers uneven benefit. Avoiding cross-registration, a realm-based pool can result in less efficient routing, but can offer alternate paths that the localized gateway could not (depending on connectivity). Such a pool also acts as a well-defined interface to a realm. 3.4 NAME CONSISTENCY The non-mapped approach has the appeal of a consistent naming interface for both senders and recipients alike. The recipient's name is already expressed in a form usable by the recipient's realm. That is, there are no adjustments required by the sender to compensate for the local realm, its syntax, or its proximity to the recipient. The realm and name together convey enough absolute information to route a message to the proper gateway and to the final recipient. This seemingly mundane issue has great impact on the recipient's ability to publicize its name without regard for the sender's vantage point. The business card is typical of the way in which realms and names are published. Users may publish their mail names (and realm) in directories (online or hardcopy) and expect senders to be able to use such names directly. They should not expect to have to publish one address for those inside their realm and another for those outside and they should not be expected to publish a different address for each senders' realms. 8 3.5 GATEWAY SUPPORT INFRASTRUCTURE The cross-registration requirements of the mapping approach force the use of mapping tables to translate one realm's syntax into another's. These mapping tables will be large, somewhat dynamic, and required globally. Continuing efforts to distribute the maintenance and retrieval of the information in the tables are creating a complex gateway support infrastructure. The name service is being extended with new and private attributes to house the new information. New name spaces are being proposed to house the cross-registration of users and hosts. The load on database administrators will increase dramatically for each new realm that seeks interoperability. This infrastructure is unnecessary with the non-mapped approach. 9 SECTION 4 CONCLUSIONS AND RECOMMENDATIONS 4.1 CONCLUSIONS It is clear from the discussions in the preceding two sections that there are very strong arguments against extensive cross- registration of users and host systems. The non-mapped approach to name resolution in application-level gateways offers a consistent interface to users and greatly reduces the burden on system database administrators. The approach scales well when large numbers of application realms are considered and the N-squared alternatives are examined and discarded. It allows for the publication of recipient names without regard to the starting position of a sender. The only requirement is for a simple, centrally-maintained registry of realm names. The non-mapped approach does not optimize the selection of a gateway, although this problem is echoed in other research efforts dealing with network resource discovery. The tradeoff for less optimal routes is the simplification of realm interfaces, table maintenance, and name consistency. The question must be asked then, as to why an elaborate, incomplete scheme should be researched, developed, and maintained. Some of the cooperative discussions about isolated European gateways and dynamic or static mapping tables are pertinent to the collecting of realm gateway registration. The same mechanisms being discussed for extensive user and host cross-registration can be applied to the much simpler task of gateway registration and selection. These discussions should proceed to put in place the necessary mechanisms, but should recognize the futility of full cross- registration. 4.2 RECOMMENDATIONS There are several recommendations which can make the non- mapped approach viable for the Internet and OSI realms. These are outlined below. They have been grouped by cognizant realm. 10 4.2.1 Internet Realm Actions The existing Internet opaque bucket is a quoted string as the user portion of an address (Crocker, 1982). This mechanism should serve its purpose well and will handle any realm's syntax if strictly enforced. There are implementations, however, that do not preserve the opacity of such strings. Such behavior should not be tolerated, since the non-mapped approach has already been shown to be the minimal functionality in the gateway. The Internet's efforts should be turned towards fixing such broken implementations. The Internet realm should create a registry for realms and their gateways in the Domain Name System. The IETF is a suitable body to decide what portion of the DNS tree should be used for naming. Such an effort should be coordinated with other realms, to ensure the DNS structure will be adequate for covering a variety of applications. 4.2.2 OSI Realm Actions The OSI realm should standardize on the use of a mechanism (such as X.400's Domain Defined Attribute) as an opaque bucket. It should establish a way to register these buckets and the procedures for using them. The NIST OIW is a suitable body for such an agreement, but it must coordinate with other realms to keep the mechanism flexible and adequate for their needs. The OSI realm should create registries for realms and their gateways in the Directory System. These should be early in the hierarchy of the name space (for simplicity) and should be centrally maintained. Such an effort should be coordinated with other realms. 4.2.3 Other Realms Some realms already have a bucket mechanism available and need to take actions similar to those above. Others may not have a bucket mechanism in place. There will either have to establish such a mechanism, or they will have to seek bilateral agreements with other realms to do some sort of proxy or mapping service. 11 POSTLUDE The above discussion was a first pass at simplifying the infrastructure and end-user confusion we saw in the current application gateway development. The basic changes were to the local user interface (to obtain a realm name) and to a portion of the name service tree (to register realm gateways). The model assumed adjacent realms and the use of a realm name was merely a local matter used to look up a gateway to that realm. Proxy gateways could be used to "front" a second-level realm, but this is a totally private and bilateral agreement. Further in-house discussions have postulated even more "daisy-chaining" of realms. This architecture allows a realm to serially front for another realm, which is fronting for another realm, etc. There will be tunneling or bridging across one realm to reach the next realm, but these can be devised locally. A mechanism must be available, however, for keeping track of the true destination realm, so that proper routing can occur. This can be accomplished either by discrimination on receiving interface characteristics (port number, net address, etc) or another "bucket" in which the realm name is carried, so that the "next hop" in the tunneling can tell how to route. The form of the bucket would be realm-specific, but may use the same sort of mechanism that a "foreign" address is carried in now (e.g., a second Domain Defined Attribute). We do not favor the long daisy-chained architecture, but admit that it may be the only practical solution for pools of connectivity and an imperfect world. The other approach not treated in the discussion is the algorithmic mapping between realm syntaxes. The notion here is that you don't need mapping tables, because each component (attribute) of a syntax can be transformed into a component in the other realm's syntax. For example, Walt.Lazear@gateway.mitre.org in Internet terms can be expressed in X.400 terms as /o=org/ou=mitre/ou=gateway/pn=Walt Lazear/ The rules for doing the transformation must be spelled out for both realms and restrictions for naming result from those rules. Note that there is the ugly part of this relating to country codes, ADMDs and PRMDs that must be turned into something the Internet knows about. The same can happen when other realms are involved (everyone has ugly parts!). We call this the community-of-interest approach, since all players in both realms who will use a gateway (knowingly or otherwise) must agree to the same rules. We do not see this approach as useful in the general case, since the various realms have widely differing levels of detail and agreement across an entire realm is difficult. From lazear@gateway.mitre.org Wed Nov 14 10:36:13 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 14 Nov 90 10:36:13 -0600 Received: from gateway.mitre.org by cs.wisc.edu; Wed, 14 Nov 90 10:36:07 -0600 Return-Path: Received: by gateway.mitre.org (5.61/SMI-2.2) id AA22716; Wed, 14 Nov 90 10:42:45 -0500 Message-Id: <9011141542.AA22716@gateway.mitre.org> To: hagens Cc: rare-wg1@switch.ch, pp-people@cs.ucl.ac.uk, ietf-osi-x400, rd-mhs-managers@rare.no, lazear@dockside.mitre.org, gomberg@gateway.mitre.org Subject: Re: RFC 987 Procedures Date: Wed, 14 Nov 90 10:34:47 -0500 From: lazear@gateway.mitre.org Rob, I think your 11/8 message begins to converge on the real issues. Your point about the DD.RFC822 being a simple solution is right on! The issue of source routing would be true if there were not some piece of information available to designate whose naming system is the target. I call this piece a "realm" and the recipient must tell others what realm he's in and a sender must tell his mail system what realm to send to, so the system can look up the gateway and route to it. Mine would be: Internet: lazear@gateway.mitre.org This works both directions, since an Internet sender can enter the "foreign" address in the foreign syntax and designate the target realm. The system looks up a gateway in the DNS under that realm (e.g., X400gw.realm.net would have A records with gateway addresses) and route to it. I think the cross-registration of gateways (not hosts, companies, or users) makes the DD.RFC822 solution work. The routing isn't perfect, but the end user can now hand out an address that works from all realms! No more 8x5" business cards listing all possible variations of my address expressed in all possible senders' terms. Walt Lazear ps - I'm not hung up on the particular realm names (Internet, X400, BITNET, etc.). From huitema@jerry.inria.fr Wed Nov 14 12:03:22 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 14 Nov 90 12:03:22 -0600 Received: from jerry.inria.fr by cs.wisc.edu; Wed, 14 Nov 90 12:02:30 -0600 Received: by jerry.inria.fr (5.61+++/IDA-1.2.8) id AA24398; Wed, 14 Nov 90 18:25:44 +0100 Message-Id: <9011141725.AA24398@jerry.inria.fr> To: lazear@gateway.mitre.org Cc: hagens, ietf-osi-x400, rd-mhs-managers@rare.no, lazear@dockside.mitre.org, gomberg@gateway.mitre.org Subject: Re: RFC 987 Procedures In-Reply-To: Your message of 14 Nov 90 17:38:56 +0100. Date: Wed, 14 Nov 90 18:25:34 +0100 From: Christian Huitema Walt, Your notion of "realms" is contradictory with the very approach that we are pushing, i.e. that the user address shall not depend on transmission technology. Several European networks have successfully managed the convergence of their X.400, UUCP, BITNET, or TCP-IP based mail networks towards a single naming scheme, and this is seen as an extremely good thing for at least two reasons: * users, and particularly large mail servers, are often connected to several transport services, * users shall not be locked in one particular mail service, and should be able to retain the same address when they move from one techno to another. In short, "naming realm" may exists, but their boundary will certainly not correlate with those of transport services. You then introduce a concept of "bucket", which I understand as a formalisation of the "% hack". Apart from the standard argument against gateway addressing, you must consider also that in practice the "buckets" are leaky. For example, one need to transform somewhat an RFC-822 address in order to place it in an X.400 DDA; and the representation of an X.400 ORName within a quoted string is not obvious nor univocal. To be short, your main argument is that "mapping tables dont scale". But one will easily notice that the "realm" approach only works if one can derive the "realm" from the address, e.g. by a directory lookup; in which case, one could as well have derived the mapping rule for the said realm! Christian Huitema From lazear@gateway.mitre.org Fri Nov 16 14:48:04 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Fri, 16 Nov 90 14:48:04 -0600 Received: from gateway.mitre.org by cs.wisc.edu; Fri, 16 Nov 90 14:47:56 -0600 Return-Path: Received: by gateway.mitre.org (5.61/SMI-2.2) id AA06622; Fri, 16 Nov 90 15:46:45 -0500 Message-Id: <9011162046.AA06622@gateway.mitre.org> To: lazear@gateway.mitre.org, hagens, ietf-osi-x400, rd-mhs-managers@rare.no, lazear@dockside.mitre.org, gomberg@gateway.mitre.org, epg@gateway.mitre.org Subject: Re: RFC 987 Procedures In-Reply-To: Your message of "Wed, 14 Nov 90 18:25:34 +0100." <9011141725.AA24398@jerry.inria.fr> Date: Fri, 16 Nov 90 15:45:07 -0500 From: lazear@gateway.mitre.org Christian, Thanks for your comments on my "realm" ideas. You certainly surprised me with a couple of the points! Let me respond to some of your comments and objections. The realm name is not something to be derived from an address. It is an explicit part of a user's address. Depending on how much tunneling one architects, it may remain a local interface matter as to how realm is indicated. The point is, my scheme proposes that we tell people which name space we're using, instead of trying to deduce it from the syntax (you can't do it with the UK and US domain name syntaxes, without formal restrictions on names in certain positions. The net has already beaten this topic to death). While I agree that users should not be locked into a particular mail service, it seems futile to try to lock them into a particular name. Which naming system should they stick with? The first one they use? (Compuserve hostid,userid?) Domain names? ORNames? UUCP names? One doesn't keep old business cards when one changes jobs, old addresses when one moves one's abode, or spouse name when one remarries. :-) Seriously, I'd really like to understand where this "requirement" for lifetime mail address lock-in came from. Your note was the first time I'd seen that expressed. I guess the bucket concept is a formalization of the percent hack, but perhaps the leaky bucket and percent hack came about because of lack of recognition of the need for an opaque portion of the name. We may have found a fundamental flaw in the early ARPA mail architecture that needs remedying now that we're smarter about mail interactions. Clearly, the DDA came out of a need for a bucket. The non-univocal view of an X.400 human-readable syntax may merely reveal the bias of the ISO standard-makers against user interface issues. I think it's a basic oversight, however, not to have defined such a canonical form and am glad the issue is being worked now. I don't understand why you state that an Internet address needs to be transformed when put in a DDA. It seems to me that the DDA is a bucket (one per realm) that should be filled blindly (by the software) from the sender's input. Interpretation (required if transformation is to occur) should be left to the gateway. The registration of realm gateways does not have to correspond to the granularity of the mapping rules...it can be fewer, especially if the gateways exist at the national or regional level. Raising the cross-over point between realms can greatly reduce the need for detailed cross-registration. I think the major downside for this simpler view is performance in the form of less-optimal routing. But think of the operational simplification by not requiring such detailed cross-registration and mapping table maintenance and distribution! Walt Lazear From lazear@gateway.mitre.org Fri Nov 16 14:50:54 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Fri, 16 Nov 90 14:50:54 -0600 Received: from gateway.mitre.org by cs.wisc.edu; Fri, 16 Nov 90 14:50:46 -0600 Return-Path: Received: by gateway.mitre.org (5.61/SMI-2.2) id AA06711; Fri, 16 Nov 90 15:49:32 -0500 Message-Id: <9011162049.AA06711@gateway.mitre.org> To: lazear@gateway.mitre.org, hagens, ietf-osi-x400, lazear@dockside.mitre.org, gomberg@gateway.mitre.org, epg@gateway.mitre.org Subject: Re: RFC 987 Procedures In-Reply-To: Your message of "Wed, 14 Nov 90 18:25:34 +0100." <9011141725.AA24398@jerry.inria.fr> Date: Fri, 16 Nov 90 15:48:28 -0500 From: lazear@gateway.mitre.org [.fr and rare.no were not resolved by our domain system, so I dropped the rd-mh-managers and Christian's personal addresses from this reply list. Walt] Christian, Thanks for your comments on my "realm" ideas. You certainly surprised me with a couple of the points! Let me respond to some of your comments and objections. The realm name is not something to be derived from an address. It is an explicit part of a user's address. Depending on how much tunneling one architects, it may remain a local interface matter as to how realm is indicated. The point is, my scheme proposes that we tell people which name space we're using, instead of trying to deduce it from the syntax (you can't do it with the UK and US domain name syntaxes, without formal restrictions on names in certain positions. The net has already beaten this topic to death). While I agree that users should not be locked into a particular mail service, it seems futile to try to lock them into a particular name. Which naming system should they stick with? The first one they use? (Compuserve hostid,userid?) Domain names? ORNames? UUCP names? One doesn't keep old business cards when one changes jobs, old addresses when one moves one's abode, or spouse name when one remarries. :-) Seriously, I'd really like to understand where this "requirement" for lifetime mail address lock-in came from. Your note was the first time I'd seen that expressed. I guess the bucket concept is a formalization of the percent hack, but perhaps the leaky bucket and percent hack came about because of lack of recognition of the need for an opaque portion of the name. We may have found a fundamental flaw in the early ARPA mail architecture that needs remedying now that we're smarter about mail interactions. Clearly, the DDA came out of a need for a bucket. The non-univocal view of an X.400 human-readable syntax may merely reveal the bias of the ISO standard-makers against user interface issues. I think it's a basic oversight, however, not to have defined such a canonical form and am glad the issue is being worked now. I don't understand why you state that an Internet address needs to be transformed when put in a DDA. It seems to me that the DDA is a bucket (one per realm) that should be filled blindly (by the software) from the sender's input. Interpretation (required if transformation is to occur) should be left to the gateway. The registration of realm gateways does not have to correspond to the granularity of the mapping rules...it can be fewer, especially if the gateways exist at the national or regional level. Raising the cross-over point between realms can greatly reduce the need for detailed cross-registration. I think the major downside for this simpler view is performance in the form of less-optimal routing. But think of the operational simplification by not requiring such detailed cross-registration and mapping table maintenance and distribution! Walt Lazear From huitema@jerry.inria.fr Mon Nov 19 02:38:45 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Mon, 19 Nov 90 02:38:45 -0600 Received: from jerry.inria.fr by cs.wisc.edu; Mon, 19 Nov 90 02:38:30 -0600 Received: by jerry.inria.fr (5.61+++/IDA-1.2.8) id AA02261; Mon, 19 Nov 90 09:39:16 +0100 Message-Id: <9011190839.AA02261@jerry.inria.fr> To: lazear@gateway.mitre.org Cc: hagens, ietf-osi-x400, rd-mhs-managers@rare.no, lazear@dockside.mitre.org, gomberg@gateway.mitre.org, epg@gateway.mitre.org Subject: Re: RFC 987 Procedures In-Reply-To: Your message of 16 Nov 90 22:31:00 +0100. <9011162046.AA06622@gateway.mitre.org> Date: Mon, 19 Nov 90 09:39:11 +0100 From: Christian Huitema Walt, I never advocated the use of "one single address for the life time", as you caricature in: > While I agree that users should not be locked into a particular >mail service, it seems futile to try to lock them into a particular name. >Which naming system should they stick with? The first one they use? >(Compuserve hostid,userid?) Domain names? ORNames? UUCP names? >One doesn't keep old business cards when one changes jobs, old addresses >when one moves one's abode, or spouse name when one remarries. :-) >Seriously, I'd really like to understand where this "requirement" for lifetime >mail address lock-in came from. Your note was the first time I'd see >that expressed. What I said was "that the user address shall not depend on transmission technology", and that someone connected to several "transmission networks" (e.g. Bitnet, UUCP, TCP Internet, RARE X.400 MHS) should have only one address. That requirement may be very weak for the users of closed, centralized systems, e.g. the CompuSource; it is however essential in widely connected organisations like ours. In short, we dont belong to what you call a "realm". As far as "buckets" are concerned, you should realize that they dont, in practice, exist. You cannot place a binary ORName in an RFC quoted string; the special chars common in RFC addresses (!%@) are illegal in an X.400 DDA. You thus have to place a translation procedure between the user and the bucket, and to coordinate it with the translations performed in gateways. This translation will be either performed by a human (poor guy) or by a software -- in which case one could as well use whatever mapping rules are available. Christian Huitema From hagens Mon Nov 19 14:17:55 1990 Message-Id: <9011192017.AA00304@janeb.cs.wisc.edu> Received: from localhost by janeb.cs.wisc.edu; Mon, 19 Nov 90 14:17:55 -0600 To: lazear@gateway.mitre.org Cc: ietf-osi-x400, lazear@dockside.mitre.org, gomberg@gateway.mitre.org, epg@gateway.mitre.org Subject: Re: RFC 987 Procedures In-Reply-To: Your message of "Fri, 16 Nov 90 15:48:28 EST." <9011162049.AA06711@gateway.mitre.org> Date: Mon, 19 Nov 90 14:17:54 CST From: hagens Walt, I am puzzled by a few aspects of your proposal. Perhaps if I ask a few questions... Consider 3 mail "networks" concatenated together: A <-> B <-> C A and C are RFC 822 based B is X.400 based (A and C are not directly connected) 1) Are there 2 or 3 realms in this picture? 2) Can you describe how a user in 'C' (call him 'c') would address a user in 'A' (call her 'a'). 3) How does B know to route to the correct gateway? 4) Suppose some user 'z' is connected to both A and B. Would 'z' have two addresses or one address with two representations? Would z have 1 or 2 mailboxes? Thanks, Rob From Alf.Hansen@pilot.cs.wisc.edu Mon Nov 19 16:39:01 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Mon, 19 Nov 90 16:39:01 -0600 Received: from csl5.cs.wisc.edu by cs.wisc.edu; Mon, 19 Nov 90 16:38:51 -0600 X400-Received: by mta pilot.cs.wisc.edu in /PRMD=xnren/ADMD= /C=us/; Relayed; Mon, 19 Nov 1990 16:38:28 +0000 X400-Received: by /PRMD=xnren/ADMD= /C=us/; Relayed; Mon, 19 Nov 1990 15:38:14 +0000 Date: Mon, 19 Nov 1990 16:38:14 -0500 X400-Originator: Alf.Hansen@pilot.cs.wisc.edu X400-Mts-Identifier: [/PRMD=xnren/ADMD= /C=us/;hansen659054294.22hermit.cs.uw] X400-Content-Type: P2-1984 (2) Content-Identifier: 901119163811 From: Alf Hansen Message-Id: <901119163811*@MHS> To: rare-wg1@switch.ch, pp-people@cs.ucl.ac.uk, ietf-osi-x400, rd-mhs-managers@rare.no Subject: News from the NSF X.400 Pilot Project. Dear Colleague, This first newsletter has already been distributed among the MTA managers in PRMD XNREN, and is now being sent out to a wider community because we think the information is of common interest. If the list managers would prefer that the future newsletters from the project are not distributed on their lists, please let me know, and you will not receive future issues. Best regards, Alf H on behalf of the NSF X.400 Pilot Project Team. ============================================================================ T H E 4 0 0 NSF X.400 Pilot Project Newsletter No 1/1990 November 1990 Queries to: c=no/admd= /prmd=edu/o=wisc/ou=cs/pn=x400-project-team x400-project-team@cs.wisc.edu Phone: +1 608 262 5084 Fax: +1 608 262 9777 Computer Sciences Department, University of Wisconsin-Madison, 1210 West Dayton Street, Madison, Wisconsin 53706, USA. ============================================================================ THIS IS OUR FIRST NEWSLETTER. ----------------------------- This new Newsletter will on a regular basis inform you about the recent developments in our project. The information is intended for - Organizations already participating in our experimental X.400 service - Organizations that may be interested in joining either as an MTA under PRMD=XNREN or as a subscriber to other X.400 services in the Internet. - Any other interested parties. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The NSF X.400 Project - why ? ------------------------------ The CCITT/ISO X.400/MOTIS messaging system offers a number of advantages over the currently used messaging system on the Internet. Not the least of these is the fact that X.400 has been accepted as an international standard. In the United States, as well as overseas, government and commercial organizations are already committed to basing future mail services on X.400. A second major benefit is that X.400 provides for the use of multi-media messages. Future X.400 systems will likely incorporate integrated graphics, voice, video and facsimile message components in addition to the current text standard. A third benefit is that X.400 also will include the ability to utilize very general directory systems which may be used to locate mail recipients. The Internet community has used electronic mail as an international service for several decades, and is a representative user group with respect to user requirements, service management, addressing- and routing- problems, interconnectivity, future service developments etc. It is essential that the Internet community itself be a leader in the development of new E-mail technology. By being an early user group of X.400 services and by gaining experience from operating a national/international X.400 service in a multi-protocol environment, other communities can take advantage of the experience gained by the Internet community. The NSF X.400 Pilot Project is one of the first steps to establish a well-organized X.400 service integrated with the current Internet Mail service. The project will operate an experimental X.400 Private Management Domain (PRMD). The precise role of and requirements for a PRMD are not fully understood. By operating a PRMD, the project will identify work items and responsibilities that clearly belong to a PRMD, and make recommendations on the future PRMD structure in the Internet. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - How can the NSF X.400 Project be useful for me? ----------------------------------------------- If you are in an organization starting to experiment with X.400, you may have discovered that there are several unresolved problems, such as: - Availability of software products. The Project is distributing ARGO (see below) to a limited number of non-commercial sites. - Naming and addressing. The project will register unique Organization names under our PRMD, and advise you on address mapping problems (see "Topic of Today"). - Connectivity to the existing Internet mail services in the US. The project will operate a central gateway facility based on the PP software from UCL, London, and assist you with use and operation (should you decide to operate your own gateway). - Connectivity to other X.400 users in the US. The project will distribute routing information between the participants in the experimental service. Under guidence of CNRI, we will seek to establish agreements with public X.400 service operaters in the US. - International connectivity. The current operational X.400 service managed by the project is connected to more than 20 countries offering X.400 services to the R&D community. The project will provide you with information about routing and connectivity. - X.400 integration in my organization. The project will propose alternative integration strategies. Results from technical innovations will be offered to end-users when the stability of the service is reasonable, such as - Mail/fax gateway. - X.500 directory services. - Multimedia document handling. Participating organizations may use the experimental infrastructure as a testbed for such new services. The project team will not operate as an isolated group. The various aspects of operation of an X.400 service integrated with the existing Internet mail service will be discussed with relevant groups in the Internet in order to reach the best possible solutions to the many controversial problems. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Who is participating in the experimental X.400 service today? ------------------------------------------------------------- Currently we have the ARGO software running on a number of machines at the University of Wisconsin and at 5 other Internet sites. We are working to complete license agreements and install the software at other academic and government sites. We have established successful X.400 connections to several European Internet sites running different X.400 implementations. By relaying through them we have X.400 connectivity to the complete R&D MHS Service coordinated by the RARE MHS Project in Europe. The following organizations are operational and interconnected as X.400 systems. Addressing examples are given in order to show how the X.400 addresses looks like. The X.400 addresses are presented both on X.400 Standard Attribute (SA) form and on RFC 822 form. Organization X.400 address on SA form and RFC 822 form ------------------------------------------------------------------------ University of Wisconsin-Madison Madison, WI C=us; ADMD= ; PRMD=xnren; O=uw-madison; OU=cs; PN=User User@pilot.cs.wisc.edu National Science Foundation Washington, D.C. C=us; ADMD= ; PRMD=xnren; O=nsf; PN=User User@pilot.nsf.gov Rice University Houston, TX C=us; ADMD= ; PRMD=xnren; O=rice-univ; PN=User User@exp.rice.edu Mitre Corporation McLean, VA C=us; ADMD= ; PRMD=xnren; O=mitre; OU=ieg; PN=User User@pilot.ie.org University of Pennsylvania Philadelphia, PA C=us; ADMD= ; PRMD=xnren; O=upenn; OU=cis; PN=User User@pilot.upenn.edu NASA-Ames Research Center CA C=us; ADMD=telemail; PRMD=arc; O=nasa; OU=argo; PN=User User@argo.pilot.arc.nasa.gov These organizations can communicate with X.400 users in the R&D MHS Service in the following countries: Austria, Australia, Belgium, Canada, Denmark, Germany, Finland, France, Iceland, Ireland, Italy, (Rep. of Korea), The Netherlands, Norway, Portugal, Spain, Sweden, Switzerland, United Kingdom, and Yougoslavia. Initially we are using the 1984 X.400 code that was implemented as part of the IBM ARGO project here at Wisconsin. This code was originally written for the IBM RT (AOS), and we have ported it to the Sun 3 (SunOS 4.x), Sun4 (SunOS 4.x) and the Vax (ULTRIX 3.x) [microVax, 11/780, etc]. For the initial stages of this experiment we will be using RFC 1006 on top of TCP/IP due to widespread availability. In the future, we expect to use OSI networking support (e.g., as will be distributed with BSD Unix 4.4). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - How can I join the project? --------------------------- If you want to be a part of the PRMD XNREN, you should first register your Organization at the XNREN Naming Authority (NA). This is simply done by filling in a simple form and sending it to us. At the same time you should decide on a RFC-822 <--> X.400 address mapping (see "Topic of today" below). This small amount of bureacracy is needed to insure unique X.400 addresses and no address conflicts between Internet mail and X.400. If you would like to use the IBM ARGO software, two copies of our IBM license agreement must be signed by a representative of your institution and returned to us. Upon receipt, we will have the agreement signed by a UW representative and will return one copy to you. If your legal representatives require modifications to the contract, we will work to reach an agreement that is mutually agreeable to your lawyers, the University of Wisconsin, and the IBM Corporation. Unfortunately this is an imposing task that has caused considerable delays with other sites. The licence agreement is available on-line. Our software is prepared for immediate distribution via ftp. We may be available to provide any necessary assistance (and possibly visit) with installation, configuration, and other relevant technical matters. You are also welcome to use your own X.400 software. When you have the software operational, we should set up X.400 connectivity between your site and the Wisconsin gateway MTA, and exchange the necessary operational information. We require a contact person (MTA manager) for each organization, and we maintain a distribution list of all local managers. This list is used to discuss operational problems and procedures, in PRMD XNREN. If you want to operate as a PRMD outside XNREN, you should contact the management of this PRMD and they should contact us to set up an interconnection agreement. This is not necessarily a complex contract, but can rather be a simple agreement insuring that there is a good flow of information between our PRMDs, and that we share recources. In this case you should register your Organization with the NA in the PRMD concerned. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * * * Topic of today: * * * Introduction of the RFC 822 <--> X.400 address mapping problem. --------------------------------------------------------------- As an example of the mapping problem, consider the following X.400 address: c=us/admd= /prmd=xnren/o=UW-Madison/ou=cs/pn=Alf.Hansen This address cannot be expressed in an RFC 822 system, therefore an address mapping from X.400 to RFC 822 must be defined. The XNREN NA will insure that all X.400 addresses in the XNREN address space has an unambiguous RFC 822 representation. Given the current mapping, the RFC 822 interpretation of the above address is: Alf.Hansen@pilot.cs.wisc.edu Mapping in the other direction: The RFC 822 address lhl@cs.wisc.edu cannot in general be expressed in an X.400 system, therefore an address mapping from RFC 822 to X.400 must be defined. Today no such mapping is defined in the US, and this create problems for existing X.400 users because they have no unique way to represent a US RFC 822 address in X.400 format. To assist their users, X.400 service providers had to define their own mappings instead of using an official US defined mapping. The result is that there exist more than a dozen ways to represent the same US Internet RFC 822 address, in X.400 format. This is confusing not only for the X.400 users, but also for the US Internet mail users, because communication between X.400 users and the US Internet mail users is difficult from an addressing point of view. The similar national problem does not exist in other countries that the US. The national network managers in the other relevant countries, where both X.400 and Internet mail are in operation, have defined their mappings. An example from Norway: The Internet mail address he@idt.unit.no is mapped to c=no/admd= /o=unit/ou=idt/pn=he It is therefore clear for all X.400 users in Norway and elsewhere, how they should address an Internet mail user in Norway. Until the US definition of such mapping has been established, X.400 users in XNREN has been told to use the Norwegian mapping to reach Internet mail users in the US. This is indeed a temporary solution, and the result is: lhl@cs.wisc.edu is mapped to c=no/admd= /prmd=edu/o=wisc/ou=cs/pn=lhl A high priority task for the US Internet is to define these mappings. The address mapping takes place in RFC 987 gateways. The project will benefit from the ongoing international coordination of mapping tables which is provided by the RARE MHS project. The X.400 and RFC 822 address space are two different address spaces. The RFC 822 address space in the US is defined and exists. The X.400 address space is about to be defined. The two address spaces need to be integrated, so special care must be taken to insure that addressing conflicts do not occur, for example, that a new X.400 address with a given mapping does not conflict with an existing RFC 822 address. Remark: Such address-overlaps can be allowed, but then we must make sure that all the operational requirements are met in order to do that. The XNREN Naming Authority will make sure that all registered organizations (O) and organizational units (OUs) under the PRMD XNREN, with a given mapping, do not create such conflicts. The XNREN NA will also guarantee unique Os under PRMD XNREN. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Contact points: --------------- The following persons are working on the project: Allan.Cargille@pilot.cs.wisc.edu C=us/ADMD= /PRMD=xnren/O=UW-Madison/OU=cs/PN=Allan.Cargille Rob.Hagens@pilot.cs.wisc.edu C=us/ADMD= /PRMD=xnren/O=UW-Madison/OU=cs/PN=Rob.Hagens Alf Hansen@pilot.cs.wisc.edu C=us/ADMD= /PRMD=xnren/O=UW-Madison/OU=cs/PN=Alf.Hansen Larry.Landweber@pilot.cs.wisc.edu C=us/ADMD= /PRMD=xnren/O=UW-Madison/OU=cs/PN=Larry.Landweber - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From stef@odin.cs.wisc.edu Mon Nov 19 23:58:56 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Mon, 19 Nov 90 23:58:56 -0600 Received: from NRTC.NORTHROP.COM by cs.wisc.edu; Mon, 19 Nov 90 23:58:49 -0600 Received: from nma.com by nrtc.nrtc.northrop.com id ae16733; 19 Nov 90 21:57 PST Received: from odin by nma.com id aa05377; 19 Nov 90 21:48 PST Received: from localhost by odin.nma.com (4.1/SMI-4.1(NMA)) id AA00313; Mon, 19 Nov 90 21:46:13 PST To: Christian Huitema Cc: lazear@gateway.mitre.org, hagens, ietf-osi-x400, rd-mhs-managers@rare.no, lazear@dockside.mitre.org, gomberg@gateway.mitre.org, epg@gateway.mitre.org Subject: Re: RFC 987 Procedures In-Reply-To: Your message of Mon, 19 Nov 90 09:38:53 +0100. <9011190839.AA02261@jerry.inria.fr> Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Mon, 19 Nov 90 21:46:11 PST Message-Id: <312.659079971@odin> Sender: stef@odin My take on the REALM and BUCKETS MODEL is that it simply a new name for "SOURCE-ROUTING"...\Stef From lazear@gateway.mitre.org Wed Nov 21 14:59:50 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 21 Nov 90 14:59:50 -0600 Received: from gateway.mitre.org by cs.wisc.edu; Wed, 21 Nov 90 14:59:41 -0600 Return-Path: Received: by gateway.mitre.org (5.61/SMI-2.2) id AA23684; Wed, 21 Nov 90 15:58:41 -0500 Message-Id: <9011212058.AA23684@gateway.mitre.org> To: hagens Cc: ietf-osi-x400, lazear@dockside.mitre.org, gomberg@gateway.mitre.org, epg@gateway.mitre.org Date: Wed, 21 Nov 90 15:57:43 -0500 From: lazear@gateway.mitre.org Subject: Re: RFC 987 Procedures -------- Rob, Here are some answers to your questions. I hope they clarify. Walt >Consider 3 mail "networks" concatenated together: > > A <-> B <-> C > > A and C are RFC 822 based > B is X.400 based > > (A and C are not directly connected) > >1) Are there 2 or 3 realms in this picture? ** 3 >2) Can you describe how a user in 'C' (call him 'c') would address a user > in 'A' (call her 'a'). ** This is the "daisy-chained" configuration I mentioned at the end of my paper. It requires a bilateral agreement that B will front for A. To begin with, user c being in a realm using RFC 822 addressing would have a mail address of the form userc.hostC.domainC in Realm C. Likewise, there would be usera.hostA.domainA in Realm A. On the other hand, a user in the X.400 realm would have an address that X.400 understands directly (not shown here since the business card form is still unsettled :). For userc to send a message to usera, it is necessary that Realm A has cross-registered in Realm C's DNS and "advertises" that it uses a gateway between Realm C and Realm B as the "path" for Realm C users to get to it. So, the To: field in userc's message might be something like: "usera.hostA.domainA"@gatewayCB.domainC The "bucket" here is what is inside the quotes. (Later the bucket will be an X.400 DDA.) First, gatewayCB.domainC is resolved to an IP-address and the message shows up at gatewayCB. Since this message is not destined for Realm B, it must be able to tell what Realm it *is* destined for so as to take proper action. There are two possibilities: either a well-known socket or NSAP (depending on which protocol stack we are talking about) can be reserved for a particular Realm, or some explicit syntax can be adopted locally (a DDA could be used in X.400; the Realm could be appended to the RFC822 address, e.g., usera.hostA.domainA.realmA). The gatewayAB now resolves, via the Directory, where the gateway is from RealmB to RealmA, say gatewayBA. This also required the appropriate cross-registration of RealmA in the RealmB Directory (this is needed if just A and B need to exchange messages). Unless realmB has agreed to do some kind of tunneling for RealmA, the message would be transformed into a form native to RealmB (X.400) and the RFC822 address would be put in a DDA (or two DDAs if the destination and realm needed to be preserved). >3) How does B know to route to the correct gateway? ** see answer to 2) >4) Suppose some user 'z' is connected to both A and B. Would 'z' have > two addresses or one address with two representations? > Would z have 1 or 2 mailboxes? ** z would have two addresses in two different realms. (How can this be otherwise?) What is a mailbox? (If it is an address, then there are two. If it is a program and data, it is still probabably two--after all, we are talking about different programs and data delivered in different formats.) As to whether there are 1 or 2, each has a termination point. How z's user interface makes that look to her (1 or 2 boxes) is a private matter that the rest of the world shouldn't be bothered with. How to send mail out the correct side (A or B) is also a private matter (after all, z decided to hook up to a couple of realms). Walt From lazear@gateway.mitre.org Wed Nov 21 17:11:35 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 21 Nov 90 17:11:35 -0600 Received: from gateway.mitre.org by cs.wisc.edu; Wed, 21 Nov 90 17:11:28 -0600 Return-Path: Received: by gateway.mitre.org (5.61/SMI-2.2) id AA24988; Wed, 21 Nov 90 18:10:28 -0500 Message-Id: <9011212310.AA24988@gateway.mitre.org> To: stef@ics.uci.edu Cc: lazear@gateway.mitre.org, ietf-osi-x400 Subject: Re X400 source route Date: Wed, 21 Nov 90 18:10:02 -0500 From: lazear@gateway.mitre.org Stef, First, I would direct your attention to the copy of a reply to Rob (included below). I consider the bucket/realm approach to be destination-determined routing, becauset the gateways have to be set up in advance (via cross-registration). The sender is merely doing "next hop" routing towards the destination realm. Walt ------- Forwarded Message Received: from janeb.cs.wisc.edu by gateway.mitre.org (5.61/SMI-2.2) id AA24078; Wed, 21 Nov 90 16:33:28 -0500 Organization: The MITRE Corp. Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 21 Nov 90 14:59:50 -0600 Received: from gateway.mitre.org by cs.wisc.edu; Wed, 21 Nov 90 14:59:41 -0600 Return-Path: Received: by gateway.mitre.org (5.61/SMI-2.2) id AA23684; Wed, 21 Nov 90 15:58:41 -0500 Message-Id: <9011212058.AA23684@gateway.mitre.org> To: hagens@cs.wisc.edu Cc: ietf-osi-x400@cs.wisc.edu, lazear@dockside.mitre.org, gomberg@gateway.mitre.org, epg@gateway.mitre.org Date: Wed, 21 Nov 90 15:57:43 -0500 From: lazear@gateway.mitre.org Subject: Re: RFC 987 Procedures - -------- Rob, Here are some answers to your questions. I hope they clarify. Walt >Consider 3 mail "networks" concatenated together: > > A <-> B <-> C > > A and C are RFC 822 based > B is X.400 based > > (A and C are not directly connected) > >1) Are there 2 or 3 realms in this picture? ** 3 >2) Can you describe how a user in 'C' (call him 'c') would address a user > in 'A' (call her 'a'). ** This is the "daisy-chained" configuration I mentioned at the end of my paper. It requires a bilateral agreement that B will front for A. To begin with, user c being in a realm using RFC 822 addressing would have a mail address of the form userc.hostC.domainC in Realm C. Likewise, there would be usera.hostA.domainA in Realm A. On the other hand, a user in the X.400 realm would have an address that X.400 understands directly (not shown here since the business card form is still unsettled :). For userc to send a message to usera, it is necessary that Realm A has cross-registered in Realm C's DNS and "advertises" that it uses a gateway between Realm C and Realm B as the "path" for Realm C users to get to it. So, the To: field in userc's message might be something like: "usera.hostA.domainA"@gatewayCB.domainC The "bucket" here is what is inside the quotes. (Later the bucket will be an X.400 DDA.) First, gatewayCB.domainC is resolved to an IP-address and the message shows up at gatewayCB. Since this message is not destined for Realm B, it must be able to tell what Realm it *is* destined for so as to take proper action. There are two possibilities: either a well-known socket or NSAP (depending on which protocol stack we are talking about) can be reserved for a particular Realm, or some explicit syntax can be adopted locally (a DDA could be used in X.400; the Realm could be appended to the RFC822 address, e.g., usera.hostA.domainA.realmA). The gatewayAB now resolves, via the Directory, where the gateway is from RealmB to RealmA, say gatewayBA. This also required the appropriate cross-registration of RealmA in the RealmB Directory (this is needed if just A and B need to exchange messages). Unless realmB has agreed to do some kind of tunneling for RealmA, the message would be transformed into a form native to RealmB (X.400) and the RFC822 address would be put in a DDA (or two DDAs if the destination and realm needed to be preserved). >3) How does B know to route to the correct gateway? ** see answer to 2) >4) Suppose some user 'z' is connected to both A and B. Would 'z' have > two addresses or one address with two representations? > Would z have 1 or 2 mailboxes? ** z would have two addresses in two different realms. (How can this be otherwise?) What is a mailbox? (If it is an address, then there are two. If it is a program and data, it is still probabably two--after all, we are talking about different programs and data delivered in different formats.) As to whether there are 1 or 2, each has a termination point. How z's user interface makes that look to her (1 or 2 boxes) is a private matter that the rest of the world shouldn't be bothered with. How to send mail out the correct side (A or B) is also a private matter (after all, z decided to hook up to a couple of realms). Walt ------- End of Forwarded Message From stef@odin.cs.wisc.edu Thu Nov 22 14:13:06 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Thu, 22 Nov 90 14:13:06 -0600 Received: from nrtc.northrop.com by cs.wisc.edu; Thu, 22 Nov 90 14:13:00 -0600 Received: from nma.com by nrtc.nrtc.northrop.com id ab27322; 22 Nov 90 12:11 PST Received: from odin by nma.com id aa00669; 22 Nov 90 6:18 PST Received: from localhost by odin.nma.com (4.1/SMI-4.1(NMA)) id AA01914; Thu, 22 Nov 90 10:08:22 PST To: lazear@gateway.mitre.org Cc: ietf-osi-x400 Subject: Re: Re X400 source route In-Reply-To: Your message of Wed, 21 Nov 90 18:10:02 -0500. <9011212310.AA24988@gateway.mitre.org> Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Thu, 22 Nov 90 10:08:21 PST Message-Id: <1913.659297301@odin> Sender: stef@odin Sorry about this, but <"usera.hostA.domainA"@gatewayCB.domainC> is source routing in its most transparent wrapper. Campare what you wrote and <"usera%hostA.domainA"@gatewayCB.domainC> which is the primordial case of source routing in the Internet, and explain to me what is different. What you are doing is inserting routing information in the addresses, which can only lead to more and more trouble. This is the essential problem with the ADMD name in the ORAddress, if you look closely. It looks like a domain name at first glance, but then when you dig deeper, it tournsout to be a routing directive, adn not just thename of a domain that contraols the names under it. In fact, the solution to the whole "source-routing" injection of the ADMD name is the use of ADMD=, which when translated to your example, becomes <"usera%hostA.domainA"@>. Your basic problem is that you have so artfully hidden the domain-routing nature of your proposal that it actually begins to look like a domain-naming proposal. The problem is that you are loading routing semantics into the top level names, just like the SSITT did for the ADMD in the X.400 ORAddress. The cardinal rule which you are breaking is that "A NAME is not an ADDRESS is not a ROUTE". Good computer science teaches us to never confuse NAMES, ADDRESSES or ROUTES in our designs. Unfortunately, not all mail system designers believe in this principle. Cheers...\Stef From hagens Mon Nov 26 17:38:41 1990 Message-Id: <9011262338.AA09279@janeb.cs.wisc.edu> Received: from localhost by janeb.cs.wisc.edu; Mon, 26 Nov 90 17:38:41 -0600 To: ietf-osi-x400 Subject: Agenda for the IETF-OSI-X.400 WG meeting Date: Mon, 26 Nov 90 17:38:40 CST From: hagens Proposed Agenda IETF OSI X.400 Working Group Boulder IETF Meeting December 5, 1990 Morning Session: Discussion & Markup of the paper: "Draft Proposal for the use of the Internet DNS to maintain RFC 987/RFC 1148 Address Mapping Tables" The goal of this session is to review this draft and modify as necessary in preparation of its submission as an internet draft. This will be the last chance for the working group to review the document before it is submitted as an internet draft. Once submitted as an I-D, I expect sites begin to implement, so it is important that we reach consensus on issues raised in the document. This paper may be retrieved by anonymous ftp from janeb.cs.wisc.edu (128.105.2.151) in the pub directory: -r--r--r-- 1 ftp 29553 Nov 26 17:03 dns987.out -r--r--r-- 1 ftp 66845 Nov 26 17:03 dns987.ps Please do not come to this session unless you have read the document and have comments. Afternoon Session: The afternoon will be spent discussing issues related to the deployment of X.400 in the Internet. Topics include o Overall organization of X.400 in the Internet o Address mapping (822/X.400) o International Connectivity/Coordination This session is open to all interested parties. If time permits we will also discuss a RARE-WG1 paper "A Minimum Profile for RFC-987: Mapping between addresses in RFC-822 format and X.400 Standard Attributes" by Ruediger Grimm, GMD This paper may be retrieved by anonymous ftp from janeb.cs.wisc.edu (128.105.2.151) in the pub directory: -r--r--r-- 1 ftp 53806 Nov 26 17:29 min-rfc987-profile.out An abstract of the paper is included below. This paper is a RARE-WG1-document (working group 1 on November 26, 1987). "A Minimum Profile for RFC-987: Mapping between addresses in RFC-822 format and X.400 Standard Attributes" by Ruediger Grimm, GMD This paper tries to explain in simple words and examples one essential part of RFC-987. It describes the transformation of addresses, whereby only those X.400 attributes are considered which are marked other than "unsupported", by the international profiles CEN/CENELEC, CEPT or NBS. One aim of this paper is to help people to understand and learn this part of RFC-987. The other aim is to describe this part of RFC-987 address transformation as a functioning subset of a full RFC-987 implementation. A gateway at the level of this subset will cooperate with gateways at full RFC-987 without distortion of addresses. Addresses that are transformed by a gateway at the level of this subset will be transformed and retransformed in the same way by a gateway at any level between this subset and full RFC-987. Therefore, this paper describes a minimum profile of RFC-987, by recommending to implementors in RARE community: "Do not implement less than the level of this subset". There are three reasons for the choice of this subset: One reason is the belief, that this subset covers all but pathological cases. The other reason is that MHS products which keep to the lowest level of the international MHS profiles would not be able to use more than this subset at a gateway. Finally, a third reason is that this subset deals with the very part of RFC-987 that definitely needs international cooperation, namely the use of the RFC-987 Conversion Tables. From hagens Mon Nov 26 17:42:12 1990 Message-Id: <9011262342.AA09296@janeb.cs.wisc.edu> Received: from localhost by janeb.cs.wisc.edu; Mon, 26 Nov 90 17:42:12 -0600 To: ietf-osi-x400 Subject: DNS paper Date: Mon, 26 Nov 90 17:42:11 CST From: hagens For those of you without FTP access, here is an ascii version of the paper. Draft December 1990 Draft Proposal for the use of the Internet DNS to maintain RFC 987/RFC 1148 Address Mapping Tables Bruce Cole (cole@cs.wisc.edu) Robert Hagens (hagens@cs.wisc.edu) $Revision: 1.5 $ 1. Introduction RFC987 describes a set of mappings between the X.400 (1984) series of protocols and the RFC822 mail protocol, or protocols derived from RFC822. That document addresses conversion of services, addresses, message envelopes, and message bodies between the two mail systems. This draft is concerned with one aspect of RFC987; the mechanism for mapping between X.400 O/R addresses and RFC822 domain names. As described in Appendix F of RFC987, imple- mentation of the mappings requires a database which maps between X.400 O/R addresses and RFC822 addresses. A possi- ble mechanism for use of the internet DNS to store, retrieve and maintain these mappings is proposed. This mechanism is of potential use to internet hosts acting as X.400/RFC822 gateways. 1.1. Definitions + domain-name text encoding of a domain name + Internet DNS encoding of a domain name, as defined in RFC 1035, section 3.3 + owner-name The name of a particular node in the DNS namespace to which one or more resource records belong. Also known as the name field of a DNS resource record. + label A set of octets representing a domain name component, as introduced in RFC1035. (A label consists of a one octet length field followed by that number of octets.) Here, the allowable values for label octets are extended to include all legal IA5 characters. + dmn-orname text encoding of an O/R address represented by a series of labels, and terminated with a label with zero Cole&Hagens [Page 1] Draft December 1990 length. This representation of X.400 O/R addresses allows storage and retrieval of O/R addresses by the Internet DNS without syntactical extensions to the DNS. 2. Motivation Implementations of RFC987 gateways require that a data- base store address mapping information for X.400 and RFC822. This information must be disseminated to all RFC987 gate- ways. In the internet community, the DNS has proven to be a practical means for providing a distributed nameservice. Advantages of using a DNS based system over a table based approach for mapping between O/R addresses and domain names are: 1. It avoids fetching and storing of entire mapping tables by every host that wishes to implement RFC987. 2. Modifications to the DNS based mapping information can be made available in a more timely manner than with a table driven approach. 3. Table management is not necessarily required for DNS-based RFC987 gateways. 4. One can determine the mappings in use by a remote gateway by querying the DNS (remote debugging). 3. Proposed Resource Records Using RFC987's assumption of an asymmetric mapping between X.400 and RFC822 addresses, two separate relations are required to store the mapping database. We propose two new DNS resource record types, TO-X400 and TO-822, which are to be used to translate between X.400 and RFC822 addresses. The owner-name field of the new resource records can be thought of as keys used to reference the RFC987 mapping data. The data format and meaning of these new resource records is as follows: TO-822 (resource record type 20, decimal) The TO-822 RR is used during the mapping of an X.400 O/R addresses to an RFC 822 address. Specifically, the TO-822 RR is used to map an X.400 O/R addresses (not including the personal name field) to a domain-name. The TO-822 RR is retrieved by searching the DNS with an owner-name that represents an X.400 O/R address in dmn-orname syntax. The domain-name that is returned is used to construct the complete 822 user address. Cole&Hagens [Page 2] Draft December 1990 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | WILDCARD-COUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / DOMAIN-NAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ TO-X400 (resource record type 21, decimal) The TO-X400 RR is used during the mapping of an RFC 822 address to an X.400 O/R addresses. Specifically, the TO-X400 RR is used to map a domain-name into a partial O/R address. The TO-X400 RR is retrieved by searching the DNS with an owner-name that represents an RFC 822 domain-name. The dmn-orname that is returned is used to construct a partial O/R address. +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | WILDCARD-COUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / DMN-ORNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ WILDCARD-COUNT A 16 bit integer. For wildcard resource records, the value specified here should represent a count of the number of labels in the fully qualified owner-name, excluding the wildcard label. Otherwise, this field should be zero. This field can be used by resolvers to determine the number of labels matched when the received resource record was derived from a wildcard resource record. DOMAIN-NAME A . DMN-ORNAME A dmn-orname. 4. Storage of TO-822 and TO-X400 Records in the DNS The RFC987 mapping information is stored in resource records located in nodes of the the DNS tree. The resource record associated with a particular node is identified by the concatenation of labels encountered while traversing the tree to that node. As defined above, a TO-822 record is Cole&Hagens [Page 3] Draft December 1990 identified by an X.400 O/R address in dmn-orname syntax; a TO-X400 record is identified by an RFC-822 domain name. The TO-X400 records will occupy a new sub-tree. This new sub-tree will be rooted under a new top level domain "ORMAP". Since the TO-X400 records are identified by domain names, they should be stored in the appropriate locations of the existent tree of domain names. However, during the experimental phase (defined below), the TO-X400 records will be stored under the ORMAP top level domain. 4.1. Construction of a dmn-orname The dmn-orname information associated with TO-X400 and TO-822 resource records does not represent a full O/R address. It is a template which specifies the fields of the O/R address that are used by the mapping algorithm. A sub- set of the possible X.400 O/R attributes are used when per- forming conversions between RFC822 and X.400 O/R addresses. The attribute names allowed in a dmn-orname, listed in des- cending order of significance are: Country ADMD PRMD Organization Organizational Unit When an O/R address is written in dmn-orname syntax, the attributes are ordered from left to right in ascending order of significance. O/R attribute names not listed in the above table (such as the surname attribute) do not appear in dmn-ornames used by the mapping procedure. When constructing a dmn-orname from an O/R address, missing O/R attributes are handled in a special way. If the missing O/R attribute is omitted from the dmn-orname, no other attributes of less significance may be included. It is envisioned that the need may arise to construct a dmn-orname with a missing O/R attribute and include other attributes of less significance. In this case, the absent attribute is included in the dmn-orname with the special encoding "-". Note: a period "." may be placed within a label. This allows attributes to contain the period character. Software that parses these dmn-ornames must recognize the "\" (backslash) character as an escape character (e.g., teledir.funny\.name). Cole&Hagens [Page 4] Draft December 1990 4.1.1. Example The following example show the construction of a dmn- orname. /C=no/ADMD=telemax/O=teledir/ -> teledir.-.telemax.no.ormap /C=no/ADMD=telemax/PRMD=teledir/ -> teledir.telemax.no.ormap /C=no/ADMD=[]/PRMD=teledir/ -> teledir.[].no.ormap /C=no/PRMD=telemax/O=teledir/ -> teledir.telemax.-.no.ormap /C=no/PRMD=telemax/OU=teledir/ -> teledir.-.telemax.-.no.ormap where "[]" represents a blank. The absent attribute encoding is unpleasant. However, one should note that this form of the address will never be visible to the user. It is only used during communication between a 987 gateway and the DNS. We will discourage the creation of a management domain named "-". 4.2. Wildcards Dmn-ornames and domain-names are used as the lookup keys to retrieve RFC987 mapping information from the DNS. A non-existent domain response from the nameserver indicates that there is no RFC987 mapping information in the DNS for the given key, and the DNS search is complete. A non-error response also completes the DNS search. Wildcard resource records can be used to allow multiple keys to map to one node in the DNS namespace. (See also RFC1034, section 4.3.3, wildcards.) If the returned resource record contains a non-zero WILDCARD-COUNT field, then the longest possible match of the supplied lookup key does not include all components of that key. For a lookup key of M components and a WILDCARD-COUNT field with value N, a non-zero value for N indicates that the leftmost M-N components of the lookup key were not explicitly matched. Assumptions are made as to the mapping of the unmatched components. There are two cases: 1) RFC822->X.400 (domain-name -> dmn-orname) Map all remaining domain-name components to additional O/R attribute/value pairs. The next attribute assigned corresponds to the attribute of next lower priority Cole&Hagens [Page 5] Draft December 1990 than the lowest attribute type already assigned. The new attribute is assigned a value which is the same as the most significant unmapped domain-name component. If the last assigned attribute type was an OU (organi- zational unit), then any additional attribute assign- ments will be to OUs, with less significant attribute- value pairs written to the left of other attribute- values. Order and significance of domain-name com- ponents are preserved by this scheme. 2) X.400->RFC822 (dmn-orname -> domain-name) Of the remaining dmn-orname components, only those which correspond to attributes at least as significant as the OU attribute type are mapped. The attribute values from these components are added to the domain- name returned by the DNS lookup, and are mapped in the same order as they appear in the dmn-orname. Those attributes less significant than the OU attribute are used in the construction of the left hand side of the RFC822 address. The translation of the left hand side of the 822 address is specified by RFC987. 4.3. Example Assume DNS is populated with the following wildcard resource record: *.CS.UW-MADISON.XNREN.[].US.ORMAP IN TO-822 6 cs.wisc.edu Given the O/R address /C=US/ADMD=[]/PRMD=XNREN/O=UW-MADISON/OU=CS/OU=DIP/S=doe/ determine the corresponding RFC822 domain name. Step 1 The address is rewritten in dmn-orname syntax as: DIP.CS.UW-MADISON.XNREN.[].US.ORMAP The /S=doe/ attribute value pair is dropped since it is less significant than an OU attribute. The attribute order is rewritten according to the dmn-orname restric- tions (see section 4.1). Step 2 Perform the DNS lookup: DIP.CS.UW-MADISON.XNREN.[].US.ORMAP The nameserver returns the domain-name "cs.wisc.edu" and a wildcard-count of 5. Cole&Hagens [Page 6] Draft December 1990 Step 3 Since the wildcard-count field is non-zero, the nameserver response indicates that the dmn-orname com- ponent "DIP" was not explicitly matched. The unmapped attribute value "DIP" is prepended to the domain-name returned by the DNS lookup to produce the domain-name "dip.cs.wisc.edu". 4.4. Error Recovery RFC987 specifies that translation from one address space to another may occur in 2 ways. The above method of translation (lookup from the mapping database) is used when sub-trees of the different name spaces are associated via mapping information. The fall back method of translation (encoding in the other address space's format) is used when table lookup fails. However, in this case, the translation is less sophisticated. The fall back method amounts to encoding the address in the other system's format. RFC987 specifies default rules that may be used to perform this encoding. These rules specify the manner in which an RFC822 address may be encoded in X.400, and vice versa, by means of domain defined attributes. This fall back method of transla- tion is referred to as "default translation". A query of the DNS can result in one of the following response codes. + Ok No error condition. + Format error The name server was unable to interpret the query. + Server failure The name server was unable to process this query due to a problem with the name server. + Name Error Meaningful only for responses from an authoritative name server, this code signifies that the domain name referenced in the query does not exist. + Not Implemented The name server does not support the requested kind of query. + Refused The name server refuses to perform the specified opera- tion for policy reasons. For example, a name server may not wish to provide the information to the particu- lar requester, or a name server may not wish to perform a particular operation (e.g., zone transfer). This code Cole&Hagens [Page 7] Draft December 1990 may also be received if the nameserver is down (i.e., cannot connect). After receiving a response code from the server, the gateway software can take one of the following actions. + Proceed (P) Use the result of the DNS query to continue the address mapping process. + Default (D) Use the default translation and continue the mapping process. + Abort (A) Abort the mapping process because the mapping is impos- sible, or the default process is likely to lead to an error. + Retry (R) Reschedule the DNS query for a later date (i.e., assume that the response is transient). When a retry action is taken, the entire message is delayed for a period of time. When the message is first delayed, a "retry counter" is attached to the message. If the retry action is taken a subsequent time, the retry counter is incremented. When the retry counter reaches the "max- imum retry threshold", a "timeout" event is generated. Note: the "maximum retry threshold" is not related to the bind MAXRETRIES parameter. The following state table describes the appropriate action for the mapping algorithm based upon the type of address being mapped and the DNS response code. For the complete- ness, two additional DNS response codes are defined. + Other This covers any other value for the DNS response code field. + Timeout This event is generated when a message has been retried more times than the "maximum retry threshold" allows. The generation of this event prevents a message from being retried indefinitely. The state table contains two axis. The vertical axis is indexed by the type of address that is being matched. Three types are defined. From = 822-P1 return address <-> P1.UMPDUEnvelope.originator Rcpt = 822-P1 recipient <-> P1.RecipientInfo Other = Any other address found in the 822 or P2 header Cole&Hagens [Page 8] Draft December 1990 The horizontal axis is indexed by DNS response code. The same state table is used for both directions. Address Ok Format Server Name Not Refused Other Timeout Type Error Failure Error Impl. From P A| R D A| R| A| D Rcpt P A+ R A+ A+ R+ A| A+ Other P D D D D D A| D |) The message is not delivered. +) The recipient in question is not served. 4.5. Constants When a query is delayed, it shall not be retried for at least minutes. The maximum retry threshold shall be set to . 5. Administration of mapping information Not all RFC987 gateways will be able to use the inter- net DNS to map between O/R addresses and RFC822 domain names. Hosts without access to the DNS are expected to obtain full mapping tables (in RFC987 Appendix F format) from a master table. Hosts with DNS access should be able to obtain full mapping information from the DNS namespace. This implies that there will be two separate copies of the mapping database, one in table form, and the other within the internet DNS namespace. The master copy of the mapping database will be the copy stored in the DNS namespace (see below). 5.1. Partitioning the mapping database Name servers are the repositories of information that make up the domain database. The database is divided up into sections called zones, which are distributed among the name servers [RFC 1034]. All TO-X400 and TO-822 records will be stored in DNS zones. The authoritative information for any particular zone may be delegated to any nameserver supporting the TO- X400 and TO-822 resource records. The root nameservers for the TO-X400 and TO-822 information delegate zones to the authoritative nameservers, and assume authority for those sections of the DNS tree that have not been delegated. Cole&Hagens [Page 9] Draft December 1990 The delegation of authority for TO-X400 and TO-822 records will begin at the management domain level. In the general case, each X.400 management domain will be responsi- ble for operating a nameserver that is authoritative for resource records pertinent to addresses within the manage- ment domain. In reality, this delegation breaks down into two subcases that are discussed below. In the following sec- tions "DNS-connected" refers to an entity that has direct access to the Internet DNS system. 5.1.1. Responsibilities of DNS-connected management domains The management domain service manager must operate at least one authoritative nameserver for pieces of the DNS tree pertinent to members of the management domain. The management domain service manager may update the nameserver database at any time. 5.1.2. Responsibilities of isolated management domains The management domain service manager must produce a tabular form of the mapping tables. These tables must be submitted to the mapping table coordination team according to the rules set forth by the coordination team. The management domain service manager will periodically receive a tabular form of the complete mapping database from the mapping table coordination team. 5.2. The mapping table coordination team (MTCT) This MTCT has three responsibilities: + Operate nameservers The MTCT is responsible for operating authoritative nameservers for resource records pertinent to isolated management domains. + Define submission rules The MTCT is responsible for defining the rules for sub- mission of mapping information by isolated management domains. + Generation of the tabular version The MTCT is responsible for generating the table form of the mappings and transmitting it to every isolated management domain. Cole&Hagens [Page 10] Draft December 1990 5.3. Transition Plan The mapping tables are in use by gateways today. The transition to using the DNS for the storage of mapping information must not interrupt the operational gateways. The transition to using the DNS will occur in two phases. 5.3.1. Experimental Phase During the experimental phase, the master copy of the mapping information will be the table form. The experimental phase will demonstrate the operational feasibility of the use of the DNS. A single site (the XNREN project team at the University of Wisconsin) will operate the authoritative nameserver for the entire "ORMAP" domain, (e.g., this site will load the entire mapping database into its nameserver). The XNREN project will request that a small number of MTAs within the project convert their mapping software to use the DNS. At the end of this phase, the XNREN project team will delegate authority for a small number of management domains to volunteer management domain managers. 5.3.2. Transition Phase During the transition phase, the MTCT will be defined and the operation of the authoritative nameservers will be moved from the XNREN project to the MTCT. The exact specifi- cation of the MTCT is beyond the scope of this document. Currently, the best model for the MTCT is the RARE MHS Project Team. However, if the operational responsibility of the R&D MHS Service is moved from RARE to COSINE, then an appropriate body within COSINE should be developed. In addition, it may be prudent to distribute the opera- tional responsibilities of the MTCT into several groups (i.e., COSINE-MTCT, North America-MTCT and Asia-MTCT). At the end of this phase, all DNS-connected management domains will operate authoritative nameservers. The master copy of the mapping information will be distributed between the management domain nameservers and the MTCT. 5.4. Generation of the table form of the mappings Periodically, the entire contents of all TO-822 and TO-X400 RRs in the DNS will be obtained in order to produce the table form of the mappings. Cole&Hagens [Page 11] Draft December 1990 This operation will utilize the zone transfer mechan- ism. The operation assumes that the results of the previous generation are available to be used as default information if the new information cannot be obtained. The following algorithm defines the manner in which the TO-822 records will be retrieved. A similar mechanism can be used to retrieve the TO-X400 RRs. Step 1 Initialize the results file to the results of the pre- vious generation. Initialize the dmn-orname pending list Step 2 Initiate an AXFR request to the authoritative nameserver for the domain name "ORMAP.". Step 3 For each record: if type is NS and the owner-name is a subdomain of the AXFR request name, add the owner-name to pending list if type is TO-822, save to results file (replacing the existing information, if present. Step 4 If the pending list is empty, stop. Otherwise, take the next dmn-orname from the pending list, initiate an AXFR request to its authoritative nameserver, and goto step 3. It is possible that sites will not allow a zone transfer. This must be discouraged. Perhaps if the TO-822 and TO-X400 RRs are placed into their own class (ISO), and the zone transfer granularity is increased to be class specific, this response can be avoided. The algorithm will loop infinitely if the dmn-orname pending list is not empty and each zone described by the dmn-orname pending list is unreachable. This condition must be detected. When detected, the algorithm should be ter- minated. The information from the previous generation will be used for the non-reachable zones. Emperical evidence suggests that this process may take several days to complete. Thus, the frequency should be low (every months). 6. Which address class to use? It can be convenient for these records to be stored in the same DNS zones as other resource record types, such as Cole&Hagens [Page 12] Draft December 1990 internet address records. It seems reasonable to store these records in the internet address class since the TO- X400 records refer to owner-names which are already present in the internet address class. In our initial implementa- tion of these new DNS records, the records are assigned to the internet address class. However, these records should probably be placed in a new address class such as an ISO address class. This would allow the zones containing TO-X400 and TO-822 records to be delegated independently of already existing DNS zones. This could be particularly useful if it is desired to keep the root nameservers for this mapping data separate from the current internet root nameservers. If these nameservers are not separate, then it is expected that the existing root nameservers will be given the new burden of acting as proxy nameservers. In addition, the resolvers can be modified to make the zone transfer denial to be class specific. Note that the scope of wildcard resource records are bounded by the presence of resource records that occupy sub- domains of the wildcard record. If the scope of wildcard records is affected by resource records from different address classes, then wildcard records can be affected in non-intuitive ways. For example the records: *.B.A. IN MX 0 B.A. C.B.A. HS TXT "data" would cause internet address class MX queries for any domain name ending in C.B.A to not match the above wildcard record. If a separate address class is to be used for the TO-X400 and TO-822 records, it is preferable for wildcard records to not be affected by resource records from other address classes. This is considered a bug, not a feature of the current DNS implementations. 7. Summary Internet DNS nameservers wishing to provide this map- ping information need to be modified to support two new resource record types, and possibly a new address class. Usage of these extensions provide RFC987 gateways with the advantages listed in the motivation section. These advantages are important for the administration of RFC987 gateways. 8. References [CCITT] CCITT SG 5/VII, "Recommendation X.400," Message Handling Systems: System Model - Service Elements, October 1984. Cole&Hagens [Page 13] Draft December 1990 [PP] Kille, S., "PP Installation and Operation", Volume 1, December 1989. [RFC 974] Partridge, C., "Mail routing and the domain system", RFC 974, CSNET CIC BBN Labs, January 1986. [RFC 987] Kille, S., "Mapping Between X.400 and RFC 822", UK Academic Community Report (MG.19) / RFC 987, June 1986. [RFC 1026] Kille, S., "Addendum to RFC 987", UK Academic Community Report (MG.23) / RFC 1026, August 1987. [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, USC/Information Sciences Institute, November 1987. [RFC 1035] Mockapetris, P., "Domain names - Implementation and Specification", RFC 1035, USC/Information Sciences Institute, November 1987. [WG] OSI-X.400 Working Group Meeting, October 1989. Cole&Hagens [Page 14] From huitema@jerry.inria.fr Tue Nov 27 02:35:52 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Tue, 27 Nov 90 02:35:52 -0600 Received: from jerry.inria.fr by cs.wisc.edu; Tue, 27 Nov 90 02:35:33 -0600 Received: by jerry.inria.fr (5.61+++/IDA-1.2.8) id AA08108; Tue, 27 Nov 90 09:37:24 +0100 Message-Id: <9011270837.AA08108@jerry.inria.fr> To: hagens Cc: ietf-osi-x400 Subject: Re: DNS paper In-Reply-To: Your message of Mon, 26 Nov 90 17:42:11 -0600. <9011262342.AA09296@janeb.cs.wisc.edu> Date: Tue, 27 Nov 90 09:37:15 +0100 From: Christian Huitema Rob, I just read your "mapping" proposal, and it seem now quite complete and workable. I have however a philosophical comment on your section on "missing attributes", regarding the handling of blank attributes vs missing attributes. In fact, this comment derives from the matching rules encouraged by the CEN-CENELEC and NIST profiles which are approximately equal to the "case ignore string" matching rules defined in X.500: * leading blanks are ignored, * trailing blanks are ignored, * multiple embedded blanks are equal to one single blank, * lower and upper case do match. This rules should be taken into account while building the "name tokens" for the DNS OR-NAME. For example, noting blank as "_", the string "ADMD=__Gold__400__" should produce the name token "gold_400". A consequence is indeed that the empty string "" is "equal" to the blank strings "_", "__" or "___". In fact, this is the very reason for the original selection of the "single blank" escape in the profiles, which later made its way in the standards. As a consequence, your document should: * explain the "canonisation" rules that should be followed prior to producing a mapping to "dns or-name", * state that when a field is missing, or empty, or blank, then the corresponding token should be a single hyphen "-", Note that this canonisation rules are only necessary for the building of the key to the "TO-822" table. The managers should be able to select whatever "preferred value" they see fit in the content of the "TO-X400" RR. Best regards Christian Huitema From S.Kille@cs.ucl.ac.uk Wed Nov 28 07:26:10 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 28 Nov 90 07:26:10 -0600 Received: from CS.UCL.AC.UK by cs.wisc.edu; Wed, 28 Nov 90 07:26:03 -0600 Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <21120-0@bells.cs.ucl.ac.uk>; Wed, 28 Nov 1990 13:25:12 +0000 To: hagens Cc: ietf-osi-x400 Subject: Re: Agenda for the IETF-OSI-X.400 WG meeting Phone: +44-71-380-7294 In-Reply-To: Your message of Mon, 26 Nov 90 17:38:40 -0600. <9011262338.AA09279@janeb.cs.wisc.edu> Date: Wed, 28 Nov 90 13:25:10 +0000 Message-Id: <1712.659798710@UK.AC.UCL.CS> From: Steve Kille I think that it would be useful to address (probably in the afternoon session): Goals - why are we trying to deploy X.400 on the Internet. I think that explictly discussing this will help the other items. Use of X.400(88) vs X.400(84). I believe that the Internet should be making 88 the target for all internal use. Whichever route is chosen, the choice should be explicit. You might discuss a paper on 88 -> 84 downgrading, which I will be sending to ifip-gtwy later today. Steve From S.Kille@cs.ucl.ac.uk Wed Nov 28 07:55:23 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 28 Nov 90 07:55:23 -0600 Received: from CS.UCL.AC.UK by cs.wisc.edu; Wed, 28 Nov 90 07:55:15 -0600 Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <22211-0@bells.cs.ucl.ac.uk>; Wed, 28 Nov 1990 13:54:15 +0000 To: hagens Cc: ietf-osi-x400 Subject: Re: DNS paper Phone: +44-71-380-7294 In-Reply-To: Your message of Mon, 26 Nov 90 17:42:11 -0600. <9011262342.AA09296@janeb.cs.wisc.edu> Date: Wed, 28 Nov 90 13:54:11 +0000 Message-Id: <1824.659800451@UK.AC.UCL.CS> From: Steve Kille I'll briefly make a few comments on the paper. I'll expand on this in Boulder. 1) You should also mention RFC 1148. It should be clear that you are implementing the funtion described there, and simply giving DNS access to the information. 2) dmn-orname format - you have used the same name as in 1148 for a syntax. This is very confusing. Either use the same syntax or have a different name. - The Appendix F format (currently dmn-orname) and the one defined for your records should be the same. Everyone is going to get very confused otherwise. If the concensus is that the 1148 syntax is deficient, then it can be revised. - I would recommend that you move to use of the 1148 syntax, unless you have a good reason not to. Inventing yet another text representation for O/R Addresses should be justified. - The string "-" is not reserved, and if someone does creat an MD or O with this name, your approach will break (the 1148 syntax is general) 3) Location on DNS tree. You should probbaly put the TO-822 records in a private subtree (like ORMAP) to be symmetrical. 4) The transition plan should probably be in a seprate document. It should allow for a country by country switch from table mastering to DNS mastering. There should be no difficult in a final state where some parts of the world are table mastered and others DNS mastered. 5) There should be a clearer model of who will run servers after the initial phase of everything being in the single DNS server at Wisconsin. Steve From S.Kille@cs.ucl.ac.uk Wed Nov 28 08:00:50 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 28 Nov 90 08:00:50 -0600 Received: from CS.UCL.AC.UK by cs.wisc.edu; Wed, 28 Nov 90 08:00:40 -0600 Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <22502-0@bells.cs.ucl.ac.uk>; Wed, 28 Nov 1990 13:59:24 +0000 To: Christian Huitema Cc: hagens, ietf-osi-x400 Subject: Re: DNS paper Phone: +44-71-380-7294 In-Reply-To: Your message of Tue, 27 Nov 90 09:37:15 +0100. <9011270837.AA08108@jerry.inria.fr> Date: Wed, 28 Nov 90 13:59:22 +0000 Message-Id: <1843.659800762@UK.AC.UCL.CS> From: Steve Kille I think that your comments are sensible. I note that these should be incorporated into 1148. I hope to revise this not to far down the road, and will deal with this. Steve From lazear@gateway.mitre.org Wed Nov 28 08:12:45 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 28 Nov 90 08:12:45 -0600 Received: from gateway.mitre.org by cs.wisc.edu; Wed, 28 Nov 90 08:12:40 -0600 Return-Path: Received: by gateway.mitre.org (5.61/SMI-2.2) id AA12079; Wed, 28 Nov 90 09:12:31 -0500 Message-Id: <9011281412.AA12079@gateway.mitre.org> To: ietf-osi-x400, gomberg@gateway.mitre.org Cc: lazear@gateway.mitre.org Subject: Re: Re X400 source route Date: Wed, 28 Nov 90 09:12:06 -0500 From: lazear@gateway.mitre.org Stef, I do understand the differences between names, addresses, and routes. Perhaps the following will help us get into sync. As far as deciding which gateway to use for mail, I think the realm notion is on the same level as an MX record. That is, you can look up a realm and get a gateway address, just like you can look up a host name and get a gateway address. The resulting IP address can be used to send the mail to the gateway. In both cases, the user did not specify a route, but the mailer used the info from the user to generate a next hop. I do not consider either to be source routing. On the OSI side, if a DDA is used, that can trigger a lookup of the gateway associated with the DDA in question. This lookup can be hidden from the sending user just like the MX. The advantage that the realm notion has is that it is well above the host level in abstraction. Thus, the number of gateways to that realm that need to be registered is orders of magnitude less. Dealing with objects at a higher level is usually better. On another topic, the use of ADMD= means that someone will have to look up in a list of PRMD-vs-ADMDs and pick an ADMD for delivery. This list can be offered as a commericial service to those who wish to pay for the extra lookup. Those who don't want to pay extra can use the explicit ADMD name. I wonder how long the extra charges will be tolerated by end-users? Why not let the marketplace decide, instead of forcing everyone to use the list? Is specifying the ADMD any more source routing than specifying the ORG? Pointing a message to a company's MTA by specifying ORG doesn't seem like source routing to me. Dave Gomberg (a MITRE colleague of mine) will be submitting a contribution to ANSI on the handling of blank ADMD that reflects the thoughts expressed above. We invite your review of the document. Walt From lazear@gateway.mitre.org Wed Nov 28 09:39:50 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 28 Nov 90 09:39:50 -0600 Received: from gateway.mitre.org by cs.wisc.edu; Wed, 28 Nov 90 09:39:42 -0600 Return-Path: Received: by gateway.mitre.org (5.61/SMI-2.2) id AA13475; Wed, 28 Nov 90 10:39:35 -0500 Message-Id: <9011281539.AA13475@gateway.mitre.org> Cc: lazear@gateway.mitre.org, hagens, ietf-osi-x400, lazear@dockside.mitre.org, gomberg@gateway.mitre.org, epg@gateway.mitre.org Subject: Re: RFC 987 Procedures Date: Wed, 28 Nov 90 10:39:04 -0500 From: lazear@gateway.mitre.org The topic of restricted character set in an X.400 DDA has come up and bears airing. The DDA value can only contain printable-string characters. This is a set of alphas, digits, and some punctuation marks. It is not full ASCII, not European, not Kanji, but a subset. It seems that the problem of representing an at-sign (such as found in Internet mail addresses) and exclamation points (such as found in UUCP mail addresses) is only a symptom of the more general problem of how does one mail system represent another mail system's addressee if the two mail systems don't use the same character set? It also seems that the only solutions so far are bilateral between character sets. Multiple ASCII characters to represent Cyrillic, Kanji, European. Multiple printable-string characters to represent ASCII. I bring this up because it's a general problem (not just a reason why DDA's aren't appropriate for holding Internet addresses), and deserves a more global treatment. It's not clear where this knowledge of a foreign mail system's character set ought to be held and applied. Unfortunately, it seems it might need application at the user interface level, which disperses the problem right to the end-user. Anyone else have thoughts on this problem? Walt ps - I certainly don't intend to start flames about why 1990 technology is restricted to the few characters in the printable-string list :-) It's a done deal, we have to live with it, and it represents a larger class of problem anyway. From Alf.Hansen@pilot.cs.wisc.edu Thu Nov 29 15:20:00 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Thu, 29 Nov 90 15:20:00 -0600 Received: from csl5.cs.wisc.edu by cs.wisc.edu; Thu, 29 Nov 90 15:19:52 -0600 X400-Received: by mta pilot.cs.wisc.edu in /PRMD=xnren/ADMD= /C=us/; Relayed; Thu, 29 Nov 1990 15:19:27 +0000 X400-Received: by /PRMD=xnren/ADMD= /C=us/; Relayed; Thu, 29 Nov 1990 14:19:14 +0000 Date: Thu, 29 Nov 1990 15:19:14 -0500 X400-Originator: Alf.Hansen@pilot.cs.wisc.edu X400-Mts-Identifier: [/PRMD=xnren/ADMD= /C=us/;hansen659913554.28hermit.cs.uw] X400-Content-Type: P2-1984 (2) Content-Identifier: 901129151910 From: Alf Hansen Message-Id: <901129151910*@MHS> To: ietf-osi-x400 Subject: Comments to the DNS proposal. Rob, I have no comments to the DNS technical things, because I am no DNS expert. If we follow Steves advise to take out the transition plan as a separate document, the DNS proposal should at least make a pointer to the transition document. I think your transition plan is good. I have some questions, probably because I don't know all the terms, but I think you have covered the basic aspects. Is the proposal sent to the European lists for comments, too? Steve says that there should be a cleare model of who will run the servers after the initial phase. To describe this in more detail needs more time because administrative problemes are not so easy to solve as the technical ones... I have some sympathy with Steves view, bacause if this is not clear from the beginning, we may end up with something that will never work in practice. One way to solve it could be to formulate the RFC in such a way that it is dependent on a future cooperative decision made by a well defined set of actors. These actors could be difficult to identify at this stage. Therefore I like the model with a COSINE-, North American- Asian-, Other regions-MTCT, with the requirement that these MTCTs MUST cooperate. Best regards, Alf H. From huitema@jerry.inria.fr Fri Nov 30 13:14:48 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Fri, 30 Nov 90 13:14:48 -0600 Received: from corton.inria.fr by cs.wisc.edu; Fri, 30 Nov 90 13:14:20 -0600 Received: from [138.96.8.25] by corton.inria.fr (5.65+/90.0.9) via Fnet-EUnet id AA01566; Fri, 30 Nov 90 19:10:50 +0100 (MET) Received: by jerry.inria.fr (5.61+++/IDA-1.2.8) id AA00430; Thu, 29 Nov 90 10:19:28 +0100 Message-Id: <9011290919.AA00430@jerry.inria.fr> To: Steve Kille Cc: hagens, ietf-osi-x400 Subject: Re: DNS paper In-Reply-To: Your message of Wed, 28 Nov 90 13:54:11 +0000. <1824.659800451@UK.AC.UCL.CS> Date: Thu, 29 Nov 90 10:19:21 +0100 From: Christian Huitema Steve, In a recent message, you object to the ORName representation specified by Rob: > - The Appendix F format (currently dmn-orname) and the one defined > for your records should be the same. Everyone is going to get > very confused otherwise. If the concensus is that the 1148 > syntax is deficient, then it can be revised. > - I would recommend that you move to use of the 1148 syntax, unless > you have a good reason not to. Inventing yet another text > representation for O/R Addresses should be justified. I happen to disagree with your comment, and think that the 1148 syntax is both somewhat of an overkill + leaves open some room for mistakes. Generally speaking: * we need a positional notation, * hence we dont need keywords, * and by using keywords as in 1148 we encourage a non-positional notation. We do need a positional notation because we have to map "the first levels of the naming tree". For example, we have to specify that a TO-822 RR matches "four levels of name"; this means in everybody's mind that it matches "C/A/P/O", and that if OU are present they should be appended as name tokens. I what we have presented to the mapping function is a string of the form: , we only have to do a very basic text processing to replace the upper levels of the tree and obtain: It is not clear to me that the mapping would have been any easier if you had presented: In fact, I fear that by doing so you will meet problems with the notation of missing attributes (O$@.PRMD$ppp.ADMD$@.C$cc) and with the ordering of OUs -- someone is going to insist for OU1$, OU2$, etc. Regarding the problem of missing attributes, I agree with you that the "-" symbol is not well chosen: a character that does not belong to the "PrintableString" subset, like "$" or "#", would be a better choice. In fact, I would tend to support an even more radical view and propose that missing attributes are simply omitted when we prepare the key of the "TO-822" record. For example, (1148 notation for missing O) would yeld: and would be mapped exactly as if we had encountered: Note that this is coherent with Ruediger's "minimum profile", and copes well with some very common user mistakes, reducing the number of errors that a gateway has to handle. Also, it reduces the size of the "ORMAP" tree, as one does not have to create to domain names: one for "PRMD" and one for "O$@.PRMD" in the case of "missing org" mappings. In the same line, an even more agressive position would be to consider, when building the "ORMAP" domain name, that when the ORG name is equal to the PRMD name, then it should be ignored: would all map to the same domain: provided that the TO-822 RR <3,same-mapping.edu> is defined for <*.same-org-name.aaa.cc.ORMAP> To give a brief rationale: * Ignoring empty ORGs eases the task of half of ".fr" and all of ".de", * Ignoring empty ORGs eases the task of half of ".fr" and all of ".ch", and having a simple solution will ease the task of many others... Indeed, the "TO-X400" RR must contain an exact mapping, with an unambiguous notation for missing or redundant fields. Christian Huitema From stef@odin.nma.com Mon Dec 3 00:48:02 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Mon, 3 Dec 90 00:48:02 -0600 Received: from NRTC.NORTHROP.COM by cs.wisc.edu; Mon, 3 Dec 90 00:47:50 -0600 Received: from nma.com by nrtc.nrtc.northrop.com id af23660; 2 Dec 90 22:46 PST Received: from odin.nma.com by nma.com id aa00323; 2 Dec 90 19:22 PST Received: from localhost by odin.nma.com (4.1/SMI-4.1(NMA)) id AA02144; Sun, 2 Dec 90 20:36:00 PST To: mhsig@ics.uci.edu, IFIP Gateway Task Group , MHSnews@ics.uci.edu, ietf-osi-x400 Cc: SG-D MHSMD Subcommittee Subject: US StudyGroupD MHSMD Subcomittee Meeting Announcement Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Sun, 02 Dec 90 20:35:59 PST Message-Id: <2143.660198959@odin.nma.com> Sender: stef@odin.nma.com ------- Forwarded Message From: arch2!rwj@lzga.attmail.COM To: Stef@nrtc.northrop.COM Date: Fri Nov 30 16:47:00 GMT 1990 Dear Friends, I am pleased to announce that the first official meeting of the MHS MD group will be held December 17 & 18 at the US State Department building in Washington DC. If you plan to attend you need to contact Mr Gary Fereo, Chairman of US Study Group D to arrange entry into the State Department building (phone # 202-647-2592). Attached you will find an agenda for the 2 day meeting and a proposed plan of work. As you will note, we ask that you come prepared to share any MHS Management Domain names in use today. If you are unable to attend you may send your information to either Stef or me, or Gary Fereno or anyone else that you know will be attending the meeting. We look forward to seeing you there. Regards, Dick Jesmajian, AT&T Bell Labs. Einar Steferud, NMA Acting Chairperson AGENDA Day 1: * Welcome and introduction of Participants * Review of Agenda * Introduction of Contributions (both old and new) * Review and Agree to a proposed plan of work for this meeting (see attached) * Commence work Day 2: * Nomination of Candidates for MHS-MD Officers * Continue Work * Election of Officers * Plans for next meeting * Any other new business * Closing remarks INITIAL PLAN OF WORK 1. Survey known Management Domain name values in use. INFORMATION AND CONTRIBUTIONS SOLICITED 2. Determine the semantic for (MHS): a. Name b. Address c. Routing 3. Develop a semantic for ADMD and PRMD Name values 4. Develop Qualitative Requirements for Name values used: a. Pragmatic constraints b. Syntax/encoding c. Intellectual property 5. Determine what's next ------- End of Forwarded Message From stef@odin.nma.com Mon Dec 3 00:42:56 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Mon, 3 Dec 90 00:42:56 -0600 Received: from NRTC.NORTHROP.COM by cs.wisc.edu; Mon, 3 Dec 90 00:42:47 -0600 Received: from nma.com by nrtc.nrtc.northrop.com id ab23660; 2 Dec 90 22:42 PST Received: from odin.nma.com by nma.com id aa00238; 2 Dec 90 16:54 PST Received: from localhost by odin.nma.com (4.1/SMI-4.1(NMA)) id AA01986; Sun, 2 Dec 90 18:08:00 PST To: lazear@gateway.mitre.org Cc: ietf-osi-x400, gomberg@gateway.mitre.org Subject: Re: Re X400 source route In-Reply-To: Your message of Wed, 28 Nov 90 09:12:06 -0500. <9011281412.AA12079@gateway.mitre.org> Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Sun, 02 Dec 90 18:07:59 PST Message-Id: <1985.660190079@odin.nma.com> Sender: stef@odin.nma.com Hello Walt -- I am just back from another week on the road, to explain why this is a delayed response. I see that you have not explained in your reply why X%Y@Z is different from "X.Y"@Z. You ask: > Is specifying the ADMD any more source routing than specifying the > ORG? Pointing a message to a company's MTA by specifying ORG doesn't > seem like source routing to me. Well, my reading is the the ADMD name inclusion in the X.400 Recommendations is in fact a violation of the separation of addresses and routes. The way the ADMD name is regularly treated is in terms of "requiring transfer through the named ADMD" which means that it is a source route, in fact, though it masqerades as a domain name. Then you say: > Dave Gomberg (a MITRE colleague of mine) will be submitting a > contribution to ANSI on the handling of blank ADMD that reflects the > thoughts expressed above. We invite your review of the document. I would like to see this contribution before we have to get into ANSI committee arguements about this issue. Also, we are starting up the US Study Group D MHSMD subcommittee to look into this same question, after we resolve the basic isues of ADMD and PRMD name registration in the US. Is this paper available? I will be sending the MHSMD meeting notice and charter to this list shortly. Best...\Stef From stef@nma.com Tue Dec 4 04:55:55 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Tue, 4 Dec 90 04:55:55 -0600 Received: from NRTC.NORTHROP.COM by cs.wisc.edu; Tue, 4 Dec 90 04:55:43 -0600 Received: from nma.com by nrtc.nrtc.northrop.com id ac29523; 4 Dec 90 1:38 PST Received: from localhost by nma.com id aa00607; 4 Dec 90 1:04 PST To: mhsig@ics.uci.edu, MHSnews@ics.uci.edu, IFIP Gateway Task Group , RARE WG1 , ietf-osi-x400, pem-dev@tis.com Subject: the MHS MD Charter Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Tue, 04 Dec 90 01:04:46 -0800 Message-Id: <605.660301486@nma> Sender: stef@nma.com This is the final approved version, and may be passed along to any interested party. Membership (as stated in the chater) is open to anyone doing business in the US with an interest in the issues, and meetings are open to any observer who wishes to attend. Meetings locations are set for the US Department of State in Washington, DC. Annexes to the Charter include some lists of topics and issues that may be addressed by the MHS MD subcommittee, in due course. The first meeting agenda is attached to the first meeting announcement in a separate message, along with contact information for notifying the US Dept of State that you plan to attend (if you do so plan). Best...\Stef ------- Forwarded Message From: rwj@arch2.att.COM To: Einar Stefferud Subject: the MHS MD Charter Date: Fri, 30 Nov 90 16:37 EST US Study Group D Subcommittee: Message Handling Systems Management Domains CHARTER This Charter was ratified by U.S. CCITT Study Group D on October 29, 1990. 1. Purpose This subcommittee is established to develop and propose registration, administration and assignment procedures for management domains with the purpose of maximizing domestic and international connectivity among Message Handling Systems (MHS) operating within the U.S. 2. Basis of Authority This subcommittee has been established by the U.S. CCITT Study Group D of the U.S. State Department and is answerable to it. The advice of the subcommittee is to be directed to the U.S. CCITT National Committee. 3. Scope The subcommittee will develop and propose U.S. X.400 MHS management domain name registration authority procedures. The procedures should apply to all MHS domains operating within the US. For purposes of this document, the term MD refers to Administration Management Domains (ADMD) and Private Management Domains (PRMD) as defined in CCITT's X.400 series of Recommendations. The subcommittee will develop guidelines and procedures to facilitate establishment of a reliable, interoperable U.S. MHS system which accommodates multiple MHS Management Domains and access to/from international services. The subcommittee will recommend inter-MHS management domain procedures for the use of registered names. The subcommittee will determine on-going activities appropriate to its purpose. Consideration will be given to existing practices in the use of MHS MD names, in the formulation of subcommittee recommendations. This subcommittee will establish criteria for identifying candidate registration agency (or agencies) and recommend potential candidate registrar(s). 4. Organization 4.1. Offices A. Terms of Office i. The term of each office in the Subcommittee for MHS Management Domains shall be for two (2) years except for the term of the first Chair which is for one (1) year. The Chair may be selected for one or more subsequent terms of two years but not to exceed two consecutive terms. The Vice-Chair is also eligible for nomination and selection for Chair. The Vice-Chair may also be selected for subsequent terms of two year duration but not to exceed two consecutive terms. B. Selection of Officers i. Officers shall be selected by consensus of the members attending the meeting at which selections appear on its agenda when the meeting notice is distributed. If such substantial agreement is not achieved, the Chairman of U.S. Study Group D shall designate such officer for a one or two year period per paragraph 4.1(A)(i) above. This designation may be appealed to the Chairman of the U.S. National Committee for the CCITT in the U.S. State Department. ii. Offices can only be held by representatives of Subcommittee members, as defined in section 4.2, paragraph A of this Charter, or their authorized agents. Officers are not restricted to the designated principal or alternate of a member. No member may hold more than one (1) office simultaneously. iii. A new officer shall be selected if one is unable to fulfill the duties of office for more than sixty (60) days. Furthermore, it is the responsibility of the officer to advise the Subcommittee in the event of difficulty in fulfilling the duties of his or her office. The Chair may appoint a substitute to temporarily represent him or her when the Vice Chair is unavailable to fulfill that substitute function. C. Leadership Offices i. Chair: The duties of the Chair are to call to order and preside over all meetings of the Subcommittee. ii. Vice-Chair: The duties of the Vice Chair are to (1) provide and distribute minutes of all meetings of the Subcommittee, (2) maintain an ongoing roster of the Subcommittee membership, and (3) temporarily assume the responsibilities of the Chair in the event that the Chair is unable to fulfill those duties. D. Liaison Responsibilities i. Liaisons shall be established with other groups as deemed appropriate by the Subcommittee. E. Subcommittee Role for US Study Group D i. The subcommittee shall provide technical advice to US Study Group D to address issues relevant to the subcommittee that should be considered at the international level by representatives of US Study Group D. 4.2 Membership A. Members Membership in the Subcommittee is open to any entity doing business in the U.S. which has a direct interest in the activities of the Subcommittee. B. Observers All other interested parties or organizations may also attend Subcommittee meetings but are not eligible to select the officers of the Subcommittee or to be nominated to those offices. 5. Operating Procedures 5.1. Decision Process All decisions of the Subcommittee shall be by consensus in accordance with normal U.S. National Committee procedures. US Study Group D reserves the right to modify or pass judgement on any deliverable of this subcommittee. 5.2 Meetings Meetings of the Subcommittee shall be held at least every six (6) months. In addition, the Subcommittee Chair or two (2) or more members of the Subcommittee may request a meeting as business requires. Notice of the meetings shall follow the rules prescribed for the operation of U.S. CCITT Study Groups. A proposed agenda for each subcommittee meeting shall be distributed to all members of the U.S. Study Group D interested in CCITT Study Group VII subject matter at least ten (10) days prior to the scheduled meeting. 5.3. Modifications to the Charter Additions, deletions and amendments to this Charter may be proposed at any time by this U.S. Study Group D Subcommittee and considered for approval by U.S. Study Group D. U.S. Department of State oversight applies in all matters related to CCITT preparatory groups such as U.S. Study Group D. ----------------- END OF CHARTER ------------------------------ ANNEX - 1 Proposed Topic List That May Be Considered By This Subcommittee This list is not considered a part of the Charter and is provided to the US study Group D and the Subcommittee for its consideration. 1. Registration Procedures for MHS Management Domain Names: a. Grandfather existing X.400 domain names, b. Uniqueness of ADMD and PRMD name space, c. Relation of the ISO Name Tree and the X.500 Directory. 2. Information sharing arrangements to facilitate a distributed national MHS service: a. Quality of Service vis-a-vis national MHS service, b. Legal aspects, e.g., examine liability exposure of MHS service providers, c. Rules for single space ADMD name, d. Settlement of disputes, e.g., through binding arbitration. 3. Establish a U.S. semantic of domain name for classification of ADMD and PRMD names. 4. Identify and recommend agencies to perform registration. 5. Utilize work already done to interconnect ADMD/PRMD domains. 6. Limitation of the scope to X.400 (1988 and beyond) systems and services. --------------- END OF ANNEX 1 ------------------------------- ANNEX - 2 Proposed Work Items for the Subcommittee 1. Registration Rules and Procedures a. Right to use of name, b. Binding of names to specific uses, c. Provision for access to and distribution of usage binding information to interested parties. 2. Syntax of MHS MD Names a. Assurance of Uniqueness, b. Use of "constructive" syntax. 3. Semantics of MHS MD Names. 4. Sharing of MD Interconnection Information. 5. Establish Criteria and Examine Liability Exposure for Candidate Registration Agencies. Identify and recommend agencies. ------------- END OF ANNEX 2 ---------------------------- ANNEX - 3 Proposed Schedule of Meetings 1. First meeting of Subcommittee December 17-18, 1990, at 10 AM, U.S. State Department, CCITT Study Group D facility. The local point of contact for this meeting is Mr. Gary Fereno. 2. General meeting plan for 1991 will be to meet before or after OSI Implementor's Workshops held at NIST. The Subcommittee will generally meet at the U.S. State Department facilities unless otherwise specified in the meeting announcements. The tentative dates are as follows: March 7-8, 1991 June 6-7, 1991 September 17-18, 1991 December 5-6, 1991 ------------- END OF ANNEX 3 ------------ ------- End of Forwarded Message To: cc: Subject: Reply-to: Stef@ics.uci.edu From: Einar Stefferud Fcc: +out Fcc: +out/log -------- From mdb@kosciusko.ESD.3Com.COM Fri Dec 7 12:05:20 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Fri, 7 Dec 90 12:05:20 -0600 Received: from bridge2.ESD.3Com.COM by cs.wisc.edu; Fri, 7 Dec 90 12:04:59 -0600 Received: from kosciusko.ESD.3Com.COM by bridge2.ESD.3Com.COM with SMTP id AA13332 (5.64+/IDA-1.3.4-901018 for ietf-osi-or@cs.wisc.edu); Fri, 7 Dec 90 10:04:37 -0800 Received: by kosciusko.ESD.3Com.COM id AA00866 (5.65+/IDA-1.4.1-901206 for ietf-osi-or@cs.wisc.edu); Fri, 7 Dec 90 10:04:26 -0800 Date: Fri, 7 Dec 90 10:04:26 -0800 Message-Id: <9012071804.AA00866@kosciusko.ESD.3Com.COM> To: ietf-osi-or From: "Mark D. Baushke" Sender: mdb@ESD.3Com.COM Organization: 3Com, 5400 Bayfront Plaza, Santa Clara, CA 95052-8145 Phone.......: (408) 764-5110 (Office); (415) 969-8328 (Home) Subject: RFC987 gateways and illegal RFC822 domainname characters [This message was also posted to comp.protocols.x400.gateway. Please excuse any duplication this may have caused. -- mdb] I apologize if this is not the appropriate forum for this messge. Please feel free to forward this posting to the appropriate list or to tell me where I should raise my concern. I am not normally involved with X.400, but I have been noticing a disturbing trend in how some X.400 address are mapped into RFC822 addresses. The trend is to take name components which contain spaces (eg, /O=Field Service/), and either map them into underscore (_) characters or actually leave them as spaces in the domain address. That is, the address was mapped into something like Joe.User@somewhere.Field_Service.that.company.country or in one case an non-repliable address for which the postmaster suggested an address like: Joe.User@somewhere."Field Service".that.company.country and noted that an underscore could be used for the space if my company could not use quotes in a domainname, but that the underscore form of the address would be going away soon. I have sent individual messages to the postmasters in charge of such gateways for their consideration. I hope that they choose to 'fix' their sites by converting to only legal characters in domainnames. Some gateways seem content to take either underscores (_) or dashes (-) in an RFC822 address and map them to spaces in the X.400 addresses. That direction of mapping is fine. It is a case of being liberal in whay you accept. You may ask why I believe it is technically 'illegal' to have either an underscore or a space in a domainname. It is because I do not see them in the set of characters permitted in a domainname as defined by the RFCs. What follows is fragments of what I believe to be the appropriate RFCs. If I have missed something, please feel free to point it out to me. In RFC 1123, | 2.1 Host Names and Numbers | | The syntax of a legal Internet host name was specified in RFC-952 | [DNS:4]. One aspect of host name syntax is hereby changed: the | restriction on the first character is relaxed to allow either a | letter or a digit. Host software MUST support this more liberal | syntax. | | Host software MUST handle host names of up to 63 characters and | SHOULD handle host names of up to 255 characters. In RFC 952, | ASSUMPTIONS | | 1. A "name" (Net, Host, Gateway, or Domain name) is a text string up | to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus | sign (-), and period (.). Note that periods are only allowed when | they serve to delimit components of "domain style names". (See | RFC-921, "Domain Name System Implementation Schedule", for | background). No blank or space characters are permitted as part of a | name. No distinction is made between upper and lower case. The first | character must be an alpha character. The last character must not be | a minus sign or period. [...] Thank you for your consideration of this matter, -- Mark D. Baushke mdb@ESD.3Com.COM From umberto@mlacus.oz.au Thu Dec 13 00:11:00 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Thu, 13 Dec 90 00:11:00 -0600 Received: from munnari.OZ.AU by cs.wisc.edu; Thu, 13 Dec 90 00:10:46 -0600 Received: from mlacus.oz (via bruce) by munnari.oz.au with SunIII (5.64+1.3.1+0.50) id AA05942; Thu, 13 Dec 1990 17:10:36 +1100 (from umberto@mlacus.oz.au) Date: Thu, 13 Dec 1990 10:24:11 +1100 From: umberto@mlacus.oz.au Message-Id: <9012130610.5942@munnari.oz.au> To: ietf-osi-x400%cs.wisc.edu@munnari.OZ.AU Subject: x400 mailing list To: ietf-osi-x400@cs.wisc.edu@munnari.oz Date: Thu, 13 Dec 90 10:24:10 EST From: Umberto Bonollo X-Mailer: ELM [version 2.2 PL0] Please place me on your x.400 mailing list ( I hope this is the correct e-mail address?) Thank you. Umberto Bonollo Computer Scientist Australian Centre for UNISYS Software (ACUS) umberto@mlacus.oz From hagens Thu Dec 13 10:19:54 1990 Message-Id: <9012131619.AA25490@janeb.cs.wisc.edu> Received: from localhost by janeb.cs.wisc.edu; Thu, 13 Dec 90 10:19:54 -0600 To: ietf-osi, ietf-osi-x400 Subject: New working group in OSI area Date: Thu, 13 Dec 90 10:19:53 CST From: hagens There is a new working group in the OSI area. The first meeting of this working group will be on the West coast in February. More information about the meeting will be sent shortly. Rob Hagens OSI Area Director ================================================================================ Charter OSI Integration Area X.400 Operations Working Group Chair: Alf Hansen, Alf.Hansen@pilot.cs.wisc.edu C=us/ADMD= /PRMD=xnren/O=UW-Madison/OU=cs/PN=Alf.Hansen Mailing Lists: ietf-osi-x400ops@pilot.cs.wisc.edu C=us/ADMD= /PRMD=xnren/O=UW-Madison/OU=cs/PN=ietf-osi-x400ops ietf-osi-x400ops-request@pilot.cs.wisc.edu C=us/ADMD= /PRMD=xnren/O=UW-Madison/OU=cs/PN=ietf-osi-x400ops-request Description of Working Group: X.400 management domains are being deployed today on the Internet. There is a need for coordination of the various efforts to insure that they can interoperate and collectively provide an Internet-wide X.400 message transfer service connected to the existing Internet mail service. Goals and Milestones: The overall goal of this group is to insure interoperability between Internet X.400 management domains and to the existing Internet mail service. The specific task of this group is to produce a document that specifies the requirements and conventions of operational Internet PRMDs. The tentative timetable for this group is Feb 1991: Initial meeting, produce internal outline. Mar 1991: Working draft, circulate to interested people. July 1991: Internet draft available. Dec 1991: Document ready for publication. From Alf.Hansen@pilot.cs.wisc.edu Thu Dec 13 15:26:19 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Thu, 13 Dec 90 15:26:19 -0600 Received: from csl5.cs.wisc.edu by cs.wisc.edu; Thu, 13 Dec 90 15:26:13 -0600 X400-Received: by mta pilot.cs.wisc.edu in /PRMD=xnren/ADMD= /C=us/; Relayed; Thu, 13 Dec 1990 15:25:50 +0000 X400-Received: by /PRMD=xnren/ADMD= /C=us/; Relayed; Thu, 13 Dec 1990 14:25:37 +0000 Date: Thu, 13 Dec 1990 15:25:37 -0500 X400-Originator: Alf.Hansen@pilot.cs.wisc.edu X400-Mts-Identifier: [/PRMD=xnren/ADMD= /C=us/;hansen661123537.53hermit.cs.uw] X400-Content-Type: P2-1984 (2) Content-Identifier: 901213152535 From: Alf Hansen Message-Id: <901213152535*@MHS> To: ietf-osi-x400, ixom Subject: Preliminary plan, 1st meeting ietf-osi-x400ops in February. Dear Colleague, I am forwarding a preliminary plan for the next meeting in the new IETF group. Comments are welcome. Best regards, Alf H. ============================================================================ Overall plan for the 1st meeting in the IETF X.400 Operations Working Group. General: The concrete goal of the meeting is to produce an internal outline of the resulting document that specifies the requirements and conventions of operational Internet PRMDs. Before doing that we should have an open discussion on the roles of a PRMD, based on the available experience in the group. Provisional agenda: ------------------- 1. Welcome, roll call of delegates, secretary. ---------------------------------------------- 2. Round table presentation of current X.400 status. ---------------------------------------------------- Short, focus on major milestones. 3. Registration of X.400 addresses. ----------------------------------- Assume a central registration of unique ADMDs and PRMDs in the US. Should we have a common registration service for Internet, or should each PRMD be its own Naming Authority (for O and OUs)? 4. RFC-822/X,400 address mapping coordination. ---------------------------------------------- Starting point will be the preliminary conclusions from the IXOM meeting in Madison Nov. 28 (Minutes to be distributed.) Case studies. We will go through the current coordination procedures and check if they have the flexibility we want. Please submit mapping / address transition examples to the mailing list prior to the meeting. 5. Basic organizational assumptions. ------------------------------------ Initial map of the current structure of PRMDs and how they may be already interconnected with each other and with external public X.400 service providers and International X.400 infrastructures. Relations to existing Internet mail service. Administrative procedures and information exchange. Should there be a collective representation of the collection of PRMDs internationally, or vs. public carriers? 6. Routing. ----------- Should we introduce a national WEP structure (hierarchical routing) between PRMDs? Should we have a "super-PRMD" handling traffic your PRMD is not able to handle? Transit traffic through PRMDs. Routing to Intenet mail and ADMDs. International routing. Starting point will be a concrete proposal from the NSF X.400 Pilot project. Discussions and modifications. 7. Future aspects. ------------------ X.400/84 <--> 88 interworking. Use of an X.500 infrastructure for routing and user catalog purposes. 8. Outline of PRMD requirements. -------------------------------- Based on the discussions above. 9. AOB and next meeting. ------------------------ From hagens Tue Dec 18 15:01:52 1990 Message-Id: <9012182101.AA01936@janeb.cs.wisc.edu> Received: from localhost by janeb.cs.wisc.edu; Tue, 18 Dec 90 15:01:52 -0600 To: ietf-osi-x400 Subject: minutes of Boulder meeting Date: Tue, 18 Dec 90 15:01:51 CST From: hagens Minutes of the OSI X.400 Working Group - Wednesday, December 5, 1990/ Reported by Judy Messing/ MITRE Corporation Agenda - Review of Draft Proposal for the use of the Internet DNS to maintain RFC 987/RFC 1148 Address Mapping Tables - X.400 Deployment Issues - XNREN Discussion - Announcement of new Working Group - Operational Issues Discussion - PRMD Organization - Originator/Recipient Name Assignment - Address Mapping The meeting was convened by Robert Hagens, Working Group Chair. An attendance list will be published with the Proceedings of the IETF. The revised "Draft Proposal for the Use of the Internet DNS to Maintain RFC 987/RFC 1148 Address Mapping Tables" (by Cole and Hagens) had been circulated on many mailing lists prior to the meeting. This proposal describes how the DNS could be used to store, retreive, and maintain the mappings between RFC 822 domain names and X.400 O/R addresses. The first order of business was the review of this draft proposal. The following issues were discussed and resoved during the review: 1) Placement of TO-X400 and TO-822 resource records in the DNS tree (Section 4). It was decided that both records should be placed under the same DNS root. This should be done in both the transitional and experimental phase of using the DNS for the mapping tables. A suggestion was made to demonstrate this placement more clearly in the document by a drawing of the domain name hierarchy. Steve Kille noted that placing the two records under the same root provide a good facility for management of the mappings, distribution of zones of the DNS, and for zone transfers. Placing the records under the same root will result in a routing performance loss because it requires lookups in two trees. 2) Determination of name for T0-X400 and T0-822 root (Section 4). Hagens suggested the root name ORMAP.ORG. Steve Kille suggested a new top level domain .TABLE. Then the root name would be ORMAP.TABLE. The consensus was to request a new top level domain .TABLE. If this request was not granted, the records should be placed in ORMAP.ORG. 3) Structure of O/R Address in Domain Name Syntax (Section 4.1). Alf Hansen proposed three alternative solutions: - the syntax given in Appendix F of RFCs 987 and 1148. - an algorithmic, more human readable, syntax replacing blank attributes with a hyphen. - an algorithmic, more human readable, syntax dropping blank attributes. Steve Kille remarked that the text syntax of RFCs 987 and 1148 are now being used in other environments and strongly argued for remaining aligned with that syntax. This syntax is also used in the DNS standard. The consensus was to keep the syntax aligned with the RFCs and to refer to RFC 1148 in the draft standard when discussing the structure of the O/R addresses. The RARE printable format will be used in text examples. In section 4.3, Step 2 of the example, the wildcard count of 5 is a typo. This will be changed to 6. 4) Error Recovery (Section 4.4). A discussion on the appropriate action for the mapping algorithm based upon the DNS response code resulted in a recommendation that this section be rewritten. The new section on Error Recovery will reflect the way RFC 1148 handles the case where a hit is not found in the mapping lookup table. 5) RFC 1148 Issues The draft will reference RFC 1148 as the primary address mapping document. RFC 987 will be referenced as a secondary document. 6) Proposed Resource Records (Section 3). Hagens reported that the types assigned to the new Resource Records defined in the document are incorrect, but that real values would be assigned when the draft is issued. 7) DNS Address Class (Section 6). Discussion was held on whether the new Resource Records should be assigned to the Internet address class, IN, or the ISO address class, ISO. Suggestions for the assigned address class were to omit it, use a wildcard, add a new class called "mapping", or use IN. The question was raised as to whether the DNS implementations actually accepted an address class other than IN. The decision was that IN would be acceptable, but that Hagens would coordinate the address class assignment with Paul Mockapetris. 8) Transition Phase (Section 5.3.2). The consensus was to remove this section from the proposed draft and expand it into a separate document. The current proposed draft and the new transition document will reference each other. 9) Coordination and Administration (Section 5). The proposed draft spoke of the master copy of the mapping database as the copy stored in the DNS namespace. Steve Kille pointed out that there is a global use of the the mapping database and that it could be stored in three forms: table form, DNS form, or X.500 form. At his suggestion, the Working Group agreed that the proposed draft should define a model on the global use of the mapping table and the proposed transition document define the details of how the model would be actualized. The model is based on country. As a national issue, each country decides whether its master copy of the mapping database is stored in the DNS, a table, or an X.500 directory. If a country changes from one master to another, it takes responsibility for moving from its original master to its new master. Procedures to follow when a country chooses to transition from one master to another must be developed. Currently the RARE project is mastered in tables. Each country maintains its own tables and the RARE working group maintains the global mapping table. The United States will be mastered in the DNS. At this time RARE is responsible for maintain the mapping tables and the University of Wisconsin is responsible for maintaining the DNS mapping records. Discussion of XNREN PRMD Alf Hansen gave a presentation on the XNREN, the Wisconsin Internet X.400 pilot project PRMD. He made the following points: - XNREN is experimental in nature. - XNREN is a production-quality service-oriented PRMD. - XNREN can be joined by any organization willing to operate a local X.400 service and contribute to a better understanding of operational issues. The Wisconsin pilot project will offer ARGO X.400 code to non-commercial private organizations. Currently there are two X.400 implementations in XNREN: the University College London PP and Wisconsin ARGO X.400. The pilot project is focusing on short term operational problems. NSF has funded it for two years. Participating organizations must agree to the following: - register their organizations and organizational units with the ad-hoc XNREN Naming authority. - appoint a MHS site manager. - operate any RFC987 gateway according to agreed upon rules. - define X.400/RFC822 address mappings. - use commonly agreed upon mappings. - use locally defined mappings. - route traffic external to XNREN according to specified rules. The XNREN pilot is a member of the International R&D Service. It provides connectivity to Internet mail and, under the leadership of the Corporation for National Research Initiatives, plans to establish contact with the national ADMDs with the goal of negotiating interconnection agreements and experimental exchange of messages. The XNREN PRMD is also interesting in exchanging experiences and establishing connectivity with other Internet PRMDs. XNREN will offer the following services: - assist participants in the pilot in setting up their X.400 service. - produce informational material about service developments. - take an active role on X.400-related mailing lists. - allow testing of new software and procedures in XNREN. - incorporate X.400 technical innovations into experiments. - use the X.400 infrastructure to experiment. Contact XNREN at: postmaster@cs.wisc.edu or X400-project-team@cs.wisc.edu. MERIT is operating an X.400 gateway to Internet for SprintMail. Mark Knopper expressed interest in directly routing to XNREN. New Working Group Anounced Rob Hagens announced the formation of the X.400 Operations Working Group. Its goal is to insure interoperability between Internet PRMDs. The first task of the group will be to draft a document that specifies requirement/conventions of Internet PRMDs. Membership in this working group will be limited to people with planning, deployment, and operational responsibilities. The working group will address the following issues: - Basic Assumptions - Connectivity - Stack Choice - Degree of interconnection - Routing - Necessity of well-known entry point - Policy on transit traffic - How to connect to ADMDs - Collective representation of PRMDs - Internationally - Interacting with public carriers - Forum for addressing mapping coordination - 1984/1988 issues - X.500 issues The group discussed the necessity of forming a new working group. Steve Kille wondered if the work was not within the scope of this Working Group. Hagens e said that the new working group was operational and motivated toward concrete progress. He also said that if the current Working Group had completed its agenda, it could be dissolved. The first meeting of the X.400 Operations Working Group will be February 4-6, 1991 at NASA-Ames. Operational Issues Discussion PRMD Organization. Rob Hagens announced that a preliminary meeting of X.400 operational people had been held on November 28 at the University of Wisconsin. The following general assumptions had evolved for the Internet PRMDs: for the Internet PRMDs: - PRMDs can be directly connected to each other. - PRMDs will not all be directly interconnected. - PRMDs must have unique names in the US. - A PRMD can be a naming authority for its organizations. - A PRMD can be connected to 0 or more ADMDs. - X.400 addresses should reflect organizational structure. Address Mapping. Alf Hansen presented two proposed methods of address mapping when a user of an X.400 system wants to send mail to a user of an RFC 822 system and vice versa. One solution consists of mapping the elements of the receiver's mail system address into elements of the sender mail system address structure. The receiver address then looks like a valid address of the sending mail system. In the second solution, the receiver's address is left in the syntax of his mail system. For the X.400 to RFC 822 case, the recipients address is placed in a Domain Defined Attribute and the Organization indicates The community the address refers to, e.g. Internet or RFC822. In the RFC 822 to X.400 case, the recipient address is placed in quotes in the left-hand side term of the domain name; the community it placed on the right-hand side of the @ sign. The group discussed the mapping issues, but no decision was made. Steve Kille warned that if the chosen solution generates X.400 addresses than messages with those addresses must be able to be delivered. 1988 X.400. Steve Kille suggested that the Working Group name 1988 X.400 as the Internet supported standard. He pointed out that 1988 X.400 supported directory, security, distribution lists and the message store. Kille said one defect of 1988 X.400 was that it did not allow a 1984 X.400 user to address an arbitrary 1988 user. However, he said he had a simple proposal that he intended to specify to correct this problem. In the discussion, it was pointed out that GOSIP does not specify 1988 X.400 until GOSIP Version 3, which is two years away. The final discussion of the meeting centered on determining if there was any interest in writing a MIB for X.400 and X.500. From Alf.Hansen@pilot.cs.wisc.edu Wed Dec 19 14:42:23 1990 Received: from csl5.cs.wisc.edu by janeb.cs.wisc.edu; Wed, 19 Dec 90 14:42:23 -0600 X400-Received: by mta pilot.cs.wisc.edu in /PRMD=xnren/ADMD= /C=us/; Relayed; Wed, 19 Dec 1990 14:42:01 +0000 X400-Received: by /PRMD=xnren/ADMD= /C=us/; Relayed; Wed, 19 Dec 1990 13:41:43 +0000 Date: Wed, 19 Dec 1990 14:41:43 -0500 X400-Originator: Alf.Hansen@pilot.cs.wisc.edu X400-Mts-Identifier: [/PRMD=xnren/ADMD= /C=us/;hansen661639303.73hermit.cs.uw] X400-Content-Type: P2-1984 (2) Content-Identifier: 901219144141 From: Alf Hansen Message-Id: <901219144141*@MHS> To: hagens Cc: ietf-osi-x400 In-Reply-To: References: <9012182101.AA01936@janeb.cs.wisc.edu> One small comment to the minutes: > .. > .. > 3) Structure of O/R Address in Domain Name Syntax (Section 4.1). > > Alf Hansen proposed three alternative solutions: > - the syntax given in Appendix F of RFCs 987 and 1148. > - an algorithmic, more human readable, syntax replacing > blank attributes with a hyphen. > - an algorithmic, more human readable, syntax dropping > blank attributes. As far as I remember I proposed to base the syntax on the RFC 987 and 1148 spec, and instead of discussing a DNS spesific syntax, we should rather discuss modifications of RFC 987 and 1148. > .. > .. > The first meeting of the X.400 Operations Working Group will be > February 4-6, 1991 at NASA-Ames. > Is this the final schedule, or has the meeting been shifted one day? Best regards, Alf H. From stef@nma.com Wed Dec 19 23:17:11 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Wed, 19 Dec 90 23:17:11 -0600 Received: from NRTC.NORTHROP.COM by cs.wisc.edu; Wed, 19 Dec 90 23:16:57 -0600 Received: from nma.com by nrtc.nrtc.northrop.com id aa05909; 19 Dec 90 21:16 PST Received: from localhost by nma.com id aa12182; 19 Dec 90 20:46 PST To: Alf Hansen Cc: hagens, ietf-osi-x400 Subject: Dates for next meeting In-Reply-To: Your message of Wed, 19 Dec 90 14:41:43 -0500. <901219144141*@MHS> Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Wed, 19 Dec 90 20:46:23 -0800 Message-Id: <12179.661668383@nma> Sender: stef@nma.com Hi All - I have a schedule conflict with your choice of the week of Feb 4-8, when I have a long standing reservation for a ski condo. So, I guess I will have to miss the next meeting too. I wonder if there is any way to have some input into your meeting schedule process to avoid constant conflict. I seem to be exactly out of synch. Nava Merry Merry and a Great New Year! Cheers...\Stef From pays@mars.emse.fr Sat Dec 22 06:57:58 1990 Received: from cs.wisc.edu by janeb.cs.wisc.edu; Sat, 22 Dec 90 06:57:58 -0600 Received: from kwai.inria.fr by cs.wisc.edu; Sat, 22 Dec 90 06:57:50 -0600 X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed; 22 Dec 90 13:59:45+0100 X400-Received: by /PRMD=emse/ADMD=atlas/C=fr/; Relayed; 22 Dec 90 13:56:47+0100 Date: 22 Dec 90 13:56:47+0100 From: Paul-Andre Pays Message-Id: <9012221256.AA13667@mars.emse.fr> To: RARE-WG1@SWITCH.ch, ietf-osi-x400, kaufmann@zpl.dfn.dbp.de, rd-mhs-managers@rare.no Subject: Re: Use of SA/DDA Cc: Paul-Andre PAYS just a Xmass "present" to stir again the discussion :-) I just disagree with Peter Kaufmann statement that DDA should be avoided as much as possible. There are plenty of reasons to my position: Even if we have beeen able so far to "live with" SA and mapping tables, this does not mean at all that this must go on indefinitly. What was possible as long as X.400 was semi confidential (ie. a small number of X.400 domains in the world) it was, though painfull, possible to organise and collect "worldwide" mapping tables and distribute them. Today RARE tables have reached 100K. This is still manageable but soon this will be completely unmanageable; we have to expect that within 2 years there will be at least 10 times the number of X.400 sites (only within europe) and certainly within 5 years 100 to 1000 times at a worldwide level. Who is willing to cope with tables 1Mbytes to 100Mbytes big? (Even DFN will not :-), what about all the "less organized" other countries?) We have to remember that EVERY gateway in the world have to use the very SAME and complete mapping tables. Yes I know DNS and/or X.500 are (will be) useable for that purpose; Will it really be done? Is not this a "stupid" misuse of these too load them with 100Mbytes of mappings?; Will we not waste tremendous bandwith just accessing the directory services; Will all the implementation be able to access these directories?;... In brief this sounds to me completely unrealistic!!! Another important aspect: What about the "poor" (really?) users provided with a real pure X.400 environement (ie. X.400 UAs)? I would be curious to know how many of the SA promoters are really using a X.400 UA (one really dealing with ORnames, and not a RFC mailer or an ugly hybrid (bastard?) with X.400 service elements but still domain addresses (or domain like, even worse). My belief is that this number will increase soon at a tremendous rate, now the products (real products) are making their debuts. The main problem is what a user receiving through X.400 mail into a X.400 UA will do with pseudo ORnames such as .... OU=foo;P=kr; A=dbp; C=de; within a "carbon copy recipient"? Nothing!!!! noth but (for example) from Korea or Japann, when "ReplyingAll" generate a message to Germany and back to Asia. Does this make any sense? Do the people using real X.400 software have to be banned from the X.400 community as being "nasty boys"? Do the X.400 software developpers have to be forced to deliver "bastards" using domain addresses instead of ORnames? Let stop to talk nonsense for the short term future! I don't criticize what has been done so far by RARE, there was no other choices due to the "wicked and weak" software available in the early age of X.400. But do we have to plan the future according to past errors or weaknesses? If some action is to be taken the right move is to put as much pressure as possible over "profile people" (eg. CEN/CENELEC) to make DDA mandatory for real X.400 usability and conformance. DDA is a nice X.400 feature to enable non X.400 interoperability. We have, we will have to use it. I know that the solution to build an ORname by putting the other address (non X.400) within a DDA and use the SAs to explicitely designate a specific gateway has its own weakness: the user have to know the attributes of the gateway the scheme is poor when a gateway has to be changed, added or removed .... But who said that the SA part of such an ORname have to carry the specific attributes of a specific gateway? Who? It is our task (we, MHS managers) to define a naming scheme enabling 1. to use this SA part to designate a *service* (the appropriate gatewaying service) and not the "address" of a specific machine (or MTA/gateway) 2. to set up a routing strategy enabling the transfer of messages to such recipients to the appropiate gateway (there could be more than one gateway, or conversely a gateway shared by several communities; there could exist a policy enabling to take into account criterias such as cost considerations, rush hours aso to determine and select for each given message which gateway will be used). The gateway service organisation is no longer a end-user issue but certainly a concer of the MHS managers, what is the right solution. A short example (just for clarification purpose): Country France decides to set up a R&D ADMD (RED400), RED400 will operate two RFC987 gateways (PARIS and NICE) and one BITNET gateway (RENNES) with a defined policy to use preferably NICE over night hours and for non european traffic and PARIS for the other. This choice may change over time, the numbers of gateway too; this not a user matter. Users will only use: DDA.RFC-822=foo@foobar.xy; P=822gate; A=RED400; C=FR; or DDA.bitnet=FOO AT FRsite; P=bitgate; A=RED400; C=FR; and not worry any more. REMEMBER this is only an example not a definitive proposal. Some choices are to be discussed. Another solution: priority to DDA over SDA when routing: This enables to dhtake the routing decision by using the DDA type and not the SA given by the Originator. (Yes this approach has some drawbacks too!) This solution is by no means exluding the previous one (which I prefer), they can perfectly cooperate. (NOTA: this is already the behaviour of some software such as M.PLUS from Huitema INRIA) Another advantage of solution 1 is that it is prherfectly in line with '88 X.400 and the use of Directory (usable to determine from the SA part which MTA/gateway is to be choosen). I don't pretend that the solution is usable as is today given the amount of "wicked" UA we are still using. What I really want is 1. to stir again the "brain storming" about this crucial issue. 2. to push for a really sound solution in our prospective and incentive role (standard bodies, manufacturers) 3. to put as much pressure over software developpers for them not to stick stupidely to CEN/CENELEC profile and include DDA attributes in their products as soon as possible. Enough for now (even If I expect and hope strong reactions). Best wishes to all of you -- PAP