idnits 2.17.1 draft-ietf-fax-minaddr-v2-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: ---------------------------------------------------------------------------- == 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 535 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 15 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == 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. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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). -- 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 (July 2000) is 8657 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: '8' is defined on line 461, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 465, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 472, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 475, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 483, 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' ** Obsolete normative reference: RFC 2304 (ref. '13') (Obsoleted by RFC 3192) -- Possible downref: Non-RFC (?) normative reference: ref. '15' ** Obsolete normative reference: RFC 2434 (ref. '16') (Obsoleted by RFC 5226) Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working C. Allocchio 2 Group GARR-Italy 3 INTERNET-DRAFT July 2000 4 Obsoletes: RFC2303 Expires: January 2001 5 Updates: RFC-fulladdr [15] File: draft-ietf-fax-minaddr-v2-01.txt 7 Minimal GSTN address format in Internet Mail 9 Status of this Memo 11 This document is an Internet Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 31 Copyright (C) The Internet Society (1999). All Rights Reserved. 33 Abstract 35 This memo describes a simple method of encoding GSTN addresses 36 (commonly called "telephone numbers") in the local-part of Internet 37 email addresses, along with an extension mechanism to allow encoding 38 of additional standard attributes needed for email gateways to 39 GSTN-based services. 41 As with all Internet mail addresses, the left-hand-side (local-part) 42 of an address generated according to this specification, is not to be 43 interpreted except by an MTA that handles messages for the domain given 44 in the right-hand-side. 46 1. Introduction 48 Since the very first e-mail to GSTN services gateway appeared, a 49 number of different methods to specify a GSTN address as an e-mail 50 address have been used by implementors. Several objectives for this 51 methods have been identified, like to enable an e-mail user to access 52 GSTN services from his/her e-mail interface, to allow some kind of 53 "GSTN over e-mail service" transport (possibly reducing the costs of 54 GSTN long distance transmissions) while using the existing e-mail 55 infrastructure. 57 This memo describes the MINIMAL addressing method to encode GSTN 58 addresses into e-mail addresses and the standard extension mechanism 59 to allow definition of further standard elements. The opposite 60 problem, i.e. to allow a traditional numeric-only GSTN device user to 61 access the e-mail transport service, is not discussed here. 63 This IANA registration templates which MUST be used to register any 64 standard element defined according to this specification are given in 65 the "IANA Considerations" chapter (section 7 of this document). 67 All implementations supporting this GSTN over e-mail service MUST 68 support as a minimum the specification described in this document. 69 The generic complex case of converting the whole GSTN addressing into 70 e-mail is out of scope in this minimal specification: there is some 71 work in progress in the field, where also a number of optional 72 standard extensions are being defined. 74 1.1 Terminology and Syntax conventions 76 In this document the formal definitions are described using ABNF 77 syntax, as defined into [7]. This memo also uses some of the "CORE 78 DEFINITIONS" defined in "APPENDIX A - CORE" of that document. The 79 exact meaning of the capitalised words 81 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 82 "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" 84 is defined in reference [6]. 86 In this document the following new terms are also defined: 88 I-pstn device: 89 a device which has an Internet domain name and it is able to 90 communicate either directly or indirectly with the GSTN network; 92 mta-I-pstn: 93 the Internet domain name which identifies uniquely an I-pstn 94 device over the Internet; 96 pstn-email: 97 the complete Internet e-mail address structure which is used to 98 transport a GSTN address over the Internet e-mail service. 100 2. Minimal GSTN address 102 The minimal specification of a GSTN address within an e-mail address is 103 as follows: 105 pstn-address = pstn-mbox [ qualif-type1 ] 107 pstn-mbox = service-selector "=" global-phone 109 service-selector = 1*( DIGIT / ALPHA / "-" ) 110 ; note that SP (space) is not allowed in 111 ; service-selector. 112 ; service-selector MUST be handled as a case 113 ; INSENSITIVE string by implementations. 115 Other specifications adopting the "pstn-address" definition MUST define 116 and register with IANA a unique case insensitive "service-selector" 117 element to identify the specific messaging service involved. 119 These specifications and registrations MUST also define which minimal 120 "qualif-type1" extensions, if any, MUST be supported for the specified 121 messanging service. 123 Implementations confirming to this minimal requirements specification 124 are allowed to ignore any other non-minimal extensions address element 125 which is present in the "pstn-address". However, conforming 126 implementations MUST preserve all "qualif-type1" address elements 127 they receive. 129 The generic "qualif-type1" element is defined as: 131 qualif-type1 = "/" keyword "=" string 133 keyword = 1*( DIGIT / ALPHA / "-" ) 134 ; note that SP (space) is not allowed in keyword 136 string = PCHAR 137 ; note that printable characters are %x20-7E 139 As such, all "pstn-address" extension elements MUST be defined in 140 the "qualif-type1" form at the time of registration with IANA. 142 2.1 Minimal "global-phone" definition 144 The purpouse of global-phone element is to represent standard E.164 145 numeric addresses [10] within a syntax for electronic mail addressing 146 that is compliant with standard e-mail specifications given in [1] 147 and [2]. 149 The minimal supported syntax for global-phone element is as follows: 151 global-phone = "+" 1*( DIGIT / written-sep ) 153 written-sep = ( "-" / "." ) 155 The use of other dialling schemes for GSTN numbers (like private 156 numbering plans or local dialling conventions) is also allowed. 157 However, this does not preclude nor remove the mandatory requirement 158 for support to the "global-phone" syntax within minimal GSTN address 159 format. 161 Any other dialling schemes MUST NOT use the leading "+" defined here 162 between the "=" sign and the dialling string. The "+" sign is 163 strictly reserved for the standard "global-phone" syntax. 165 Note: 166 The specification of alternate dialling schemas is out of scope 167 for this minimal specification. 169 This document also permit the use of written-sep elements in order to 170 improve human readibility of GSTN e-mail addreses. The written-sep are 171 elements which can be placed between dial elements such as digits 172 etc. 174 Implementors' note: 175 Use of the written-sep elements is allowed, but not recommended 176 for transmission. Any occurences of written-sep elements in a 177 pstn-mbox MUST be ignored by all conformant implementations. User 178 Agents SHOULD remove written-sep elements before submitting messages 179 to the Message Transport System. 181 2.2 The minimal "pstn-address" examples 183 Some examples of minimal pstn-address follows: 185 VOICE=+3940226338 187 FAX=+12027653000/T33S=6377 189 SMS=+33-1-88335215 191 Note: 192 only the use of registered service-selector and qualif-type1 193 elements is allowed. The examples shown are just for illustration 194 purposes. 196 3. The e-mail address of the I-pstn device: mta-I-pstn 198 An "I-pstn device" has, among its characteristics, a unique 199 Internet domain name which identifies it on the Internet. Within 200 Internet mail, this is the Right Hand Side (RHS) part of the 201 address, i.e. the part on the right of the "@" sign. For purpouses 202 of this document we will call this "mta-I-pstn" 204 mta-I-pstn = domain 206 For "domain" strings used in SMTP transmissions, the string MUST 207 conform to the requirements of that standard's 208 specifications [1], [3]. For "domain" strings used in message 209 content headers, the string MUST conform to the requirements of the 210 relevant standards [2], [3]. 212 Note: both in the SMTP envelope and in the message headers, the 213 standards permit the use of "domain names" or "domain literals" 214 in addresses. 216 4. The pstn-email 218 The complete structure used to transfer a minimal GSTN address over 219 the Internet e-mail transport system is called "pstn-email". This 220 object is a an e-mail address which conforms to [2] and [3] 221 "addr-spec" syntax, with structure refinements which allows the 222 GSTN number to be identified. 224 pstn-email = ["/"] pstn-address ["/"] "@" mta-I-pstn 226 Implementors' note: 227 The optional "/" characters can result from translations from 228 other transport gateways (such as some X.400 gateways) which 229 have included the "/" as an optional element. Implementations 230 MUST accept the optional slashes but SHOULD NOT generate them. 231 Gateways are allowed to strip them off when converting to 232 Internet mail addressing. Implementors are reminded that it is 233 essential that "pstn-address" element MUST strictly follow the 234 "quoting rules" spcified in the relevant standards [2], [3]. 236 4.1 Multiple subaddresses 238 There are some instances in GSTN applications where multiple 239 subaddresses are used. On the other hand in e-mail practice 240 a separate and unique e-mail address is always used for each 241 recipient. 243 In the event a particular GSTN service requires multiple 244 subaddresses (in any form defined by the standard specification for 245 that GSTN service) that are associated with the same "pstn-mbox", 246 then the use of multiple "pstn-email" elements is REQUIRED. 248 Implementors' note: 249 The UA may accept multiple subaddress elements for the same 250 global-phone, but it MUST generate multiple "pstn-mbox" elements 251 when submitting the message to the MTA. 253 4.2 Some examples of minimal "pstn-email" addresses 255 Some examples of minimal pstn-email addresses follows: 257 VOICE=+3940226338@worldvoice.com 259 FAX=+1.202.7653000/T33S=6377@faxserv.org 261 /SMS=+33-1-88335215/@telecom.com 263 Note: 264 only the use of registered service-selector and qualif-type1 265 elements is allowed. The examples shown are just for illustration 266 purpouses. 268 5. Conclusions 270 This proposal creates a minimal standard encoding for GSTN addresses 271 within the global e-mail transport system. It also defines the 272 standard extension mechanism to be used to introduce new elements for 273 GSTN addresses. 275 The proposal is consistent with existing e-mail standards. Each 276 specific GSTN service using this proposal MUST define and register 277 with IANA its own "service-selector" specification and MUST define 278 and register the eventual other "qualif-type1" elements needed for 279 its specifical application. An example of such an application is 280 contained in reference [13]. 282 6. Security Considerations 284 This document specifies a means by which GSTN addresses can be 285 encoded into e-mail addresses. Since e-mail routing is determined by 286 Domain Name System (DNS) data, a successful attack to DNS could 287 disseminate tampered information, which causes e-mail messages to be 288 diverted via some MTA or Gateway where the security of the software 289 has been comprimised. 291 There are several means by which an attacker might be able to deliver 292 incorrect mail routing information to a client. These include: (a) 293 compromise of a DNS server, (b) generating a counterfeit response to 294 a client's DNS query, (c) returning incorrect "additional 295 information" in response to an unrelated query. Clients SHOULD ensure 296 that mail routing is based only on authoritative answers. Once DNS 297 Security mechanisms [5] become more widely deployed, clients SHOULD 298 employ those mechanisms to verify the authenticity and integrity of 299 mail routing records. 301 7. IANA Considerations 303 As the service-selector and qualif-type1 elements values are 304 extensible ones, they MUST be registered with IANA. 306 To register a service-selector or a qualif-type1 element, the 307 registration form templates given in 7.1 and 7.2 MUST be used. 308 Any new registration MUST fulfil the "Specification Required" 309 criterium, as defined in RFC 2434, section 2 [16]: 311 "Specification Required - Values and their meaning MUST be 312 documented in an RFC or other permanent and readily available 313 reference, in sufficient detail so that interoperability 314 between independent implementations is possible." 316 IANA MUST NOT accept registrations which are not supplemented by 317 a Specification as defined above and which are not fully specified 318 accoding to the template forms given in 7.1 and 7.2. In case of need 319 for further consultation about accepting a new registration, IANA 320 SHOULD refer to the Application Area Director to be directed to the 321 appropriate "expert" individal or IETF Working Group. 323 After succesful registration, IANA should publish the registered new 324 element in the appropriate on-line IANA WEB site, and include it 325 into the updates of the "Assigned Numbers" RFC series. 327 This section (including 7.1 and 7.2) updates the ones contained in 328 [15]. 330 7.1: IANA Registration form template for new values of GSTN 331 address service-selector 333 To: IANA@isi.edu 334 Subject: Registration of new values for the GSTN address 335 service-selector specifier "foo" 337 service-selector name: 339 foo 341 Description of Use: 343 foo - ("foo" is a fictional new service-selector used in this 344 template as an example, it is to be replaced with the new value 345 being registered. Include a short description of the use of the 346 new value here. This MUST include reference to Standard Track RFCs 347 and eventaully to other Standard Bodies documents for the complete 348 description; the use of the value must be defined completely 349 enough for independent implementation). 351 Security Considerations: 353 (Any additional security considerations that may be introduced by 354 use of the new service-selector parameter should be defined here or 355 in the reference Standards Track RFCs) 357 Person & email address to contact for further information: 359 (fill in contact information) 361 INFORMATION TO THE SUBMITTER: 363 The accepted registrations will be listed in the "Assigned Numbers" 364 series of RFCs. The information in the registration form is freely 365 distributable. 367 7.2: IANA Registration form template for new values of GSTN 368 address qualif-type1 keyword and value 370 To: IANA@isi.edu 371 Subject: Registration of new values for the GSTN address 372 qualif-type1 element "bar" 374 qualif-type1 "keyword" name: 376 bar 378 qualif-type1 "value" ABNF definition: 380 abnf - ("abnf" MUST define the ABNF form of the qualif-type1 value. 381 The ABNF specification MUST be self-contained, using as basic 382 elements the tokens given in specification [4]. To avoid any 383 duplication (when appropriate), it MUST also use any already 384 registered non-basic token from other qualif-type1 elements, 385 i.e. it MUST use the same non-basic token name and then repeat its 386 identical ABNF definition from basic tokens. 388 Description of Use: 390 bar - ("bar" is a fictional description for a new qualif-type1 391 element used in this template as an example. It is to be replaced 392 by the real description of qualif-type1 element being registered. 393 Include a short description of the use of the new qualif-type1 here. 394 This MUST include reference to Standards Track RFCs and eventually 395 to other Standard Bodies documents for the complete description; the 396 use of the value MUST be defined completely enough for independent 397 implementation.) 399 Use Restriction: 401 (If the new qualif-type1 elements is meaningful only for a specific 402 set of service-element, you MUST specify here the list of allowed 403 service-element types. If there is no restriction, then specify the 404 keyword "none") 406 Security Considerations: 408 (Any additional security considerations that may be introduced by 409 use of the new service-selector parameter should be defined here or 410 in the reference Standards Track RFCs) 412 Person & email address to contact for further information: 414 (fill in contact information) 416 INFORMATION TO THE SUBMITTER: 418 The accepted registrations will be listed in the "Assigned Numbers" 419 series of RFCs. The information in the registration form is freely 420 distributable. 422 8. Author's Address 424 Claudio Allocchio 425 INFN-GARR 426 c/o Sincrotrone Trieste 427 SS 14 Km 163.5 Basovizza 428 I 34012 Trieste 429 Italy 431 RFC822: Claudio.Allocchio@elettra.trieste.it 432 X.400: C=it;A=garr;P=Trieste;O=Elettra; 433 S=Allocchio;G=Claudio; 434 Phone: +39 040 3758523 435 Fax: +39 040 3758565 437 9. References 439 [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 440 August 1982. --> DRUMS? 442 [2] Crocker, D., " Standard for the format of ARPA Internet text 443 messages", STD 11, RFC 822, August 1982. --> DRUMS? 445 [3] Braden, R., "Requirements for Internet hosts - application and 446 support", RFC 1123, October 1989. 448 [4] Malamud, C. and M. Rose, "Principles of Operation for the 449 TPC.INT Subdomain: Remote Printing -- Technical Procedures", RFC 450 1528, October 1993. 452 [5] Eastlake, D. and C. Kaufman, "Domain Name System Security 453 Extensions", RFC 2065, January 1997. 455 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 456 Levels", RFC 2119, March 1997. 458 [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax 459 Specifications", RFC 2234, November 1997. 461 [8] ITU F.401 - Message Handling Services: Naming and Addressing for 462 Public Message Handling Service; recommendation F.401 (August 463 1992) 465 [9] ITU F.423 - Message Handling Services: Intercommunication 466 Between the Interpersonal Messaging Service and the Telefax 467 Service; recommendation F.423 (August 1992) 469 [10] ITU E.164 - The International Public Telecommunication Numbering 470 Plan E.164/I.331 (May 1997) 472 [11] ITU T.33 - Facsimile routing utilizing the subaddress; 473 recommendation T.33 (July, 1996) 475 [12] ETSI I-ETS 300,380 - Universal Personal Telecommunication 476 (UPT): Access Devices Dual Tone Multi Frequency (DTMF) sender 477 for acoustical coupling to the microphone of a handset telephone 478 (March 1995) 480 [13] Allocchio, C., "Minimal FAX address format in Internet Mail", 481 RFC 2304 bis, xxxxx 1999. 483 [14] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping 484 between X.400 and RFC 822/MIME", RFC 2156, January 1998. 486 [15] Allocchio, C. "GSTN address element extensions in e-mail 487 services", RFC xxxx, xxxxxxx 1999. 489 [16] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA 490 Considerations Section in RFCs", RFC 2434, October 1998. 492 10. Full Copyright Statement 494 Copyright (C) The Internet Society (1999). All Rights Reserved. 496 This document and translations of it may be copied and furnished to 497 others, and derivative works that comment on or otherwise explain it 498 or assist in its implementation may be prepared, copied, published 499 and distributed, in whole or in part, without restriction of any 500 kind, provided that the above copyright notice and this paragraph are 501 included on all such copies and derivative works. However, this 502 document itself may not be modified in any way, such as by removing 503 the copyright notice or references to the Internet Society or other 504 Internet organizations, except as needed for the purpose of 505 developing Internet standards in which case the procedures for 506 copyrights defined in the Internet Standards process must be 507 followed, or as required to translate it into languages other than 508 English. 510 The limited permissions granted above are perpetual and will not be 511 revoked by the Internet Society or its successors or assigns. 513 This document and the information contained herein is provided on an 514 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 515 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 516 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 517 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 518 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.