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
