| RFC : | rfc1685 |
| Title: | |
| Date: | August 1994 |
| Status: | INFORMATIONAL |
| See Also: | RTR12 |
Network Working Group H. Alvestrand
Request for Comments: 1685 UNINETT
RARE Technical Report: 12 August 1994
Category: Informational
Writing X.400 O/R Names
Status of this Memo
This memo provides information for the Internet Community. It does
not specify an Internet Standard of any kind. Distribution of this
memo is unlimited.
1. Introduction
There is a need for human beings who use X.400 systems to be able to
write down O/R names in a uniform way.
There has been a preexisting recommendation on how to write O/R names
for human consumption in the RARE community. Now that the ISO/ITU has
adopted a recommendation on how to do this [1], RARE needs to update
its recommendation on writing O/R names to take this standard into
account.
2. Recommendations on writing O/R names
RARE recommends that the ISO standard be followed when writing O/R
names. The ISO/ITU standard contains a number of options. RARE makes
the following recommendations:
- The "main" abbreviations, G, I, S, O, OU1, OU2, P, A and C
are used. They should be written using UPPER CASE.
- The separation character should be semicolon (;).
- The ADMD value "blank" is expressed by omitting the
attribute. No other interpretation of a missing ADMD
attribute is allowed.
- The recommended sequence is G=;I=;S=;O=;OU1=;OU2=;P=;A=;C=;
This means that the O, OU1 and so on will be in opposite order to the
fields of an Internet domain name; the reason for choosing the
ISO/ITU order is that this will be more common among users of X.400
services.
RARE Working Group on Mail and Messaging (WG-MSG) [Page 1]
RFC 1685 Writing X.400 O/R Names August 1994
3. Copy of the recommmendation
This is a COPY of a DRAFT of the relevant appendix. For the
authoritative text, consult the ITU standard itself.
Final text for AMENDMENT, 7 February 1993
Annex to CCITT Rec. F.401 and ISO/IEC 10021-2/Am.1
Annex F
Representation of O/R addresses for human usage (This annex does
not form an integral part of this Recommendation|International
Standard)
F.1 Purpose
An O/R address (specified in clause 18) consists of a set of
values of attributes taken from the list shown in Table F.1. In
order to represent visually an address to a human user, and to
enable the user to enter the address into a user interface, each
attribute value needs to be associated with the correct attribute
type. Many of the names of the attribute types shown in Table F.1
are too long for convenient usage on paper or a screen. There is a
need for a format which allows attributes to be represented
concisely, e.g., on a business card.
This annex specifies how addresses can be expressed concisely
using labels to represent the attribute types. There are three
categories of attributes: those standard mnemonic attributes which
are most likely to be found in O/R addresses represented for human
usage (e.g., on business cards), those used in physical delivery
addresses, and other specialised attributes (including domain
defined attributes). In order to provide a format which is as
concise as possible, many of the labels are single characters.
This also makes them less language dependent.
Clause F.3 specifies the format for the representation of
addresses, and clause F.4 specifies the characteristics necessary
for user interfaces which are intended to be used in conjunction
with this format.
F.2 Scope
A labelled format for the communication of O/R addresses to human
users is specified. The format consists of a set of pairs of
labels and attribute-values. The characteristics of a user
interface which are necessary to accept addresses given in this
RARE Working Group on Mail and Messaging (WG-MSG) [Page 2]
RFC 1685 Writing X.400 O/R Names August 1994
format are also specified.
In addition a self-explanatory format suitable for use where there
is more space, e.g., in printed material and in the user
interface, is specified.
F.3 Format
F.3.1 General
The objective of the labelled format is to enable O/R addresses to
be represented in a format which is concise and which can be
accurately transcribed by human users. This can be facilitated by
careful consideration of which attributes and values are used to
form an O/R address.
If the attributes of an O/R address include characters from an
extended character set, human users who do not normally use the
same extended character set may have difficulty representing the
O/R address or entering it into their messaging system. In this
situation, an alias of the O/R address should be provided which is
composed entirely of printable string characters.
NOTES
1. The policy for structuring O/R addresses needs to be
carefully considered. Individual O/R addresses should be
allocated within an appropriate division of the address
space to reduce to an acceptable level the probability that
2 users might expect to have the same O/R address. Use of
given name or initials is usually sufficient to distinguish
between users. It may be inappropriate to reflect too much
granularity in OUs particularly if the organizational
structure is subject to frequent change, or users move
between OUs.
2. There may be a conflict between the benefits of using long
values for attributes which are self explanatory (such as
the full name of an organisation) and the benefits of
shorter values (e.g., to concisely fit on a business card).
One solution to this problem is to provide an alternative
short attribute value (such as the initials of the
organisation) as an alias for the long value.
3. If a human user might be uncertain about the existence of a
space in an attribute value (particularly when it is
typeset), aliases could be provided with and without the
space (e.g., "SNOMAIL400" as an alias for "SNOMAIL 400" and
RARE Working Group on Mail and Messaging (WG-MSG) [Page 3]
RFC 1685 Writing X.400 O/R Names August 1994
"Mac Donald" as an alias for MacDonald).
4. If an alias is provided for an O/R address, it is desirable
that this is implemented in such a way that a consistent
(preferred) form of O/R address is generated for all
messages originated by the user.
Where national usage permits a single space value for the ADMD in
an address, this is represented in the address either by omitting
the ADMD attribute, or showing the ADMD attribute with no value or
the value of a space.
F.3.2 Labelled format
F.3.2.1 Syntax
O/R addresses in labelled format consist of delimited pairs of
labels and values in the syntax <label>"="<value>. The labels for
each attribute are specified in Tables F.1, F.2 and F.3. (The
physical delivery attributes in Table F.2 are included for
completeness.) The label and its value are either separated by the
character "=", or by the space between two columns in a table.
Labels may be represented in upper or lower case, but the use of
uppercase is recommended as it is likely to be more visually
distinctive.
If label/value pairs appear in sequence on a line, they are
separated by delimiters. Delimiters may optionally be followed by
one or more spaces. The delimiter character may be either ";" or
"/", but only one of these can be used in one O/R address. When
the delimiter is "/" the first label is prefixed by "/". The use
of a delimiter at the end of a line is optional. If the value of
any attribute contains the delimiter character, this is
represented by a pair of delimiter characters.
If an identifier is required to preface a labelled address, it is
recommended that "X.400" is used.
If an address is entirely composed of attributes contained in
Table F.1, it is recommended that the sequence of attributes in
the address is that given in Table F.1. If this sequence is
incompatible with normal cultural conventions, an alternative
sequence may be adopted for representations of addresses which are
primarily intended for use within that culture.
RARE Working Group on Mail and Messaging (WG-MSG) [Page 4]
RFC 1685 Writing X.400 O/R Names August 1994
EXAMPLE
X.400: G=john; S=smith; O=a bank ltd; P=abl; A=snomail; C=aq
This address may also be layed out as a table:
G John
S Smith
O A Bank Ltd
P ABL
A Snomail
C AQ
Table F.1. Standard Attributes of the Mnemonic Address Form
Attribute Type Abbreviation Label
(where necessary)
Given Name Given name G
Initial Initials I
Surname Surname S
Generation Qualifier Generation Q
Common Name Common Name CN
Organization Organization O
Organizational Unit 1 Org.Unit.1 OU1
Organizational Unit 2 Org.Unit.2 OU2
Organizational Unit 3 Org.Unit.3 OU3
Organizational Unit 4 Org.Unit.4 OU4
Private Management Domain Name PRMD P
Administration Management Domain Name ADMD A
Country Country C
RARE Working Group on Mail and Messaging (WG-MSG) [Page 5]
RFC 1685 Writing X.400 O/R Names August 1994
Table F.2. Physical Delivery Attributes
Physical Delivery Personal Name PD-person PD-PN
Extension of Postal O/R Address
Components PD-ext.address PD-EA
Extension of Physical Delivery Address
Components PD-ext.delivery PD-ED
Physical Delivery Office Number PD-office number PD-OFN
Physical Delivery Office Name PD-office PD-OF
Physical Delivery Organization Name PD-organization PD-O
Street Address PD-street PD-S
Unformatted Postal Address PD-address PD-A1
PD-A2
(there are individual labels for PD-A3
each line of the address) PD-A4
PD-A5
PD-A6
Unique Postal Name PD-unique PD-U
Local Postal Attributes PD-local PD-L
Postal Restante Address PD-restante PD-R
Post Office Box Address PD-box PD-B
Postal Code PD-code PD-PC
Physical Delivery Service Name PD-service PD-SN
Physical Delivery Country Name PD-country PD-C
Table F.3. Other Attributes
X.121 Network Address X.121 X.121
E.163/E.164 Network Address ISDN ISDN
PSAP Network Address PSAP PSAP
User Agent Numeric ID N-ID N-ID
Terminal Identifier T-ID T-ID
Terminal Type T-TY T-TY
Domain Defined Attribute DDA:<type>
DDA:<type>
where the notation <type> identifies the type of domain defined
attribute.
F.3.2.2 Terminal Type
There are currently six terminal types, and if international
consistency is required the following specific abbreviations
should be used to represent the values for these types: tlx, ttx,
g3fax, g4fax, ia5 and vtx.
RARE Working Group on Mail and Messaging (WG-MSG) [Page 6]
RFC 1685 Writing X.400 O/R Names August 1994
F.3.2.3 Domain Defined Attribute
The label for a DDA consists of "DDA:" followed by the DDA type.
If an address includes more than one DDA of the same type, it is
assumed that the DDAs are intended to be processed in the sequence
in which they are represented.
EXAMPLE - DDA:RFC-822=fred(a)widget.co.uk; O=gateway; P=abc; C=gb
If the <type> of a DDA type includes the character "=", it is
represented by "==".
F.3.3 Self-explanatory format
The self-explanatory format may be used when space is available.
It consists of a list of the attribute types, either in full or
abbreviated. The attribute types or abbreviations may be in any
language, but each attribute type or abbreviation in Table F.1 is
followed by the specified label. If English language abbreviations
are used, they should be those given in Tables F.1, F.2 and F.3.
If an address is entirely composed of attributes contained in
Table F.1, it is recommended that the sequence of attributes in
the address is that given in Table F.1. If this sequence is
incompatible with normal cultural conventions, an alternative
sequence may be adopted for representations of addresses which are
primarily intended for use within that culture.
EXAMPLE 1 - Using attribute types in the Norwegian language
Fornavn (G) Per
Etternavn (S) Hansen
Organisasjon (O) Teledir
Organisasjonsenhet (OU1) Forskning
Privat domene (P) Tele
Administrasjonsdomene (A) Telemax
Land (C) NO
RARE Working Group on Mail and Messaging (WG-MSG) [Page 7]
RFC 1685 Writing X.400 O/R Names August 1994
EXAMPLE 2 - Using attribute types and abbreviations in the English
language
Given name (G) John
Surname (S) Smith
Organization (O) A Bank Ltd
Org. Unit (OU1) IT Dept
Org. Unit (OU2) MSG Group
PRMD (P) ABL
ADMD (A) Snomail
Country (C) AQ
F.4 User interface
This clause specifies the characteristics of a user interface
which are necessary to enable a user to input O/R addresses
represented in either of the formats specified in clause F.3.
It is necessary for the user interface to be able to accept any
valid combination of attributes from Tables F.1, F.2 and F.3.
If the user interface lists the attributes given in Table F.1, it
is recommended that either the sequence used in Table F.1 should
be used, or if this sequence is incompatible with normal cultural
conventions, the alternative sequence adopted within a particular
culture.
If the user supplies a value for the PRMD attribute but omits the
ADMD attribute, or omits the value for the ADMD attribute, the
ADMD value to be used is a single space.
Where an interface accepts an O/R address as a single string
(e.g., in a command line interface), it is necessary to accept any
valid labelled format address allowing the user to enter either
delimiter. The interface should not require the attributes to be
specified in any particular order. The interface should accept
labels in upper or lower case.
NOTE - For some existing command line interfaces it may be
necessary to enclose the whole labelled format address in quotes.
If any other type of interface is provided (e.g., a prompting or
form-fill interface), it is necessary to provide a means which
enables the user to easily associate the identity of each
attribute with the labels specified in Tables F.1, F.2 and F.3.
RARE Working Group on Mail and Messaging (WG-MSG) [Page 8]
RFC 1685 Writing X.400 O/R Names August 1994
NOTES
1. One way to associate the identity of each attribute with the
labels is to follow the attribute type (or abbreviation) for
each attribute with the label in brackets, for example:
Given name (G)
Initials (I)
Surname (S)
Generation Qualifier (Q)
Common Name (CN)
Organization (O)
Organizational Unit 1 (OU1)
Organizational Unit 2 (OU2)
Organizational Unit 3 (OU3)
Organizational Unit 4 (OU4)
Private Management Domain Name (P)
Administration Management Domain Name (A)
Country (C)
2. Many users may have difficulty copying an address presented
as a table (either in labelled or self-explanatory format)
into a command line interface which uses delimiters.
3. For form-fill style interfaces, user performance will be
optimised when the interface most closely resembles the
format of the supplied address with the same sequence of
attributes using the same attribute types or labels.
Examples of application
1. The Norwegian user of a command line interface receives a
business card containing the following O/R address:
G=john; S=smith; O=a bank ltd; P=abl; A=snomail; C=aq
The command line interface enables the user to type in the
address exactly as presented on the card.
2. The Norwegian user of a form fill interface receives the
same business card. The form on the screen includes the
following field names:
RARE Working Group on Mail and Messaging (WG-MSG) [Page 9]
RFC 1685 Writing X.400 O/R Names August 1994
Fornavn (G)
Etternavn (S)
Organisasjon (O)
Privat domene (P)
Administrasjonsdomene (A)
Land (C)
The user is able to fill in the form by associating the
single letter labels on the business card with the same
labels in brackets after the Norwegian names of the
attributes on the screen. (For form fill input the
delimiters are not used.)
3. The English speaking user of a command line interface
receives a document quoting the following O/R address:
Fornavn (G) Per
Etternavn (S) Hansen
Organisasjon (O) Teledir
Organisasjonsenhet (OU1) Forskning
Privat domene (P) Tele
Administrasjonsdomene (A) Telemax
Land (C) NO
The user knows how to transform the address from self-
explanatory to labelled format. The user can choose to enter
the address with either delimiter, e.g.,:
g=per;s=hansen;o=teledir;ou1=forskning;p=tele;a=telemax;c=no
or:
/g=per/s=hansen/o=teledir/ou1=forskning/p=tele/a=telemax/c=no
4. References
[1] F.401 - CCITT Message Handling Services - Operations
and Definitions of Service - Naming and Addressing
for Public Message Handling Services, Annex B
(08/92).
Available (at the time of writing) as the GOPHER URL:
gopher://info.itu.ch/9/.1/ITUdoc/.dirtree/.1/.itu-
t/.rec/.f/.23068/.7724.zip
RARE Working Group on Mail and Messaging (WG-MSG) [Page 10]
RFC 1685 Writing X.400 O/R Names August 1994
5. Security Considerations
Security issues are not discussed in this memo.
6. Author's Address
Harald Tveit Alvestrand
UNINETT A/S
P.O.Box 6883
ELGESETER
N-7002 TRONDHEIM
NORWAY
RFC822: Harald.Alvestrand@uninett.no
X.400: C=no; ADMD=; PRMD=uninett; O=uninett; S=alvestrand;
G=harald
RARE Working Group on Mail and Messaging (WG-MSG) [Page 11]