4. Addressing and Message IDs
Addressing is the most complex aspect of X.400 <-> RFC 822std11(-> 2822prop) gateway and is therefore given a separate chapter. This chapter also discusses message identifiers, as they are closely linked to addresses. This chapter, as a side effect, also defines a textual representation of an X.400 OR Address. This specification has much similarity to the X.400(92) representation of addresses. This was because early versions of this specification were a major input to this work. This specification retains compatibility with earlier versions. The X.400 specification of address representation can be parsed but is not generated.
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 822std11(-> 2822prop) address is defined by the EBNF EBNF.822-address:
822-address = [ route ] addr-spec
These definitions are taken from RFC 822std11(-> 2822prop). In SMTP (or another 822- MTS protocol), the originator and each recipient are considered to be defined by such a construct. In an RFC 822std11(-> 2822prop) 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 OR Address, used by the MTS for routing, is defined by MTS.ORAddress. In IPMS, the MTS.ORAddress is encapsulated within IPMS.ORDescriptor.
The RFC 822std11(-> 2822prop) 822.address is mapped with IPMS.ORDescriptor, and that RFC 822std11(-> 2822prop) EBNF.822-address is mapped with MTS.ORAddress.
Section 4.1 defines a textual representation of an OR Address, which is used throughout the rest of this specification. This text representation is designed to represent an X.400 address in the LHS (left hand side) or local part of an RFC 822std11(-> 2822prop) address, and so this representation gives a mechanism to represent X.400 addresses within RFC 822std11(-> 2822prop) addresses.
Section 4.2 describes global equivalence mapping between parts of the X.400 and RFC 822std11(-> 2822prop) name spaces, and defines the concept of a MIXER Conformant Global Address Mapping (MCGAM). Gateways conforming to this specification shall support MCGAMs.
Section 4.3 is the core part of this chapter, and defines the mapping mechanism.
4.1. A textual representation of MTS.ORAddress
MTS.ORAddress is structured as an ordered set of attributes (type/value pairs). It is clearly necessary to be able to encode this in ASCII for gatewaying purposes. All components shall be encoded, in order to guarantee return of error messages, and to optimise third party replies.
4.1.1. Basic OR Address Representation
An OR 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 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 attribute key 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. The attribute key table follows:
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 P 18.3.23 MTS.OrganizationName O P/T 18.3.9 MTS.OrganizationalUnitNames.value OU P/T 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.DomainDefineAttribute.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 MTS.PDSName PD-SERVICE P 18.3.11 7 MTS.PhysicalDeliveryCountryName PD-C P 18.3.13 8 MTS.PostalCode PD-CODE 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-ADDRESS 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-DELIVERY P/T 18.3.5 15 MTS.UnformattedPostalAddress PD-ADDRESS UPA 18.3.25 16 MTS.StreetAddress PD-STREET P/T 18.3.22 17 MTS.PostOfficeBoxAddress PD-BOX P/T 18.3.18 18 MTS.PosteRestanteAddress PD-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 T-TY I 18.3.24 23
The following keys identify different EBNF encodings, which are associated with the ASCII representation of MTS.ORAddress.
Key Encoding
P printablestring
N numericstring
T teletex-string
P/T teletex-and-or-ps
UPA upa-string
I labelled-integer
X presentation-address
The EBNF for presentation-address is taken from the specification RFC 1278 "A String Encoding of Presentation Address" [23].
In most cases, the EBNF encoding maps directly to the ASN.1 encoding of the attribute. There are a few exceptions. In cases where an attribute can be encoded as either a PrintableString or NumericString (Country, ADMD, PRMD), either form is mapped into the EBNF. When generating ASN.1, the NumericString encoding shall be used if the string contains digits and only digits.
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 example:
/CN=yen*{165}/
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. If there is teletex attribute or teletex component only, and it contains only characters in the printable string character set, it shall be represented in the EBNF as if it had been encoded as printable string. A single printable string representation shall also be done when both forms are present and they have the same printable string representation.
The Unformatted Postal Address has a slightly more complex mapping onto a variant of (teletex-and-or-ps), defined as:
upa-string = [ printable-upa ] [ "*" teletex-string ]
printable-upa = printablestring *( "|" printablestring )
The optional teletex part is straightforward. There is an (optional) sequence of printable strings which are mapped in order. For example:
/PD-ADDRESS=The Dome|The Square|Richmond|England/
X.400 (1992) has introduced a string representation of OR Addresses (see F.401, Annex B). This has specified a number of string keywords for attributes. As earlier versions of this specification were an input to this work, many of the keywords are the same. To increase compatibility, the following alternative values shall be recognised when mapping from RFC 822std11(-> 2822prop) to X.400. These shall not be generated when mapping from X.400 to RFC 822std11(-> 2822prop). The following keyword alternative table and the subsequent paragraph lists alternative keywords.
Keyword Alternative
ADMD A
PRMD P
GQ Q
X121 X.121
UA-ID N-ID
PD-OFFICE-NUM PD-OFFICE NUMBER
PD-OFFICE-NUM PD-OFN
PD-EXT-ADDRESS PD-EA
PD-EXT-DELIVERY PD-ED
PD-OFFICE PD-OF
PD-STREET PD-S
PD-UNIQUE PD-U
PD-LOCAL PD-L
PD-RESTANTE PD-R
PD-BOX PD-B
PD-CODE PD-PC
PD-SERVICE PD-SN
DD DDA
NET-NUM E.164
NET-PSAP PSAP
PD-ADDRESS PD-A
When mapping from RFC 822std11(-> 2822prop) to X.400, the keywords defined in this paragraph shall be recognized. The ordered keywords: OU1, OU2, OU3, and OU4, shall be recognised. If these are present, no keyword OU shall be present. These will be treated as ordered values of OU. PD-A1, PD-A2, PD-A3, PD-A4, PD-A5, PD-A6 shall be treated as ordered lines. If present, these will be assembled with separating line feeds to form a single physical address. In this case PD-ADDRESS (or PD-A) shall not be present. Similarly, there are ordered keywords for domain defined attributes: DD1, DD2, DD3, DD4,
If ISDN is present, it may be interpreted as an E.163/164 address, using local heuristics to parse the string. X.400 defines the key, but does not give an interpretation of the value.
For T-TY (Terminal Type), the X.400 recommended values are preferred, but other values are allowed. These values are: tlx (3); ttx (4); g3fax (5); g4fax (6); ia5 (7); and vtx (8).
4.1.2. Encoding of Personal Name
Handling of Personal Name and Teletex Personal Name is a common requirement. Therefore MIXER defines an alternative to the EBNF.standard-type syntax, which utilises the "human" conventions for encoding these components. A syntax is defined, which is designed to provide a clean encoding for the common cases of OR Address specification where:
1. There is no generational qualifier
2. Initials, if present, contain only letters
3. Given Name, if present, does not contain full stop ("."),
and is at least two characters long.
4. Surname does not contain full stop in the first two
characters.
5 If Surname is the only component, it does not contain full
stop.
The following EBNF is defined:
encoded-pn = [ given "." ] *( initial "." ) surname
given = 2*<ps-char not including ".">
initial = ALPHA
surname = printablestring
This is used to map from any string containing only printable string characters to an OR address personal name. To map from a string to OR Address components, parse the string according to the EBNF. The given name and surname are assigned directly. All EBNF.initial tokens are concatenated without intervening full stops to generate the initials component.
For an OR address which follows the above restrictions, a string is derived in the natural manner. In this case, the mapping will be reversible.
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 suggests that Initials is used to encode all initials except the surname (X.402 section 18.3.12). Therefore, the defined encoding is "natural" when either GivenName or Initials, but not both, are present. The case where both are present can be encoded.
4.1.3. Standard Encoding of MTS.ORAddress
Given this structure, we can specify an EBNF representation of an OR Address. The output format of addresses is defined by EBNF.std-or- address. The more flexible input format is defined by EBNF.std-or- address-input. The input EBNF has been added subsequent to RFC 1327(-> 2156prop), to reflect the formal incorporation of a number of heuristics. The address element separator on input may be "/", ";", or a mixture of these. The output format is used in all examples.
std-or-address = 1*( "/" attribute "=" value ) "/"
attribute = standard-type
/ "RFC-822"
/ dd-key "." std-printablestring
std-or-address-input = [ sep pair ] sep pair *( sep pair )
sep [ pair sep ]
sep = "/" / ";"
pair = input-attribute "=" value
input-attribute = attribute
/ dd-key ":" std-printablestring
standard-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
For address generation, the standard-type is any key defined in the key table in Section 4.1, except PN, and DD. For address parsing, other key values from Section 4.1 are also valid. The EBNF leads to a set of attribute/value pairs. The value is interpreted according to the EBNF encoding defined in the table.
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) or one of the alternatives defined in Section 4.1, then the type and value are interpreted according to the syntax implied from the encoding, and aligned to either the teletex or printable string form. Key and value shall 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 shall be done in a case-independent manner.
EBNF.std-or-address uses the characters "/" and "=" as delimiters. Domain Defined Attributes and any value may contain these characters. A quoting mechanism, using the non-printable string "$" is used to allow these characters to be represented.
If an address of this syntax is parsed, and a country value is present, but no ADMD, the string shall be interpreted as if an ADMD value of single space had been specified.
4.2. Global Address Mapping
From a user perspective, the ideal mapping 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
impossible.
2 There is insufficient administrative co-operation between
the X.400 and RFC 822std11(-> 2822prop) name registration authorities for this
to work.
Another way to view this situation is to see that there is not a full global equivalence between X.400 and RFC 822std11(-> 2822prop) addressing. To meet user needs to the extent possible, this specification provides for equivalence where there is sufficient co-operation. To be useful, this equivalence shall be recognised and interpreted in the same way by all gateways. Therefore, an asymmetrical mapping is defined, which can be symmetrical where there is appropriate administrative co-operation. Section 4.3 describes the asymetrical aspects. This section describes a mechanism to enable the administrative co- ordination for symmetrical mappings.
In order to achieve a symmetrical mapping there is a need to define an administrative equivalence between parts of the OR Address and Domain namespaces. Previous version of this specification did this by definition of a global set of mappings. MIXER defines the concept of a MIXER Conformant Global Address Mapping (MCGAM). This acronym is defined so that it is very clear what is being referenced.
The X.400 and Internet Mail address spaces are hierarchical. It is possible to define an equivalence between two points in the hierarchies, such that addresses below that point can be derived in an algorithmic manner. An MCGAM is a mapping from a point in one hierarchy to a point in the other hierarchy. An "MGGAM pair" is a pair of symmetrical mappings between two points. To define an MCGAM, the following shall apply:
1. The authority defining the MCGAM shall have responsibility for BOTH of the namespaces between which the MCGAM is defined. 2. The authority defining the MCGAM is responsible to ensure that addresses allocated below the two equivalence points conform to the rules set out below. 3. The authority defining the MCGAM is responsible to ensure that addresses which are generated according to the MCGAM are routed correctly.
In general, MCGAMs will be independent. In some cases, a set of MCGAMs may be related (e.g., where one MCGAM defines a mapping for an organization and a second MCGAM defines an excpetion for a subtree within the organization). In this case, the related set of MCGAMs shall be treated as a single MCGAM for distribution purposes.
The existence of an MCGAM does not imply routability and access for all users.
The authority defining an MCGAM may simply use this mapping locally. This will often be the case in a "local scenario" gateway. Because of third party addressing, a MIXER gateway will work best with the maximum number of MCGAMs. Therefore, three mechanisms are defined to enable publication and exchange of MCGAMs:
1. Distribution of text tables. This is described in Appendix
F of this specification.
2. Distribution by Domain Name Service. This is described in
RFC 2163prop [3].
3. Distribution by X.500 Directory Service. This is defined
in RFC 2164prop [26].
The following sections define how the MCGAM namespace equivalence is modelled. The Internet Domain Namespace defines a simple hierarchy. For the purposes of this mapping, only parts of the namespace where domains conform to the EBNF domain-syntax are allowed.
domain-syntax = alphanum [ *alphanumhyphen alphanum ]
alphanum = <ALPHA or DIGIT>
alphanumhyphen = <ALPHA or DIGIT or HYPHEN>
Although RFC 822std11(-> 2822prop) allows for a more general syntax, this restricted syntax is used in MIXER as it is the one chosen by the various domain service administrations. In practice, it reflects all RFC 822std11(-> 2822prop) usage.
The following OR Address attributes are considered as a hierarchy, and may be specified by the domain. They are (in order of the hierarchy defined by MIXER):
Country, ADMD, PRMD, Organization, Organizational Units
There may be up to four ordered Organizational Units. This hierarchy reflects most usage of X.400, although X.400 may be used in other ways. In particular, it covers the Mnemonic OR Address using a 1984 compatible encoding. This is seen as the dominant form of OR Address. MCGAMs may only be used when this hierarchy applies.
An equivalence mapping is defined between two nodes in the respective hierarchies. For example:
=> "AC.UK" might be mapped with
PRMD="UK.AC", ADMD="GOLD 400", C="GB"
The mapping identifies that the management of these points in the respective hierarchies is the same (or co-operate very closely). The equivalence means that the namespaces below this equivalence point map 1:1, except where the mapping is overridden by further equivalence mappings lower down the hierarchy. This equivalence may be achieved in three ways:
1. All of the nodes below this point are RFC 822std11(-> 2822prop), and the MIXER mapping defines the X.400 addresses for these nodes. 2. All of the nodes below this point are X.400, and the MIXER mapping defines the RFC 822std11(-> 2822prop) addresses for these nodes. 3. There are X.400 and RFC 822std11(-> 2822prop) nodes below this point, and addressing is managed in a manner which ensures the equivalence. The rules to achieve this are defined by MIXER.
Each of these ways gives a framework for MCGAM definition.
When an MCGAM is defined, a systematic mapping for the inferior nodes in the two hierarchies follows. This is a 1:1 mapping between the nodes in the subtrees. For example, given the MCGAM pair defined above:
the domain "R-D.Salford.AC.UK" algorithmically maps with
OU="R-D", O="Salford", PRMD="UK.AC", ADMD="GOLD 400", C="GB"
Note that when an equivalence is defined, that this can be re-defined for lower points in the hierarchy. However, it is not possible to declare contained subtrees to be un-mappable.
The equivalence mapping also provides a mechanism to deal with missing elements in the X.400 hierarchy (most commonly the PRMD, which is the only element that may be ommitted when conforming to recent versions of X.400). A domain may be associated with an omitted attribute in conjunction with several present ones. When performing the algorithmic insertion of components lower in the hierarchy, the omitted value shall be skipped. For example:
If there is an MCGAM pair between domain HNE.EGM" and "O=HNE",
"ADMD=ECQ", "C=TC", and omitted PRMD
then
"ZI.HNE.EGM" is algorithmically mapped with "OU=I", "O=HNE",
"ADMD=ECQ", "C=TC"
Attributes may have null values, and this is treated separately from omitted attributes (while it is not ideal to make this distinction, it is useful in practice).
4.2.1. Directory and Nameserver Mappings
When a set of MCGAMs are supported by X.500 or DNS, there is the possibility that results will be indeterminate due to timeout. Lookup shall be repeated until a value is determined, in order to maintain consistent gateway operation.
Where the mapping relates to an envelope address, the gateway shall non-deliver messages according to the associated MTA's normal timeout policy. Where the mapping relates to addresses in the message header, there shall be a timeout in the range of 1-4 hours or shorter if this is required to maintain quality of service constraints. If a mapping cannot be done in this time, address encapsulation shall be used.
4.3. EBNF.822-address <-> MTS.ORAddress
This section defines the basic address mapping.
4.3.1. X.400 encoded in RFC 822std11(-> 2822prop)
This section defines how X.400 addresses are represented in RFC 822std11(-> 2822prop) addresses.
The std-or-address syntax is used to encode OR Address information in the 822.local-part of EBNF.822-address. Where there is an applicable equivalence mapping, further OR Address information is associated with the 822.domain component. This cannot be used in the general case, due to character set problems, and to the variants of X.400 OR Addresses which use different attribute types. 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 822std11(-> 2822prop) set, by restrictions imposed by domain conventions and policy [10], and by the EBNF definition in SMTP.
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) are considered to specify routing within the RFC 822std11(-> 2822prop) world, and will not be interpreted by the gateway (although they may have identified the gateway from within the RFC 822std11(-> 2822prop) world).
The 822.domain associated with the 822.local-part identifies the gateway from within the RFC 822std11(-> 2822prop) world. This final 822.domain may be used to determine some number of OR Address attributes, where this does not conflict with the first role. RFC 822std11(-> 2822prop) routing to gateways will usually be set up to facilitate the 822.domain being used for both purposes.
In the case that there is no applicable equivalence mapping, all of the X.400 address is encoded in the 822.local-part and the 822.domain identifies the gateway to which the message is being sent. This technique may be used by the RFC 822std11(-> 2822prop) user for any X.400 address where the equivalence mapping is not known.
In the case that there is an applicable MCGAM, the maximum number of attributes are encoded in the 822.domain. 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"
on the basis of an MCGAM pair between:
Domain: Widget.COM
OR Address: O="Widget", ADMD="BTT", C="TC"
Given the OR address, the domain Widget.COM is determined from the equivalence mapping and the next component is determined algorithmically to give Marketing.Widget.COM. The remaining attributes are encoded on the LHS in 822.local-part.
There is a further mechanism to simplify the encoding of common cases, where the only attributes to be encoded on the LHS are (non- Teletex) Personal Name attributes which comply with the restrictions of 4.1.2. To achieve this, the 822.local-part shall be encoded as EBNF.encoded-pn. In the previous example, if the GenerationQualifier was not present in the OR Address, it would map with the RFC 822std11(-> 2822prop) address: J.Linnimouth@Marketing.Widget.COM.
From the standpoint of the RFC 822std11(-> 2822prop) Message Transfer System, the domain specification is used to route the message in the standard manner. The standard domain mechanisms are used to select appropriate gateways for the corresponding OR Address space. It is the responsibility of the management that defines the equivalence mapping to define routing in the manner which will enable the message to be delivered.
4.3.2. RFC 822std11(-> 2822prop) encoded in X.400
The previous section showed a mapping from X.400 to RFC 822std11(-> 2822prop). In the case where the mapping was symmetrical and based on the equivalence mapping, this has also shown how RFC 822std11(-> 2822prop) is encoded in the X.400. This equivalence cannot be used for all RFC 822std11(-> 2822prop) addresses.
The general case is mapped by use of domain defined attributes. A (Printable String) 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 follows RFC 822std11(-> 2822prop), and RFC 1123std3 [10,16]. Domains shall always be fully qualified.
Other OR Address attributes will be used to identify a context in which the OR 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.
There is a limit of 128 characters in the length of value of a domain defined attribute, and an OR Address can have a maxmimum of four domain defined attributes. Where the printable string generated from the RFC 822std11(-> 2822prop) address exceeds 128 characters, additional domain defined attributes are used to enable up to 512 characters to be encoded. These attributes shall be filled completely before the next one is started. The (Printable String) DDA keywords are: RFC822C1; RFC822C2; RFC822C3. Longer addresses cannot be encoded.
MIXER defines a representation of RFC 822std11(-> 2822prop) addresses in printable string domain defined attributes. Teletex domain defined attributes with a key of RFC-822, RFC822C1; RFC822C2; RFC822C3 shall not be generated. This is for backwards compatibility reasons.
Reception of these attributes in the manner defined below is mandatory. This is to allow the possibility for future versions of MIXER to allow generation of teletex domain defined attributes. Where the values of all of these teletex domain defined attributes are printable string characters, they shall be interpreted in the same way as the printable string domain defined attributes. If this is not the case, the printable string encoding translation shall be omitted. If both teletex and printable string attributes are present, this is valid if and only if they represent exactly the same RFC 822std11(-> 2822prop) address.
4.3.3. Component Ordering
In most cases, ordering of OR Address components is not significant for the mappings specified. However, Organizational 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 2. To ensure preservation of order over multiple mappings.
There are three places where an order is specified:
1. The text encoding (std-or-address) of MTS.ORAddress as used in the local-part of an RFC 822std11(-> 2822prop) address. An order is needed for those components which may have multiple values (Organizational Unit, and Domain Defined Attributes). When generating an 822.std-or-address, components of a given type shall be in hierarchical order with the most significant component on the RHS (right hand side or domain part). If there is an Organization Attribute, it shall be to the right of any Organizational Unit attributes. These requirements are for the following reasons: - Alignment to the hierarchy of other components in RFC 822std11(-> 2822prop) addresses (thus, Organizational Units will appear in the same order, whether encoded on the RHS or LHS). - Backwards compatibility with RFC 987(-> 2156prop | 1327(-> 2156prop))/1026(-> 2156prop | 1327(-> 2156prop)). - To ensure that gateways generate consistent addresses. This is both to help end users, and to generate identical message ids. Further, it is recommended that all other attributes are generated according to this ordering, so that all attributes so encoded follow a consistent hierarchy. When generating 822.msg-id, this order shall be followed. 2. For the Organizational Units (OU) in MTS.ORAddress, the first OU in the SEQUENCE is the most significant, as specified in X.400. 3. For the Domain Defined Attributes in MTS.ORAddress, the First Domain Defined Attribute in the SEQUENCE is the most significant. Note that although this ordering is mandatory for this mapping, MIXER does not give additional implications on the ordering significance within X.400.
4.3.4. RFC 822std11(-> 2822prop) -> X.400 Basic Address Mapping
There are two basic cases: 1. X.400 addresses encoded in RFC 822std11(-> 2822prop). This will also include RFC 822std11(-> 2822prop) addresses which are given reversible encodings. 2. "Genuine" RFC 822std11(-> 2822prop) addresses. The mapping shall proceed as follows, by first assuming case 1). STAGE I. 1. If the 822-address is not of the form: local-part "@" domain take the domain which will be routed on and apply step 2 of stage 1 to derive (a possibly null) set of attributes. Then go to stage II. The gateway may reduce a source route address to this form by removal of all but the last domain. In terms of the design intentions of RFC 822std11(-> 2822prop), this would be an incorrect action. (Note that an address of the form local%part@domain is not a source route). However, in most cases, it will provide a better service to the end user, and is in line with the Internet Host Requirements. This is a reflection on the common inappropriate use of source routing in RFC 822std11(-> 2822prop) based systems, despite the discussion in the Host Requirements [10]. Either approach, or the intermediate approach of stripping only domain references which reference the local gateway are conformant to this specification. 2. If the 822.local-part uses the 822.quoted-string encoding, remove this quoting. If the resulting unquoted 822.local-part has leading space, trailing space, or two adjacent spaces go to stage II. 3. If the unquoted 822.local-part contains any characters not in PrintableString, "{", "}", "*", and "$", go to stage II. 4. Parse the (unquoted) 822.local-part according to the EBNF EBNF.std-or-address-input. Checking of upper bounds shall not be done at this point. If this parse fails, parse the local-part according to the EBNF EBNF.encoded-pn. If this parse fails, go to stage II. The result is a set of type/value pairs. 5. Associate the EBNF.attribute-value syntax (determined from the identified type) with each value, and check that it conforms. If not, go to stage II. 6. If the set of attributes forms a valid X.400 address, according to X.402, then go to step 9. All forms of X.400 address are allowed at this stage. Steps 7-8 default attributes for certain types of OR Address. 7. If the set of attributes cannot form a mnemonic form of X.400 address after addition of attributes which may be derived from the EBNF.domain (C, ADMD, PRMD, O, OU), go to stage II. 8. Attempt to parse EBNF.domain as: *( domain-syntax "." ) known-domain Where EBNF.known-domain is the longest possible match in the set of MCGAMs being used by the gateway (described in Section 4.2). EBNF.domain-syntax is the restricted domain syntax defined in Section 4.2, to which all of the domain components shall conform for the parse to be successful. If this fails, go to stage II. For each component, systematically allocate the attribute implied by each EBNF.domain-syntax component in the order: C, ADMD, PRMD, O, OU. Note that if the MCGAM used identifies an "omitted attribute", then this attribute shall be omitted in the systematic allocation. If this new component exceed an upper bound (ADMD: 16; PRMD: 16; O: 64; OU: 32) or it would lead to more than four OUs, then go to stage II with the attributes derived. The attributes derived in this step (referred to as RHS attributes) are merged with the ones derived from the LHS (step 6). In some cases, not all of the RHF attributes are used. LHS attributes are all used. C will not be in the LHS attributes. If ADMD is in the LHS attributes, only C is taken from the RHS attributes. If PRMD is in the LHS attributes, C and ADMD are taken from the RHS attributes. If O is on the LHS, C, ADMD and PRMD (if present) are taken from the RHS attributes. In other cases all RHS attributes are taken. 9. Ensure that the set of attributes conforms both to the MTS.ORAddress specification and to the restrictions on this set given in X.400, and that no upper bounds are exceeded for any attribute. If not go to stage II. 10. Build the OR Address from this information. STAGE II. This will only be reached if the RFC 822std11(-> 2822prop) EBNF.822-address is not a valid X.400 encoding. This implies that the address refers to a recipient on an RFC 822std11(-> 2822prop) system or that the encoding of the address is invalid. Such addresses shall be encoded in an X.400 OR Address using a domain defined attribute. 1. Convert the EBNF.822-address to PrintableString, as specified in Chapter 3. 2. Generate the "RFC-822" domain defined attribute from this string. 3. Build the rest of the OR Address in the manner described below. It is not always possible to encode the domain defined attribute due to length restrictions. If the limit is exceeded by a mapping at the MTS level, then the gateway shall reject the message in question. If this occurs at the IPMS level, then the action will depend on the policy being taken for IPMS encoding, which is discussed in Section 5.1.3. Use Stage I, step 8, to generate a set of attributes to build the remainder of the address. The administrative equivalence of the mappings will ensure correct routing through X.400 to a gateway back to RFC 822std11(-> 2822prop). If Stage I, step 8 does not generate a set of attributes or the address generated is unroutable, the remained of the OR address is generated as follows. The remainder of the OR address effectively identifies a source route to a gateway from the X.400 side. There are three cases, which are handled differently: SMTP Return Address This shall be set up so that errors are returned through the same gateway. Therefore, the OR Address of the local gateway shall be used. IPMS Addresses These are optimised for replying. In general, the message may end up anywhere within the X.400 world, and so this optimisation identifies a gateway appropriate for the RFC 822std11(-> 2822prop) address being converted. The 822.domain to which the address would be routed is used to select an appropriate gateway. In this case, it may be useful to use a non-local gateway, which will optimise the reply address. This information may be looked up in gateway tables in a manner equivalent to the MCGAM lookup. Because of the similarity of lookup, the three MCGAM lookup mechanisms (table, X.500, DNS) are also available to look up this information. This information is local, and a gateway may insert any appropriate (gateway) OR Address. The longest possible match on the 822.domain defines which gateway to use. This mechanism is used for any part of the X.400 namespace for which it is desirable to identify a preferred X.400 gateway in order to optimise routing. If no mapping is found for the 822.domain, a default value (typically that of the local gateway) is used. It is never appropriate to ignore the locally used MCGAMs. SMTP Recipient As the RFC 822std11(-> 2822prop) and X.400 worlds are in principle fully connected, there is no technical reason for this situation to occur. In practice, this is not the case. In some cases, routing may be configured to use X.400 to connect an RFC 822std11(-> 2822prop) island to the Internet. The information that this part of the domain space is to be routed by X.400 rather than remaining within the RFC 822std11(-> 2822prop) world shall be configured privately into the gateway in question. X.400 routing shall not make use of the presence of the RFC-822 DDA to perform X.400 routing. The OR address shall then be generated in the same manner as for an IPMS address, using the locally available MCGAMs. It is to support this case that the definition of the global domain to gateway mapping is important, as the use of this mapping will lead to a remote X.400 address, which can be routed by X.400 routing procedures. The information in this mapping shall not be used as a basis for deciding to convert a message from RFC 822std11(-> 2822prop) to X.400. Three examples are given, neither of which has applicable MCGAMs. Example 1: (Address not in "localpart" "@" "domainpart") @relay.co.uk:userb@host2 maps to c=gb; a= ; p=uk.ac; o=mr; dd.rfc-822=(a)relay.co.uk:userb(a)host2; Example 2: (Address with non printablestring characters) Tom_Harris@cs.widget.com maps to c=us; a=MCI; P=relay; dd.rfc-822=Tom(u)Harris(a)cs.widget.com; Example 3: (Address with an entry for alter.net into the OR Address of Preferred Gateway table, pointing to c=gb; A=BTglobal; P=relay) postmaster@UK.alter.net maps to c=gb; a=BTglobal; P=relay; dd.rfc-822=postmaster(a)UK.alter.net;
4.3.4.1. Heuristic for mapping RFC 822std11(-> 2822prop) to X.400
The following heuristic, which relates to ordering of address components, may be used when mapping from RFC 822std11(-> 2822prop) to X.400. The ordering of attributes may be inverted or mixed, and so the following heuristics may be applied:
If there is an Organization attribute to the left of any Org Unit attribute, assume that the hierarchy is inverted. This is to facilitate the situation where a user has input the attributes in reverse hierarchical order. To do this the gateway shall first map according to the order defined in 4.3.3. If this mapping generates an address which X.400 address verification shows to be invalid, this heuristic may be applied as an alternative to immediate rejection of the address.
4.3.5. X.400 -> RFC 822std11(-> 2822prop) Basic Address Mapping
There are two basic cases: 1. RFC 822std11(-> 2822prop) addresses encoded in X.400. 2. "Genuine" X.400 addresses. This may include symmetrically encoded RFC 822std11(-> 2822prop) addresses. When an MTS Recipient OR Address is interpreted, gatewaying will be selected if there is a single "RFC-822" domain defined attribute present. In this case, use mapping A and in other cases, use mapping B. RFC 1327(-> 2156prop) specified that this shall only be done when the gateway identfied is local or otherwise known, and identified the approach specified here as a pragmatic option. Experience has shown that this is effective in practice, despite theoretical problems. If a gateway wishes to make a mapping in a manner similar to RFC 1327(-> 2156prop), but does not wish for this global interpretation (e.g., to support an RFC 822std11(-> 2822prop) local system, which does not use global addressing), then it may choose a private domain defined attribute, different to "RFC-822". An RFC 1327(-> 2156prop) gateway might be configurable to operate in this manner. Mapping A 1. Map the domain defined attribute value to ASCII, as defined in Chapter 3, and drop all other attributes. Mapping B This is used for X.400 addresses which do not use the explicit RFC 822std11(-> 2822prop) encoding. 1. For all string encoded attributes, remove any leading or trailing spaces, and replace adjacent spaces with a single space. The only attribute which is permitted to have zero length is the ADMD. This shall be mapped onto a single space. These transformations are for lookup only. If an EBNF.std-or-address mapping is used as in 4), then the original values shall be used. 2. The numeric country codes may be mapped to the two letter values (as defined in ISO 3166). Global mappings are usually only defined in terms of the ISO 3166 codes. 3. Noting the hierarchy specified in 4.3.1 and including omitted attributes, determine the maximum