idnits 2.17.1 draft-ietf-sipping-kpml-03.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 is 1 instance 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 (May 17, 2004) is 7284 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: '179' is mentioned on line 1239, but not defined -- Looks like a reference, but probably isn't: '2-9' on line 1246 == Unused Reference: '19' is defined on line 1978, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1981, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 1985, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 1988, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3265 (ref. '2') (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 2234 (ref. '4') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 3023 (ref. '6') (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 3406 (ref. '8') (Obsoleted by RFC 8141) == Outdated reference: A later version (-05) exists of draft-ietf-sipping-app-interaction-framework-01 == Outdated reference: A later version (-09) exists of draft-vandyke-mscml-04 -- Obsolete informational reference (is this intentional?): RFC 2833 (ref. '13') (Obsoleted by RFC 4733, RFC 4734) -- Obsolete informational reference (is this intentional?): RFC 1889 (ref. '14') (Obsoleted by RFC 3550) == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-01 == Outdated reference: A later version (-06) exists of draft-ietf-sipping-dialog-package-02 -- Obsolete informational reference (is this intentional?): RFC 3525 (ref. '17') (Obsoleted by RFC 5125) -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '19') (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '20') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3266 (ref. '21') (Obsoleted by RFC 4566) == Outdated reference: A later version (-11) exists of draft-burger-sipping-netann-08 Summary: 6 errors (**), 0 flaws (~~), 13 warnings (==), 10 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: November 15, 2004 M. Dolly 5 AT&T Labs 6 May 17, 2004 8 A Session Initiation Protocol (SIP) Event Package for Key Press 9 Stimulus (KPML) 10 draft-ietf-sipping-kpml-03 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 15, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 The Key Press Stimulus Event Package is a component of the 42 Applications Interaction Framework for the Session Initiation 43 Protocol (SIP). The event package defines a Key Press Markup 44 Language (KPML) that describes filter specifications for reporting 45 key presses entered at a presentation-free user interface SIP User 46 Agent (UA). The scope of this package is for collecting supplemental 47 key presses or mid-call key presses (triggers). We recommend using 48 VoiceXML or MSCML, as described in the Applications Interaction 49 Framework, for building interactive voice response applications. 51 Conventions used in this document 53 RFC2119 [1] provides the interpretations for the key words "MUST", 54 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 55 "RECOMMENDED", "MAY", and "OPTIONAL" found in this document. 57 The Application Interaction Framework [9] provides the 58 interpretations for the terms "User Device", "SIP Application", and 59 "User Input". This document uses the term "Application" and 60 "Requesting Application" interchangeably with "SIP Application". 62 The Application Interaction Framework discusses User Device Proxies. 63 A common instantiation of a User Device Proxy is a Public-Switched 64 Telephone Network (PSTN) gateway. Because the normative behavior of 65 a presentation-free user interface is identical for a 66 presentation-free SIP User Agent and a presentation-free User Device 67 Proxy, this document uses "User Device" for both cases. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 2. Key Press Stimulus Operation . . . . . . . . . . . . . . . . . 5 73 2.1 Model . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2.2 Stream to Monitor . . . . . . . . . . . . . . . . . . . . 7 75 2.3 Operation . . . . . . . . . . . . . . . . . . . . . . . . 8 76 3. Event Package Operation . . . . . . . . . . . . . . . . . . . 9 77 3.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 9 78 3.2 Event Package Parameters . . . . . . . . . . . . . . . . . 9 79 3.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 10 80 3.4 Subscription Duration . . . . . . . . . . . . . . . . . . 11 81 3.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 11 82 3.6 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 11 83 3.7 Notifier Generation of NOTIFY Requests . . . . . . . . . . 13 84 3.7.1 SIP Protocol-Generated . . . . . . . . . . . . . . . . 13 85 3.7.2 Match . . . . . . . . . . . . . . . . . . . . . . . . 13 86 3.7.3 Inter-Digit Timeout No Match . . . . . . . . . . . . . 13 87 3.7.4 Dialog Terminated . . . . . . . . . . . . . . . . . . 14 88 3.7.5 No Call Leg . . . . . . . . . . . . . . . . . . . . . 14 89 3.7.6 Bad Document . . . . . . . . . . . . . . . . . . . . . 14 90 3.7.7 One-Shot vs. Persistent Requests . . . . . . . . . . . 15 91 3.8 Subscriber Processing of NOTIFY Requests . . . . . . . . . 15 92 3.8.1 No KPML Body . . . . . . . . . . . . . . . . . . . . . 15 93 3.8.2 KPML Body . . . . . . . . . . . . . . . . . . . . . . 15 94 3.9 Handling of Forked Requests . . . . . . . . . . . . . . . 16 95 3.10 Rate of Notifications . . . . . . . . . . . . . . . . . . 16 96 3.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . 16 97 4. Message Format - KPML . . . . . . . . . . . . . . . . . . . . 16 98 4.1 KPML Request . . . . . . . . . . . . . . . . . . . . . . . 16 99 4.1.1 User Input Buffer Behavior . . . . . . . . . . . . . . 17 100 4.1.2 Pattern Matching . . . . . . . . . . . . . . . . . . . 18 101 4.1.3 Digit Suppression . . . . . . . . . . . . . . . . . . 22 102 4.1.4 One-Shot and Persistent Triggers . . . . . . . . . . . 23 103 4.1.5 Multiple Patterns . . . . . . . . . . . . . . . . . . 24 104 4.1.6 Monitoring Direction . . . . . . . . . . . . . . . . . 24 105 4.1.7 Multiple, Simultaneous Subscriptions . . . . . . . . . 24 106 4.2 KPML Reports . . . . . . . . . . . . . . . . . . . . . . . 25 107 4.2.1 Pattern Match Reports . . . . . . . . . . . . . . . . 25 108 4.2.2 KPML No Match Reports . . . . . . . . . . . . . . . . 26 109 5. DRegex Syntax . . . . . . . . . . . . . . . . . . . . . . . . 27 110 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 29 111 6.1 DRegex . . . . . . . . . . . . . . . . . . . . . . . . . . 29 112 6.2 KPML . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 113 7. Enumeration of KPML Status Codes . . . . . . . . . . . . . . . 33 114 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 115 8.1 MIME Media Type application/kpml+xml . . . . . . . . . . . 34 116 8.2 URN Sub-Namespace Registration for urn:ietf:xml:ns:kpml . 34 117 8.3 KPML Schema Registration . . . . . . . . . . . . . . . . . 35 118 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 119 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 36 120 10.1 Monitoring for Octothorpe . . . . . . . . . . . . . . . . 36 121 10.2 Dial String Collection . . . . . . . . . . . . . . . . . . 36 122 10.3 Interactive Digit Collection . . . . . . . . . . . . . . . 37 123 11. Call Flow Example . . . . . . . . . . . . . . . . . . . . . 38 124 11.1 INVITE-Initiated Dialog . . . . . . . . . . . . . . . . . 38 125 11.2 Third-Party Subscription . . . . . . . . . . . . . . . . . 43 126 11.3 Remote-End Monitoring . . . . . . . . . . . . . . . . . . 44 127 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 128 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 44 129 12.2 Informative References . . . . . . . . . . . . . . . . . . . 44 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 46 131 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46 132 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46 133 Intellectual Property and Copyright Statements . . . . . . . . 48 135 1. Introduction 137 This document describes the Key Press Stimulus Event Package. The 138 Key Press Stimulus Package is a SIP Event Notification Package [2] 139 that uses the SUBSCRIBE and NOTIFY methods of SIP. The subscription 140 filter and notification report bodies use the Keypad Markup Language, 141 KPML. KPML is a markup [10] that enables presentation-free user 142 interfaces as described in the Application Interaction Framework [9]. 144 In particular, KPML enables "dumb phones" and gateways to dumb phones 145 to report user key-press events. Colloquially, this mechanism 146 provides for "digit reporting" or "Dual-Tone Multi-Frequency (DTMF) 147 reporting." 149 A goal of KPML is to fit in an extremely small memory and processing 150 footprint. Note KPML has a corresponding lack of functionality. For 151 those applications that require more functionality, please refer to 152 VoiceXML [11] and MSCML [12]. 154 The name of the markup, KPML, reflects its legacy support role. The 155 public switched telephony network (PSTN) accomplished end-to-end 156 signaling by transporting DTMF tones in the bearer channel. This is 157 in-band signaling. 159 Voice-over-IP networks transport in-band signaling with actual DTMF 160 waveforms or RFC2833 [13] packets. In RFC2833, the signaling 161 application inserts RFC2833 named signal packets as well as or 162 instead of generating tones in the media path. The receiving 163 application gets the signal information in the media stream. 165 RFC2833 correlates the time the end user pressed a digit with the 166 user's media. However, out-of-band signaling methods, as are 167 appropriate for User Device to application signaling, do not need 168 millisecond accuracy. On the other hand, they do need reliability, 169 which RFC2833 does not provide. 171 An interested application could request notifications of every key 172 press. However, many of the use cases for such signaling has the 173 application interested in only one or a few keystrokes. Thus we need 174 a mechanism for specifying to the User Device what stimulus the 175 application would like notification of. 177 2. Key Press Stimulus Operation 179 2.1 Model 181 The Key Press Stimulus reporting model is that key presses, or 182 detected digits, are events at the User Device. The subscription 183 installs an event filter. That event filter specifies the User Input 184 strings, which, if matched, the User Device sends a notification. 186 There are three usage models for the event package. Functionally, 187 they are equivalent. However, it is useful to understand the use 188 cases. 190 The first model is that of a third-party application that is 191 interested in the User Input. Figure 1 shows an established SIP 192 dialog between the User Device and the SIP UA. The Requesting 193 Application addresses the particular media stream (From RTP [14] port 194 B to RTP port Y) by referencing the dialog identifier referring to 195 the dialog between SIP ports A and X. 197 +-------------+ 198 | Requesting | 199 /---| Application | 200 / +-------------+ 201 / 202 SIP / (SUBSCRIBE/NOTIFY) 203 / 204 / 205 +---M----+ SIP (INVITE) +-----+ 206 | A--------------------X | 207 | User | | SIP | 208 | Device | RTP | UA | 209 | B--------------------Y | 210 +--------+ +-----+ 212 Figure 1: Third-Party Model 214 The second model is that of a SIP User Agent (UA) that directly 215 interacts, on a given dialog, with the User Device. Figure 2 shows a 216 SIP dialog. In this scenario, the SIP UA takes on the role of the 217 Application. Thus it issues a SUBSCRIBE request to establish a new 218 dialog for the User Device to report on User Input (key press) 219 events. This could represent, for example, a toll by-pass scenario 220 where the User Device is an ingress gateway and the SIP UA is an 221 egress gateway. 223 +--------+ SIP (INVITE) +-----+ 224 | A--------------------X SIP | 225 | | SIP (SUBSCRIBE) | UA | 226 | User A'-------------------X' | 227 | Device | RTP |(App)| 228 | B--------------------Y | 229 +--------+ +-----+ 231 Figure 2: Endpoint Model 233 The third model is that of a media proxy. A media proxy is a media 234 relay in the terminology of RFC1889 [14]. However, in addition to 235 the RTP forwarding capability of a RFC1889 media relay, the media 236 proxy can also do light media processing, such as tone detection, 237 tone transcoding (tones to RFC2833 [13]), and so on. 239 The Requesting Application uses dialog identifiers to identify the 240 stream to monitor. The default is to monitor the media entering the 241 User Device. For example, if the Requesting Application in Figure 3 242 refers to the dialog represented by SIP ports V-C, then the media 243 coming from SIP UAa RTP port W gets monitored. Likewise, the dialog 244 represented by A-X directs the User Device to monitor the media 245 coming from SIP UAb RTP Port Y. 247 +-------------+ 248 | Requesting | 249 /---| Application | 250 / +-------------+ 251 / 252 SIP / (SUBSCRIBE/NOTIFY) 253 / 254 / 255 +-----+ SIP +---M----+ SIP +-----+ 256 | V--------------------C A--------------------X | 257 | SIP | | User | | SIP | 258 | UAa | RTP | Device | RTP | UAb | 259 | W--------------------D B--------------------Y | 260 +-----+ +--------+ +-----+ 262 Figure 3: Media Proxy Model 264 2.2 Stream to Monitor 266 The default media stream to monitor is the stream represented by the 267 local tag of the SIP dialog at the monitoring User Device. A 268 requesting application MAY request monitoring of the stream 269 represented by the remote tag of the SIP dialog at the User Device. 271 Not all User Devices are able to monitor the remote media stream. 272 However, the User Device MUST be able to report on local User Input. 273 In the case where the User Device is a gateway, that is, it is a User 274 Device Proxy, local User Input is the media stream that emanates from 275 the User Device. 277 If the requesting application wishes to monitor both the ingress and 278 egress streams at a given User Device, the application MUST establish 279 two subscriptions, one for each leg. 281 Section 4.1.6 describes how to specify to the User Device which 282 stream direction of the dialog to monitor. 284 2.3 Operation 286 The Key Press Stimulus Event Package uses explicit subscription 287 notification requests, using the SUBSCRIBE/NOTIFY [2] mechanism. 289 The User Device MUST return a GRUU [15] in the Contact header of a 290 SIP INVITE, 1xx, or 2xx response. 291 NOTE: Generating and using a GRUU is in no way required for the 292 KPML mechanism to operate. For example, consider a restricted 293 deployment scenario, such as between a single service provider's 294 gateway (User Device) and application server (Application) without 295 any intervening proxies. Ignoring the obvious performance issues 296 of requesting GRUUs, the service provider probably does not want 297 the gateway to offer the first, principal feature of a GRUU. 298 Namely, the service provider may NOT want to offer a globally 299 routable Request-URI. All of the mechanisms in this document will 300 work in such deployment topologies without a GRUU. However, as 301 described in the GRUU document, there are scenarios where the 302 subscriber may not be able to find the User Device without a GRUU. 303 Thus, this document mandates the use of a GRUU as part of an 304 Internet standard. That is, mandating a GRUU means the mechanism 305 will work in all deployment scenarios. Likewise, an 306 implementation that did not use a GRUU is not fully compliant with 307 this specification. 309 Following the semantics of SUBSCRIBE, if the User Device receives a 310 second subscription on the same dialog, including id, if present, the 311 User Device MUST terminate the existing KPML subscription and replace 312 it with the new subscription. 314 An Application MAY register multiple User Input patterns in a single 315 KPML subscription. 317 If the User Device supports multiple, simultaneous KPML 318 subscriptions, the Application installs the subscriptions either in a 319 new SUBSCRIBE-initiated dialog or on an existing SUBSCRIBE-initiated 320 dialog with a new event id tag. 322 If the User Device does not support multiple, simultaneous KPML 323 subscriptions, the User Device MUST respond with an error response 324 code. See Section 4.1.7 for more information. 326 A KPML subscription can be persistent or one-shot. Persistent 327 requests are active until either the dialog terminates, including 328 normal subscription expiration, the Application replaces them, the 329 Application deletes them by sending a null document on the dialog, or 330 the Application deletes the subscription by sending a SUBCRIBE with 331 an expires of zero (0). 333 Standard SUBSCRIBE processing dictates the User Device sends a NOTIFY 334 response if it receives a SUBSCRIBE with an expires of zero. 336 One-shot requests terminate themselves once a match occurs. The 337 "persist" KPML element specifies whether the subscription remains 338 active for the duration specified in the SUBSCRIBE message or if it 339 automatically terminates after a pattern matches. 341 KPML subscriptions route to the User Device using standard SIP 342 request routing. A KPML subscription identifies the media stream by 343 referencing its dialog identifiers. 345 Notifications are KPML documents. If the User Device matched a digit 346 map, the response indicates the User Input detected and whether the 347 User Device suppressed User Input. If the User Device had an error, 348 such as a timeout, it will indicate that instead. 350 3. Event Package Operation 352 The following sub-sections are the formal specification of the KPML 353 SIP-specific event notification package. 355 3.1 Event Package Name 357 The name for the Key Press Stimulus Event Package is "kpml". 359 3.2 Event Package Parameters 361 SIP identifies dialogs by their dialog identifier. The dialog 362 identifier is the remote-tag, local-tag, and Call-ID entities. 364 To identify a specific dialog, all three of these parameters MUST be 365 present. Usually, the local-tag is the To: entity with the To tag, 366 the remote-tag is the From: entity including tag, and the call-id 367 matches the Call-ID. Although semantically different, the important 368 entities are the To: and From: tags. 370 The "leg" parameter identifies the dialog to monitor. If there is no 371 corresponding dialog, the User Device MUST send a 481 result code in 372 a KPML notification. 373 NOTE: The SUBSCRIBE may succeed, resulting in a SIP 200 OK. 374 However, the "current state" will be the KPML 481 result, and the 375 subscription state will be "terminated." 377 There may be ambiguity in specifying only the SIP dialog to monitor. 378 The dialog may specify multiple SDP streams that could carry key 379 press events. For example, a dialog may have multiple audio streams. 380 Wherever possible, the User Device MAY apply local policy to 381 disambiguate which stream or streams to monitor. In order to have an 382 extensible mechanism for identifying streams, the mechanism for 383 specifying streams is as an element content to the tag. The 384 only content defined today is the tag. 386 For most situations, such as a monaural point-to-point call with a 387 single codec, the stream to monitor is obvious. In such situations 388 the Application need not specify which stream to monitor. 390 The BNF for these parameters is as follows. The definitions of 391 callid, token, EQUAL, and DQUOTE are from RFC3261 [3]. 393 call-id = "call-id" EQUAL DQUOTE callid DQUOTE 394 from-tag = "from-tag" EQUAL token 395 to-tag = "to-tag" EQUAL token 397 The call-id parameter is a quoted string. This is because the BNF 398 for word (which is used by callid) allows for characters not allowed 399 within token. One usually just copies these elements from the 400 Call-Id, to, and from fields of the SIP INVITE. 402 One can use any method of determining the dialog identifier. One 403 method available, particularly for third-party applications, is the 404 SIP Dialog Package [16]. 406 3.3 SUBSCRIBE Bodies 408 Key press event notification filters use KPML, as described in 409 Section 4.1. The MIME type for KPML is application/kpml+xml. 411 The KPML document MUST be well-formed and SHOULD be valid. KPML 412 documents MUST conform to XML 1.0 [10] and MUST use UTF-8 encoding. 414 Because of the potentially sensitive nature of the information 415 reported by KPML, subscribers SHOULD use sips: and SHOULD consider 416 the use of S/MIME on the content. 418 Subscribers MUST be prepared for the notifier to insist on 419 authentication at a minimum and to expect encryption on the 420 documents. 422 3.4 Subscription Duration 424 The "persist" attribute to the tag in the KPML subscription 425 body affects the lifetime of the subscription. 427 If the persist attribute is "one-shot", then once there is a match 428 (or no match is possible), the subscription ends after the User 429 Device notifies the Application. 431 If the persist attribute is "persistent" or "single-notify", then the 432 subscription ends when the Application explicitly ends it or the User 433 Device terminates the subscription. 435 The subscription lifetime MUST NOT be longer than the negotiated 436 expires time, per RFC3265 [2]. 438 The subscription lifetime should be longer than the expected call 439 time. The default subscription lifetime (Expires value) MUST be 7200 440 seconds. 442 Subscribers MUST be able to handle the User Device returning an 443 Expires value smaller than the requested value. Per RFC3265 [2], the 444 subscription duration is the value returned by the User Device in the 445 200 OK Expires entity. 447 3.5 NOTIFY Bodies 449 The key press notification uses KPML, as described in Section 4.2. 450 The MIME type for KPML is application/kpml+xml. The default MIME 451 type for the kpml event package is application/kpml+xml. 453 If the requestor is not using a secure transport protocol such as TLS 454 (e.g., by using a sips: URI), the User Device SHOULD use S/MIME to 455 protect the user information in responses. 457 3.6 Notifier Processing of SUBSCRIBE Requests 459 The user information transported by KPML is potentially sensitive. 460 For example, it could include calling card or credit card numbers. 461 Thus the first action of the User Device (notifier) SHOULD be to 462 authenticate the requesting party. 464 User Devices MUST support digest authentication at a minimum. 466 User Devices MUST support the sips: scheme and TLS. 468 Upon authenticating the requesting party, the User Device determines 469 if the requesting party has authorization to monitor the user's key 470 presses. Determining authorization policies and procedures is beyond 471 the scope of this specification. 472 NOTE: While it would be good to require both authorization and 473 user notification for KPML, some uses, such as lawful intercept 474 pen registers, have very strict authorization requirements yet 475 have a requirement of no user notification. Conversely, pre-paid 476 applications running on a private network may have no 477 authorization requirements and already have implicit user 478 acceptance of key press monitoring. Thus we cannot give any 479 guidelines here. 481 After authorizing the request (RECOMMENDED), the User Device checks 482 to see if the request is to terminate a subscription. If the request 483 will terminate the subscription, the User Device does the appropriate 484 processing, including the procedures described in Section 3.7.4. 486 If the request has no KPML body, then any KPML document running on 487 that dialog, and addressed by the event id, if present, immediately 488 terminates. This is a mechanism for unloading a KPML document while 489 keeping the SUBSCRIBE-initiated dialog active. This can be important 490 for secure sessions that have high costs for session establishment, 491 such as TLS. The User Device follows the procedures described in 492 Section 3.7.1. 494 If the dialog referenced by the "leg" parameter to the kpml 495 subscription does not exist, the User Device follows the procedures 496 in Section 3.7.5 Note the User Device MUST issue a 200 OK before 497 issuing the NOTIFY, as the SUBSCRIBE itself is well-formed. 499 If the request has a KPML body, the User Device parses the KPML 500 document. The User Device SHOULD validate the XML document against 501 the schema presented in Section 6.2. If the document is not valid, 502 the User Device performs the procedures described in Section 3.7.6. 503 If there is a loaded KPML document on the dialog (and given event id, 504 if present), the User Device unloads the document. 506 If the KPML document is valid, and the User Device is capable of 507 performing the monitoring, the User Device performs the filtering 508 specified by the KPML document. See Section 4 for the specification 509 of KPML. 511 3.7 Notifier Generation of NOTIFY Requests 513 3.7.1 SIP Protocol-Generated 515 The User Device (notifier in SUBSCRIBE/NOTIFY parlance) generates 516 NOTIFY requests based on the requirements of RFC3265 [2]. 517 Specifically, unless a SUBSCRIBE request is not valid, all SUBSCRIBE 518 requests will result in an immediate NOTIFY. 520 The KPML payload distinguishes between a NOTIFY that RFC3265 mandates 521 and a NOTIFY informing of key presses. If there is no User Input 522 quarantined at the time of the SUBSCRIBE (see Section 4.1 below) or 523 the quarantined User Input does not match the new KPML document, then 524 the immediate NOTIFY MUST NOT contain a KPML body. If User Device 525 has User Input quarantined that result in a match using the new KPML 526 document, then the NOTIFY MUST return the appropriate KPML document. 528 3.7.2 Match 530 During the subscription lifetime, the User Device may detect a key 531 press stimulus that triggers a KPML event. In this case, the User 532 Device (notifier) MUST return the appropriate KPML document. 534 3.7.3 Inter-Digit Timeout No Match 536 Once a user starts to enter stimulus, it is highly likely they will 537 enter all of the key presses of interest within a specific time 538 period. There is a temporal locality of reference for key presses. 539 It is possible for users to accidentally press a key, however. 540 Moreover, users may start pressing a key and then be lost as to what 541 to do next. For applications to handle this situation, KPML allows 542 applications to request notification if the user starts to enter 543 stimulus but then stops before a match. 545 Once the User Device detects a key press that matches the first 546 character of a digit map, the User Device starts the interdigit timer 547 specified in the tag. Every subsequent key press detected 548 restarts the interdigit timer. If the interdigit timer expires, the 549 User Device generates a KPML report with the KPML status code 423, 550 Timer Expired. The report also includes the User Input collected up 551 to the time the timer expired. This could be the null string. After 552 sending the NOTIFY, the User Device will resume quarantining 553 additional detected User Input. 555 Applications may have different requirements for the interdigit 556 timer. For example, applications targeted to user populations that 557 tend to key in information slowly may require longer interdigit 558 timers. The specification of the interdigit timer is in 559 milliseconds. The default value is 4000, for 4 seconds. A value of 560 zero indicates disabling the interdigit timer. The User Device MUST 561 round up the requested interdigit timer to the nearest time increment 562 it is capable of detecting. 564 3.7.4 Dialog Terminated 566 It is possible for a dialog to terminate during key press collection. 567 The cases enumerated here are explicit SUBSCRIPTION termination, 568 automatic SUBSCRIPTION termination, and underlying (INVITE-initiated) 569 dialog termination. 571 If a SUBSCRIBE request has an expires of zero (explicit SUBSCRIBE 572 termination), includes a KPML document, and there is quarantined User 573 Input, then the User Device attempts to process the quarantined 574 digits against the document. If there is a match, the User Device 575 MUST generate the appropriate KPML report with the KPML status code 576 of 200. The SIP NOTIFY body terminates the subscription by setting 577 the subscription state to "terminated" and a reason of "timeout". 579 If the SUBSCRIBE request has an expires of zero and no KPML body or 580 the expires timer on the SUBSCRIBE-initiated dialog fires at the User 581 Device (notifier), then the User Device MUST issue a KPML report with 582 the KPML status code 487, Subscription Expired. The report also 583 includes the User Input collected up to the time the expires timer 584 expired or when the subscription with expires equal to zero was 585 processed. This could be the null string. 587 Per the mechanisms of RFC3265 [2], the User Device MUST terminate the 588 SIP SUBSCRIBE dialog. The User Device does this via the SIP NOTIFY 589 body transporting the final report described in the preceding 590 paragraph. In particular, the subscription state will be 591 "terminated" and a reason of "timeout". 593 Terminating the subscription when a dialog terminates ensures 594 reauthorization (if necessary) for attaching to subsequent call legs. 596 3.7.5 No Call Leg 598 If a SUBSCRIBE request references a dialog that is not present at the 599 User Device, the User Device MUST generate a KPML report with the 600 KPML status code 481, Dialog Not Found. The User Device terminates 601 the subscription by setting the subscription state to "terminated". 603 3.7.6 Bad Document 605 If the KPML document is not valid, the User Device generates a KPML 606 report with the KPML status code 501, Bad Document. The User Device 607 terminates the subscription by setting the subscription state to 608 "terminated". 610 If the document is valid but the User Device does not support a 611 namespace in the document, the User Device MUST respond with a KPML 612 status code 502, Namespace Not Supported. 614 3.7.7 One-Shot vs. Persistent Requests 616 There are two types of subscriptions: one-shot and persistent. 617 Persistent subscriptions have two sub-types: continuous notify and 618 single-notify. 620 One-shot subscriptions terminate after a pattern match and report. 621 If the User Device detects a key press stimulus that triggers a 622 one-shot KPML event, then the User Device (notifier) MUST set the 623 "Subscription-State" in the NOTIFY message to "terminated". At this 624 point the User Device MUST consider the subscription destroyed. The 625 User Device MUST quarantine User Input per the controls specified in 626 Section 4.1. 628 Persistent subscriptions remain active at the User Device, even after 629 a match. For continuous notify persistent subscriptions, the User 630 Device will emit a notification whenever the User Input matches a 631 pattern. For single-notify persistent subscriptions, the User Device 632 will emit a notification at the first match, but will not emit 633 further notifications until the Application issues a new document on 634 the subscription dialog. 636 NOTE: The single-notify persistent subscription enables lock-step 637 (race-free) quarantining of User Input between different digit 638 maps. 640 3.8 Subscriber Processing of NOTIFY Requests 642 3.8.1 No KPML Body 644 If there is no KPML body, it means the SUBSCRIBE was successful. 645 This establishes the dialog if there is no quarantined User Input to 646 report. 648 3.8.2 KPML Body 650 If there is a KPML document, and the KPML status code is 200, then a 651 match occurred. 653 If there is a KPML document, and the KPML status code is 4xx, then an 654 error occurred with User Input collection. The most likely cause is 655 a timeout condition. 657 If there is a KPML document, and the KPML status code is 5xx, then an 658 error occurred with the subscription. See Section 7 for more on the 659 meaning of error codes. 661 The subscriber MUST be mindful of the subscription state. The User 662 Device may terminate the subscription at any time. 664 3.9 Handling of Forked Requests 666 The SUBSCRIBE behavior described in Section 3.6 ensures that it is 667 only possible to have a subscription where there is an active (e.g., 668 voice) dialog. Thus the case of multiple subscription installation 669 cannot occur. 671 3.10 Rate of Notifications 673 The User Device MUST NOT generate messages faster than one message 674 every 40 milliseconds. This is the minimum time period for MF digit 675 spills. Even 30-millisecond DTMF, as one sometimes finds in Japan, 676 has a 20-millisecond off time, resulting in a 50-millisecond 677 interdigit time. This document strongly RECOMMENDS AGAINST using 678 KPML for digit-by-digit messaging, such as would be the case if the 679 only is "x". 681 The User Device MUST reliably deliver notifications. Because there 682 is no meaningful metric for throttling requests, the User Device 683 SHOULD send NOTIFY messages over a congestion-controlled transport, 684 such as TCP or SCTP. 686 User Devices MUST at a minimum implement SIP over TCP. 688 3.11 State Agents 690 Not applicable. 692 4. Message Format - KPML 694 The Key Press Markup Language (KPML) has two, mutually exclusive 695 elements: the request and response. 697 4.1 KPML Request 699 A KPML request document contains a entity containing a 700 tag with a series of tags. The element 701 specifies a pattern for the User Device to report on. Section 5 702 describes the DRegex, or digit regular expression, language. 704 4.1.1 User Input Buffer Behavior 706 User Devices MUST buffer User Input. Subsequent KPML documents apply 707 their patterns against the buffered User Input. Some applications 708 use modal interfaces where the first few key presses determine what 709 the following key presses mean. For a novice user, the application 710 may play a prompt describing what mode the application is in. 711 However, "power users" often barge through the prompt. 713 The markup provides a tag in the element. The 714 default is not to flush User Input. Flushing User Input has the 715 effect of ignoring key presses entered before the installation of the 716 KPML subscription. To flush User Input, include the tag yes in the KPML subscription document. Note that this directive 718 affects only the current subscription dialog/id combination. 720 Lock-step processing of User Input is where the User Device issues a 721 notification, the Application processes the notification while the 722 User Device buffers additional User Input, the Application requests 723 more User Input, and only then does the User Device notify the 724 Application based on the collected User Input. To direct the User 725 Device to operate in lock-step mode, set the attribute 726 persist="single-notify". 728 The User Device MUST be able to process no. This 729 directive is effectively a no-op. 731 Other string values for may be defined in the future. If the 732 User Device receives a string it does not understand, it MUST treat 733 the string as a no-op. 735 If the user presses a key not matched by a tag, the User 736 Device MUST discard the key press from consideration against the 737 current or future KPML documents on a given dialog. However, as 738 described above, once there is a match, the User Device quarantines 739 any key presses the user entered subsequent to the match. 741 NOTE: This behavior allows for applications to only receive User 742 Input that interest them. For example, a pre-paid application 743 only wishes to monitor for a long pound. If the user enters other 744 stimulus, presumably for other applications, the pre-paid 745 applicationd does not want notification of that User Input. This 746 feature is fundamentally different than the behavior of TDM-based 747 equipment where every application receives every key press. 749 To limit reports to only complete matches, set the "nopartial" 750 attribute to the tag to "true". In this case, the User 751 Device attempts to match a rolling window over the collected User 752 input. 754 KPML subscriptions are independent. Thus it is not possible for the 755 current document to know if a following document will enable barging 756 or want User Input flushed. Therefore, the User Device MUST buffer 757 all User Input. 759 On a given SUBSCRIBE dialog with a given id, the User Device MUST 760 quarantine all User Input detected between the time of the report and 761 the receipt of the next document, if any. If the next document 762 indicates a buffer flush, then the interpreter MUST flush all 763 collected User Input from consideration from KPML documents received 764 on that dialog with the given event id. If the next document does 765 not indicate flushing the quarantined User Input, then the 766 interpreter MUST apply the collected User Input (if possible) against 767 the digit maps presented by the script's tags. If there is a 768 match, the interpreter MUST follow the procedures in Section 3.7.2. 769 If there is no match, the interpreter MUST flush all of the collected 770 User Input. 772 Given the potential for the need for an infinite buffer for User 773 Input, the User Device MAY discard the oldest User Input from the 774 buffer. When the User Device issues a KPML notification, it MUST set 775 the forced_flush attribute of the tag to "true". For 776 future use, the Application MUST consider any non-null value, other 777 than "false" that it does not understand, to be the same as "true". 778 NOTE: The requirement to buffer all User Input for the entire 779 length of the session is not really onerous under normal 780 operation. For example, if one has a gateway with 8,000 sessions, 781 and the gateway buffers 50 key presses on each session, the 782 requirement is only 400,000 bytes, assuming one byte per key 783 press. 785 Unless there is a suppress indicator in the digit map, it is not 786 possible to know if the User Input is for local KPML processing or 787 for other recipients of the media stream. Thus, in the absence of a 788 suppression indicator, the User Device transmits the User Input to 789 the far end in real time, using either RFC2833, generating the 790 appropriate tones, or both. 792 The section Digit Suppression (Section 4.1.3) describes the operation 793 of the suppress indicator. 795 4.1.2 Pattern Matching 797 4.1.2.1 Inter-Digit Timing 799 The pattern matching logic works as follows. KPML User Devices MUST 800 follow the logic presented in this section so that different 801 implementations will perform deterministically on the same KPML 802 document given the same User Input. 804 The pattern match algorithm matches the longest regular expression. 805 This is the same mode as H.248.1 [17] and not the mode presented by 806 MGCP [18]. The pattern match algorithm choice has an impact on 807 determining when a pattern matches. Consider the following KPML 808 document. 810 811 815 816 817 0 818 011 819 820 821 823 Figure 5: Greedy Matching 825 In Figure 5, if we were to match on the first found pattern, the 826 string "011" would never match. This happens because the "0" rule 827 would match first. 829 While this behavior is what most applications desire, it does come at 830 a cost. Consider the following KPML document snippet. 832 x{7} 833 x{10} 835 Figure 6: Timeout Matching 837 Figure 6 is a typical North American dial plan. From an application 838 perspective, users expect a seven-digit number to respond quickly, 839 not waiting the typical inter-digit critical timer (usually four 840 seconds). Conversely, the User does not want the system to cut off 841 their ten-digit number at seven digits because they did not enter the 842 number fast enough. 844 One approach to this problem is to have an explicit dial string 845 terminator. Typically, it is the pound key (#). Now, consider the 846 following snippet. 848 x{7}# 849 x{10}# 851 Figure 7: Timeout Matching with Enter 853 The problem with the approach in Figure 7 is that the digit collector 854 will still look for a digit after the "#" in the seven-digit case. 855 Worse yet, the "#" will appear in the returned dial string. 857 The approach used in KPML is to have an explicit "Enter Key", as 858 shown in the following snippet. 860 861 862 x{7} 863 x{10} 864 865 867 Figure 8: Timeout Matching with Enter Key 869 In Figure 8, the enterkey attribute to the tag specifies a 870 string that terminates a pattern. In this situation, if the user 871 enters seven digits followed by the "#" key, the pattern matches (or 872 fails) immediately. KPML indicates a terminated nomatch with a KPML 873 status code 402. 874 NOTE: The enterkey is a string. The enterkey can be a sequence 875 of key presses. 877 To address the various key press collection scenarios, we define 878 three timers. The timers are the critical timer (criticaltimer), the 879 inter-digit timer (interdigittimer), and the extra digit timer 880 (extradigittimer). The critical timer is the time to wait for 881 another digit if the collected digits can match a pattern. The extra 882 timer is the time to wait after the longest match has occurred 883 (presumably for the return key). The inter-digit timer inter-digit 884 timer is the time to wait between digits in all other cases. Note 885 there is no start timer, as that concept does not apply in the KPML 886 context. 888 The User Device MAY support an inter-digit timeout value. This is 889 the amount of time the User Device will wait for User Input before 890 returning a timeout error result on a partially matched pattern. The 891 application can specify the inter-digit timeout as an integer number 892 of milliseconds by using the "interdigittimer" attribute to the 893 tag. The default is 4000 milliseconds. If the User Device 894 does not support the specification of an inter-digit timeout, the 895 User Device MUST silently ignore the specification. If the User 896 Device supports the specification of an inter-digit timeout, but not 897 to the granularity specified by the value presented, the User Device 898 MUST round up the requested value to the closest value it can 899 support. 901 The User Device MAY support an extra-digit timeout value. This is 902 the amount of time the User Device will wait for another key press 903 when it already has a matched . The application can specify 904 the extra-digit timeout as an integer number of milliseconds by using 905 the "extradigittimer" attribute to the tag. The default is 906 500 milliseconds. 908 The User Device MAY support a critical-digit timeout value. This is 909 the amount of time the User Device will wait for another key press 910 when it already has a matched but there is another, longer 911 that may also match the pattern. The application can specify 912 the extra-digit timeout as an integer number of milliseconds by using 913 the "extradigittimer" attribute to the tag. The default is 914 1000 milliseconds. 916 4.1.2.2 Intra-Digit Timing 918 Some patterns look for long duration key presses. For example, some 919 applications look for long "#" or long "*". 921 KPML uses the "L" modifier to characters to indicate long key 922 presses. The following KPML document looks for a long pound of at 923 least 3 seconds. 925 926 930 931 932 L# 933 934 935 937 The request can specify what constitutes "long" by setting the long 938 attribute to the . This attribute is an integer 939 representing the number of milliseconds. If the user presses a key 940 for longer than longtimer milliseconds, the Long modifier is true. 941 The default length of the long attribute is 2500 milliseconds. 943 Some User Devices are unable to present long key presses. An example 944 is an old private branch exchange (PBX) phone set that emits 945 fixed-length tones when the user presses a key. To address this 946 issue, the User Device MAY interpret a succession of a single key 947 press to be equivalent to a long key press of the same key. The 948 Application indicates it wants this behavior by setting the 949 "longrepeat" attribute tot he to "true". 951 4.1.3 Digit Suppression 953 Under basic operation, a KPML User Device will transmit in-band tones 954 (RFC2833 [13] or actual tone) in parallel with User Input reporting. 956 NOTE: If KPML did not have this behavior, then a User Device 957 executing KPML could easily break called applications. For 958 example, take a personal assistant that uses "*9" for attention. 959 If the user presses the "*" key, KPML will hold the digit, looking 960 for the "9". What if the user just enters a "*" key, possibly 961 because they accessed an IVR system that looks for "*"? In this 962 case, the "*" would get held by the User Device, because it is 963 looking for the "*9" pattern. The user would probably press the 964 "*" key again, hoping that the called IVR system just did not hear 965 the key press. At that point, the User Device would send both "*" 966 entries, as "**" does not match "*9". However, that would not 967 have the effect the user intended when they pressed "*". 969 On the other hand, there are situations where passing through tones 970 in-band is not desirable. Such situations include call centers that 971 use in-band tone spills to effect a transfer. 973 For those situations, KPML adds a suppression tag, "pre", to the 974 tag. There MUST NOT be more than one 
 in any given
