rfc987.txt

RFC 相关的技术文档

         In some cases, the encoding defined above may be reversed, to
         give a "natural" encoding of genuine RFC 822 addresses.  This
         depends largely on the allocation of appropriate management
         domains.

         The general case is mapped by use of domain defined attributes.
         Three are defined, according to the full environment used to
         interpret the RFC 822 information.

            1.   Domain defined type "RFC-822".  This string is to be
                 interpreted in the context of RFC 822, and RFC 920
                 [Crocker82a,Postel84a].

            2.   Domain defined type "JNT-Mail".  This string is to be
                 interpreted in the context of the JNT Mail protocol,
                 and the NRS [Kille84a,Larmouth83a].

            3.   Domain defined type "UUCP".  This is interpreted
                 according to the constraints of the UUCP world
                 [Horton86a].

         These three are values currently known to be of use.  Further
         recognised values may be defined.  These will be maintained in
         a list at the SRI Network Information Center.

         Other O/R Name attributes will be used to identify a context in
         which the O/R Name will be interpreted.  This might be a
         Management Domain, or some part of a Management Domain which
         identifies a gateway MTA.  For example:

            1)

            C               = "GB"
            ADMD            = "BT"
            PRMD            = "AC"
            "JNT-Mail"      = "Jimmy(a)UK.CO.BT-RESEARCH-LABS"

            2)

            C               = "US"
            ADMD            = "Telemail"
            PRMD            = "San Fransisco"
            O               = "U Cal"
            OU              = "Berkeley"
            "RFC-822"       = "postel(a)usc-isib.arpa"


Kille                                                          [Page 29]



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


         Note in each case the PrintableString encoding of "@" as "(a)".
         In the first example, the "JNT-Mail" domain defined attribute
         is interpreted everywhere within the (Administrative or
         Private) Management Domain.  In the second example, further
         attributes are needed within the Management Domain to identify
         a gateway.  Thus, this scheme can be used with varying levels
         of Management Domain co-operation.

      4.2.3.  RFC 822 -> X.400

         There are two basic cases:

            1.   X.400 addresses encoded in RFC 822.  This will also
                 include RFC 822 addresses which are given reversible
                 encodings.

            2.   "Genuine" RFC 822 addresses.

         The mapping should proceed as follows, by first assuming case
         1).

         STAGE 1.

            1.   If the 822-address is not of the form:

               local-part "@" domain

               go to stage 2.

            2.   Attempt to parse domain as:

               *( domain-syntax "." ) known-domain

               Where known-domain is the longest possible match in a
               list of gatewayed domains.  If this fails, and the domain
               does not explicitly identify the local gateway, go to
               stage 2.  If it succeeds, allocate the attributes
               associated with EBNF.known-domain, and systematically
               allocate the attributes implied by each
               EBNF.domain-syntax component.

            3.   Map 822.local-part to ASCII, according to the
                 definition of Appendix A.  This step should be applied:

               A.  If the source network cannot support
                   822.quoted-string (as discussed in Appendix A).



Kille                                                          [Page 30]



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


               B.  If the address is an 822-P1 recipient.

                  This mapping is always applied in case B, as it
                  increases the functionality of the gateway, and does
                  not imply any loss of generality.  Mapping case B
                  allows sites which cannot generate 822.quoted-string
                  to address recipients the gateway, without the gateway
                  having to know this explicitly.  There is no loss of
                  functionality, as the quoting character of Appendix A
                  (#) is not in PrintableString.  This seems desirable.
                  It should not be applied in to other addresses, as a
                  third party RFC#822 address containing the sequence
                  EBNF.atom-encoded (as defined in Appendix A) would be
                  transformed asymmetrically.

            4.   Map the result of 3) to EBNF.ps-encoded according to
                 section 3.

            5.   Parse the result of 4) according to the EBNF
                 EBNF.std-orname.  If this parse fails, parse the result
                 of 4) according to the EBNF EBNF.encoded-pn.  If this
                 also fails, go to stage 2.  Otherwise, the result is a
                 set of type/value pairs.

            6.   Associate the EBNF.attribute-value syntax (determined
                 from the identified type) with each value, and check
                 that it conforms.  If not, go to stage 2.

            7.   Ensure that the set of attributes conforms both to the
                 X.411 P1.ORName specification and to the restrictions
                 on this set given in X.400.  If not go to stage 2.

            8.   Build the O/R Name from this information.

         STAGE 2.

         This will only be reached if the RFC 822 EBNF.822-address is
         not a valid X.400 encoding.  If the address is an 822-P1
         recipient address, it must be rejected, as there is a need to
         interpret such an address in X.400.  For the 822-P1 return
         address, and any addresses in the RFC 822 header, they should
         now be encoded as RFC 822 addresses in an X.400 O/R Name:

            1.   Convert the EBNF.822-address to PrintableString, as
                 specified in chapter 3.

            2.   The domain defined attribute ("RFC-822", "JNT-Mail" or


Kille                                                          [Page 31]



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


                 "UUCP") appropriate to the gateway should be selected,
                 and its value set.

            3.   Build the rest of the O/R Name in the local Management
                 Domain agreed manner, so that the O/R Name will receive
                 a correct global interpretation.

      4.2.4.  X.400 -> RFC 822

         There are two basic cases:

            1.   RFC 822 addresses encoded in X.400.

            2.   "Genuine" X.400 addresses.  This may include
                 symmetrically encoded RFC 822 addresses.

         When a P1 Recipient O/R Name is interpreted, gatewaying will be
         selected if there a single special domain defined attribute
         present ("RFC-822", "JNT-Mail" or "UUCP").  In this case, use
         mapping A.  For other O/R Names which

            1.   Contain the special attribute.

               AND

            2.   Identify the local gateway with the other attributes.

         Use mapping A.  In other cases, use mapping B.

         Mapping A

            1.   Map the domain defined attribute value to ASCII, as
                 defined in chapter 3.

            2.   Where appropriate (P1 recipients), interpret the string
                 according to the semantics implied by the domain
                 defined attribute.

         Mapping B.

         This will be used for X.400 addresses which do not use the
         explicit RFC 822 encoding.

            1.   Noting the hierarchy specified in 4.3.1, determine the
                 maximum set of attributes which have an associated
                 domain specification. If no match is found, allocate



