rfc1148.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   quoting mechanism similar to the printable string mechanism.  Each
   octet is represented as 3 decimal digits.

   There are a number of places where a string may have a Teletex and/or
   Printable String representation.  The following BNF is used to
   represent this.

   teletex-and-or-ps = [ printablestring ] [ "*" teletex-string ]

   The natural mapping is restricted to EBNF.ps-char, in order to make
   the full BNF easier to parse.

3.3.5.  UTCTime

   Both UTCTime and the RFC 822 822.date-time syntax contain:  Year
   (lowest two digits), Month, Day of Month, hour, minute, second
   (optional), and Timezone.  822.date-time also contains an optional
   day of the week, but this is redundant.  Therefore a symmetrical
   mapping can be made between these constructs.

   Note:
        In practice, a gateway will need to parse various illegal
        variants on 822.date-time.  In cases where 822.date-time
        cannot be parsed, it is recommended that the derived UTCTime
        is set to the value at the time of translation.

   The UTCTime format which specifies the timezone offset should be
   used.

3.3.6.  Integer

   A basic ASN.1 Integer will be mapped onto EBNF.numericstring.  In many
   cases ASN.1 will enumerate Integer values or use ENUMERATED.  An EBNF
   encoding labelled-integer is provided. When mapping from EBNF to
   ASN.1, only the integer value is mapped, and the associated text is
   discarded.  When mapping from ASN.1 to EBNF, addition of an
   appropriate text label is strongly encouraged.

      labelled-integer ::= [ key-string ] "(" numericstring ")"

      key-string      = *key-char
      key-char        = <a-z, A-Z, 1-9, and "-">

3.3.7.  Object Identifier

   Object identifiers are represented in a form similar to that
   given in ASN.1.  The numbers are mandatory, to ease encoding.
   It is recommended that as many strings as possible are used, to



Kille                                                          [Page 27]

RFC 1148               Mapping X.400(88) and 822              March 1990


   facilitate user recognition.

      object-identifier ::= [ defined-value ] oid-comp-list

      oid-comp-list ::= oid-comp oid-comp-list
                      | oid-comp

      defined-value ::= key-string

      oid-comp ::= [ key-string ] "(" numericstring ")"