975	   .

977	   If there is only a single  and a single , suppression
978	   processing is straightforward.  The end-point passes User Input until
979	   the stream matches the regular expression 
.  At that point, the
980	   User Device will continue collecting User Input, but will suppress
981	   the generation or pass-through of any in-band User Input.

983	   If the User Device suppressed stimulus, it MUST indicate this by
984	   including the attribute "suppressed" with a value of "true" in the
985	   notification.

987	   Clearly, if the User Device is processing the KPML document against
988	   quarantined User Input, it is too late to suppress the transmission
989	   of the User Input, as the User Device has long sent the stimulus.
990	   This is a situation where there is a 
 specification, but the
991	   "suppressed" attribute will not be "true" in the notification.  If
992	   there is a 
 tag that the User Device matched and the User Device
993	   is unable to suppress the User Input, it MUST set the "suppressed"
994	   attribute to "false".

996	   A KPML User Device MAY perform suppression.  If it is not capable of
997	   suppression, it ignores the suppression attribute.  It MUST set the
998	   "suppressed" attribute to "false".  In this case, the pattern to
999	   match is the concatenated pattern of pre+value.

1001	   At some point in time, the User Device will collect enough User Input
1002	   to the point it hits a 
 pattern.  The interdigittimer attribute
1003	   indicates how long to wait once the user enters stimulus before
1004	   reporting a time-out error.  If the interdigittimer expires, the User
1005	   Device MUST issue a time-out report, transmit the suppressed User
1006	   Input on the media stream, and stop suppression.

