rfc987.txt

RFC 相关的技术文档

         Auto-forwarded Indication

            Supported as new RFC 822 header.

         Originator Indication

            Supported.

         Authorising User's Indication

            Supported, although the mapping (From:) is not quite the
            same.

         Primary and Copy Recipients Indication

            Supported.

         Expiry Date Indication

            Supported as new RFC 822 header.  In general, only human
            action can be expected.

         Cross Referencing Indication

            Supported.

         Importance Indication

            Supported as new RFC 822 header.

         Obsoleting Indication

            Supported as new RFC 822 header.

         Sensitivity Indication

            Supported as new RFC 822 header.

         Subject Indication

            Supported.

         Reply Request Indication

            Supported as comment next to address.




Kille                                                          [Page 15]



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


         Forwarded IP-message Indication

            Supported, with some loss of information.

         Body Part Encryption Indication

            Not supported.

         Multi-part Body

            Supported, with some loss of information, in that the
            structuring cannot be formalised in RFC 822.





































Kille                                                          [Page 16]



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


Chapter 3 -- Basic Mappings

   3.1.  Notation

      The P1 and P2 protocols are encoded in a structured manner
      according to the X.409 specifications, whereas RFC 822 is text
      encoded.  To define a detailed mapping, it is necessary to refer
      to detailed protocol elements in each format.  This is described.

      3.1.4.  RFC 822

         Structured text is defined according to the Extended Backus
         Naur Form (EBNF) defined in section 2 of RFC 822 [Crocker82a].
         In the EBNF definitions used in this specification, the syntax
         rules given in Appendix D of RFC 822 are assumed.  When these
         EBNF tokens are referred to outside an EBNF definition, they
         are identified by the string "882." appended to the beginning
         of the string (e.g. 822.addr-spec).  Additional syntax rules,
         to be used throughout this specification are defined in this
         chapter.

         The EBNF is used in two ways.

            1.   To describe components of RFC 822 messages (or of
                 822-P1 components).  In this case, the lexical analysis
                 defined in section 3 of RFC 822 should be used.  When
                 these new EBNF tokens are referred to outside an EBNF
                 definition, they are identified by the string "EBNF."
                 appended to the beginning of the string (e.g.
                 EBNF.bilateral-info).

            2.   To describe the structure of IA5 or ASCII information
                 not in an RFC 822 message.  In these cases, tokens will
                 either be self delimiting, or be delimited by self
                 delimiting tokens.  Comments and LWSP are not used as
                 delimiters.

      3.1.5.  X.409

         An element is referred to with the following syntax, defined in
         EBNF:

            element        = protocol "." definition *( "." definition )
            protocol       = "P1" / "P2"
            definition     = identifier / context
            identifier     = ALPHA *< ALPHA or DIGIT or "-" >
            context        = "[" 1*DIGIT "]"


Kille                                                          [Page 17]



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


         For example, P2.Heading.subject defines the subject element of
         the P2 heading.  The same syntax is also used to refer to
         element values. For example,
         P1.EncodedInformationTypes.[0].g3Fax refers to a value of
         P1.EncodedInformationTypes.[0] .

   3.2.  ASCII and IA5

      A gateway will interpret all IA5 as ASCII.  Thus, they are treated
      identically for the rest of this document.

   3.3.  Universal Primitives

      There is a need to convert between ASCII text, and some of the
      Universal Primitive types defined in X.409 [CCITT84d].  For each
      case, an EBNF syntax definition is given, for use in all of this
      specification.  All EBNF syntax definitions of Universal
      Primitives are in lower case, whereas X.409 primitives are
      referred to with the first letter in upper case.  Except as noted,
      all mappings are symmetrical.

      3.3.1.  Boolean

         Boolean is encoded as:

            boolean = "TRUE" / "FALSE"

      3.3.2.  NumericString

         NumericString is encoded as:

            numericstring = *DIGIT

      3.3.3.  PrintableString

         PrintableString is a restricted IA5String defined as:

            printablestring  = *( ps-char / ps-delim )

            ps-char          = 1DIGIT /  1ALPHA / " " / "'" / "+" / ")"
                               / "," / "-" / "." / "/" / ":" / "=" / "?"

            ps-delim         = "("

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


Kille                                                          [Page 18]



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


            ps-encoded       = *( ps-char / ps-encoded-char )

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

         The 822.3DIGIT in EBNF.ps-encoded-char must have range 0-127
         (Decimal), and is interpreted in decimal as the corresponding
         ASCII character. Special encodings are given for: at sign (@),
         percent (%), exclamation mark/bang (!), double quote ("), and
         underscore (_).  These characters 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.

         An asymmetric mapping between PrintableString and ASCII can now
         be defined <3>.  To encode ASCII as PrintableString, the
         EBNF.ps-encoded syntax is used, with all EBNF.ps-char AND
         EBNF.ps-delim mapped directly <4>.  All other 822.CHAR are
         encoded as EBNF.ps-encoded-char. There are two cases of
         encoding PrintableString as ASCII.  If the PrintableString can
         be parsed as EBNF.ps-encoded, then the previous mapping should
         be reversed.  If not, it should be interpreted as
         EBNF.printablestring.

         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)               <-    (a)
            (040)a(041)       ->    (a)
            (040)(a)          ->    (@
            ((a)              <-    (@

         The algorithm is designed so that it is simple to use in all
         common cases, so that it is general, and so that it is
         straightforward to code.  It is not attempting to minimise the
         number of pathological cases.


Kille                                                          [Page 19]



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


      3.3.4.  T.61String

         T.61 strings are, in general, only used for conveying human
         interpreted information.  Thus, the aim of a mapping should be
         to render the characters appropriately in the remote character
         set, rather than to maximise reversibility.  The mappings
         defined in the CEN/CENELEC X.400 functional standard should be
         used [CEN/CENELEC/85a].  These are based on the mappings of
         X.408 (sections 4.2.2 and 5.2.2).

      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 <5>.
         The UTCTime format which specifies the timezone offset should
         be used, in line with CEN/CENELEC recommendations.






























Kille                                                          [Page 20]



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


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 standard textual representation of
   X.400 addresses.

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

      822-address     = [ route ] addr-spec

   In an 822-P1 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.

   The basic X.400 address is defined by P1.ORName.  In P1 all recipient
   P1.ORnames are encapsulated within P1.RecipientInfo, and in P2 all
   P2.ORNames <6> are encapsulated within P2.ORDescriptor.

   It can be seen that RFC 822 822.address must be mapped with
   P2.ORDescriptor, and that RFC 822 EBNF.822-address must be mapped
   with P1.ORName (originator) and P1.RecipientInfo (recipients).

   This chapter is structured as follows:

      4.1  Introduction.

      4.2  A textual representation of P1.ORName.  This is needed for
           the later mappings, and as a side effect provides a standard
           representation for O/R names.

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

      4.4  The Full P1 / 822-P1 Mapping

      4.5  The Full P2 / RFC 822 Mapping

      4.6  Mapping Message-IDs.







Kille                                                          [Page 21]



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