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