1008	   Once the User Device detects a match and it sends a NOTIFY request to
1009	   report the User Input, the User Device MUST stop suppression.
1010	   Clearly, if subsequent User Input matches another 
 expression,
1011	   then the User Device MUST start suppression.

1013	   After suppression begins, it may become clear that a match will not
1014	   occur.  For example, take the expression " 
*8xxx[2-9]xxxxxx".  At the point the User Device receives
1016	   "*8", it will stop forwarding stimulus.  Let us say that the next
1017	   three digits are "408".  If the next digit is a zero or one, the
1018	   pattern will not match.

1020	      NOTE: It is critically important for the User Device to have a
1021	      sensible inter-digit timer.  This is because an errant dot (".")
1022	      may suppress digit sending forever.  See Section 4.1 for setting
1023	      the inter-digit timer.

1025	   Applications should be very careful to indicate suppression only when
1026	   they are fairly sure the user will enter a digit string that will
1027	   match the regular expression.  In addition, applications should deal
1028	   with situations such as no-match or time-out.  This is because the
1029	   User Device will hold digits, which will have obvious user interface
1030	   issues in the case of a failure.

1032	4.1.4  One-Shot and Persistent Triggers

1034	   The KPML document specifies if the patterns are to be persistent by
1035	   setting the persistent attribute to the  tag to "persistent"
1036	   or "one-notify".  Any other value, including "one-shot", indicates
1037	   the request is a one-shot subscription.  If the User Device does not
1038	   support persistent subscriptions, it returns a KPML document with the
1039	   KPML result code set to 531.  If there are digits in the quarantine
1040	   buffer and the digits match an expression in the KPML document, the
1041	   User Device prepares the appropriate KPML document.

