nbevan@ess.cs.ucl.ac.uk (Nigel Bevan) (06/03/91)
This is the text which will shortly be circulated for vote in ISO as a
Proposed Draft Amendment to the standard.
COVER SHEET FOR PDAM
ISSUES CONSIDERED IN PREPARING THE DRAFT
This revised draft was produced by a meeting of CCITT Q18/VII and ISO/IEC
JTC1/SC18/WG4 SWG Messaging as a proposed annex to CCITT Rec. F.401 and
ISO/IEC 10021-2. (The format conforms with the rules for presentation of
joint CCITT/ISO/IEC documents, Nov 1990.)
Comments are invited from member bodies not represented at the meeting on
the following issues which were considered in producing this draft:
1. Sequence of attributes
The major objective is to represent the address in a format which is
convenient and meaningful to the ordinary user (who is not familiar with the
internal representation of O/R addresses).
One order proposed for the sequence of attributes is the top-down sequence
used internally in the standard:
Country C
Administration Management Domain Name ADMD A
Private Management Domain Name PRMD P
Organisation O
Organisational Unit 1 Org.Unit.1 OU1
Organisational Unit 2 Org.Unit.2 OU2
Organisational Unit 3 Org.Unit.3 OU3
Organisational Unit 4 Org.Unit.4 OU4
Common Name CN
Generation Qualifier Generation Q
Surname S
Initials I
Given Name G
An example of an address using the top-down sequence is:
C=gb; A=gold 400; P=abl; O=a bank ltd; OU1=reading; OU2=it dept;
OU3=msg group; S=smith; G=john
This sequence has the advantage that is given as an example in the IAOG
guidelines, and it is commonly used.
The problem with the completely bottom-up sequence which had been considered
in the past was that the it is not easy to deal with the OUs in reverse
order. The sequence in Table D.1 solves this problem by following O with
the OUs in top-down order.
An example of an address using the modified bottom-up sequence is:
G=john; S=smith; O=a bank ltd;
OU1=reading; OU2=it dept; OU3=msg group; P=abl; A=gold 400; C=gb
This sequence has the advantage that it is convenient and meaningful to the
ordinary user. The name which is the most significant information to the
human user is given first. This makes it easier to identify the address as
belonging to the individual concerned, and easier to locate names when a
list of addresses is given. This sequence has a close resemblance to the
sequence used most often in a postal address. It is also more convenient if
the user interface permits default values to be used for address attributes.
This sequence is recommended in the specification.
2. Delimiter between label/attribute pairs
It was agreed that to facilitate human usage and machine parsing, it was
desirable to specify a single format for labelled addresses. There is a
specific requirement to copy labelled-format addresses into command line
interfaces.
The requirements for the ideal delimiter are that it should not be from the
printable string repertoire, should be available on user interface
keyboards, should not be easily confused with any other keyboard character,
should be recognised as a delimiter for human usage, and should be
compatible with existing interfaces.
";" would meet all but the last requirement, as it is a delimiter in UNIX.
Some submissions have maintained that this is a major problem, but it was
concluded that sending mail from the UNIX command line is only appropriate
for experienced computer users who could easily make any necessary
substitutions.
The problem with using "/" as a delimiter would be that it is more likely to
occur in an attribute than ";", particularly as it is a printable string
character, and that it is not as natural a delimiter for the user as it can
have other meanings (eg alternatives or division).
3. Identifier
The ideal requirements for an identifier for an O/R address are that it
should be short, recognised by users, and language-independent. None of the
proposed identifiers was entirely satisfactory. "X.400" is a technical term
which may not be recognised by some users. "Email" is sometimes used for
other specific systems rather than generically, and is based on English
language. "MHS" or "MH" are not widely used and are based on English words.
It is important that some preference is given in the standard to encourage
harmonisation on a particular identifier.
4. Single space value for ADMD
The base specification requires that messages can be sent internationally to
O/R addresses with a space value for the ADMD name in countries where this
is permitted. There is a corresponding requirement to represent these
values visually and input them to the user interface. It is difficult to
represent the O/R address in such a way that the human user would interpret
it as a requirement to actually type a space into the user interface. As
the meaning of the space value is that no ADMD name need be given, the most
logical representation is to omit the ADMD parameter in the representation
and not give an ADMD value in the user interface.
5. Conformance
No requirements for conformance are imposed in ISO/IED 10021-2. No claims
of conformance with other parts of the standard may be taken as a
requirement to meet the specifications in this annex.
PROPOSED DRAFT AMENDMENT, 19 Feb 1991
Annex to CCITT Rec. F.401 and ISO/IEC 10021-2
ANNEX D
REPRESENTATION OF O/R ADDRESSES FOR HUMAN USAGE
(This annex forms an integral part of this specification)
D.1 PURPOSE
An O/R address consists of a set of attribute values taken from a total of
31 possible attributes. In order to represent visually an address to a
human user, and enable the user to enter the address into a user interface,
each attribute value needs to be associated with the correct attribute name.
Many of the full attribute names given in this specification 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, eg on a business card.
This annex specifies how addresses can be expressed concisely using labels
as abbreviations for the attribute names. There are 3 categories of
attributes: those which may be used in commonly-used O/R addresses (eg on
business cards), those used in physical delivery addresses, and other
specialised attributes (network address, user agent numeric ID and terminal
identifier). In order to provide a format for commonly-used O/R addresses
which is as concise as possible, many of the labels are single characters.
This also makes them less language dependent. The labels for the physical
address attributes need not be as concise, so the labels specified are more
self explanatory.
Clause 3 specifies the format for the representation of addresses, and
clause 4 specifies requirements for user interfaces which are used in
conjunction with this format.
D.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 requirements for user interfaces which are designed
to accept addresses given in this format are also specified.
In addition a self-explanatory format suitable for use where there is more
space, eg in printed material and in the user interface, is specified.
D.3 FORMAT
D.3.1 General
To be represented concisely, O/R addresses should only contain those
attributes which are necessary to uniquely identify the recipient. OUs and
DDAs which are unnecesssary for unique addressing should normally be
omitted.
NOTE - The use of a given name and/or initials will reduce the
requirement to include OUs which may change.
This annex is primarily concerned with representing the commonly-used
attributes in Table D.1, but physical delivery attributes (Table D.2) and
other attributes (Table D.3) are included for completeness.
Where national usage permits a single space value for the ADMD in an
address, this may be represented in the address by omitting the ADMD
attribute.
If O/R addresses are to be used between communicating parties which do not
use the same extended character set, the representation of the attribute
values should be composed exclusively from the printable string repertoire.
If the O/R address includes characters outside the printed string
repertoire, an alias composed entirely of printed string characters may be
required.
D.3.2 Labelled format
O/R addresses expressed in labelled format consist of pairs of labels and
values. The labels for each attribute are specified in Tables 1, 2 and 3.
The label and value shall either be separated by the character "=", or by
the space between two columns in a table.
The label for DDAs includes the value of 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.
If the value of a DDA type includes the character "=", this shall be
represented by "==".
If label/value pairs appear in sequence on a line, they shall be separated
by ";".
If the value of any attribute contains the ";" character, this shall be
represented by ";;".
If an address is entirely composed of attributes contained in Table D.1, it
is recommended that the sequence of attributes in the address is that given
in Table D.1.
Table D.1. Commonly-Used Attributes
Attribute Type Abbreviation Label
(if any)
Given Name G
Initials I
Surname S
Generation Qualifier Generation Q
Common Name CN
Organisation O
Organisational Unit 1 Org.Unit.1 OU1
Organisational Unit 2 Org.Unit.2 OU2
Organisational Unit 3 Org.Unit.3 OU3
Organisational Unit 4 Org.Unit.4 OU4
Private Management Domain Name PRMD P
Administration Management Domain Name ADMD A
Country C
Table D.2. Physical Delivery Attributes
Physical Delivery Personal Name PD-PN
Extension of Postal O/R Address Components PD-EXT-ADDRESS
Extension of Physical Delivery Address Components PD-EXT-DELIVERY
Physical Delivery Office Number PD-OFFICE NUMBER
Physical Delivery Office Name PD-OFFICE
Physical Delivery Organisation Name PD-O
Street Address PD-STREET
Unformatted Postal Address PD-ADDRESS
Unique Postal Name PD-UNIQUE
Local Postal Attributes PD-LOCAL
Postal Restante Address PD-RESTANTE
Post Office Box Address PD-BOX
Postal Code PD-CODE
Physical Delivery Service Name PD-SERVICE
Physical Delivery Country Name PD-C
Table D.3. Other Attributes
Network Address X.121
User Agent Numeric ID N-ID
Terminal Identifier T-ID
Terminal Type T-TY
Domain Defined Attribute DDA:<type>
where <type> is the name of the type of domain defined attribute.
If an identifier is required to preface a labelled address, it is
recommended that "X.400:" is used, for example:
X.400: G=john; S=smith; O=a bank ltd; P=abl; A=snomail; C=aq
NOTE - When the label-value pairs appear in sequence on a line, the use
of upper case for labels and lower case for the values facilitates accurate
use of the information by the user.
The address above may also be layed out as a table:
G John
S Smith
O A Bank Ltd
P ABL
A Snomail
C AQ
D.3.3 Self-explanatory format
The self-explanatory format may be used when space is available. It
consists of a list of the attribute names, either in full or abbreviated.
Recommended English language abbreviations are given for some of the
attributes in Table D.1. The names or abbreviations may be in any language,
but each name or abbreviation which is included in Table D.1 shall be
followed by the specified label. If an address is entirely composed of
attributes contained in Table D.1, it is recommended that the sequence of
attributes in the address is that given in Table D.1.
EXAMPLES
Fornavn (G): Per
Etternavn (S): Hansen
Organisasjon (O): Teledir
Organisasjonsenhet (OU1): Forskning
Privat domene (P): Tele
Administrasjonsdomene (A): Telemax
Land (C): NO
Given name (G): John
Surname (S): Smith
Organisation (O): A Bank Ltd
Org. Unit (OU1): IT Dept
Org. Unit (OU2): MSG Group
PRMD (P): ABL
ADMD (A): Snomail
Country (C): AQ
D.4 USER INTERFACE
D.4.1 General
The following requirements and recommendations apply to user interfaces
designed to be used in conjunction with the labelled or self-explanatory
formats.
- The user interface shall enable all the attributes in Table D.1 to be
entered, or any valid subset of these attributes.
- If the user interface lists the attributes, it is recommended that the
sequence used is that given in Table D.1.
- The name or abbreviation used to identify each attribute to the user shall
include use of the label specified in Table D.1.
EXAMPLE
Given name (G)
Initials (I)
Surname (S)
Generation Qualifier (Q)
Common Name (CN)
Organisation (O)
Organisational Unit 1 (OU1)
Organisational Unit 2 (OU2)
Organisational Unit 3 (OU3)
Organisational Unit 4 (OU4)
Private Management Domain Name (P)
Administration Management Domain Name (A)
Country (C)
- Where the country specified in an O/R address permits a single space value
for the ADMD in an address, this shall be taken as the value if the user
omits the ADMD attribute.
NOTE - As a consequence of clause 18 of CCITT Rec. X.402;ISO/IEC
10021-2:
- consecutive spaces inside a value are treated as single spaces, and
leading and trailing spaces are ignored, and
- no distinction is made between upper and lower case letters.
D.4.2 Copying O/R addresses to specific interfaces
It is recommended that command-line interfaces designed for use with
labelled-format O/R addresses should enable the user to copy the address
directly into the interface. The interface should not require the
attributes to be specified in any particular order.
NOTES
1. The user may be required to modify the format to make it acceptable to
certain existing command-line interfaces.
2. Many users will have difficulty copying an address presented as a table
(either in labelled or self-explanatory format) into a command line
interface.
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 names or labels.csg@pyramid.pyramid.com (06/06/91)
Hmpph. Is it really necessary to introduce yet another syntax for string representation of O/R names? (There are at least three already.) I see nothing that this one contributes that has not already been dealt with by the others. The others do have one major advantage: they are already deployed. Just say no to "standards" that differ from established practice for no obvious reason other than to be different. <csg>
mskuhn@immd4.informatik.uni-erlangen.de (Markus Kuhn) (06/07/91)
Thank you for posting the draft here. It would be nice if we could read
things like this more often on the net.
I think it's a good idea to include a standard for writing O/R addresses
in the X.400 familie. Are there also plans to do this for directory names?
Just two things, I missed in the draft:
- As the addresses are quite long, it will often be neccessary to split
them in two lines (eg on small business cards). Where should the
address be splitted? Only after semicolons seems preferebly to me.
- Should there be a space after each ';'? The examples show this,
but there is no note about it. May be, the printed documents won't
show this as clear as the ascii text. I personally don't like the
spaces very much as they again make the address longer. But they
should be used if there are any spaces in attribute values.
Markus
---
Markus Kuhn, Computer Science student -- University of Erlangen, Germany
X.400: G=Markus;S=Kuhn;OU1=rrze;OU2=cnve;P=uni-erlangen;A=dbp;C=de
I'net: mskuhn@immd4.informatik.uni-erlangen.de