Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!ncis.tis.llnl.gov!CS.UCL.AC.UK!S.Kille From: S.Kille@CS.UCL.AC.UK (Steve Kille) Newsgroups: comp.protocols.iso.x400.gateway Subject: Fw: 2 of 5 Message-ID: <1043.616429245@UK.AC.UCL.CS> Date: 14 Jul 89 14:20:45 GMT Sender: root@ncis.tis.llnl.gov Reply-To: kehres@tis.llnl.gov Distribution: inet Organization: The Internet Lines: 1379 Approved: post-x400-gateway@tis.llnl.gov and is not reverse mappable. DL Expansion History Indication Supported by use of a new RFC 822 header | (DL-Expansion-History:). DL Expansion Prohibited Distribution List means MTS supported distribution list, in | the manner of X.400. This service does not exist in the RFC | 822 world. RFC 822 distribution lists should be regarded as | an informal redistribution mechanism, beyond the scope of | this control. Messages will be sent to RFC 822, | irrespective of whether this service is requested. | Theoretically therefore, this service is supported, although | in practice it may appear that it is not supported. Express Mail Service Kille [page 24] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 N/A (PDAU). | Expiry Date Indication Supported as new RFC 822 header (Expiry-Date:). In general, | no automatic action can be expected. Explicit Conversion N/A (prior). | Forwarded IP Message Indication Supported, with some loss of information. The message is forwarded in an RFC 822 body, and so can only be interpreted visually. Grade of Delivery Selection N/A (PDAU) | Importance Indication Supported as new RFC 822 header (Importance:). | Incomplete Copy Indication Supported as new RFC 822 header (Incomplete-Copy:). | Language Indication Supported as new RFC 822 header (Language:). | Latest Delivery Designation Not supported. A new RFC 822 header (Latest-Delivery-Time:) | is provided, which may be used by the recipient. Message Flow Confidentiality Not supported. Message Origin Authentication N/A (reception). | Message Security Labelling Not supported. Message Sequence Integrity Not supported. Multi-Destination Delivery Supported. Kille [page 25] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 Multi-part Body Supported, with some loss of information, in that the structuring cannot be formalised in RFC 822. Non Receipt Notification Request Not supported. Non Repudiation of Delivery Not supported. Non Repudiation of Origin N/A (reception). | Non Repudiation of Submission N/A (local). | Obsoleting Indication Supported as new RFC 822 header (Obsoletes:). | Ordinary Mail N/A (PDAU). | Originator Indication Supported. Originator Requested Alternate Recipient Not supported, but is placed as comment next to address. Physical Delivery Notification by MHS N/A (PDAU). | Physical Delivery Notification by PDS N/A (PDAU). | Physical Forwarding Allowed Supported by use of a comment in a new RFC 822 header | (X400-Recipients:), associated with the recipient in | question. Physical Forwarding Prohibited Supported by use of a comment in a new RFC 822 header | (X400-Recipients:), associated with the recipient in | question. Kille [page 26] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 Prevention of Non-delivery notification Supported, as delivery notifications cannot be generated by | RFC 822. In practice, errors will be returned as IP | Messages, and so this service may appear not to be supported | (see Non-delivery Notification). Primary and Copy Recipients Indication Supported Probe Supported at the gateway (i.e., the gateway services the probe). Probe Origin Authentication N/A (reception). | Proof of Delivery Not supported. Proof of Submission N/A (local). | Receipt Notification Request Indication Not supported. Redirection Allowed by Originator Redirection means MTS supported redirection, in the manner | of X.400. This service does not exist in the RFC 822 world. | RFC 822 redirection (e.g., aliasing) should be regarded as | an informal redirection mechanism, beyond the scope of this | control. Messages will be sent to RFC 822, irrespective of | whether this service is requested. Theoretically therefore, | this service is supported, although in practice it may | appear that it is not supported. Registered Mail N/A (PDAU). | Registered Mail to Addressee in Person N/A (PDAU). | Reply Request Indication Supported as comment next to address. Kille [page 27] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 Replying IP Message Indication Supported. Report Origin Authentication N/A (reception). | Request for Forwarding Address N/A (PDAU). | Requested Delivery Method N/A (local). The services required must be dealt with at | submission time. Any such request is made available through | the gateway by use of a comment associated with the | recipient in question. Return of Content In principle, this is N/A, as non-delivery notifications are | not supported. In practice, most RFC 822 systems will | return part or all of the content along with the IP Message | indicating an error (see Non-delivery Notification). Sensitivity Indication Supported as new RFC 822 header (Sensitivity:). | Special Delivery N/A (PDAU). | Stored Message Deletion N/A (MS). | Stored Message Fetching N/A (MS). | Stored Message Listing N/A (MS). | Stored Message Summary N/A (MS). | Subject Indication Supported. Undeliverable Mail with Return of Physical Message N/A (PDAU). | Kille [page 28] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 Use of Distribution List In principle this applies only to X.400 supported | distribution lists (see DL Expansion Prohibited). | Theoretically, this service is N/A (prior). In practice, | because of informal RFC 822 lists, this service can be | regarded as supported. 2.3.2. Reception by X.400 | 2.3.2.1. Standard Mandatory Services The following standard IPM mandatory user facilities may be required for reception of RFC 822 originated mail by an X.400 UA. | Content Type Indication Delivery Time Stamp Indication IP Message Identification Message Identification Non-delivery Notification Original Encoded Information Types Indication Submission Time Stamp Indication Typed Body 2.3.2.2. Standard Optional Services The following standard IPM optional user facilities may be required for reception of RFC 822 originated mail by an X.400 UA. | Authorising User's Indication Blind Copy Recipient Indication Cross Referencing Indication Originator Indication Kille [page 29] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 Primary and Copy Recipients Indication Replying IP Message Indication Subject Indication 2.3.2.3. New Services A new service "RFC 822 Header Field" is defined using the extension facilities. This allows for any RFC 822 header field to be represented. It may be present in RFC 822 originated | messages, which are received by an X.400 UA. Kille [page 30] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 Chapter 3 Basic Mappings 3.1. Notation The X.400 protocols are encoded in a structured manner according to ASN.1, whereas RFC 822 is text encoded. To define a detailed mapping, it is necessary to refer to detailed protocol elements in each format. This is described. 3.1.1. RFC 822 Structured text is defined according to the Extended Backus Naur Form (EBNF) defined in Section 2 of RFC 822 [Crocker82a]. In the EBNF definitions used in this specification, the syntax rules given in Appendix D of RFC 822 are assumed. When these EBNF tokens are referred to outside an EBNF definition, they are | identified by the string "822." appended to the beginning of the string (e.g., 822.addr-spec). Additional syntax rules, to be used throughout this specification, are defined in this chapter. The EBNF is used in two ways. 1. To describe components of RFC 822 messages (or of 822-MTS components). In this case, the lexical analysis defined in Section 3 of RFC 822 should be used. When these new EBNF tokens are referred to outside an EBNF definition, they are identified by the string "EBNF." appended to the beginning of the string (e.g., EBNF.bilateral-info). 2. To describe the structure of IA5 or ASCII information not in an RFC 822 message. In these cases, tokens will either be self delimiting, or be delimited by self delimiting tokens. Comments and LWSP are not used as delimiters. 3.1.2. ASN.1 An element is referred to with the following syntax, defined in EBNF: Kille [page 31] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 element = service "." definition *( "." definition ) service = "IPMS" / "MTS" / "MTA" definition = identifier / context identifier = ALPHA *< ALPHA or DIGIT or "-" > context = "[" 1*DIGIT "]" The EBNF.service keys are shorthand for the following service specifications: IPMS IPMSInformationObjects defined in Annex E of X.420 / ISO | 10021-7. MTS MTSAbstractService defined in Section 9 of X.411 / ISO | 10021-4. MTA MTAAbstractService defined in Section 13 of X.411 / ISO | 10021-4. The first EBNF.identifier identifies a type or value key in the context of the defined service specification. Subsequent EBNF.identifiers identify a value label or type in the context of the first identifier (SET or SEQUENCE). EBNF.context indicates a context tag, and is used where there is no label or type to | uniquely identify a component. The special EBNF.identifier keyword "value" is used to denote an element of a sequence. For example, IPMS.Heading.subject defines the subject element of the IPMS heading. The same syntax is also used to refer to element values. For example, MTS.EncodedInformationTypes.[0].g3Fax refers to a value of MTS.EncodedInformationTypes.[0] . 3.2. ASCII and IA5 A gateway will interpret all IA5 as ASCII. Thus, mapping between these forms is conceptual. 3.3. | Standard Types There is a need to convert between ASCII text, and some of the | types defined in ASN.1 . For each case, an EBNF syntax [ definition is given, for use in all of this specification, which [ Kille [page 32] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 leads to a mapping between ASN.1, and an EBNF construct. All | EBNF syntax definitions of ASN.1 types are in lower case, whereas | ASN.1 types are referred to with the first letter in upper case. Except as noted, all mappings are symmetrical. 3.3.1. Boolean Boolean is encoded as: boolean = "TRUE" / "FALSE" 3.3.2. NumericString NumericString is encoded as: numericstring = *DIGIT 3.3.3. PrintableString PrintableString is a restricted IA5String defined as: printablestring = *( ps-char ) ps-restricted-char = 1DIGIT / 1ALPHA / " " / "'" / "+" / "," / "-" / "." / "/" / ":" / "=" / "?" ps-delim = "(" / ")" ps-char = ps-delim / ps-restricted-char This can be used to represent real printable strings in EBNF. * 3.3.4. T.61String In cases where T.61 strings are only used for conveying human interpreted information, the aim of a mapping should be to render the characters appropriately in the remote character set, rather than to maximise reversibility. For these cases, the mappings defined in CCITT Recommendation X.408 (1988) should be used [CCITT/ISO88a]. These will then be encoded in ASCII. There is also a need to represent Teletex Strings in ASCII, for some aspects of O/R Address. For these, the following encoding is used: Kille [page 33] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 teletex-string = *( ps-char / t61-encoded ) | t61-encoded = "{" 1* t61-encoded-char "}" | t61-encoded-char = 3DIGIT | Common characters are mapped simply. Other octets are mapped using a quoting mechanism similar to the printable string | mechanism. Each octet is represented as 3 decimal digits. There are a number of places where a string may have a Teletex and/or Printable String representation. The following BNF is used to represent this. teletex-and-or-ps = [ printablestring ] [ "*" teletex-string ]| The natural mapping is restricted to EBNF.ps-char, in order to make the full BNF easier to parse. 3.3.5. UTCTime Both UTCTime and the RFC 822 822.date-time syntax contain: Year (lowest two digits), Month, Day of Month, hour, minute, second (optional), and Timezone. 822.date-time also contains an optional day of the week, but this is redundant. Therefore a symmetrical mapping can be made between these constructs. Note: In practice, a gateway will need to parse various illegal variants on 822.date-time. In cases where 822.date-time cannot be parsed, it is recommended that the derived UTCTime is set to the value at the time of translation. The UTCTime format which specifies the timezone offset should be used. 3.3.6. Integer A basic ASN.1 Integer will be mapped onto EBNF.numericstring. In many cases ASN.1 will enumerate Integer values or use ENUMERATED. An EBNF encoding labelled-integer is provided. When mapping from EBNF to ASN.1, only the integer value is mapped, and the associated text is discarded. When mapping from ASN.1 to EBNF, addition of an appropriate text label is strongly encouraged. Kille [page 34] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 labelled-integer ::= key-string "(" numericstring ")" 3.3.7. Object Identifier Object identifiers are represented in a form similar to that given in ASN.1. The numbers are mandatory, to ease encoding. It is recommended that as many strings as possible are used, to facilitate user recognition. object-identifier ::= [ defined-value ] oid-comp-list oid-comp-list ::= oid-comp oid-comp-list | oid-comp defined-value ::= key-string oid-comp ::= [ key-string ] "(" numericstring ")" key-string = *key-char key-char = 3.4. Encoding ASCII in Printable String Some information in RFC 822 is represented in ASCII, and needs to be mapped into X.400 elements encoded as printable string. For this reason, a mechanism to represent ASCII encoded as PrintableString is needed. A structured subset of EBNF.printablestring is now defined. This can be used to encode ASCII in the PrintableString character set. ps-encoded = *( ps-restricted-char / ps-encoded-char ) ps-encoded-char = "(a)" ; (@) / "(p)" ; (%) / "(b)" ; (!) / "(q)" ; (") / "(u)" ; (_) / "(l)" ; "(" / "(r)" ; ")" / "(" 3DIGIT ")" Kille [page 35] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 The 822.3DIGIT in EBNF.ps-encoded-char must have range 0-127, and is interpreted in decimal as the corresponding ASCII character. Special encodings are given for: at sign (@), percent (%), exclamation mark/bang (!), double quote ("), underscore (_), left bracket ((), and right bracket ()). These characters, with the | exception of round braces, are not included in PrintableString, | but are common in RFC 822 addresses. The abbreviations will ease specification of RFC 822 addresses from an X.400 system. A reversible mapping between PrintableString and ASCII can now be defined. The reversibility means that some values of printable string (containing round braces) cannot be generated from ASCII. Therefore, this mapping must only be used in cases where the printable strings may only be derived from ASCII (and will therefore have a restricted domain). For example, in this specification, it is only applied to a Domain defined attribute which will have been generated by use of this specification and a value such as "(" would not be possible. To encode ASCII as PrintableString, the EBNF.ps-encoded syntax is used, with all EBNF.ps-restricted-char mapped directly. All other 822.CHAR are encoded as EBNF.ps-encoded-char. To encode PrintableString as ASCII, parse PrintableString as EBNF.ps-encoded, and then reverse the previous mapping. If the PrintableString cannot be parsed, then the mapping is being applied in to an inappropriate value, and an error should be given to the procedure doing the mapping. In some cases, it may be preferable to pass the printable string through unaltered. Some examples are now given. Note the arrows which indicate asymmetrical mappings: PrintableString ASCII 'a demo.' <-> 'a demo.' foo(a)bar <-> foo@bar (q)(u)(p)(q) <-> "_%" (a) <-> @ (l)a(r) <-> (a) (126) <-> ~ | ( -> ( (l) <-> ( Kille [page 36] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 Chapter 4 - Addressing Addressing is probably the trickiest problem of an X.400 <-> RFC 822 gateway. Therefore it is given a separate chapter. This | chapter, as a side effect, also defines a textual representation | of an X.400 O/R Address. Initially we consider an address in the (human) mail user sense of "what is typed at the mailsystem to reference a mail user". A basic RFC 822 address is defined by the EBNF EBNF.822-address: 822-address = [ route ] addr-spec In an 822-MTS protocol, the originator and each recipient should be considered to be defined by such a construct. In an RFC 822 header, the EBNF.822-address is encapsulated in the 822.address syntax rule, and there may also be associated comments. None of this extra information has any semantics, other than to the end user. The basic X.400 O/R Address, used by the MTS for routing, is defined by MTS.ORAddress. In IPMS, the MTS.ORAddress is encapsulated within IPMS.ORDescriptor. It can be seen that RFC 822 822.address must be mapped with | IPMS.ORDescriptor, and that RFC 822 EBNF.822-address must be | mapped with MTS.ORAddress. 4.1. A textual representation of MTS.ORAddress MTS.ORAddress is structured as a set of attribute value pairs. It is clearly necessary to be able to encode this in ASCII for gatewaying purposes. All aspects should be encoded, in order to guarantee return of error messages, and to optimise third party replies. 4.2. Basic Representation An O/R Address has a number of structured and unstructured attributes. For each unstructured attribute, a key and an encoding is specified. For structured attributes, the X.400 Kille [page 37] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 attribute is mapped onto one or more attribute value pairs. For domain defined attributes, each element of the sequence will be mapped onto a triple (key and two values), with each value having the same encoding. The attributes are as follows, with 1984 attributes given in the first part of the table. For each | attribute, a reference is given, consisting of the relevant | sections in X.402 / ISO 10021-2, and the extension identifier for | 88 only attributes: Attribute (Component) Key Enc Ref Id| 84/88 Attributes MTS.CountryName C P 18.3.3 | MTS.AdministrationDomainName ADMD P 18.3.1 | MTS.PrivateDomainName PRMD P 18.3.21 | MTS.NetworkAddress X121 N 18.3.7 | MTS.TerminalIdentifier T-ID N 18.3.23 | MTS.OrganizationName O P/T 18.3.9 | MTS.OrganizationalUnitNames.value OU P 18.3.10 | MTS.NumericUserIdentifier UA-ID N 18.3.8 | MTS.PersonalName PN P/T 18.3.12 | MTS.PersonalName.surname S P/T 18.3.12 | MTS.PersonalName.given-name G P/T 18.3.12 | MTS.PersonalName.initials I P/T 18.3.12 | MTS.PersonalName .generation-qualifier GQ P/T 18.3.12 | MTS.DomainDefinedAttribute.value DD P/T 18.1 | 88 Attributes MTS.CommonName CN P/T 18.3.2 1 | MTS.TeletexCommonName CN P/T 18.3.2 2 | MTS.TeletexOrganizationName O P/T 18.3.9 3 | MTS.TeletexPersonalName PN P/T 18.3.12 4 | MTS.TeletexPersonalName.surname S P/T 18.3.12 4 | MTS.TeletexPersonalName.given-name G P/T 18.3.12 4 | MTS.TeletexPersonalName.initials I P/T 18.3.12 4 | MTS.TeletexPersonalName .generation-qualifier GQ P/T 18.3.12 4 | MTS.TeletexOrganizationalUnitNames .value OU P/T 18.3.10 5 | MTS.TeletexDomainDefinedAttribute .value DD P/T 18.1 6 | Kille [page 38] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 MTS.PDSName PD-SYSTEM P 18.3.11 7 | MTS.PhysicalDeliveryCountryName PD-C P 18.3.13 8 | MTS.PostalCode POSTCODE P 18.3.19 9 | MTS.PhysicalDeliveryOfficeName PD-OFFICE P/T 18.3.14 10| MTS.PhysicalDeliveryOfficeNumber PD-OFFICE-NUM P/T 18.3.15 11| MTS.ExtensionORAddressComponents PD-EXT-D P/T 18.3.4 12| MTS.PhysicalDeliveryPersonName PD-PN P/T 18.3.17 13| MTS.PhysicalDeliveryOrganizationName PD-O P/T 18.3.16 14| MTS.ExtensionPhysicalDelivery AddressComponents PD-EXT-LOC P/T 18.3.5 15| MTS.UnformattedPostalAddress PD-ADDRESS P/T 18.3.25 16| MTS.StreetAddress STREET P/T 18.3.22 17| MTS.PostOfficeBoxAddress PO-BOX P/T 18.3.18 18| MTS.PosteRestanteAddress POSTE-RESTANTE P/T 18.3.20 19| MTS.UniquePostalName PD-UNIQUE P/T 18.3.26 20| MTS.LocalPostalAttributes PD-LOCAL P/T 18.3.6 21| MTS.ExtendedNetworkAddress .e163-4-address.number NET-NUM N 18.3.7 22| MTS.ExtendedNetworkAddress .e163-4-address.sub-address NET-SUB N 18.3.7 22| MTS.ExtendedNetworkAddress .psap-address NET-PSAP X 18.3.7 22| MTS.TerminalType NET-TTYPE I 18.3.24 23| The following keys identify different encodings: | Key Encoding | P printablestring | N numericstring | T teletex-string | P/T teletex-and-or-ps | I labelled-integer | X presentation-address | In cases where an attribute can be encoded as either a | PrintableString or NumericString (Country, ADMD, PRMD), the | NumericString encoding should be used if the string contains only | digits. | The BNF for presentation-address is taken from the specification | "A String Encoding of Presentation Address" [Kille89a]. | Kille [page 39] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 There are a number of cases where the P/T (teletex-and-or-ps) | representation is used. Where the key maps to a single | attribute, this choice is reflected in the encoding of the | attribute (attributes 10-21). For most of the 1984 attributes | and common name, there is a printablestring and a teletex | variant. This pair of attributes is mapped onto the single | component here. This will give a clean mapping for the common | cases where only one form of the name is used. 4.2.1. Encoding of Personal Name Handling of Personal Name and Teletex Personal Name based purely on the EBNF.standard-type syntax defined above is likely to be clumsy. It seems desirable to utilise the "human" conventions for encoding these components. A syntax is proposed here. It is designed to cope with the common cases of O/R Address specification where: 1. There is no generational qualifier 2. Initials contain only letters 3. Given Name does not contain full stop ("."), and is at least two characters long. 4. If Surname contains full stop, then it may not be in the first two characters, and either initials or given name is present. The following EBNF is defined: encoded-pn = [ given "." ] *( initial "." ) surname given = 2* initial = ALPHA surname = printablestring Kille [page 40] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 Subject to the above restrictions, this is a reversible mapping. For example: GivenName = "Marshall" Surname = "Rose" Maps with "Marshall.Rose" Initials = "MT" Surname = "Rose" Maps with "M.T.Rose" GivenName = "Marshall" Initials = "MT" Surname = "Rose" Maps with "Marshall.M.T.Rose" Note that X.400 suggest that Initials is used to encode ALL initials. Therefore, the proposed encoding is "natural" when either GivenName or Initials, but not both, are present. The case where both are present can be encoded, but this appears to be contrived! 4.2.2. Standard Encoding of MTS.ORAddress Given this structure, we can specify a BNF representation of an O/R Address. Kille [page 41] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 std-or-address = 1*( "/" attribute "=" value ) "/" attribute = standard-type / "RFC-822" / registered-dd-type / dd-key "." std-printablestring standard-type = key-string registered-dd-type = key-string dd-key = key-string value = std-printablestring std-printablestring | = *( std-char / std-pair ) std-char = <"{", "}", "*", and any ps-char except "/" and "="> std-pair = "$" ps-char The standard-type, is any key defined in the table in | Section 4.2, except PN, and DD. The value, after quote removal, should be interpreted according to the defined encoding. If the standard-type is PN, the value is interpreted | according to EBNF.encoded-pn, and the components of | MTS.PersonalName and/or MTS.TeletexPersonalName derived accordingly. If dd-key is the recognised Domain Defined string (DD), then | the type and value should be interpreted according to the syntax implied from the encoding, and aligned to either the teletex or | printable string form. Key and value should have the same | encoding. If value is "RFC-822", then the (printable string) Domain Defined Type of "RFC-822" is assumed. This is an optimised encoding of the domain defined type defined by this specification. The matching of all keywords should be done in a case- independent manner. If the value is registered-dd-type, if the value is Kille [page 42] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 registered at the SRI NIC as an accepted Domain Defined Attribute type, then the value should be interpreted accordingly. This restriction maximises the syntax checking which can be done at a gateway. * 4.3. EBNF.822-address <-> MTS.ORAddress Ideally, the mapping specified would be entirely symmetrical and global, to enable addresses to be referred to transparently in the remote system, with the choice of gateway being left to the Message Transfer Service. There are two fundamental reasons why this is not possible: 1. The syntaxes are sufficiently different to make this awkward. 2. In the general case, there would not be the necessary administrative co-operation between the X.400 and RFC 822 worlds, which would be needed for this to work. Therefore, an asymmetrical mapping is defined, which can be symmetrical where there is appropriate administrative control. 4.3.1. X.400 encoded in RFC 822 The std-or-address syntax is used to encode O/R Address information in the 822.local-part of EBNF.822-address. Further O/R Address information may be associated with the 822.domain component. This cannot be used in the general case, basically due to character set problems, and lack of order in X.400 O/R Addresses. The only way to encode the full PrintableString character set in a domain is by use of the 822.domain-ref syntax | (i.e. 822.atom). This is likely to cause problems on many systems. The effective character set of domains is in practice reduced from the RFC 822 set, by restrictions imposed by domain conventions and policy. A generic 822.address consists of a 822.local-part and a sequence of 822.domains (e.g., <@domain1,@domain2:user@domain3>). All except the 822.domain associated with the 822.local-part (domain3 in this case) should be considered to specify routing within the RFC 822 world, and will not be interpreted by the gateway (although they may have identified the gateway from within the RFC 822 world). The 822.domain associated with the Kille [page 43] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 822.local-part may also identify the gateway from within the RFC 822 world. This final 822.domain may be used to determine some number of O/R Address attributes. The following O/R Address attributes are considered as a hierarchy, and may be specified by the domain. They are (in order of hierarchy): Country, ADMD, PRMD, Organisation, Organisational Unit There may be multiple Organisational Units. Associations may be defined between domain specifications, and some set of attributes. This association proceeds hierarchically. For example, if a domain implies ADMD, it also implies country. Subdomains under this are associated according to the O/R Address hierarchy. For example: => "AC.UK" might be associated with C="GB", ADMD="GOLD 400", PRMD="UK.AC" then domain "R-D.Salford.AC.UK" maps with C="GB", ADMD="GOLD 400", PRMD="UK.AC", O="Salford", OU="R-D" There are three basic reasons why a domain/attribute mapping might be maintained, as opposed to using simply subdomains: 1. As a shorthand to avoid redundant X.400 information. In particular, there will often be only one ADMD per country, and so it does not need to be given explicitly. 2. To deal with cases where attribute values do not fit the syntax: domain-syntax = alphanum [ *alphanumhyphen alphanum ] alphanum = alphanumhyphen = Although RFC 822 allows for a more general syntax, this restricted syntax is chosen as it is the one chosen by the various domain service administrations. 3. To deal with missing elements in the hierarchy. A domain may be associated with an omitted attribute in conjunction Kille [page 44] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 with several present ones. When performing the algorithmic insertion of components lower in the hierarchy, the omitted value should be skipped. For example, if "HNE.EGM" is | associated with "C=TC", "ADMD=ECQ", "PRMD=HNE", and omitted | organisation, then "ZI.HNE.EGM" is mapped with "C=TC", | "ADMD=ECQ", "PRMD=HNE", "OU=ZI". It should be noted that attributes may have null values, and that this is treated separately from omitted attributes (whilst it would be bad practice to treat these two cases differently, they must be allowed for). This set of mappings need only be known by the gateways relaying between the RFC 822 world, and the O/R Address space associated with the mapping in question. However, it is desirable (for the optimal mapping of third party addresses) for all gateways to know these mappings. A format for the exchange of this information is defined in Appendix F. The remaining attributes are encoded on the LHS, using the | EBNF.std-or-address syntax. For example: /I=J/S=Linnimouth/GQ=5/@Marketing.Widget.COM | encodes the MTS.ORAddress consisting of: MTS.CountryName = "TC" | MTS.AdministrationDomainName = "BTT" | MTS.OrganizationName = "Widget" | MTS.OrganizationalUnitNames.value = "Marketing" MTS.PersonalName.surname = "Linnimouth" MTS.PersonalName.initials = "J" MTS.PersonalName.generation-qualifier = "5" The first three attributes are determined by the domain | Widget.COM. Then, the first element of OrganizationalUnitNames is determined systematically, and the remaining attributes are encoded on the LHS. In an extreme case, all of the attributes will be on the LHS. As the domain cannot be null, the RHS will simply be a domain indicating the gateway. The RHS (domain) encoding is designed to deal cleanly with common addresses, and should be used where possible. In particular, it covers the Mnemonic O/R Address using a 1984 compatible encoding. This is seen as the dominant form of O/R Kille [page 45] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 Address. Use of other forms of O/R Address, and teletex encoded attributes will require an LHS encoding. As a further mechanism to simplify the encoding of common cases, where the only attributes to be encoded on the LHS is a (non-Teletex) Personal Name attributes which comply with the | restrictions of 4.2.1, the 822.local-part may be encoded as EBNF.encoded-pn. In the previous example, if the GenerationQualifier was not present, the encoding | J.Linnimouth@Marketing.Widget.COM could be used. From the standpoint of the RFC 822 Message Transfer System, the domain specification is simply used to route the message in the standard manner. The standard domain mechanisms are used to identify gateways, and are used to select appropriate gateways for the corresponding O/R Address space. In most cases, this will be done by registering the higher levels, and assuming that the gateway can handle the lower levels. There has been an implicit assumption that an RFC 822 domain is either X.400 or RFC 822. This is pragmatic, but undesirable, as the namespace should be structured on a logical basis which does not necessarily correspond to the choice of Message Transfer protocols. The restriction can be lifted, provided that the name | service deals with multiple message transfer protocols. It could also be achieved with the DARPA Domain Nameserver scheme by use of the WKS mechanism. However, this does not fit with current usage of the scheme. 4.3.2. RFC 822 encoded in X.400 In some cases, the encoding defined above may be reversed, to give a "natural" encoding of genuine RFC 822 addresses. This depends largely on the allocation of appropriate management domains. The general case is mapped by use of domain defined attributes. A Domain defined type "RFC-822" is defined. The | associated attribute value is an ASCII string encoded according | to Section 3.3.3 of this specification. The interpretation of the ASCII string depends on the context of the gateway. 1. In the context of RFC 822, and RFC 920 [Crocker82a,Postel84a], the string can be used directly. Kille [page 46] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 2. In the context of the JNT Mail protocol, and the NRS [Kille84a,Larmouth83a], the string should be interpreted according to Mailgroup Note 15 [Kille84b]. 3. In the context of UUCP based systems, the string should be interpreted as defined in [Horton86a]. Other O/R Address attributes will be used to identify a context in which the O/R Address will be interpreted. This might be a Management Domain, or some part of a Management Domain which identifies a gateway MTA. For example: C = "GB" ADMD = "GOLD 400" PRMD = "UK.AC" O = "UCL" OU = "CS" "RFC-822" = "Jimmy(a)WIDGET-LABS.CO.UK" | OR C = "TC" | ADMD = "Wizz.mail" | PRMD = "42" | "rfc-822" = "postel(a)venera.isi.edu" | Note in each case the PrintableString encoding of "@" as "(a)". In the second example, the "RFC-822" domain defined attribute is interpreted everywhere within the (Private) Management Domain. In the first example, further attributes are needed within the Management Domain to identify a gateway. Thus, this scheme can be used with varying levels of Management Domain co-operation. 4.3.3. Component Ordering In most cases, ordering of O/R Address components is not significant for the mappings specified. However, Organisational Units (printable string and teletex forms) and Domain Defined Attributes are specified as SEQUENCE, in MTS.ORAddress, and so their order may be significant. This specification needs to take account of this: 1. To allow consistent mapping into the domain hierarchy Kille [page 47]