idnits 2.17.1 draft-ietf-fax-minaddrgen-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. ** Bad filename characters: the document name given in the document, 'draft-ietf-fax-minaddrgen-01.txt)', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-fax-minaddrgen-01.txt)', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-fax-minaddrgen-01.txt)', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-fax-minaddrgen-01.txt)', but the file name used is 'draft-ietf-fax-minaddrgen-01' == 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 332 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract 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. ** There are 33 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 241 has weird spacing: '...for the purpo...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 (December 1997) is 9591 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: '4' is defined on line 280, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 292, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 295, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 299, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 302, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 305, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 312, but no explicit reference was found in the text ** Obsolete normative reference: RFC 821 (ref. '1') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (ref. '2') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1528 (ref. '4') (Obsoleted by RFC 9121) ** Obsolete normative reference: RFC 2065 (ref. '5') (Obsoleted by RFC 2535) ** Obsolete normative reference: RFC 2234 (ref. '7') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Duplicate reference: RFC822, mentioned in '14', was also mentioned in '2'. ** Obsolete normative reference: RFC 822 (ref. '14') (Obsoleted by RFC 2822) Summary: 18 errors (**), 1 flaw (~~), 13 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group C. Allocchio 2 INTERNET-DRAFT GARR-Italy 3 Expires: June 1998 December 1997 5 Minimal PSTN address format in Internet Mail 7 (draft-ietf-fax-minaddrgen-01.txt) 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts. Internet Drafts are draft 15 documents valid for a maximum of six months. Internet Drafts may be 16 updated, replaced, or obsoleted by other documents at any time. It is 17 not appropriate to use Internet Drafts as reference material or to 18 cite them other than as a ``working draft'' or ``work in progress.'' 19 Please check the I-D abstract listing contained in each Internet Draft 20 directory to learn the current status of this or any other Internet 21 Draft. 23 1. Introduction 25 Since the very first e-mail to PSTN services gateway appeared, a 26 number of different methods to specify a PSTN address as an e-mail 27 address have been used by implementors. Two major objectives for 28 this were 30 - enable an e-mail user to access these services from his/her 31 e-mail interface; 33 - enable some kind of ''PSTN over e-mail service'' transport, to 34 reduce the costs of PSTN long distance transmissions, and use 35 the existing e-mail infrastructure. 37 This memo describes the MINIMAL addressing method to encode PSTN 38 addresses into e-mail addresses and the standard extension mechanism 39 to allow definition of further standard elements. The opposite problem, 40 i.e. to allow a traditional numeric-only PSTN device user to access 41 the e-mail transport service, is not discussed here. 43 All implementations supporting this PSTN over e-mail service MUST 44 support as a minimum the specification described in this document. 45 The generic complex case of converting the whole PSTN addressing 46 into e-mail is out of scope in this minimal specification: there 47 is some work in progress in the field, where also a number of 48 standard optional extensions are being defined. 50 In this document the formal definitions are described using ABNF 51 syntax, as defined into [7]. We will also use some of the ''CORE 52 DEFINITIONS'' defined in ''APPENDIX A - CORE'' of that document. The 53 exact meaning of the capitalised words 55 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 56 "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" 58 is defined in reference [6]. 60 2. Minimal PSTN address 62 The minimal specification of a PSTN address in e-mail address is 63 as follows: 65 pstn-address = pstn-mbox [ qualif-type1 ] 67 pstn-mbox = service-selector "=" global-phone 69 service-selector = 1*( DIGIT / ALPHA / "-" ) 70 ; note that SP (space) is not allowed in 71 ; service-selector. 72 ; service-selector MUST be handled as a case 73 ; INSENSITIVE string by implementations. 75 Specifications adopting the "pstn-address" definition MUST define a 76 unique case insensitive "service-selector" element to identify the 77 specific messaging service involved. 79 These specifications MUST also define which minimal "qualif-type1" 80 extensions, if any, MUST be supported for the specified service. 82 Implementations confirming to these minimal requirements specification 83 are allowed to ingnore any other non-minimal extensions address 84 element which can be present in the "pstn-address". However, conforming 85 implementations MUST preserve all "qualif-type1" address elements they 86 receive. 88 The generic "qualif-type1" element is defined as: 90 qualif-type1 = "/" keyword "=" string 92 keyword = 1*( DIGIT / ALPHA / "-" ) 93 ; note that SP (space) is not allowed in keyword 95 string = PCHAR 96 ; note that printable characters are %x20-7E 98 As such, all "pstn-address" extensions elements MUST be defined in the 99 "qualif-type1" form. 101 2.1 Minimal "global-phone" definition 103 We now define the minimal supported syntax for global-phone: 105 global-phone = "+" 1*( DIGIT , written-sep ) 107 written-sep = ( "-" / "." ) 109 The use of other dialling schemas for PSTN numbers (like private 110 numbering plans or local dialling conventions) is also allowed. 111 However, this does not preclude nor remove the minimal compulsory 112 requirement to support the "global-phone" syntax as defined above. 114 Any non "global-phone" dialling schema MUST NOT use the leading 115 "+" between the "=" sign and the dialling string. The "+" sign is 116 strictly reserved for the standard "global-phone" syntax. 118 Note: 119 The specification of these different dialling schemas is out of scope 120 for this minimal specification. 122 User specification of PSTN e-mail addresses will be facilitated if 123 they can insert these separators between dial elements like digits etc. 124 For this reason we allow them in the syntax the written-sep element. 126 Implementors' note: 127 Use of the written-sep elements is allowed, but not recommended. Any 128 occurences of written-sep elements in a pstn-mbox MUST be ignored by 129 all conformant implementations. User Agents SHOULD remove written-sep 130 elements before submitting messages to the Message Transport System. 132 2.2 Some examples of a minimal "pstn-address" 134 VOICE=+3940226338 136 FAX=+12027653000/T33S=6377 138 SMS=+33-1-88335215 140 3. The e-mail address of the I-pstn device: mta-I-pstn 142 An "I-pstn device" has an e-mail address, or to be more exact, a 143 name which enables a mail system to identify it on the e-mail 144 global system. 146 In Internet mail, this is the Right Hand Side (RHS) part of the 147 address, i.e. the part on the right of the "@" sign. We will call 148 this "mta-I-pstn" 150 mta-I-pstn = domain 152 For "domain" strings used in SMTP transmissions, the string MUST conform 153 to the requirements of that standard's specifications [1], [3] 154 and their updates. For "domain" strings used in message content headers, 155 the string MUST conform to the requirements of the relevant standards [2], 156 [3] and their updates. 158 Note: in both cases, the standards permit use of "domain names" or "domain 159 literals" in addresses. 161 4. The pstn-email 163 The complete structure used to transfer a minimal PSTN address over the 164 Internet e-mail transport system is called "pstn-email". This object 165 is a an e-mail address which conforms to RFC822 [2] (and its updates) 166 "addr-spec" syntax, with some extra structure which allows the PSTN 167 number to be identified. 169 pstn-email = ["/"] pstn-address ["/"] "@" mta-I-pstn 171 Implementors' note: 172 The optional "/" characters can result from other mail transport 173 services gateways, where it is also an optional element. 174 Implementations MUST accept the optional slashes but SHOULD NOT 175 generate them. Gateways are allowed to strip them off when 176 converting to Internet mail addressing. 178 4.1 Multiple subaddresses 180 In case a particular service requires multiple subaddresses (in any form 181 defined by the specific standard specification for that service), and 182 these subaddresses need to be given on the same "pstn-mbox", multiple 183 "pstn-email" elements will be used. 185 Implementors' note: 186 The UA could accept multiple subaddress elements for the same 187 global-phone, but it must generate multiple "pstn-mbox" elements 188 when passing the message to the MTA. 190 4.2 Some examples of "pstn-email" 192 VOICE=+3940226338@worldvoice.com 194 FAX=+1.202.7653000/T33S=6377@faxserv.org 196 /SMS=+33-1-88335215/@telecom.com 198 5. Conclusions 200 This proposal creates a minimal standard encoding for PSTN addresses 201 within the global e-mail transport system and defines the standard 202 extension mechanism to be used to introduce specific new elements. 204 The proposal requires no changes to existing e-mail software. Each 205 specific PSTN service using this proposal MUST define its own 206 "service-selector" specification and MUST define the eventual other 207 "qualif-type1" elements to be supported for its minimal addressing 208 specification. An example is in reference [13]. 210 6. Security Considerations 212 This document specifies a means by which PSTN addresses can be 213 encoded into e-mail addresses. As routing of e-mail messages is 214 determined by Domain Name System (DNS) information, a successful 215 attack on this service could force the mail path via some particular 216 gateway or message transfer agent where mail security can be 217 affected by compromised software. 219 There are several means by which an attacker might be able to 220 deliver incorrect mail routing information to a client. These 221 include: (a) compromise of a DNS server, (b) generating a 222 counterfeit response to a client's DNS query, (c) returning 223 incorrect "additional information" in response to an unrelated 224 query. Clients SHOULD ensure that mail routing is based only 225 on authoritative answers. Once DNS Security mechanisms [5] 226 become more widely deployed, clients SHOULD employ those mechanisms 227 to verify the authenticity and integrity of mail routing records. 229 7. Copyright 231 "Copyright (C) The Internet Society (date). All Rights Reserved. 233 This document and translations of it may be copied and furnished to 234 others, and derivative works that comment on or otherwise explain it 235 or assist in its implmentation may be prepared, copied, published and 236 distributed, in whole or in part, without restriction of any kind, 237 provided that the above copyright notice and this paragraph are 238 included on all such copies and derivative works. However, this 239 document itself may not be modified in any way, such as by removing 240 the copyright notice or references to the Internet Society or other 241 Internet organizations, except as needed for the purpose of 242 developing Internet standards in which case the procedures for 243 copyrights defined in the Internet Standards process must be followed, 244 or as required to translate it into languages other than English. 246 The limited permissions granted above are perpetual and will not be 247 revoked by the Internet Society or its successors or assigns. 249 This document and the information contained herein is provided on an 250 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 251 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 252 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 253 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 254 FITNESS FOR A PARTICULAR PURPOSE." 256 8. Author's Address 258 Claudio Allocchio 259 Sincrotrone Trieste 260 SS 14 Km 163.5 Basovizza 261 I 34012 Trieste 262 Italy 264 RFC822: Claudio.Allocchio@elettra.trieste.it 265 X.400: C=it;A=garr;P=Trieste;O=Elettra; 266 S=Allocchio;G=Claudio; 267 Phone: +39 40 3758523 268 Fax: +39 40 3758565 270 9. References 272 [1] RFC821 Simple Mail Transfer Protocol. J. Postel. (August 1982) 274 [2] RFC822 Standard for the format of ARPA Internet text messages. D. 275 Crocker. (August 1982) 277 [3] RFC1123 Requirements for Internet hosts - application and support. R.T. 278 Braden. (October 1989) 280 [4] RFC1528 Principles of Operation for the TPC.INT Subdomain: Remote 281 Printing -- Technical Procedures. C. Malamud & M. Rose. (October 1993) 283 [5] RFC2065 Domain Name System Security Extensions. D. Eastlake, 3rd, C. 284 Kaufman. (January 1997) 286 [6] RFC2119 Key words for use in RFCs to Indicate Requirement Levels. 287 S. Bradner (March 1997) 289 [7] RFC2234 Augmented BNF for Syntax Specifications. D. Crocker, 290 P. Overell (November 1997). 292 [8] ITU F.401 - Message Handling Services: Naming and Addressing for Public 293 Message Handling Service; recommendation F.401 (August 1992) 295 [9] ITU F.423 - Message Handling Services: Intercommunication Between the 296 Interpersonal Messaging Service and the Telefax Service; recommendation 297 F.423 (August 1992) 299 [10] ITU E.164 - Numbering plan for the ISDN era; recommendation E.164/I.331 300 (August 1991) 302 [11] ITU T.33 - Facsimile routing utilizing the subaddress; recommendation 303 T.33 (July, 1996) 305 [12] ETSI I-ETS 300,380 - Universal Personal Telecommunication (UPT): Access 306 Devices Dual Tone Multi Frequency (DTMF) sender for acoustical coupling 307 to the microphone of a handset telephone (March 1995) 309 [13] RFCxxxx (DRAFT-IETF-FAX-ADDRMINFAX-xx.TXT) Minimal FAX address format 310 in Internet Mail. C. Allocchio (xxxx 199x) 312 [14] RFCxxxx (DRAFT-KILLE-MIXER-RFC1327BIS-xx.TXT) MIXER (Mime Internet 313 X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME. 314 S.E. Kille. (xxxx 199x)