Domain-to-O/R-Address mappings are maintained rather than relying solely on subdomains for three reasons: as shorthand to avoid redundant X.400 information (e.g., a single ADMD per country), to handle attribute values that do not fit domain syntax, and to handle missing elements in the address hierarchy.

email

Five principles govern the specification: (1) pragmatism over academic complexity, (2) maximize cross-gateway functionality, (3) never discard information during transformation, (4) gateways must understand higher-level semantics beyond their operational layer, and (5) mappings should be reversible so a double transformation returns to the original.

email

The addressing mapping is asymmetric rather than global/symmetric because RFC 822 and X.400 syntaxes are sufficiently different, and full symmetry would require administrative cooperation between the two worlds that cannot generally be assumed. Symmetry is achievable only where appropriate administrative control exists.

email

The mapping targets X.400(1988) exclusively rather than a 1984-compatible subset. New 1988 features enable a much cleaner mapping than RFC 987's 1984-based approach. Interworking with 1984 systems is handled separately via Appendix G.

email

When encoding X.400 in RFC 822 addresses, the RHS domain encodes as many O/R attributes as possible (Country through OU) and the LHS local-part carries the remainder. This maximizes the RHS representation to cleanly support the dominant Mnemonic O/R Address form with 1984-compatible encoding.

email

For compatibility with ISO's string form of O/R Address, alternative keywords are recognized when mapping from RFC 822 to X.400 only (not generated going the other way): ADMD=A, PRMD=P, GQ=Q, X121=X.121, UA-ID=N-ID, PD-OFFICE-NUMBER='PD-OFFICE NUMBER'. Keywords OU1/OU2/OU3/OU4 are also recognized as ordered OU values.

email

For X.400(1984) interworking, Appendix G must be followed. If a message is transferred to a 1984 system via a 1988 MTA, following Appendix G provides a slightly better service. The main specification does not define a 1984-compatible subset.

email

When a message traverses multiple X.400/RFC 822 gateways, service quality degrades to approximately the lowest common denominator (RFC 822 service level). X.400 services without RFC 822 equivalents are not expected to survive a round trip through an RFC 822 network.

email

For Country, ADMD, and PRMD attributes that may be encoded as either PrintableString or NumericString, when generating ASN.1 the NumericString encoding shall be used if the string contains only digits.

email

For unsupported X.400 service elements, the gateway's behavior depends on the criticality marking: if marked critical for transfer or delivery, a non-delivery notification must be generated; otherwise the service request is silently ignored.

email

Implementations and specifications that subset this specification are strongly discouraged. The mapping is intended to preserve all services in existing RFC 822 communities.

email

MTS Messages containing Content Types other than those defined by the IPMS are not mapped by the gateway and should be rejected. Probes must be processed by the gateway itself.

email

When generating a std-or-address, multi-valued components (Organisational Units, Domain Defined Attributes) shall be in hierarchical order with the most significant component on the RHS; Organisation attributes shall appear to the right of any OU attributes. This ordering shall also be followed when generating msg-id values.

email

When mapping to X.400, the UTCTime format specifying the timezone offset shall be used. When mapping to RFC 822, the date-time format shall include a numeric timezone offset (e.g., +0000). The timezone shall be preserved as specified; dates shall not be normalized to any other timezone.

email

A globally defined set of domain-to-O/R-Address mappings is required by all gateways for correct routing. The exchange format for this information is defined in Appendix F, covering Domain->O/R Address, O/R Address->Domain, and Domain->O/R Address of Gateway tables. Administrative equivalence between mapped namespace portions must be maintained.

email

A new X.400 service 'RFC 822 Header Field' is defined using extension facilities to carry any RFC 822 header field in an X.400 message. New RFC 822 headers are also defined for X.400 services without RFC 822 equivalents, including X400-MTS-Identifier, Importance, Sensitivity, Expiry-Date, DL-Expansion-History, Language, Obsoletes, and others.

email

RFC 822 addresses are encoded in X.400 using a Domain Defined Attribute of type 'RFC-822' with a PrintableString value (using ps-encoded for non-printable characters). Where the address exceeds 128 characters, continuation DDAs with keywords RFC822C1, RFC822C2, RFC822C3 allow up to 512 total characters; longer addresses cannot be encoded.

email

The gateway model specifies that RFC 822 messages always map into an X.400 IPM (covering MTA, MTS, and IPMS services). Going X.400 to RFC 822, a message may be derived from a Report, an IPN, or an IPM. Probes are serviced by the gateway directly; MTS Messages with non-IPMS content types must be rejected.

email

The document defines Domain Defined Attribute type 'RFC-822' to be registered at IANA as an accepted DDA type for encoding RFC 822 addresses within X.400 O/R Addresses. Additional continuation DDA keywords RFC822C1, RFC822C2, and RFC822C3 extend the encoding for addresses up to 512 characters.

email, registry

X.400 security services are not mapped onto RFC 822: Content Confidentiality, Content Integrity, Message Security Labelling, Message Sequence Integrity, Non-Repudiation of Delivery, Non-Repudiation of Origin, Message Flow Confidentiality, and Message Origin Authentication are all listed as 'Not Supported'. Gateways generate non-delivery notifications for service elements marked critical that cannot be mapped.

email, security

RFC 822 to X.400 address mapping uses two stages. Stage I attempts to parse the address as X.400-encoded-in-RFC-822: derive O/R attributes from domain mapping, parse local-part as std-or-address or encoded-pn, validate attribute syntax and bounds. Stage II (fallback when Stage I fails) encodes the full RFC 822 address as an 'RFC-822' Domain Defined Attribute.

email

ASCII characters not representable in PrintableString are encoded via ps-encoded using named escape sequences: '(a)' for @, '(p)' for %, '(b)' for !, '(q)' for ", '(u)' for _, '(l)' for (, '(r)' for ), or '(' 3DIGIT ')' for any ASCII character by decimal value (0–127). Escape sequences are interpreted case-insensitively but generated in lower case.

email

O/R Addresses are encoded as std-or-address: '1*( "/" attribute "=" value ) "/"', using '/' and '=' as delimiters with '$' as a quoting character for literal '/' or '=' in values. Attribute keys include C, ADMD, PRMD, O, OU, S, G, I, GQ, CN, DD; encodings are P (PrintableString), N (NumericString), P/T (teletex-and-or-ps), I (labelled-integer), or X (presentation-address).

email

Personal names are encoded using encoded-pn syntax: '[ given "." ] *( initial "." ) surname', where given is 2+ ps-chars excluding '.', initial is a single ALPHA, and surname is a printablestring. The encoding is reversible for names meeting five restrictions (no generational qualifier, single-letter initials, given name at least 2 chars, etc.).

email

T.61 (Teletex) strings are encoded in ASCII using the quoting form: common ps-char characters map directly; other octets are represented as '{' followed by one or more 3-digit decimal octet values '}'. The combined teletex-and-or-ps encoding is '[ printablestring ] [ "*" teletex-string ]' and handles attributes that may have either or both forms.

email