rfc1327.txt

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

   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.

   When mapping to X.400, the UTCTime format which specifies the
   timezone offset shall be used.

   When mapping to RFC 822, the 822.date-time format shall include a
   numeric timezone offset (e.g., +0000).

   When mapping time values, the timezone shall be preserved as
   specified.  The date shall not be normalised to any other timezone.

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



Hardcastle-Kille                                               [Page 27]

RFC 1327        Mapping between X.400(1988) and RFC 822         May 1992


   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, 0-9, and "-">


3.3.7.  Object Identifier

   Object identifiers are represented in a form similar to that given in
   ASN.1.  The order is the same as for ASN.1 (big-endian).  The numbers
   are mandatory, and used when mapping from the ASCII to ASN.1.  The
   key-strings are optional.  It is recommended that as many strings as
   possible are generated when mapping from ASN.1 to ASCII, to
   facilitate user recognition.

        object-identifier  ::= oid-comp object-identifier
                        | oid-comp

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

An example representation of an object identifier is:

        joint-iso-ccitt(2) mhs (6) ipms (1) ep (11) ia5-text (0)

        or

        (2) (6) (1)(11)(0)

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
   shall be used to encode ASCII in the PrintableString character set.










Hardcastle-Kille                                               [Page 28]

RFC 1327        Mapping between X.400(1988) and RFC 822         May 1992


        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 shall be
   interpreted in a case insensitive manner, but always 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
   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 shall be given to the
   procedure doing the mapping. In some cases, it may be preferable to
   pass the printable string through unaltered.










Hardcastle-Kille                                               [Page 29]

RFC 1327        Mapping between X.400(1988) and RFC 822         May 1992


   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 are
   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.

   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 components shall be encoded, in order to guarantee
   return of error messages, and to optimise third party replies.



Hardcastle-Kille                                               [Page 30]

RFC 1327        Mapping between X.400(1988) and RFC 822         May 1992


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           P     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

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



Hardcastle-Kille                                               [Page 31]

RFC 1327        Mapping between X.400(1988) and RFC 822         May 1992


MTS.PDSName                            PD-SERVICE     P     18.3.11   7
MTS.PhysicalDeliveryCountryName        PD-C           P     18.3.13   8
MTS.PostalCode                         PD-CODE        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-ADDRESS P/T   18.3.4    12
MTS.PhysicalDeliveryPersonName         PD-PN          P/T   18.3.17   13
MTS.PhysicalDeliveryOrganizationName   PD-O           P/T   18.3.16   14
MTS.ExtensionPhysicalDelivery
   AddressComponents                  PD-EXT-DELIVERY P/T   18.3.5    15
MTS.UnformattedPostalAddress           PD-ADDRESS     P/T   18.3.25   16
MTS.StreetAddress                      PD-STREET      P/T   18.3.22   17
MTS.PostOfficeBoxAddress               PD-BOX         P/T   18.3.18   18
MTS.PosteRestanteAddress               PD-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                       T-TY           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
                   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 is mapped into the BNF.  When
   generating ASN.1, the NumericString encoding shall 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,



Hardcastle-Kille                                               [Page 32]

RFC 1327        Mapping between X.400(1988) and RFC 822         May 1992


   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.

   Recently, ISO has undertaken work to specify a string form of O/R
   Address [CCITT/ISO91a].  This has specified a number of string
   keywords for attributes.  As RFC 1148 was an input to this work, many
   of the keywords are the same.  To increase compatability, the
   following alternative values shall be recognised when mapping from
   RFC 822 to X.400.  These shall not be generated when mapping from
   X.400 to RFC 822.

                   Keyword          Alternative

               ADMD               A
               PRMD               P
               GQ                 Q
               X121               X.121
               UA-ID              N-ID
               PD-OFFICE-NUMBER   PD-OFFICE NUMBER

   When mapping from RFC 822 to X.400, the keywords: OU1, OU2, OU3, and
   OU4, shall be recognised.    If these are present, no keyword OU
   shall be present.  These will be treated as ordered values of OU.

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.   Surname does not contain full stop in the first two
        characters.

   5    If Surname is the only component, it does not contain full
        stop.



Hardcastle-Kille                                               [Page 33]

RFC 1327        Mapping between X.400(1988) and RFC 822         May 1992