1043	   Note the values of the persistent attribute are case sensitive.

1045	4.1.5  Multiple Patterns

1047	   Some User Devices may support multiple regular expressions in a given
1048	   pattern request.  In this situation, the application may wish to know
1049	   which pattern triggered the event.

1051	   KPML provides a "tag" attribute to the  tag.  The "tag" is an
1052	   opaque string that the User Device sends back in the notification
1053	   report upon a match in the digit map.  In the case of multiple
1054	   matches, the User Device MUST chose the longest match in the KPML
1055	   document.  If multiple matches match the same length, the User Device
1056	   MUST chose the first expression listed in the subscription KPML
1057	   document based on KPML document order.

1059	   If the User Device does not support multiple regular expressions in a
1060	   pattern request, the User Device MUST return a KPML document with the
1061	   KPML result code set to 532.

1063	4.1.6  Monitoring Direction

1065	   By default, the User Device monitors key presses emanating from the
1066	   User Device.  Given a dialog identifier of Call-ID, local-tag, and
1067	   remote-tag, the User Device monitors the key presses associated with
1068	   the local-tag.

1070	   In the media proxy case, and potentially other cases, there is a need
1071	   to monitor the key presses arriving from the remote user agent.  The
1072	   optional  element to the >request> tag specifies which stream
1073	   to monitor.  The only legal value is "reverse", which means to
1074	   monitor the stream associated with the remote-tag.  The User Device
1075	   MUST ignore other values.
1076	      NOTE:  The reason this is a tag is so individual stream selection,
1077	      if needed, can be addressed in a backwards-compatible way.

