1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
|
<pre>Network Working Group S.E. Kille
Request for Comments 1026 University College London
September 1987
<span class="h1">Addendum to <a href="./rfc987">RFC 987</a></span>
(Mapping between X.400 and <a href="./rfc822">RFC-822</a>)
Status of this Memo
This RFC suggest a proposed protocol for the Internet community, and
requests discussion and suggestions for improvements. Distribution
of this memo is unlimited.
This document specifies a number of additions and corrections to
<a href="./rfc987">RFC-987</a>, aka Mailgroup Note 19.
The addendum carries equal weight to the original specification,
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.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Errata</span>
- In <a href="#section-4.6.4">section 4.6.4</a>, replace ".." with ".".
- In <a href="#section-4.2.4">section 4.2.4</a>, replace three references to 4.3.1 by
4.2.1, and one reference to 4.2.2 by 4.1.2.
- In <a href="#section-5.2">section 5.2</a>, replace "1 mailbox" with "1#mailbox",
"1 msg-id" with "1#msg-id" and "1 encoded-type" with
"1#encoded-type".
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Component Ordering</span>
In most cases, ordering of O/R name components is not significant for
the mappings specified by this document. However, Organisational
Units and Domain Defined Attributes are specified as SEQUENCE, in
P1.ORName, and so their order may be significant. This specification
needs to take account of this in two ways:
1) To allow consistent mapping into the domain hierarchy
2) To ensure preservation of order over multiple mappings.
<span class="grey">Kille [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc1026">RFC 1026</a> September 1987</span>
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 <a href="./rfc822">RFC-822</a> 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 <a href="#appendix-F">Appendix F</a>, 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 signicicant. 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
Implementation of <a href="./rfc987">RFC-987</a> has proved to be a little inflexible for
some naming strategies. In particular, there are some difficulties
where Organisation or PRMD is omitted:
The following sentence of <a href="./rfc987">RFC-987</a> 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.
Essentially, a domain may be associated with an omitted attribute in
conjuction 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).
<span class="grey">Kille [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc1026">RFC 1026</a> September 1987</span>
To allow the mapping of null organisations to be represented in the
specification of <a href="#appendix-F">Appendix F</a>, 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 = "."
<a href="#appendix-F">Appendix F</a> - Format of address mapping tables
A new <a href="#appendix-F">Appendix F</a> is defined as follows:
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 manner which makes it suitable
for use with domain nameservices (such as the Internet Domain
nameservers or the UK NRS). The mapping is not symmetric, and 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#
<span class="grey">Kille [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc1026">RFC 1026</a> September 1987</span>
HMI.DBP.DFN#O$@.PRMD$HMI.ADMD.DBP.C$DE#
For X.400 -> domain:
dmn-orname "#" domain-syntax "#"
Kille [Page 4]
</pre>
|
