rfc987.txt

RFC 相关的技术文档

   4.1.  A textual representation of P1.ORName.

      P1.ORName is structured as a set of attribute value pairs.  It is
      clearly necessary to be able to encode this in ASCII for
      gatewaying purposes.  A general encoding is given here, which may
      be used as a basis for a user interface, as well as for the
      defined gateway mapping.

      4.1.1.  Basic Representation

         A series of BNF definitions of each possible attribute value
         pair is given, which is given a 1:1 mapping with the X.400
         encoding.  The rest of the mapping then talks in terms of these
         BNF components, with the mapping to X.400 encoding being
         trivial.

         attributevalue = c / admd / prmd / x121 / t-id / o / ou
                         / ua-id / pn.g / pn.i / pn.s / pn.gq / dd.value

         c        = printablestring       ; P1.CountryName
         admd     = printablestring       ; P1.AdministrationDomainName
         prmd     = printablestring       ; P1.PrivateDomainName
         x121     = numericstring         ; P1.X121Address
         t-id     = numericstring         ; P1.TerminalID
         o        = printablestring       ; P1.OrganisationName
         ou       = printablestring       ; P1.OrganisationalUnit
         ua-id    = numericstring         ; P1.UniqueUAIdentifier
         pn.s     = printablestring       ; P1.PersonalName.surName
         pn.g     = printablestring       ; P1.PersonalName.givenName
         pn.i     = printablestring       ; P1.PersonalName.initials
         pn.gq    = printablestring       ; P1.PersonalName.generation
                                            Qualifier
         dd.value = printablestring       ; P1.DomainDefined
                                            Attribute.value

         In cases where an attribute can be encoded as either a
         PrintableString or NumericString (Country, ADMD, PRMD) it is
         assumed that the NumericString encoding will be adopted if
         possible.  This prevents the encoding of PrintableString where
         the characters are all numbers. This restriction seems
         preferable to the added complexity of a general solution.
         Similarly, we can define a set of attribute types.







Kille                                                          [Page 22]



RFC 987                                                        June 1986
Mapping between X.400 and RFC 822


         dd.type = printablestring      ; P1.DomainDefinedAttribute.type

         standard-type =
                   "C"           ; P1.CountryName
                 / "ADMD"        ; P1.AdministrationDomainName
                 / "PRMD"        ; P1.PrivateDomainName
                 / "X121"        ; P1.X121Address
                 / "T-ID"        ; P1.TerminalID
                 / "O"           ; P1.OrganisationName
                 / "OU"          ; P1.OrganisationalUnit
                 / "UA-ID"       ; P1.UniqueUAIdentifier
                 / "S"           ; P1.PersonalName.surName
                 / "G"           ; P1.PersonalName.givenName
                 / "I"           ; P1.PersonalName.initials
                 / "GQ"          ; P1.PersonalName.generationQualifier

         standard-dd-type =
                   "RFC-822"     ; dd.type = "RFC-822"
                 / "JNT-Mail"    ; dd.type = "JNT-Mail"
                 / "UUCP"        ; dd.type = "UUCP"

      4.1.2.  Encoding of Personal Name

         Handling of Personal Name based purely on the
         EBNF.standard-type syntax defined above is likely to be clumsy.
         It seems desirable to utilise the "human" conventions for
         encoding these components.  A syntax is proposed here.  It is
         designed to cope with the common cases of O/R Name
         specification where:

            1.   There is no generational qualifier

            2.   Initials contain only letters <7>.

            3.   Given Name does not contain full stop ("."), and is at
                 least two characters long.

            4.   If Surname contains full stop, then it may not be in
                 the first two characters, and either initials or given
                 name is present.









Kille                                                          [Page 23]