Kille                                                          [Page 32]



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


                 the domain as the domain specification of the local
                 gateway, and go to step 4.

            2.   Following the 4.3.1 hierarchy, if each successive
                 component exists, and conforms to the syntax
                 EBNF.domain-syntax (as defined in 4.3.1), allocate the
                 next subdomain.

            3.   If the remaining components are personal-name
                 components, conforming to the restrictions of 4.2.2,
                 then EBNF.encoded-pn should be derived to form
                 822.local-part.  In other cases the remaining
                 components should simply be encoded as a 822.local-part
                 using the EBNF.std-orname syntax.  Where registered
                 domain defined types exist, the DD. syntax should not
                 be used.

            4.   If this step is reached for an 822-P1 recipient, then
                 the address is invalid.  For other addresses, if the
                 derived 822.local-part can only be encoded by use of
                 822.quoted-string, the gateway may optionally use the
                 ASCII to 822.local-part mapping defined in Appendix A,
                 dependent on the mail protocols of the networks being
                 relayed to.  Use of this encoding is discouraged.

   4.3.  Repeated Mappings

      The mappings defined are symmetrical across a single gateway,
      except in certain pathological cases (see chapter 3).  However, it
      is always possible to specify any valid address across a gateway.
      This symmetry is particularly useful in cases of (mail exploder
      type) distribution list expansion.  For example, an X.400 user
      sends to a list on an RFC 822 system which he belongs to.  The
      received message will have the originator and any 3rd party X.400
      O/R names in correct format (rather than doubly encoded).  In
      cases (X.400 or RFC 822) where there is common agreement on
      gateway identification, then this will apply to multiple gateways.

      However, the syntax may be used to source route.

      For example:  X.400 -> RFC 822  -> X.400

         C               = "UK"
         ADMD            = "BT"
         PRMD            = "AC"
         "JNT-Mail"      = "/PN=Duval/DD.Title=Manager/(a)FR.PTT.Inria"



Kille                                                          [Page 33]



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


         This will be sent to an arbitrary UK Academic Community gateway
         by X.400.  Then by JNT Mail to another gateway determined by
         the domain FR.PTT.Inria.  This will then derive the X.400 O/R
         Name:

            C               = "FR"
            ADMD            = "PTT"
            PRMD            = "Inria"
            PN.S            = "Duval"
            "Title"         = "Manager"

      Similarly:  RFC 822 -> X.400 -> RFC 822

         "/C=UK/ADMD=BT/PRMD=AC/RFC-822=jj(a)seismo.css.gov/"
                                                     @monet.berkeley.edu

         /C=UK/ADMD=BT/PRMD=AC/RFC-822=jj#l#a#r#seismo.css.gov/
                                                     @monet.berkeley.edu

         The second case uses the Appendix A encoding to avoid
         822.quoted-text. This will be sent to monet.berkeley.edu by
         RFC 822, then to the AC PRMD by X.400, and then to
         [e-mail] by RFC 822.

   4.4.  The full P1 / 822-P1 mapping

      There are two basic mappings at the P1 level:

         1.   822-P1 return address <-> P1.UMPDUEnvelope.originator

         2.   822-P1 recipient <-> P1.RecipientInfo

      822-P1 recipients and return addresses are encoded as
      EBNF.822-address.  As P1.UMPDUEnvelope.originator is encoded as
      P1.ORName, mapping 1) has already been specified.
      P1.RecipientInfo contains a P1.ORName and additional information.
      The handling of this additional information is now specified.

      4.4.1.  RFC 822 -> X.400

         The following default settings should be made for each
         component of P1.RecipientInfo.

            P1.ExtensionIdentifier

               This can be set systematically by the X.400 system.



Kille                                                          [Page 34]



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


            P1.RecipientInfo.perRecipientFlag

               Responsibility Flag should be set.  Report Request should
               be set according to content return policy, as discussed
               in section 5.3. User Report Request should be set to
               Basic.

            P1.ExplicitConversion

               This optional component should be omitted.

      4.4.2.  X.400 -> RFC 822

         The mapping only takes place in cases where
         P1.RecipientInfo.perRecipientFlag Responsibility Flag is set.
         The following treatment should be given to the other
         P1.RecipientInfo components.

            P1.ExtensionIdentifier

               Not used.

            P1.RecipientInfo.perRecipientFlag

               If ReportRequest is Confirmed or Audit-and-Confirmed then
               a delivery report indicating success should be sent by
               the gateway. This report should use each
               P1.ReportedRecipientInfo.SupplementaryInformation to
               indicate the identity of the gateway, and the nature of
               the report (i.e. only as far as the gateway).  Failures
               will be handled by returning RFC 822 messages, and so
               User Report Request set to No report is ignored.

            P1.ExplicitConversion

               If present, the O/R name should be rejected, unless the
               requested conversion can be achieved.  None of the
               currently recognised values of this parameter are
               appropriate to a gateway using this specification.










Kille                                                          [Page 35]



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


   4.5.  The full P2 / RFC 822 mapping

      All RFC 822 addresses are assumed