idnits 2.17.1 draft-boulton-ivr-vxml-control-package-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 726. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 737. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 744. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 750. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (February 23, 2008) is 5907 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 415 -- Looks like a reference, but probably isn't: '2' on line 416 -- Looks like a reference, but probably isn't: '3' on line 417 -- Looks like a reference, but probably isn't: '4' on line 418 == Unused Reference: 'RFC2616' is defined on line 644, but no explicit reference was found in the text == Unused Reference: 'RFC3262' is defined on line 656, but no explicit reference was found in the text == Unused Reference: 'RFC3263' is defined on line 660, but no explicit reference was found in the text == Unused Reference: 'RFC3264' is defined on line 664, but no explicit reference was found in the text == Unused Reference: 'RFC4574' is defined on line 671, but no explicit reference was found in the text == Unused Reference: 'RFC4722' is defined on line 674, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-mediactrl-sip-control-framework-01 == Outdated reference: A later version (-09) exists of draft-saleem-msml-06 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3023 (Obsoleted by RFC 7303) -- Obsolete informational reference (is this intentional?): RFC 4722 (Obsoleted by RFC 5022) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Boulton 3 Internet-Draft Avaya 4 Intended status: Standards Track T. Melanchuk 5 Expires: August 26, 2008 Rain Willow Communications 6 S. McGlashan 7 Hewlett-Packard 8 February 23, 2008 10 A VoiceXML Control Package for the Media Control Channel Framework 11 draft-boulton-ivr-vxml-control-package-04 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 26, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This document defines a VoiceXML Control Package for the Media 45 Control Channel Framework. This Control Package extends the Basic 46 IVR control package with support for VoiceXML dialogs. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 52 3. Control Package Definition . . . . . . . . . . . . . . . . . . 5 53 3.1. Control Package Name . . . . . . . . . . . . . . . . . . . 5 54 3.2. Framework Message Usage . . . . . . . . . . . . . . . . . 5 55 3.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 5 56 3.4. CONTROL Message Body . . . . . . . . . . . . . . . . . . . 5 57 3.5. REPORT Message Body . . . . . . . . . . . . . . . . . . . 6 58 4. Element Extensions . . . . . . . . . . . . . . . . . . . . . . 7 59 4.1. . . . . . . . . . . . . . . . . . . . . . 7 60 4.2. . . . . . . . . . . . . . . . . . . . . . . 7 61 4.3. . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.4. . . . . . . . . . . . . . . . . . . . . . . . 8 63 5. Element Definitions . . . . . . . . . . . . . . . . . . . . . 10 64 5.1. . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 13 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 69 9.1. Control Package Registration . . . . . . . . . . . . . . . 18 70 9.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 18 71 10. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 19 72 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 73 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 74 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 75 13.1. Normative References . . . . . . . . . . . . . . . . . . . 22 76 13.2. Informative References . . . . . . . . . . . . . . . . . . 22 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 78 Intellectual Property and Copyright Statements . . . . . . . . . . 25 80 1. Introduction 82 The Media Control Channel Framework [MCCF] provides a generic 83 approach for establishment and reporting capabilities of remotely 84 initiated commands. The Framework utilizes many functions provided 85 by the Session Initiation Protocol [RFC3261] (SIP) for the rendezvous 86 and establishment of a reliable channel for control interactions. 87 The Control Framework also introduces the concept of a Control 88 Package. A Control Package is an explicit usage of the Control 89 Framework for a particular interaction set. 91 This specification defines a Control Package for IVR functions using 92 VoiceXML 2.0 dialogs ([VXML20], [VXML21]). As a recognized 93 international standard for IVR dialogs, VoiceXML is used extensively 94 within media server control languages (cf. [CCXML10], [MSML], 95 [RFC4240]). 97 To ensure interoperability, implementations MUST support VoiceXML 2.0 98 dialogs. They SHOULD support later versions of VoiceXML (e.g. 99 [VXML21]). 101 The VoiceXML package extends the basic IVR control package 102 ([BASEIVRCP]) by replacing the basic ivr dialog type with a VoiceXML 103 dialog type. In particular, this package 105 1. extends and elements to include 106 inline dialogs, http related attributes and a 107 element to pass information into the dialog. 109 2. extends to provide VoiceXML exit information 111 Otherwise, this package follows precisely the syntax and semantics of 112 the basic IVR control package. 114 2. Conventions and Terminology 116 In this document, BCP 14/RFC 2119 [RFC2119] defines the key words 117 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 118 "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL". In addition, BCP 15 indicates requirement levels for 120 compliant implementations. 122 The additional terms defined in Section 2 of [BASEIVRCP] are used in 123 this document. 125 3. Control Package Definition 127 This section fulfills the mandatory requirement for information that 128 MUST be specified during the definition of a Control Framework 129 Package, as detailed in Section 8 of [MCCF]. 131 3.1. Control Package Name 133 The Control Framework requires a Control Package definition to 134 specify and register a unique name and version. 136 The name and version of this Control Package is "msc-ivr-vxml/1.0" 137 (Media Server Control - Interactive Voice Response - VoiceXML - 138 version 1.0). Its IANA registration is specified in Section 9.1. 140 3.2. Framework Message Usage 142 The Control Framework requires a Control Package to explicitly detail 143 the control messages that can be used as well as provide an 144 indication of directionality between entities. This will include 145 which role type is allowed to initiate a request type. 147 This package adheres to Framework Message usage defined in Section 148 3.2 of [BASEIVRCP]. This package extends the dialog control elements 149 as defined in Section 4; additional elements are defined in 150 Section 5. A XML Schema for this package is provided in Section 7. 152 Implementation of this control package MUST adhere to the syntax and 153 semantics of XML elements defined in this document. In cases where 154 there is a difference in constraints between the XML schema and the 155 textual description of elements, the textual definition takes 156 priority. 158 3.3. Common XML Support 160 The Control Framework requires a Control Package definition to 161 specify if the attributes for media dialog or conference references 162 are required. 164 This package adheres to Common XML Support defined in Section 3.3 of 165 [BASEIVRCP]. 167 3.4. CONTROL Message Body 169 The Control Framework requires a Control Package to define the 170 control body that can be contained within a CONTROL command request 171 and to indicate the location of detailed syntax definitions and 172 semantics for the appropriate body types. 174 This package adheres to CONTROL Message Body as defined in Section 175 3.4 of [BASEIVRCP]. 177 3.5. REPORT Message Body 179 The Control Framework requires a control package definition to define 180 the REPORT body that can be contained within a REPORT command 181 request, or that no report package body is required. This section 182 should indicate the location of detailed syntax definitions and 183 semantics for the appropriate body types. 185 This package adheres to REPORT Message Body as defined in Section 3.5 186 of [BASEIVRCP]. 188 4. Element Extensions 190 The XML elements used in this package are those defined in Section 4 191 of [BASEIVRCP] unless otherwise specified in this section. 193 4.1. 195 This package extends the definition of request in 196 Section 4.1.1 of [BASEIVRCP] as follows. 198 The element has the following modified attributes: 200 src: implementations MUST support the HTTP protocol 202 type: The default value is "application/voicexml+xml". 204 The element has the following additional attributes: 206 maxage: string defining a time interval according to the max-age 207 parameter in HTTP. The attribute is optional. 209 maxstale: string defining a time interval according to the max-stale 210 parameter in HTTP. The attribute is optional. 212 method: string indicating the HTTP method to use. Permitted values 213 are "post" or "get". The default value is "get". The attribute 214 is optional. 216 enctype: string identifying the encoding type of the submitted 217 document (when the value of the method attribute is 'post'). The 218 default value is "application/x-www-form-url-encoded". The 219 attribute is optional. 221 The element has the following additional child 222 elements: 224 : contains an inline VoiceXML document in the VoiceXML 225 namespace. The element is optional. 227 4.2. 229 This package extends the definition of request in 230 Section 4.1.2 of [BASEIVRCP] as follows. 232 The element has the following modified attributes: 234 src: implementations MUST support the HTTP URI protocol 236 type: The default value is "application/voicexml+xml". 238 The element has the following additional attributes: 240 maxage: string defining a time interval according to the max-age 241 parameter in HTTP. The attribute is optional. 243 maxstale: string defining a time interval according to the max-stale 244 parameter in HTTP. The attribute is optional. 246 method: string indicating the HTTP method to use. Permitted values 247 are "post" or "get". The default value is "get". The attribute 248 is optional. 250 enctype: string identifying the encoding type of the submitted 251 document (when the value of the method attribute is 'post'). The 252 default value is "application/x-www-form-url-encoded". The 253 attribute is optional. 255 The element has the following additional child elements 256 defined: 258 : contains an inline VoiceXML document in the VoiceXML 259 namespace. The element is optional. 261 : an XML data structure (see Section 5.1) to pass parameters 262 into the dialog. The element is optional. 264 [Editors Note: further work is required to define how connection 265 related information is passed to the VoiceXML interpreter.] 267 4.3. 269 Transfer behavior is not defined. 271 [Editors Note: A later version of this package may specify how 272 is extended with child elements describing transfer events.] 274 4.4. 276 This package extends the definition of in Section 4.3.2 277 of [BASEIVRCP] as follows. 279 The element has the following additional attributes: 281 termmode: indicates how the voicexml dialog was terminated. Valid 282 values are: exit, disconnect, or implementation specific string 283 values beginning with "_". The attribute is mandatory. 285 The element has the following additional child element: 287 : parameters returned from the dialog. The element is 288 optional. 290 5. Element Definitions 292 5.1. 294 The element is a general container for parameterized data. 296 The element has no attributes, but has the following child 297 elements defined: 299 : specifies a parameter. Multiple instances of this element 300 are permitted. The element is mandatory. 302 The element has the following attributes: 304 name: a string indicating the name of the parameter. The attribute 305 is mandatory. 307 type: a string indicating the type of the value. The attribute is 308 optional. The default is a string type. 310 value: a string indicating the value of the parameter. separation. 311 The attribute is mandatory. 313 The element has no children. 315 [Editors Note: this defintion of may be extended in a later 316 version to allow inline binary data, used reporting recordings when 317 the dialog exits. ] 319 6. Examples 321 [Editors Note: this section needs further work.] 323 Example: a request to prepare a dialog where the dialog script is is 324 referenced: 326 328 330 In the following example, the VoiceXML dialog script is specified 331 inline: 333 334 335
336 337 340
341 342 344 The following example shows a request to start a dialog on a 345 conference where the dialog script is indicated using the src 346 attribute: 348 351 352 354 355 357 Where the parameter "media" would be available in the VoiceXML script 358 as "connection.ccxml.values.media" so different prompts can be played 359 using the same dialog script. 361 In the following example, the VoiceXML dialog script is specified 362 inline. 364 365 366
367 368 371
372 373 375 7. Formal Syntax 377 This package defines an XML schema which extends the msc-ivr- 378 common.xsd schema defined in Section 9 of [BASEIVRCP]. 380 All elements in the defined schema are in the 381 urn:ietf:params:xml:ns:msc-ivr-vxml namespace. 383 384 391 392 393 IETF MediaCtrl VoiceXML IVR 1.0 (20080225) 395 This is the schema of the VoiceXML IVR Control Package. 396 It imports the msc-ivr-common schema (dialogprepare, etc) 397 and extends them for VoiceXML support. 399 The schema namespace is urn:ietf:params:xml:ns:msc-ivr-vxml 401 402 404 412 413 414 415 This import brings in the IVR common package Redefinitions: [1] 416 Adds http related attributes in dialogprepare [2] Adds http 417 related attributes in dialogstart [3] Allow params in dialogstart 418 [4] Adds attribute and params to dialogexit 419 421 423 424 425 426 428 429 430 431 432 433 435 436 437 438 440 441 442 444 446 447 448 449 450 451 453 455 462 464 465 466 468 469 470 471 473 474 476 477 478 480 481 483 484 485 486 488 490 492 493 494 495 496 497 499 500 501 503 504 506 507 508 511 512 514 515 516 517 519 521 529 530 531 532 534 535 537 545 546 547 548 549 550 552 553 554 556 558 8. Security Considerations 560 As this control package uses XML markup, implementation MUST address 561 the security considerations of [RFC3023]. 563 9. IANA Considerations 565 This specification instructs IANA to register a new Media Control 566 Channel Framework Package and a new XML namespace. 568 9.1. Control Package Registration 570 Control Package name: msc-ivr-vxml/1.0 572 9.2. URN Sub-Namespace Registration 574 XML namespace: urn:ietf:params:xml:ns:msc-ivr-vxml 576 10. Change Summary 578 The following are the primary changes between the -04 of the draft 579 and the -03 version. 581 o Aligned with the -06 version of the basic ivr control package. 583 o Simplified the structure so that only differences with the basic 584 ivr control package are specified. 586 o Specified how VoiceXML data is returned in a 588 o replaced with 590 o updated references 592 The following are the primary changes between the -03 of the draft 593 and the -02 version. 595 o None 597 The following are the primary changes between the -02 of the draft 598 and the -01 version. 600 o Updated references. 602 The following are the primary changes between the -01 of the draft 603 and the -00 version. 605 o Changes in Basic IVR package version 02 applied. 607 11. Contributors 609 Asher Shiratzky from Radvision provided valuable support and 610 contributions to the early versions of this document. 612 12. Acknowledgments 614 TBD 616 13. References 618 13.1. Normative References 620 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 621 Requirement Levels", BCP 14, RFC 2119, March 1997. 623 13.2. Informative References 625 [BASEIVRCP] 626 Boulton, C., Melanchuk, T., and S. McGlashan, "A Basic 627 Interactive Voice Response (IVR) Control Package for the 628 Media Control Channel Framework", 629 draft-boulton-ivr-control-package-06 (work in progress), 630 February 2008. 632 [CCXML10] Auburn, R J., "Voice Browser Call Control: CCXML Version 633 1.0", W3C Working Draft (work in progress), January 2007. 635 [MCCF] Boulton, C., Melanchuk, T., McGlashan, S., and A. 636 Shiratzky, "Media Control Channel Framework", 637 draft-ietf-mediactrl-sip-control-framework-01 (work in 638 progress), February 2008. 640 [MSML] Saleem, A., Xin, Y., and G. Sharratt, "Media Session 641 Markup Language (MSML)", draft-saleem-msml-06 (work in 642 progress), February 2008. 644 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 645 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 646 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 648 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 649 Types", RFC 3023, January 2001. 651 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 652 A., Peterson, J., Sparks, R., Handley, M., and E. 653 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 654 June 2002. 656 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 657 Provisional Responses in Session Initiation Protocol 658 (SIP)", RFC 3262, June 2002. 660 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 661 Protocol (SIP): Locating SIP Servers", RFC 3263, 662 June 2002. 664 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 665 with Session Description Protocol (SDP)", RFC 3264, 666 June 2002. 668 [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network 669 Media Services with SIP", RFC 4240, December 2005. 671 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 672 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 674 [RFC4722] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server 675 Control Markup Language (MSCML) and Protocol", RFC 4722, 676 November 2006. 678 [VXML20] McGlashan, S., Burnett, D., Carter, J., Danielsen, P., 679 Ferrans, J., Hunt, A., Lucas, B., Porter, B., Rehor, K., 680 and S. Tryphonas, "Voice Extensible Markup Language 681 (VoiceXML) Version 2.0", W3C Recommendation, March 2004. 683 [VXML21] Oshry, M., Auburn, RJ., Baggia, P., Bodell, M., Burke, D., 684 Burnett, D., Candell, E., Carter, J., McGlashan, S., Lee, 685 A., Porter, B., and K. Rehor, "Voice Extensible Markup 686 Language (VoiceXML) Version 2.1", W3C Recommendation, 687 June 2007. 689 Authors' Addresses 691 Chris Boulton 692 Avaya 693 Building 3 694 Wern Fawr Lane 695 St Mellons 696 Cardiff, South Wales CF3 5EA 698 Email: cboulton@avaya.com 700 Tim Melanchuk 701 Rain Willow Communications 703 Email: tim.melanchuk@gmail.com 705 Scott McGlashan 706 Hewlett-Packard 707 Gustav III:s boulevard 36 708 SE-16985 Stockholm, Sweden 710 Email: scott.mcglashan@hp.com 712 Full Copyright Statement 714 Copyright (C) The IETF Trust (2008). 716 This document is subject to the rights, licenses and restrictions 717 contained in BCP 78, and except as set forth therein, the authors 718 retain all their rights. 720 This document and the information contained herein are provided on an 721 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 722 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 723 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 724 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 725 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 726 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 728 Intellectual Property 730 The IETF takes no position regarding the validity or scope of any 731 Intellectual Property Rights 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; nor does it represent that it has 735 made any independent effort to identify any such rights. Information 736 on the procedures with respect to rights in RFC documents can be 737 found in BCP 78 and BCP 79. 739 Copies of IPR disclosures made to the IETF Secretariat and any 740 assurances of licenses to be made available, or the result of an 741 attempt made to obtain a general license or permission for the use of 742 such proprietary rights by implementers or users of this 743 specification can be obtained from the IETF on-line IPR repository at 744 http://www.ietf.org/ipr. 746 The IETF invites any interested party to bring to its attention any 747 copyrights, patents or patent applications, or other proprietary 748 rights that may cover technology that may be required to implement 749 this standard. Please address the information to the IETF at 750 ietf-ipr@ietf.org. 752 Acknowledgment 754 Funding for the RFC Editor function is provided by the IETF 755 Administrative Support Activity (IASA).