RFC 987                                                        June 1986
Mapping between X.400 and RFC 822


         The following EBNF is defined:

            encoded-pn      = [ given "." ] *( initial "." ) surname

            given           = 2*<ps-char not including ".">

            initial         = ALPHA

            surname         = printablestring

         Subject to the above restriction, this is a reversible mapping.

         For example:

            GivenName       = "Marshall"
            Surname         = "Rose"

            Maps with  "Marshall.Rose"

            Initials        = "MT"
            Surname         = "Rose"

            Maps with  "M.T.Rose"

            GivenName       = "Marshall"
            Initials        = "MT"
            Surname         = "Rose"

            Maps with  "Marshall.M.T.Rose"

         Note that CCITT guidelines suggest that Initials is used to
         encode ALL initials.  Therefore, the proposed encoding is
         "natural" when either GivenName or Initials, but not both, are
         present.  The case where both are present can be encoded, but
         this appears to be contrived!

      4.1.3.  Two encodings of P1.ORName

         Given this structure, we can specify a BNF representation of an
         O/R Name.









Kille                                                          [Page 24]



RFC 987                                                        June 1986
Mapping between X.400 and RFC 822


            std-orname      = 1*( "/" attribute "=" value ) "/"
            attribute       = standard-type
                            / "PN"
                            / standard-dd-type
                            / registered-dd-type
                            / "DD." std-printablestring
            value           = std-printablestring
            registered-dd-type
                            = std-printablestring
            std-printablestring =
                            = *( std-char / std-pair )
            std-char        = <ps-delim, and any ps-char except "/"
                              and "=">
            std-pair        = "$" ( ps-delim / ps-char )

         If the type is PN, the value is interpreted according to
         EBNF.encoded-pn, and the components of P1.PersonalName derived
         accordingly.  If the value is registered-dd-type, if the value
         is registered at the SRI NIC as an accepted Domain Defined
         Attribute type, then the value should be interpreted
         accordingly.  This restriction maximises the syntax checking
         which can be done at a gateway.

         Another syntax is now defined.  This is intended to be
         compatible with the syntax used for 822.domains.  This syntax
         is not intended to be handled by users.

            dmn-orname      = dmn-part *( "." dmn-part )
            dmn-part        = attribute "$" value
            attribute       = standard-type
                            / "~" dmn-printablestring
            value           = dmn-printablestring
            dmn-printablestring =
                            = *( dmn-char / dmn-pair )
            dmn-char        = <ps-delim, and any ps-char except ".">
            dmn-pair        = "\."

         For example: C$US.ADMD$ATT.~ROLE$Big\.Chief











Kille                                                          [Page 25]



RFC 987                                                        June 1986
Mapping between X.400 and RFC 822


   4.2.  Mapping between EBNF.822-address and P1.ORName

      Ideally, the mapping specified would be entirely symmetrical and
      global, to enable addresses to be referred to transparently in the
      remote system, with the choice of gateway being left to the
      Message Transfer Service.  There are two fundamental reasons why
      this is not possible:

         1.   The syntaxes are sufficiently different to make this
              awkward.

         2.   In the general case, there would not be the necessary
              administrative co-operation between the X.400 and RFC 822
              worlds, which would be needed for this to work.

      Therefore, an asymmetrical mapping is defined.

      4.2.1.  X.400 encoded in RFC 822

         The std-orname syntax is  used to encode O/R Name information
         in the 822.local-part of EBNF.822-address.  Further  O/R Name
         information may be associated with the 822.domain component.
         This cannot be used in the general case, basically due to
         character set problems, and lack of order in X.400 O/R Names.
         The only way to encode the full PrintableString character set
         in a domain is by use of the 822.domain-ref syntax.  This is
         likely to cause problems on many systems.  The effective
         character set of domains is in practice reduced from the
         RFC 822 set, by restrictions imposed by domain conventions and
         policy.

         A generic 822.address consists of a 822.local-part and a
         sequence of 822.domains (e.g.
         <@domain1,@domain2:user@domain3>).  All except the 822.domain
         associated with the 822.local-part (domain3 in this case)
         should be considered to specify routing within the RFC 822
         world, and will not be interpreted by the gateway (although
         they may have identified the gateway from within the RFC 822
         world).  The 822.domain associated with the 822.local-part may
         also identify the gateway from within the RFC 822 world.  This
         final 822.domain may be used to determine some number of O/R
         Name attributes.  The following O/R Name attributes are
         considered as a hierarchy, and may be specified by the domain.
         They are (in order of hierarchy):

            Country, ADMD, PRMD, Organisation, Organisational Unit



