[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
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]