From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc1685.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 619 insertions(+)
 create mode 100644 doc/rfc/rfc1685.txt

(limited to 'doc/rfc/rfc1685.txt')

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]
+
-- 
cgit v1.2.3