idnits 2.17.1 draft-rosen-iptel-dialstring-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 191. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 168. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 175. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 181. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 130 has weird spacing: '...details or se...' -- 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 (February 2005) is 7009 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: 'RFC3261' is defined on line 140, but no explicit reference was found in the text Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 iptel B. Rosen 3 Internet-Draft NeuStar 4 Expires: August 5, 2005 February 2005 6 Dialstring parameter for the sip URI 7 draft-rosen-iptel-dialstring-02.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 5, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 RFC3966 explicitly states that tel uris may not represent a dial 41 string. That leaves no way specify a dialstring in a standardized 42 way. Great confusion exists with the SIP URI parameter "user=phone", 43 and specifically, if it can represent a dial string. This memo 44 creates a new value for the user parameter "dialstring", so that one 45 may specify "user=dialstring" to encode a dialstring as a SIP URI. 47 Table of Contents 49 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 50 2. Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 54 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 5 56 Intellectual Property and Copyright Statements . . . . . . . . 6 58 1. Requirements notation 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in [RFC2119]. 64 2. Problem 66 A user at a phone often has a limited User Interface, and in some 67 cases, is limited to a 10 key pad (and sometimes a "flash" function 68 with the switchhook). One enters a series of digits that invoke some 69 kind of function. The entered sequence, called a "dialstring" might 70 be translated to a telephone number, or it may invoke a special 71 service. In many newer designs, the mapping between a dialstring and 72 a phone number or service URI is contained within the phone 73 (digitmap). However, there are many phones and terminal adapters 74 that do not have internal translation mechanisms. Without a 75 translation mechanism in the phone, the phone must send the 76 dialstring to an intermediary that can transform the dialstring to a 77 phone number or a service invocation. 79 At some point, a dialstring is translated to a phone number. After 80 that point, it is no longer a dialstring. However, there is no 81 current way for any entity to determine if translation has already 82 been accomplished. 84 Use of DTMF detectors post dial is not uncommon. A common functions 85 some systems have is to express a string that incorporates fixed time 86 delays, or in some cases, actual "wait for call completion" after 87 which additional DTMF signals are emitted. For example, many 88 voicemail systems use a common phone number, after which the system 89 expects the desired mailbox number as DTMF to deposit a message for. 90 Many gateways have the ability to interpret such strings, but there 91 is no standardized way to express them, leading to interoperability 92 problems between endpoints. 94 3. Requirements 96 A mechanism to express a dialstring is required. A dialstring 97 consists of a sequence of 98 * The digits 0-9 99 * The special characters # and * 100 * The MF digits A-D 102 A dialstring always exists within a context. The context MUST be 103 specified when expressing a dialstring. 105 It MUST be possible to distinguish between a dialstring and a phone 106 number. 108 It MUST be possible to express a short pause, and a "Wait for call 109 completion" in a dialstring. 111 4. Solution 113 A new value for the user parameter is defined, "dialstring". This 114 value may be used in a sip or sips URI when the userpart is a 115 dialstring. The userpart is a sequence of the characters 0-9, A-F, P 116 and X. E is represent *, F represents #, P is a pause (short wait, 117 like a comma in a modem string) and X represents call completion. 119 When the "user=dialstring" is used, a context parameter as defined in 120 [RFC3966] MUST be specified. 122 A proxy server or B2BUA which is authoratative for the context may 123 translate the dialstring to a telephone number or service invocation 124 URI. If such a translation is performed, the proxy server MUST 125 change the URI to specify user=phone. 127 5. Security Considerations 129 Dialstrings exposed to the Internet may reveal information about 130 internal network details or service invocations that could allow 131 attackers to use the PSTN or the Internet to attack such internal 132 systems. Dialstrings normally should not be sent over the open 133 Internet without some kind of protection against eavesdropping. 135 6. References 137 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 138 Requirement Levels", BCP 14, RFC 2119, March 1997. 140 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 141 A., Peterson, J., Sparks, R., Handley, M., and E. 142 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 143 June 2002. 145 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 146 RFC 3966, December 2004. 148 Author's Address 150 Brian Rosen 151 NeuStar 152 470 Conrad Dr 153 Mars, PA 16046 154 US 156 Phone: +1 724 382 1051 157 Email: br@brianrosen.net 159 Intellectual Property Statement 161 The IETF takes no position regarding the validity or scope of any 162 Intellectual Property Rights or other rights that might be claimed to 163 pertain to the implementation or use of the technology described in 164 this document or the extent to which any license under such rights 165 might or might not be available; nor does it represent that it has 166 made any independent effort to identify any such rights. Information 167 on the procedures with respect to rights in RFC documents can be 168 found in BCP 78 and BCP 79. 170 Copies of IPR disclosures made to the IETF Secretariat and any 171 assurances of licenses to be made available, or the result of an 172 attempt made to obtain a general license or permission for the use of 173 such proprietary rights by implementers or users of this 174 specification can be obtained from the IETF on-line IPR repository at 175 http://www.ietf.org/ipr. 177 The IETF invites any interested party to bring to its attention any 178 copyrights, patents or patent applications, or other proprietary 179 rights that may cover technology that may be required to implement 180 this standard. Please address the information to the IETF at 181 ietf-ipr@ietf.org. 183 Disclaimer of Validity 185 This document and the information contained herein are provided on an 186 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 187 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 188 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 189 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 190 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 191 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 193 Copyright Statement 195 Copyright (C) The Internet Society (2005). This document is subject 196 to the rights, licenses and restrictions contained in BCP 78, and 197 except as set forth therein, the authors retain all their rights. 199 Acknowledgment 201 Funding for the RFC Editor function is currently provided by the 202 Internet Society.