Kille                                                          [Page 26]



RFC 987                                                        June 1986
Mapping between X.400 and RFC 822


         There may be multiple Organisational Units.

         Associations may be defined between domain specifications, and
         some set of attributes.  This association proceeds
         hierarchically: i.e. if a domain implies ADMD, it also implies
         country.  If one of the hierarchical components is omitted from
         an X.400 structure, this information can be associated with the
         corresponding domain (e.g. a domain can be mapped onto a
         Country/ADMD/Organisation tuple). Subdomains under this are
         associated according to the O/R Name hierarchy.  For example:

            => "AC.UK" might be associated with
                                          C="234", ADMD="BT", PRMD="DES"

            then domain "R-D.Salford.AC.UK" maps with
                   C="234", ADMD="BT", PRMD="DES", O="Salford", OU="R-D"

         There are two basic reasons why a domain/attribute mapping
         might be maintained, as opposed to using simply subdomains:

            1.   As a shorthand to avoid redundant X.400 information.
                 In particular, there will often be only one ADMD per
                 country, and so it does not need to be given
                 explicitly.

            2.   To deal with cases where attribute values do not fit
                 the syntax:

               domain-syntax   = ALPHA [ *alphanumhyphen alphanum ]
               alphanum        = <ALPHA or DIGIT>
               alphanumhyphen  = <ALPHA or DIGIT or HYPHEN>

         Although RFC 822 allows for a more general syntax, this
         restriced syntax is chosen as it is the one chosen by the
         various domain service administrations.

         This provides a general aliasing mechanism.

         This set of mappings need only be known by the gateways
         relaying between the RFC 822 world, and the O/R Name namespace
         associated with the mapping in question.  However, it is
         desirable (for the optimal mapping of third party addresses)
         for all gateways to know these mappings.  A format for the
         exchange of this information is defined in Appendix F.

         From the standpoint of the RFC 822 Message Transfer System, the
         domain specification is simply used to route the message in the


Kille                                                          [Page 27]



RFC 987                                                        June 1986
Mapping between X.400 and RFC 822


         standard manner.  The standard domain mechanisms are used to
         identify gateways, and are used to select appropriate gateways
         for the corresponding O/R Name namespace.  In most cases, this
         will be done by registering the higher levels, and assuming
         that the gateway can handle the lower levels.

         As a further mechanism to simplify the encoding of common
         cases, where the only attributes to be encoded on the LHS are
         Personal Name attributes which comply with the restrictions of
         4.2.2, the 822.local-part may be encoded as EBNF.encoded-pn.

         An example encoding is:

            /PN=J.Linnimouth/GQ=5/@Marketing.Xerox.COM

            encodes the P1.ORName consisting of

               P1.CountryName                  = "US"
               P1.AdministrationDomainName     = "ATT"
               P1.OrganisationName             = "Xerox"
               P1.OrganisationalUnit           = "Marketing"
               P1.PersonalName.surName         = "Linnimouth"
               P1.PersonalName.initials        = "J"
               P1.PersonalName.GenerationQualifier = "5"

            If the GenerationQualifier was not present, the encoding
            [e-mail] could be used.

         Note that in this example, the first three attributes are
         determined by the domain Xerox.COM.  The OrganisationalUnit is
         determined systematically.

         There has been an implicit assumption that an RFC 822 domain is
         either X.400 or RFC 822.  This is pragmatic, but undesirable,
         as the namespace should be structured on a logical basis which
         does not necessarily correspond to the choice of Message
         Transfer protocols. The restriction can be lifted, provided
         that the nameservice deals with multiple message transfer
         protocols.  This can happen in a straightforward manner for the
         UK NRS, as explained in [Kille86a].  It could also be achieved
         with the DARPA Domain Nameserver scheme by use of the WKS
         mechanism.







Kille                                                          [Page 28]



RFC 987                                                        June 1986
Mapping between X.400 and RFC 822


      4.2.2.  RFC 822 Encoded in X.400