RFC 1026

Addendum to RFC 987 (Mapping between X.400 and RFC-822) 💖

• Request for Comments: 1026 🎀
• Working group: Network Working Group 🌸
• Author: S.E. Kille, University College London ✨
• Date: September 1987 📅
• Category: Proposed protocol for the Internet community. Discussion and suggestions for improvements are requested 💜
• Updates: RFC 987 (aka Mailgroup Note 19). This addendum adds to and corrects it 🦋
• Obsoletes: Nothing is named in this document 🙈

---

Status of This Memo ✨

okay so this RFC proposes a protocol for the Internet community and asks for discussion and suggestions for improvements 🫶 Distribution of this memo is unlimited 💅

This document lists a bunch of additions and corrections to RFC-987, aka Mailgroup Note 19 🌈

The addendum carries equal weight to the original spec, which MUST be used when this mapping is performed on the Internet or in the UK Academic Community. This mapping MAY also be used within the RARE community in Europe. This specification MAY be modified in the light of implementation experience, but no substantial changes are expected 🔥

1. Errata 🧚

Here are the fixes, bestie:

• In section 4.6.4, replace .. with ..
• In section 4.2.4, replace three references to 4.3.1 by 4.2.1, and one reference to 4.2.2 by 4.1.2.
• In section 5.2, replace 1 mailbox with 1#mailbox, 1 msg-id with 1#msg-id and 1 encoded-type with 1#encoded-type.

2. Component Ordering 👑

In most cases, the order of O/R name components doesn't matter for the mappings in this document 💅 BUT Organisational Units and Domain Defined Attributes are specified as SEQUENCE in P1.ORName, so their order MAY be significant. This spec needs to handle that in two ways:

• 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 MUST be specified:

• 1) On the text encoding (std-orname) of P1.ORName as used in the local-part of an RFC-822 address, the most significant component MUST be on the RHS. This applies only to those components which MAY have multiple values (Organisational Unit, and Domain Defined Attributes). Other attributes MAY be presented in any order. Note that in dmn-orname specified in Appendix F, this ordering is already implied by the current ordering requirements.
• 2) For the Organisational Units (OU) in P1.ORName, the first OU in the SEQUENCE is the most significant. This follows the "natural" hierarchy of the specification of P1.ORName, where the most significant components are defined first.
• 3) For the Domain Defined Attributes in P1.ORName, the First Domain Defined Attribute in the SEQUENCE is the most significant.

Note that although the ordering defined in 2) and 3) is mandatory for this mapping, there are NO implications on ordering significance within X.400. 🙌

3. Extensions To Deal with Omitted Components 🦋

RFC-987 turned out to be a little inflexible for some naming strategies 🙈 In particular, things get messy where Organisation or PRMD is omitted.

The following sentence of RFC-987 SHOULD be removed: 4.2.1 (Page 27):

"If one of the hierarchical components is omitted ....  tuple)."

The strategy proposed is to introduce the concept of explicit missing components to the symmetrical mapping described in 4.2.1. Basically, 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 SHOULD be skipped. For example, if GMD.DFN is associated with C=DE, ADMD=DBP, PRMD=GMD, and omitted organisation, then ZI.GMD.DFN is mapped with C=DE, ADMD=DBP, PRMD=GMD, OU=ZI. It SHOULD be noted that attributes MAY have null values, and that this is treated separately from omitted attributes. (Whilst it would be bad practice to treat these two cases differently, they MUST be allowed for in practice.) 🫶

To allow the mapping of null organisations to be represented in the specification of Appendix F, the dmn-orname syntax is extended, so that values MAY be given the symbol "@" (not a printable string character). This corresponds to an omitted attribute. The new definition is:

dmn-orname      = dmn-part *( "." dmn-part )
dmn-part        = attribute "$" value
attribute       = standard-type
                / "~" dmn-printablestring
value           = dmn-printablestring
                / "@"
dmn-printablestring
                = *( dmn-char / dmn-pair )
dmn-char        = <ps-delim, and any ps-char except ".">
dmn-pair        = "."

Appendix F - Format of address mapping tables 🌈

There is a need to specify the association between the domain and X.400 namespaces described in 4.2.1. This is defined as a table syntax, but the syntax is defined in a way that makes it suitable for use with domain nameservices (such as the Internet Domain nameservers or the UK NRS). The mapping is not symmetric, so a separate table is specified for each direction. If multiple matches are possible, the longest possible match SHOULD be used. 🔥

Various restrictions are placed on the usage of dmn-orname:

• 1) Only C, ADMD, PRMD, O, and OU MAY be used.
• 2) There MUST be a strict ordering of all components, with the most significant components on the RHS.
• 3) No components MAY be omitted from the hierarchy, although the hierarchy MAY terminate at any level. If the mapping is to an omitted component, the "@" syntax is used.

For domain -> X.400:

domain-syntax "#" dmn-orname "#"

Note that the trailing "#" is used for clarity, as the dmn-orname syntax can lead to values with trailing blanks. ✨

For example:

AC.UK#PRMD$DES.ADMD$BT.C$UK#
XEROX.COM#O$Xerox.ADMD$ATT.C$US#
HMI.DBP.DFN#O$@.PRMD$HMI.ADMD.DBP.C$DE#

For X.400 -> domain:

dmn-orname "#" domain-syntax "#"

that's the whole tea, bestie 🌈💖