1079	4.1.7  Multiple, Simultaneous Subscriptions

1081	   Some User Devices may support multiple key press event notification
1082	   subscriptions at the same time.  In this situation, the User Device
1083	   honors each subscription individually and independently.

1085	   A SIP user agent may request multiple subscriptions on the same
1086	   SUBSCRIBE dialog, using the id parameter to the kpml event request.

1088	   One or more SIP user agents may request independent subscriptions on
1089	   different SIP dialogs.  In the body of the SUBSCRIBE is a leg
1090	   parameter that indicates which leg to monitor.  Section 3.2 describes
1091	   the dialog addressing mechanism in detail.

1093	   If the User Device does not support multiple, simultaneous
1094	   subscriptions, the User Device MUST return a KPML document with the
1095	   KPML result code set to 533 on the dialog that requested the second
1096	   subscription.  The User Device MUST NOT modify the state of the first
1097	   subscription on the account of the second subscription attempt.

1099	4.2  KPML Reports

1101	   When the user enters key press(es) that match a  tag, the User
1102	   Device will issue a report.

1104	   After reporting, the interpreter terminates the KPML session unless
1105	   the subscription has a persistence indicator.  If the subscription
1106	   does not have a persistence indicator, the User Device MUST set the
1107	   state of the subscription to "terminated" in the NOTIFY report.

1109	   If the subscription does not have a persistence indicator, to collect
1110	   more digits the requestor must issue a new request.

1112	      NOTE: This highlights the "one shot" nature of KPML, reflecting
1113	      the balance of features and ease of implementing an interpreter.
1114	      If your goal is to build an IVR session, we strongly suggest you
1115	      investigate more appropriate technologies such as VoiceXML [11] or
1116	      MSCML [12].

1118	   KPML reports have two mandatory attributes, code and text.  These
1119	   attributes describe the state of the KPML interpreter on the User
1120	   Device.  Note the KPML code is not necessarily related to the SIP
1121	   result code.  An important example of this is where a legal SIP
1122	   subscription request gets a normal SIP 200 OK followed by a NOTIFY,
1123	   but there is something wrong with the KPML request.  In this case,
1124	   the NOTIFY would include the KPML failure code in the KPML report.
1125	   Note that from a SIP perspective, the SUBSCRIBE and NOTIFY were
1126	   successful.  Also, if the KPML failure is not recoverable, the User
1127	   Device will most likely set the Subscription-Sate to "terminated".
1128	   This lets the SIP machinery know the subscription is no longer
1129	   active.

1131	4.2.1  Pattern Match Reports

1133	   If a pattern matches, the User Device will emit a KPML report.  Since
1134	   this is a success report, the code is "200" and the text is "OK".

1136	   The KPML report includes the actual digits matched in the digit
1137	   attribute.  The digit string uses the conventional characters '*' and
1138	   '#' for star and octothorpe respectively.  The KPML report also
1139	   includes the tag attribute if the regex that matched the digits had a
1140	   tag attribute.

1142	   If the subscription requested digit suppression (Section 4.1.3) and
1143	   the User Device suppressed digits, the suppressed attribute indicates
1144	   "true".  The default value of suppressed is "false".

1146	      NOTE: KPML does not include a timestamp.  There are a number of
1147	      reasons for this.  First, what timestamp would in include?  Would
1148	      it be the time of the first detected key press?  The time the
1149	      interpreter collected the entire string?  A range?  Second, if the
1150	      RTP timestamp is a datum of interest, why not simply get RTP in
1151	      the first place?  That all said, if it is really compelling to
1152	      have the timestamp in the response, it could be an attribute to
1153	      the  tag.

1155	4.2.2  KPML No Match Reports

1157	   There are a few circumstances in which the User Device will emit a no
1158	   match report.  They are an immediate NOTIFY in response to SUBSCRIBE
1159	   request (no digits detected yet), a request for service not supported
1160	   by User Device, or a failure of a digit map to match a string
1161	   (timeout).

1163	4.2.2.1  Immediate NOTIFY

1165	   The NOTIFY in response to a SUBSCRIBE request has no KPML if there
1166	   are no matching quarantined digits.  An example of this is in Figure
1167	   10.

1169	   If there are quarantined digits in the SUBSCRIBE request that match a
1170	   pattern, then the NOTIFY message in response to the SUBSCRIBE request
1171	   MUST include the appropriate KPML document.

1173	   NOTIFY sip:application@example.com SIP/2.0
1174	   Via: SIP/2.0/UDP proxy.example.com
1175	   Max-Forwards: 70
1176	   To: 
1177	   From: 
1178	   Call-Id: 439hu409h4h09903fj0ioij
1179	   Subscription-State: active; expires=7200
1180	   CSeq: 49851 NOTIFY
1181	   Event: kpml

1183	                  Figure 10: Immediate NOTIFY Example

1185	5.  DRegex Syntax

1187	   The Digit REGular EXpression (DRegex) syntax follows the Unix egrep
1188	   and Java Regular Expression syntax.

