rfc1327.txt

RFC 的详细文档！

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

Non Receipt Notification Request
      Not supported.

Non Repudiation of Delivery
      Not supported.

Non Repudiation of Origin
      N/A (reception).

Non Repudiation of Submission
      N/A (local).

Obsoleting Indication
      Supported as new RFC 822 header (Obsoletes:).

Ordinary Mail
      N/A (PDAU).

Originator Indication
      Supported.

Originator Requested Alternate Recipient
      Not supported, but is placed as comment next to address
      X400-Recipients:).

Physical Delivery Notification by MHS
      N/A (PDAU).

Physical Delivery Notification by PDS
      N/A (PDAU).





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


Physical Forwarding Allowed
      Supported by use of a comment in a new RFC 822 header
      X400-Recipients:), associated with the recipient in
      question.

Physical Forwarding Prohibited
      Supported by use of a comment in a new RFC 822 header
      X400-Recipients:), associated with the recipient in
      question.

Prevention of Non-delivery notification
      Supported, as delivery notifications cannot be generated by
      RFC 822.  In practice, errors will be returned as IP
      Messages, and so this service may appear not to be supported
      see Non-delivery Notification).

Primary and Copy Recipients Indication
      Supported

Probe
      Supported at the gateway (i.e., the gateway services the
      probe).

Probe Origin Authentication
      N/A (reception).

Proof of Delivery
      Not supported.

Proof of Submission
      N/A (local).

Receipt Notification Request Indication
      Not supported.

Redirection Allowed by Originator
      Redirection means MTS supported redirection, in the manner
      of X.400.  This service does not exist in the RFC 822 world.
      RFC 822 redirection (e.g., aliasing) should be regarded as
      an informal redirection mechanism, beyond the scope of this
      control.  Messages will be sent to RFC 822, irrespective of
      whether this service is requested.  Theoretically therefore,
      this service is supported, although in practice it may
      appear that it is not supported.

Registered Mail
      N/A (PDAU).




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


Registered Mail to Addressee in Person
      N/A (PDAU).

Reply Request Indication
      Supported as comment next to address.

Replying IP Message Indication
      Supported.

Report Origin Authentication
      N/A (reception).

Request for Forwarding Address
      N/A (PDAU).

Requested Delivery Method
      N/A (local).   The services required must be dealt with at
      submission time.  Any such request is made available through
      the gateway by use of a comment associated with the
      recipient in question.

Return of Content
      In principle, this is N/A, as non-delivery notifications are
      not supported.  In practice, most RFC 822 systems will
      return part or all of the content along with the IP Message
      indicating an error (see Non-delivery Notification).

Sensitivity Indication
      Supported as new RFC 822 header (Sensitivity:).

Special Delivery
      N/A (PDAU).

Stored Message Deletion
      N/A (MS).

Stored Message Fetching
      N/A (MS).

Stored Message Listing
      N/A (MS).

Stored Message Summary
      N/A (MS).

Subject Indication
      Supported.




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


Undeliverable Mail with Return of Physical Message
      N/A (PDAU).

Use of Distribution List
      In principle this applies only to X.400 supported
      distribution lists (see DL Expansion Prohibited).
      Theoretically, this service is N/A (prior).  In practice,
      because of informal RFC 822 lists, this service can be
      regarded as supported.

2.3.2.  Reception by X.400

2.3.2.1.  Standard Mandatory Services

   The following standard IPM mandatory  user facilities are required
   for reception of RFC 822 originated mail by an X.400 UA.

   Content Type Indication

   Delivery Time Stamp Indication

   IP Message Identification

   Message Identification

   Non-delivery Notification

   Original Encoded Information Types Indication

   Submission Time Stamp Indication

   Typed Body

2.3.2.2.  Standard Optional Services

   The following standard IPM optional user facilities are required for
   reception of RFC 822 originated mail by an X.400 UA.

   Authorising User's Indication

   Blind Copy Recipient Indication

   Cross Referencing Indication

   Originator Indication

   Primary and Copy Recipients Indication




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


   Replying IP Message Indication

   Subject Indication

2.3.2.3.  New Services

   A new service "RFC 822 Header Field" is defined using the extension
   facilities.  This allows for any RFC 822 header field to be
   represented.  It may be present in RFC 822 originated messages, which
   are received by an X.400 UA.

Chapter 3 Basic Mappings

3.1.  Notation

   The X.400 protocols are encoded in a structured manner according to
   ASN.1, whereas RFC 822 is text encoded.  To define a detailed
   mapping, it is necessary to refer to detailed protocol elements in
   each format.  A notation to achieve this is described in this
   section.

3.1.1.  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 "822." 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-MTS
        components).  In this case, the lexical analysis defined in
        Section 3 of RFC 822 shall 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.importance).

   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, except for the
        following cases, where LWSP may be inserted according to RFC
        822 rules.




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


   -         Around the ":" in all headers

   -         EBNF.labelled-integer

   -         EBNF.object-identifier

   -         EBNF.encoded-info

   RFC 822 folding rules are applied to all headers.

3.1.2.  ASN.1

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

        element         = service "." definition *( "." definition )
        service         = "IPMS" / "MTS" / "MTA"
        definition      = identifier / context
        identifier      = ALPHA *< ALPHA or DIGIT or "-" >
        context         = "[" 1*DIGIT "]"

   The EBNF.service keys are shorthand for the following service
   specifications:

      IPMS IPMSInformationObjects defined in Annex E of X.420 / ISO
           10021-7.

      MTS  MTSAbstractService defined in Section 9 of X.411 / ISO
           10021-4.

      MTA  MTAAbstractService defined in Section 13 of X.411 / ISO
           10021-4.

   The first EBNF.identifier identifies a type or value key in the
   context of the defined service specification.   Subsequent
   EBNF.identifiers identify a value label or type in the context of the
   first identifier (SET or SEQUENCE).  EBNF.context indicates a context
   tag, and is used where there is no label or type to uniquely identify
   a component.  The special EBNF.identifier keyword "value" is used to
   denote an element of a sequence.

   For example, IPMS.Heading.subject defines the subject element of the
   IPMS heading.  The same syntax is also used to refer to element
   values.  For example,

   MTS.EncodedInformationTypes.[0].g3Fax refers to a value of
   MTS.EncodedInformationTypes.[0] .





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


3.2.  ASCII and IA5

   A gateway will interpret all IA5 as ASCII.  Thus, mapping between
   these forms is conceptual.

3.3.  Standard Types

   There is a need to convert between ASCII text, and some of the types
   defined in ASN.1 [CCITT/ISO88d].  For each case, an EBNF syntax
   definition is given, for use in all of this specification, which
   leads to a mapping between ASN.1, and an EBNF construct.  All EBNF
   syntax definitions of ASN.1 types are in lower case, whereas ASN.1
   types 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-restricted-char      = 1DIGIT /  1ALPHA / " " / "'" / "+"
                              / "," / "-" / "." / "/" / ":" / "=" / "?"
           ps-delim         = "(" / ")"
           ps-char          = ps-delim / ps-restricted-char

   This can be used to represent real printable strings in EBNF.