MMUSIC V. Olmedo Internet-Draft V. Villagra Expires: May 8, 2008 UPM J. Burgos Experience IS G. Gallizo Telefonica I+D November 5, 2007 The Session Description Protocol (SDP) WSDL Attribute draft-volmedo-mmusic-sdp-wsdl-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 May 8, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Olmedo, et al. Expires May 8, 2008 [Page 1] Internet-Draft WSDL Attribute November 2007 Abstract This document defines a new Session Description Protocol (SDP) media- level attribute: 'wsdl'. The 'wsdl' attribute allows for a user running Web Services to let a potential client know the Uniform Resource Identifier (URI) where the Web Service Description Language file (WSDL) describing the service can be obtained. The WSDL file describes the public interface offered by the Web Service and allows the client to consume the service. It also defines the SDP proto value 'TCP/HTTP', needed for this type of communication. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. The 'wsdl' Attribute . . . . . . . . . . . . . . . . . . . . . 6 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Olmedo, et al. Expires May 8, 2008 [Page 2] Internet-Draft WSDL Attribute November 2007 1. Introduction The Session Description Protocol (SDP) [1] is a protocol usually intended to describe multimedia sessions, most typically used with the Session Initiation Protocol (SIP) [9]. This combination allows the establishment and management of multimedia sessions with nomadic and mobile users who can be connected from heterogeneous devices. Currently, massive usage of nomadic and mobile devices has pushed for these devices hosting also other kind of applications and services, not always related to multimedia. Specifically, Web Service-based applications are one of the most popular services nowadays under the so-called Service Oriented Architecture (SOA). SDP is generic in order to describe different types of sessions. However, these sessions may need some specific session-related attributes for its establishment. This is the case of Web Service sessions, where the requestor needs to access the description of the offered services, specified in a Web Service Description Language (WSDL) document. This specification defines the SDP 'wsdl' media-level attribute, which provides the requestor with a pointer for accessing the service description document from the provider. Also, as this attribute is intended to allow the creation of Web Service sessions, which usually use HTTP as transport protocol, this specification also defines two new proto values: 'TCP/HTTP' and 'TCP/TLS/HTTP'. These new values are in conformance with RFC 4145 [2]. Olmedo, et al. Expires May 8, 2008 [Page 3] Internet-Draft WSDL Attribute November 2007 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [3], and indicate requirements levels for compliant implementations. Olmedo, et al. Expires May 8, 2008 [Page 4] Internet-Draft WSDL Attribute November 2007 3. Motivation The aim of this Internet-Draft is the definition of a new SDP attribute in order to allow the exchanging of the necessary information between two entities willing to establish a "Web Service session" by using the SDP offer/answer model [4]. The established session could be used, for example, by a Web Service requestor (WS- requestor) in order to invoke a service exposed by a Web Service provider (WS-provider). Considering that the Web Service Description Language document (WSDL) [10] is a key element on a standard Web Service interaction, a reference to this element needs to be included in the new attribute. The WSDL document contains an XML-based description of the public interface that a Web Service offers, so in the most generic Web Service interaction scenario, a WS-requestor will need access to the WSDL of a WS-provider in order to generate the required software to invoke the offered service. A WS-requestor can obtain this service WSDL document URI in multiple manners, e.g., through WS-specific mechanisms, such as UDDI [11], or directly (in a peer-to-peer fashion) from the service provider, either by pre-sharing the WSDL URI (if the service resides in a fixed device) or by using the mechanism proposed in this Internet-Draft to obtain this URI dynamically (especially suitable for nomadic/mobile devices). The usage of nomadic/mobile devices (laptops, PDA and mobile phones) acting as services providers becomes a reality. The demand on such devices has experienced a spectacular increase, in parallel with the growth of the capabilities that these devices can offer (memory, CPU power, autonomy, interoperability...), and the intensive deployments of wireless networks based on different technologies (like WiFi or WiMax). The definition of a SDP offer/answer model-based mechanism to retrieve the WSDL document is especially relevant in a mobile and pervasive environment. The physical network address of a mobile computer hosting a service can change for many reasons, e.g., a network handover, or because the device is switched off since the user wants to remain connected from a different one. Olmedo, et al. Expires May 8, 2008 [Page 5] Internet-Draft WSDL Attribute November 2007 4. The 'wsdl' Attribute This section provides the definition of the 'wsdl' attribute using Augmented Backus Naur Form (ABNF) [5] notation: wsdl-attribute = "a=wsdl:" wsdl-uri wsdl-uri = scheme ":" hier-part [ "?" query ] [ "#" fragment ] The 'wsdl' attribute contains a pointer (the 'wsdl-uri' part) to the WSDL file that defines the Web Service offered. This pointer has the form of a URI, as defined in RFC 3986 [6]. As WSDL files are usually fetched using HTTP, the most common value for the 'scheme' field is 'http'. Olmedo, et al. Expires May 8, 2008 [Page 6] Internet-Draft WSDL Attribute November 2007 5. Examples This section shows the SDP messages that will be exchanged when a service consumer (Alice) contacts the service provider (Bob) in order to define a new service session. In such an interaction, Alice is the Offerer and Bob is the Answerer, according to the SDP Offer/ Answer Model [4]. When a positive answer is received in response to a previous offer, the new service session is created and ready to be used. Alice and Bob will then send and receive the SOAP messages needed to consume the service. The WSDL file location is sent by the service provider as part of the service session creation process. In order to define the service session, Alice constructs the SDP shown below: v=0 o=alice 28903711 28903711 IN IP4 192.0.2.1 s=- c=IN IP4 192.0.2.1 t=0 0 m=application 9 TCP/HTTP soap+xml a=setup:active The SDP above defines a HTTP session targeted to the exchange of SOAP messages. Although other protocols could also be used, HTTP is the most popular binding for SOAP. The SDP "s=" line has a value of "-", as recommended by RFC 3264 [4] for unicast sessions. Also in RFC 3264, it is recommended to use a value of "0 0" for the "t=" line when the session is initiated and terminated using external signaling means, which will always be the case in this kind of sessions. Of course, the "m=" line defines an application-type media that will be used to send and receive SOAP messages over HTTP. A client-server relationship is defined for the exchange of SOAP messages, with Alice being the client in this example. As this kind of communication is connection-oriented, this specification is in conformance with RFC 4145 [2]. On the one hand, this specification uses a new proto value, 'TCP/ HTTP' (and 'TCP/TLS/HTTP' when using Transport Layer Security (TLS) [12] to secure the HTTP communication). On the other hand, it reuses the 'setup' attribute, which is used here with a value of "active" to indicate that Alice will initiate the SOAP interaction. Besides, the port number included in the "m=" line is set to 9 (the discard port), Olmedo, et al. Expires May 8, 2008 [Page 7] Internet-Draft WSDL Attribute November 2007 as it is irrelevant but a valid port number must be used (as recommended in RFC 4145). When Bob receives Alice's offer, he constructs an answer and sends it back to Alice. The SDP answer is shown below: v=0 o=bob 28903823 28903823 IN IP4 192.0.2.2 s=- c=IN IP4 192.0.2.2 t=0 0 m=application 80 TCP/HTTP soap+xml a=setup:passive a=wsdl:http://192.0.2.2/service.wsdl In this answer, Bob indicates that he is willing to accept ("a=setup: passive") SOAP messages over HTTP at the port 80. Finally, he uses a "a=wsdl" line to indicate where the WSDL file that defines the service can be retrieved. Olmedo, et al. Expires May 8, 2008 [Page 8] Internet-Draft WSDL Attribute November 2007 6. Security Considerations As 'wsdl' attributes contain URIs to WSDL files, an attacker may attempt to use this URI to contact the service. This is usually not a problem, as authentication mechanisms can be imposed by the service. However, an attacker could also modify the content of the 'wsdl' attribute or even remove it completely. This could lead to Denial of Service (DoS) attacks, man-in-the-middle attacks or other kinds of attacks depending on how the applications handle the bogus signalling. Therefore, it is strongly RECOMMENDED to apply integrity protection to SDP session descriptions. For session descriptions carried as SIP message bodies, mechanisms as Transport Layer Security (TLS) [12] or Secure MIME (S/MIME) [13] MAY be used to provide integrity protection. These mechanisms can also be used to provide confidentiality if required. Olmedo, et al. Expires May 8, 2008 [Page 9] Internet-Draft WSDL Attribute November 2007 7. IANA Considerations This document defines a new 'wsdl' media-level attribute for SDP. Its format is defined in Section 4. The following information characterizes the 'wsdl' attribute: Contact name: Vicente Olmedo . Attribute name: 'wsdl'. Type of attribute: Media level. Subject to charset: No. Purpose of attribute: The 'wsdl' attribute provides the URI of the WSDL file that defines a Web Service. No standard values need to be defined. As the 'wsdl' attribute contains the URI of a WSDL file, every URI in conformance with RFC 3986 [6] is also an allowed value for the 'wsdl' attribute. Additionally, this document defines new proto values: 'TCP/HTTP' and 'TCP/TLS/HTTP'. These proto values should be registered by the IANA under "Session Description Protocol (SDP) Parameters" under "proto". These values are constructed according to the advices given in Section 8 of RFC 4145 [2]. According to the RFC 4566 [1], that defines SDP, the definition of new proto values must be accompanied by the definition of the associated media formats, i.e., the allowed fmt values. For the HTTP protocol, new formats SHOULD have an associated MIME registration. Use of an existing MIME subtype for the format is encouraged. If no MIME subtype exists, it is RECOMMENDED that a suitable one is registered through the IETF process [7] by production of, or reference to, a standards-track RFC that defines the transport protocol for the format. Olmedo, et al. Expires May 8, 2008 [Page 10] Internet-Draft WSDL Attribute November 2007 8. Acknowledgements The authors would like to thank the members of the AKOGRIMO (Access to Knowledge through the Grid in a Mobile World) [14] project, funded by the European Commission under the FP6-IST programme, where the problem was identified and the proposed solution was designed and implemented. Olmedo, et al. Expires May 8, 2008 [Page 11] Internet-Draft WSDL Attribute November 2007 9. References 9.1. Normative References [1] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [2] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [7] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996. [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 9.2. Informative References [9] 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. [10] Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, "Web Service Description Language (WSDL) Version 2.0 Part 1: Core Language", World Wide Web Consortium Recommendation REC-wsdl20- 20070626, June 2007. [11] Clement, L., Hately, A., von Riegen, C., and T. Rogers, "UDDI Version 3 Specification", OASIS Specification, October 2004. [12] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. Olmedo, et al. Expires May 8, 2008 [Page 12] Internet-Draft WSDL Attribute November 2007 [13] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. [14] The AKOGRIMO Consortium, "AKOGRIMO Project Web Site", . Olmedo, et al. Expires May 8, 2008 [Page 13] Internet-Draft WSDL Attribute November 2007 Authors' Addresses Vicente Olmedo Technical University of Madrid Avda. Complutense s/n Madrid, Madrid 28040 ES Phone: +34 91 549 57 00 ext. 3024 Email: volmedo@dit.upm.es URI: http://www.dit.upm.es/volmedo Victor Villagra Technical University of Madrid Avda. Complutense s/n Madrid, Madrid 28040 ES Phone: +34 91 453 35 15 Email: villagra@dit.upm.es URI: http://www.dit.upm.es/villagra Juan Enrique Burgos Experience Ingenieria y Servicios Parque Tecnologico de Boecillo, Edificio Centro, Modulo 202 Boecillo, Valladolid 47151 ES Phone: +34 98 354 82 86 Email: jeburgos@experienceis.com Georgina Gallizo Telefonica Investigacion y Desarrollo Emilio Vargas 6 Madrid, Madrid 28043 ES Phone: +34 91 312 98 79 Email: gallizo@tid.es Olmedo, et al. Expires May 8, 2008 [Page 14] Internet-Draft WSDL Attribute November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Olmedo, et al. Expires May 8, 2008 [Page 15]