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