Movatterモバイル変換
[0]ホーム
[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]
EXPERIMENTAL
Network Working Group C. AllocchioRequest for Comments: 2162 I.N.F.N. - ItalyObsoletes:1405 January 1998Category: ExperimentalMaXIM-11 - Mapping between X.400 / Internet mailandMail-11 mailStatus of this Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved.Abstract This document describes a set of mappings which will enable inter working between systems operating the ISO/IEC 10021 - CCITT (now ITU) X.400 Recommendations on Message Handling Systems, and systems running the Mail-11 (also known as DECnet mail or VMSmail) protocol. The specifications are valid both within DECnet Phase IV and DECnet/OSI addressing and routing scheme. The complete scenario of X.400 / MIME / Mail-11 is also considered, in order to cover the possible complex cases arising in multiple gateway translations. This document covers mainly the X.400 O/R address to/from Mail-11 address mapping and theRFC822 to/from Mail-11 ones; other mappings are based on MIXER specifications. Bodypart mappings are not specified in this document: MIXER and MIME-MHS specifications can be applied to map bodyparts between X.400, MIME and Mail-11, too. In fact MIME encoding can be used without modifications within Mail-11 text bodyparts. This document obsoletesRFC 1405, which was a combined effort of TERENA Working Group on Messaging, and the IETF X.400 Ops Working Group. This update was prepared by IETF MIXER working group.Allocchio Experimental [Page 1]
RFC 2162 MaXIM-11 January 1998Chapter 1 - Introduction1.1. X.400 The standard referred shortly into this document as "X.400" relates to the ISO/IEC 10021 - CCITT 1984, 1988 and 1992 X.400 Series Recommendations covering the Message Oriented Text Interchange Service (MOTIS). This document covers the Inter Personal Messaging System (IPMS) only.1.2. Mail-11 Mail-11, also known as DECnet mail and often improperly referred as VMSmail, is the proprietary protocol implemented by Digital Equipment Corporation (DEC) to establish a real-time text messaging system among systems implementing the DECnet Phase IV and DECnet/OSI (CLNS) networking protocols.1.3.RFC822 / MIMERFC822 was defined as a standard for personal messaging systems within the DARPA Internet and is now diffused on top of many different message transfer protocols, like SMTP, UUCP, BITNET, JNT Grey Book, CSnet. MIME specifications allows transport of non-textual information intoRFC822 messages. Their mapping with X.400 is fully described in MIXER and MIME-MHS. In this document we will consider their relations with Mail-11, too.1.4. The user community The community using MIME or X.400 messaging system is currently growing in the whole world, but there is still a number of very large communities using Mail-11 based messaging systems willing to communicate easily with X.400 based Message Handling Systems and with MIME based systems. Among these large DECnet based networks we can include the High Energy Physics network (HEPnet) and the Space Physics Analysis Network (SPAN). Many other local communities actively use internally Mail-11 mailing protocols. As any other "non standard" mail protocol, using non standard mapping techniques between Mail-11 and standard mail systems can produce unpredictable results. For these reasons a set of rules covering conversion between Mail-11 and X.400 or MIME is described in this document.Allocchio Experimental [Page 2]
RFC 2162 MaXIM-11 January 1998 This document also covers the case of Mail-11 systems implementing the "foreign mail protocol" allowing Mail-11 to interface other mail systems, includingRFC822 based system.Chapter 2 - Message Elements2.1. Service Elements Mail-11 protocol offers a very restricted set of elements composing a Inter Personal Message (IPM), whereas X.400 andRFC822/MIME specifications support a complex and large amount of service elements. Considering the case where a message is relayed between two X.400 MHS or MIME Message Transport System (MTS) via a Mail-11 messaging system this could result in a nearly complete loss of information. To minimise the inconvenience, any of the X.400 or MIME service elements which do not map directly into Mail-11 equivalent ones accordingly to this specification, will be included into Mail-11 text body parts as an additionalRFC822-like header; this additional header will be inserted between the Mail-11 P2 headers (From:, To:, CC:, Subj:) and the other Mail-11 bodyparts. In particular, X.400 elements will also be at first converted into textual representation before insertion. An example, where a multimedia message has been encoded into mail-11 after having crossed also a MIME-MHS (MIXER conformant) gateway: From: smtp%"Admin@SURFnet.nl" "Erik" 18-OCT-1994 13:55:00.49 To: ALLOCCHIO CC: smtp%"netman@MailFLOW.dante.net" Subj: enjoy this nice picture! X400-Originator: root@sun3.SURFnet.nl X400-Recipients: Allocchio@elettra.ts.it, netman@MailFLOW.dante.net Sender: Erik Newmann <root@SURFnet.nl> Organisation: SURFnet bv Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaa0" Content-ID: <21223.78342785@SURFnet.nl> ------- =_aaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21223.78342785@SURFnet.nl> look... you never saw this one!! I just include the picture in the next bodypart and I hope you get it fine.Allocchio Experimental [Page 3]
RFC 2162 MaXIM-11 January 1998 regards, Erik (continues...) ------- =_aaaaaa0 (continued...) Content-Type: image/gif Content-ID: <21223.78342785@SURFnet.nl> Content-Description: a nice snapshot! Content-Transfer-Encoding: base64 RAV8372FAASD83D721NSHDHD3ASDFJKHWEHKJHCBASDFA829CA8SDB29B132RBAKDFA 9KSJ2KJAA0SDFNAL20DDKFALJ20AJDLFB239B9SC9B29BA9BDFADSDF03998ASDFASD ------- =_aaaaaa0 We need, in fact, to consider also the case when a message originates from a network implementingRFC822/MIME protocols and is relayed via Mail-11 to an X.400 MHS, or vice versa. Whenever any X.400 element not covered in this specification needs to be converted into textual representation (to be included into a Mail-11RFC822-like header or text bodypart) we will apply the rules specified in MIXER (X.400 toRFC822/MIME sections). Vice versa, MIXER specification (RFC822/MIME to X.400 sections) also gives the correct rules to convert from textual representations contained into Mail-11RFC822-like header or bodyparts into X.400 elements. On the other hand,RFC822/MIME headers not covered by this specification are included 'as they are' into Mail-11RFC822-like header and bodyparts. The way back from Mail-11 toRFC822/MIME structure becomes thus straightforward. The above methods assures maximum transparency and minimal or null loss of information also when Mail-11 is involved.Allocchio Experimental [Page 4]
RFC 2162 MaXIM-11 January 19982.2. Mail-11 service elements to X.400 service elements. All envelope (P1) and header (P2) Mail-11 service elements are supported in the conversion to X.400. Note that Mail-11 P1 is solely composed by P1-11.From and P1-11.To, and any other Mail-11 element belongs to Mail-11 P2: - P1-11.From maps to P1.Originator - P1-11.To maps to P1.Primary Recipient - P2-11.'From:' usually maps to P2.Originator (seesection 2.6) - P2-11.'To:' maps to P2.Primary Recipient - P2-11.'CC:' maps to P2.Copy Recipient - P2-11.Date maps to P2.Submission Time Stamp - P2-11.'Subj:' maps to P2.Subject Any eventualRFC822-like text header in Mail-11 body part will be interpreted as specified into MIXER.2.3. X.400 service elements to Mail-11 service elements The following X.400 service elements are supported directly into Mail-11 conversion: - P1.Originator maps to P1-11.'From:' - P1.Primary Recipients maps to P1-11.'To:' - P2.Originator usually maps to P2-11.'From:' (seesection 2.6) - P2.Primary Recipients maps to P2-11.'To:'Allocchio Experimental [Page 5]
RFC 2162 MaXIM-11 January 1998 - P2.Copy Recipients maps to P2-11.'CC:' - P2.Submission Time Stamp maps to P2-11.Date - P2.Subject maps to P2-11.'Subj:' The following X.400 service element is partially supported into Mail-11 conversion: - P2.Blind Copy Recipient to ensure the required privacy, when a message contains a BCC address, the following actions occurs: - a new message is created, containing the body parts; - a new envelope is added to the new message, containing the originator and the BCC recipient addresses only; - a note is added to the message informing the BCC recipient about the fact that the message was a BCC; - the new message is delivered separately; - a note is added to the message delivered to TO and CC recipients informing them about the fact that there were some BCC recipients, too. Any other X.400 service element support is done accordingly to MIXER including the mapped element into theRFC822-like header into Mail-11 body part.2.4. Mail-11 service elements toRFC822/MIME service elements. All envelope (P1) and header (P2) Mail-11 service elements are supported in the conversion toRFC822/MIME: - P1-11.From maps to 822-MTS.Originator - P1-11.To maps to 822-MTS.Primary Recipient - P2-11.'From:' usually maps to 822.'From:' (seesection 2.6) - P2-11.'To:' maps to 822.'To:' - P2-11.'CC:' maps to 822.'Cc:'Allocchio Experimental [Page 6]
RFC 2162 MaXIM-11 January 1998 - P2-11.Date maps to 822.'Date:' - P2-11.'Subj:' maps to 822.'Subject:' Any eventualRFC822-like text header in Mail-11 body part will be re-inserted intoRFC822/MIME message 'as it is'.2.5.RFC822/MIME service elements to Mail-11 service elements The followingRFC822 service elements are supported directly into Mail-11 conversion: - 822-MTS.Originator maps to P1-11.From - 822-MTS.Primary Recipients maps to P1-11.To - 822.'From:' usually maps to P2-11.'From:' (seesection 2.5) - 822.'To:' maps to P2-11.'To:' - 822.'Cc:' maps to P2-11.'CC:' - 822.'Date:' maps to P2-11.Date - 822.'Subject:' maps to P2-11.'Subj:'Allocchio Experimental [Page 7]
RFC 2162 MaXIM-11 January 1998 The followingRFC822 service element is partially supported into Mail-11 conversion: - 822.'Bcc:' to ensure the required privacy, when a message contains a BCC address, the following actions occurs: - a new message is created, containing the body parts; - a new envelope is added to the new message, containing the originator and the BCC recipient addresses only; - a note is added to the message informing the BCC recipient about the fact that the message was a BCC; - the new message is delivered separately; - a note is added to the message delivered to TO and CC recipients informing them about the fact that there were some BCC recipients, too. Any otherRFC822/MIME service element support is done simply including the element 'as it is' into theRFC822-like header and into a Mail-11 body part.2.6. Rules to define the Mail-11 P2-11.'From:' element Mail-11 User Agents (usually VMSmail) uses the P2-11.'From:' element as destination in case the REPLY command is issued, ignoring any other specification like 'Sender:' 'Reply-To:' 'Return-Path:' etc. Also a number of automatic responders uses this field only to address their messages. Is it thus essential to insert into this field the correct information, i.e. the correct address where, according to X.400 orRFC822 rules the REPLY command or any automatically generated message should go. The rules specified inRFC822, section 4.4.4 should be used as a selection criterion to define the content of this field. In particular, in case the P2-11.'From:' element is not generated from the P2.Originator (X.400) or from the 822.'From:' (RFC822), it is essential to preserve into a 'From:' record of theRFC822-like header the original information contained into the P2.Originator or 822.'From:' fields.Allocchio Experimental [Page 8]
RFC 2162 MaXIM-11 January 1998 Vice versa, when converting from Mail-11 into X.400 orRFC822/MIME the information contained into the 'From:' field of theRFC822-like header (if present) will supersede the one contained into the Mail-11 P2-11.'From:'. An example: From: smtp%"Admin@SURFnet.nl" "Erik" 18-OCT-1994 13:55:00.49 To: ALLOCCHIO CC: smtp%"netman@MailFLOW.dante.net" Subj: enjoy this nice picture! From: Erik Newmann <root@SURFnet.nl> Reply-To: Admin@SURFnet.nl Organisation: SURFnet bv Message-Id: <21235.25442281@SURFnet.nl> when converting back intoRFC822 the header will be: From: Erik Newmann <root@SURFnet.nl> Reply-To: Admin@SURFnet.nl To: Allocchio@elettra.ts.it Cc: netman@MailFLOW.dante.net Subject: enjoy this nice picture! Organisation: SURFnet bv Message-Id: <21235.25442281@SURFnet.nl> The described method, although violating canonical conversion principles, assures the maximum functionality to the users, and provides consistency in case of multiple conversions for a single message.Chapter 3 - Basic Mappings The basic mappings indicated in MIXER and its updates should be fully used. A special consideration must be used for encodingRFC822 addresses containing quotes '"' into Mail-11. In fact Mail-11 addresses cannot contain that special character, as it is reserved to delimit "quoted strings" themselves, as when using the Mail-11 foreign mail protocol. An example: "John Poe"@Mixergw.local.ca.us (RFC822) cannot be included in a Mail-11 foreign mail protocol address 'as is', due to the quotes in the LHS section. Quotes must thus be encoded. MIXER specifies exactly how to encode quotes and other characters when translatingRFC822 addresses into X.400. Mail-11 addresses are not limited to printablestring, as for X.400, but aAllocchio Experimental [Page 9]
RFC 2162 MaXIM-11 January 1998 subset of the MIXER encoding can be used for the quotes character, and, as a direct consequence, for open and closed round brackets '(' and ')': smtp%"(q)John Poe(q)@Mixergw.local.ca.us"Chapter 4 - Addressing - Mail-11 / X.4004.1. Mail-11 addressing Mail-11 addressing can vary from a very simple case up to complex ones, if there are other Mail-11 to "something-else" gateways involved. In any case a Mail-11 address is an ASCII string composed of different elements.4.2. X.400 addressing On the other hand, An X.400 O/R address is a collection of attributes, which can anyway be presented as an IA5 textual representation as defined inRFC1685 and CCITT F.401, Annex B.4.3. Mail-11 address components Let us start defining the different parts composing a Mail-11 address. Mail-11 addresses syntax is slightly different between Phase IV and DECnet/OSI cases: - Phase IV: we consider a Mail-11 address as composed by 3 parts: [route] [node::] local-part where 'route' and 'node' are optional and only 'local-part' is compulsory. - DECnet/OSI: we consider a Mail-11 address as composed by 3 parts: [net:] [node-clns::] local-part where 'net and 'node-clns' are optional and only 'local-part' is compulsory. Here comes a formal definition of these elements node = *(ALPHA/DIGIT) / *DIGIT / *DIGIT "." *DIGIT route = *(node "::") subdomain = *(ALPHA/DIGIT)Allocchio Experimental [Page 10]
RFC 2162 MaXIM-11 January 1998 node-clns = *("." subdomain) net = *(ALPHA/DIGIT) local-part = username / nickname / for-protocol username = *(ALPHA/DIGIT) nickname = <printablestring - <" " and HTAB>> for-protocol = (f-pref f-sep <">f-address<">) f-pref = *(ALPHA/DIGIT) f-sep = "%" / "::" f-address = printablestring /RFC822-address / X400-text-address X400-text-address = <textual representation of an X.400 O/R addr> Please note that in x400-text-address both the ";" notation and the "/" notation are equivalent and allowed (see examples in different sect.) Some examples (Phase IV): route node local-part ----------------------------------------------------------- USER47 MYNODE::BETTY BOSTON::CLUS02::GOOFY1::MARY34 IN%"M.P.Tracy@Dicdum.cc.edu" UCLA13::MVAX93::MRGATE::"MBOX1::MBX34::MYC3::BOB" MIAMI2::George.Rosenthal CCUBVX::VS3100::Jnet%"IAB3425@IBAX23L" MRGATE::"C=xx::A=bbb::P=ppp::S=Joe" MAINVX::IN%"path1!path2!user%dom" GWX400::gw%"C=xx;ADMD=aaa;PRMD=ppp;S=Lee;" GX409A::x400%"/C=xx/A=aaa/P=ppp/S=Lee" smtp%"postmast@nodeb.bitnet" MICKEY::PRFGAT::profs%"NANCY@IBMB" edu%"HU427BD%CSUNIB@abc.acme.edu"Allocchio Experimental [Page 11]
RFC 2162 MaXIM-11 January 1998 Some examples (DECnet/OSI): net node local-part ----------------------------------------------------------- USER47 .IT.MYDOM1.MYNODE::BETTY OMNI:.US.GOV.LB.GOOFY1::MARY34 IN%"M.P.Tracy@Dicdum.cc.edu" NET1:.SALES.ADM.MVAX93::MRGATE::"MBOX1::MBX34::MYC3::BOB" .FR.LYON.MIAMI2::George.Rosenthal .AU.ABXY2W.VS3100::Jnet%"IAB3425@IBAX23L" MRGATE::"C=xx::A=bbb::P=ppp::S=Joe" INT:.GB.3LABV56.MAINV::IN%"path1!path2!user%dom" GWX400::gw%"C=xx;ADMD=aaa;PRMD=ppp;S=Lee;" smtp%"postmast@nodeb.bitnet" OMNI:.DE.TEST.V1.GWY32::GX409A::x400%"/C=xx/A=aaa/P=ppp/S=Lee" Note that also in DECnet/OSI there can be Phase IV like node names, the so called "Phase IV compatibility node names", but no 'route' term is allowed in front of them. In case the address consists of a DECnet/OSI 'net' and/or 'node' specification, plus an old Phase IV node address (like the last one in above examples) we consider the old Phese IV node name (GX409A) as 'local-part'.Chapter 5 - Mapping - Mail-11 / X.4005.1. Mapping scheme DECnet phase IV address field is somehow a 'flat land' with some obliged routes to reach some hidden areas. Thus a truly hierarchical mapping scheme using mapping rules as suitable forRFC822 is not the appropriate solution. A fixed set of encoding rules using DDAs support is defined in order to define the mapping. DECnet/OSI address field is, on the other hand, hyerarchical, implementing a real domain style organization, resembling very closely theRFC822 domain addresses. However also in DECnet/OSI networks the old Phase IV flat addresing schema remains valid, expecially for the so called 'Phase IV short aliases'. For this reason, and to keep mapping as simple as possible, the same set of fixed rules usind DDAs encoding will be used both for Phase IV and DECnet/OSI addresses.Allocchio Experimental [Page 12]
RFC 2162 MaXIM-11 January 1998 Another important aspect of the problem is the coexistence in DECnet phase IV of many disjoint networks, using the same DECnet address space, i.e., common X.400 and/orRFC822 mailing system acting as glue to connect different isolated Mail-11 islands. In DECnet/OSI this aspect is more canonically approached, introducing the concept of 'net', a unique name identifying the single internally fully interconnected DECnet network sharing the same DECnet/OSI name space. To identify uniquely each DECnet Phase IV network we will thus extend the concept of DECnet/OSI 'net' also to this case. We define as 'net' in Phase IV a unique ASCII string identifying the DECnet network we are connected to. If the Phase IV network is already migrating and thus interconnected to DECnet/OSI areas, the 'net' identifier already used in the DECnet/OSI areas is automatically extended to the whole DECnet community. If the network still uses Phase IV protocols only, a 'net' identifier must be chosen. In this case the 'net' element will identify the DECnet community being served, but it could also differ from the actual official network name. It is reccommended that the same 'net' identifier will be adopted unmodified when the eventual migration to DECnet/OSI will take place within that DECnet community. Aliases are allowed for the 'net' identifier. Some well known identifiers and aliases: net = 'OMNI' the High Energy Physics & Space Physics DECnet network; aliases: net = 'HEPnet' alias for 'OMNI' net = 'SPAN' alias for 'OMNI' The need of labelling each DECnet network with its name comes also from the requirement to implement the 'intelligent' gateway, i.e., the gateway which is able to understand its ability to connect directly to the specified DECnet network, even if the O/R address specify a path to a different gateway. A more detailed discussion of the problem is in 5.3 and 5.5.Allocchio Experimental [Page 13]
RFC 2162 MaXIM-11 January 1998 A registry of 'net' attributes to insure uniqueness of names must be established: this registry is the same one created for migration to DECnet/OSI. A simple table coupling 'net' and the gateway address is also used, in a syntax similar to the 'gate1' and 'gate2' tables used in MIXER. An example: OMNI#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT# OMNI#O$ESRIN1.PRMD$esa.ADMD$Master400.C$it# HEPnet#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT# HEPnet#O$ESRIN1.PRMD$esa.ADMD$Master400.C$it# SPAN#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT# SPAN#O$ESRIN1.PRMD$esa.ADMD$Master400.C$it# Ambiguous left entries are allowed. Gateway implementations could simply choose among one of the specified gateways, or try them all in cyclic order to obtain better performances. Note that aliases are established using this gate table, too: simply add equivalent entries into the table, like the 'HEPnet' and 'SPAN' entries. Aliases, however, must be used only to enable users to use commonly used names, but any gateway implementing this specification must generate addresses with official 'net' names, only ('OMNI' for the above table). The Mail-11 gateways table, however, just constitutes the list of the the appropriate MIXER address translation)RFC822 world. Any other gateway implementing this specification (and the related ones) should use its local name as first choice for the Mail-11 'net' it can reach, and use the official Mail-11 gateway table to reach only the non connected ones. This list of Mail-11 gateway entries is supposed to contain the list of 'net' tags and their aliases; as this list is usually small, currently we do not take into account distribution mechanisms for this information different from a static table. In order to keep the mapping rules very simple, avoiding the need to analyse Mail-11 addresses to distinguish the 'route', 'node', and Attributes (DDAs) needed to cover the mapping problem.5.2. Mail-11 --> X.400 We define the following Domain Defined Attributes to map a Mail-11 address: DD.Dnet DD.Mail-11Allocchio Experimental [Page 14]
RFC 2162 MaXIM-11 January 1998 We thus define the Mail-11 Phase IV mapping rule: route::node::localpart maps into C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net; DD.Mail-11=route::node::localpart; Meanwhile we define the mapping rule for Mail-11 DECnet/OSI: net:node-clns::localpart maps into C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net; DD.Mail-11=node-clns::localpart; with: xx = country code of the gateway performing the conversion yyy = Admd of the gateway performing the conversion zzz = Prmd of the gateway performing the conversion ooo = Organisation of the gateway performing the conversion uuu = Org. Unit(s) of the gateway performing the conversion net = name of the DECnet network (e.g., OMNI, HEPnet, SPAN,...) ('zzz','ooo','uuu' being used or dropped appropriately in order to identify uniquely within the X.400 MHS the gateway performing the conversion). The following defaults also apply: if 'node' (or 'node-clns') is missing and we are mapping the Mail-11 originator (From) then 'node' (or 'node-clns') defaults to the DECnet node name of the gateway (gwnode); if 'node' (or 'node-clns') is missing and we are mapping the Mail-11 recipient (To, Cc) then 'node' (or 'node-clns') defaults to the DECnet node name of the 'From' address. if 'net' is missing, then it defaults to a value defined locally by the gateway: if the gateway is connected to one DECnet network only, then 'net' will be the name of this unique network; if the gateway is connected to more than one DECnet network, then the gateway will establish a 'first choice' DECnet network, and 'net' will default to this value.Allocchio Experimental [Page 15]
RFC 2162 MaXIM-11 January 1998 The 'node' syntax (DECnet/OSI or Phase IV) depends on the DECnet protocol implemented and on the value of a system parameter (usually the MAIL$SYSTEM_FLAGS one) on the gateway host. In case 'local-part' contains 'x400-text-address' see alsosection6.4.3; In case 'local-part' contains 'RFC822-address' see alsosection6.4.4.5.2.1. Examples Let us suppose that: - the DECnet network name (net) is 'OMNI'; - the DECnet node name of the gateway (gwnode) is '.IT.DM.X4TDEC' alias 'X4TDEC' in Phase IV; - the Country Code of the gateway is 'IT' and its ADMD is 'garr' (and these two fields are enough to identify uniquely the gateway within the X.400 MHS). USER47 C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=.IT.DM.X4TDEC::USER47; MYNODE::BETTY C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=MYNODE::BETTY; BOSTON::GOOFY1::MARY34 C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=BOSTON::GOOFY1::MARY34; .DE.UNI-BN.PHYS.NODE18::MARY34 C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=.DE.UNI-BN.PHYS.NODE18::MARY34; UCLA13::MVAX93::MRGATE::"MBOX1::MBX34:MYC3::BOB" C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=UCLA13::MVAX93::MRGATE::(q)MBOX1::MBX34::MYC3::BOB(q) ENET:.US.CENTRAL.MIAMI2::George.Rosenthal C=it; ADMD=garr; DD.Dnet=ENET; DD.Mail-11=.US.CENTRAL.MIAMI2::George.Rosenthal; MRGATE::"C=xx::A=bbb::P=ppp::S=Joe" C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=X4TDEC::MRGATE::(q)C=xx::A=bbb::P=ppp::S=Joe(q)Allocchio Experimental [Page 16]
RFC 2162 MaXIM-11 January 1998 MAINVX::In%"path1!path2!user%dom" C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=MAINVX::In(p)(q)path1(b)path2(b)user(p)dom(q)5.3. X.400 encoding of Mail-11 --> Mail-11 In order to assure path reversibility in case of multiple Mail- 11/X.400 gateway crossing we must distinguish two cases: - DD.Dnet=net is known to the gateway as one of the DECnet networks it is connected to. In this case the mapping is trivial: C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net; DD.Mail-11=route::node::localpart; (see sect. 5.2 for explication of 'xx','yyy','zzz','ooo','uuu','net') maps into route::node::localpart and for DECnet/OSI addresses C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net; DD.Mail-11=node-clns::localpart; maps into net:node-clns::localpart - DD.Dnet=net is NOT known to the gateway as one of the DECnet networks it is connected to. In this case the mapping rule described intosection 5.4 apply: C=xx; ADMD=yyy; PRMD=www; DD.Dnet=net; DD.Mail-11=route::node::localpart; maps into gwnode::gw%"C=xx;ADMD=yyy;PRMD=www;DD.Dnet=net; DD.Mail-11=route::node::localpart;"Allocchio Experimental [Page 17]
RFC 2162 MaXIM-11 January 1998 Again for DECnet/OSI addresses: C=xx; ADMD=yyy; PRMD=www; DD.Dnet=net; DD.Mail-11=node-clns::localpart; maps into gwnode::gw%"C=xx;ADMD=yyy;PRMD=www;DD.Dnet=net; DD.Mail-11=node-clns::localpart;"5.3.1. Examples Let us suppose that: - the DECnet network name (net) is 'OMNI'; - the DECnet node name of the gateway (gwnode) is '.IT.DM.X4TDEC'; alias 'X4TDEC' in Phase IV; - the Country Code of the gateway is 'IT' and its ADMD is 'garr'; (and these two fields are enough to identify uniquely the gateway within the X.400 MHS). C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=X4TDEC::MRGATE::(q)C=ab::A=dsa::P=qwty::OU=mie::S=Cly(q) MRGATE::"C=ab::A=dsa::P=qwty::OU=mie::S=Cly" C=it; ADMD=garr; DD.Dnet=EASYNET; DD.Mail-11=ROM01::CARLO; X4TDEC::gw%"C=it;ADMD=garr;DD.Dnet=EASYNET; DD.Mail-11=ROM01::CARLO;" (in the above example 'EASYNET' is supposed to be not connected to our gateway located on .IT.DM.X4TDEC DECnet node).5.4. X.400 --> Mail-11 The mapping of an X.400 O/R address into Mail-11 is done encoding the various attributes into the X400-text-address as defined in chapter 4 of MIXER, and including this as 'f-address'. A 'f-pref' and a the DECnet node name of the gateway.Allocchio Experimental [Page 18]
RFC 2162 MaXIM-11 January 1998 Thus x400-text-address will be encoded like gwnode::gw%"x400-text-address" having spaces dividing attributes as optional.5.4.1. Example Let us suppose that: - the DECnet node name of the gateway (gwnode) is '.IT.DM.X4TDEC' alias 'X4TDEC' in Phase IV, and 'net' is 'OMNI' Thus C=gb; ADMD=G400; PRMD=AC.UK; O=ucl; S=Clay; will be encoded like X4TDEC::gw%"/C=gb/A=G400/P=AC.UK/O=ucl/S=Clay" or its equivalent with the ";" notation and DECnet/OSI 'node' OMNI:.IT.DM.X4TDEC::gw%"C=gb;ADMD=G400;PRMD=AC.UK;O=ucl;S=Clay;"5.5. Mail-11 encoding of X.400 --> X.400 It can happen that Mail-11 is used to relay messages between X.400 systems; this will mean multiple X.400/Mail-11 gateway crossing and we will encounter Mail-11 addresses containing embedded X.400 informations. In order to assure path reversibility we must then distinguish two cases:Allocchio Experimental [Page 19]
RFC 2162 MaXIM-11 January 1998 - the embedded X.400 address belongs to a domain whose naming and routing rules are known to the global X.400 MHS. In this case the mapping is trivial: route::gwnode::gw%"x400-text-address" or (for DECnet/OSI) net:gwnode::gw%"x400-text-address" maps into x400-text-address 'route' and 'gwnode' are mapped into X.400 Trace service elements. - the encoded X.400 domain does not belong to the global X.400 name space. In this case the mapping rule described intosection 5.2 apply: route::gwnode::gw%"x400-text-address" maps into C=xx; ADMD=yyy; DD.Dnet=net; DD.Mail-11=route::gwnode::gw(p)(q)x400-text-address(q); and (for DECnet/OSI) net:gwnode::gw%"x400-text-address" maps into C=xx; ADMD=yyy; DD.Dnet=net; DD.Mail-11=gwnode::gw(p)(q)x400-text-address(q); The latter case is deprecated and must be regarded as a possible temporary solution only, while waiting to include into the global X.400 MHS also this domain.Allocchio Experimental [Page 20]
RFC 2162 MaXIM-11 January 19985.5.1. Examples Let us suppose that: - the DECnet network name (net) is 'OMNI'; - the DECnet node name of the gateway (gwnode) is '.IT.DM.X4TDEC' alias 'X4TDEC' in Phase IV; - the Country Code of the gateway is 'IT' and its ADMD is 'garr'; (and these two fields are enough to identify uniquely the gateway within the X.400 MHS). X4TDEC::gw%"C=fr;ADMD=atlas;PRMD=ifip;O=poly;S=Moreau;" C=fr; ADMD=atlas; PRMD=ifip; O=poly; S=Moreau; X4TDEC::gw%"C=zz;ADMD= ;PRMD=Botwa;O=Miner;S=Chiuaw;" C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=X4TDEC::gw(p)(q)C=zz;ADMD= ; PRMD=Botwa;O=Miner;S=Chiuaw;(q) (in the above example C=zz is unknown to the global X.400 MHS)Chapter 6 - Mapping - Mail-11 /RFC8226.1 Introduction The implementation of a Mail-11 -RFC822 gateway was faced by many software developers independently, and was included in many mail products which were running on both VMS and UNIX systems. As there was not a unique standard mapping way, the implementations resulted into a number of possible variant methods to map a Mail-11 address into anRFC822 one. Some of these products became then largely widespread, starting to create a number of de facto mapping methods. In this chapter some sort of standardisation of the mapping problem is considered, trying to be compatible with the existing installed software. We must also remind that, in some cases, only simple Mail- 11 addresses could be mapped intoRFC822, having complex ones producing all sort of quite strange results. In case DECnet/OSI Mail-11 addresses are involved we must also notice that only one mapping method can be used from/toRFC822 addresses.Allocchio Experimental [Page 21]
RFC 2162 MaXIM-11 January 1998 On the other hand, the mapping of anRFC822 address in Mail-11 was quite straightforward, resulting in a common definition which uses "Mail-11 foreign mail protocol" to design anRFC822 address: [[node::][node::]...]prot%"rfc-822-address" or [node::][node::]...]prot::"rfc-822-address" or again for DECnet/OSI addresses [net:][node-clns::]prot%"rfc-822-address" or [net:][node-clns::]prot::"rfc-822-addres"6.2 De facto implementations A considerable number of de-facto implementations of Mail-11/RFC822 gateways is existing. As said in the introduction, the mapping ofRFC822 addresses in Mail-11 is accomplished using the foreign mail protocol syntax and is thus unique. On the other hand, Mail-11 addresses are encoded inRFC822 syntax in various ways. Here are the most common ones: a) "node::user"@gateway-address b) user%node@gateway-address c) user@node.decnet.domains d) user%node.dnet@gateway-addressLet's have a quick look to these different choices. a - This form simply encloses as quoted Left Hand Side string the original Mail-11 address into theRFC822 address of the Mail-11/RFC822 gateway. This method is fully conformant withRFC822 syntax, and the Mail-11 address is left untouched; thus no encoding rules need to applied to it. This method applies also easily to DECnet/OSI Mail-11 addresses. b - As one will immediately notice, this form has nothing in it indicating the address is a Mail-11 one; this makes the encoding indistinguishable from a similar encoding of RSCS (BITnet) addresses used by some IBM VM Mailer systems. It should thus be deprecated.Allocchio Experimental [Page 22]
RFC 2162 MaXIM-11 January 1998 c - In this case a sort of 'reserved word' (DECnet) embedded into the address itself identifies the presence of a Mail-11 original address preceding it. The decoding is possible, dropping 'domains' and extracting 'user' and 'node' parts. However complex Mail-11 addresses cannot be mapped properly in this syntax, and there is no specific rule for adding the 'domains' part of the address. d - In this case again there is a 'reserved word' (dnet) which make possible the identification of the original Mail-11 address; 'gateway-address' points to the Mail-11/RFC822 gateway and 'node' and 'user' information can be easily drawn from the address. However complex Mail-11 addresses cannot be embedded easily into this syntax. Note the only methods a) can be successfully used for DECnet/OSI Mail-11 addresses, while the other cases are already too complex to encode in a unique way such addresses inRFC822.6.3 Recommended mappings From the examples seen in the previous paragraphs we can derive a canonical form for representing the mapping between Mail-11 andRFC822.6.3.1RFC822 mapped in Mail-11 The mapping of anRFC822 address in Mail-11 is straightforward, using the "Mail-11 foreign mail protocol" syntax. The two possible variants for Phase IV are: [[node::][node::]...]prot%"rfc-822-address" or [node::][node::]...]prot::"rfc-822-address" The equivalent two possible variants for DECnet/OSI are: [net:][node-clns::]prot%"rfc-822-address" or [net:][node-clns::]prot::"rfc-822-address"Allocchio Experimental [Page 23]
RFC 2162 MaXIM-11 January 19986.3.2 Mail-11 mapped inRFC822RFC822 foresee a canonical form for representing non-RFC822 addresses: put the foreign address in local part (Left Hand Side, LHS) is a form as similar as possible to its original syntax. Thus the suggested mapping both for Phase IV and DECnet/OSI is: "Mail-11-address"@gateway-address This format assures also the return path via the appropriate gateway.6.3.3 Mail-11 (foreign mail protocol) mapped inRFC822 A Mail-11 address containing a foreign mail protocol syntax can also contain the percent '%' character as a separator between the foreign protocol name and the actual address itself. In some cases the address part can also be an unquoted string. Some examples: deliver%swan myprot%root.owner listserv%my-private.list.A1 If these addresses are encoded into anRFC822 address using the "natural" method described in 6.3.2, they will result in something which can be easily mismatched with an address using the percent hack in LHS for source routing. "myprot%root.owner"@lohost.mydom.edu (Mail-11 address) "LISTSERV%IBMB.BITnet"@bitgate.anu.edu (% routing address) The percent hack is strongly deprecated, and thus should be avoided; the second address above shoud be expressed as: @bitgate.anu.edu:"LISTSERV@IBMB.BITnet" However, in order to assure maximum functionality and avoid problems, it is recommended to encode Mail-11 addresses containing the foreign protocol specification inRFC822 syntax using the DD.Mail-11 and DD.dnet qualifiers, i.e. "/DD.Mail-11=myprot%root.owner/DD.dnet=OMNI"@lohost.mydom.edu The DD.dnet defaults as indicated in the similar cases for the Mail- 11 / X.400 mappings. This encoding method can, of course, also be used to map any other Mail-11 address inRFC822, and is the only one which enable to specify the network name ('OMNI' in the above example) for DECnet Phase IV Mail-11 addresse. The method is fullyAllocchio Experimental [Page 24]
RFC 2162 MaXIM-11 January 1998 compatible with the results also produced by gateways following the MIXER specification for Mail-11 addresses encoded in X.400 and then translated intoRFC822.Chapter 7 - Complex mapping - X.400 / Mail-11 /RFC8227.1. The protocol triangle The bilateral mappings described in chapters 5 and 6 must be extended in order to cover also the case in which alsoRFC822 addressing is involved, and the following triangular situation occurs: X.400 / \ / \ / \ Mail-11----RFC822 The X.400 -RFC822 side is fully covered by MIXER, and the previous chapters in this document cover the Mail-11 - X.400 side and the Mail-11 -RFC822 one.7.2.RFC822 mapped in Mail-11 The 'RFC822-address' is usually included in 'local-part' as route::gwnode::gw%"rfc822-address" or the equivalent in DECnet/OSI: net:gwnode::gw%"rfc822-address" An example in Phase IV NVXA23::SMTPGW::in%"M.T.Rose@CS.UCLA.edu" and another one in DECnet/OSI OMNI:.FR.INET.LABOL.SMTPGW::in%"M.T.Rose@CS.UCLA.edu"7.3. Mail-11 mapped inRFC822 There are different styles in mapping a Mail-11 address inRFC822; let's have a short summary of what was traditionally done in some implementations.Allocchio Experimental [Page 25]
RFC 2162 MaXIM-11 January 19987.3.1 Mail-11 address encoded in "Left Hand Side" (LHS) ofRFC822 address, using "%" syntax or "::" syntax route::node::localpart (Phase IV) maps to localpart%node%route@gw-domains or "route::node::localpart"@gw-domains Again, let's consider the DECnet/OSI case: net:node-clns::localpart (DECnet/OSI) maps to "net:node-clns::localpart"@gw-domains (note that "%" encoding does not exist for this case) where 'gw-domains' identify uniquely the Mail-11 /RFC822 gateway.7.3.2 Mail-11 address maps partly to LHS and partly to 'domain' part ofRFC822 address node::localpart maps to localpart@node.gw-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 resultantRFC822 address contains no trace at all of the original Mail-11 address.Allocchio Experimental [Page 26]
RFC 2162 MaXIM-11 January 19987.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 anRFC822 address which can be mapped in Mail-11 using the 'f-address' field, as described insection 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 Jim.Clay@cs.UCL.AC.UK and finally becomes SMTPGW::In%"Jim.Clay@cs.UCL.AC.UK" and finally becomes SMTPGW::In%"Jim.Clay@cs.UCL.AC.UK" where 'SMTPGW' is the DECnet Phase IV node name of the machine running theRFC822 to Mail-11 gateway. Again, in case the machine running theRFC822 to Mail-11 gateway is a DECnet/OSI one (like OMNI:.US.VA.CENTRL) we would get OMNI:.US.VA.CENTRL::In%"Jim.Clay@cs.UCL.AC.UK"7.4.2. Mail-11 -->RFC822 --> X.400 Some of the possible mapping described insection 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 intoRFC822 as BETTY%MYNODE@RELAY.dnet.gw1.it 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 toRFC822 gateway.7.4.3. X.400 --> Mail-11 -->RFC822 The X.400 address is stored into Mail-11 'f-address' element as described in sections5.3 and5.4; then if the Mail-11 toRFC822 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 toRFC822 gateway recognise the x400-text-address, then the address becomes, accordingly to MIXER Jim.Clay@cs.UCL.AC.UK and the followingRFC822 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 19987.4.4.RFC822 --> Mail-11 --> X.400 TheRFC822 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: Jim.Clay@cs.UCL.AC.UK will be encoded like SMTPGW::In%"Jim.Clay@cs.UCL.AC.UK" If the Mail-11 to X.400 gateway recognise theRFC822-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 sections5.3 and5.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: Jim.Clay@cs.UCL.AC.UK 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 sections5.2 and5.5; then MIXER is used to convert the address inRFC822. 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 intoRFC822 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 1998Chapter 8 - Notifications and Probes8.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 inRFC822/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 1998Acknowledgements 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 formerRFC1405.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 andRFC 822/MIME",RFC 2156, January 1998. [6] Alvestrand H., Kille S., Miles R., Rose M., and Thompson S., (MIME-MHS) "Mapping between X.400 andRFC-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 1998Author's Address Claudio Allocchio Sincrotrone Trieste SS 14 Km 163.5 Basovizza I 34012 Trieste Italy Phone: +39 40 3758523 Fax: +39 40 3758565 EMail: Claudio.Allocchio@elettra.Trieste.it C=it; A=garr; P=Trieste; O=Elettra; S=Allocchio; G=Claudio;Allocchio Experimental [Page 33]
RFC 2162 MaXIM-11 January 1998Full 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]
[8]ページ先頭