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 <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] 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.
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 <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:
Boehmer & Tschofenig Expires April 18, 2005 [Page 9]
Internet-Draft Service Identification October 2004
<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>
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.
<?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>
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]