rfc2162.txt

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

7.3.2 Mail-11 address maps partly to LHS and partly to 'domain' part of
      RFC822 address

        node::localpart

   maps to

        [e-mail]-domains

   note that this kind of mapping does not exists with DECnet/OSI Mail-
   11 addresses.

7.3.3 Mail-11 address is completely hidden by a mapping table

   In this case the resultant RFC822 address contains no trace at all of
   the original Mail-11 address.










Allocchio                     Experimental                     [Page 26]

RFC 2162                        MaXIM-11                    January 1998


7.4. Multiple conversions

   Let us now examine briefly the possible situations which involve
   multiple conversions, having one protocol as a relay between the
   other two. This summary suggest some possible enhanced solutions to
   avoid heavy and unduly mappings, but the 'step by step' approach,
   considering blindly one conversion as disjointed to the other, as
   described in the previous sections, can always be used.

7.4.1. X.400 --> RFC822 --> Mail-11

   We apply the MIXER rules to the first step, obtaining an RFC822
   address which can be mapped in Mail-11 using the 'f-address' field,
   as described in section 7.2.

   an example:

      C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;

   maps accordingly to MIXER to

      [e-mail]

   and finally becomes

      SMTPGW::In%"[e-mail]"

   and finally becomes

      SMTPGW::In%"[e-mail]"

   where 'SMTPGW' is the DECnet Phase IV node name of the machine
   running the RFC822 to Mail-11 gateway. Again, in case the machine
   running the RFC822 to Mail-11 gateway is a DECnet/OSI one (like
   OMNI:.US.VA.CENTRL) we would get

      OMNI:.US.VA.CENTRL::In%"[e-mail]"

7.4.2. Mail-11 --> RFC822 --> X.400

   Some of the possible mapping described in section 7.3 for Phase IV
   apply to the Mail-11 address, hiding completely its origin. The MIXER
   apply on the last step.








Allocchio                     Experimental                     [Page 27]

RFC 2162                        MaXIM-11                    January 1998


   an example:

      RELAY::MYNODE::BETTY

   could map into RFC822 as

      [e-mail]

   and accordingly to MIXER

      C=it; A=garr; P=dom1; O=gw1; OU=RELAY; S=BETTY(p)MYNODE;

   where 'dnet.gw1.it' is the domain of the machine running the Mail-11
   to RFC822 gateway.

7.4.3. X.400 --> Mail-11 --> RFC822

   The X.400 address is stored into Mail-11 'f-address' element as
   described in sections 5.3 and 5.4; then if the Mail-11 to RFC822
   gateway is able to understand the presence of a 'x400-text-address'
   nto the Mail-11 address, then it applies MIXER to it, and encodes
   header. Otherwise it applies the rules described in 7.3.

   an example:

     C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;

   will be encoded like

     X4TDEC::gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Jim/S=Clay"

   If the Mail-11 to RFC822 gateway recognise the x400-text-address,
   then the address becomes, accordingly to MIXER

     [e-mail]

   and the following RFC822 header line is added

     Received: from X4TDEC with DECnet (Mail-11) on xx-xxx-xxxx.

   Otherwise one of the dumb rules could produce

    gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Jim/S=Clay"@X4TDEC.doms

   The case with DECnet/OSI Mail-11 is conceptually identical.






Allocchio                     Experimental                     [Page 28]

RFC 2162                        MaXIM-11                    January 1998


7.4.4. RFC822 --> Mail-11 --> X.400

   The RFC822 address is encoded in Mail-11 f-address element as
   described in sect. 7.2; then if the Mail-11 to X.400 gateway is able
   to understand the presence of an 'RFC822-address' into the Mail-11
   address, then it applies MIXER to it, and encodes 'route' and applies
   the rules described in 5.2 and 5.5.

   an example:

      [e-mail]

   will be encoded like

      SMTPGW::In%"[e-mail]"

   If the Mail-11 to X.400 gateway recognise the RFC822-address, then
   the address becomes, accordingly to MIXER

      C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;

   and a 'trace' record is added into the X.400 P1 data, stating that a
   node named SMTPGW was crossed.

   Otherwise dumb rule produces

      C=it; ADMD=garr; DD.Dnet=HEP;
      DD.Mail-11=SMTPGW::In(p)(q)Jim.Clay(a)cs.UCL.AC.UK(q)

   Again, the case for DECnet/OSI Mail-11 addresses, is conceptually
   identical.

7.4.5. RFC822 --> X.400 --> Mail-11

   We apply MIXER to the first conversion, obtaining an X.400 address.
   Then the rules described in sections 5.3 and 5.4 are used to store
   the X.400 address as 'x400-text-address' into the Mail-11.














Allocchio                     Experimental                     [Page 29]

RFC 2162                        MaXIM-11                    January 1998


   an example:

      [e-mail]

   maps accordingly to MIXER to

      C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;

   and finally becomes

      SMTPGW::gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Jim/S=Clay"

   where 'SMTPGW' is the DECnet Phase IV node name of the machine
   running the X.400 to Mail-11 gateway. No differences also for
   DECnet/OSI Mail-11 addresses.

