summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1685.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1685.txt')
-rw-r--r--doc/rfc/rfc1685.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc1685.txt b/doc/rfc/rfc1685.txt
new file mode 100644
index 0000000..9e84402
--- /dev/null
+++ b/doc/rfc/rfc1685.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+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]
+