Status of this Memo

By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I 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). All Rights Reserved.

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.

Table of Contents

1.  Introduction
2.  Terminology
3.  Discussion of possible Approaches
    3.1  Deduction of Services
    3.2  Enumeration of Services
4.  Proposal
5.  Discussion
6.  Example
7.  XML Schema
8.  Security Considerations
9.  IPR Considerations with UDDI
10.  Open Issues
11.  Acknowledgments
§.  Normative References
§.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1. Introduction

A lot of discussion [SIMPLE WG discussion]SIMPLE WG, SIMPLE WG discussion on service identification, September 2004. took place around the identification of services with regard to the definition of the presence data model [I-D.ietf-simple-presence-data-model]Rosenberg, J., A Data Model for Presence, September 2004. 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:

• 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.
• Services exist in different versions which generally do fully not interwork.
• 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.

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]Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, March 1997..

3. Discussion of possible Approaches

[I-D.roach-simple-service-features]Roach, A., Identification of Services in RPID (Rich Presence Information Data), February 2004. 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:

• URI scheme, e.g. pres:, sip:, im:, etc.
• set of supported SIP methods
• capabilities listed in [RFC3840]Schulzrinne, H., Rosenberg, J. and P. Kyzivat, Indicating User Agent Capabilities in the Session Initiation Protocol (SIP), August 2004. and [I-D.ietf-simple-prescaps-ext]Lonnfors, M. and K. Kiss, User agent capability presence status extension, May 2004..

This proposal has been discussed extensively in the SIMPLE WG [SIMPLE WG discussion]SIMPLE WG, SIMPLE WG discussion on service identification, September 2004.. 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]SIMPLE WG, SIMPLE WG discussion on service identification, September 2004..
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 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.

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]Bellwood, T., Claement, L. and C. von Riegen, UDDI Version 3.0.1, UDDI Spec Technical Committee Specification, Dated 20031014, October 2003.. 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]Bellwood, T., Claement, L. and C. von Riegen, UDDI Version 3.0.1, UDDI Spec Technical Committee Specification, Dated 20031014, October 2003.. 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]Schulzrinne, H., Gurbani, V., Kyzivat, P. and J. Rosenberg, RPID: Rich Presence: Extensions to the Presence Information Data Format (PIDF), March 2004.. This serviceDescription is a complex type and consists of three elements: a <tModelKey> element, a <name> element and an optional <description> element. <tModelKey> is an element containing a tModel key of the tModel describing the service. The tModel key MUST follow the encoding rules given in [UDDI]Bellwood, T., Claement, L. and C. von Riegen, UDDI Version 3.0.1, UDDI Spec Technical Committee Specification, Dated 20031014, October 2003. and MUST have the same value as the UDDI tModel attribute "tModelKey" registered with at the UDDI registry. <name> 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. <description> contains a short description of the service. It SHOULD be the same as the description used in the UDDI "description" element.

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.

6. Example

The sample XML document is based on the RPID extension [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), March 2004.. The service status is set to "open" and an appropriate icon is provided via <status-icon>. The service "foo service" is described in a tModel which is identified by the <tModelKey>.

   <?xml version="1.0" encoding="UTF-8"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
   xmlns:ep="urn:ietf:params:xml:ns:pidf:status:rpid-status"
   xmlns:et="urn:ietf:params:xml:ns:pidf:rpid-tuple"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   entity="pres:someone@example.com"
   xsi:schemaLocation="urn:ietf:params:xml:ns:pidf pidf.xsd
   urn:ietf:params:xml:ns:pidf:status:rpid-status rpid-status.xsd
   urn:ietf:params:xml:ns:pidf:rpid-tuple rpid-tuple.xsd">
   	<tuple id="x765">
   		<status>
   			<basic>open</basic>
   			<ep:privacy>public</ep:privacy>
   			<ep:idle since="2003-01-27T10:43:00Z"/>
   			<ep:status-icon>
   			http://www.example.com/fooService/statusActive.gif
   			</ep:status-icon>
   		</status>
   		<et:class>sip</et:class>
   		<contact priority="0.8">sip:someone@example.com</contact>
   		<timestamp>2001-10-27T16:49:29Z</timestamp>
   		<!-- This part is defined by the present document. --> 
		<et:serviceDescription>
			<et:tModelKey>
			    uuid:c8aea832-3faf-33c6-b32a-bbfd1b656294
			</et:tModelKey>
			<et:name>
			 	example.com:fooService	
			</et:name>
			<et:description>
			    The foo Service doing some nice things.
			</et:description>
		</et:serviceDescription>
		<!-- End of newly defined part. -->
	</tuple>
   </presence>

A sample tModel is given below:

<tModel tModelKey="uuid:c8aea832-3faf-33c6-b32a-bbfd1b656294">
  <name>example.com:fooService</name>
  <description>The foo Service doing some nice things.</description>
  <overviewDoc>
    <overviewURL useType="text">
       http://www.example.com/theFooService.htm
    </overviewURL>
  </overviewDoc>
</tModel>

7. XML Schema

The schema definition relies on the RPID schema specified in [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), March 2004.. The additions defined by this document are identified.

             
  <?xml version="1.0" encoding="UTF-8"?>
  <schema 
   targetNamespace="urn:ietf:params:xml:ns:pidf:status:rpid-tuple"
   xmlns:rp="urn:ietf:params:xml:ns:pidf:rpid-tuple"
   xmlns="http://www.w3.org/2001/XMLSchema"
   elementFormDefault="qualified"
   attributeFormDefault="unqualified">

   <!-- This import brings in the XML language attribute xml:lang-->
   <xs:import namespace="http://www.w3.org/XML/1998/namespace"
     schemaLocation="http://www.w3.org/2001/xml.xsd"/>

   <annotation>
     <documentation xml:lang="en">
       Describes RPID tuple extensions for PIDF.
     </documentation>
   </annotation>

     
   <element name="class" type="token"/>

   <element name="relationship" type="token"/>
     
 <!-- Start add to RPID schema -->    
 <element name="serviceDescription">
   <complexType>
     <sequence minOccurs="1" maxOccurs="unbounded">
       <element name="tModelKey" type="token"/>
       <element name="name" type="token"/>
       <element name="description" type="token" 
            minOccurs="0" maxOccurs="1" />  
     </sequence>
    </complexType>
 </element> 
 <!-- End add to RPID schema -->
 </schema>   
   

8. Security Considerations

TBD

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], OASIS UDDI Specification TC, IPR disclosure page, ..

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.

11. Acknowledgments

The authors would like to thank Christian Schmidt and Stefan Goeman for their input to this draft.

12. References

12.1 Normative References

12.2 Informative References

Authors' Addresses

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.