MMUSIC N. Deason Internet-Draft USCL Expires: August 24, 2003 February 23, 2003 SDP Usage for SOAP Sessions draft-deason-mmusic-sdp-soap-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 24, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines how the Session Description Protocol (SDP) can be used to describe sessions of Simple Object Access Protocol (SOAP) messages. To achieve this it presents how existing SDP functionality should be utilized and defines two new SDP attributes. The usage of SDP for SOAP sessions within the Offer/Answer model is specifically discussed as this enables the Session Initiation Protocol (SIP) to be used to create, modify and terminate SOAP sessions. Deason Expires August 24, 2003 [Page 1] Internet-Draft SDP Usage for SOAP Sessions February 2003 1. Introduction The Session Description Protocol SDP [1] provides a general purpose syntax for the description of multimedia sessions. SDP files may be transported between users using a variety of application protocols, e.g. SIP, HTTP, SMTP, etc., to enable the particpation in multimedia sessions. The flexibility of SDP means that there is more than one possible way that SOAP [2] message sessions could be described. Having consensus over a single method of operation promotes interoperability. As well as describing the general syntax required for describing SOAP sessions this document pays particular attention to the usage of SDP for SOAP within the Offer/Answer model. [3] The Offer/Answer model of SDP usage is followed by Session Initiation Protocol (SIP). [4] Providing this information therefore enables SOAP based sessions to be intiated, modified and terminated by SIP. The usage of SIP and SOAP within the same environment provides support for an application component based model for services. For example, multiparty conferences, created through SIP, can support floor control and configuration through SOAP. [5] Deason Expires August 24, 2003 [Page 2] Internet-Draft SDP Usage for SOAP Sessions February 2003 2. Terminology and Conventions The terms "session-level", "media-level" are used as defined in SDP. [1] The SDP direction attribute is defined in [6]. The key words MUST, MUSTNOT, REQUIRED, SHOULD, SHOULDNOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [7]. Deason Expires August 24, 2003 [Page 3] Internet-Draft SDP Usage for SOAP Sessions February 2003 3. SDP for SOAP Session Descriptions This section details how a SDP file describes the operation of SOAP sessions. 3.1 Media streams SOAP sessions are enumerated at the media-level. If there are multiple SOAP sessions each one MUST be described on a separarte "m=" line as defined by SDP [1]. m= The media type sub-field SHOULD be set to "application", "data" or "control", as also defined by SDP [1]. "application" signifies the SOAP messaging provides information expected to be displayed to the user (e.g. whiteboard information). "data" signifies the SOAP messaging carries information which will not be typically displayed to the user. "control" signifies that the SOAP messaging will be used as a control channel associated with audio and/or video streams also defined within the SDP message (e.g. control of a SIP Media Server). This list can be extended as new categories of usage emerge. The second sub-field is the port to which the SOAP messages should be sent. The usage of the port field within the Offer/Answer model for SDP, where this may not be initially known, is discussed in Section 4.3. The third sub field is the transport protocol. The following transport protocols for SOAP messaging are defined "HTTP" and "BEEP". This may be extended through registration of new protocols with IANA. The forth sub-field defines media formats. For SOAP messaging this MUST carry the value "application/soap+xml", in accordance with the conventions for XML Media types set out in [8]. 3.2 SDP Attributes for SOAP Sessions An important part of SOAP messaging session is the setup procedure. When SOAP message sessions are being set up over a HTTP or BEEP connection one end point needs to initiate the connection and the other needs to accept the connection. The direction attribute defined in [6] is used to describe these roles. a=direction: [] The is one of the following: Deason Expires August 24, 2003 [Page 4] Internet-Draft SDP Usage for SOAP Sessions February 2003 passive: The endpoint will accept an incoming connection. active: The endpoint will initiate the outgoing connection. both: The endpoint will both accept and incoming connection and will initiate an outgoing connection. The is an optional set of values that describes where the connection will originate. When describing SOAP sessions in SDP the SHOULD NOT be used. It has been proposed that the source address information be removed from the direction attribute. [9] If the value of the direction attribute is set to "both" then the establishment of two connections is deemed acceptable or even desirable. Unlike in the usage of direction attributes for setting TCP connections the behaviour for trying to open two connections, but falling back to one is not defined. An example where two associated HTTP connections are set up for a bidirectional SOAP session is shown in Section 4.3.1. Where only a single connection is wanted SDP carrying only the "passive" or "active" value for the direction attribute MUST be used. The operational complexity introduced by using the "both" value to create two connections where only one is ultimately used is motivated by the desire to establish TCP connections through NATs. Because the SOAP messages are transported at the application layer though HTTP or BEEP the overhead introduced for this feature is not warranted. 3.3 New SDP Attributes for SOAP Sessions The following two new attributes are defined for SDP to describe SOAP sessions. 3.3.1 Contact Attribute The contact attribute is used to provide a URL which will support a connection over which the SOAP messages are transported. The media level description of a SOAP session MUST contain a contact attribute. The ABNF grammar [10] for expressing the contact attribute is as follows: contact-attribute = "contact" ":" url Deason Expires August 24, 2003 [Page 5] The url value SHOULD be an absolute URL following the rules and ABNF grammar set out in RFC 1738. [11] Example: a=contact:http://www.example.com/process1?id=302940 This SDP attribute is believed to be useful for any session that requires a connection described by a URL as opposed to a fully-qualified domain name or IP address. For example, it could be used within the context of IM sessions set up through SIP/SDP. [12] (This document currently proposes an attribute called "uri" for similar purposes.) 3.3.2 WSDL Attribute The WSDL attribue can be used to provide a WSDL document [13] describing the supported SOAP messaging for the session. The media level description of a SOAP session MAY contain a wsdl attribute. The ABNF grammar [10] for expressing the contact attribute is as follows: wsdl-attribute = "wsdl" ":" url The url value SHOULD be an absolute URL following the rules and ABNF grammar set out in RFC 1738. [11] Example: a=contact:http://schemas.example.com/schema1.wsdl Deason Expires August 24, 2003 [Page 6] Internet-Draft SDP Usage for SOAP Sessions February 2003 4. Example Usage 4.1 Basic Case The following example illustrates a basic case where SDP is used to set up a session of SOAP messaging. The recipient of this SDP is able to send SOAP messages to http://foo.example.com/process1. The format of the SOAP messages is defined in a WSDL document located at a=wsdl:http://schemas.example.com/MyMsgs.wsdl. Note that as the connection information is specified by the contact attribute the SDP "c=" field carries a suitable null value. v=0 o=- 289083124 289083124 IN IP4 foo.example.com s=- t=0 0 c=IN IP4 0.0.0.0 m=data 80 HTTP application/soap+xml a=contact:http://foo.example.com/process1 a=direction:passive a=wsdl:http://schemas.example.com/MyMsgs.wsdl 4.2 Associated Audio and SOAP Session The following example illustrates the case where a SOAP session is being set up alongside an associated audio session. In this example the SOAP session is being used to provide control of a Media Server and BEEP is the transport protocol for the SOAP messages. v=0 o=mediaserver 2890844526 2890844526 IN IP4 mediaserver.example.com s=- t=0 0 c=IN IP4 131.160.1.112 m=audio 5004 RTP/AVP 0 c=IN IP4 0.0.0.0 m=control 605 BEEP application/soap+xml a=contact:soap.beep://mediaserver.example.com/MediaServerControl a=direction:passive a=wsdl:http://schemas.example.com/MSControl.wsdl The recipient of this SDP knows that they can establish a RTP session to 131.160.1.112:5004. In addition they can initate a BEEP connection to the url soap.beep://mediaserver.example.com/ MediaServerControl [14] to perform control of a Media Server sending this audio stream. The format of the supported SOAP messages is defined by http://schemas.example.com/MSControl.wsdl. Deason Expires August 24, 2003 [Page 7] Note that the the connection information in the line "c=IN IP4 131.160.1.112" applies only to the audio media. The BEEP media level description supplies it's own "c=" field containing a null value. 4.3 Usage within the SDP Offer/Answer model The following example shows the case where an offerer sends SDP for a SOAP over HTTP session. In this case the offer wishes to be the initiator of a SOAP over HTTP session. Therefore the direction attribute is set to active. Because they do not know where the answering party will want them to connect to for the session the port number offered in the "m=" line is set to 9 (the discard port) and there is no contact attribute. This behaviour follows the precedence of [6]. v=0 o=- 289083125 289083125 IN IP4 foo.example.com s=- t=0 0 c=IN IP4 0.0.0.0 m=data 9 HTTP application/soap+xml a=direction:active The following SDP is communicated in the answer, which supports a session consisting off a RPC style SOAP messaging. Within the "m=" line corresponding to the "m=" line in the offer the port for the HTTP session is set to 80. The contact attribute carries the URL to use and the direction attribute confirms the offerer will accept the connection. v=0 o=- 2890844526 2890844526 IN IP4 bar.example.com s=- t=0 0 c=IN IP4 0.0.0.0 m=data 80 HTTP application/soap+xml a=contact:http://bar.example.com/process2?id=4935 a=direction:passive 4.3.1 Usage of the SDP Offer/Answer Model to create bi-directional SOAP/ HTTP sessions An interesting case of the SDP Offer/Answer model is to set up bidirectional SOAP over HTTP connections. Typically SOAP over HTTP is used to perform RPC like method calls because of the synchronous nature of HTTP. Sessions being setup by SDP however can create 2 associated HTTP connections between the parties to support richer messaging styles, such as asynchronous event notifications. Deason Expires August 24, 2003 [Page 8] Internet-Draft SDP Usage for SOAP Sessions February 2003 The offer in such an exchange would like: v=0 o=- 289083126 289083126 IN IP4 foo.example.com s=- t=0 0 c=IN IP4 0.0.0.0 m=data 80 HTTP application/soap+xml a=contact:http://foo.example.com/process3?id=7949 a=direction:both a=wsdl:http://schemas.example.com/messages1.wsdl Whereas the response would like: v=0 o=- 2890844527 2890844527 IN IP4 bar.example.com s=- t=0 0 c=IN IP4 0.0.0.0 m=data 80 HTTP application/soap+xml a=contact:http://bar.example.com/process7?id=0235 a=direction:both a=wsdl:http://schemas.example.com/messages1.wsdl Deason Expires August 24, 2003 [Page 9] Internet-Draft SDP Usage for SOAP Sessions February 2003 5. IANA Considerations The new SDP attributes defined in this document need to be registered with IANA. These are the contact attribute (Section 3.3.1) and the wsdl attribute (Section 3.3.2). Deason Expires August 24, 2003 [Page 10] Internet-Draft SDP Usage for SOAP Sessions February 2003 6. Security Considerations The usage of SDP for SOAP sessions does not introduce any new security considerations. But implementors should be aware of the general security considerations for usage of SDP described in [1]. Deason Expires August 24, 2003 [Page 11] Internet-Draft SDP Usage for SOAP Sessions February 2003 References [1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [2] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielsen, H., Thatte, S. and D. Winer, "Simple Object Access Protocol (SOAP) 1.1", W3CNote 08, May 2000. [3] Rosenberg, J. and H. Schulzinne, "An Offer/Answer Model with the Session Description Protocol", RFC 3264, UJune 2002. [4] Rosenberg, J., Schulzinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [5] Wu, X., Wu, X., Koskelainen, P. and H. Schulzinne, "Use of Session Initiation Protocol (SIP) and Simple Object Access Protocol (SOAP) for Conference Floor Control", draft-wu-sipping-floor-control-03 (work in progress), January 2003. [6] Yon, D., "Connection-Oriented Media Transport in SDP", draft-ietf-mmusic-sdp-comedia-04 (work in progress), July 2002. [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [8] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001. [9] Rosenberg, J., "Proposed Changes to Connection Oriented Media Handling in the Session Description Protocol (SDP)", draft-rosenberg-mmusic-comedia-fix-00 (work in progress), January 2003. [10] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [11] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994. [12] Campbell, B., "Instant Message Transport Sessions using the CPIM Message Format", draft-campbell-simple-cpimmsg-sessions-00 (work in progress), October 2002. [13] Christensen, E., Curbera, F., Meredith, G. and S. Weerawarana, "Web Services Description Language (WSDL) 1.1", W3CNote 15, Deason Expires August 24, 2003 [Page 12] Internet-Draft SDP Usage for SOAP Sessions February 2003 March 2001. [14] O'Tuathail, E. and M. Rose, "Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", RFC 3288, June 2002. Author's Address Neil Deason Ubiquity Software Corporation Limited 3 Lagoon Drive Suite 345 Redwood City, CA 94605 USA Phone: +1 650 413 7108 EMail: ndeason@ubiquity.net URI: http://users.rcn.com/neildeason Deason Expires August 24, 2003 [Page 13] Internet-Draft SDP Usage for SOAP Sessions February 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Deason Expires August 24, 2003 [Page 14] Internet-Draft SDP Usage for SOAP Sessions February 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Deason Expires August 24, 2003 [Page 15]