S.Kille@CS.UCL.AC.UK (Steve Kille) (07/14/89)
and is not reverse mappable.
DL Expansion History Indication
Supported by use of a new RFC 822 header |
(DL-Expansion-History:).
DL Expansion Prohibited
Distribution List means MTS supported distribution list, in |
the manner of X.400. This service does not exist in the RFC |
822 world. RFC 822 distribution lists should be regarded as |
an informal redistribution mechanism, beyond the scope of |
this control. Messages will be sent to RFC 822, |
irrespective of whether this service is requested. |
Theoretically therefore, this service is supported, although |
in practice it may appear that it is not supported.
Express Mail Service
Kille [page 24]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
N/A (PDAU). |
Expiry Date Indication
Supported as new RFC 822 header (Expiry-Date:). In general, |
no automatic action can be expected.
Explicit Conversion
N/A (prior). |
Forwarded IP Message Indication
Supported, with some loss of information. The message is
forwarded in an RFC 822 body, and so can only be interpreted
visually.
Grade of Delivery Selection
N/A (PDAU) |
Importance Indication
Supported as new RFC 822 header (Importance:). |
Incomplete Copy Indication
Supported as new RFC 822 header (Incomplete-Copy:). |
Language Indication
Supported as new RFC 822 header (Language:). |
Latest Delivery Designation
Not supported. A new RFC 822 header (Latest-Delivery-Time:) |
is provided, which may be used by the recipient.
Message Flow Confidentiality
Not supported.
Message Origin Authentication
N/A (reception). |
Message Security Labelling
Not supported.
Message Sequence Integrity
Not supported.
Multi-Destination Delivery
Supported.
Kille [page 25]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
Multi-part Body
Supported, with some loss of information, in that the
structuring cannot be formalised in RFC 822.
Non Receipt Notification Request
Not supported.
Non Repudiation of Delivery
Not supported.
Non Repudiation of Origin
N/A (reception). |
Non Repudiation of Submission
N/A (local). |
Obsoleting Indication
Supported as new RFC 822 header (Obsoletes:). |
Ordinary Mail
N/A (PDAU). |
Originator Indication
Supported.
Originator Requested Alternate Recipient
Not supported, but is placed as comment next to address.
Physical Delivery Notification by MHS
N/A (PDAU). |
Physical Delivery Notification by PDS
N/A (PDAU). |
Physical Forwarding Allowed
Supported by use of a comment in a new RFC 822 header |
(X400-Recipients:), associated with the recipient in |
question.
Physical Forwarding Prohibited
Supported by use of a comment in a new RFC 822 header |
(X400-Recipients:), associated with the recipient in |
question.
Kille [page 26]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
Prevention of Non-delivery notification
Supported, as delivery notifications cannot be generated by |
RFC 822. In practice, errors will be returned as IP |
Messages, and so this service may appear not to be supported |
(see Non-delivery Notification).
Primary and Copy Recipients Indication
Supported
Probe
Supported at the gateway (i.e., the gateway services the
probe).
Probe Origin Authentication
N/A (reception). |
Proof of Delivery
Not supported.
Proof of Submission
N/A (local). |
Receipt Notification Request Indication
Not supported.
Redirection Allowed by Originator
Redirection means MTS supported redirection, in the manner |
of X.400. This service does not exist in the RFC 822 world. |
RFC 822 redirection (e.g., aliasing) should be regarded as |
an informal redirection mechanism, beyond the scope of this |
control. Messages will be sent to RFC 822, irrespective of |
whether this service is requested. Theoretically therefore, |
this service is supported, although in practice it may |
appear that it is not supported.
Registered Mail
N/A (PDAU). |
Registered Mail to Addressee in Person
N/A (PDAU). |
Reply Request Indication
Supported as comment next to address.
Kille [page 27]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
Replying IP Message Indication
Supported.
Report Origin Authentication
N/A (reception). |
Request for Forwarding Address
N/A (PDAU). |
Requested Delivery Method
N/A (local). The services required must be dealt with at |
submission time. Any such request is made available through |
the gateway by use of a comment associated with the |
recipient in question.
Return of Content
In principle, this is N/A, as non-delivery notifications are |
not supported. In practice, most RFC 822 systems will |
return part or all of the content along with the IP Message |
indicating an error (see Non-delivery Notification).
Sensitivity Indication
Supported as new RFC 822 header (Sensitivity:). |
Special Delivery
N/A (PDAU). |
Stored Message Deletion
N/A (MS). |
Stored Message Fetching
N/A (MS). |
Stored Message Listing
N/A (MS). |
Stored Message Summary
N/A (MS). |
Subject Indication
Supported.
Undeliverable Mail with Return of Physical Message
N/A (PDAU). |
Kille [page 28]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
Use of Distribution List
In principle this applies only to X.400 supported |
distribution lists (see DL Expansion Prohibited). |
Theoretically, this service is N/A (prior). In practice, |
because of informal RFC 822 lists, this service can be |
regarded as supported.
2.3.2. Reception by X.400 |
2.3.2.1. Standard Mandatory Services
The following standard IPM mandatory user facilities may be
required for reception of RFC 822 originated mail by an X.400 UA. |
Content Type Indication
Delivery Time Stamp Indication
IP Message Identification
Message Identification
Non-delivery Notification
Original Encoded Information Types Indication
Submission Time Stamp Indication
Typed Body
2.3.2.2. Standard Optional Services
The following standard IPM optional user facilities may be
required for reception of RFC 822 originated mail by an X.400 UA. |
Authorising User's Indication
Blind Copy Recipient Indication
Cross Referencing Indication
Originator Indication
Kille [page 29]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
Primary and Copy Recipients Indication
Replying IP Message Indication
Subject Indication
2.3.2.3. New Services
A new service "RFC 822 Header Field" is defined using the
extension facilities. This allows for any RFC 822 header field
to be represented. It may be present in RFC 822 originated |
messages, which are received by an X.400 UA.
Kille [page 30]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
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. This is described.
3.1.1. RFC 822
Structured text is defined according to the Extended Backus Naur
Form (EBNF) defined in Section 2 of RFC 822 [Crocker82a]. 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 822-MTS
components). In this case, the lexical analysis defined in
Section 3 of RFC 822 should be used. 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.bilateral-info).
2. To describe the structure of IA5 or ASCII information not in
an RFC 822 message. In these cases, tokens will either be
self delimiting, or be delimited by self delimiting tokens.
Comments and LWSP are not used as delimiters.
3.1.2. ASN.1
An element is referred to with the following syntax, defined in
EBNF:
Kille [page 31]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
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.
MTA MTAAbstractService defined in Section 13 of X.411 / ISO |
10021-4.
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 . For each case, an EBNF syntax [
definition is given, for use in all of this specification, which [
Kille [page 32]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
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 should be to render
the characters appropriately in the remote character set, rather
than to maximise reversibility. For these cases, the mappings
defined in CCITT Recommendation X.408 (1988) should be used
[CCITT/ISO88a]. These will then be encoded in ASCII.
There is also a need to represent Teletex Strings in ASCII,
for some aspects of O/R Address. For these, the following
encoding is used:
Kille [page 33]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
teletex-string = *( ps-char / t61-encoded ) |
t61-encoded = "{" 1* t61-encoded-char "}" |
t61-encoded-char = 3DIGIT |
Common characters are mapped simply. Other octets are mapped
using a quoting mechanism similar to the printable string |
mechanism. Each octet is represented as 3 decimal digits.
There are a number of places where a string may have a Teletex
and/or Printable String representation. The following BNF 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.
3.3.5. UTCTime
Both UTCTime and the RFC 822 822.date-time syntax contain: Year
(lowest two digits), Month, Day of Month, hour, minute, second
(optional), and Timezone. 822.date-time also contains an
optional day of the week, but this is redundant. Therefore 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.
The UTCTime format which specifies the timezone offset should be
used.
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,
addition of an appropriate text label is strongly encouraged.
Kille [page 34]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
labelled-integer ::= key-string "(" numericstring ")"
3.3.7. Object Identifier
Object identifiers are represented in a form similar to that
given in ASN.1. The numbers are mandatory, to ease encoding.
It is recommended that as many strings as possible are used, to
facilitate user recognition.
object-identifier ::= [ defined-value ] oid-comp-list
oid-comp-list ::= oid-comp oid-comp-list
| oid-comp
defined-value ::= key-string
oid-comp ::= [ key-string ] "(" numericstring ")"
key-string = *key-char
key-char = <a-z, A-Z, 1-9, and "-">
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 can 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 ")"
Kille [page 35]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
The 822.3DIGIT in EBNF.ps-encoded-char must 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 braces, 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.
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 must only be used in cases
where the printable strings may only be 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 should 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) <-> @
(l)a(r) <-> (a)
(126) <-> ~ |
( -> (
(l) <-> (
Kille [page 36]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
Chapter 4 - Addressing
Addressing is probably the trickiest problem of an X.400 <-> RFC
822 gateway. Therefore it is given a separate chapter. This |
chapter, as a side effect, also defines a textual representation |
of an X.400 O/R Address.
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
In an 822-MTS protocol, the originator and each recipient should
be 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 O/R Address, used by the MTS for routing, is
defined by MTS.ORAddress. In IPMS, the MTS.ORAddress is
encapsulated within IPMS.ORDescriptor.
It can be seen that RFC 822 822.address must be mapped with |
IPMS.ORDescriptor, and that RFC 822 EBNF.822-address must be |
mapped with MTS.ORAddress.
4.1. A textual representation of MTS.ORAddress
MTS.ORAddress is structured as a set of attribute value pairs.
It is clearly necessary to be able to encode this in ASCII for
gatewaying purposes. All aspects should be encoded, in order to
guarantee return of error messages, and to optimise third party
replies.
4.2. Basic Representation
An O/R 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
Kille [page 37]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
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 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:
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 N 18.3.23 |
MTS.OrganizationName O P/T 18.3.9 |
MTS.OrganizationalUnitNames.value OU P 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.DomainDefinedAttribute.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 |
Kille [page 38]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
MTS.PDSName PD-SYSTEM P 18.3.11 7 |
MTS.PhysicalDeliveryCountryName PD-C P 18.3.13 8 |
MTS.PostalCode POSTCODE 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-D 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-LOC P/T 18.3.5 15|
MTS.UnformattedPostalAddress PD-ADDRESS P/T 18.3.25 16|
MTS.StreetAddress STREET P/T 18.3.22 17|
MTS.PostOfficeBoxAddress PO-BOX P/T 18.3.18 18|
MTS.PosteRestanteAddress POSTE-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 NET-TTYPE I 18.3.24 23|
The following keys identify different encodings: |
Key Encoding |
P printablestring |
N numericstring |
T teletex-string |
P/T teletex-and-or-ps |
I labelled-integer |
X presentation-address |
In cases where an attribute can be encoded as either a |
PrintableString or NumericString (Country, ADMD, PRMD), the |
NumericString encoding should be used if the string contains only |
digits. |
The BNF for presentation-address is taken from the specification |
"A String Encoding of Presentation Address" [Kille89a]. |
Kille [page 39]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
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 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.
4.2.1. Encoding of Personal Name
Handling of Personal Name and Teletex Personal Name based purely
on the EBNF.standard-type syntax defined above is likely to be
clumsy. It seems desirable to utilise the "human" conventions
for encoding these components. A syntax is proposed here. It is
designed to cope with the common cases of O/R Address
specification where:
1. There is no generational qualifier
2. Initials contain only letters
3. Given Name does not contain full stop ("."), and is at least
two characters long.
4. If Surname contains full stop, then it may not be in the
first two characters, and either initials or given name is
present.
The following EBNF is defined:
encoded-pn = [ given "." ] *( initial "." ) surname
given = 2*<ps-char not including ".">
initial = ALPHA
surname = printablestring
Kille [page 40]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
Subject to the above restrictions, this is a reversible mapping.
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 suggest that Initials is used to encode ALL
initials. Therefore, the proposed encoding is "natural" when
either GivenName or Initials, but not both, are present. The
case where both are present can be encoded, but this appears to
be contrived!
4.2.2. Standard Encoding of MTS.ORAddress
Given this structure, we can specify a BNF representation of an
O/R Address.
Kille [page 41]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
std-or-address = 1*( "/" attribute "=" value ) "/"
attribute = standard-type
/ "RFC-822"
/ registered-dd-type
/ dd-key "." std-printablestring
standard-type = key-string
registered-dd-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
The standard-type, is any key defined in the table in |
Section 4.2, except PN, and DD. The value, after quote removal,
should be interpreted according to the defined encoding.
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), then |
the type and value should be interpreted according to the syntax
implied from the encoding, and aligned to either the teletex or |
printable string form. Key and value should 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 should be done in a case-
independent manner.
If the value is registered-dd-type, if the value is
Kille [page 42]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
registered at the SRI NIC as an accepted Domain Defined Attribute
type, then the value should be interpreted accordingly. This
restriction maximises the syntax checking which can be done at a
gateway. *
4.3. EBNF.822-address <-> MTS.ORAddress
Ideally, the mapping specified 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
awkward.
2. In the general case, there would not be the necessary
administrative co-operation between the X.400 and RFC 822
worlds, which would be needed for this to work.
Therefore, an asymmetrical mapping is defined, which can be
symmetrical where there is appropriate administrative control.
4.3.1. X.400 encoded in RFC 822
The std-or-address syntax is used to encode O/R Address
information in the 822.local-part of EBNF.822-address. Further
O/R Address information may be associated with the 822.domain
component. This cannot be used in the general case, basically
due to character set problems, and lack of order in X.400 O/R
Addresses. 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.
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) should be 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
Kille [page 43]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
822.local-part may also identify the gateway from within the RFC
822 world. This final 822.domain may be used to determine some
number of O/R Address attributes. The following O/R Address
attributes are considered as a hierarchy, and may be specified by
the domain. They are (in order of hierarchy):
Country, ADMD, PRMD, Organisation, Organisational Unit
There may be multiple Organisational Units.
Associations may be defined between domain specifications,
and some set of attributes. This association proceeds
hierarchically. For example, if a domain implies ADMD, it also
implies country. Subdomains under this are associated according
to the O/R Address hierarchy. For example:
=> "AC.UK" might be associated with
C="GB", ADMD="GOLD 400", PRMD="UK.AC"
then domain "R-D.Salford.AC.UK" maps with
C="GB", ADMD="GOLD 400", PRMD="UK.AC", O="Salford", OU="R-D"
There are three basic reasons why a domain/attribute mapping
might be maintained, as opposed to using simply subdomains:
1. As a shorthand to avoid redundant X.400 information. In
particular, there will often be only one ADMD per country,
and so it does not need to be given explicitly.
2. To deal with cases where attribute values do not fit the
syntax:
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 chosen as it is the one chosen by the
various domain service administrations.
3. To deal with missing elements in the hierarchy. A domain
may be associated with an omitted attribute in conjunction
Kille [page 44]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
with several present ones. When performing the algorithmic
insertion of components lower in the hierarchy, the omitted
value should be skipped. For example, if "HNE.EGM" is |
associated with "C=TC", "ADMD=ECQ", "PRMD=HNE", and omitted |
organisation, then "ZI.HNE.EGM" is mapped with "C=TC", |
"ADMD=ECQ", "PRMD=HNE", "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).
This set of mappings need only be known by the gateways
relaying between the RFC 822 world, and the O/R Address space
associated with the mapping in question. However, it is
desirable (for the optimal mapping of third party addresses) for
all gateways to know these mappings. A format for the exchange
of this information is defined in Appendix F.
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"
The first three attributes are determined by the domain |
Widget.COM. Then, the first element of OrganizationalUnitNames
is determined systematically, and the remaining attributes are
encoded on the LHS. In an extreme case, all of the attributes
will be on the LHS. As the domain cannot be null, the RHS will
simply be a domain indicating the gateway.
The RHS (domain) encoding is designed to deal cleanly with
common addresses, and should be used where possible. In
particular, it covers the Mnemonic O/R Address using a 1984
compatible encoding. This is seen as the dominant form of O/R
Kille [page 45]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
Address. Use of other forms of O/R Address, and teletex encoded
attributes will require an LHS encoding.
As a further mechanism to simplify the encoding of common
cases, where the only attributes to be encoded on the LHS is a
(non-Teletex) Personal Name attributes which comply with the |
restrictions of 4.2.1, the 822.local-part may be encoded as
EBNF.encoded-pn. In the previous example, if the
GenerationQualifier was not present, the encoding |
J.Linnimouth@Marketing.Widget.COM could be used.
From the standpoint of the RFC 822 Message Transfer System,
the domain specification is simply used to route the message in
the standard manner. The standard domain mechanisms are used to
identify gateways, and are used to select appropriate gateways
for the corresponding O/R Address space. In most cases, this
will be done by registering the higher levels, and assuming that
the gateway can handle the lower levels.
There has been an implicit assumption that an RFC 822 domain
is either X.400 or RFC 822. This is pragmatic, but undesirable,
as the namespace should be structured on a logical basis which
does not necessarily correspond to the choice of Message Transfer
protocols. The restriction can be lifted, provided that the name |
service deals with multiple message transfer protocols. It could
also be achieved with the DARPA Domain Nameserver scheme by use
of the WKS mechanism. However, this does not fit with current
usage of the scheme.
4.3.2. RFC 822 encoded in X.400
In some cases, the encoding defined above may be reversed, to
give a "natural" encoding of genuine RFC 822 addresses. This
depends largely on the allocation of appropriate management
domains.
The general case is mapped by use of domain defined
attributes. A 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 depends on the context of the gateway.
1. In the context of RFC 822, and RFC 920
[Crocker82a,Postel84a], the string can be used directly.
Kille [page 46]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
2. In the context of the JNT Mail protocol, and the NRS
[Kille84a,Larmouth83a], the string should be interpreted
according to Mailgroup Note 15 [Kille84b].
3. In the context of UUCP based systems, the string should be
interpreted as defined in [Horton86a].
Other O/R Address attributes will be used to identify a
context in which the O/R 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.
4.3.3. Component Ordering
In most cases, ordering of O/R Address components is not
significant for the mappings specified. However, Organisational
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
Kille [page 47]