rfc1148.txt

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

      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:).




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


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

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

      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,



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


            this service is supported, although in practice it may
            appear that it is not supported.

      Registered Mail
            N/A (PDAU).

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




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


      Stored Message Summary
            N/A (MS).

      Subject Indication
            Supported.

      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 may be 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 may be required
   for reception of RFC 822 originated mail by an X.400 UA.

      Authorising User's Indication

      Blind Copy Recipient Indication




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


      Cross Referencing Indication

      Originator Indication

      Primary and Copy Recipients Indication

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



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


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

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



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


   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.

3.3.4.  T.61String

   In cases where T.61 strings are only used for conveying human
   interpreted information, the aim of a mapping should be to render the
   characters appropriately in the remote character set, rather than to
   maximise reversibility.  For these cases, the mappings to IA5 defined
   in CCITT Recommendation X.408 (1988) should be used [CCITT/ISO88a].
   These will then be encoded in ASCII.

   There is also a need to represent Teletex Strings in ASCII, for some
   aspects of O/R Address.  For these, the following encoding is used:

      teletex-string   = *( ps-char / t61-encoded )
      t61-encoded      = "{" 1* t61-encoded-char "}"
      t61-encoded-char = 3DIGIT

   Common characters are mapped simply.  Other octets are mapped using a



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