Received: from nri.nri.reston.va.us by ietf.ietf.NRI.Reston.VA.US id aa06744; 2 Mar 92 5:03 EST Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa09798; 2 Mar 92 5:01 EST Received: from mhs-relay.cs.wisc.edu by NRI.NRI.Reston.VA.US id aa09794; 2 Mar 92 5:01 EST Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <14888-0@mhs-relay.cs.wisc.edu>; Mon, 2 Mar 1992 03:38:19 +0000 Message-Id: <9203020938.AA24377@cs.wisc.edu> Received: from surver.surfnet.nl by cs.wisc.edu; Mon, 2 Mar 92 03:38:07 -0600 Received: from localhost.surfnet.nl by surver.surfnet.nl with SMTP (PP) id <14015-0@surver.surfnet.nl>; Mon, 2 Mar 1992 10:37:37 +0100 To: Urs Eppenberger Cc: ietf-osi-x400ops , RARE Working Group 1 , rd-mhs-managers Subject: Re: Routing Coordination V4.1 In-Reply-To: Your message of Fri, 28 Feb 92 00:56:19 +0100. <2077*/S=Eppenberger/OU=verw/O=switch/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS> Organisation: SURFnet BV Address: Godebaldkwartier 24, P.O. Box 19035, 3501 DA Utrecht, NL Phone: +31 30 310290 Telefax: +31 30 340903 Date: Mon, 02 Mar 92 10:37:24 +0100 From: "Erik Huizer (SURFnet BV)" Urs, Rob, I still propose that it goes forward as an experimental RFC. I don't know about RFC 1111 but the definition is (as it currently stands, taken from rfc12xx, soon to be published): ------------ The "experimental" designation on a TS (Technical Specification) permits widespread dissemination (through usual rfc procedures) with explicit caveats: it may specify behaviour that has not been thoroughly analysed or is poorly understood; it may be subject to considerble change; it may never be a candidate for the formal standards track; and may be discarded in favour of some other proposal. Any TS that is not an immediate candidate for Internet standardization is appropriate for publication as Experimental. Interested parties are thereby given 5the opportunity to gain experience with implementations and to report their findings to the community of interest, but the specification is explicitly not recommended for general production use. ---------------- This makes an experimental rfc just a bit more then an informational. The informational can be regarded as a real standard, but made outside of the rfc community, so published as an FYI. The experimental status indicates that we don't want manufacturers to adopt this, because we expect better solutions to come up. (X.500?). So I strongly suggest experimental, Erik   Received: from nri.nri.reston.va.us by ietf.ietf.NRI.Reston.VA.US id ab06936; 2 Mar 92 5:53 EST Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa10499; 2 Mar 92 5:51 EST Received: from mhs-relay.cs.wisc.edu by NRI.NRI.Reston.VA.US id aa10495; 2 Mar 92 5:51 EST X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Mon, 2 Mar 1992 03:55:17 +0000 Date: Mon, 2 Mar 1992 03:55:17 +0000 X400-Originator: cargille@cs.wisc.edu X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=XNREN/ADMD= /C=US/;mhs-relay..088:02.02.92.09.55.17] Priority: Non-Urgent DL-Expansion-History: ietf-osi-x400ops@cs.wisc.edu ; Mon, 2 Mar 1992 03:55:16 +0000; From: Urs Eppenberger Message-ID: <2088*/S=Eppenberger/OU=verw/O=switch/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS> To: ietf-osi-x400ops , RARE Working Group 1 Subject: Experimental Status for 'Routing Coordination V4' Erik, I had to base the 'Status of this Memo' according the currently valid RFC1111. I fully agree with you that the experimental status would be more appropriate. Rob, you have to contacts and submitted the doc. Is it possible to modify the status? I also have a revised version ready by tomorrow: 90% of the typos and other bugs removed Some sections rephrased to make it more understandable BNF reformatted Update info in the docs Urs.   Received: from nri.nri.reston.va.us by ietf.ietf.NRI.Reston.VA.US id aa11047; 2 Mar 92 15:45 EST Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa02347; 2 Mar 92 15:35 EST Received: from mhs-relay.cs.wisc.edu by NRI.NRI.Reston.VA.US id aa02342; 2 Mar 92 15:35 EST Received: from calypso.cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <16987-0@mhs-relay.cs.wisc.edu>; Mon, 2 Mar 1992 14:33:12 +0000 Received: from localhost by calypso.cs.wisc.edu with SMTP (PP) id <15009-0@calypso.cs.wisc.edu>; Mon, 2 Mar 1992 11:00:26 +0000 To: Urs Eppenberger cc: ietf-osi-x400ops , RARE Working Group 1 Subject: Re: Experimental Status for 'Routing Coordination V4' In-reply-to: Your message of "Mon, 02 Mar 92 04:00:43 GMT." <2088*/S=Eppenberger/OU=verw/O=switch/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS> Date: Mon, 02 Mar 92 11:00:20 CST From: hagens@cs.wisc.edu Message-ID: <9203021535.aa02342@NRI.NRI.Reston.VA.US> Erik - agree with experimental. Urs - Let me know when you have final draft ready to be submitted as internet draft. Rob   Received: from nri.nri.reston.va.us by ietf.ietf.NRI.Reston.VA.US id aa11581; 2 Mar 92 16:45 EST Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa04861; 2 Mar 92 16:40 EST Received: from mhs-relay.cs.wisc.edu by NRI.NRI.Reston.VA.US id aa04852; 2 Mar 92 16:40 EST Received: from calypso.cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <16993-0@mhs-relay.cs.wisc.edu>; Mon, 2 Mar 1992 14:34:29 +0000 Received: from localhost by calypso.cs.wisc.edu with SMTP (PP) id <15185-0@calypso.cs.wisc.edu>; Mon, 2 Mar 1992 11:54:26 +0000 To: ALLOCCHIO@elettra-ts.infn.it cc: RARE-WG1@switch.ch, IETF-OSI-X400OPS@cs.wisc.edu Subject: Re: a suggestion for the agenda In-reply-to: Your message of "Fri, 28 Feb 92 08:02:29 GMT." <"22924182202991/90417 INFN*"@MHS> Date: Mon, 02 Mar 92 11:54:19 CST From: hagens@cs.wisc.edu Message-ID: <9203021640.aa04852@NRI.NRI.Reston.VA.US> > > Last year I prepared a document discussione how to map, to be more exact, > how to deal with, Mail-11 (DECnet phase IV) addresses into x.400. > > That document was revised by WG1 meeting, and its last version will be > published in May as a RARE Techincal Report. I'll send out the final > version with the latest corrections I had from WG1 and Steve H-Kille > next week. > > I'd like to have also IETF X.400 ops opinions before finalizing the > document; being it quite short, will a 10-15 minutes slot be available > for it? > > would it be woth to publish it as an RFC, also if it deals HEPNET/SPAN and > X.400 ? I believe so, as Internet is also to be considered into the X.400 > side of the world. Hi, Please do send the document around to the list. We can put it on the agenda. As far as RFC publication goes, if it serves the community to publish, then I think it should be done. We can discuss this more at the IETF. NOTE TO ALF - consider this a request to put onto the agenda - thanks Rob   Received: from nri.nri.reston.va.us by ietf.ietf.NRI.Reston.VA.US id aa00426; 3 Mar 92 5:27 EST Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa01507; 3 Mar 92 5:18 EST Received: from mhs-relay.cs.wisc.edu by NRI.NRI.Reston.VA.US id aa01497; 3 Mar 92 5:18 EST X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Tue, 3 Mar 1992 03:58:08 +0000 Date: Tue, 3 Mar 1992 03:58:08 +0000 X400-Originator: cargille@cs.wisc.edu X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=XNREN/ADMD= /C=US/;mhs-relay..588:03.02.92.09.58.08] Priority: Non-Urgent DL-Expansion-History: ietf-osi-x400ops@cs.wisc.edu ; Tue, 3 Mar 1992 03:58:08 +0000; From: Urs Eppenberger Message-ID: <2096*/S=Eppenberger/OU=verw/O=switch/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS> To: RARE Working Group 1 , ietf-osi-x400ops Subject: Routing Coordination, March 3 1992 Dear colleagues, here followes the 'final' version right in time beforethe IETF meeting. There won't be any changes till after IETF. I do think it is worth to throw away any older version and read this one. A lot of typos have been removed. I added tutorial sections on priorities and delays. The appendix should match now the document definitions. The term MHS subtree has been introduced. I applied for the experimental specification status. I did not change the sequence of the fields in the connection info line. The proposed sequence follows the logic of the presentation address. I also did not add the super WEP functionality. All WEPs of a community should therefore still be interconnected where possible. Other MTAs can connect to a WEP nearby. I promise, for the next three weeks you won't get any newer versions. Kind regards and many thanks four your support, Urs. 8<-------------------------------------------------------------------->8 X400 Operations Group U. Eppenberger Internet Draft SWITCH March 3 1992 Routing coordination for X.400 MHS services within a multi protocol / multi network environment Status of this Memo This memo defines an experimental specification on how the routing of X.400 services within the Internet community and other networking communities can be managed. The distribution of this memo is unlimited. 1. Introduction The usage of the X.400 Message Handling System (MHS) is growing rapidly, especially in the academic and research community. New networks and new addresses come into use each and every day. The underlying technology for different X.400 networks can vary depending on the transport network and the X.400 MHS implementations used. As a large number of X.400 implementations now support multiple stacks, this offers the chance of implementing a world wide message handling service using the same electronic mail standard and, therefore, without the need of gateways with service reduction and without the restriction to a single common transport network. This, however, leads to several problems for the MHS manager however, two of which are: - Where do I route new X.400 addresses and - How do I connect to a MHS domain that uses an underlying technology that I do not support. This document proposes how these problems can be solved in the short term. It proposes a strategy for maintaining and distributing routing information and shows how messages can travel over different networks by using multi stack MTAs as relays. Document formats and coordination procedures bridge the gap until an X.500 directory service is ready to store the needed connectivity and routing information. Many experts from IETF X.400-Operations Group and RARE Working Group 1 on Message Handling Systems have read drafts of this document and contributed ideas and solutions. I would especially like to thank Harald Alvestrand, Erik Huizer, Marko Kaittola and Paul-Andre Pays. Tom Oliphant did an excellent proofreading job. 2. Terminology MHS community One or more MHS domains form together an MHS community. Mail exchange between these MHS domains is defined by the coordination procedures within this document. An example of an MHS community is the global X.400 MHS service. Eppenberger [Page 1] INTERNET-DRAFT Routing Coordination for X.400 Services February 1992 MHS domain One or more MHS subtrees form together an MHS domain. This is a purely administrative grouping of MHS subtrees. It is helpful, if someone is responsible for several MHS subtrees, to refer to an MHS domain instead of listing all the subtrees. MHS subtree An MHS subtree consists of the total of the mailboxes addressable within a subtree of the X.400 OR address space. Example: C=CH; ADMD=ARCOM; PRMD=SWITCH; O=SWITCH; MHS domain of SWITCH in Switzerland, consisting of all mailboxes with C=CH; ADMD=ARCOM; PRMD=SWITCH; O=SWITCH; in the OR address. WEP Well known Entry Point, an X.400 MTA serving one or several MHS domains. COSINE-MHS The COSINE-MHS community is mainly formed by European X.400 service providers from the academic and research area, each of which is a member of RARE. The COSINE-MHS community is used in the annex as an example for the usage of this document in a multinational environment. 3. Requirements X.400 MTAs can communicate using different transport and network protocol stacks. For this document the stacks used in a WAN environment need to be considered: Stack 1 Stack 2 Stack 3 Stack 4 Transport Layer 4 TP0 TP4 RFC1006 TP0 Networkservice 1-3 X.25 CLNS TCP/IP CONS A common protocol stack is not the only requirement to enable communication between two MTAs. The networks to which the MTAs belong need to be interconnected. Some well known networks are listed together with the stacks they use. Network Stack Abbreviation Public Switched Packet Data Networks 1 Public-X.25 International X.25 Infrastructure IXI 1,4 RARE-IXI RARE connectionless pilot 2 RARE-CLNS Internet 3 Internet Note that several stacks may be supported over a single network. However communication between MTAs is only possible if the MTAs share at least a common stack AND a common network. Eppenberger [Page 2] INTERNET-DRAFT Routing Coordination for X.400 Services February 1992 Unlike SMTP/TCP/IP systems, there is no directory service available which would allow an MTA to look up the next MTA to which it should submit a message. Routing within X.400 will continue to be table based until a solution using X.500 directory services is available. Furthermore it is not generally allowed to connect to any MTA even on the same network without being registered on the destination MTA. These restrictions require a large coordination effort and carefully configured and updated systems. 4. Outline of the proposal This proposal offers a solution for describing information about X.400 message routing within an MHS community in WEP and DOMAIN documents. Basic information on the MHS community is documented in the corresponding COMMUNITY document. A future X.500 based solution may need extended information to overcome still unsolved problems like optimal routing or traffic optimization for messages with multiple recipients. The information collected for the intermediate solution however is very basic. All established coordination procedures will help and even speed up the future introduction of an X.500 based solution. 4.1 The COMMUNITY document For each MHS community there exists one single COMMUNITY document containing basic information. First the contact information for the central coordination point can be found together with the addresses for the file server where all the documents are stored. It also lists network names and stacks to be used in the WEP and DOMAIN documents. An MHS community must agree on its own set of mandatory and optional networks and stacks. 4.2 The WEP document Every MHS domain in the community may designate one or more MTAs as WEPs. These WEPs accept incoming connections from the WEPs of the other MHS domains and in return are allowed to send messages to these WEPs. A WEP is documented with all the needed connection information in the corresponding WEP document. 4.3 The DOMAIN document An MHS domain has a responsible person who sets up the routing entries for the domain in the DOMAIN document. The WEPs listed in the DOMAIN document as serving this MHS domain must, TOGETHER, offer at least connectivity to all networks and stacks listed as mandatory in the COMMUNITY document. An MHS domain may also decide not to operate a WEP. It will then only need agreements with one or more WEPs from other MHS domains which will relay for this domain. The domain itself, however, must always create a DOMAIN document. Eppenberger [Page 3] INTERNET-DRAFT Routing Coordination for X.400 Services February 1992 The structure of the DOMAIN document is very straightforward. It starts of with one or more MHS subtrees, each on its own line. After the domains follows a line indicating the responsible person for the MHS subtrees mentioned. Finally the relaying WEP(s) are listed with appropriate priorities. 4.4 Coordination This approach requires an identified coordination point. It is up to the MHS community to decide on the level of coordination and support to be provided and on the funding mechanisms for such activities. Basic information can be found in the COMMUNITY document. The following list of support activities is considered mandatory for an operational service: - New WEPs joining the service are tested and support is given to create the WEP document. - New MHS domains joining the MHS community get assistance to set up WEP(s) and find appropriate relaying WEP(s) and to create DOMAIN documents. - Updated documents are announced to the WEP managers. - All the WEP and DOMAIN documents are made available on a file server together with the COMMUNITY document. The file server must at least be reachable via email. MHS communites with a big number of documents may consider additional access methods like ftp and FTAM. - Tools should be made available to manage routing tables for the X.400 software used on the WEPs. The format of the documents has especially been choosen to enable the use of automated tools. 4.5 Routing The proposal addresses MHS communities spanning several organisations. But it may also be used to manage routing within a single organisation or even a global MHS community. Common to each community is that each WEP is connected to each other WEP where technically possible. This creates a meshed network with as few hops as possible and the possibility of integrating backup WEPs to avoid single points of failure. The WEP managers must be aware that a large number of WEPs in an MHS community may require significant operational recources to keep the local routing tables up-to-date and to constantly monitor the correct functioning of the connections. MHS communities may decide on additional mandatory requirements for the operation of a WEP. These may include a hot line, echo services, exchange of statistics, response time to problem reports, uptime of the WEP, etc. This will ensure a certain quality of service for the end users. Each MHS community must define update procedures for the routing based on the documention. Automated update has to be studied carefully. An MHS community should also define procedures for new WEPs and MHS Eppenberger [Page 4] INTERNET-DRAFT Routing Coordination for X.400 Services February 1992 domains joining the service. Since the usage of X.400 is growing rapidly a flexible but well coordinated way of integrating new members into an MHS community is needed. 5. The documents The definition is given in BNF-like syntax. The following conventions are used: | means choice \ is used for continuation of a definition over several lines [] means optional {} means repeated one or more times 'CR' is a Carriage Return and means that the next section starts on its own line. The definition is complete only to a certain level of detail. Below this level, all expressions are to be replaced with text strings. The format and semantics should be clear from the names of the expressions and the comments given. Expressions without more detailed definition are marked with single quotes '. Comments may be placed anywhere in the document but only on separate lines. Such a comment line must start with a '#' sign followed by a space. If the information on a line in a document exceeds 80 characters, it is suggested to do line wrapping according RFC822: Continue on the second line with a leading space. 5.1 Basic Definitions ::= \ \ { } \ { } ::= "Community: " 'community name' 'CR' # The 'community name' is a string identifying the MHS community to # be used in the first line of all documents. ::= "C=" 'Two Character Country Code ISO-3166' \ [";ADMD=" 'ADMDname' ] \ [ ";PRMD=" 'PRMDname' ] \ ";MTAname=" 'MTAname' # A unique key is needed to identify the WEP. In addition to the MTA # name itself, it is proposed to use OR address attributes of the # management domain where the WEP resides. ADMD and PRMD fields are # both optional and may be used to guarantee uniqueness of the key. # The values used are irrelevant. Even non-printable characters like # @ or ! are acceptable. The result is not an address but a key # string. Eppenberger [Page 5] INTERNET-DRAFT Routing Coordination for X.400 Services February 1992 ::= "C=" 'Two Character Country Code ISO-3166' \ ";ADMD=" 'ADMDname' \ [ ";PRMD=" 'PRMDname' ] \ [ ";O=" 'Organization-name' ] \ [ { ";OU=" 'OrganizationalUnit-name' } ] \ ";S=" 'surname' \ [ ";G=" 'given name'] 'CR' # This is a restricted subset of the possibilities allowed by the # Standard for an OR address. ::= "Address: " 'CR' ::= [{"; " }] ::= {"+" " " " " \ } ::= 'international prefix' ::= 'area code' ::= 'local telefone number' ::= "Phone: " 'CR' # One or more phone numbers ::= "FAX: " 'CR' # One or more FAX numbers ::= "Mail: " 'postal address information' 'CR' # The items of the postal address are separated by '/' wherever # the next item goes onto the next line for the label. # Example: # Mail: SWITCH Head Office/Urs Eppenberger/Limmatquai 138/ # CH-8001 Zurich/Switzerland # results in the following mailing label: # SWITCH Head Office # Urs Eppenberger # Limmatquai 138 # CH-8001 Zurich # Switzerland Eppenberger [Page 6] INTERNET-DRAFT Routing Coordination for X.400 Services February 1992 ::= "Update: DATE=" 'yymmdd' \ ["; START=" 'yymmdd'] \ ["; END=" 'yymmdd'] 'CR' # The date of the last update of a document is given in the # form 'yymmdd'. # An optional start date can be set. A document can be published this # way before the information in it is valid. (This is especially # useful in absence of automated tools. WEP managers get more time to # prepare their systems.) # An end date is used to set an expiration date for the document. 5.2. The COMMUNITY document ::= \ \ # At this place the Community-Identifier is specified. It is # recommended to add a few comment lines to describe the members of # this MHS community. ::= {} ::= \ # Set of contact information for the coordination point ::= [{}] \ [{]} # All documents must be available at least to the managers of the MHS # domains and the WEPs through an email server. If FTAM and FTP are # also available, the generation of automated update tools is much # easier. # It is suggested to have a single server. If there is only one, # knowing a single X.400 OR address will allow you to reach the # server. However for FTP and FTAM more system addresses may be # possible depending on the number of available network connections # (or service types as they are called in this document). ::= "Mail-server: " 'CR' # The email address of the file server. ::= "FTP-server: " 'domain name' "; " 'account-name' ["; " 'password'] 'CR' # In addition to the domain name of the server, an account name # and a password is given. In most cases this will probably be # something like "anonymous" and "guest". ::= "FTAM-server: " 'P-address' "; " \ ["; " 'password'] 'CR' Eppenberger [Page 7] INTERNET-DRAFT Routing Coordination for X.400 Services February 1992 ::= 'String encoded Presentation Address' # The format of this string follows RFC1xxx, a string encoding # of Presentation Address. ::= {} \ {[]} # At least one service type is mandatory. ::= "Mandatory-Service: " 'CR' ::= "Optional-Service: " 'CR' ::= "/" \ "/" \ ::= 'Name of a network' # The network-name string identifies a network. A well known # key word should be choosen. (No '/' character is allowed.) # Examples: Public-X.25, Internet, RARE-IXI, RARE-CLNS, WIN, ::= "X.25" | "CONS" | "CLNS" | "TCP" # One of the four values identiefies the 'network service' used. # (TCP is considered a network service together with RFC1006) ::= "TP0" | "TP2" | "TP4" | "RFC1006" # The service type consists of a string with three parts concatenated # with a "/": # Network-name/Network-service/Transport-Protocol. # Since network and stack information forms one string, it identifies # in an easy way a connection possibility between to WEPs. The # community document defines the strings to be used in the WEP and # DOMAIN documents. Some examples: # Internet/TCP/RFC1006 # Public-X.25/X.25/TP0 # RARE-IXI/CONS/TP0 # RARE-CLNS/CLNS/TP4 # (It is probably important to mention here that this string has # nothing to do with the format of a presentation address as defined # by Steve Hardcastle-Kille in RFC1278. The problem of networks using # the same address structure (X.121 DTEs, 4 Byte Internet addresses) # but not beeing connected is not addressed in RFC1278 but solved by # using the proposed service identifier above in addition to the # presentation address. As long as there are network islands, there is # no other way than the addition of an 'island'-identifier. As soon as # all systems have an NSAP and are connected to a global OSI network, # this problem will disappear.) Eppenberger [Page 8] INTERNET-DRAFT Routing Coordination for X.400 Services February 1992 5.3. The WEP document ::= \ \ \ # A WEP document contains the full description of a single WEP. # Only one community is allowed. Since some of the information # is community dependent, it would not be easily possible to # have a single WEP document used in different communities. ::= "WEP: 'CR' ::= # More than one set of connection information may be present for # WEPs supporting several networks and protocol stacks. ::= \ { } \ [] ::= "Password: used" | "Password: not used" 'CR' # The usage of passwords significantly increases the effort to # establish a connection. The password is not documented but must be # exchanged during connection configuration by other means. This line # just expresses wether a password is used at all. ::= "C: " "; " "; " \ 'CR' # Very short key word to save space! For easier usage all # information related to the connection is placed in one entry. # However multiple lines may be used if, for example, X.400(84) # and X.400(88) are supported. ::= "MTS-T" | "MTS-TP" | "MTS-TP-84" # MTS-T: mts-transfer # MTS-TP: mts-transfer-protocol # MTS-TP-84: mts-transfer-protocol-1984 # See ISO 10021-6, Section 3, chapter 11.1 for more details on this # matter. X.400(84) systems only support mts-transfer-protocol-1984. ::="R: " "; " 'CR' # Since called and calling network addresses may differ in # certain configurations and some X.400 systems do validation # on calling network addresses, it is important to have this # information in the WEP document also. ::= "System: COM=" 'wep computer type' "; " \ "OPS=" 'wep operating system' "; " \ "MHS=" 'wep MHS software' 'CR' # It is optional to provide HW/SW information. Experience, Eppenberger [Page 9] INTERNET-DRAFT Routing Coordination for X.400 Services February 1992 # however, has shown that a number of communication problems # were more easily identified and solved with this information # present and up-to-date. ::= { \ } # It is important to have the name of a 'real' person. # For email, however, distribution lists and aliases # (i.e. postmaster, WEP-manager, ...) may be used. ::= "Name: " 'name of person' 'CR' # The name of the WEP manager is given. The issue of the character set # problem is not addressed in this document. In general one should # restrict itself to IA5. ::= "RFC822: " 'CR' # This is the RFC-822 address of the WEP manager. It is often a big # help to know the RFC822 address of the WEP manager, for example if # the X.400 system is not reachable. ::= "Reachable: " {