idnits 2.17.1 draft-ietf-mixer-mail11-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 506 has weird spacing: '... node loc...' == Line 527 has weird spacing: '... net node ...' == Line 634 has weird spacing: '...but any gatew...' == Line 923 has weird spacing: '...er case is de...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1997) is 9751 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 1457, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1460, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1463, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1466, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1469, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1473, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1477, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1479, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1481, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1486, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 822 (ref. '4') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1327 (ref. '5') (Obsoleted by RFC 2156) ** Obsolete normative reference: RFC 1495 (ref. '6') (Obsoleted by RFC 2156) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 13 errors (**), 0 flaws (~~), 17 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Allocchio 3 Internet-Draft v1.0 I.N.F.N. - Italy 4 Obsoletes: RFC 1405 January 1997 5 File:draft-ietf-mixer-mail11-00.txt expires: August 1997 7 MaXIM-11 - Mapping between X.400 / Internet mail 8 and 9 Mail-11 mail 11 Status of this Memo 13 This document is an Internet Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its 15 Areas, and its Working Groups. Note that other groups may also 16 distribute working documents as Internet Drafts. 18 Internet Drafts are valid for a maximum of six months and may be 19 updated, replaced, or obsoleted by other documents at any time. 20 It is inappropriate to use Internet Drafts as reference material 21 or to cite them other than as a "work in progress". 23 To learn the current status of any Internet-Draft, please check 24 the ``1id-abstracts.txt'' listing contained in the Internet- 25 Drafts Shadow Directories on ftp.is.co.za (Africa), 26 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 27 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 29 Distribution of this memo is unlimited. 31 Abstract 33 This document describes a set of mappings which will enable inter 34 working between systems operating the ISO/IEC 10021 - CCITT (now ITU) 35 X.400 Recommendations on Message Handling Systems, and systems 36 running the Mail-11 (also known as DECnet mail or VMSmail) protocol. 37 The specifications are valid both within DECnet Phase IV and 38 DECnet/OSI addressing and routing scheme. 40 The complete scenario of X.400 / MIME / Mail-11 is also considered, 41 in order to cover the possible complex cases arising in multiple 42 gateway translations. 44 This document covers mainly the X.400 O/R address to/from Mail-11 45 address mapping and the RFC822 to/from Mail-11 ones; other mappings 46 are based on MIXER specifications. Bodypart mappings are not 47 specified in this document: MIXER and MIME-MHS specifications can be 48 applied to map bodyparts between X.400, MIME and Mail-11, too. In 49 fact MIME encoding can be used without modifications within Mail-11 50 text bodyparts. 52 This document obsoletes RFC 1405, which was a combined effort of 54 I-DRAFT Mail-11 Mapping January 1997 56 TERENA Working Group on Messaging, and the IETF X.400 Ops Working 57 Group. This update was prepared by IETF MIXER working group. 59 Chapter 1 - Introduction 61 1.1. X.400 63 The standard referred shortly into this document as "X.400" relates 64 to the ISO/IEC 10021 - CCITT 1984, 1988 and 1992 X.400 Series 65 Recommendations covering the Message Oriented Text Interchange 66 Service (MOTIS). This document covers the Inter Personal Messaging 67 System (IPMS) only. 69 1.2. Mail-11 71 Mail-11, also known as DECnet mail and often improperly referred as 72 VMSmail, is the proprietary protocol implemented by Digital Equipment 73 Corporation (DEC) to establish a real-time text messaging system 74 among systems implementing the DECnet Phase IV and DECnet/OSI (CLNS) 75 networking protocols. 77 1.3. RFC822 / MIME 79 RFC822 was defined as a standard for personal messaging systems 80 within the DARPA Internet and is now diffused on top of many 81 different message transfer protocols, like SMTP, UUCP, BITNET, JNT 82 Grey Book, CSnet. MIME specifications allows transport of non-textual 83 information into RFC822 messages. Their mapping with X.400 is fully 84 described in MIXER and MIME-MHS. In this document we will consider 85 their relations with Mail-11, too. 87 1.4. The user community 89 The community using MIME or X.400 messaging system is currently 90 growing in the whole world, but there is still a number of very large 91 communities using Mail-11 based messaging systems willing to 92 communicate easily with X.400 based Message Handling Systems and with 93 MIME based systems. Among these large DECnet based networks we can 94 include the High Energy Physics network (HEPnet) and the Space 95 Physics Analysis Network (SPAN). 97 Many other local communities actively use internally Mail-11 mailing 98 protocols. As any other "non standard" mail protocol, using non 99 standard mapping techniques between Mail-11 and standard mail systems 100 can produce unpredictable results. 102 For these reasons a set of rules covering conversion between Mail-11 103 and X.400 or MIME is described in this document. 105 I-DRAFT Mail-11 Mapping January 1997 107 This document also covers the case of Mail-11 systems implementing 108 the "foreign mail protocol" allowing Mail-11 to interface other mail 109 systems, including RFC822 based system. 111 Chapter 2 - Message Elements 113 2.1. Service Elements 115 Mail-11 protocol offers a very restricted set of elements composing a 116 Inter Personal Message (IPM), whereas X.400 and RFC822/MIME specifi- 117 cations support a complex and large amount of service elements. 118 Considering the case where a message is relayed between two X.400 MHS 119 or MIME Message Transport System (MTS) via a Mail-11 messaging system 120 this could result in a nearly complete loss of information. 122 To minimise the inconvenience, any of the X.400 or MIME service 123 elements which do not map directly into Mail-11 equivalent ones 124 accordingly to this specification, will be included into Mail-11 text 125 body parts as an additional RFC822-like header; this additional 126 header will be inserted between the Mail-11 P2 headers (From:, To:, 127 CC:, Subj:) and the other Mail-11 bodyparts. In particular, X.400 128 elements will also be at first converted into textual representation 129 before insertion. 131 An example, where a multimedia message has been encoded into mail-11 132 after having crossed also a MIME-MHS (MIXER conformant) gateway: 134 From: smtp%"Admin@SURFnet.nl" "Erik" 18-OCT-1994 13:55:00.49 135 To: ALLOCCHIO 136 CC: smtp%"netman@MailFLOW.dante.net" 137 Subj: enjoy this nice picture! 139 X400-Originator: root@sun3.SURFnet.nl 140 X400-Recipients: Allocchio@elettra.ts.it, netman@MailFLOW.dante.net 141 Sender: Erik Newmann 142 Organisation: SURFnet bv 143 Mime-Version: 1.0 144 Content-Type: multipart/mixed; boundary="----- =_aaaaaa0" 145 Content-ID: <21223.78342785@SURFnet.nl> 147 ------- =_aaaaaa0 148 Content-Type: text/plain; charset="us-ascii" 149 Content-ID: <21223.78342785@SURFnet.nl> 151 look... you never saw this one!! 152 I just include the picture in the next bodypart 153 and I hope you get it fine. 155 regards, 157 Erik (continues...) 159 I-DRAFT Mail-11 Mapping January 1997 161 ------- =_aaaaaa0 (continued...) 162 Content-Type: image/gif 163 Content-ID: <21223.78342785@SURFnet.nl> 164 Content-Description: a nice snapshot! 165 Content-Transfer-Encoding: base64 167 RAV8372FAASD83D721NSHDHD3ASDFJKHWEHKJHCBASDFA829CA8SDB29B132RBAKDFA 168 9KSJ2KJAA0SDFNAL20DDKFALJ20AJDLFB239B9SC9B29BA9BDFADSDF03998ASDFASD 170 ------- =_aaaaaa0 172 We need, in fact, to consider also the case when a message originates 173 from a network implementing RFC822/MIME protocols and is relayed via 174 Mail-11 to an X.400 MHS, or vice versa. 176 Whenever any X.400 element not covered in this specification needs to 177 be converted into textual representation (to be included into a 178 Mail-11 RFC822-like header or text bodypart) we will apply the rules 179 specified in MIXER (X.400 to RFC822/MIME sections). 181 Vice versa, MIXER specification (RFC822/MIME to X.400 sections) also 182 gives the correct rules to convert from textual representations 183 contained into Mail-11 RFC822-like header or bodyparts into X.400 184 elements. 186 On the other hand, RFC822/MIME headers not covered by this specifica- 187 tion are included 'as they are' into Mail-11 RFC822-like header and 188 bodyparts. The way back from Mail-11 to RFC822/MIME structure becomes 189 thus straightforward. 191 The above methods assures maximum transparency and minimal or null 192 loss of information also when Mail-11 is involved. 194 2.2. Mail-11 service elements to X.400 service elements. 196 All envelope (P1) and header (P2) Mail-11 service elements are 197 supported in the conversion to X.400. Note that Mail-11 P1 is solely 198 composed by P1-11.From and P1-11.To, and any other Mail-11 element 199 belongs to Mail-11 P2: 201 - P1-11.From 202 maps to P1.Originator 204 - P1-11.To 205 maps to P1.Primary Recipient 207 - P2-11.'From:' 208 usually maps to P2.Originator (see section 2.6) 210 - P2-11.'To:' 211 maps to P2.Primary Recipient 213 I-DRAFT Mail-11 Mapping January 1997 215 - P2-11.'CC:' 216 maps to P2.Copy Recipient 218 - P2-11.Date 219 maps to P2.Submission Time Stamp 221 - P2-11.'Subj:' 222 maps to P2.Subject 224 Any eventual RFC822-like text header in Mail-11 body part will be 225 interpreted as specified into MIXER. 227 2.3. X.400 service elements to Mail-11 service elements 229 The following X.400 service elements are supported directly into 230 Mail-11 conversion: 232 - P1.Originator 233 maps to P1-11.'From:' 235 - P1.Primary Recipients 236 maps to P1-11.'To:' 238 - P2.Originator 239 usually maps to P2-11.'From:' (see section 2.6) 241 - P2.Primary Recipients 242 maps to P2-11.'To:' 244 - P2.Copy Recipients 245 maps to P2-11.'CC:' 247 - P2.Submission Time Stamp 248 maps to P2-11.Date 250 - P2.Subject 251 maps to P2-11.'Subj:' 253 The following X.400 service element is partially supported into 254 Mail-11 conversion: 256 - P2.Blind Copy Recipient 257 to ensure the required privacy, when a message contains 258 a BCC address, the following actions occurs: 259 - a new message is created, containing the body parts; 260 - a new envelope is added to the new message, containing 261 the originator and the BCC recipient addresses only; 262 - a note is added to the message informing the BCC 263 recipient about the fact that the message was a BCC; 264 - the new message is delivered separately; 266 I-DRAFT Mail-11 Mapping January 1997 268 - a note is added to the message delivered to TO and CC 269 recipients informing them about the fact that there 270 were some BCC recipients, too. 272 Any other X.400 service element support is done accordingly to 273 MIXER including the mapped element into the RFC822-like header into 274 Mail-11 body part. 276 2.4. Mail-11 service elements to RFC822/MIME service elements. 278 All envelope (P1) and header (P2) Mail-11 service elements are 279 supported in the conversion to RFC822/MIME: 281 - P1-11.From 282 maps to 822-MTS.Originator 284 - P1-11.To 285 maps to 822-MTS.Primary Recipient 287 - P2-11.'From:' 288 usually maps to 822.'From:' (see section 2.6) 290 - P2-11.'To:' 291 maps to 822.'To:' 293 - P2-11.'CC:' 294 maps to 822.'Cc:' 296 - P2-11.Date 297 maps to 822.'Date:' 299 - P2-11.'Subj:' 300 maps to 822.'Subject:' 302 Any eventual RFC822-like text header in Mail-11 body part will be 303 re-inserted into RFC822/MIME message 'as it is'. 305 2.5. RFC822/MIME service elements to Mail-11 service elements 307 The following RFC822 service elements are supported directly into 308 Mail-11 conversion: 310 - 822-MTS.Originator 311 maps to P1-11.From 313 - 822-MTS.Primary Recipients 314 maps to P1-11.To 316 - 822.'From:' 317 usually maps to P2-11.'From:' (see section 2.5) 319 I-DRAFT Mail-11 Mapping January 1997 321 - 822.'To:' 322 maps to P2-11.'To:' 324 - 822.'Cc:' 325 maps to P2-11.'CC:' 327 - 822.'Date:' 328 maps to P2-11.Date 330 - 822.'Subject:' 331 maps to P2-11.'Subj:' 333 The following RFC822 service element is partially supported into 334 Mail-11 conversion: 336 - 822.'Bcc:' 337 to ensure the required privacy, when a message contains 338 a BCC address, the following actions occurs: 339 - a new message is created, containing the body parts; 340 - a new envelope is added to the new message, containing 341 the originator and the BCC recipient addresses only; 342 - a note is added to the message informing the BCC 343 recipient about the fact that the message was a BCC; 344 - the new message is delivered separately; 345 - a note is added to the message delivered to TO and CC 346 recipients informing them about the fact that there 347 were some BCC recipients, too. 349 Any other RFC822/MIME service element support is done simply 350 including the element 'as it is' into the RFC822-like header and into 351 a Mail-11 body part. 353 2.6. Rules to define the Mail-11 P2-11.'From:' element 355 Mail-11 User Agents (usually VMSmail) uses the P2-11.'From:' element 356 as destination in case the REPLY command is issued, ignoring any 357 other specification like 'Sender:' 'Reply-To:' 'Return-Path:' etc. 358 Also a number of automatic responders uses this field only to address 359 their messages. 361 Is it thus essential to insert into this field the correct 362 information, i.e. the correct address where, according to X.400 or 363 RFC822 rules the REPLY command or any automatically generated message 364 should go. 366 The rules specified in RFC822, section 4.4.4 should be used as a 367 selection criterion to define the content of this field. 369 In particular, in case the P2-11.'From:' element is not 370 generated from the P2.Originator (X.400) or from the 822.'From:' 371 (RFC822), it is essential to preserve into a 'From:' record of the 373 I-DRAFT Mail-11 Mapping January 1997 375 RFC822-like header the original information contained into the 376 P2.Originator or 822.'From:' fields. 378 Vice versa, when converting from Mail-11 into X.400 or RFC822/MIME 379 the information contained into the 'From:' field of the RFC822-like 380 header (if present) will supersede the one contained into the Mail-11 381 P2-11.'From:'. An example: 383 From: smtp%"Admin@SURFnet.nl" "Erik" 18-OCT-1994 13:55:00.49 384 To: ALLOCCHIO 385 CC: smtp%"netman@MailFLOW.dante.net" 386 Subj: enjoy this nice picture! 388 From: Erik Newmann 389 Reply-To: Admin@SURFnet.nl 390 Organisation: SURFnet bv 391 Message-Id: <21235.25442281@SURFnet.nl> 393 when converting back into RFC822 the header will be: 395 From: Erik Newmann 396 Reply-To: Admin@SURFnet.nl 397 To: Allocchio@elettra.ts.it 398 Cc: netman@MailFLOW.dante.net 399 Subject: enjoy this nice picture! 400 Organisation: SURFnet bv 401 Message-Id: <21235.25442281@SURFnet.nl> 403 The described method, although violating canonical conversion 404 principles, assures the maximum functionality to the users, and 405 provides consistency in case of multiple conversions for a single 406 message. 408 Chapter 3 - Basic Mappings 410 The basic mappings indicated in MIXER and its updates should be 411 fully used. 413 A special consideration must be used for encoding RFC822 addresses 414 containing quotes '"' into Mail-11. In fact Mail-11 addresses cannot 415 contain that special character, as it is reserved to delimit "quoted 416 strings" themselves, as when using the Mail-11 foreign mail protocol. 417 An example: 419 "John Poe"@Mixergw.local.ca.us (RFC822) 421 cannot be included in a Mail-11 foreign mail protocol address 'as 422 is', due to the quotes in the LHS section. Quotes must thus be 423 encoded. MIXER specifies exactly how to encode quotes and other 424 characters when translating RFC822 addresses into X.400. Mail-11 425 addresses are not limited to printablestring, as for X.400, but a 427 I-DRAFT Mail-11 Mapping January 1997 429 subset of the MIXER encoding can be used for the quotes character, 430 and, as a direct consequence, for open and closed round brackets '(' 431 and ')': 433 smtp%"(q)John Poe(q)@Mixergw.local.ca.us" 435 Chapter 4 - Addressing - Mail-11 / X.400 437 4.1. Mail-11 addressing 439 Mail-11 addressing can vary from a very simple case up to complex 440 ones, if there are other Mail-11 to "something-else" gateways 441 involved. In any case a Mail-11 address is an ASCII string composed 442 of different elements. 444 4.2. X.400 addressing 446 On the other hand, An X.400 O/R address is a collection of 447 attributes, which can anyway be presented as an IA5 textual 448 representation as defined in RFC1685 and CCITT F.401, Annex B. 450 4.3. Mail-11 address components 452 Let us start defining the different parts composing a Mail-11 453 address. Mail-11 addresses syntax is slightly different between Phase 454 IV and DECnet/OSI cases: 456 - Phase IV: we consider a Mail-11 address as composed by 3 parts: 458 [route] [node::] local-part 460 where 'route' and 'node' are optional and only 'local-part' is 461 compulsory. 463 - DECnet/OSI: we consider a Mail-11 address as composed by 3 parts: 465 [net:] [node-clns::] local-part 467 where 'net and 'node-clns' are optional and only 'local-part' is 468 compulsory. 470 Here comes a formal definition of these elements 472 node = *(ALPHA/DIGIT) / *DIGIT / *DIGIT "." *DIGIT 474 route = *(node "::") 476 subdomain = *(ALPHA/DIGIT) 478 node-clns = *("." subdomain) 480 I-DRAFT Mail-11 Mapping January 1997 482 net = *(ALPHA/DIGIT) 484 local-part = username / nickname / for-protocol 486 username = *(ALPHA/DIGIT) 488 nickname = > 490 for-protocol = (f-pref f-sep <">f-address<">) 492 f-pref = *(ALPHA/DIGIT) 494 f-sep = "%" / "::" 496 f-address = printablestring / RFC822-address / X400-text-address 498 X400-text-address = 500 Please note that in x400-text-address both the ";" notation and the 501 "/" notation are equivalent and allowed (see examples in different 502 sect.) 504 Some examples (Phase IV): 506 route node local-part 507 ----------------------------------------------------------- 508 USER47 509 MYNODE::BETTY 510 BOSTON::CLUS02::GOOFY1::MARY34 511 IN%"M.P.Tracy@Dicdum.cc.edu" 512 UCLA13::MVAX93::MRGATE::"MBOX1::MBX34::MYC3::BOB" 513 MIAMI2::George.Rosenthal 514 CCUBVX::VS3100::Jnet%"IAB3425@IBAX23L" 515 MRGATE::"C=xx::A=bbb::P=ppp::S=Joe" 516 MAINVX::IN%"path1!path2!user%dom" 517 GWX400::gw%"C=xx;ADMD=aaa;PRMD=ppp;S=Lee;" 518 GX409A::x400%"/C=xx/A=aaa/P=ppp/S=Lee" 519 smtp%"postmast@nodeb.bitnet" 520 MICKEY::PRFGAT::profs%"NANCY@IBMB" 521 edu%"HU427BD%CSUNIB@abc.acme.edu" 523 I-DRAFT Mail-11 Mapping January 1997 525 Some examples (DECnet/OSI): 527 net node local-part 528 ----------------------------------------------------------- 529 USER47 530 .IT.MYDOM1.MYNODE::BETTY 531 OMNI:.US.GOV.LB.GOOFY1::MARY34 532 IN%"M.P.Tracy@Dicdum.cc.edu" 533 NET1:.SALES.ADM.MVAX93::MRGATE::"MBOX1::MBX34::MYC3::BOB" 534 .FR.LYON.MIAMI2::George.Rosenthal 535 .AU.ABXY2W.VS3100::Jnet%"IAB3425@IBAX23L" 536 MRGATE::"C=xx::A=bbb::P=ppp::S=Joe" 537 INT:.GB.3LABV56.MAINV::IN%"path1!path2!user%dom" 538 GWX400::gw%"C=xx;ADMD=aaa;PRMD=ppp;S=Lee;" 539 smtp%"postmast@nodeb.bitnet" 540 OMNI:.DE.TEST.V1.GWY32::GX409A::x400%"/C=xx/A=aaa/P=ppp/S=Lee" 542 Note that also in DECnet/OSI there can be Phase IV like node names, 543 the so called "Phase IV compatibility node names", but no 'route' 544 term is allowed in front of them. In case the address consists of 545 a DECnet/OSI 'net' and/or 'node' specification, plus an old Phase IV 546 node address (like the last one in above examples) we consider the 547 old Phese IV node name (GX409A) as 'local-part'. 549 Chapter 5 - Mapping - Mail-11 / X.400 551 5.1. Mapping scheme 553 DECnet phase IV address field is somehow a 'flat land' with some 554 obliged routes to reach some hidden areas. Thus a truly hierarchical 555 mapping scheme using mapping rules as suitable for RFC822 is not the 556 appropriate solution. A fixed set of encoding rules using DDAs 557 support is defined in order to define the mapping. 559 DECnet/OSI address field is, on the other hand, hyerarchical, 560 implementing a real domain style organization, resembling very 561 closely the RFC822 domain addresses. However also in DECnet/OSI 562 networks the old Phase IV flat addresing schema remains valid, 563 expecially for the so called 'Phase IV short aliases'. For this 564 reason, and to keep mapping as simple as possible, the same set of 565 fixed rules usind DDAs encoding will be used both for Phase IV and 566 DECnet/OSI addresses. 568 Another important aspect of the problem is the coexistence in DECnet 569 phase IV of many disjoint networks, using the same DECnet address 570 space, i.e., common X.400 and/or RFC822 mailing system acting as glue 571 to connect different isolated Mail-11 islands. In DECnet/OSI this 572 aspect is more canonically approached, introducing the concept of 573 'net', a unique name identifying the single internally fully 574 interconnected DECnet network sharing the same DECnet/OSI name space. 576 I-DRAFT Mail-11 Mapping January 1997 578 To identify uniquely each DECnet Phase IV network we will thus extend 579 the concept of DECnet/OSI 'net' also to this case. We define as 'net' 580 in Phase IV a unique ASCII string identifying the DECnet network we 581 are connected to. If the Phase IV network is already migrating and 582 thus interconnected to DECnet/OSI areas, the 'net' identifier already 583 used in the DECnet/OSI areas is automatically extended to the whole 584 DECnet community. 586 If the network still uses Phase IV protocols only, a 'net' identifier 587 must be chosen. In this case the 'net' element will identify the 588 DECnet community being served, but it could also differ from the 589 actual official network name. It is reccommended that the same 'net' 590 identifier will be adopted unmodified when the eventual migration to 591 DECnet/OSI will take place within that DECnet community. 593 Aliases are allowed for the 'net' identifier. Some well known 594 identifiers and aliases: 596 net = 'OMNI' the High Energy Physics & Space Physics 597 DECnet network; 599 aliases: 601 net = 'HEPnet' alias for 'OMNI' 602 net = 'SPAN' alias for 'OMNI' 604 The need of labelling each DECnet network with its name comes also 605 from the requirement to implement the 'intelligent' gateway, i.e., 606 the gateway which is able to understand its ability to connect 607 directly to the specified DECnet network, even if the O/R address 608 specify a path to a different gateway. A more detailed discussion of 609 the problem is in 5.3 and 5.5. 611 A registry of 'net' attributes to insure uniqueness of names must be 612 established: this registry is the same one created for migration to 613 DECnet/OSI. A simple table coupling 'net' and the gateway address is 614 also used, in a syntax similar to the 'gate1' and 'gate2' tables 615 used in MIXER. An example: 617 OMNI#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT# 618 OMNI#O$ESRIN1.PRMD$esa.ADMD$Master400.C$it# 619 HEPnet#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT# 620 HEPnet#O$ESRIN1.PRMD$esa.ADMD$Master400.C$it# 621 SPAN#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT# 622 SPAN#O$ESRIN1.PRMD$esa.ADMD$Master400.C$it# 624 Ambiguous left entries are allowed. Gateway implementations could 625 simply choose among one of the specified gateways, or try them all in 626 cyclic order to obtain better performances. 628 Note that aliases are established using this gate table, too: simply 630 I-DRAFT Mail-11 Mapping January 1997 632 add equivalent entries into the table, like the 'HEPnet' and 'SPAN' 633 entries. Aliases, however, must be used only to enable users to use 634 commonly used names, but any gateway implementing this specification 635 must generate addresses with official 'net' names, only ('OMNI' for 636 the above table). 638 The Mail-11 gateways table, however, just constitutes the list of the 639 'official gateways' between Mail-11 based communities, X.400 and (via 640 the appropriate MIXER address translation) RFC822 world. Any other 641 gateway implementing this specification (and the related ones) should 642 use its local name as first choice for the Mail-11 'net' it can 643 reach, and use the official Mail-11 gateway table to reach only the 644 non connected ones. This list of Mail-11 gateway entries is supposed 645 to contain the list of 'net' tags and their aliases; as this list is 646 usually small, currently we do not take into account distribution 647 mechanisms for this information different from a static table. 649 In order to keep the mapping rules very simple, avoiding the need to 650 analyse Mail-11 addresses to distinguish the 'route', 'node', and 651 'local-part', we will just define the minimal set of Domain Defined 652 Attributes (DDAs) needed to cover the mapping problem. 654 5.2. Mail-11 --> X.400 656 We define the following Domain Defined Attributes to map a Mail-11 657 address: 659 DD.Dnet 660 DD.Mail-11 662 We thus define the Mail-11 Phase IV mapping rule: 664 route::node::localpart 666 maps into 668 C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net; 669 DD.Mail-11=route::node::localpart; 671 Meanwhile we define the mapping rule for Mail-11 DECnet/OSI: 673 net:node-clns::localpart 675 maps into 677 C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net; 678 DD.Mail-11=node-clns::localpart; 680 with: 682 xx = country code of the gateway performing the conversion 683 yyy = Admd of the gateway performing the conversion 685 I-DRAFT Mail-11 Mapping January 1997 687 zzz = Prmd of the gateway performing the conversion 688 ooo = Organisation of the gateway performing the conversion 689 uuu = Org. Unit(s) of the gateway performing the conversion 690 net = name of the DECnet network (e.g., OMNI, HEPnet, SPAN,...) 692 ('zzz','ooo','uuu' being used or dropped appropriately in order to 693 identify uniquely within the X.400 MHS the gateway performing the 694 conversion). 696 The following defaults also apply: 698 if 'node' (or 'node-clns') is missing and we are mapping the Mail-11 699 originator (From) then 'node' (or 'node-clns') defaults to the DECnet 700 node name of the gateway (gwnode); 702 if 'node' (or 'node-clns') is missing and we are mapping the Mail-11 703 recipient (To, Cc) then 'node' (or 'node-clns') defaults to the 704 DECnet node name of the 'From' address. 706 if 'net' is missing, then it defaults to a value defined locally by 707 the gateway: if the gateway is connected to one DECnet network only, 708 then 'net' will be the name of this unique network; if the gateway is 709 connected to more than one DECnet network, then the gateway will 710 establish a 'first choice' DECnet network, and 'net' will default to 711 this value. 713 The 'node' syntax (DECnet/OSI or Phase IV) depends on the DECnet 714 protocol implemented and on the value of a system parameter (usually 715 the MAIL$SYSTEM_FLAGS one) on the gateway host. 717 In case 'local-part' contains 'x400-text-address' see also section 718 6.4.3; 720 In case 'local-part' contains 'RFC822-address' see also section 721 6.4.4. 723 5.2.1. Examples 725 Let us suppose that: 727 - the DECnet network name (net) is 'OMNI'; 728 - the DECnet node name of the gateway (gwnode) is '.IT.DM.X4TDEC' 729 alias 'X4TDEC' in Phase IV; 730 - the Country Code of the gateway is 'IT' and its ADMD is 'garr' 731 (and these two fields are enough to identify uniquely the gateway 732 within the X.400 MHS). 734 USER47 735 C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=.IT.DM.X4TDEC::USER47; 737 MYNODE::BETTY 738 C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=MYNODE::BETTY; 740 I-DRAFT Mail-11 Mapping January 1997 742 BOSTON::GOOFY1::MARY34 743 C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=BOSTON::GOOFY1::MARY34; 745 .DE.UNI-BN.PHYS.NODE18::MARY34 746 C=it; ADMD=garr; DD.Dnet=OMNI; 747 DD.Mail-11=.DE.UNI-BN.PHYS.NODE18::MARY34; 749 UCLA13::MVAX93::MRGATE::"MBOX1::MBX34:MYC3::BOB" 750 C=it; ADMD=garr; DD.Dnet=OMNI; 751 DD.Mail-11=UCLA13::MVAX93::MRGATE::(q)MBOX1::MBX34::MYC3::BOB(q) 753 ENET:.US.CENTRAL.MIAMI2::George.Rosenthal 754 C=it; ADMD=garr; DD.Dnet=ENET; 755 DD.Mail-11=.US.CENTRAL.MIAMI2::George.Rosenthal; 757 MRGATE::"C=xx::A=bbb::P=ppp::S=Joe" 758 C=it; ADMD=garr; DD.Dnet=OMNI; 759 DD.Mail-11=X4TDEC::MRGATE::(q)C=xx::A=bbb::P=ppp::S=Joe(q) 761 MAINVX::In%"path1!path2!user%dom" 762 C=it; ADMD=garr; DD.Dnet=OMNI; 763 DD.Mail-11=MAINVX::In(p)(q)path1(b)path2(b)user(p)dom(q) 765 5.3. X.400 encoding of Mail-11 --> Mail-11 767 In order to assure path reversibility in case of multiple 768 Mail-11/X.400 gateway crossing we must distinguish two cases: 770 - DD.Dnet=net is known to the gateway as one of the DECnet networks 771 it is connected to. In this case the mapping is trivial: 773 C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net; 774 DD.Mail-11=route::node::localpart; 776 (see sect. 5.2 for explication of 'xx','yyy','zzz','ooo','uuu','net') 778 maps into 780 route::node::localpart 782 and for DECnet/OSI addresses 784 C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net; 785 DD.Mail-11=node-clns::localpart; 787 maps into 789 net:node-clns::localpart 791 - DD.Dnet=net is NOT known to the gateway as one of the DECnet 792 networks it is connected to. In this case the mapping rule 793 described into section 5.4 apply: 795 I-DRAFT Mail-11 Mapping January 1997 797 C=xx; ADMD=yyy; PRMD=www; DD.Dnet=net; 798 DD.Mail-11=route::node::localpart; 800 maps into 802 gwnode::gw%"C=xx;ADMD=yyy;PRMD=www;DD.Dnet=net; 803 DD.Mail-11=route::node::localpart;" 805 Again for DECnet/OSI addresses: 807 C=xx; ADMD=yyy; PRMD=www; DD.Dnet=net; 808 DD.Mail-11=node-clns::localpart; 810 maps into 812 gwnode::gw%"C=xx;ADMD=yyy;PRMD=www;DD.Dnet=net; 813 DD.Mail-11=node-clns::localpart;" 815 5.3.1. Examples 817 Let us suppose that: 819 - the DECnet network name (net) is 'OMNI'; 820 - the DECnet node name of the gateway (gwnode) is '.IT.DM.X4TDEC'; 821 alias 'X4TDEC' in Phase IV; 822 - the Country Code of the gateway is 'IT' and its ADMD is 'garr'; 824 (and these two fields are enough to identify uniquely the gateway 825 within the X.400 MHS). 827 C=it; ADMD=garr; DD.Dnet=OMNI; 828 DD.Mail-11=X4TDEC::MRGATE::(q)C=ab::A=dsa::P=qwty::OU=mie::S=Cly(q) 829 MRGATE::"C=ab::A=dsa::P=qwty::OU=mie::S=Cly" 831 C=it; ADMD=garr; DD.Dnet=EASYNET; DD.Mail-11=ROM01::CARLO; 832 X4TDEC::gw%"C=it;ADMD=garr;DD.Dnet=EASYNET; 833 DD.Mail-11=ROM01::CARLO;" 835 (in the above example 'EASYNET' is supposed to be not connected to 836 our gateway located on .IT.DM.X4TDEC DECnet node). 838 5.4. X.400 --> Mail-11 840 The mapping of an X.400 O/R address into Mail-11 is done encoding the 841 various attributes into the X400-text-address as defined in chapter 4 842 of MIXER, and including this as 'f-address'. A 'f-pref' and a the 843 DECnet node name of the gateway. 845 Thus 847 x400-text-address 849 I-DRAFT Mail-11 Mapping January 1997 851 will be encoded like 853 gwnode::gw%"x400-text-address" 855 having spaces dividing attributes as optional. 857 5.4.1. Example 859 Let us suppose that: 861 - the DECnet node name of the gateway (gwnode) is '.IT.DM.X4TDEC' 862 alias 'X4TDEC' in Phase IV, and 'net' is 'OMNI' 864 Thus 866 C=gb; ADMD=G400; PRMD=AC.UK; O=ucl; S=Clay; 868 will be encoded like 870 X4TDEC::gw%"/C=gb/A=G400/P=AC.UK/O=ucl/S=Clay" 872 or its equivalent with the ";" notation and DECnet/OSI 'node' 874 OMNI:.IT.DM.X4TDEC::gw%"C=gb;ADMD=G400;PRMD=AC.UK;O=ucl;S=Clay;" 876 5.5. Mail-11 encoding of X.400 --> X.400 878 It can happen that Mail-11 is used to relay messages between X.400 879 systems; this will mean multiple X.400/Mail-11 gateway crossing and 880 we will encounter Mail-11 addresses containing embedded X.400 881 informations. In order to assure path reversibility we must then 882 distinguish two cases: 884 - the embedded X.400 address belongs to a domain whose naming and 885 routing rules are known to the global X.400 MHS. In this case the 886 mapping is trivial: 888 route::gwnode::gw%"x400-text-address" 890 or (for DECnet/OSI) 892 net:gwnode::gw%"x400-text-address" 894 maps into 896 x400-text-address 898 'route' and 'gwnode' are mapped into X.400 Trace service elements. 900 - the encoded X.400 domain does not belong to the global X.400 name 901 space. In this case the mapping rule described into section 5.2 903 I-DRAFT Mail-11 Mapping January 1997 905 apply: 907 route::gwnode::gw%"x400-text-address" 909 maps into 911 C=xx; ADMD=yyy; DD.Dnet=net; 912 DD.Mail-11=route::gwnode::gw(p)(q)x400-text-address(q); 914 and (for DECnet/OSI) 916 net:gwnode::gw%"x400-text-address" 918 maps into 920 C=xx; ADMD=yyy; DD.Dnet=net; 921 DD.Mail-11=gwnode::gw(p)(q)x400-text-address(q); 923 The latter case is deprecated and must be regarded as a possible 924 temporary solution only, while waiting to include into the global 925 X.400 MHS also this domain. 927 5.5.1. Examples 929 Let us suppose that: 931 - the DECnet network name (net) is 'OMNI'; 932 - the DECnet node name of the gateway (gwnode) is '.IT.DM.X4TDEC' 933 alias 'X4TDEC' in Phase IV; 934 - the Country Code of the gateway is 'IT' and its ADMD is 'garr'; 935 (and these two fields are enough to identify uniquely the 936 gateway within the X.400 MHS). 938 X4TDEC::gw%"C=fr;ADMD=atlas;PRMD=ifip;O=poly;S=Moreau;" 939 C=fr; ADMD=atlas; PRMD=ifip; O=poly; S=Moreau; 941 X4TDEC::gw%"C=zz;ADMD= ;PRMD=Botwa;O=Miner;S=Chiuaw;" 942 C=it; ADMD=garr; DD.Dnet=OMNI; 943 DD.Mail-11=X4TDEC::gw(p)(q)C=zz;ADMD= ; 944 PRMD=Botwa;O=Miner;S=Chiuaw;(q) 946 (in the above example C=zz is unknown to the global X.400 MHS) 948 Chapter 6 - Mapping - Mail-11 / RFC822 950 6.1 Introduction 952 The implementation of a Mail-11 - RFC822 gateway was faced by many 953 software developers independently, and was included in many mail 954 products which were running on both VMS and UNIX systems. As there 955 was not a unique standard mapping way, the implementations resulted 957 I-DRAFT Mail-11 Mapping January 1997 959 into a number of possible variant methods to map a Mail-11 address 960 into an RFC822 one. Some of these products became then largely 961 widespread, starting to create a number of de facto mapping methods. 963 In this chapter some sort of standardisation of the mapping problem 964 is considered, trying to be compatible with the existing installed 965 software. We must also remind that, in some cases, only simple 966 Mail-11 addresses could be mapped into RFC822, having complex ones 967 producing all sort of quite strange results. In case DECnet/OSI 968 Mail-11 addresses are involved we must also notice that only one 969 mapping method can be used from/to RFC822 addresses. 971 On the other hand, the mapping of an RFC822 address in Mail-11 was 972 quite straightforward, resulting in a common definition which uses 973 "Mail-11 foreign mail protocol" to design an RFC822 address: 975 [[node::][node::]...]prot%"rfc-822-address" 977 or 979 [node::][node::]...]prot::"rfc-822-address" 981 or again for DECnet/OSI addresses 983 [net:][node-clns::]prot%"rfc-822-address" 985 or 987 [net:][node-clns::]prot::"rfc-822-addres" 989 6.2 De facto implementations 991 A considerable number of de-facto implementations of Mail-11/RFC822 992 gateways is existing. As said in the introduction, the mapping of 993 RFC822 addresses in Mail-11 is accomplished using the foreign mail 994 protocol syntax and is thus unique. 996 On the other hand, Mail-11 addresses are encoded in RFC822 syntax in 997 various ways. Here are the most common ones: 999 a) "node::user"@gateway-address 1000 b) user%node@gateway-address 1001 c) user@node.decnet.domains 1002 d) user%node.dnet@gateway-address 1004 Let's have a quick look to these different choices. 1006 a - This form simply encloses as quoted Left Hand Side string the 1007 original Mail-11 address into the RFC822 address of the 1008 Mail-11/RFC822 gateway. This method is fully conformant with 1009 RFC822 syntax, and the Mail-11 address is left untouched; thus 1010 no encoding rules need to applied to it. This method applies also 1012 I-DRAFT Mail-11 Mapping January 1997 1014 easily to DECnet/OSI Mail-11 addresses. 1016 b - As one will immediately notice, this form has nothing in it 1017 indicating the address is a Mail-11 one; this makes the encoding 1018 indistinguishable from a similar encoding of RSCS (BITnet) 1019 addresses used by some IBM VM Mailer systems. It should thus be 1020 deprecated. 1022 c - In this case a sort of 'reserved word' (DECnet) embedded into 1023 the address itself identifies the presence of a Mail-11 original 1024 address preceding it. The decoding is possible, dropping 1025 'domains' and extracting 'user' and 'node' parts. However complex 1026 Mail-11 addresses cannot be mapped properly in this syntax, and 1027 there is no specific rule for adding the 'domains' part of the 1028 address. 1030 d - In this case again there is a 'reserved word' (dnet) which make 1031 possible the identification of the original Mail-11 address; 1032 'gateway-address' points to the Mail-11/RFC822 gateway and 'node' 1033 and 'user' information can be easily drawn from the address. 1034 However complex Mail-11 addresses cannot be embedded easily into 1035 this syntax. 1037 Note the only methods a) can be successfully used for DECnet/OSI 1038 Mail-11 addresses, while the other cases are already too complex to 1039 encode in a unique way such addresses in RFC822. 1041 6.3 Recommended mappings 1043 From the examples seen in the previous paragraphs we can derive a 1044 canonical form for representing the mapping between Mail-11 and 1045 RFC822. 1047 6.3.1 RFC822 mapped in Mail-11 1049 The mapping of an RFC822 address in Mail-11 is straightforward, using 1050 the "Mail-11 foreign mail protocol" syntax. The two possible variants 1051 for Phase IV are: 1053 [[node::][node::]...]prot%"rfc-822-address" 1055 or 1057 [node::][node::]...]prot::"rfc-822-address" 1059 The equivalent two possible variants for DECnet/OSI are: 1061 [net:][node-clns::]prot%"rfc-822-address" 1063 or 1065 [net:][node-clns::]prot::"rfc-822-address" 1067 I-DRAFT Mail-11 Mapping January 1997 1069 6.3.2 Mail-11 mapped in RFC822 1071 RFC822 foresee a canonical form for representing non-RFC822 1072 addresses: put the foreign address in local part (Left Hand Side, 1073 LHS) is a form as similar as possible to its original syntax. Thus 1074 the suggested mapping both for Phase IV and DECnet/OSI is: 1076 "Mail-11-address"@gateway-address 1078 This format assures also the return path via the appropriate gateway. 1080 6.3.3 Mail-11 (foreign mail protocol) mapped in RFC822 1082 A Mail-11 address containing a foreign mail protocol syntax can 1083 also contain the percent '%' character as a separator between the 1084 foreign protocol name and the actual address itself. In some cases 1085 the address part can also be an unquoted string. Some examples: 1087 deliver%swan 1088 myprot%root.owner 1089 listserv%my-private.list.A1 1091 If these addresses are encoded into an RFC822 address using the 1092 "natural" method described in 6.3.2, they will result in something 1093 which can be easily mismatched with an address using the percent 1094 hack in LHS for source routing. 1096 "myprot%root.owner"@lohost.mydom.edu (Mail-11 address) 1098 "LISTSERV%IBMB.BITnet"@bitgate.anu.edu (% routing address) 1100 The percent hack is strongly deprecated, and thus should be avoided; 1101 the second address above shoud be expressed as: 1103 @bitgate.anu.edu:"LISTSERV@IBMB.BITnet" 1105 However, in order to assure maximum functionality and avoid problems, 1106 it is recommended to encode Mail-11 addresses containing the foreign 1107 protocol specification in RFC822 syntax using the DD.Mail-11 and 1108 DD.dnet qualifiers, i.e. 1110 "/DD.Mail-11=myprot%root.owner/DD.dnet=OMNI"@lohost.mydom.edu 1112 The DD.dnet defaults as indicated in the similar cases for the 1113 Mail-11 / X.400 mappings. This encoding method can, of course, also 1114 be used to map any other Mail-11 address in RFC822, and is the only 1115 one which enable to specify the network name ('OMNI' in the above 1116 example) for DECnet Phase IV Mail-11 addresse. The method is fully 1117 compatible with the results also produced by gateways following the 1118 MIXER specification for Mail-11 addresses encoded in X.400 and 1119 then translated into RFC822. 1121 I-DRAFT Mail-11 Mapping January 1997 1123 Chapter 7 - Complex mapping - X.400 / Mail-11 / RFC822 1125 7.1. The protocol triangle 1127 The bilateral mappings described in chapters 5 and 6 must be extended 1128 in order to cover also the case in which also RFC822 addressing is 1129 involved, and the following triangular situation occurs: 1131 X.400 1132 / \ 1133 / \ 1134 / \ 1135 Mail-11----RFC822 1137 The X.400 - RFC822 side is fully covered by MIXER, and the previous 1138 chapters in this document cover the Mail-11 - X.400 side and the 1139 Mail-11 - RFC822 one. 1141 7.2. RFC822 mapped in Mail-11 1143 The 'RFC822-address' is usually included in 'local-part' as 1145 route::gwnode::gw%"rfc822-address" 1147 or the equivalent in DECnet/OSI: 1149 net:gwnode::gw%"rfc822-address" 1151 An example in Phase IV 1153 NVXA23::SMTPGW::in%"M.T.Rose@CS.UCLA.edu" 1155 and another one in DECnet/OSI 1157 OMNI:.FR.INET.LABOL.SMTPGW::in%"M.T.Rose@CS.UCLA.edu" 1159 7.3. Mail-11 mapped in RFC822 1161 There are different styles in mapping a Mail-11 address in RFC822; 1162 let's have a short summary of what was traditionally done in some 1163 implementations. 1165 7.3.1 Mail-11 address encoded in "Left Hand Side" (LHS) of RFC822 1166 address, using "%" syntax or "::" syntax 1168 route::node::localpart (Phase IV) 1170 maps to 1172 I-DRAFT Mail-11 Mapping January 1997 1174 localpart%node%route@gw-domains 1176 or 1178 "route::node::localpart"@gw-domains 1180 Again, let's consider the DECnet/OSI case: 1182 net:node-clns::localpart (DECnet/OSI) 1184 maps to 1186 "net:node-clns::localpart"@gw-domains 1188 (note that "%" encoding does not exist for this case) 1190 where 'gw-domains' identify uniquely the Mail-11 / RFC822 gateway. 1192 7.3.2 Mail-11 address maps partly to LHS and partly to 'domain' part of 1193 RFC822 address 1195 node::localpart 1197 maps to 1199 localpart@node.gw-domains 1201 note that this kind of mapping does not exists with DECnet/OSI 1202 Mail-11 addresses. 1204 7.3.3 Mail-11 address is completely hidden by a mapping table 1206 In this case the resultant RFC822 address contains no trace at all of 1207 the original Mail-11 address. 1209 7.4. Multiple conversions 1211 Let us now examine briefly the possible situations which involve 1212 multiple conversions, having one protocol as a relay between the 1213 other two. This summary suggest some possible enhanced solutions to 1214 avoid heavy and unduly mappings, but the 'step by step' approach, 1215 considering blindly one conversion as disjointed to the other, as 1216 described in the previous sections, can always be used. 1218 7.4.1. X.400 --> RFC822 --> Mail-11 1220 We apply the MIXER rules to the first step, obtaining an RFC822 1221 address which can be mapped in Mail-11 using the 'f-address' field, 1222 as described in section 7.2. 1224 an example: 1226 I-DRAFT Mail-11 Mapping January 1997 1228 C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay; 1230 maps accordingly to MIXER to 1232 Jim.Clay@cs.UCL.AC.UK 1234 and finally becomes 1236 SMTPGW::In%"Jim.Clay@cs.UCL.AC.UK" 1238 and finally becomes 1240 SMTPGW::In%"Jim.Clay@cs.UCL.AC.UK" 1242 where 'SMTPGW' is the DECnet Phase IV node name of the machine 1243 running the RFC822 to Mail-11 gateway. Again, in case the machine 1244 running the RFC822 to Mail-11 gateway is a DECnet/OSI one (like 1245 OMNI:.US.VA.CENTRL) we would get 1247 OMNI:.US.VA.CENTRL::In%"Jim.Clay@cs.UCL.AC.UK" 1249 7.4.2. Mail-11 --> RFC822 --> X.400 1251 Some of the possible mapping described in section 7.3 for Phase IV 1252 apply to the Mail-11 address, hiding completely its origin. The 1253 MIXER apply on the last step. 1255 an example: 1257 RELAY::MYNODE::BETTY 1259 could map into RFC822 as 1261 BETTY%MYNODE@RELAY.dnet.gw1.it 1263 and accordingly to MIXER 1265 C=it; A=garr; P=dom1; O=gw1; OU=RELAY; S=BETTY(p)MYNODE; 1267 where 'dnet.gw1.it' is the domain of the machine running the Mail-11 1268 to RFC822 gateway. 1270 7.4.3. X.400 --> Mail-11 --> RFC822 1272 The X.400 address is stored into Mail-11 'f-address' element as 1273 described in sections 5.3 and 5.4; then if the Mail-11 to RFC822 1274 gateway is able to understand the presence of a 'x400-text-address' 1275 into the Mail-11 address, then it applies MIXER to it, and encodes 1276 header. Otherwise it applies the rules described in 7.3 1278 an example: 1280 I-DRAFT Mail-11 Mapping January 1997 1282 C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay; 1284 will be encoded like 1286 X4TDEC::gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Jim/S=Clay" 1288 If the Mail-11 to RFC822 gateway recognise the x400-text-address, 1289 then the address becomes, accordingly to MIXER 1291 Jim.Clay@cs.UCL.AC.UK 1293 and the following RFC822 header line is added 1295 Received: from X4TDEC with DECnet (Mail-11) on xx-xxx-xxxx. 1297 Otherwise one of the dumb rules could produce 1299 gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Jim/S=Clay"@X4TDEC.doms 1301 The case with DECnet/OSI Mail-11 is conceptually identical. 1303 7.4.4. RFC822 --> Mail-11 --> X.400 1305 The RFC822 address is encoded in Mail-11 f-address element as 1306 described in sect. 7.2; then if the Mail-11 to X.400 gateway is able 1307 to understand the presence of an 'RFC822-address' into the Mail-11 1308 address, then it applies MIXER to it, and encodes 'route' and 1309 applies the rules described in 5.2 and 5.5. 1311 an example: 1313 Jim.Clay@cs.UCL.AC.UK 1315 will be encoded like 1317 SMTPGW::In%"Jim.Clay@cs.UCL.AC.UK" 1319 If the Mail-11 to X.400 gateway recognise the RFC822-address, then 1320 the address becomes, accordingly to MIXER 1322 C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay; 1324 and a 'trace' record is added into the X.400 P1 data, stating that a 1325 node named SMTPGW was crossed. 1327 Otherwise dumb rule produces 1329 C=it; ADMD=garr; DD.Dnet=HEP; 1330 DD.Mail-11=SMTPGW::In(p)(q)Jim.Clay(a)cs.UCL.AC.UK(q) 1332 Again, the case for DECnet/OSI Mail-11 addresses, is conceptually 1333 identical. 1335 I-DRAFT Mail-11 Mapping January 1997 1337 7.4.5. RFC822 --> X.400 --> Mail-11 1339 We apply MIXER to the first conversion, obtaining an X.400 address. 1340 Then the rules described in sections 5.3 and 5.4 are used to store 1341 the X.400 address as 'x400-text-address' into the Mail-11 1343 an example: 1345 Jim.Clay@cs.UCL.AC.UK 1347 maps accordingly to MIXER to 1349 C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay; 1351 and finally becomes 1353 SMTPGW::gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Jim/S=Clay" 1355 where 'SMTPGW' is the DECnet Phase IV node name of the machine 1356 running the X.400 to Mail-11 gateway. No differences also for 1357 DECnet/OSI Mail-11 addresses. 1359 7.4.6. Mail-11 --> X.400 --> RFC822 1361 The Mail-11 address is encoded as specified in sections 5.2 and 5.5; 1362 then MIXER is used to convert the address in RFC822. 1364 an example: 1366 RELAY::MYNODE::BETTY 1368 maps into X.400 as 1370 C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=RELAY::MYNODE::BETTY; 1372 and accordingly to MIXER 1374 "/C=it/A=garr/DD.Dnet=OMNI/DD.Mail-11=RELAY::MYNODE::BETTY"@gw2.it 1376 where 'gw2.it' is the domain of the machine running the MIXER 1377 gateway. 1379 7.4. Conclusions 1381 A standard way of mapping Mail-11 addresses into RFC822 and vice 1382 versa is feasible. A suggestion is thus made to unify all existing 1383 and future implementations. It should be noted, however, that it 1384 could be impossible (in case of DECnet Phase IV) to specify in these 1385 mappings the name of the decnet community owning the encoded address, 1386 as it can be always done for X.400; thus the implementation of the 1387 'intelligent' gateway in this case could result impossible. 1389 I-DRAFT Mail-11 Mapping January 1997 1391 Chapter 8 - Notifications and Probes 1393 8.1. Overview 1395 Mail-11 is a real time protocol, i.e. connection is established 1396 directly to the destination node. This makes possible some level of 1397 services like verification of an address, and delivery confirmation. 1399 However, Mail-11 User Agents ususally do not support notification or 1400 probe services, whereas it is possible to deliver the result of a 1401 notification or a probe to Mail-11. In this section we will briefly 1402 describe the level of service which can be obtained on these services 1403 when Mail-11 is involved. 1405 8.2. Delivery of Notifications via Mail-11 1407 As described in the previous chapters, it is possible to transport 1408 also in Mail-11 with minimal loss of information complex information. 1409 This also includes Notifications. In fact Notifications in 1410 RFC822/MIME are encoded as MIME multipart messages: there are thus no 1411 problems in transporting these messages in Mail-11 as any other MIME 1412 message. Also X.400 Notifications can be transported and delivered 1413 via Mail-11: MIXER describes in fact how to convert them into MIME 1414 multipart messages, taking the problem back to the previous 1415 situation. 1417 Even when Mail-11 is just an intermediate step for a Notification 1418 message, this consideration just enable support for the service. 1420 8.3. Generation of Notifications and Probes from Mail-11 1422 Although Mail-11 does not support Notification or Probe, the service 1423 could also be supported at gateway level. In fact, due to real time 1424 nature of Mail-11 protocol, the gateway could be reasonably sure that 1425 delivery until the other end of the Mail-11 path was successful or 1426 unsuccessful (and try to verify the feasibility of a delivery in 1427 case a Probe as requested). However, Mail-11 could just be an 1428 intermediate relay service, vanishing the value of the information. 1430 Implementation of this kind of service at gateway level is thus 1431 questionable, and if done, should clearly state the situation where 1432 it was generated, and the "confidence level" it conveys. 1434 Security Considerations 1436 Security issues are not discussed in this memo. 1438 Acknowledgements 1440 I wish to thank all those people who read the first draft and 1441 contributed a lot with their useful suggestions to the revision of 1442 this document, in particular RARE WG1 and IETF X.400 ops group 1444 I-DRAFT Mail-11 Mapping January 1997 1446 members and S. E. Kille. 1448 Thanks also to a number of implementors (among which Ned Freed, 1449 Julian Onions, The Hebrew University of Tel Aviv - Pine VMS support 1450 team), to the HEPnet Mail Technical Committee and to all my Mail-11 1451 "end users", in particular Enzo Valente, for their suggestions and 1452 wishes which helped me really a lot to prepare this revision of 1453 former RFC1405. 1455 References 1457 [1] CCITT, "CCITT Recommendations X.400-X.430", Message Handling 1458 Systems: Red Book, October 1984. 1460 [2] CCITT, "CCITT Recommendations X.400-X.420", Message Handling 1461 Systems: Blue Book, November 1988. 1463 [3] CCITT/ISO, "CCITT Recommendations X.400/ ISO IS 10021-1," 1464 Message Handling: System and Service Overview , December 1992. 1466 [4] Crocker D., "Standard of the Format of ARPA Internet Text 1467 Messages", STD 11, RFC 822, UDel, August 1982. 1469 [5] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): 1470 Mapping between X.400 and RFC 822/MIME", RFC 1327bis, xxxxx 1471 1997. 1473 [6] Alvestrand H., Kille S., Miles R., Rose M., and Thompson S., 1474 (MIME-MHS) "Mapping between X.400 and RFC-822 Message Bodies," 1475 RFC 1495, Aug 1993. 1477 [7] Digital Equipment Corp., "VMS Mail Utility". 1479 [8] Joiner Associates Inc., "Jnet User's Manual". 1481 [9] PMDF User's Guide. 1483 [10] Alvestrand, H. "Writing X.400 O/R Names", UNINETT / RFC1685, 1484 August 1994. 1486 [10] CCITT, "F.401 CCITT Message Handling Services - Operations and 1487 Definitions of Service - Naming and Addressing for Public 1488 Message Handling Services, Annex B (08/92)", August 1992 1490 I-DRAFT Mail-11 Mapping January 1997 1492 Author's Address 1494 Claudio Allocchio 1495 Sincrotrone Trieste 1496 SS 14 Km 163.5 Basovizza 1497 I 34012 Trieste 1498 Italy 1500 Phone: +39 40 3758523 1501 Fax: +39 40 3758565 1502 EMail: Claudio.Allocchio@elettra.Trieste.it 1503 C=it; A=garr; P=Trieste; O=Elettra; S=Allocchio; G=Claudio;