1190	   DRegex is a proper superset of RFC3435 [18] syntax.  There are two
1191	   additions.  The first is Digit Not in Range ([^digits]).  This syntax
1192	   comes directly from egrep.  Not in Range enables the easy
1193	   specification of, for example, the North American Numbering Plan.
1194	   The second is the Java RegExp Repeat Indicator ({m,n}).  The Java
1195	   RegExp Repeat Indicator solves a serious deficiency in both RFC3235
1196	   and H.248.1 [17] regular expressions.  Namely, the dot rule does not
1197	   have any limit and could collect an infinite number of digits.  With
1198	   the repeat indicator, one can specify the minimum and maximum number
1199	   of digits or a pattern will match.

1201	   White space is removed before parsing DRegex.  This enables sensible
1202	   pretty printing in XML without affecting the meaning of the DRegex
1203	   string.

1205	   The following rules demonstrate the use of DRegex in KPML.  Section
1206	   6.1 describes the ABNF for DRegex.

1208	   +---------------------------------+---------------------------------+
1209	   | Entity                          | Matches                         |
1210	   +---------------------------------+---------------------------------+
1211	   | character                       | digits 0-9 and A-D (case        |
1212	   |                                 | insensitive)                    |
1213	   | *                               | *                               |
1214	   | #                               | #                               |
1215	   | [character selector]            | Any character in selector       |
1216	   | [^digit selector]               | Any digit (0-9) NOT in selector |
1217	   | [range1-range2]                 | Any digit (0-9) in range from   |
1218	   |                                 | range1 to range2, inclusive     |
1219	   | x                               | Any digit 0-9                   |
1220	   | .                               | Zero or more repetitions of     |
1221	   |                                 | previous pattern                |
1222	   | |                               | Alternation                     |
1223	   | {m}                             | m repetitions of previous       |
1224	   |                                 | pattern                         |
1225	   | {m,}                            | m or more repetitions of        |
1226	   |                                 | previous pattern                |
1227	   | {,n}                            | At most n (including zero)      |
1228	   |                                 | repetitions of previous pattern |
1229	   | {m,n}                           | at least m and at most n        |
1230	   |                                 | repetitions of previous pattern |
1231	   | Lc                              | Match the character c if it is  |
1232	   |                                 | "long"; c is a digit 0-9 and    |
1233	   |                                 | A-D, #, or *.                   |
1234	   +---------------------------------+---------------------------------+
1235	        +------------+-----------------------------------------+
1236	        | Example    | Description                             |
1237	        +------------+-----------------------------------------+
1238	        | 1          | Matches the digit 1                     |
1239	        | [179]      | Matches 1, 7, or 9                      |
1240	        | [^01]      | Matches 2, 3, 4, 5, 6, 7, 8, 9          |
1241	        | [2-9]      | Matches 2, 3, 4, 5, 6, 7, 8, 9          |
1242	        | x          | Matches 0, 1, 2, 3, 4, 5, 6, 7, 8, 9    |
1243	        | 2|3        | Matches 2 or 3; same as [23]            |
1244	        | 00|011     | Matches the string 00 or 011            |
1245	        | 0.         | Zero or more occurrences of 0           |
1246	        | [2-9].     | Zero or more occurrences of 2-9         |
1247	        | *6[179#]   | Matches *61, *67, *69, or *6#           |
1248	        | x{10}      | Ten digits (0-9)                        |
1249	        | 011x{7,15} | 011 followed by seven to fifteen digits |
1250	        | L*         | Long star                               |
1251	        +------------+-----------------------------------------+

1253	6.  Formal Syntax

1255	6.1  DRegex

1257	   The following definition follows RFC2234 [4].  The definition of
1258	   DIGIT is from the CORE specification of RFC2234, namely the
1259	   characters "0" through "9".  Note the DRegexCharacater is not a
1260	   HEXDIG from RFC2234.  In particular, DRegexCharacter neither includes
1261	   "E" nor "F".  Moreover DRegexCharacter is case insensitive, unlike
1262	   HEXDIG.

1264	   DRegex           = DRegexString *( "|" DRegexString )
1265	   DRegexString     = 1*( DRegexPosition [ RepeatCount ] )
1266	   DRegexPosition   = DRegexSymbol / DRegexSet
1267	   DRegexSet        = ( "[" DRegexSetList "]" ) /
1268	                      ( "[^" DigitList "]" )
1269	   DRegexSetList    = 1*( (DIGIT "-" DIGIT) / DRegexSymbol )
1270	   DigitList        = 1*( (DIGIT "-" DIGIT) / DIGIT )
1271	   DRegexSymbol     = DRegexCharacter / ( "L" DRegexCharacter )
1272	   RepeatCount      = "." / "{" RepeatRange "}"
1273	   RepeatRange      = Count / ( Count "," Count ) /
1274	                              ( Count "," ) / ( "," Count )
1275	   Count            = 1*(DIGIT)
1276	   DRegexCharacter  = DIGIT / "*" / "#" / "A" / "a" / "B" / "b" /
1277	                              "x" / "X" / "C" / "c" / "D" / "d"

1279	   Note that future extensions to this document may introduce other
1280	   characters for DRegexCharacter, in the scheme of H.248.1 [17] or
1281	   possibly as named strings or XML namespaces.

1283	6.2  KPML

1285	   The following syntax in Figure 12 uses the XML Schema [5].

1287	   
1288	   
1290	   
1295	    
1296	     
1297	      IETF Keypad Markup Language
1298	     
1299	     
1300	      
1301	       
1302	        
1303	         
1304	          
1305	          
1306	           
1307	            
1308	             
1309	              
1310	               Default is to not flush buffer
1311	               

1313	              
1314	              
1315	               
1316	                
1317	               
1318	              
1319	             
1320	             
1321	              
1322	               No default enter key
1323	               
1324	              
1325	              
1326	               
1327	                
1328	               
1329	              
1330	             
1331	             
1332	              
1333	               Key press notation is a string to
1334	                allow for future extension of non-16 digit keypads
1335	                or named keys
1336	               
1337	              
1338	              
1339	               
1340	                
1341	                 
1342	                  
1343	                   
1344	                  
1345	                 
1346	                
1347	               
1348	               
1350	              
1351	             
1352	            
1353	            
1354	             
1355	              Default is "one-shot"
1356	              
1357	             
1358	             
1359	              
1360	               
1361	               
1362	               
1363	              
1364	             
1365	            
1366	            
1368	             
1369	              Default is 4000 (ms)
1370	             
1371	            
1372	            
1374	             
1375	              Default is 1000 (ms)
1376	             
1377	            
1378	            
1380	             
1381	              Default is 500 (ms)
1382	             
1383	            
1384	            
1386	            
1388	            
1390	             
1391	              Default is false
1392	             
1393	            
1394	           
1395	          
1396	         
1397	        
1398	       
1399	       
1400	        
1401	         
1402	         
1403	         
1405	         
1407	          
1408	           String for future use for e.g., number
1409	            of digits lost.
1410	          
1411	         
1412	         
1413	         
1414	          
1415	           Matches tag from regex in request
1416	           
1417	          
1418	         
1419	        
1420	       
1421	      
1422	      
1423	     
1424	    
1425	   

1427	                     Figure 12: XML Schema for KPML

1429	7.  Enumeration of KPML Status Codes

1431	   KPML failure codes broadly follow their SIP counterparts.  Codes that
1432	   start with a 2 indicate success.  Codes that start with a 4 indicate
1433	   failure.  Codes that start with a 5 indicate a server failure,
1434	   usually a failure to interpret the document or to support a requested
1435	   feature.

1437	   KPML clients MUST be able to handle arbitrary status codes by
1438	   examining the first digit only.

1440	   Any text can be in a KPML report document.  KPML clients MUST NOT
1441	   interpret the text field.

1443	   +------+---------------------------------------------------------+
1444	   | Code | Text                                                    |
1445	   +------+---------------------------------------------------------+
1446	   | 200  | Success                                                 |
1447	   | 402  | User Terminated Without Match                           |
1448	   | 423  | Timer Expired                                           |
1449	   | 481  | Dialog (call leg) Not Found                             |
1450	   | 487  | Subscription Expired                                    |
1451	   | 501  | Bad Document                                            |
1452	   | 531  | Persistent Subscriptions Not Supported                  |
1453	   | 532  | Multiple or Alternate Regular Expressions Not Supported |
1454	   | 533  | Multiple Subscriptions on a Call Leg Not Supported      |
1455	   +------+---------------------------------------------------------+

1457	                      Table 3: KPML Failure Codes

1459	8.  IANA Considerations

1461	8.1  MIME Media Type application/kpml+xml

1463	   MIME media type name: application
1464	   MIME subtype name: kpml+xml
1465	   Required parameters: none
1466	   Optional parameters: charset

1468	      charset This parameter has identical semantics to the charset
1469	         parameter of the "application/xml" media type as specified in
1470	         XML Media Types [6].

1472	   Encoding considerations: See RFC3023 [6].

1474	   Interoperability considerations: See RFC2023 [6] and this document.

1476	   Published specification: This document.

1478	   Applications which use this media type: Session-oriented applications
1479	   that have primitive user interfaces.

1481	   Intended usage: COMMON

1483	8.2  URN Sub-Namespace Registration for urn:ietf:xml:ns:kpml

1485	   URI: urn:ietf:params:xml:ns:kpml

1487	   Registrant Contact: IETF, SIPPING Work Group , Eric
1488	   Burger .

1490	   XML:

1492	   
1493	   
1495	   
1496	     
1497	       
1499	       Key Press Markup Language
1500	     
1501	     
1502	       
Namespace for Key Press Markup Language

1503	       
urn:ietf:params:xml:ns:kpml

1504	       

1505	   RFCXXXX.
1506	       

1507	     
1508	   

1510	8.3  KPML Schema Registration

1512	   Per RFC3688 [7], please register the XML Schema for KPML as
1513	   referenced in Section 6.2.

1515	   URI: Please assign.

1517	   Registrant Contact: IETF, SIPPING Work Group , Eric
1518	   Burger .

1520	9.  Security Considerations

1522	   As an XML markup, all of the security considerations of RFC3023 [6]
1523	   and RFC3406 [8] apply.  Pay particular attention to the robustness
1524	   requirements of parsing XML.

1526	   Key press information is potentially sensitive.  Hijacking sessions
1527	   allow unauthorized entities access to this sensitive information.
1528	   Therefore, signaling SHOULD be secure, e.g., use of TLS and sips:
1529	   SHOULD be used.  Moreover, the information itself is sensitive.  Thus
1530	   if TLS is not used, S/MIME or other appropriate mechanism SHOULD be
1531	   used.

1533	   User Devices implementing this specification MUST implement TLS and
1534	   SHOULD implement S/MIME at a minimum.

1536	10.  Examples

1538	   This section is informative in nature.  If there is a discrepancy
1539	   between this section and the normative sections above, the normative
1540	   sections take precedence.

1542	10.1  Monitoring for Octothorpe

1544	   A common need for pre-paid and personal assistant applications is to
1545	   monitor a conversation for a signal indicating a change in user focus
1546	   from the party they called through the application to the application
1547	   itself.  For example, if you call a party using a pre-paid calling
1548	   card and the party you call redirects you to voice mail, digits you
1549	   press are for the voice mail system.  However, many applications have
1550	   a special key sequence, such as the octothorpe (#, or pound sign) or
1551	   *9 that terminate the called party leg and shift the user's focus to
1552	   the application.

1554	   Figure 14 shows the KPML for long octothorpe.

1556	   
1557	   
1561	     
1562	       
1563	         L#
1564	       
1565	     
1566	   

1568	                   Figure 14: Long Octothorpe Example

1570	   The regex value L indicates the following digit needs to be a
1571	   long-duration key press.

1573	10.2  Dial String Collection

1575	   In this example, the User Device collects a dial string.  The
1576	   application uses KPML to quickly determine when the user enters a
1577	   target number.  In addition, KPML indicates what type of number the
1578	   user entered.

1580	   
1581	   
1585	     
1586	       
1587	         0
1588	         00
1589	         7[x][x][x]
1590	         9xxxxxxx
1591	         9401xxxxxxx
1592	         9xxxxxxxxxx
1593	         91xxxxxxxxxx
1594	         011x.
1595	       
1596	     
1597	   

1599	                Figure 15: Dial String KPML Example Code

1601	   Note the use of the "tag" attribute to indicate which regex matched
1602	   the dialed string.  The interesting case here is if the user entered
1603	   "94015551212".  This string matches both the "9401xxxxxxx" and
1604	   "9xxxxxxxxxx" regular expressions.  By following the rules described
1605	   in Section 4.1.5, the KPML interpreter will pick the "9401xxxxxxx"
1606	   string, as it occurs first in document order (both expressions match
1607	   the same length).  Figure 16 shows the response.

1609	   
1610	   
1614	     
1616	   

1618	                  Figure 16: Dial String KPML Response

1620	10.3  Interactive Digit Collection

1622	   This is an example where one would probably be better off using a
1623	   full scripting language such as VoiceXML [11] or MSCML [12] or a
1624	   device control language such as H.248.1 [17].

1626	   In this example, an application requests the User Device to send the
1627	   user's signaling directly to the platform in HTTP, rather than
1628	   monitoring the entire RTP stream.  Figure 17 shows a voice mail menu,
1629	   where presumably the application played a "Press K to keep the
1630	   message, R to replay the message, and D to delete the message"
1631	   prompt.  In addition, the application does not want the user to be
1632	   able to barge the prompt.

1634	   
1635	   
1639	     
1640	       
1641	         yes
1642	         5
1643	         7
1644	         3
1645	       
1646	     
1647	   

1649	                    Figure 17: IVR KPML Example Code

1651	      NOTE: This usage of KPML is clearly inferior to using a device
1652	      control protocol like H.248.1.  From the application's point of
1653	      view, it has to do the low-level prompt-collect logic.  Granted,
1654	      it is relatively easy to change the key mappings for a given menu.
1655	      However, often more of the call flow than a given menu mapping
1656	      gets changed.  Thus there would be little value in such a mapping
1657	      to KPML.  We STRONGLY suggest using a real scripting language such
1658	      as VoiceXML or MSCML for this purpose.

1660	11.  Call Flow Example

1662	11.1  INVITE-Initiated Dialog

1664	   This section describes a successful subscription and notification
1665	   from an Application with an User Device ("User A") in an
1666	   INVITE-Initiated dialog.  Note the Application can be a Record-Route
1667	   Proxy, a B2BUA, or another User Device.

1669	   User A	       Application
1670	     |                |
1671	     |    INVITE F1   |
1672	     |--------------->|
1673	     |  100 TRYING F2 |
1674	     |<---------------|
1675	     |     180 F3     |
1676	     |<---------------|
1677	     |    200 OK F4   |
1678	     |<---------------|
1679	     |      ACK F5    |
1680	     |--------------->|
1681	     |  Media Session |
1682	     |<==============>|
1683	     | SUBSCRIBE F6   |   Application Subscribes to "***" from User A
1684	     |<---------------|
1685	     |   200 OK F7    |
1686	     |--------------->|
1687	     |   NOTIFY F8    |   Immediate Notify indicating monitoring
1688	     |--------------->|
1689	     |   200 OK F9    |
1690	     |<---------------|
1691	     |       .        |
1692	     |       :        |
1693	     |   NOTIFY F10   |
1694	     |--------------->|   Notification of detection of "***"
1695	     |   200 OK F11   |
1696	     |<---------------|
1697	     |                |

1699	   Connection setup between User A and an Application subscribing to a
1700	   DTMF event of "***" at User A.

1702	   F1 INVITE User A --> Application

1704	         INVITE sip:UserB@subB.example.com SIP/2.0
1705	         Via: SIP/2.0/UDP client.subA.example.com:5060;branch=z9hG4bK74
1706	         Max-Forwards: 70
1707	         From: ;tag=1234567
1708	         To: 
1709	         Call-ID: 12345601@subA.example.com
1710	         CSeq: 1 INVITE
1711	         Contact: 
1712	         Route: 
1713	         Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, SUBCRIBE, NOTIFY
1714	         Allow-Events: kpml
1715	         Supported: replaces
1716	         Content-Type: application/sdp
1717	         Content-Length: ...

1719	         v=0
1720	         o=UserA 2890844526 2890844526 IN IP4 client.subA.example.com
1721	         s=Session SDP
1722	         c=IN IP4 client.subA.example.com
1723	         t=3034423619 0
1724	         m=audio 49170 RTP/AVP 0
1725	         a=rtpmap:0 PCMU/8000

1727	   F2 100 Trying Application --> User A

1729	         SIP/2.0 100 Trying
1730	         Via: SIP/2.0/UDP client.subA.example.com:5060;branch=z9hG4bK74
1731	           ;received=192.168.12.22
1732	         From: ;tag=1234567
1733	         To: 
1734	         Call-ID: 12345601@subA.example.com
1735	         CSeq: 1 INVITE
1736	         Content-Length: 0

1738	   F3 180 Ringing Application --> User A

1740	         SIP/2.0 180 Ringing
1741	         Via: SIP/2.0/UDP client.subA.example.com:5060;branch=z9hG4bK74
1742	           ;received=192.168.12.22
1743	         Record-Route: 
1744	         From: ;tag=1234567
1745	         To: ;tag=567890
1746	         Call-ID: 12345601@subA.example.com
1747	         CSeq: 1 INVITE
1748	         Contact: 
1749	         Content Length: 0

1751	   F4 200 OK Application --> User A

1753	         SIP/2.0 200 OK
1754	         Via: SIP/2.0/UDP client.subA.example.com:5060;branch=z9hG4bK74
1755	           ;received=192.168.12.22
1756	         Record-Route: 
1757	         From: ;tag=1234567
1758	         To: ;tag=567890
1759	         Call-ID: 12345601@subA.example.com
1760	         CSeq: 1 INVITE
1761	         Contact: 
1762	         Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, SUBSCRIBE, NOTIFY
1763	         Supported: replaces
1764	         Content-Type: application/sdp
1765	         Content-Length: ...

1767	         v=0
1768	         o=UserB 2890844527 2890844527 IN IP4 client.subB.example.com
1769	         s=Session SDP
1770	         c=IN IP4 client.subB.example.com
1771	         t=3034423619 0
1772	         m=audio 3456 RTP/AVP 0
1773	         a=rtpmap:0 PCMU/8000

1775	   F5 ACK User A --> Application

1777	         ACK sip:UserB@subB.example.com SIP/2.0
1778	         Via: SIP/2.0/UDP client.subA.example.com:5060;branch=z9hG4bK74
1779	         Max-Forwards: 70
1780	         Route: 
1781	         From: ;tag=1234567
1782	         To: ;tag=567890
1783	         Call-ID: 12345601@subA.example.com
1784	         CSeq: 1 ACK
1785	         Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
1786	         Supported: replaces
1787	         Content-Length: 0

1789	   F6 SUBSCRIBE Application --> User A

1791	         SUBSCRIBE sip:UserA@subA.example.com SIP/2.0
1792	         Max-Forwards: 70
1793	         From: ;tag=567890
1794	         To: ;tag=1234567
1795	         Call-ID: 12345601@subA.example.com
1796	         CSeq: 1 SUBSCRIBE
1797	         Contact: 
1798	         Event: kpml
1799	         Expires: 7200
1800	         Accept: application/kpml+xml
1801	         Content-Type: application/kmpl+xml
1802	         Content-Length: ...

1804	         
1805	         

1810	           
1811	             
1812	               
1813	             
1814	           
1815	         

1817	   F7 200 OK User A --> Application

1819	         SIP/2.0 200 OK
1820	         To: ;tag=1234567
1821	         From: ;tag=567890
1822	         Call-ID: 12345601@subA.example.com
1823	         CSeq: 1 SUBSCRIBE
1824	         Contact: 
1825	         Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, SUBSCRIBE, NOTIFY
1826	         Supported: replaces
1827	         Content-Length: 0

1829	   F8 NOTIFY User A --> Application

1831	         NOTIFY sip:UserB@subB.example.com SIP/2.0
1832	         Max-Forwards: 70
1833	         From: ;tag=1234567
1834	         To: ;tag=567890
1835	         Call-ID: 12345601@subA.example.com
1836	         CSeq: 2 NOTIFY
1837	         Subscription-State: active;expires=3600
1838	         Content-Type: application/kpml+xml
1839	         Content-Length: ...
1840	         Event: kpml

1842	         
1843	         
1847	           
1848	         

1850	   F9 200 OK Application --> User A

1852	         SIP/2.0 200 OK
1853	         From: ;tag=1234567
1854	         To: ;tag=567890
1855	         Call-ID: 12345601@subA.example.com
1856	         CSeq: 2 NOTIFY
1857	         Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, SUBSCRIBE, NOTIFY
1858	         Supported: replaces
1859	         Content-Type: application/sdp
1860	         Content-Length: 0

1862	   F10 NOTIFY User A --> Application

1864	         NOTIFY sip:UserB@subB.example.com SIP/2.0
1865	         Max-Forwards: 70
1866	         From: ;tag=1234567
1867	         To: ;tag=567890
1868	         Call-ID: 12345601@subA.example.com
1869	         CSeq: 3 NOTIFY
1870	         Subscription-State: active;expires=3125
1871	         Content-Type: application/kpml+xml
1872	         Content-Length: ...
1873	         Event: kpml

1875	         
1876	         
1880	           
1882	         

1884	   F11 200 OK Application --> User A

1886	         SIP/2.0 200 OK
1887	         From: ;tag=1234567
1888	         To: 
1889	         Call-ID: 12345601@subA.com
1890	         JVD: CSeq: 3 NOTIFY
1891	         Contact: 
1892	         Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, SUBSCRIBE, NOTIFY
1893	         Supported: replaces
1894	         Content-Type: application/sdp
1895	         Content-Length: 0

1897	11.2  Third-Party Subscription

1899	   Coming soon!

1901	11.3  Remote-End Monitoring

1903	   Coming soon!

1905	12.  References

1907	12.1  Normative References

1909	   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
1910	        Levels", BCP 14, RFC 2119, March 1997.

1912	   [2]  Roach, A., "Session Initiation Protocol (SIP)-Specific Event
1913	        Notification", RFC 3265, June 2002.

1915	   [3]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
1916	        Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
1917	        Session Initiation Protocol", RFC 3261, June 2002.

1919	   [4]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
1920	        Specifications: ABNF", RFC 2234, November 1997.

1922	   [5]  Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML
1923	        Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502,
1924	        May 2001.

1926	   [6]  Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
1927	        3023, January 2001.

1929	   [7]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
1930	        2004.

1932	   [8]  Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom,
1933	        "Uniform Resource Names (URN) Namespace Definition Mechanisms",
1934	        BCP 66, RFC 3406, October 2002.

1936	12.2  Informative References

1938	   [9]   Rosenberg, J., "A Framework for Application Interaction in the
1939	         Session Initiation Protocol  (SIP)",
1940	         draft-ietf-sipping-app-interaction-framework-01 (work in
1941	         progress), February 2004.

1943	   [10]  Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
1944	         "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
1945	         REC REC-xml-20001006, October 2000.

1947	   [11]  World Wide Web Consortium, "Voice Extensible Markup Language
1948	         (VoiceXML) Version 2.0", W3C Working Draft , April 2002,
1949	         .

1951	   [12]  Burger, E., Van Dyke, J. and A. Spitzer, "Media Server Control
1952	         Markup Language (MSCML) and Protocol", draft-vandyke-mscml-04
1953	         (work in progress), March 2004.

1955	   [13]  Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
1956	         Telephony Tones and Telephony Signals", RFC 2833, May 2000.

1958	   [14]  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
1959	         "RTP: A Transport Protocol for Real-Time Applications", RFC
1960	         1889, January 1996.

1962	   [15]  Rosenberg, J., "Obtaining and Using Globally Routable User
1963	         Agent (UA) URIs (GRUU) in the  Session Initiation Protocol
1964	         (SIP)", draft-ietf-sip-gruu-01 (work in progress), February
1965	         2004.

1967	   [16]  Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog
1968	         Event Package for the Session Initiation  Protocol (SIP",
1969	         draft-ietf-sipping-dialog-package-02 (work in progress), June
1970	         2003.

1972	   [17]  Groves, C., Pantaleo, M., Anderson, T. and T. Taylor, "Gateway
1973	         Control Protocol Version 1", RFC 3525, June 2003.

1975	   [18]  Andreasen, F. and B. Foster, "Media Gateway Control Protocol
1976	         (MGCP) Version 1.0", RFC 3435, January 2003.

1978	   [19]  Handley, M. and V. Jacobson, "SDP: Session Description
1979	         Protocol", RFC 2327, April 1998.

1981	   [20]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
1982	         Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
1983	         HTTP/1.1", RFC 2616, June 1999.

1985	   [21]  Olson, S., Camarillo, G. and A. Roach, "Support for IPv6 in
1986	         Session Description Protocol (SDP)", RFC 3266, June 2002.

1988	   [22]  Hunt, A. and S. McGlashan, "Speech Recognition Grammar
1989	         Specification Version 1.0", W3C CR CR-speech-grammar-20020626,
1990	         June 2002.

1992	   [23]  Burger (Ed.), E., Van Dyke, J. and A. Spitzer, "Basic Network
1993	         Media Services with SIP", draft-burger-sipping-netann-08 (work
1994	         in progress), February 2004.

1996	Authors' Addresses

1998	   Eric Burger
1999	   SnowShore Networks, Inc.
2000	   285 Billerica Rd.
2001	   Chelmsford, MA  01824-4120
2002	   USA

2004	   EMail: e.burger@ieee.org

2006	   Martin Dolly
2007	   AT&T Labs

2009	   EMail: mdolly@att.com

2011	Appendix A.  Contributors

2013	   Ophir Frieder of the Illinois Institute of Technology collaborated on
2014	   the development of the quarantine algorithm.

2016	   Jeff Van Dyke worked enough hours and wrote enough text to be
2017	   considered an author under the old rules.

2019	   Robert Fairlie-Cuninghame, Cullen Jennings, Jonathan Rosenberg, and I
2020	   were the members of the Application Stimulus Signaling Design Team.
2021	   All members of the team contributed to this work.  In addition,
2022	   Jonathan Rosenberg postulated DML in his "A Framework for Stimulus
2023	   Signaling in SIP Using Markup" draft.

2025	   This version of KPML has significant influence from MSCML, the
2026	   SnowShore Media Server Control Markup Language.  Jeff Van Dyke and
2027	   Andy Spitzer were the primary contributors to that effort.

2029	   That said, any errors, misinterpretation, or fouls in this document
2030	   are my own.

2032	Appendix B.  Acknowledgements

2034	   Hal Purdy and Eric Cheung of AT&T Laboratories helped immensely
2035	   through many conversations and challenges.

2037	   Steve Fisher of AT&T Laboratories suggested the digit suppression
2038	   syntax and provided excellent review of the document.

2040	   Terence Lobo of SnowShore Networks made it all work.

2042	   Jerry Kamitses, Swati Dhuleshia, Shaun Bharrat, Sunil Menon, and
2043	   Bryan Hill helped with clarifying the quarantine behavior and DRegex
2044	   syntax.

2046	Intellectual Property Statement

2048	   The IETF takes no position regarding the validity or scope of any
2049	   intellectual property or other rights that might be claimed to
2050	   pertain to the implementation or use of the technology described in
2051	   this document or the extent to which any license under such rights
2052	   might or might not be available; neither does it represent that it
2053	   has made any effort to identify any such rights.  Information on the
2054	   IETF's procedures with respect to rights in standards-track and
2055	   standards-related documentation can be found in BCP-11.  Copies of
2056	   claims of rights made available for publication and any assurances of
2057	   licenses to be made available, or the result of an attempt made to
2058	   obtain a general license or permission for the use of such
2059	   proprietary rights by implementors or users of this specification can
2060	   be obtained from the IETF Secretariat.

2062	   The IETF invites any interested party to bring to its attention any
2063	   copyrights, patents or patent applications, or other proprietary
2064	   rights which may cover technology that may be required to practice
2065	   this standard.  Please address the information to the IETF Executive
2066	   Director.

2068	   The IETF has been notified of intellectual property rights claimed in
2069	   regard to some or all of the specification contained in this
2070	   document.  For more information consult the online list of claimed
2071	   rights.

2073	Full Copyright Statement

2075	   Copyright (C) The Internet Society (2004).  All Rights Reserved.

2077	   This document and translations of it may be copied and furnished to
2078	   others, and derivative works that comment on or otherwise explain it
2079	   or assist in its implementation may be prepared, copied, published
2080	   and distributed, in whole or in part, without restriction of any
2081	   kind, provided that the above copyright notice and this paragraph are
2082	   included on all such copies and derivative works.  However, this
2083	   document itself may not be modified in any way, such as by removing
2084	   the copyright notice or references to the Internet Society or other
2085	   Internet organizations, except as needed for the purpose of
2086	   developing Internet standards in which case the procedures for
2087	   copyrights defined in the Internet Standards process must be
2088	   followed, or as required to translate it into languages other than
2089	   English.

2091	   The limited permissions granted above are perpetual and will not be
2092	   revoked by the Internet Society or its successors or assignees.

2094	   This document and the information contained herein is provided on an
2095	   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2096	   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2097	   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2098	   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2099	   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

2101	Acknowledgment

2103	   Funding for the RFC Editor function is currently provided by the
2104	   Internet Society.