7.4.6. Mail-11 --> X.400 --> RFC822

   The Mail-11 address is encoded as specified in sections 5.2 and 5.5;
   then MIXER is used to convert the address in RFC822.

   an example:

      RELAY::MYNODE::BETTY

   maps into X.400 as

      C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=RELAY::MYNODE::BETTY;

   and accordingly to MIXER

      "/C=it/A=garr/DD.Dnet=OMNI/DD.Mail-11=RELAY::MYNODE::BETTY"@gw2.it

   where 'gw2.it' is the domain of the machine running the MIXER
   gateway.

7.4. Conclusions

   A standard way of mapping Mail-11 addresses into RFC822 and vice
   versa is feasible. A suggestion is thus made to unify all existing
   and future implementations. It should be noted, however, that it
   could be impossible (in case of DECnet Phase IV) to specify in these
   mappings the name of the decnet community owning the encoded address,
   as it can be always done for X.400; thus the implementation of the
   'intelligent' gateway in this case could result impossible.






Allocchio                     Experimental                     [Page 30]

RFC 2162                        MaXIM-11                    January 1998


Chapter 8 - Notifications and Probes

8.1. Overview

   Mail-11 is a real time protocol, i.e. connection is established
   directly to the destination node. This makes possible some level of
   services like verification of an address, and delivery confirmation.

   However, Mail-11 User Agents ususally do not support notification or
   probe services, whereas it is possible to deliver the result of a
   notification or a probe to Mail-11. In this section we will briefly
   describe the level of service which can be obtained on these services
   when Mail-11 is involved.

8.2. Delivery of Notifications via Mail-11

   As described in the previous chapters, it is possible to transport
   also in Mail-11 with minimal loss of information complex information.
   This also includes Notifications. In fact Notifications in
   RFC822/MIME are encoded as MIME multipart messages: there are thus no
   problems in transporting these messages in Mail-11 as any other MIME
   message. Also X.400 Notifications can be transported and delivered
   via Mail-11: MIXER describes in fact how to convert them into MIME
   multipart messages, taking the problem back to the previous
   situation.

   Even when Mail-11 is just an intermediate step for a Notification
   message, this consideration just enable support for the service.

8.3. Generation of Notifications and Probes from Mail-11

   Although Mail-11 does not support Notification or Probe, the service
   could also be supported at gateway level. In fact, due to real time
   nature of Mail-11 protocol, the gateway could be reasonably sure that
   delivery until the other end of the Mail-11 path was successful or
   unsuccessful (and try to verify the feasibility of a delivery in case
   a Probe as requested). However, Mail-11 could just be an intermediate
   relay service, vanishing the value of the information.

   Implementation of this kind of service at gateway level is thus
   questionable, and if done, should clearly state the situation where
   it was generated, and the "confidence level" it conveys.

Security Considerations

   Security issues are not discussed in this memo.





Allocchio                     Experimental                     [Page 31]

RFC 2162                        MaXIM-11                    January 1998


Acknowledgements

   I wish to thank all those people who read the first draft and
   contributed a lot with their useful suggestions to the revision of
   this document, in particular RARE WG1 and IETF X.400 ops group
   members and S. E. Kille.

   Thanks also to a number of implementors (among which Ned Freed,
   Julian Onions, The Hebrew University of Tel Aviv - Pine VMS support
   team), to the HEPnet Mail Technical Committee and to all my Mail-11
   "end users", in particular Enzo Valente, for their suggestions and
   wishes which helped me really a lot to prepare this revision of
   former RFC1405.

References

   [1]  CCITT, "CCITT Recommendations X.400-X.430", Message Handling
        Systems: Red Book, October 1984.

   [2]  CCITT, "CCITT Recommendations X.400-X.420", Message Handling
        Systems: Blue Book, November 1988.

   [3]  CCITT/ISO, "CCITT Recommendations X.400/ ISO IS 10021-1,"
        Message Handling: System and Service Overview , December 1992.

   [4]  Crocker D., "Standard of the Format of ARPA Internet Text
        Messages", STD 11, RFC 822, UDel, August 1982.

   [5]  Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
        Mapping between X.400 and RFC 822/MIME", RFC 2156, January
        1998.

   [6]  Alvestrand H., Kille S., Miles R., Rose M., and Thompson S.,
        (MIME-MHS) "Mapping between X.400 and RFC-822 Message Bodies,"
        RFC 1495, Aug 1993.

   [7]  Digital Equipment Corp., "VMS Mail Utility".

   [8]  Joiner Associates Inc., "Jnet User's Manual".

   [9]  PMDF User's Guide.

   [10] Alvestrand, H. "Writing X.400 O/R Names", UNINETT / RFC1685,
        August 1994.

   [11] CCITT, "F.401 CCITT Message Handling Services - Operations and
        Definitions of Service - Naming and Addressing for Public
        Message Handling Services, Annex B (08/92)", August 1992.



Allocchio                     Experimental                     [Page 32]

RFC 2162                        MaXIM-11                    January 1998


Author's Address

   Claudio Allocchio
   Sincrotrone Trieste
   SS 14 Km 163.5 Basovizza
   I 34012 Trieste
   Italy

   Phone:   [phone]
   Fax:     [phone]
   EMail:  [e-mail]
           C=it; A=garr; P=Trieste; O=Elettra; S=Allocchio; G=Claudio;







































Allocchio                     Experimental                     [Page 33]

RFC 2162                        MaXIM-11                    January 1998


Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Allocchio                     Experimental                     [Page 34]