3.4.  Encoding ASCII in Printable String

   Some information in RFC 822 is represented in ASCII, and needs to be
   mapped into X.400 elements encoded as printable string.  For this
   reason, a mechanism to represent ASCII encoded as PrintableString is
   needed.

   A structured subset of EBNF.printablestring is now defined.  This can
   be used to encode ASCII in the PrintableString character set.

      ps-encoded       = *( ps-restricted-char / ps-encoded-char )
      ps-encoded-char  = "(a)"               ; (@)
                       / "(p)"               ; (%)
                       / "(b)"               ; (!)
                       / "(q)"               ; (")
                       / "(u)"               ; (_)
                       / "(l)"               ; "("
                       / "(r)"               ; ")"
                       / "(" 3DIGIT ")"

   The 822.3DIGIT in EBNF.ps-encoded-char must have range 0-127, and is
   interpreted in decimal as the corresponding ASCII character.  Special
   encodings are given for: at sign (@), percent (%), exclamation
   mark/bang (!), double quote ("), underscore (_), left bracket ((),
   and right bracket ()).  These characters, with the exception of round
   brackets, are not included in PrintableString, but are common in RFC
   822 addresses.  The abbreviations will ease specification of RFC 822
   addresses from an X.400 system.  These special encodings should be
   mapped in a case insensitive manner, but always be generated in lower
   case.

   A reversible mapping between PrintableString and ASCII can now be
   defined.  The reversibility means that some values of printable
   string (containing round braces) cannot be generated from ASCII.
   Therefore, this mapping must only be used in cases where the
   printable strings may only be derived from ASCII (and will therefore
   have a restricted domain).  For example, in this specification, it is



Kille                                                          [Page 28]

RFC 1148               Mapping X.400(88) and 822              March 1990


   only applied to a Domain defined attribute which will have been
   generated by use of this specification and a value such as "(" would
   not be possible.

   To encode ASCII as PrintableString, the EBNF.ps-encoded syntax is
   used, with all EBNF.ps-restricted-char mapped directly.  All other
   822.CHAR are encoded as EBNF.ps-encoded-char.

   To encode PrintableString as ASCII, parse PrintableString as
   EBNF.ps-encoded, and then reverse the previous mapping.  If the
   PrintableString cannot be parsed, then the mapping is being applied
   in to an inappropriate value, and an error should be given to the
   procedure doing the mapping. In some cases, it may be preferable to
   pass the printable string through unaltered.

   Some examples are now given.  Note the arrows which indicate
   asymmetrical mappings:

                   PrintableString           ASCII

                   'a demo.'         <->   'a demo.'
                   foo(a)bar         <->   foo@bar
                   (q)(u)(p)(q)      <->   "_%"
                   (a)               <->   @
                   (A)               <->   @
                   (l)a(r)           <->   (a)
                   (126)             <->   ~
                   (                  ->   (
                   (l)               <->   (

Chapter 4 -- Addressing

   Addressing is probably the trickiest problem of an X.400 <-> RFC 822
   gateway.  Therefore it is given a separate chapter.  This chapter, as
   a side effect, also defines a textual representation of an X.400 O/R
   Address.

   Initially, we consider an address in the (human) mail user sense of
   "what is typed at the mailsystem to reference a mail user".  A basic
   RFC 822 address is defined by the EBNF EBNF.822-address:

                822-address     = [ route ] addr-spec

   In an 822-MTS protocol, the originator and each recipient should be
   considered to be defined by such a construct.  In an RFC 822 header,
   the EBNF.822-address is encapsulated in the 822.address syntax rule,
   and there may also be associated comments.  None of this extra
   information has any semantics, other than to the end user.



Kille                                                          [Page 29]

RFC 1148               Mapping X.400(88) and 822              March 1990


   The basic X.400 O/R Address, used by the MTS for routing, is defined
   by MTS.ORAddress.  In IPMS, the MTS.ORAddress is encapsulated within
   IPMS.ORDescriptor.

   It can be seen that RFC 822 822.address must be mapped with
   IPMS.ORDescriptor, and that RFC 822 EBNF.822-address must be mapped
   with MTS.ORAddress.

4.1.  A textual representation of MTS.ORAddress

   MTS.ORAddress is structured as a set of attribute value pairs.  It is
   clearly necessary to be able to encode this in ASCII for gatewaying
   purposes.  All aspects should be encoded, in order to guarantee
   return of error messages, and to optimise third party replies.

4.2.  Basic Representation

   An O/R Address has a number of structured and unstructured
   attributes.  For each unstructured attribute, a key and an encoding
   is specified.  For structured attributes, the X.400 attribute is
   mapped onto one or more attribute value pairs.  For domain defined
   attributes, each element of the sequence will be mapped onto a triple
   (key and two values), with each value having the same encoding.  The
   attributes are as follows, with 1984 attributes given in the first
   part of the table.  For each attribute, a reference is given,
   consisting of the relevant sections in X.402 / ISO 10021-2, and the
   extension identifier for 88 only attributes:

Attribute (Component)               Key            Enc     Ref       Id

84/88 Attributes

MTS.CountryName                     C              P       18.3.3
MTS.AdministrationDomainName        ADMD           P       18.3.1
MTS.PrivateDomainName               PRMD           P       18.3.21
MTS.NetworkAddress                  X121           N       18.3.7
MTS.TerminalIdentifier              T-ID           N       18.3.23
MTS.OrganizationName                O              P/T     18.3.9
MTS.OrganizationalUnitNames.value   OU             P/T     18.3.10
MTS.NumericUserIdentifier           UA-ID          N       18.3.8
MTS.PersonalName                    PN             P/T     18.3.12
MTS.PersonalName.surname            S              P/T     18.3.12
MTS.PersonalName.given-name         G              P/T     18.3.12
MTS.PersonalName.initials           I              P/T     18.3.12
MTS.PersonalName
   .generation-qualifier            GQ             P/T     18.3.12
MTS.DomainDefinedAttribute.value    DD             P/T     18.1




Kille                                                          [Page 30]

RFC 1148               Mapping X.400(88) and 822              March 1990


88 Attributes

MTS.CommonName                      CN             P/T     18.3.2    1
MTS.TeletexCommonName               CN             P/T     18.3.2    2
MTS.TeletexOrganizationName         O              P/T     18.3.9    3
MTS.TeletexPersonalName             PN             P/T     18.3.12   4
MTS.TeletexPersonalName.surname     S              P/T     18.3.12   4
MTS.TeletexPersonalName.given-name  G              P/T     18.3.12   4
MTS.TeletexPersonalName.initials    I              P/T     18.3.12   4
MTS.TeletexPersonalName
   .generation-qualifier            GQ             P/T     18.3.12   4
MTS.TeletexOrganizationalUnitNames
   .value                           OU             P/T     18.3.10   5
MTS.TeletexDomainDefinedAttribute
   .value                           DD             P/T     18.1      6
MTS.PDSName                         PD-SYSTEM      P       18.3.11   7
MTS.PhysicalDeliveryCountryName     PD-C           P       18.3.13   8
MTS.PostalCode                      POSTCODE       P       18.3.19   9
MTS.PhysicalDeliveryOfficeName      PD-OFFICE      P/T     18.3.14  10
MTS.PhysicalDeliveryOfficeNumber    PD-OFFICE-NUM  P/T     18.3.15  11
MTS.ExtensionORAddressComponents    PD-EXT-D       P/T     18.3.4   12
MTS.PhysicalDeliveryPersonName      PD-PN          P/T     18.3.17  13
MTS.PhysicalDelivery                PD-O           P/T     18.3.16  14
   OrganizationName
MTS.ExtensionPhysicalDelivery
   AddressComponents                PD-EXT-LOC     P/T     18.3.5   15
MTS.UnformattedPostalAddress        PD-ADDRESS     P/T     18.3.25  16
MTS.StreetAddress                   STREET         P/T     18.3.22  17
MTS.PostOfficeBoxAddress            PO-BOX         P/T     18.3.18  18
MTS.PosteRestanteAddress            POSTE-RESTANTE P/T     18.3.20  19
MTS.UniquePostalName                PD-UNIQUE      P/T     18.3.26  20
MTS.LocalPostalAttributes           PD-LOCAL       P/T     18.3.6   21
MTS.ExtendedNetworkAddress
   .e163-4-address.number           NET-NUM        N       18.3.7   22
MTS.ExtendedNetworkAddress
   .e163-4-address.sub-address      NET-SUB        N       18.3.7   22
MTS.ExtendedNetworkAddress
  .psap-address                     NET-PSAP       X       18.3.7   22
MTS.TerminalType                    NET-TTYPE      I       18.3.24  23

   The following keys identify different EBNF encodings, which are
   associated with the ASCII representation of MTS.ORAddress.

                 Key         Encoding

                 P     printablestring
                 N     numericstring
                 T     teletex-string



Kille                                                          [Page 31]

RFC 1148               Mapping X.400(88) and 822              March 1990


                 P/T   teletex-and-or-ps
                 I     labelled-integer
                 X     presentation-address

   The BNF for presentation-address is taken from the specification "A
   String Encoding of Presentation Address" [Kille89a].

   In most cases, the EBNF encoding maps directly to the ASN.1 encoding
   of the attribute.  There are a few exceptions. In cases where an
   attribute can be encoded as either a PrintableString or NumericString
   (Country, ADMD, PRMD), either form should be mapped into the BNF.
   When generating ASN.1, the NumericString encoding should be used if
   the string contains only digits.

   There are a number of cases where the P/T (teletex-and-or-ps)
   representation is used.  Where the key maps to a single attribute,
   this choice is reflected in the encoding of the attribute (attributes
   10-21).  For most of the 1984 attributes and common name, there is a
   printablestring and a teletex variant.   This pair of attributes is
   mapped onto the single component here.  This will give a clean
   mapping for the common cases where only one form of the name is used.

4.2.1.  Encoding of Personal Name

   Handling of Personal Name and Teletex 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 defined, which is designed to provide
   a clean encoding for the common cases of O/R address specification
   where:

      1.   There is no generational qualifier

      2.   Initials contain only letters

      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.

   The following EBNF is defined:

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

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




Kille                                                          [Page 32]

RFC 1148               Mapping X.400(88) and 822              March 1990


                initial         = ALPHA

                surname         = printablestring

   This can be used to map from any string containing only printable
   string characters to an O/R address personal name. Parse the string
   according to the EBNF.  The given name and surname are assigned
   directly.  All EBNF.initial tokens are concatenated without
   intervening full stops to generate the initials.

   For an O/R address which follows the above restrictions, a string can
   be derived in the natural manner.  In this case, the mapping will be
   reversible.

        For example:

                GivenName       = "Marshall"
                Surname         = "Rose"

                Maps with  "Marshall.Rose"

                Initials        = "MT"
                Surname         = "Rose"