RFC 4730
A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)
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.
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.
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
"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 Response10. 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.
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
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>
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".
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
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) |
|--------------------->| |
| | |
| | |
|(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) | |
|.............................................| | | | | | | |(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
<?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"/>
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
<?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>
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="#"/>
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.
[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.
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.
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
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.