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.  A notation to achieve this is described in this
   section.

3.1.1.  RFC 822

   Structured text is defined according to the Extended Backus Naur Form
   (EBNF) defined in Section 2 of RFC 822 [16].  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 SMTP
        components).  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.importance).

   2.   To describe the structure of IA5 or ASCII information not in
        an RFC 822 message.

   For all new EBNF, tokens will either be self delimiting, or be
   delimited by self delimiting tokens.  Comments and LWSP are not used
   as delimiters, except for the following cases, where LWSP may be
   inserted according to RFC 822 rules.

   -    Around the ":" in all headers

   -    EBNF.labelled-integer

   -    EBNF.object-identifier

   -    EBNF.encoded-info

   RFC 822 folding rules are applied to all headers.  Comments are never
   used in these new headers.

   This notation is used in a modified form to refer to NOTARY EBNF
   [28].  For this EBNF, the keyword EBNF it replaces with DSN, for
   example DSN.final-recipient-field fields.

3.1.2.  ASN.1

   An element is referred to with the following syntax, defined in EBNF:

      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.

   TA MTAAbstractService defined in Section 13 of X.411 / ISO 10021-4.

   FTBP File Transfer Body Part, as defined in [27].

   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 [14].  For each case, an EBNF syntax definition is
   given, for use in all of this specification, which 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 is to render the
   characters appropriately in the remote character set, rather than to
   maximise reversibility.  For these cases, there are two options, both
   of which are conformant to this specification:

   1.   The mappings to IA5 defined in ITU-T Recommendation X.408
        (1988) may be used [13].  These will then be encoded in
        ASCII.   This is the approach mandated in RFC 1327.

   2.   This mapping may be used if the characters are not contained
        within ASCII repertoire, but are all in an IANA-registered
        character set.  Use the encoding defined in RFC 1522 [9] to
        generate appropriate encoded-words.  If this mapping is
        used, the character set ISO-8859-1 shall be used if all of
        the characters needed are available in this repertoire.  In
        other cases, the character set TELETEX shall be used.  The
        details of this character set is defined in the Appendix C
        of RFC 2157.

   There is also a need to represent Teletex Strings in ASCII, for some
   aspects of OR Address.  For these, the following encoding is used:

      teletex-string   = *( ps-char / t61-encoded )
      t61-encoded      = "{" 1* t61-encoded-char "}"
      t61-encoded-char = 3DIGIT

   Characters in EBNF.ps-char are mapped simply.  Other octets,
   including control characters, are mapped using a quoting mechanism
   similar to the printable string mechanism.  Each octet is represented
   as 3 decimal digits.  For example, the Yen character (hex A5) is
   represented as {165}.  As the three character string, a, yen
   character, b, would be represented as either "a{165}b".

   The use of escape sequences follows that set down for ASN1.  in ISO
   8825-1, with the additional specifiction that the default G1 page is
   ISO Latin 1.  The page settings may be changed by escape sequences.
   Changes of the settings hold within a pair of curly brackets ({}),
   and the settings revert to the default after the right bracket (})
   (i.e., they do not carry forward to subsequent T.61 encoding).

   There are a number of places where a string may have a Teletex and/or
   Printable String representation.  The following EBNF 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.  An example is:

         "yen*{165}"

3.3.5.  UTCTime

   Both UTCTime and the RFC 822 822.date-time syntax contain: Year,
   Month, Day of Month, hour, minute, second (optional), and Timezone
   (technically a time differential in UTCTime).  822.date-time also
   contains an optional day of the week, but this is redundant.  With
   the exception of Year, 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.  Such errors may be noted in an RFC 822
      comment, to aid detection and correction.

   When mapping to X.400, the UTCTime format which specifies the
   timezone offset shall be used.

   When mapping to RFC 822, the 822.date-time format shall include a
   numeric timezone offset (e.g., -0500).

   When mapping time values, the timezone shall be preserved as
   specified.  The date shall not be normalised to any other timezone.

   RFC 822, as modified by RFC 1123, requires use of a four digit year.
   Note that the original RFC 822 uses a two digit date, which is no
   longer legal.  UTCTime uses a two digit date.  To map a year from RFC
   822 to X.400, simply use the last two digits.  To map a year from
   X.400 to RFC 822, assume that the two digit year refers to a year in
   the 10 year epoch 1980-2079.

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, a text label may be
   added.  It is recommended that this is done wherever possible and
   that clear text labels are chosen.

   A second encoding labelled-integer-2 is provided. This is used in
   DSNs, where the parsing rules will treat the text as a comment. This
   definition was not present in RFC 1327.

      labelled-integer ::= [ key-string ] "(" numericstring ")"

      labelled-integer-2 ::= [ numericstring ] "(" key-string ")"

      key-string      = *key-char
      key-char        = <a-z, A-Z, 0-9, and "-">


