(Note: The original of this document can be found here. -thb)

Annex F: Representation of O/R addresses for human usage

Final text for AMENDMENT, 7 February 1993. (This annex does not form an integral part of this Recommendation / International Standard.)

Contents:

Purpose
Scope
Format
User interface

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 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:

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.
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.
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 "Mac Donald" as an alias for MacDonald).
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 "=". 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.

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

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.

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 "\=". 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.

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

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.

Notes:

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)

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.
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:

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.
The Norwegian user of a form fill interface receives the same business card. The form on the screen includes the following field names:
```
         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.)

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

From: nbevan@ess.cs.ucl.ac.uk (Nigel Bevan)
Subject: Representation of O/R addresses
Newsgroups: comp.protocols.iso.x400
Date: 13 Feb 93 14:31:57 GMT

Auswege: Impressum, Haftungsausschlu�, Datenschutz, Auswege: Eine Ebene hoch, Meine Homepage.

Thomas Bätzler, Thomas@Baetzler.de

$Id: annex_f.html 1.1 1995/07/12 23:40:16 thb Exp thb $