idnits 2.17.1 draft-hardcastle-mapping-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-19) 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. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations 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 an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (October 17, 1992) is 11507 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) -- Missing reference section? 'MHS88' on line 114 looks like a reference -- Missing reference section? 'Cro82' on line 106 looks like a reference -- Missing reference section? 'Kil92' on line 110 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working S.E. Hardcastle-Kille 3 Group ISODE Consortium 4 INTERNET-DRAFT October 17, 1992 5 Expires: April 1993 7 Mapping between X.400 and RFC 822 for a closed RFC 822 Community 9 IC-11 (1.1) 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 Areas, 15 and its Working Groups. Note that other groups may also distribute 16 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six months. 18 Internet Drafts may be updated, replaced, or obsoleted by other 19 documents at any time. It is not appropriate to use Internet Drafts 20 as reference material or to cite them other than as a "working draft" 21 or "work in progress." 22 Please check the I-D abstract listing contained in each Internet Draft 23 directory to learn the current status of this or any other Internet 24 Draft. 26 Abstract 27 This document proposes a modification of the X.400/RFC 822 mapping 28 described in RFC 1327, for a specific type of application. 30 This document will be submitted to the IETF X.400 OPS WG for suggested 31 progress as a standards track RFC. 33 INTERNET--DRAFT RFC 1327 for closed RFC 822 October 17, 1992 35 1 Problem Statement 37 An organisation may choose to have all external mail access using 38 X.400 [MHS88]. Reasons for this include: 40 o Policy 42 o Choosing a single access mechanism to ensure coherency 44 o Security and traceability reasons 46 Such an organisation may wish to run RFC 822 user agents internally, 47 as there are a number of sound products available. Mapping between 48 RFC 822 and X.400 according to RFC 1327 requires the use of a globally 49 unique mapping. Maintenance of this mapping is a significant overhead 50 [Cro82, Kil92]. 51 The reason for maintenance of the globally unique mapping is to 52 maintain coherency between gateways. For a closed community, there is 53 no fundamental requirement for this consistency. This document 54 proposes a modification of RFC 1327 which does not utilise a globally 55 unique mapping. This results in the generation of addresses which 56 follow RFC 822 syntax, but have local semantics. 58 2 Mechanism 60 2.1 Use with private tables 62 The basic mechanism is to follow RFC 1327, but use a private mapping 63 common to all of the gateways in the community. The mappings should 64 be defined to produce addresses which are convenient to the community. 65 Typically, the tables will be simple, and lead to addresses which are 66 algorithmically related to the X.400 address. Mappings may be defined 67 to make local addresses short and convenient. 69 WARNING: This specification should not be used where there is or may 70 in the future be a direct RFC 822 connection into the global RFC 71 822 community. 73 INTERNET--DRAFT RFC 1327 for closed RFC 822 October 17, 1992 75 2.2 Use without tables 77 A special variant is to perform the mapping without any mapping 78 tables. In this case, all the RFC 822 addresses will have a full LHS 79 encoding, and the domain is set according to one of two variants. 81 1. Where there is no external RFC 822 connection. Here the domain is 82 set to MHS. 84 2. Where there is an external RFC 822 connection, the domain should 85 be set to the local RFC 822 domain. This will lead to inefficient 86 RFC 822 routing, and so should be avoided if there is extensive 87 external RFC 822 traffic. 89 2.3 Domain Defined Attributes 91 When mapping from X.400 to RFC 822, it is important that any RFC-822 92 DDA is not interpreted as a locale RFC 822 address (as allowed in the 93 note on page 55 of RFC 1327). Rather, it should be encoded on the 94 LHS, so that a replyable address is generated. 96 The closed RFC 822 community should, if possible, be set up so that 97 all local RFC 822 addresses are mapped to X.400 addresses without 98 DDAs. If a DDA must be generated, the values CLD-822, CLD822C1, 99 CLD822C2, and CLD822C2 shall be used instead of the usual RFC 1327 100 Domain Defined Attributes. This will prevent a remote RFC 1327 101 gateway from interpreting a local RFC 822 address as if it had global 102 semantics. 104 References 106 [Cro82] D.H. Crocker. Standard of the format of ARPA internet text 107 messages. Request for Comments 822, University of Delaware, 108 August 1982. 110 [Kil92] S.E. Kille. Mapping between X.400(1988) / ISO 10021 and RFC 111 822. Request for Comments 1327, Department of Computer 112 Science, University College London, May 1992. 114 [MHS88] CCITT recommendations X.400 / ISO 10021, April 1988. CCITT 115 SG 5/VII / ISO/IEC JTC1, Message Handling: System and 116 Service Overview.