idnits 2.17.1 draft-burger-sipping-kpml-00.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 3) being 59 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (October 28, 2002) is 7850 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) -- Missing reference section? '1' on line 14 looks like a reference -- Missing reference section? '2' on line 69 looks like a reference -- Missing reference section? '3' on line 320 looks like a reference -- Missing reference section? '4' on line 78 looks like a reference -- Missing reference section? '5' on line 97 looks like a reference -- Missing reference section? '6' on line 98 looks like a reference -- Missing reference section? '7' on line 118 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Work Group E. Burger 3 Internet Draft SnowShore Networks, Inc. 4 Document: draft-burger-sipping-kpml-00.txt 5 Category: Standards Track 6 Expires: April 28, 2002 October 28, 2002 8 Keypad Markup Language (KPML) 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. Internet-Drafts are draft documents valid for a maximum of 19 six months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 Keypad Markup Language (KPML) is a markup language used in 33 conjunction with SIP and HTTP to provide instructions to SIP User 34 Agents for the reporting of user digit presses. Note that this 35 document specifies a hypothetical language that has no 36 implementations. 38 Burger Draft - Expires 4/2002 1 39 KPML October 27, 2002 41 Table of Contents 43 1. Conventions used in this document..................................2 44 2. Introduction.......................................................2 45 3. Overview...........................................................3 46 4. Examples...........................................................4 47 4.1. Monitoring for Octothorpe........................................4 48 4.2. Interactive Digit Collection.....................................5 49 4.3. VoiceXML Digit Collection........................................6 50 5. Formal Syntax......................................................7 51 6. Security Considerations............................................7 52 7. References.........................................................7 53 8. Contributors.......................................................8 54 9. Acknowledgments....................................................8 55 10. Author's Address..................................................9 57 1. Conventions used in this document 59 In the narrative discussion, the "device" is a User Agent that will 60 report stimulus. An "endpoint" is the system requesting a device to 61 report stimulus. The "user" is an entity that stimulates the device 62 to report the stimulus. In English, the device is a phone, the 63 endpoint is an application server, and the user presses keys to 64 generate stimulus. 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 68 this document are to be interpreted as described in RFC-2119 [2]. 70 2. Introduction 72 This document describes the Keypad Markup Language, KPML. KPML is a 73 markup [3] that enables "dumb phones" to report on basic user key- 74 press interactions. 76 This document refers to a "dumb phone" as a device that does not 77 have a display. Otherwise, it is actually a rather smart device. 78 KPML requires the device to be an http [4] client and interpret KPML 79 markup. 81 The name of the markup, KPML, reflects its legacy support role. The 82 public switched telephony network (PSTN) accomplished end-to-end 83 signaling by transporting Dual-Tone, Multi-Frequency (DTMF) tones in 84 the bearer channel. This is in-band signaling. 86 From the point of view of an endpoint being signaled, what is 87 important is the fact of the stimulus, not the tones used to 88 transport the stimulus. For example, an application may ask the 89 caller to press the "1" key. What the application cares about is 91 Burger Draft - Expires 4/2003 2 92 KPML October 27, 2002 94 the key press, not that there were two cosine waves at 697 Hz and 95 1209 Hz transmitted. 97 In a SIP-signaled [5] network, the preferred method of transporting 98 end-to-end signaling is RFC 2833 [6]. In RFC 2833, the signaling 99 endpoint inserts RFC 2833 signal packets instead of generating the 100 tones. The receiving endpoint gets the tone information, which is 101 what it wanted in the first place. 103 RFC 2833 is the "correct" answer for end-to-end signaling. It is 104 the only method that can correlate the time the end user pressed a 105 digit with the user's media. However, for various reasons, people 106 request an out-of-band signaling method. 108 An interested endpoint could request notifications of every key 109 press. However, many of the use cases for such signaling has the 110 endpoint interested in only one or a few keystrokes. Thus we need a 111 mechanism for specifying to the device what stimulus the endpoint 112 would like notification of. 114 3. Overview 116 KPML is a stateless, declarative markup. A KPML document contains a 117 tag with a series of tags. The tag has a 118 value attribute which is a RFC 3015 (H.248) [7] digit map. 120 NOTE: We use Megaco digit maps instead of MGCP digit 121 maps because the former is an IETF standard, while the 122 latter is proprietary. If we have to play by the rules, 123 we'll play by all of the rules. 125 For HTTP reporting, each tag in the markup has an href 126 attribute. When the user enters keypress(es) that match a 127 tag, the device will issue a http POST to the URI specified by the 128 href. The body of the POST is a report of the actual digits 129 entered. This is so the device can indicated what digit string 130 matched a pattern with wildcards. 132 It is possible that the page returned by the http POST is another 133 KPML document. In this situation, the device needs to decide what 134 to do with user key presses collected between the time the device 135 posted the last result and the fetch and interpretation of the next 136 KPML document. 138 For many applications, the device needs to quarantine (buffer) those 139 digits. Some applications use modal interfaces where the first few 140 key presses determine what the following digits mean. For a novice 141 user, the endpoint may play a prompt describing what mode the 142 application is in. However, "power users" often barge through the 143 prompt. 145 Burger Draft - Expires 4/2003 3 146 KPML October 27, 2002 148 KPML provides a barge attribute to the tag. The default 149 is "barge=yes". Enabling barge means that the device buffers digits 150 and applies them immediately when the next KPML document arrives. 151 Disabling barge by specifying "barge=no" means the device flushes 152 any collected digits before collecting more digits and comparing 153 them against the tags. 155 If the user presses a key not matched by the tags, the 156 device discards the key press from consideration against the current 157 or future KPML documents. However, as described above, once there 158 is a match, the device quarantines any keys the user enters 159 subsequent to the match. 161 Because it is not possible to know if the signaled digits may be for 162 the far end, the device transmits the digits to the far end in real 163 time, using either RFC 2833 or by generating the appropriate tones. 165 NOTE: If KPML did not have this behavior, then a device 166 executing KPML could easily break called applications. 167 For example, take a personal assistant that uses "*9" 168 for attention. If the user presses the "*" key, KPML 169 will hold the digit, looking for the "9". What if the 170 user just enters a "*" key, possibly because they 171 accessed an IVR system that looks for "*"? In this 172 case, the "*" would get held by the device, because it 173 is looking for the "*9" pattern. The user would 174 probably press the "*" key again, hoping that the called 175 IVR system just didn't hear the key press. At that 176 point, the device would send both "*" entries, as "**" 177 does not match "*9". However, that would not have the 178 effect the user intended when they pressed "*". 180 4. Examples 182 4.1. Monitoring for Octothorpe 184 A common need for pre-paid and personal assistant applications is to 185 monitor a conversation for a signal indicating a change in user 186 focus from the party they called through the application to the 187 application itself. For example, if you call a party using a pre- 188 paid calling card and the party you call redirects you to voice 189 mail, digits you press are for the voice mail system. However, many 190 applications have a special key sequence, such as the octothorpe (#, 191 or pound sign) or *9 that terminate the called party leg and shift 192 the user's focus to the application. 194 Figure 1 shows the KPML for long octothorpe. 196 Burger Draft - Expires 4/2003 4 197 KPML October 27, 2002 199 200 201 202 205 206 208 Figure 1 - Long Octothorpe Example 210 In this example, the parameter "session=19fsjcalksd" associates the 211 http POST with the SIP call session. One can use other methods to 212 associate the POST with a SIP call. The following examples will 213 show these various methods. 215 The regex value Z indicates the following digit needs to be a long- 216 duration key press. F, from the H.248 DTMF package, is the 217 octothorpe key. 219 4.2. Interactive Digit Collection 221 In this example, an application endpoint requests the device to send 222 the user's signaling directly to the platform in HTTP, rather than 223 monitoring the entire RTP stream. Figure 2 shows a voice mail menu, 224 where presumably the endpoint played a "Press K to keep the message, 225 R to replay the message, and D to delete the message" prompt. 227 228 229 230 232 234 236 237 239 Figure 2 - IVR KPML Example 241 The target of the http post, "sess$9aej08asd7", identifies the SIP 242 session. 244 NOTE: It is unclear if this usage of KPML is better than 245 using a device control protocol like H.248. From the 246 application's point of view, it has to do the low-level 247 prompt-collect logic. Granted, it is relatively easy to 248 change the key mappings for a given menu. However, 250 Burger Draft - Expires 4/2003 5 251 KPML October 27, 2002 253 often more of the call flow than a given menu mapping 254 gets changed. 256 4.3. VoiceXML Digit Collection 258 One could imagine a VoiceXML platform that wants to have the device 259 signal the user's key presses, while the VoiceXML platform still 260 streams prompts to the device. Of course, by definition, the 261 VoiceXML platform receives all of the device's media. This is 262 because the user hears prompts from the VoiceXML platform and the 263 platform hears all of the user's utterances (e.g., for recording a 264 message). 266 However, let us say that the VoiceXML platform would like to receive 267 the stimulus in http, rather than in RFC 2833. KPML can do this, as 268 the following example shows. 270 NOTE: Clearly I don't believe this is a useful use case. 271 In particular, there is no way to indicate whether a 272 future prompt is non-bargeable. 274 In this example, a VoiceXML script builds a menu. The VoiceXML 275 interpreter has pulls out a grammar definition similar to the 276 following. 278 279 280 281 For sports press 1, For weather press 2, For Stargazer 282 astrophysics press 3. To speak to a person press 0. 283 284 286 288 290 292 294 Figure 3 - VoiceXML Code 296 Burger Draft - Expires 4/2003 6 297 KPML October 27, 2002 299 300 301 302 304 306 308 310 311 313 Figure 4 - VoiceXML KPML Example 314 Note the targets of the href's are opaque strings that have meaning 315 only to the VoiceXML platform. 317 5. Formal Syntax 319 The following syntax specification uses the augmented Data Type 320 Definition (DTD) as described in XML [3]. 322 323 325 326 328 329 333 6. Security Considerations 335 KPML presents no further security issues beyond the startup issues 336 addressed in the companion documents to this document. 338 7. References 340 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 341 9, RFC 2026, October 1996. 342 INFORMATIVE 344 Burger Draft - Expires 4/2003 7 345 KPML October 27, 2002 347 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 348 Levels", BCP 14, RFC 2119, March 1997. 349 NORMATIVE 351 3 Bray, T. et. al., "Extensible Markup Language (XML) 1.0 (Second 352 Edition)", W3C Recommendation, http://www.w3.org/TR/REC-xml, 353 October 2000. 354 NORMATIVE 356 4 Fielding, R. et. al., "Hypertext Transfer Protocol -- HTTP/1.1", 357 RFC 2616, June 1999. 358 INFORMATIVE 360 5 Rosenberg, J. et. al., "SIP: Session Initiation Protocol", RFC 361 3261, June 2002. 362 INFORMATIVE 364 6 Schulzrinne, H. and Petrack, S., "RTP Payload for DTMF Digits, 365 Telephony Tones and Telephony Signals", RFC 2833, May 2000. 366 INFORMATIVE 368 7 Cuervo, F. et. al., "Megaco Protocol Version 1.0", RFC 3015, 369 November 2000. 370 NORMATIVE 372 8. Contributors 374 Robert Fairlie-Cuninghame, Cullen Jennings, Jonathan Rosenberg, and 375 I were the members of the Application Stimulus Signaling Design 376 Team. All members of the team contributed significantly to this 377 work. In addition, Jonathan Rosenberg postulated DML in his "A 378 Framework for Stimulus Signaling in SIP Using Markup" draft. 380 This version of KPML has significant influence from MSCML, the 381 SnowShore Media Server Control Markup Language. Jeff Van Dyke, Andy 382 Spitzer, and Walter O'Connor were the primary contributors to that 383 effort. 385 That said, any errors, misinterpretation, or fouls in this document 386 are my own. 388 9. Acknowledgments 390 Burger Draft - Expires 4/2003 8 391 KPML October 27, 2002 393 10. Author's Address 395 Eric Burger 396 SnowShore Networks, Inc. 397 285 Billerica Rd. 398 Chelmsford, MA 01824-4120 399 USA 401 E-mail: eburger@snowshore.com 402 Phone: +1 978/367-8400 404 Burger Draft - Expires 4/2003 9 405 KPML October 27, 2002 407 Full Copyright Statement 409 Copyright (C) The Internet Society (2002). All Rights Reserved. 411 This document and translations of it may be copied and furnished to 412 others, and derivative works that comment on or otherwise explain it 413 or assist in its implementation may be prepared, copied, published 414 and distributed, in whole or in part, without restriction of any 415 kind, provided that the above copyright notice and this paragraph 416 are included on all such copies and derivative works. However, this 417 document itself may not be modified in any way, such as by removing 418 the copyright notice or references to the Internet Society or other 419 Internet organizations, except as needed for the purpose of 420 developing Internet standards in which case the procedures for 421 copyrights defined in the Internet Standards process must be 422 followed, or as required to translate it into languages other than 423 English. 425 The limited permissions granted above are perpetual and will not be 426 revoked by the Internet Society or its successors or assigns. This 427 document and the information contained herein is provided on an "AS 428 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 429 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 430 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 431 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 432 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 434 Acknowledgement 436 The Internet Society currently provides funding for the RFC Editor 437 function. 439 SnowShore Networks, Inc. is a member of the Internet Society. 441 Burger Draft - Expires 4/2003 10