SIMPLE B. Boehmer Internet-Draft H. Tschofenig Expires: April 18, 2005 Siemens October 18, 2004 Service Identification draft-boehmer-simple-service-identification-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 April 18, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document discusses the aspect of service identification in presence documents. A solution is proposed which extends RPID by utilizing the tModel service description provided by the Universal Description, Discovery and Integration (UDDI) framework. Boehmer & Tschofenig Expires April 18, 2005 [Page 1] Internet-Draft Service Identification October 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Discussion of possible Approaches . . . . . . . . . . . . . . 5 3.1 Deduction of Services . . . . . . . . . . . . . . . . . . 5 3.2 Enumeration of Services . . . . . . . . . . . . . . . . . 5 4. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. IPR Considerations with UDDI . . . . . . . . . . . . . . . . . 13 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 16 12.2 Informative References . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 18 Boehmer & Tschofenig Expires April 18, 2005 [Page 2] Internet-Draft Service Identification October 2004 1. Introduction A lot of discussion [SIMPLE WG discussion] took place around the identification of services with regard to the definition of the presence data model [I-D.ietf-simple-presence-data-model] in the SIMPLE WG. An important concept is the requirement to inform a watcher about the communication means of a presentity. This can be either "simple" voice communication or may be based upon a highly complex voice/-video interaction with a computer game. Providing this information to the watcher allows him or her to make an appropriate decision about the communication means to be used. Furthermore, beside the communication aspect, certain services may maintain a rich set of internal states being of interest for certain watchers, e.g. high scores in games, entering of a certain person on a chat room, etc. Thus, services may act as differentiated presence sources on their own and, therefore, a means to represent this service and its states is a relevant requirement. Identification of services is, however, a highly non-trivial issue due to a number of reasons. Many of them being already mentiond in mailing list dicussions in the SIMPLE working group: o A vast amount of services exists. In general, they are of more or less proprietary character. This fact must be taken into account as soon as services are considered. Especially, services may use proprietary protocols or proprietary extensions of standardized protocols. o Services exist in different versions which generally do fully not interwork. o Standardization of services is too slow and will be therefore only done for a small subset of services. For the IETF, this task is even not on the agenda. This document proposes an approach to service description based on the UDDI framework. Boehmer & Tschofenig Expires April 18, 2005 [Page 3] Internet-Draft Service Identification October 2004 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Boehmer & Tschofenig Expires April 18, 2005 [Page 4] Internet-Draft Service Identification October 2004 3. Discussion of possible Approaches [I-D.roach-simple-service-features] discusses two basic approaches to deal with this issue. Either an enumeration of services should be provided or services are deduced from low-level capabilities or external information. 3.1 Deduction of Services This approach assumes that a service may be derived from a set of low-level attributes. Most important attributes discussed are: o URI scheme, e.g. pres:, sip:, im:, etc. o set of supported SIP methods o capabilities listed in [RFC3840] and [I-D.ietf-simple-prescaps-ext]. This proposal has been discussed extensively in the SIMPLE WG [SIMPLE WG discussion]. This approach has certain limitations we summarize here: 1. There does not exist a unique URI scheme for each service. It is even questionable whether such an approach would be feasible since the routing network must each time be adapted to this new URI scheme. 2. Proprietary services using an existing URI scheme cannot be distinguished from standardized ones. The granularity of URI schemes cannot be made fine enough to allow such distinction. 3. URI schemes may subsume more than one service, see the SIMPLE WG mailing list discussions [SIMPLE WG discussion]. 4. Describing services based on a finite list of capabilities implies already a certain degree of service standardization since every service using more than those capabilities would obscure this kind of service description. 5. Even in case of identical URI scheme, used protocol methods, and codecs there might exist differences in behavior. This can only be documented by additional specifications. 6. A given service may be realized in different manners. A typical example are the IM and Presence services both being at least implemented by the SIP/SIMPLE standard and the Wireless Village/OMA IMPS standard. Thus, enlisting of SIP UA capabilities is not sufficient to describe a given service. 7. Exchanging the set of capabilities increases the size of the presence document. Especially for the wireless world this may become an issue. 3.2 Enumeration of Services The current discussion around the enumeration of services implies that each service has a unique ID assigned to. This approach has Boehmer & Tschofenig Expires April 18, 2005 [Page 5] Internet-Draft Service Identification October 2004 also some drawbacks: 1. Identifying a service by a unique ID in a pidf-extension requires some kind of service standardization. It might be difficult to address proprietary solutions and new services quickly. 2. Each combination of service capabilities leads to a new variant of the service. Assigning a service ID to each of these variants would lead to a combinatorial increase of service IDs. Thus, defining a fixed set of service ID is not possible or difficult to maintain. 3. Using the name of the service or, generally, proprietary assignments of service IDs will prevent interworking between technically equally services due to the different name space used. Boehmer & Tschofenig Expires April 18, 2005 [Page 6] Internet-Draft Service Identification October 2004 4. Proposal This document proposes a solution combining aspects of both approaches summarized in Section 3. Main idea is the introduction of a unique reference to a service description. The reference is generated at service development time by an appropriate entity. The service description can be provided by a standardization body or as proprietary solution by anybody. This combines the advantages of the deduction of services (a complete description is provided via the reference) and the enumeration of services in an easily extensible solution. As a basis, we rely on the Universal Description & Integration (UDDI) infrastructure as defined in [UDDI]. The focus of UDDI is the definition of a framework supporting the description and discovery of 1. businesses, organizations, and other services providers, 2. the services they are publishing, 3. the technical interface which may be used to access those services. Note that UDDI encompasses any kind of services and not Web Services only. The solution proposal introduces an extension to the presence document providing a reference to a service description. This description is a tModel as defined by [UDDI]. It is part of a service description and MUST be registered with a public UDDI registry such as uddi.microsoft.com or uddi.ibm.com. It may be either maintained by a standardization body in charge of the service specification or a company providing a proprietary service solution. It introduces a new status element "serviceDescription" to the tuple definition in [I-D.ietf-simple-rpid]. This serviceDescription is a complex type and consists of three elements: a element, a element and an optional element. is an element containing a tModel key of the tModel describing the service. The tModel key MUST follow the encoding rules given in [UDDI] and MUST have the same value as the UDDI tModel attribute "tModelKey" registered with at the UDDI registry. contains the name of the service. It MUST be the same as given in the "name" element of the UDDI tModel structure stored in the UDDI registry. contains a short description of the service. It SHOULD be the same as the description used in the UDDI "description" element. Boehmer & Tschofenig Expires April 18, 2005 [Page 7] Internet-Draft Service Identification October 2004 5. Discussion The given proposal addresses some of the issues of service description. The presence document contains not the complete description but only a reference to a full description. The presence document remains light. By using the UDDI tModel approach an established solution can be reused. The services have a unique identifier. This is ensured by the tModel key which is unique by specification and ensured by the UDDI registries. The technical description of services can be done thoroughly in the overview document. Not only protocol message details but any kind of additional information such as behavior of the service, codecs, internal states (if needed as presence information) may be described here. The UDDI framework allows a flexible and - if needed - automated management of service descriptions. This allows to deal with the assumed strong dynamics in the (application) service area. Reuse of this functionality seems appropriate. Eventually (see the open issues section) the categorization scheme of UDDI may allow the management of variants of one service. Each variant can have its own tModel key but is maintained as variant of the same basic service. This can also include proprietary variants. Boehmer & Tschofenig Expires April 18, 2005 [Page 8] Internet-Draft Service Identification October 2004 6. Example The sample XML document is based on the RPID extension [I-D.ietf-simple-rpid]. The service status is set to "open" and an appropriate icon is provided via . The service "foo service" is described in a tModel which is identified by the . open public http://www.example.com/fooService/statusActive.gif sip sip:someone@example.com 2001-10-27T16:49:29Z uuid:c8aea832-3faf-33c6-b32a-bbfd1b656294 example.com:fooService The foo Service doing some nice things. A sample tModel is given below: Boehmer & Tschofenig Expires April 18, 2005 [Page 9] Internet-Draft Service Identification October 2004 example.com:fooService The foo Service doing some nice things. http://www.example.com/theFooService.htm Boehmer & Tschofenig Expires April 18, 2005 [Page 10] Internet-Draft Service Identification October 2004 7. XML Schema The schema definition relies on the RPID schema specified in [I-D.ietf-simple-rpid]. The additions defined by this document are identified. Describes RPID tuple extensions for PIDF. Boehmer & Tschofenig Expires April 18, 2005 [Page 11] Internet-Draft Service Identification October 2004 8. Security Considerations TBD Boehmer & Tschofenig Expires April 18, 2005 [Page 12] Internet-Draft Service Identification October 2004 9. IPR Considerations with UDDI In the context of UDDI IPR statements exit. For further information see the Intellectual Property Rights section at the UDDI Spec TC web page [UDDI-IPR]. Boehmer & Tschofenig Expires April 18, 2005 [Page 13] Internet-Draft Service Identification October 2004 10. Open Issues It is an open issue whether the categorization scheme of UDDI can be used to manage services and their variations. Such a categorization could be used to manage variants of a service. Eventually, some standardization work for the categoization has to be done. This draft does not address how service-specific state is published in presence documents. However, the presented approach could be extended by adding presence states into the overview document referenced by the tModel. Boehmer & Tschofenig Expires April 18, 2005 [Page 14] Internet-Draft Service Identification October 2004 11. Acknowledgments The authors would like to thank Christian Schmidt and Stefan Goeman for their input to this draft. Boehmer & Tschofenig Expires April 18, 2005 [Page 15] Internet-Draft Service Identification October 2004 12. References 12.1 Normative References [I-D.ietf-simple-rpid] Schulzrinne, H., Gurbani, V., Kyzivat, P. and J. Rosenberg, "RPID: Rich Presence: Extensions to the Presence Information Data Format (PIDF)", draft-ietf-simple-rpid-03 (work in progress), March 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [UDDI] Bellwood, T., Claement, L. and C. von Riegen, "UDDI Version 3.0.1, UDDI Spec Technical Committee Specification, Dated 20031014", October 2003. 12.2 Informative References [I-D.ietf-simple-prescaps-ext] Lonnfors, M. and K. Kiss, "User agent capability presence status extension", draft-ietf-simple-prescaps-ext-01 (work in progress), May 2004. [I-D.ietf-simple-presence-data-model] Rosenberg, J., "A Data Model for Presence", draft-ietf-simple-presence-data-model-00 (work in progress), September 2004. [I-D.roach-simple-service-features] Roach, A., "Identification of Services in RPID (Rich Presence Information Data)", draft-roach-simple-service-features-00 (work in progress), February 2004. [RFC3840] Schulzrinne, H., Rosenberg, J. and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. [SIMPLE WG discussion] SIMPLE WG, "SIMPLE WG discussion on service identification", mail thread, September 2004. [UDDI-IPR] "OASIS UDDI Specification TC, IPR disclosure page". Boehmer & Tschofenig Expires April 18, 2005 [Page 16] Internet-Draft Service Identification October 2004 Authors' Addresses Bernhard Boehmer Siemens Siemensdamm 50 Berlin, Berlin 13629 Germany EMail: bernhard.boehmer@siemens.com Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bayern 81730 Germany EMail: hannes.tschofenig@siemens.com Boehmer & Tschofenig Expires April 18, 2005 [Page 17] Internet-Draft Service Identification October 2004 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Boehmer & Tschofenig Expires April 18, 2005 [Page 18]