idnits 2.17.1 draft-allocchio-gstn-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 435 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (November 2001) is 8199 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2806 (ref. '6') (Obsoleted by RFC 3966) ** Obsolete normative reference: RFC 2234 (ref. '7') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 5 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 November 2001 4 Expires: May 2002 5 File: draft-allocchio-gstn-01.txt 7 Text string notation for Dial Sequences and GSTN / E.164 addresses 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 (2001). All Rights Reserved. 33 Abstract 35 This memo describes the full set of notations needed to represent 36 in a text string a Dial Sequence. A Dial Sequence is normally 37 composed by Dual Tone Multi Frequency (DTMF) elements [1] plus 38 separators and the additional "actions" (such as "wait for 39 dialtone", "pause for N secs", etc.) which could be needed to 40 successfully establish the connection with the target service: 41 this includes the cases where subaddresses or DTMF menu navigation 42 apply. Global Switched Telephone Numbers (GSTN) / E.164 addresses 43 (commonly called "telephone numbers") [2] are a subset of a Dial 44 Sequence, and thus use the same set of notations. 46 This notation MUST be used in all specifications needing a text 47 string representation of a Dial Sequence (including GSTN / E.164 48 addresses). 50 1. Introduction 52 Since the very first devices interacting with GSTN services appeared, 53 a need for a unique text string representation of telephone numbers, 54 and more generally DTMF sequences and actions, was forseen. 56 This memo describes the full text string representation method. The 57 main scope is thus to provide a unique and complete reference for all 58 specification needing this representation. 60 Compatibility with existing Standard Track specifications (such as 61 [3] [4] [5] [6]) is also one of the most important issues in this 62 specification. 64 1.1 Terminology and Syntax conventions 66 In this document the formal definitions are described using ABNF 67 syntax, as defined into [7]. This memo also uses some of the "CORE 68 DEFINITIONS" defined in "APPENDIX A - CORE" of that document. The 69 exact meaning of the capitalised words 71 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 72 "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" 74 is defined in reference [8]. 76 In this document the following terms are also defined: 78 Dial Sequence: 79 a series of DTMF elements and human or device "actions"; 81 phone-string: 82 a text representation of a Dial Sequence; 84 gstn-phone: 85 a text representation of a GSTN address (which includes 86 the E.164 addresses); 88 subaddr-string: 89 a text representation of a GSTN subaddress (which includes 90 ISDN subaddresses [2] and T.33 subaddresses [9]); 92 post-dial: 93 a text representation of a post dialling sequence. 95 2. The "Dial Sequence" definition 97 The possible elements composing a Dial Sequence can vary from a 98 minimum number up to a really large and complex collection: in 99 fact, already the sequences needed to dial a GSTN address, which is 100 a subset of the generic Dial Sequence, well represents this variety 101 and complexity of cases. 103 In particular, a Dial Sequence is composed by: 105 - "DTMF elelments": normally available as "keys" on numeric keypads 106 of dialling devices; 108 - "actions": normally performed by the agent (human or device) 109 composing the Dial Sequence; 111 - "separators": used only to improve human readibility of a Dial 112 Sequence. 114 2.1 The "phone-string" definition 116 The text representation of the Dial Sequence elements is defined 117 into the phone-string specification: 119 phone-string = 1*( DTMF / pause / tonewait / written-sep ) 121 DTMF = ( DIGIT / "#" / "*" / "A" / "B" / "C" / "D" ) 122 ; special DTMF codes like "*", "#", "A", "B", 123 ; "C", "D" are defined in [1]. 124 ; Important Note: these elements only apply for 125 ; alphabetic strings used in DTMF operations. 126 ; They are NOT applicable for the alphabetic 127 ; characters that are mapped to digits on phone 128 ; keypads in some countries. 130 pause = "p" 132 tonewait = "w" 134 written-sep = ( "-" / "." ) 136 Note: 137 DTMF are the "DTMF elements", pause and tonewait are the "actions" 138 and written-sep is the "separators". 140 The "pause" and "tonewait" elements interpretation in phone-string 141 depends on the specific devices and implementation using the 142 specification. Thus their exact meaning is not defined here. 143 Both "pause" and "tonewait" are case insensitive. 145 The use of written-sep elements is allowed in order to improve 146 human readibility of phone-string. The written-sep are elements 147 which can be placed between dial elements such as digits etc. 148 Any occurences of written-sep elements in a phone-string MUST NOT 149 result in any action. Conformant implementations MAY drop or 150 insert written-sep into the phone-string they handle. 152 The phone-string definition is used in the following sections to 153 explicitly describe the encoding of some specific subcases where 154 it applies. 156 3. The "gstn-phone" definition 158 In order to access a GSTN address, a human or a device must perform 159 a Dial Sequence. Thus also a GSTN address can be represented using 160 the phone-string elements. In particual, standard E.164 numeric 161 addresses [2] represent a limited subset of all possible GSTN 162 addresses, while the complete complex case needs a full encoding 163 schema. 165 In order to describe this distinction and provide anyhow a complete 166 encoding schema, the following definition of "gstn-phone" is provided: 168 gstn-phone = ( global-phone / local-phone ) 170 3.1 The "global-phone" definition 172 The purpose of global-phone element is to represent standard E.164 173 numeric addresses. As such it uses a subset of phone-string 174 definition, only. 176 The syntax for global-phone element is as follows: 178 global-phone = "+" 1*( DIGIT / written-sep ) 180 Any other dialling schemes MUST NOT use the leading "+" defined here. 181 The "+" sign is strictly reserved for the standard "global-phone" 182 syntax, and, even if not specifically part of phone-string definition, 183 is needed to label uniquely a global-phone. 185 3.2 The "local-phone" definition 187 The local-phone element is intended to represent the set of possible 188 cases where the global-phone numbering schema does not apply. Given 189 the different and complex conventions currently being used in the 190 GSTN system, the local-phone definition supports a large number of 191 elements. 193 The detailed syntax for local-phone elements follows: 195 local-phone = [ exit-code ] dial-number 197 local-phone =/ exit-code [ dial-number ] 199 exit-code = phone-string 200 ; this will include elements such as the digit to 201 ; access outside line, the long distance carrier 202 ; access code, the access password to the service, 203 ; etc... 205 dial-number = phone-string 206 ; this is in many cases composed of different elements 207 ; such as the local phone number, the area code 208 ; (if needed), the international country code 209 ; (if needed), etc... 211 Notes: 212 the "+" character is reserved for use in global-phone and MUST NOT 213 be used in a local-phone string; 215 please note that a local-phone string MUST NOT be a null string, 216 i.e. at least an exit-code, or a dial-number or both MUST be 217 present. 219 4. The "subaddr-string" definition 221 In GSTN service there are cases where a subaddress is required to 222 specify the final destination. To specify these subaddresses a Dial 223 Sequence is also used, and thus the "subaddr-string" can be encoded 224 as: 226 subaddr-string = phone-string 228 Note: 229 within actual uses of subaddresses, some specific services can 230 limit the possible set of phone-string elements allowed. In 231 particular there are ISDN subaddresses [2] [5], which restrict the 232 phone-string elements to 1*( DIGIT / written-sep ) and service 233 specific subaddresses, like the fax service T.33 subaddress [9] 234 [4] which restrict phone-string elements to 1*( DIGIT ). 236 5. The "post-dial" definition 238 In some cases, after the connection with the destination GSTN device 239 has been established, a further dialling sequence is required to 240 access further services. A typical example is an automated menu- 241 driven service using DTMF sequences. These cases may be represented 242 using "post-dial" definition below: 244 post-dial = phone-string 246 6. Examples 248 In order to clarify the specification we present here a limited set 249 of examples. Please note that all the examples are for illustration 250 purpouses, only. 252 A GSTN address in Italy, dialled from U.S.A., using local-phone, 253 without written-sep: 255 01139040226338 257 A GSTN address address in Germany, using global-phone and 258 written-sep ".": 260 +49.81.7856345 262 A GSTN address in U.S.A. using global-phone and written-sep "-": 264 +1-202-455-7622 266 A post-dial sequence, pausing, dialling 1, waiting for dial tone, 267 dialling 7005393, waiting again for dial tone and dialling 373; 268 note the use of four "p" elements (pppp) to specify a longer initial 269 pause: 271 pppp1w7005393w373 273 A Dial Sequence in Italy (long distance call), using local-phone, 274 with exit-code "9", long distant access "0", area code "40", 275 pause "p" and written-sep ".": 277 9p040p22.63.38 279 A Dial Sequence using exit-code "0", a wait for dial tone, 280 local-phone for an International "800" toll-free number dialled 281 from Beglium (international prefix "00"), and a post-dial sequence 282 to access a voice mailbox with userID "334422" and Personal 283 Identification Number (PIN) code "1234": 285 0w00800-39380023pp334422p1234 287 7. Conclusions 289 This proposal creates a full standard text encoding for Dial 290 Sequences, including GSTN / E.164 addresses, and thus provides a 291 unique common representation method both for standard protocols 292 and applications. 294 Some definitions, like these corresponding to an alias of the generic 295 phone-string element, are somewhat a theoretical distinction; however 296 they are useful to provide a more subtle distinction, allowing other 297 specifications to be more exact in a consistent way, too. 299 The proposal is consistent with existing standard specifications. 301 8. Security Considerations 303 This document specifies a means to represent Dial Sequences, which 304 thus could include GSTN addresses, and private codes sequences, 305 like Personal Identification Numbers, to access special services. 306 As these text strings could be transmitted without encoding inside 307 protocols or applications services, this could allow unauthorized 308 people to gain access to these codes. Users SHOULD be provided methods 309 to prevent this disclosure, like code encryption, or masquerading 310 techniques: out-of-band communication of authorization information or 311 use of encrypted data in special fields are the available non-standard 312 techniques. 314 9. Collected ABNF Syntax 316 In this section we provide a summary of ABNF specifications. 318 phone-string = 1*( DTMF / pause / tonewait / written-sep ) 320 DTMF = ( DIGIT / "#" / "*" / "A" / "B" / "C" / "D" ) 322 written-sep = ( "-" / "." ) 324 pause = "p" 326 tonewait = "w" 328 gstn-phone = ( global-phone / local-phone ) 330 global-phone = "+" 1*( DIGIT / written-sep ) 332 local-phone = [ exit-code ] dial-number 334 local-phone =/ exit-code [ dial-number ] 336 exit-code = phone-string 338 dial-number = phone-string 340 subaddr-string = phone-string 342 post-dial = phone-string 344 10. Author's Address 346 Claudio Allocchio 347 INFN-GARR 348 c/o Sincrotrone Trieste 349 SS 14 Km 163.5 Basovizza 350 I 34012 Trieste 351 Italy 353 RFC2822: Claudio.Allocchio@garr.it 354 X.400: C=it;A=garr;P=garr;S=Allocchio;G=Claudio; 355 Phone: +39 040 3758523 356 Fax: +39 040 3758565 358 11. References 360 [1] ETSI I-ETS 300,380 - Universal Personal Telecommunication 361 (UPT): Access Devices Dual Tone Multi Frequency (DTMF) sender 362 for acoustical coupling to the microphone of a handset telephone 363 (March 1995) 365 [2] ITU E.164 - The International Public Telecommunication Numbering 366 Plan E.164/I.331 (May 1997) 368 [3] Allocchio, C., "Minimal GSTN address format in Internet Mail", 369 RFC 3191, October 2001 371 [4] Allocchio, C., "Minimal FAX address format in Internet Mail", 372 RFC 3192, October 2001 374 [5] Allocchio, C. "GSTN address element extensions in e-mail 375 services", RFC 2846, June 2000. 377 [6] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, 378 April 2000. 380 [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax 381 Specifications", RFC 2234, November 1997. 383 [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement 384 Levels", BCP 14, RFC 2119, March 1997. 386 [9] ITU T.33 - Facsimile routing utilizing the subaddress; 387 recommendation T.33 (July, 1996) 389 12. Full Copyright Statement 391 Copyright (C) The Internet Society (2001). All Rights Reserved. 393 This document and translations of it may be copied and furnished to 394 others, and derivative works that comment on or otherwise explain it 395 or assist in its implementation may be prepared, copied, published 396 and distributed, in whole or in part, without restriction of any 397 kind, provided that the above copyright notice and this paragraph are 398 included on all such copies and derivative works. However, this 399 document itself may not be modified in any way, such as by removing 400 the copyright notice or references to the Internet Society or other 401 Internet organizations, except as needed for the purpose of 402 developing Internet standards in which case the procedures for 403 copyrights defined in the Internet Standards process must be 404 followed, or as required to translate it into languages other than 405 English. 407 The limited permissions granted above are perpetual and will not be 408 revoked by the Internet Society or its successors or assigns. 410 This document and the information contained herein is provided on an 411 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 412 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 413 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 414 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 415 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.