For X.400 services that cannot be guaranteed in RFC 822 (Alternate Recipient Allowed prohibition and DL Expansion Prohibited), MIXER defines two conformant gateway options: (1) reject the message to honor the service, or (2) gateway the message treating the service as unsupported. RFC 1327 only allowed option 2; MIXER allows both.

email

MIXER intentionally does not expose all X.400 services to RFC 822 users; the aim on the RFC 822 side is to preserve current RFC 822 service. X.400 implementors should not use MIXER as a general X.400 interface because too many X.400 aspects are inaccessible through it.

email

MIXER's conformance target is the global scenario (two interconnected global mail networks with multiple gateways), not the local scenario. A solution for the global scenario works for the local scenario, but not vice versa.

email

MIXER's core design principles are: pragmatism (no complex mappings for academic reasons), maximizing functionality, information preservation (gateways must not discard information), gateway awareness of higher-level semantics, and reversibility (double transformation should return to original state).

email

The document uses ISO specification language ('shall' = 'must', 'may' = optional, 'should' and 'may not' not used) rather than RFC 2119 keywords, because consistency with previous versions was required and ISO language can be mechanically converted to Internet language but not vice versa.

email, process

X.400 security services — Content Confidentiality, Content Integrity, Message Security Labelling, Non-Repudiation of Delivery/Origin/Submission, Message Flow Confidentiality, and Message Sequence Integrity — are not mapped onto RFC 822 because no equivalent RFC 822 mechanisms exist. If such a service is marked critical for transfer or delivery, the gateway generates a non-delivery notification; otherwise the request is silently ignored.

email, security

MIME format messages generated by MIXER are fully RFC 822 compliant and will not cause problems with non-MIME capable systems. The companion specification RFC 2157 defines body part mappings between X.400 and MIME; both documents together constitute the complete MIXER mapping.

email

When a message traverses multiple X.400 <-> RFC 822 gateways, the resulting service level is approximately the lowest common denominator (roughly the services offered by RFC 822). X.400 services without RFC 822 equivalents are not expected to survive a round-trip through multiple gateways.

email

All components of an OR Address shall be encoded in the textual representation in order to guarantee return of error messages and to optimize third-party replies.

email

Gateways conforming to MIXER shall support MCGAMs. MCGAMs may be distributed via text tables (Appendix F), DNS (RFC 2163), or X.500 Directory (RFC 2164).

email, dns

Implementations and specifications that subset the MIXER specification are non-conformant and strongly discouraged. The full mapping must be implemented.

email

Keyword matching of OR Address attribute keys (C, ADMD, PRMD, O, OU, CN, DD, etc.) shall be performed in a case-independent manner. Alternative keywords from X.400(1992) (e.g., A for ADMD, P for PRMD, DDA for DD, E.164 for NET-NUM) shall be recognized on input but shall not be generated on output.

email

MTS Messages containing Content Types other than those defined by the IPMS shall be rejected at the gateway if no other gatewaying procedure is defined. The gateway shall not map non-IPMS content types.

email

To interwork with X.400(1984) systems, Appendix B of MIXER shall be followed. The core MIXER mapping is defined using the full X.400(1988) version, not a 1984-compatible subset.

email

When generating ASN.1 for attributes encodable as either PrintableString or NumericString (Country, ADMD, PRMD), the NumericString encoding shall be used if the string contains digits and only digits.

email

When mapping a two-digit year from X.400 UTCTime to RFC 822, the year shall be assumed to fall within the epoch 1980-2079. RFC 822 (as modified by RFC 1123) requires a four-digit year; the original two-digit form is no longer legal.

email

When mapping time values, the timezone shall be preserved as specified and the date shall not be normalized to any other timezone. When mapping to X.400, the UTCTime format specifying the timezone offset shall be used. When mapping to RFC 822, a numeric timezone offset (e.g., -0500) shall be included in 822.date-time.

email