3.3.7.  Object Identifier

   Object identifiers are represented in a form similar to that given in
   ASN.1.  The order is the same as for ASN.1 (big-endian).  The numbers
   are mandatory, and used when mapping from the ASCII to ASN.1.  The
   key-strings are optional.  It is recommended that as many strings as
   possible are generated when mapping from ASN.1 to ASCII, to
   facilitate user recognition.

      object-identifier  ::= oid-comp object-identifier
                      | oid-comp

      oid-comp ::= [ key-string ] "(" numericstring ")"

   An example representation of an object identifier is:

      joint-iso-ccitt(2) mhs (6) ipms (1) ep (11) ia5-text (0)

      or

      (2) (6) (1)(11)(0)

   Because of the use of brackets and the conflict with the RFC 822
   comment convention, MIXER is defines so that the EBNFobject-
   identifier definition is not used in structured fields.

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
   shall 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 ")"

   The 822.3DIGIT in EBNF.ps-encoded-char shall 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
   brackets, 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.  These special encodings shall be
   interpreted in a case insensitive manner, but always generated in
   lower case.

   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 shall only be used in cases where the
   printable strings have been 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 shall 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)               <->   @
         (A)               ->    @
         (l)a(r)           <->   (a)
         (126)             <->   ~
         (                 ->    (
         (l)               <->   (

3.5.  RFC 1522

   RFC 1522 defines a mechanism for encoding other character set
   information into elements of RFC 822 Headers.  A gateway may ignore
   this encoding and treat the elements as ASCII.

   A preferred approach is for the gateway to interpret the RFC 1522
   encoding. This will not always be straightforward, because:

   1.   RFC 1522 permits an openly extensible character set choice,
        which may be broader than T.61.

   2.   It is not always possible to map all characters into the
        equivalent X.400 field.

   RFC 1522 is only applied to fields which are "for information only".
   A gateway which interprets header elements according to RFC 1522 may

   apply reasonable heuristics to minimise information loss.

Chapter 4 - Addressing and Message IDs

   Addressing is the most complex aspect of X.400 <-> RFC 822 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 822 address is defined by the EBNF EBNF.822-address:

         822-address     = [ route ] addr-spec

   These definitions are taken from RFC 822.  In SMTP (or another 822-
   MTS protocol), the originator and each recipient are 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 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 822 822.address is mapped with IPMS.ORDescriptor, and that
   RFC 822 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 822 address, and so this
   representation gives a mechanism to represent X.400 addresses within
   RFC 822 addresses.

   Section 4.2 describes global equivalence mapping between parts of the
   X.400 and RFC 822 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 822 to X.400.  These shall not be generated
   when mapping from X.400 to RFC 822.  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 822 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,
   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 822 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 822 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 2163 [3].

   3.   Distribution by X.500 Directory Service.   This is defined
        in RFC 2164 [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 822 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 822 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 822, 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 822 addresses for these nodes.

   3.   There are X.400 and RFC 822 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 822

   This section defines how X.400 addresses are represented in RFC 822
   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 822 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 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 822.local-part identifies the
   gateway from within the RFC 822 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 822 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 822 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 822
   address:  J.Linnimouth@Marketing.Widget.COM.

   From the standpoint of the RFC 822 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 822 encoded in X.400

   The previous section showed a mapping from X.400 to RFC 822.  In the
   case where  the mapping was symmetrical and based on the equivalence
   mapping, this has also shown how RFC 822 is encoded in the X.400.
   This equivalence cannot be used for all RFC 822 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 822, and RFC 1123 [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 822 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 822 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 822 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 822 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
             822 addresses (thus, Organizational Units will appear
             in the same order, whether encoded on the RHS or LHS).

   -         Backwards compatibility with RFC 987/1026.

   -         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 822 -> X.400 Basic Address Mapping

   There are two basic cases:

   1.   X.400 addresses encoded in RFC 822.  This will also include
        RFC 822 addresses which are given reversible encodings.

   2.   "Genuine" RFC 822 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 822, 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 822 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 822 EBNF.822-address is not a
   valid X.400 encoding.  This implies that the address  refers to a
   recipient on an RFC 822 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 822.

   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
      822 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 822 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 822
      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 822 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
      822 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 822 to X.400

   The following heuristic, which  relates to ordering of address
   components, may be used when mapping from RFC 822 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 822 Basic Address Mapping

   There are two basic cases:

   1.   RFC 822 addresses encoded in X.400.

   2.   "Genuine" X.400 addresses.  This may include symmetrically
        encoded RFC 822 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 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, but does not wish for this global interpretation (e.g., to
   support an RFC 822 local system, which does not use global
   addressing), then it may choose a private domain defined attribute,
   different to "RFC-822".  An RFC 1327 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
   822 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 set of attributes
        which have an associated domain specification in the local
        set of MCGAMs.  If no match is found, allocate the domain as
        described below, and go to step 5. The default domain to be
        used is the specification of the local gateway.   A gateway
        may use other domains according to private mapping tables or
        heuristics.   For example, it may choose a domain which it
        knows to provide a free gateway service to the mapped
        address.

        In cases where the address refers to an X.400 UA, it is
        important that the generated domain will correctly route to
        a gateway.  In general, this is achieved by carefully co-
        ordinating RFC 822 routing with the definition of the
        MCGAMs, as there is no easy way for the gateway to make this
        check.  One rule that shall be used is that domains with
        only one component will not route to a gateway.  If the
        generated domain does not route correctly, the address is
        treated as if no match is found.

        The gateway may also make use of a mapping equivalent to the
        MCGAM mapping to determine the domain to use.  This mapping
        is done from the OR Address hierarchy.   This is not a
        global mapping, but is a routing style mapping from the OR
        Address space, to enable a best choice domain to be
        inserted.   This mapping is supported by the three MCGAM
        lookup mechanisms.

   4.   The mapping identified  in 3) gives a domain, and an OR
        address prefix.  Follow the hierarchy: C, ADMD, PRMD, O, OU.
        For each successive component below the OR address prefix, which
        conforms to the syntax EBNF.domain-syntax (as defined in 4.3.1),
        allocate the next subdomain.  At least one attribute of the
        X.400 address shall not be mapped onto subdomain, as 822.local-
        part cannot be null.  If there are omitted attributes in the OR
        address prefix, these will have correctly and uniquely mapped to
        a domain component.   Where there is an attribute omitted below
        the prefix, all attributes remaining in the OR address shall be
        encoded on the LHS.  This is to ensure a reversible mapping. For
        example, if there is an address /S=XX/O=YY/ADMD=A/C=NN/ and a
        mapping for /ADMD=A/C=NN/ is used, then /S=XX/O=YY/ is encoded
        on the LHS.

   5.   If the address contains any attribute not used in mnemonic
        form, then all of the attributes in the address shall be encoded
        on the LHS in EBNF.std-or-address syntax, as described below.

        For addresses of mnemonic form, if the remaining components are
        personal-name components, conforming to the restrictions of
        4.2.1, then EBNF.encoded-pn is derived to form 822.local-part.
        In other cases the remaining components are simply encoded as
        822.local-part using the EBNF.std-or-address syntax.  If
        necessary, the 822.quoted-string encoding is used.  The
        following are examples of legal quoting: "a b".c@x; "a b.c"@x.
        Either form may be generated.  Generation of the latter style is
        strongly recommended.

   Four examples are given.

   Example 1: (Address with missing X.400 elements and no specific
   mapping rule for "o=sales; a=Master400; C=it", where a mapping exists
   for a=master400; C=it;)

   S=Support; O=sales;  A=Master400; C=it;

       maps to

   /S=Support/o=sales/@Master400.it

   Example 2: (Address with illegal characters in RFC822 generated
   domain if default hierarchical translation (specific mapping rule is
   existing for c=fr; a=atlas; p=autoroutes) is used)

   S=renseignements; O=Region Parisienne; P=autoroutes; A=atlas; C=fr;

       maps to

   "/S=renseignements/o=Region Parisienne/"@autoroutes.fr


   Example 3:  (Address containing elements not mappable into RFC822
   local part)

   S=Rossi; DD.cap=20100; DD.ph1=Via Larga 11; DDA.city=Milano;
   A=PtPostel; C=it;

       maps to

   "/DD.cap=20100/DD.ph1=Via Larga
   11/DD.city=Milano/S=Rossi/"@ptpostel.it


   Example 4:   (Address with an entry for A=ATT; C=us; into the domain
   of Preferred Gateway table, pointing to attmail.com)

   G=Andy; S=Wharol; O=MMNY; A=ATT; C=us;

      maps to

   /G=Andy/S=Wharol/O=MMNY@attmail.com