rfc1685.txt

<VC++网络游戏建摸与实现>源代码

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