idnits 2.17.1 draft-burger-sipping-kpml-02.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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 68 instances of lines with control characters in the document. 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 (June 30, 2003) is 7605 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: '15' is defined on line 716, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (ref. '2') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3525 (ref. '4') (Obsoleted by RFC 5125) -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 3023 (ref. '6') (Obsoleted by RFC 7303) == Outdated reference: A later version (-09) exists of draft-vandyke-mscml-00 -- Obsolete informational reference (is this intentional?): RFC 2833 (ref. '10') (Obsoleted by RFC 4733, RFC 4734) -- Obsolete informational reference (is this intentional?): RFC 1889 (ref. '15') (Obsoleted by RFC 3550) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING E. Burger 3 Internet-Draft SnowShore Networks, Inc. 4 Expires: December 29, 2003 June 30, 2003 6 Keypad Markup Language (KPML) 7 draft-burger-sipping-kpml-02 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 other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 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 This Internet-Draft will expire on December 29, 2003. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 Keypad Markup Language (KPML) is a markup language used in 38 conjunction with SIP and HTTP to provide instructions to SIP User 39 Agents for the reporting of user key presses. 41 Conventions used in this document 43 RFC2119 [1] provides the interpretations for the key words "MUST", 44 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 45 "RECOMMENDED", "MAY", and "OPTIONAL" found in this document. 47 In the narrative discussion, the "user device" is a User Agent that 48 will report stimulus. An "application" is a User Agent requesting 49 the user device to report stimulus. The "user" is an entity that 50 stimulates the user device. In English, the user device is a phone, 51 the application is an application server or proxy server, and the 52 user presses keys to generate stimulus. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. KPML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Digit Suppression . . . . . . . . . . . . . . . . . . . . . 7 59 4. HTTP Reporting . . . . . . . . . . . . . . . . . . . . . . . 9 60 5. SIP Reporting . . . . . . . . . . . . . . . . . . . . . . . 10 61 6. Mixing HTTP and SIP . . . . . . . . . . . . . . . . . . . . 11 62 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 7.1 Monitoring for Octorhorpe . . . . . . . . . . . . . . . . . 12 64 7.2 Dial String Collection . . . . . . . . . . . . . . . . . . . 12 65 7.3 Interactive Digit Collection . . . . . . . . . . . . . . . . 13 66 7.4 SIP Request . . . . . . . . . . . . . . . . . . . . . . . . 14 67 8. Report Body . . . . . . . . . . . . . . . . . . . . . . . . 15 68 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 16 69 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 70 10.1 IANA Registration of MIME media type application/kpml+xml . 19 71 10.2 Schema Registration . . . . . . . . . . . . . . . . . . . . 19 72 11. Security Considerations . . . . . . . . . . . . . . . . . . 20 73 Normative References . . . . . . . . . . . . . . . . . . . . 21 74 Informative References . . . . . . . . . . . . . . . . . . . 22 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . 22 76 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 77 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 78 Intellectual Property and Copyright Statements . . . . . . . 25 80 1. Introduction 82 This document describes the Keypad Markup Language, KPML. KPML is a 83 markup [7] that enables "dumb phones" to report on basic user 84 key-press interactions. 86 This document refers to a "dumb phone" as a user device that does not 87 have a display. Otherwise, it is actually a rather smart device. 88 Most KPML implementations require the user device to be an http [2] 89 client and interpret KPML markup. 91 We strongly discourage the use of non-validating XML parsers, as one 92 can expect problems with future versions of KPML. That said, one 93 could envision user devices that only accept SIP reporting and have a 94 fixed parser, rather than a full XML parser. This means that KPML 95 can fit in to an extremely small memory and processing footprint. 96 Note KPML has a corresponding lack of functionality. For those 97 applications that require more functionality, please refer to 98 VoiceXML [8] and MSCML [9]. 100 The name of the markup, KPML, reflects its legacy support role. The 101 public switched telephony network (PSTN) accomplished end-to-end 102 signaling by transporting Dual-Tone, Multi-Frequency (DTMF) tones in 103 the bearer channel. This is in-band signaling. 105 NOTE: The spelunking community already took the name KML for their 106 cave data base interchange format. 108 From the point of view of an application being signaled, what is 109 important is the fact the stimulus occurred, not the tones used to 110 transport the stimulus. For example, an application may ask the 111 caller to press the "1" key. What the application cares about is the 112 key press, not that there were two cosine waves at 697 Hz and 1209 Hz 113 transmitted. 115 A SIP-signaled [3] network transports end-to-end signaling with 116 RFC2833 [10] packets. In RFC2833, the signaling application inserts 117 RFC2833 named signal packets instead of generating tones. The 118 receiving application gets the signal information, which is what it 119 wanted in the first place. 121 RFC2833 is the only method that can correlate the time the end user 122 pressed a digit with the user's media. However, out-of-band 123 signaling methods, as are appropriate for user device to application 124 signaling, do not need millisecond accuracy. On the other hand, they 125 do need reliability, which RFC2833 does not provide. 127 An interested application could request notifications of every key 128 press. However, many of the use cases for such signaling has the 129 application interested in only one or a few keystrokes. Thus we need 130 a mechanism for specifying to the user device what stimulus the 131 application would like notification of. 133 2. KPML 135 KPML is a stateless, declarative markup. A KPML document contains a 136 tag with a series of tags. The tag has a 137 value attribute that is a H.248.1 [4] digit map. 139 NOTE: We use RFC3525 digit maps instead of MGCP [11] digit maps 140 because the former is an IETF standard and the latter is not. 142 NOTE: We do not use SRGS [12] DTMF grammars because it is unlikely 143 one would use KPML for independent digit collection in a browser 144 context. 146 Interface attributes, such as the interdigit timeout and what 147 constitutes a long key press, are implementation matters beyond the 148 scope of this document. 150 For many applications, the user device needs to quarantine (buffer) 151 digits. Some applications use modal interfaces where the first few 152 key presses determine what the following digits mean. For a novice 153 user, the application may play a prompt describing what mode the 154 application is in. However, "power users" often barge through the 155 prompt. 157 KPML provides a barge attribute to the tag. The default is 158 "barge=yes". Enabling barge means that the user device buffers 159 digits and applies them immediately when the next KPML document 160 arrives. Disabling barge by specifying "barge=no" means the user 161 device flushes any collected digits before collecting more digits and 162 comparing them against the tags. 164 NOTE: Quarantine and barge are separate actions. However, the 165 barge action directly determines the quarantine action. Thus KPML 166 only specifies the barge action request. 168 If the user presses a key not matched by the tags, the user 169 device discards the key press from consideration against the current 170 or future KPML documents. However, as described above, once there is 171 a match, the user device quarantines any keys the user enters 172 subsequent to the match. 174 KPML documents are independent. Thus it is not possible for the 175 current document to know if a following document will enable barging 176 or want the digits flushed. Therefore, the user device MUST 177 quarantine all digits detected between the time of the report (http 178 POST or SIP NOTIFY) and the interpretation of the next script, if 179 any. If the next script has "barge=no", then the interpreter MUST 180 flush all collected digits. If the next script has "barge=yes", then 181 the interpreter MUST apply the collected digits against the digit 182 maps presented by the script's tags. If there is a match, 183 the interpreter MUST quarantine the remaining digits. If there is no 184 match, the interpreter MUST flush all of the collected digits. 186 Unless there is a suppress indicator in the digit map, it is not 187 possible to know if the signaled digits are for local KPML processing 188 or for other recipients of the media stream. Thus, in the absence of 189 a digit suppression indicator, the user device transmits the digits 190 to the far end in real time, using either RFC2833, generating the 191 appropriate tones, or both. 193 The following section details the operation of the suppress 194 indicator. 196 3. Digit Suppression 198 Under basic operation, a KPML endpoint will transmit in-band tones 199 (RFC2833 [10] or actual tone) in parallel with digit reporting. 201 NOTE: If KPML did not have this behavior, then a user device 202 executing KPML could easily break called applications. For 203 example, take a personal assistant that uses "*9" for attention. 204 If the user presses the "*" key, KPML will hold the digit, looking 205 for the "9". What if the user just enters a "*" key, possibly 206 because they accessed an IVR system that looks for "*"? In this 207 case, the "*" would get held by the user device, because it is 208 looking for the "*9" pattern. The user would probably press the 209 "*" key again, hoping that the called IVR system just did not hear 210 the key press. At that point, the user device would send both "*" 211 entries, as "**" does not match "*9". However, that would not 212 have the effect the user intended when they pressed "*". 214 On the other hand, there are situations where passing through tones 215 in-band is not desirable. Such situations include call centers that 216 use in-band tone spills to effect a transfer. 218 For those situations, KPML adds a digit suppression token to H.248.1 219 [4] digit maps. The digit suppression token is a "Q". There MUST 220 NOT be more than one Q in any given . 222 If there is only a single and a single , the 223 suppression processing is straightforward. The end-point passes 224 digits until the stream matches the regular expression up to the 225 suppression token, Q. At that point, the endpoint will continue 226 collecting digits, but will suppress the generation or pass-through 227 of any in-band digits. 229 If the endpoint suppresses digits, it MUST indicate this by including 230 the attribute "suppressed" with a value of "yes" in the digit report. 232 A KPML endpoint MAY perform digit suppression. If it is not capable 233 of digit suppression, it ignores the digit suppression token and will 234 never send a suppressed indication in the digit report. 236 At some point in time, the endpoint will collect enough digits to the 237 point it hits a suppression marker. The interdigittimer attribute 238 indicates how long to wait once the user enters digits before 239 reporting a time-out error. If the interdigittimer expires, the 240 endpoint MUST issue a time-out report and transmit the suppressed 241 digits on the media stream. 243 After digit suppression begins, it may become clear that a match will 244 not occur. For example, take the regular expression 245 "*8Qxxx[2-9]xxxxxx". At the point the endpoint receives "*8", it 246 will stop forwarding digits. Let us say that the next three digits 247 are "408". If the next digit is a zero or one, the pattern will not 248 match. 250 NOTE: It is critically important for the endpoint to have a 251 sensible inter-digit timer. This is because an errant dot (".") 252 may suppress digit sending forever. 254 Applications should be very careful to indicate suppression only when 255 they are fairly sure the user will enter a digit string that will 256 match the regular expression. In addition, applications should deal 257 with situations such as no-match or time-out. This is because the 258 endpoint will hold digits, which will have obvious user interface 259 issues in the case of a failure. 261 4. HTTP Reporting 263 For HTTP reporting, each tag in the markup has an href 264 attribute. When the user enters keypress(es) that match a 265 tag, the user device issues an http POST to the URI specified by the 266 href. The body of the POST is a report of the actual digits entered. 267 This is so the user device can indicate what digit string matched a 268 pattern with wildcards. 270 If the resulting document returned by the http POST is empty, the 271 user device terminates the KPML session. 273 NOTE: This is different than the behavior for VoiceXML as 274 described in Basic Network Media Services with SIP [13], where an 275 empty document results in the termination of the session. 277 If the KPML document includes "sip:" or "im:" href targets, and the 278 KPML interpreter does not support SIP Reporting, the KPML interpreter 279 MUST reject the document in its entirety at interpretation time with 280 the appropriate SIP error as described in ????. 282 EDITOR'S NOTE: draft-jennings-sip-app-info-00.txt should cover 283 document rejection. It does not right now. KPML does not address 284 document rejection, other than the criteria for rejection. This 285 draft focuses on KPML, not on the initiation mechanism. 287 5. SIP Reporting 289 For SIP reporting, the href attribute of the tag MUST be a 290 SIP compatible scheme, such as "sip:", "sips:", or "im:". When the 291 user enters keypress(es) that match a tag, the user device 292 will issue a SIP MESSAGE to the Request-URI specified by the href 293 attribute. RFC3428 [14] describes the protocol machinery for the 294 MESSAGE method. 296 NOTE: What MESSAGE has over INFO is some sense of congestion 297 control. What MESSAGE has over NOTIFY is there are no implicit 298 subscription issues. 300 A KPML interpreter cannot validate the href URI. See the Security 301 Considerations (Section 11) section. 303 The reason one must specify a sip: scheme, and not simply make 304 href optional, is to catch a HTTP-based script error where one 305 forgets to specify the href tag. If href was optional, then this 306 error would result in the user device generating a SIP NOTIFY, 307 which would not be the desired action. 309 The specification of any scheme-specific part, that is, anything 310 following the colon in "sip:", is an error. The interpreter MUST 311 reject the request. 313 After reporting a SIP , the interpreter terminates the KPML 314 session. To collect more digits, the requestor must issue a 315 re-INVITE on the dialog. 317 NOTE: This highlights the "one shot" nature of KPML, reflecting 318 the balance of features and ease of implementing an interpreter. 319 If your goal is to build an IVR session, we strongly suggest you 320 investigate more appropriate technologies such as VoiceXML [8] or 321 MSCML [9]. 323 If the KPML document includes "http:" href targets, and the KPML 324 interpreter does not support HTTP Reporting, the KPML interpreter 325 MUST reject the document in its entirety at interpretation time with 326 the appropriate SIP error as described in ?????. 328 NOTE: draft-jennings-sip-app-info-00.txt should cover document 329 rejection. It does not right now. This draft should not address 330 document rejection, other than the criteria for rejection. This 331 draft focuses on KPML, not on the initiation mechanism. 333 6. Mixing HTTP and SIP 335 NOTE: So, now that Pandora's Box is open... 337 There is nothing to prevent mixing SIP and HTTP reporting requests in 338 the same KPML document. While this may be a benefit, it has definite 339 drawbacks. 341 The major drawback is that one cannot negotiate SIP-ness or 342 HTTP-ness. As far as the endpoints are concerned it is all KPML. 343 One could use "application/KPML+SIP+XML" and "application/ 344 KPML+HTTP+XML", but that is pretty ugly. 346 7. Examples 348 7.1 Monitoring for Octorhorpe 350 A common need for pre-paid and personal assistant applications is to 351 monitor a conversation for a signal indicating a change in user focus 352 from the party they called through the application to the application 353 itself. For example, if you call a party using a pre-paid calling 354 card and the party you call redirects you to voice mail, digits you 355 press are for the voice mail system. However, many applications have 356 a special key sequence, such as the octothorpe (#, or pound sign) or 357 *9 that terminate the called party leg and shift the user's focus to 358 the application. 360 The following figure shows the KPML for long octothorpe. Note that 361 the href is really on one line, but divided for clarity. 363 364 365 366 367 370 371 372 374 Figure 1 - Long Octothorpe Example 376 In this example, the parameter "session=19fsjcalksd" associates the 377 http POST with the SIP call session. One can use other methods to 378 associate the POST with a SIP call. The following examples will show 379 these various methods. 381 The regex value Z indicates the following digit needs to be a 382 long-duration key press. F, from the H.248.1 DTMF package, is the 383 octothorpe key. In fact, KPML supports all digits, 1-9, *, #, A-D 384 from the H.248 DTMF.1 package. 386 7.2 Dial String Collection 388 In this example, the user device collects a dial string. The 389 application uses KPML to quickly determine when the user enters a 390 target number. In addition, KPML indicates what type of number the 391 user entered. 393 394 395 396 397 436 437 438 439 441 444 446 447 448 450 Figure 5 - IVR KPML Example Code 452 The target of the http post, "sess$9aej08asd7", identifies the SIP 453 session. 455 NOTE: It is unclear if this usage of KPML is better than using a 456 device control protocol like H.248.1. From the application's 457 point of view, it has to do the low-level prompt-collect logic. 458 Granted, it is relatively easy to change the key mappings for a 459 given menu. However, often more of the call flow than a given 460 menu mapping gets changed. Thus there would be little value in 461 such a mapping to KPML. We STRONGLY suggest using a real 462 scripting language such as VoiceXML or MSCML for this purpose. 464 7.4 SIP Request 466 For example, the following figure is the example from Figure 1, but 467 with SIP NOTIFY reporting. 469 470 471 472 473 475 476 477 479 Figure 6 - Long Octothorpe Example 481 The response body is identical to the response that Figure 1 would 482 generate. 484 8. Report Body 486 For HTTP or SIP responses, the body of the response from the user 487 device is a KPML response form. 489 The tag has an attribute, "digits". The digits attribute 490 is the digit string. The digit string uses the conventional 491 characters '*' and '#' for star and octothorpe respectively. 493 Figure 7 shows a sample response body to the example in the Dial 494 String Collection (Section 7.2) section. 496 497 498 499 501 Figure 7 - Response Body 503 NOTE: KPML does not include a timestamp. There are a number of 504 reasons for this. First, what timestamp would in include? Would 505 it be the time of the first detected keypress? The time the 506 interpreter collected the entire string? A range? Second, if the 507 RTP timestamp is a datum of interest, why not simply get RTP in 508 the first place? That all said, if it is really compelling to 509 have the timestamp in the response, it could be an attribute to 510 the tag. 512 9. Formal Syntax 514 The following syntax specification uses the augmented Data Type 515 Definition (DTD) as described in XML [7]. 517 518 520 522 523 528 529 533 534 539 Figure 8 - KPML DTD 541 And, if you prefer XML Schema [5], here it is. 543 544 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 Figure 9 - XML Schema for KPML 610 10. IANA Considerations 612 10.1 IANA Registration of MIME media type application/kpml+xml 614 MIME media type name: application 616 MIME subtype name: kpml+xml 618 Required parameters: none 620 Optional parameters: charset 622 charset This parameter has identical semantics to the charset 623 parameter of the "application/xml" media type as specified in 624 XML Media Types [6]. 626 Encoding considerations: See RFC3023 [6]. 628 Interoperability considerations: See RFC2023 [6] and this document. 630 Published specification: This document. 632 Applications which use this media type: Session-oriented applications 633 that have primitive user interfaces. 635 Intended usage: COMMON 637 10.2 Schema Registration 639 We really need a place to register the XML Schema. Where would that 640 be? 642 11. Security Considerations 644 Since a KPML document directs a device to send results to an 645 arbitrary URI, one could construct distributed denial of service 646 attacks. For example, an errant application might send out KPML to 647 numerous endpoints, all reporting to a single, unrelated href. Thus 648 the policies for accepting KPML, such as access control lists ("only 649 accept KPML from these hosts"), report limiting lists ("only send 650 KPML responses to these hosts"), and other protections must be well 651 thought out. 653 At the very least, the session startup protocol SHOULD be 654 non-repudiable and secure. 656 KPML presents no further security issues beyond the startup issues 657 addressed in the companion documents to this document. 659 As an XML markup, all of the security considerations of RFC3023 [6] 660 apply. 662 Normative References 664 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 665 Levels", BCP 14, RFC 2119, March 1997. 667 [2] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 668 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 669 HTTP/1.1", RFC 2616, June 1999. 671 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 672 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 673 Session Initiation Protocol", RFC 3261, June 2002. 675 [4] Groves, C., Pantaleo, M., Anderson, T. and T. Taylor, "Gateway 676 Control Protocol Version 1", RFC 3525, June 2003. 678 [5] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML 679 Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502, 680 May 2001. 682 [6] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 683 3023, January 2001. 685 Informative References 687 [7] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 688 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 689 REC REC-xml-20001006, October 2000. 691 [8] World Wide Web Consortium, "Voice Extensible Markup Language 692 (VoiceXML) Version 2.0", W3C Working Draft , April 2002, 693 . 695 [9] Burger, E., Van Dyke, J. and A. Spitzer, "SnowShore Media 696 Server Control Markup Language and Protocol", 697 draft-vandyke-mscml-00 (work in progress), November 2002. 699 [10] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, 700 Telephony Tones and Telephony Signals", RFC 2833, May 2000. 702 [11] Andreasen, F. and B. Foster, "Media Gateway Control Protocol 703 (MGCP) Version 1.0", RFC 3435, January 2003. 705 [12] Hunt, A. and S. McGlashan, "Speech Recognition Grammar 706 Specification Version 1.0", W3C CR CR-speech-grammar-20020626, 707 June 2002. 709 [13] Van Dyke, J., Burger (Ed.), E. and A. Spitzer, "Basic Network 710 Media Services with SIP", January 2003. 712 [14] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and 713 D. Gurle, "Session Initiation Protocol (SIP) Extension for 714 Instant Messaging", RFC 3428, December 2002. 716 [15] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 717 "RTP: A Transport Protocol for Real-Time Applications", RFC 718 1889, January 1996. 720 Author's Address 722 Eric Burger 723 SnowShore Networks, Inc. 724 285 Billerica Rd. 725 Chelmsford, MA 01824-4120 726 USA 728 EMail: e.burger@ieee.org 730 Appendix A. Contributors 732 Robert Fairlie-Cuninghame, Cullen Jennings, Jonathan Rosenberg, and I 733 were the members of the Application Stimulus Signaling Design Team. 734 All members of the team contributed significantly to this work. In 735 addition, Jonathan Rosenberg postulated DML in his "A Framework for 736 Stimulus Signaling in SIP Using Markup" draft. 738 This version of KPML has significant influence from MSCML, the 739 SnowShore Media Server Control Markup Language. Jeff Van Dyke and 740 Andy Spitzer were the primary contributors to that effort. 742 That said, any errors, misinterpretation, or fouls in this document 743 are my own. 745 Appendix B. Acknowledgements 747 Hal Purdy and Eric Cheung of AT&T Laboratories helped immensely 748 through many conversations and challenges. 750 Steve Fisher of AT&T Laboratories helped with the digit suppression 751 logic and syntax. 753 Intellectual Property Statement 755 The IETF takes no position regarding the validity or scope of any 756 intellectual property or other rights that might be claimed to 757 pertain to the implementation or use of the technology described in 758 this document or the extent to which any license under such rights 759 might or might not be available; neither does it represent that it 760 has made any effort to identify any such rights. Information on the 761 IETF's procedures with respect to rights in standards-track and 762 standards-related documentation can be found in BCP-11. Copies of 763 claims of rights made available for publication and any assurances of 764 licenses to be made available, or the result of an attempt made to 765 obtain a general license or permission for the use of such 766 proprietary rights by implementors or users of this specification can 767 be obtained from the IETF Secretariat. 769 The IETF invites any interested party to bring to its attention any 770 copyrights, patents or patent applications, or other proprietary 771 rights which may cover technology that may be required to practice 772 this standard. Please address the information to the IETF Executive 773 Director. 775 Full Copyright Statement 777 Copyright (C) The Internet Society (2003). All Rights Reserved. 779 This document and translations of it may be copied and furnished to 780 others, and derivative works that comment on or otherwise explain it 781 or assist in its implementation may be prepared, copied, published 782 and distributed, in whole or in part, without restriction of any 783 kind, provided that the above copyright notice and this paragraph are 784 included on all such copies and derivative works. However, this 785 document itself may not be modified in any way, such as by removing 786 the copyright notice or references to the Internet Society or other 787 Internet organizations, except as needed for the purpose of 788 developing Internet standards in which case the procedures for 789 copyrights defined in the Internet Standards process must be 790 followed, or as required to translate it into languages other than 791 English. 793 The limited permissions granted above are perpetual and will not be 794 revoked by the Internet Society or its successors or assignees. 796 This document and the information contained herein is provided on an 797 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 798 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 799 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 800 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 801 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 803 Acknowledgment 805 Funding for the RFC Editor function is currently provided by the 806 Internet Society.