idnits 2.17.1 draft-burger-sipping-kpml-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 58 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 3, 2003) is 7725 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '8' is defined on line 673, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (ref. '2') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3015 (ref. '4') (Obsoleted by RFC 3525) -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 3023 (ref. '6') (Obsoleted by RFC 7303) -- Obsolete informational reference (is this intentional?): RFC 1889 (ref. '8') (Obsoleted by RFC 3550) -- Obsolete informational reference (is this intentional?): RFC 2833 (ref. '9') (Obsoleted by RFC 4733, RFC 4734) == Outdated reference: A later version (-09) exists of draft-vandyke-mscml-00 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING E. Burger 3 Internet-Draft SnowShore Networks, Inc. 4 Expires: September 1, 2003 March 3, 2003 6 Keypad Markup Language (KPML) 7 draft-burger-sipping-kpml-01 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on September 1, 2003. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 Keypad Markup Language (KPML) is a markup language used in 38 conjunction with SIP and HTTP to provide instructions to SIP User 39 Agents for the reporting of user key presses. 41 Conventions used in this document 43 RFC2119 [1] provides the interpretations for the key words "MUST", 44 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 45 "RECOMMENDED", "MAY", and "OPTIONAL" found in this document. 47 In the narrative discussion, the "user device" is a User Agent that 48 will report stimulus. An "application" is a User Agent requesting 49 the user device to report stimulus. The "user" is an entity that 50 stimulates the user device. In English, the user device is a phone, 51 the application is an application server or proxy server, and the 52 user presses keys to generate stimulus. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. HTTP Reporting . . . . . . . . . . . . . . . . . . . . . . . . 7 59 4. SIP Reporting . . . . . . . . . . . . . . . . . . . . . . . . 8 60 5. Mixing HTTP and SIP . . . . . . . . . . . . . . . . . . . . . 9 61 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 6.1 Monitoring for Octorhorpe . . . . . . . . . . . . . . . . . . 10 63 6.2 VoiceXML Digit Collection . . . . . . . . . . . . . . . . . . 10 64 6.3 Dial String Collection . . . . . . . . . . . . . . . . . . . . 12 65 6.4 Interactive Digit Collection . . . . . . . . . . . . . . . . . 13 66 6.5 SIP Request . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 7. Report Body . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 70 9.1 IANA Registration of MIME media type application/kpml+xml . . 18 71 9.2 Schema Registration . . . . . . . . . . . . . . . . . . . . . 18 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 73 Normative References . . . . . . . . . . . . . . . . . . . . . 20 74 Informative References . . . . . . . . . . . . . . . . . . . . 21 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21 76 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 77 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 78 Intellectual Property and Copyright Statements . . . . . . . . 24 80 1. Introduction 82 This document describes the Keypad Markup Language, KPML. KPML is a 83 markup [7] that enables "dumb phones" to report on basic user 84 key-press interactions. 86 This document refers to a "dumb phone" as a user device that does not 87 have a display. Otherwise, it is actually a rather smart device. 88 Most KPML implementations require the user device to be an http [2] 89 client and interpret KPML markup. 91 We strongly discourage the use of non-validating XML parsers, as one 92 can expect problems with future versions of KPML. That said, one can 93 envision user devices that only accept SIP reporting and have a fixed 94 parser, rather than a full XML parser. This means that KPML can fit 95 in to an extremely small memory and processing footprint. Note KPML 96 has a corresponding lack of functionality. For those applications 97 that require more functionality, please refer to VoiceXML [11] and 98 MSCML [10]. 100 The name of the markup, KPML, reflects its legacy support role. The 101 public switched telephony network (PSTN) accomplished end-to-end 102 signaling by transporting Dual-Tone, Multi-Frequency (DTMF) tones in 103 the bearer channel. This is in-band signaling. 105 NOTE: The spelunking community already took the name KML for their 106 cave data base interchange format. 108 From the point of view of an application being signaled, what is 109 important is the fact the stimulus occurred, not the tones used to 110 transport the stimulus. For example, an application may ask the 111 caller to press the "1" key. What the application cares about is the 112 key press, not that there were two cosine waves at 697 Hz and 1209 Hz 113 transmitted. 115 A SIP-signaled [3] network transports end-to-end signaling with 116 RFC2833 [9] packets. In RFC2833, the signaling application inserts 117 RFC2833 named signal packets instead of generating tones. The 118 receiving application gets the signal information, which is what it 119 wanted in the first place. 121 RFC2833 is the only method that can correlate the time the end user 122 pressed a digit with the user's media. However, out-of-band 123 signaling methods, as are appropriate for user device to application 124 signaling, do not need millisecond accuracy. On the other hand, they 125 do need reliability, which RFC2833 does not provide. 127 An interested application could request notifications of every key 128 press. However, many of the use cases for such signaling has the 129 application interested in only one or a few keystrokes. Thus we need 130 a mechanism for specifying to the user device what stimulus the 131 application would like notification of. 133 2. Overview 135 KPML is a stateless, declarative markup. A KPML document contains a 136 tag with a series of tags. The tag has a 137 value attribute which is a RFC3015 [4] (H.248) digit map. 139 NOTE: We use H.248 digit maps instead of MGCP [13] digit maps 140 because the former is an IETF standard and the latter is not. 142 NOTE: We do not use SRGS [14] DTMF grammars because it is unlikely 143 one would use KPML for independent digit collection in a browser 144 context. 146 Interface attributes, such as the interdigit timeout and what 147 constitutes a long key press, are implementation matters beyond the 148 scope of this document. 150 For many applications, the user device needs to quarantine (buffer) 151 digits. Some applications use modal interfaces where the first few 152 key presses determine what the following digits mean. For a novice 153 user, the application may play a prompt describing what mode the 154 application is in. However, "power users" often barge through the 155 prompt. 157 KPML provides a barge attribute to the tag. The default is 158 "barge=yes". Enabling barge means that the user device buffers 159 digits and applies them immediately when the next KPML document 160 arrives. Disabling barge by specifying "barge=no" means the user 161 device flushes any collected digits before collecting more digits and 162 comparing them against the tags. 164 NOTE: Quarantine and barge are separate actions. However, the 165 barge action directly determines the quarantine action. Thus KPML 166 only specifies the barge action request. 168 If the user presses a key not matched by the tags, the user 169 device discards the key press from consideration against the current 170 or future KPML documents. However, as described above, once there is 171 a match, the user device quarantines any keys the user enters 172 subsequent to the match. 174 KPML documents are independent. Thus it is not possible for the 175 current document to know if a following document will enable barging 176 or want the digits flushed. Therefore, the user device MUST 177 quarantine all digits detected between the time of the report (http 178 POST or SIP NOTIFY) and the interpretation of the next script, if 179 any. If the next script has "barge=no", then the interpreter MUST 180 flush all collected digits. If the next script has "barge=yes", then 181 the interpreter MUST apply the collected digits against the digit 182 maps presented by the script's tags. If there is a match, 183 the interpreter MUST quarantine the remaining digits. If there is no 184 match, the interpreter MUST flush all of the collected digits. 186 Because it is not possible to know if the signaled digits are for 187 local KPML processing or for other recipients of the media stream, 188 the user device transmits the digits to the far end in real time, 189 using either RFC2833 or by generating the appropriate tones. 191 NOTE: If KPML did not have this behavior, then a user device 192 executing KPML could easily break called applications. For 193 example, take a personal assistant that uses "*9" for attention. 194 If the user presses the "*" key, KPML will hold the digit, looking 195 for the "9". What if the user just enters a "*" key, possibly 196 because they accessed an IVR system that looks for "*"? In this 197 case, the "*" would get held by the user device, because it is 198 looking for the "*9" pattern. The user would probably press the 199 "*" key again, hoping that the called IVR system just did not hear 200 the key press. At that point, the user device would send both "*" 201 entries, as "**" does not match "*9". However, that would not 202 have the effect the user intended when they pressed "*". 204 3. HTTP Reporting 206 For HTTP reporting, each tag in the markup has an href 207 attribute. When the user enters keypress(es) that match a 208 tag, the user device issues an http POST to the URI specified by the 209 href. The body of the POST is a report of the actual digits entered. 210 This is so the user device can indicate what digit string matched a 211 pattern with wildcards. 213 If the resulting document returned by the http POST is empty, the 214 user device terminates the KPML session. 216 NOTE: This is different than the behavior for VoiceXML as 217 described in Basic Network Media Services with SIP [12], where an 218 empty document results in the termination of the session. 220 If the KPML document includes "sip:" href targets, and the KPML 221 interpreter does not support SIP Reporting, the KPML interpreter MUST 222 reject the document in its entirety at interpretation time with the 223 appropriate SIP error as described in ?????. 225 NOTE: draft-jennings-sip-app-info-00.txt should cover document 226 rejection. It does not right now. This draft should not address 227 document rejection, other than the criteria for rejection. This 228 draft focuses on KPML, not on the initiation mechanism. 230 4. SIP Reporting 232 For SIP reporting, the href attribute of the tag MUST be 233 "sip:". When the user enters keypress(es) that match a tag, 234 the user device will issue a SIP NOTIFY to the Contact of the 235 original INVITE. A KPML interpreter MUST NOT direct the NOTIFY to 236 other SIP endpoints. See the Security Considerations (Section 10) 237 section for the rationale for this restriction. 239 The reason one must specify a sip: scheme, and not simply make 240 href optional, is to catch a HTTP-based script error where one 241 forgets to specify the href tag. If href was optional, then this 242 error would result in the user device generating a SIP NOTIFY, 243 which would not be the desired action. 245 The specification of any scheme-specific part, that is, anything 246 following the colon in "sip:", is an error. The interpreter MUST 247 reject the request. 249 NOTE: This greatly simplifies the security issues about who can 250 send a NOTIFY to what dialog. Here we say simply that if someone 251 asks you for service, you can tell them about it. However, you 252 cannot tell someone else about it. 254 After reporting a SIP , the interpreter terminates the KPML 255 session. To collect more digits, the requestor must issue a 256 re-INVITE on the dialog. 258 NOTE: This highlights the "one shot" nature of KPML, reflecting 259 the balance of features and ease of implementing an interpreter. 260 If your goal is to build an IVR session, we strongly suggest you 261 investigate more appropriate technologies such as VoiceXML [11] or 262 MSCML [10]. 264 If the KPML document includes "http:" href targets, and the KPML 265 interpreter does not support HTTP Reporting, the KPML interpreter 266 MUST reject the document in its entirety at interpretation time with 267 the appropriate SIP error as described in ?????. 269 NOTE: draft-jennings-sip-app-info-00.txt should cover document 270 rejection. It does not right now. This draft should not address 271 document rejection, other than the criteria for rejection. This 272 draft focuses on KPML, not on the initiation mechanism. 274 5. Mixing HTTP and SIP 276 NOTE: So, now that Pandora's Box is open... 278 There is nothing to prevent mixing SIP and HTTP reporting requests in 279 the same KPML document. While this may be a benefit, it has definite 280 drawbacks. 282 The major drawback is that one cannot negotiate SIP-ness or 283 HTTP-ness. As far as the endpoints are concerned it is all KPML. 284 One could use "application/KPML+SIP+XML" and "application/ 285 KPML+HTTP+XML", but that is pretty ugly. 287 6. Examples 289 6.1 Monitoring for Octorhorpe 291 A common need for pre-paid and personal assistant applications is to 292 monitor a conversation for a signal indicating a change in user focus 293 from the party they called through the application to the application 294 itself. For example, if you call a party using a pre-paid calling 295 card and the party you call redirects you to voice mail, digits you 296 press are for the voice mail system. However, many applications have 297 a special key sequence, such as the octothorpe (#, or pound sign) or 298 *9 that terminate the called party leg and shift the user's focus to 299 the application. 301 The following figure shows the KPML for long octothorpe. Note that 302 the href is really on one line, but divided for clarity. 304 305 306 307 308 311 312 313 315 Figure 1 - Long Octothorpe Example 317 In this example, the parameter "session=19fsjcalksd" associates the 318 http POST with the SIP call session. One can use other methods to 319 associate the POST with a SIP call. The following examples will show 320 these various methods. 322 The regex value Z indicates the following digit needs to be a 323 long-duration key press. F, from the H.248 DTMF package, is the 324 octothorpe key. In fact, KPML supports all digits, 1-9, *, #, A-D 325 from the H.248 DTMF package. 327 6.2 VoiceXML Digit Collection 329 One could imagine a VoiceXML [11] platform that wants to have the 330 user device signal the user's key presses, while the VoiceXML 331 platform still streams prompts to the user device. Of course, by 332 definition, the VoiceXML platform receives all of the user device's 333 media. This is because the user hears prompts from the VoiceXML 334 platform and the platform hears all of the user's utterances (e.g., 335 for recording a message). 337 However, let us say that the VoiceXML platform would like to receive 338 the stimulus in http, rather than in RFC2833. Moreover, the KPML 339 mechanism enables the user device to immediately barge the prompt, 340 saving at least a round-trip-time of latency. 342 In this example, a VoiceXML script builds a menu. The VoiceXML 343 interpreter has pulls out a grammar definition similar to the 344 following. 346 347 348 349 For sports press 1, For weather press 2, For Stargazer 350 astrophysics press 3. To speak to a person press 0. 351 352 354 356 358 360 362 Figure 2 - VoiceXML Code 364 A browser could take the code in Figure 2 and make a KPML request 365 similar to that shown in Figure 3. 367 368 369 370 371 373 375 377 379 380 381 383 Figure 3 - VoiceXML KPML Example Code 385 Note the targets of the href's are opaque strings that have meaning 386 only to the VoiceXML platform. 388 6.3 Dial String Collection 390 In this example, the user device collects a dial string. The 391 application uses KPML to quickly determine when the user enters a 392 target number. In addition, KPML indicates what type of number the 393 user entered. 395 396 397 398 399 438 439 440 441 443 445 447 448 449 451 Figure 5 - IVR KPML Example Code 453 The target of the http post, "sess$9aej08asd7", identifies the SIP 454 session. 456 NOTE: It is unclear if this usage of KPML is better than using a 457 device control protocol like H.248. From the application's point 458 of view, it has to do the low-level prompt-collect logic. 459 Granted, it is relatively easy to change the key mappings for a 460 given menu. However, often more of the call flow than a given 461 menu mapping gets changed. Thus there would be little value in 462 such a mapping to KPML. 464 6.5 SIP Request 466 For example, the following figure is the example from Figure 1, but 467 with SIP NOTIFY reporting. 469 470 471 472 473 475 476 477 479 Figure 6 - Long Octothorpe Example 481 The response body is identical to the response that Figure 1 would 482 generate. 484 7. Report Body 486 For HTTP or SIP responses, the body of the response from the user 487 device is a KPML response form. 489 The tag has an attribute, "digits". The digits attribute 490 is the digit string. The digit string uses the conventional 491 characters '*' and '#' for star and octothorpe respectively. 493 Figure 7 shows a sample response body to the example in the Dial 494 String Collection (Section 6.3) section. 496 497 498 499 501 Figure 7 - Response Body 503 NOTE: KPML does not include a timestamp. There are a number of 504 reasons for this. First, what timestamp would in include? Would 505 it be the time of the first detected keypress? The time the 506 interpreter collected the entire string? A range? Second, if the 507 RTP timestamp is a datum of interest, why not simply get RTP in 508 the first place? That all said, if it is really compelling to 509 have the timestamp in the response, it will be an attribute to the 510 tag. 512 8. Formal Syntax 514 The following syntax specification uses the augmented Data Type 515 Definition (DTD) as described in XML [7]. 517 518 520 522 523 525 526 530 531 534 Figure 8 - KPML DTD 536 And, if you prefer XML Schema [5], here it is. 538 539 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 601 Figure 9 - XML Schema for KPML 603 9. IANA Considerations 605 9.1 IANA Registration of MIME media type application/kpml+xml 607 MIME media type name: application 609 MIME subtype name: kpml+xml 611 Required parameters: none 613 Optional parameters: charset 615 charset This parameter has identical semantics to the charset 616 parameter of the "application/xml" media type as specified in 617 XML Media Types [6]. 619 Encoding considerations: See RFC3023 [6]. 621 Interoperability considerations: See RFC2023 [6] and this document. 623 Published specification: This document. 625 Applications which use this media type: Session-oriented applications 626 that have primitive user interfaces. 628 Intended usage: COMMON 630 9.2 Schema Registration 632 We really need a place to register the XML Schema. Where would that 633 be? 635 10. Security Considerations 637 KPML presents no further security issues beyond the startup issues 638 addressed in the companion documents to this document. 640 As an XML markup, all of the security considerations of RFC3023 [6] 641 apply. 643 Normative References 645 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 646 Levels", BCP 14, RFC 2119, March 1997. 648 [2] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 649 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 650 HTTP/1.1", RFC 2616, June 1999. 652 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 653 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 654 Session Initiation Protocol", RFC 3261, June 2002. 656 [4] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and 657 J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November 658 2000. 660 [5] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML 661 Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502, 662 May 2001. 664 [6] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 665 3023, January 2001. 667 Informative References 669 [7] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 670 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 671 REC REC-xml-20001006, October 2000. 673 [8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 674 "RTP: A Transport Protocol for Real-Time Applications", RFC 675 1889, January 1996. 677 [9] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, 678 Telephony Tones and Telephony Signals", RFC 2833, May 2000. 680 [10] Burger, E., Van Dyke, J. and A. Spitzer, "SnowShore Media 681 Server Control Markup Language and Protocol", 682 draft-vandyke-mscml-00 (work in progress), November 2002. 684 [11] World Wide Web Consortium, "Voice Extensible Markup Language 685 (VoiceXML) Version 2.0", W3C Working Draft , April 2002, 686 . 688 [12] Van Dyke, J., Burger (Ed.), E. and A. Spitzer, "Basic Network 689 Media Services with SIP", January 2003. 691 [13] Andreasen, F. and B. Foster, "Media Gateway Control Protocol 692 (MGCP) Version 1.0", RFC 3435, January 2003. 694 [14] Hunt, A. and S. McGlashan, "Speech Recognition Grammar 695 Specification Version 1.0", W3C CR CR-speech-grammar-20020626, 696 June 2002. 698 Author's Address 700 Eric Burger 701 SnowShore Networks, Inc. 702 285 Billerica Rd. 703 Chelmsford, MA 01824-4120 704 USA 706 EMail: e.burger@ieee.org 708 Appendix A. Contributors 710 Robert Fairlie-Cuninghame, Cullen Jennings, Jonathan Rosenberg, and I 711 were the members of the Application Stimulus Signaling Design Team. 712 All members of the team contributed significantly to this work. In 713 addition, Jonathan Rosenberg postulated DML in his "A Framework for 714 Stimulus Signaling in SIP Using Markup" draft. 716 This version of KPML has significant influence from MSCML, the 717 SnowShore Media Server Control Markup Language. Jeff Van Dyke and 718 Andy Spitzer were the primary contributors to that effort. 720 That said, any errors, misinterpretation, or fouls in this document 721 are my own. 723 Appendix B. Acknowledgements 725 Hal Purdy, Steve Fisher and Eric Chueng of AT&T Laboratories helped 726 immensely through many conversations and challenges. 728 Intellectual Property Statement 730 The IETF takes no position regarding the validity or scope of any 731 intellectual property or other rights that might be claimed to 732 pertain to the implementation or use of the technology described in 733 this document or the extent to which any license under such rights 734 might or might not be available; neither does it represent that it 735 has made any effort to identify any such rights. Information on the 736 IETF's procedures with respect to rights in standards-track and 737 standards-related documentation can be found in BCP-11. Copies of 738 claims of rights made available for publication and any assurances of 739 licenses to be made available, or the result of an attempt made to 740 obtain a general license or permission for the use of such 741 proprietary rights by implementors or users of this specification can 742 be obtained from the IETF Secretariat. 744 The IETF invites any interested party to bring to its attention any 745 copyrights, patents or patent applications, or other proprietary 746 rights which may cover technology that may be required to practice 747 this standard. Please address the information to the IETF Executive 748 Director. 750 Full Copyright Statement 752 Copyright (C) The Internet Society (2003). All Rights Reserved. 754 This document and translations of it may be copied and furnished to 755 others, and derivative works that comment on or otherwise explain it 756 or assist in its implementation may be prepared, copied, published 757 and distributed, in whole or in part, without restriction of any 758 kind, provided that the above copyright notice and this paragraph are 759 included on all such copies and derivative works. However, this 760 document itself may not be modified in any way, such as by removing 761 the copyright notice or references to the Internet Society or other 762 Internet organizations, except as needed for the purpose of 763 developing Internet standards in which case the procedures for 764 copyrights defined in the Internet Standards process must be 765 followed, or as required to translate it into languages other than 766 English. 768 The limited permissions granted above are perpetual and will not be 769 revoked by the Internet Society or its successors or assignees. 771 This document and the information contained herein is provided on an 772 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 773 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 774 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 775 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 776 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 778 Acknowledgement 780 Funding for the RFC Editor function is currently provided by the 781 Internet Society.