When parsing an OR Address that contains a country attribute but no ADMD, the string shall be interpreted as if an ADMD value of a single space had been specified.

email

A MIXER Conformant Global Address Mapping (MCGAM) defines administrative equivalence between a point in the X.400 OR Address hierarchy and a point in the Internet domain hierarchy, enabling algorithmic derivation of addresses below those points. MCGAMs must be defined by an authority with responsibility for both namespaces.

email, dns

A new X.400 service 'RFC 822 Header Field' is defined using X.400 extension facilities, allowing any RFC 822 header field to be represented in messages received by an X.400 UA that originated in RFC 822.

email

MIXER defines a compact personal name encoding (EBNF.encoded-pn) of the form 'Given.I.Surname' (e.g., 'Marshall.Rose', 'M.T.Rose', 'Marshall.M.T.Rose'), enabling reversible mapping of MTS.PersonalName components for common cases without generational qualifiers.

email

New RFC 822 headers are defined and registered by this standard to carry X.400 service information not natively supported by RFC 822, including: X400-Content-Type, X400-MTS-Identifier, X400-Received, X400-Originator, X400-Recipients, X400-Content-Identifier, DL-Expansion-History, Importance, Sensitivity, Supersedes, Expires, Deferred-Delivery, Autoforwarded, Autosubmitted, and others.

email

The gateway always maps RFC 822 messages and associated SMTP information to an X.400 IPM (using MTA, MTS, and IPMS Services), and Delivery Status Notifications to X.400 Reports. Going X.400 to RFC 822, IPMs and IPNs map to RFC 822 messages; Reports map to delivery status notifications. Probes are serviced by the gateway itself.

email

The OR Address attribute key table defines keys and encodings for all X.400 address attributes: 1984/1988 attributes (C, ADMD, PRMD, O, OU, PN, S, G, I, GQ, DD, X121, T-ID, UA-ID, CN) and 1988-only attributes for Teletex variants and physical delivery (PD-SERVICE, PD-C, PD-CODE, PD-OFFICE, PD-ADDRESS, PD-STREET, PD-BOX, etc.), each with P, N, T, P/T, UPA, I, or X encoding.

email

The MIXER gateway does not support X.400 security services including Content Confidentiality, Content Integrity, Message Security Labelling, Non-Repudiation of Delivery, Non-Repudiation of Origin, Message Flow Confidentiality, and Message Sequence Integrity. These properties cannot be preserved across the X.400/RFC 822 boundary, and applications requiring end-to-end security must use other mechanisms.

email, security

ASCII characters absent from PrintableString are encoded in EBNF.ps-encoded as special abbreviations: '@' as '(a)', '%' as '(p)', '!' as '(b)', '"' as '(q)', '_' as '(u)', '(' as '(l)', ')' as '(r)', and other non-PS characters as 3-digit decimal in parentheses (range 0-127). Special encodings are case-insensitive on parse but always generated in lower case.

email

T.61String characters outside the PrintableString repertoire are represented in ASCII using curly-brace quoting: each octet is encoded as 3 decimal digits inside '{}' (e.g., Yen character hex A5 as '{165}'). The default G1 page is ISO Latin 1; escape sequences may change the page setting within a pair of curly brackets, reverting after the closing '}'.

email

The labelled-integer encoding maps ASN.1 INTEGER or ENUMERATED to ASCII as an optional text label followed by the decimal integer in parentheses (e.g., 'important(2)'). The variant labelled-integer-2 reverses the order for use in DSNs. Only the numeric part is used when mapping back to ASN.1.

email

The standard OR Address textual representation (EBNF.std-or-address) encodes MTS.ORAddress as a sequence of attribute=value pairs delimited by '/' (e.g., /C=GB/ADMD=Gold 400/O=UCL/CN=Steve Kille/). A '$' quoting mechanism allows '/' and '=' characters within values. The output delimiter is always '/', while input accepts '/', ';', or mixed.

email