Internet DRAFT - draft-deason-mmusic-sdp-soap
draft-deason-mmusic-sdp-soap
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=<media> <port> <transport> <fmt list>
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:<role> [<source-address>]
The <role> 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 <source-address> is an optional set of values that describes
where the connection will originate.
When describing SOAP sessions in SDP the <source-address> 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]
