Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4730

A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)

Pages: 56
Proposed Standard
Errata
Part 3 of 3 – Pages 37 to 56
First   Prev   None

Top   ToC   RFC4730 - Page 37   prevText

8. Security Considerations

The user information transported by KPML is potentially sensitive. For example, it could include calling card or credit card numbers. This potentially private information could be provided accidentally if the notifier does not properly authenticate or authorize a subscription. Similarly private information (such as a credit card number or calling card number) could be revealed to an otherwise legitimate subscriber (one operating an IVR) if digits buffered earlier in the session are provided unintentionally to the new subscriber. Likewise, an eavesdropper could view KPML digit information if it is not encrypted, or an attacker could inject fraudulent notifications unless the messages or the SIP path over which they travel are integrity protected. Therefore, User Interfaces MUST NOT downgrade their own security policy. That is, if a User Interface policy is to restrict notifications to authenticated and authorized subscribers over secure communications, then the User Interface must not accept an unauthenticated, unauthorized subscription over an insecure communication channel. As an XML markup, all of the security considerations of RFC 3023 [3] and RFC 3406 [6] MUST be met. Pay particular attention to the robustness requirements of parsing XML.
Top   ToC   RFC4730 - Page 38
   Key press information is potentially sensitive.  For example, it can
   represent credit card, calling card, or other personal information.
   Hijacking sessions allow unauthorized entities access to this
   sensitive information.  Therefore, signaling SHOULD be secure, e.g.,
   use of TLS and sips: SHOULD be used.  Moreover, the information
   itself is sensitive so S/MIME or other appropriate mechanisms SHOULD
   be used.

   Subscriptions MUST be authenticated in some manner.  As required by
   the core SIP [4] specification, all SIP implementations MUST support
   digest authentication.  In addition, User Interfaces MUST implement
   support for the sips: scheme and SIP over TLS.  Subscribers MUST
   expect the User Interface to demand the use of an authentication
   scheme.  If the local policy of a User Interface is to use
   authentication or secure communication channels, the User Interface
   MUST reject subscription requests that do not meet that policy.

   User Interfaces MUST begin buffering User Input upon receipt of an
   authenticated and accepted subscription.  This buffering is done on a
   per-subscription basis.

9. Examples

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

9.1. Monitoring for Octothorpe

