Movatterモバイル変換

Network Working Group                                      H. AlvestrandRequest for Comments: 1685                                       UNINETTRARE Technical Report: 12                                    August 1994Category: InformationalWriting X.400 O/R NamesStatus 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 19943. 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 thisRARE 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" andRARE 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           CRARE 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)                               NORARE 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=no4. 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.zipRARE Working Group on Mail and Messaging (WG-MSG)              [Page 10]

RFC 1685                Writing X.400 O/R Names              August 19945. 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   NORWAYRFC822: Harald.Alvestrand@uninett.no   X.400:  C=no; ADMD=; PRMD=uninett; O=uninett; S=alvestrand;   G=haraldRARE Working Group on Mail and Messaging (WG-MSG)              [Page 11]