A common need for pre-paid and personal assistant applications is to monitor a conversation for a signal indicating a change in user focus from the party they called through the application to the application itself. For example, if you call a party using a pre-paid calling card, and the party you call redirects you to voice mail, digits you press are for the voice mail system. However, many applications have a special key sequence, such as the octothorpe (#, or pound sign) or *9, that terminate the called party session and shift the user's focus to the application.
Top   ToC   RFC4730 - Page 39
   Figure 16 shows the KPML for long octothorpe.

   <?xml version="1.0"?>
   <kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation=
           "urn:ietf:params:xml:ns:kpml-request kpml-request.xsd"
         version="1.0">
     <pattern>
       <regex>L#</regex>
     </pattern>
   </kpml-request>

                    Figure 16: Long Octothorpe Example

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

9.2. Dial String Collection

In this example, the User Interface collects a dial string. The application uses KPML to quickly determine when the user enters a target number. In addition, KPML indicates what type of number the user entered. <?xml version="1.0"?> <kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "urn:ietf:params:xml:ns:kpml-request kpml-request.xsd" version="1.0"> <pattern> <regex tag="local-operator">0</regex> <regex tag="ld-operator">00</regex> <regex tag="vpn">7[x][x][x]</regex> <regex tag="local-number7">9xxxxxxx</regex> <regex tag="RI-number">9401xxxxxxx</regex> <regex tag="local-number10">9xxxxxxxxxx</regex> <regex tag="ddd">91xxxxxxxxxx</regex> <regex tag="iddd">011x.</regex> </pattern> </kpml-request> Figure 17: Dial String KPML Example Code Note the use of the "tag" attribute to indicate which regex matched the dialed string. The interesting case here is if the user entered "94015551212". This string matches both the "9401xxxxxxx" and
Top   ToC   RFC4730 - Page 40
   "9xxxxxxxxxx" regular expressions.  Both expressions are the same
   length.  Thus the KPML interpreter will pick the "9401xxxxxxx"
   string, as it occurs first in document order.  Figure 18 shows the
   response.

   <?xml version="1.0"?>
   <kpml-response xmlns="urn:ietf:params:xml:ns:kpml-resposne"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation=
           "urn:ietf:params:xml:ns:kpml-response kpml-response.xsd"
         version="1.0"
         code="200" text="OK"
         digits="94015551212" tag="RI-number"/>

                   Figure 18: Dial String KPML Response

10. Call Flow Examples

10.1. Supplemental Digits

This section gives a non-normative example of an application that collects supplemental digits. Supplemental digit collection is where the network requests additional digits after the caller enters the destination address. A typical supplemental dial string is four digits in length.
Top   ToC   RFC4730 - Page 41
   Ingress Gateway      Application Server       Egress Gateway
          |                      |                      |
          |                      |                      |
          |                      |                      |
          |(1) INVITE            |                      |
          |-------------------------------------------->|
          |                      |                      |
          |                      |                      |
          |(2) 200 OK            |                      |
          |<--------------------------------------------|
          |                      |                      |
          |                      |                      |
          |(3) ACK               |                      |
          |-------------------------------------------->|
          |                      |                      |
          |                      |                      |
          |(4) SUBSCRIBE (one-shot)                     |
          |<---------------------|                      |
          |                      |                      |
          |                      |                      |
          |(5) 200 OK            |                      |
          |--------------------->|                      |
          |                      |                      |
          |                      |                      |
          |(6) NOTIFY            |                      |
          |--------------------->|                      |
          |                      |                      |
          |                      |                      |
          |(7) 200 OK            |                      |
          |<---------------------|                      |
          |                      |                      |
          |                      |                      |
          |(8)                   |                      |
          |......................|                      |
          |                      |                      |
          |                      |                      |
          |(9) NOTIFY (digits)   |                      |
          |--------------------->|                      |
          |                      |                      |
          |                      |                      |
          |(10) 200 OK           |                      |
          |<---------------------|                      |
          |                      |                      |
          |                      |                      |
          |                      |                      |
          |                      |                      |

                 Figure 19: Supplemental Digits Call Flow
Top   ToC   RFC4730 - Page 42
   In messages (1-3), the ingress gateway establishes a dialog with an
   egress gateway.  The application learns the dialog ID through out-of-
   band mechanisms, such as the Dialog Package or being co-resident with
   the egress gateway.  Part of the ACK message is below, to illustrate
   the dialog identifiers.

   ACK sip:gw@subA.example.com SIP/2.0
   Via: ...
   Max-Forwards: ...
   Route: ...
   From: <sip:phn@example.com>;tag=jfh21
   To: <sip:gw@subA.example.com>;tag=onjwe2
   Call-ID: 12345592@subA.example.com
   ...

   In message (4), the application the requests that gateway collect a
   string of four key presses.

   SUBSCRIBE sip:gw@subA.example.com SIP/2.0
   Via: SIP/2.0/TCP client.subB.example.com;branch=q4i9ufr4ui3
   From: <sip:ap@subB.example.com>;tag=567890
   To: <sip:gw@subA.example.com>
   Call-ID: 12345601@subA.example.com
   CSeq: 1 SUBSCRIBE
   Contact: <sip:ap@client.subB.example.com>
   Max-Forwards: 70
   Event: kpml ;remote-tag="sip:phn@example.com;tag=jfh21"
               ;local-tag="sip:gw@subA.example.com;tag=onjwe2"
               ;call-id="12345592@subA.example.com"
   Expires: 7200
   Accept: application/kpml-response+xml
   Content-Type: application/kpml-request+xml
   Content-Length: 292

   <?xml version="1.0" encoding="UTF-8"?>
   <kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation=
         "urn:ietf:params:xml:ns:kpml-request kpml-request.xsd"
       version="1.0">
     <pattern persist="one-shot">
       <regex>xxxx</regex>
     </pattern>
   </kpml-request>
Top   ToC   RFC4730 - Page 43
   Message (5) is the acknowledgement of the subscription request.

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP subB.example.com;branch=q4i9ufr4ui3;
        received=192.168.125.12
   From: <sip:ap@subB.example.com>;tag=567890
   To: <sip:gw@subA.example.com>;tag=1234567
   Call-ID: 12345601@subA.example.com
   CSeq: 1 SUBSCRIBE
   Contact: <sip:gw27@subA.example.com>
   Expires: 3600
   Event: kpml

   Message (6) is the immediate notification of the subscription.

   NOTIFY sip:ap@client.subB.example.com SIP/2.0
   Via: SIP/2.0/UDP subA.example.com;branch=gw27id4993
   To: <sip:ap@subB.example.com>;tag=567890
   From: <sip:gw@subA.example.com>;tag=1234567
   Call-ID: 12345601@subA.example.com
   CSeq: 1000 NOTIFY
   Contact: <sip:gw27@subA.example.com>
   Event: kpml
   Subscription-State: active;expires=3599
   Max-Forwards: 70
   Content-Length: 0

   Message (7) is the acknowledgement of the notification message.

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP subA.example.com;branch=gw27id4993
   To: <sip:ap@subB.example.com>;tag=567890
   From: <sip:gw@subA.example.com>;tag=1234567
   Call-ID: 12345601@subA.example.com
   CSeq: 1000 NOTIFY

   Some time elapses (8).

   The user enters the input.  The device provides the notification of
   the collected digits in message (9).  Since this was a one-shot
   subscription, note the Subscription-State is "terminated".
Top   ToC   RFC4730 - Page 44
   NOTIFY sip:ap@client.subB.example.com SIP/2.0
   Via: SIP/2.0/UDP subA.example.com;branch=gw27id4993
   To: <sip:ap@subB.example.com>;tag=567890
   From: <sip:gw@subA.example.com>;tag=1234567
   Call-ID: 12345601@subA.example.com
   CSeq: 1001 NOTIFY
   Contact: <sip:gw27@subA.example.com>
   Event: kpml
   Subscription-State: terminated
   Max-Forwards: 70
   Content-Type: application/kpml-response+xml
   Content-Length: 258

   <?xml version="1.0" encoding="UTF-8"?>
   <kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation=
           "urn:ietf:params:xml:ns:kpml-response kpml-response.xsd"
         version="1.0"
         code="200" text="OK"
         digits="4336"/>

   Message (10) is the acknowledgement of the notification.

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP subA.example.com;branch=gw27id4993
   To: <sip:ap@subB.example.com>;tag=567890
   From: <sip:gw@subA.example.com>;tag=1234567
   Call-ID: 12345601@subA.example.com
   CSeq: 1001 NOTIFY
Top   ToC   RFC4730 - Page 45

10.2. Multiple Applications

This section gives a non-normative example of multiple applications. One application collects a destination number to call. That application then waits for a "long pound." During the call, the call goes to a personal assistant application, which interacts with the user. In addition, the personal assistant application looks for a "short pound." For clarity, we do not show the INVITE dialogs. Gateway Card Application Personal Assistant | | | | | | | | | |(1) SUBSCRIBE (persistent) | |<---------------------| | | | | | | | |(2) 200 OK | | |--------------------->| | | | | | | | |(3) NOTIFY | | |--------------------->| | | | | | | | |(4) 200 OK | | |<---------------------| | | | | | | | |(5) | | |......................| | | | | | | | |(6) NOTIFY (tag=card) | | |--------------------->| | | | | | | | |(7) 200 OK | | |<---------------------| | | | | | | | |(8) | | |......................| | | | | | | | |(9) NOTIFY (tag=number) |
Top   ToC   RFC4730 - Page 46
      |--------------------->|                      |
      |                      |                      |
      |                      |                      |
      |(10) 200 OK           |                      |
      |<---------------------|                      |
      |                      |                      |
      |                      |                      |
      |(11) SUBSCRIBE        |                      |
      |<--------------------------------------------|
      |                      |                      |
      |                      |                      |
      |(12) 200 OK           |                      |
      |-------------------------------------------->|
      |                      |                      |
      |                      |                      |
      |(13) NOTIFY           |                      |
      |-------------------------------------------->|
      |                      |                      |
      |                      |                      |
      |(14) 200 OK           |                      |
      |<--------------------------------------------|
      |                      |                      |
      |                      |                      |
      |(15)                  |                      |
      |.............................................|
      |                      |                      |
      |                      |                      |
      |(16) NOTIFY (tag=number)                     |
      |-------------------------------------------->|
      |                      |                      |
      |                      |                      |
      |(17) 200 OK           |                      |
      |<--------------------------------------------|
      |                      |                      |
      |                      |                      |
      |(18)                  |                      |
      |.............................................|
      |                      |                      |
      |                      |                      |
      |(19) NOTIFY (tag=#)   |                      |
      |-------------------------------------------->|
      |                      |                      |
      |                      |                      |
      |(20) 200 OK           |                      |
      |<--------------------------------------------|
      |                      |                      |
      |                      |                      |
      |(21)                  |                      |
Top   ToC   RFC4730 - Page 47
      |.............................................|
      |                      |                      |
      |                      |                      |
      |(22) NOTIFY (tag=number)                     |
      |-------------------------------------------->|
      |                      |                      |
      |                      |                      |
      |(23) 200 OK           |                      |
      |<--------------------------------------------|
      |                      |                      |
      |                      |                      |
      |(24)                  |                      |
      |.............................................|
      |                      |                      |
      |                      |                      |
      |(25) NOTIFY (L#)      |                      |
      |--------------------->|                      |
      |                      |                      |
      |                      |                      |
      |(26) 200 OK           |                      |
      |<---------------------|                      |
      |                      |                      |
      |                      |                      |
      |                      |                      |
      |                      |                      |

                 Figure 27: Multiple Application Call Flow

   Message (1) is the subscription request for the card number.

   SUBSCRIBE sip:gw@subA.example.com SIP/2.0
   Via: SIP/2.0/TCP client.subB.example.com;branch=3qo3j0ouq
   From: <sip:ap@subB.example.com>;tag=978675
   To: <sip:gw@subA.example.com>
   Call-ID: 12345601@subA.example.com
   CSeq: 20 SUBSCRIBE
   Contact: <sip:ap@client.subB.example.com>
   Max-Forwards: 70
   Event: kpml ;remote-tag="<sip:phn@example.com;tag=jfi23>"
               ;local-tag="sip:gw@subA.example.com;tag=oi43jfq"
               ;call-id="12345598@subA.example.com"
   Expires: 7200
   Accept: application/kpml-response+xml
   Content-Type: application/kpml-request+xml
   Content-Length: 339
Top   ToC   RFC4730 - Page 48
   <?xml version="1.0" encoding="UTF-8"?>
   <kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation=
           "urn:ietf:params:xml:ns:kpml-request kpml-request.xsd"
         version="1.0">
     <pattern persist="persist">
       <regex tag="card">x{16}</regex>
       <regex tag="number">x{10}</regex>
     </pattern>
   </kpml-request>

   Messages (2-4) are not shown, for brevity.  Message (6) is the
   notification of the card number.

   NOTIFY sip:ap@client.subB.example.com SIP/2.0
   Via: SIP/2.0/UDP subA.example.com;branch=3qo3j0ouq
   To: <sip:ap@subB.example.com>;tag=978675
   From: <sip:gw@subA.example.com>;tag=9783453
   Call-ID: 12345601@subA.example.com
   CSeq: 3001 NOTIFY
   Contact: <sip:gw27@subA.example.com>
   Event: kpml
   Subscription-State: active;expires=3442
   Max-Forwards: 70
   Content-Type: application/kpml-response+xml
   Content-Length: 271

   <?xml version="1.0" encoding="UTF-8"?>
   <kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation=
           "urn:ietf:params:xml:ns:kpml-response kpml-response.xsd"
         version="1.0"
         code="200" text="OK"
         digits="9999888877776666"/>
Top   ToC   RFC4730 - Page 49
   Message (7) is the acknowledgement of the notification.  Time goes by
   in (8).  Message (9) is the notification of the dialed number.

   NOTIFY sip:ap@client.subB.example.com SIP/2.0
   Via: SIP/2.0/UDP subA.example.com;branch=3qo3j0ouq
   To: <sip:ap@subB.example.com>;tag=978675
   From: <sip:gw@subA.example.com>;tag=9783453
   Call-ID: 12345601@subA.example.com
   CSeq: 3001 NOTIFY
   Contact: <sip:gw27@subA.example.com>
   Event: kpml
   Subscription-State: active;expires=3542
   Max-Forwards: 70
   Content-Type: application/kpml-response+xml
   Content-Length: 278

   <?xml version="1.0" encoding="UTF-8"?>
   <kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation=
           "urn:ietf:params:xml:ns:kpml-response kpml-response.xsd"
         version="1.0"
         code="200" text="OK"
         digits="2225551212" tag="number"/>

   Message (11) is the request for long-pound monitoring.

   SUBSCRIBE sip:gw@subA.example.com SIP/2.0
   Via: SIP/2.0/TCP client.subB.example.com;branch=3qo3j0ouq
   From: <sip:ap@subB.example.com>;tag=978675
   To: <sip:gw@subA.example.com>
   Call-ID: 12345601@subA.example.com
   CSeq: 21 SUBSCRIBE
   Contact: <sip:ap@client.subB.example.com>
   Max-Forwards: 70
   Event: kpml ;remote-tag="<sip:phn@example.com;tag=jfi23>"
               ;local-tag="sip:gw@subA.example.com;tag=oi43jfq"
               ;call-id="12345598@subA.example.com"
   Expires: 7200
   Accept: application/kpml-response+xml
   Content-Type: application/kpml-request+xml
   Content-Length: 295
Top   ToC   RFC4730 - Page 50
   <?xml version="1.0" encoding="UTF-8"?>
   <kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation=
           "urn:ietf:params:xml:ns:kpml-request kpml-request.xsd"
         version="1.0">
     <pattern persist="single-notify">
       <regex>L#</regex>
     </pattern>
   </kpml-request>

   Message (13) is the request from the personal assistant application
   for number and pound sign monitoring.

   SUBSCRIBE sip:gw@subA.example.com SIP/2.0
   Via: SIP/2.0/TCP pahost.example.com;branch=xzvsadf
   From: <sip:pa@example.com>;tag=4rgj0f
   To: <sip:gw@subA.example.com>
   Call-ID: 93845@pahost.example.com
   CSeq: 21 SUBSCRIBE
   Contact: <sip:pa12@pahost.example.com>
   Max-Forwards: 70
   Event: kpml ;remote-tag="<sip:phn@example.com;tag=jfi23>"
               ;local-tag="sip:gw@subA.example.com;tag=oi43jfq"
               ;call-id="12345598@subA.example.com"
   Expires: 7200
   Accept: application/kpml-response+xml
   Content-Type: application/kpml-request+xml
   Content-Length: 332

   <?xml version="1.0" encoding="UTF-8"?>
   <kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation=
           "urn:ietf:params:xml:ns:kpml-request kpml-request.xsd"
         version="1.0">
     <pattern persist="persist">
       <regex tag="number">x{10}</regex>
       <regex tag="#">#</regex>
     </pattern>
   </kpml-request>
Top   ToC   RFC4730 - Page 51
   Message (18) is the notification of the number collected.

   NOTIFY sip:pa@example.com SIP/2.0
   Via: SIP/2.0/UDP subA.example.com;branch=xzvsadf
   To: <sip:pa@example.com>;tag=4rgj0f
   From: <sip:gw@subA.example.com>;tag=9788823
   Call-ID: 93845@pahost.example.com
   CSeq: 3021 NOTIFY
   Contact: <sip:gw27@subA.example.com>
   Event: kpml
   Subscription-State: active;expires=3540
   Max-Forwards: 70
   Content-Type: application/kpml-response+xml
   Content-Length: 278

   <?xml version="1.0" encoding="UTF-8"?>
   <kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation=
           "urn:ietf:params:xml:ns:kpml-response kpml-response.xsd"
         version="1.0"
         code="200" text="OK" digits="3335551212" tag="number"/>

   Message (21) is the notification of pound sign detected.

   NOTIFY sip:pa@example.com SIP/2.0
   Via: SIP/2.0/UDP subA.example.com;branch=xzvsadf
   To: <sip:pa@example.com>;tag=4rgj0f
   From: <sip:gw@subA.example.com>;tag=9788823
   Call-ID: 93845@pahost.example.com
   CSeq: 3022 NOTIFY
   Contact: <sip:gw27@subA.example.com>
   Event: kpml
   Subscription-State: active;expires=3540
   Max-Forwards: 70
   Content-Type: application/kpml-response+xml
   Content-Length: 264

   <?xml version="1.0" encoding="UTF-8"?>
   <kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation=
           "urn:ietf:params:xml:ns:kpml-response kpml-response.xsd"
         version="1.0"
         code="200" text="OK"
         digits="#" tag="#"/>
Top   ToC   RFC4730 - Page 52
   Message (27) is the notification of long pound to the card
   application.

   NOTIFY sip:ap@client.subB.example.com SIP/2.0
   Via: SIP/2.0/UDP subA.example.com;branch=3qo3j0ouq
   To: <sip:ap@subB.example.com>;tag=978675
   From: <sip:gw@subA.example.com>;tag=9783453
   Call-ID: 12345601@subA.example.com
   CSeq: 3037 NOTIFY
   Contact: <sip:gw27@subA.example.com>
   Event: kpml
   Subscription-State: active;expires=3216
   Max-Forwards: 70
   Content-Type: application/kpml-response+xml
   Content-Length: 256

   <?xml version="1.0" encoding="UTF-8"?>
   <kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation=
           "urn:ietf:params:xml:ns:kpml-response kpml-response.xsd"
         version="1.0"
         code="200" text="OK"
         digits="#"/>

11. References

11.1. Normative References

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [3] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [6] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002.
Top   ToC   RFC4730 - Page 53
   [7]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
        January 2004.

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

11.2. Informative References

[9] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Work in Progress, June 2006. [10] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000. [11] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003. [12] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway Control Protocol Version 1", RFC 3525, June 2003. [13] Institute of Electrical and Electronics Engineers, "Information Technology - Portable Operating System Interface (POSIX) - Part 1: Base Definitions, Chapter 9", IEEE Standard 1003.1, June 2001. [14] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C REC REC-xml-20001006, October 2000. [15] Rosenberg, J., "A Framework for Application Interaction in the Session Initiation Protocol (SIP)", Work in Progress, July 2005. [16] Burger, E., Van Dyke, J., and A. Spitzer, "Media Server Control Markup Language (MSCML) and Protocol", RFC 4722, November 2006. [17] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005. [18] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006.
Top   ToC   RFC4730 - Page 54

Appendix A. Contributors

Ophir Frieder of the Illinois Institute of Technology collaborated on the development of the buffer algorithm. Jeff Van Dyke worked enough hours and wrote enough text to be considered an author under the old rules. Robert Fairlie-Cuninghame, Cullen Jennings, Jonathan Rosenberg, and we were the members of the Application Stimulus Signaling Design Team. All members of the team contributed to this work. In addition, Jonathan Rosenberg postulated DML in his "A Framework for Stimulus Signaling in SIP Using Markup" draft. This version of KPML has significant influence from MSCML [16], the SnowShore Media Server Control Markup Language. Jeff Van Dyke and Andy Spitzer were the primary contributors to that effort. Rohan Mahy did a significant reorganization of the content, as well as providing considerable moral support in the production of this document. That said, any errors, misinterpretation, or fouls in this document are our own.

Appendix B. Acknowledgements

Hal Purdy and Eric Cheung of AT&T Laboratories helped immensely through many conversations and challenges. Steve Fisher of AT&T Laboratories suggested the digit suppression syntax and provided excellent review of the document. Terence Lobo of SnowShore Networks made it all work. Jerry Kamitses, Swati Dhuleshia, Shaun Bharrat, Sunil Menon, and Bryan Hill helped with clarifying the buffer behavior and DRegex syntax. Silvano Brewster and Bill Fenner of AT&T Laboratories and Joe Zebarth of Nortel helped considerably with making the text clear and DRegex tight. Bert Culpepper and Allison Mankin gave an early version of this document a good scouring. Scott Hollenbeck provided XML and MIME review. Tim Bray pointed out the general issue of UTF-8 versus UTF-16 with XML.
Top   ToC   RFC4730 - Page 55

Authors' Addresses

Eric Burger Cantata Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA EMail: eburger@cantata.com Martin Dolly AT&T Labs EMail: mdolly@att.com
Top   ToC   RFC4730 - Page 56
Full Copyright Statement

   Copyright (C) The IETF Trust (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
   AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
   THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
   IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
   PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

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