[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                        B. Campbell
Internet-Draft                                               dynamicsoft
Expires: October 31, 2002                                    May 2, 2002


        Requirements for Binding Published Data to SIP Services
                    draft-campbell-pub-bind-reqs-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 October 31, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   A growing number of SIP based services depend on the idea that
   clients may publish service-related information to network elements.
   This information may then affect further processing of the service.
   Examples of such services include presence and CPL.

   Multiple protocols may exists for the actual publication of such
   data.  But regardless of the protocol, a client must know where to
   send it.  This document describes requirements for a mechanism to
   inform clients where and how to publish service related information.






Campbell                Expires October 31, 2002                [Page 1]


Internet-Draft      Service Data Binding Requirements           May 2002


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Scope of This Document . . . . . . . . . . . . . . . . . . . .  3
   3.  Publication Mechanism Assumptions  . . . . . . . . . . . . . .  3
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.1 Publication URI  . . . . . . . . . . . . . . . . . . . . . . .  4
   4.2 Publication Mechanism  . . . . . . . . . . . . . . . . . . . .  4
   4.3 Address of Record  . . . . . . . . . . . . . . . . . . . . . .  4
   4.4 Enumeration of Services  . . . . . . . . . . . . . . . . . . .  4
   4.5 Lifetime of Publication URIs . . . . . . . . . . . . . . . . .  5
   4.6 Communication of Publication URIs  . . . . . . . . . . . . . .  5
   4.7 Separate publication points  . . . . . . . . . . . . . . . . .  5
   4.8 Publication URIs that are not easily guessable . . . . . . . .  5
   4.9 Security . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  5
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  6
       References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  6
       Full Copyright Statement . . . . . . . . . . . . . . . . . . .  7































Campbell                Expires October 31, 2002                [Page 2]


Internet-Draft      Service Data Binding Requirements           May 2002


1. Introduction

   A growing number of SIP [1] related services depend on client
   publication of some form of service data to network elements.  This
   data is then either distributed as part of the service, or affect the
   processing of the service in some way.  Examples include SIMPLE [3],
   where a client may publish a presence document to a remote Presence
   Agent which distributes the document to presence watchers.  Another
   example is the Call Processing Language [2], where users may publish
   CPL scripts to SIP registrars.

   The actual mechanisms for such publications are somewhat
   controversial.  There is general agreement in the SIP and SIPPING
   working groups that the SIP REGISTER method is not adequate to the
   task.  To a lesser degree, there has been agreement that the
   publication mechanism should not be SIP at all.  There is, however,
   no consensus as to what the publication mechanism should be, or that
   a single mechanism makes sense in all situations.

   Regardless of the publication mechanism or mechanisms chosen, clients
   will require a way to determine where to send such service data, and
   to bind that data to a particular service element or resource.  This
   is essentially a matter of client configuration, and could
   conceivably handled through provisioning; however such a provisioning
   effort would likely become prohibitively complex for large
   installations.

2. Scope of This Document

   This document discusses requirements for a service data binding
   mechanism.  It does not propose a mechanism for realizing those
   requirements.

   It does not attempt to address requirements or mechanism for the
   actual publication of service data.  We make only a few very basic
   assumptions about such mechanisms.

3. Publication Mechanism Assumptions

   We assume any service data publication mechanism or mechanisms will
   use a URI based addressing scheme.  It is possible that the mechanism
   will not use URIs natively in its internal addressing scheme, but it
   will be possible to express such addresses in terms of URIs
   externally to the mechanism.  For example, FTP does not natively use
   URIs, but there exists an FTP URI scheme that can be used to express
   the combination of an FTP server  and a location in its file system.

   We assume that more than one publication mechanism will exist, and



Campbell                Expires October 31, 2002                [Page 3]


Internet-Draft      Service Data Binding Requirements           May 2002


   that a single service may actually use multiple mechanisms.

   We assume the existence of mechanisms which directly push service
   data to the publication points, as well as mechanisms where a client
   tells a service a URI where it can find the service data.  (It is
   interesting to notice that indirect publication is also a type of
   binding operation and may have requirements similar to those in this
   document.)

4. Requirements

   This section describes the requirements that are known at the time of
   this draft.  Requirement discussion is still underway in the SIPPING
   working group.  This document attempts to capture the requirements
   discussed so far.

4.1 Publication URI

   The binding mechanism MUST allow a client to discover or infer a URI,
   or set of URIs, to which data may be published for a particular
   service.  The mechanism MUST allow for any URI scheme, and MUST NOT
   make assumptions about how a specific publication mechanism
   interprets URIs.

4.2 Publication Mechanism

   The binding mechanism MUST allow a client to discover or infer the
   mechanism, or set of mechanisms, to use to publish data to a
   particular publication URI.

4.3 Address of Record

   The binding mechanism MUST allow clients to determine binding
   information based only on knowledge of an AoR.  A client MAY allow
   provisioning of individual service publication bindings for an AoR.
   The binding mechanism MUST allow for multiple data-driven services
   for a single AoL, and MUST allow the client to distinguish one such
   service from another for publication purposes.  (For example, the AoR
   "sip:alice@example.com" may have both presence and CPL services
   associated with it.  A client must be able to avoid sending CPL to
   the presence service, or a presence document to the CPL services.)

4.4 Enumeration of Services

   The binding mechanism SHOULD offer a way for a client to determine a
   list of all services for a given AoR for which it can publish data.





Campbell                Expires October 31, 2002                [Page 4]


Internet-Draft      Service Data Binding Requirements           May 2002


4.5 Lifetime of Publication URIs

   The binding mechanism MUST allow a service element to manage the
   lifetime of a publication URI.  It MUST allow long-lived publication
   URIs.  It MAY also allow very short-lived publication URIs; for
   example, the URI may be single-use only.

4.6 Communication of Publication URIs

   The binding mechanism MUST allow a service provider to communicate
   publication URIs to a client, directly or through a third party.  For
   example the client might directly query a service element, or query a
   directory service.  The mechanism MAY also provide a method for a
   client to infer publication URIs from an AoR without directly
   contacting the service elements, for example by using an algorithmic
   transformation, schema mapping, or the DNS.

4.7 Separate publication points

   The mechanism MUST NOT require all publication URIs for a given AoR
   to share the same host, address, or even domain.  The mechanism MUST
   NOT require the publication point for a data-driven service to be
   colocated with the network element(s) that provide the service
   itself.

4.8 Publication URIs that are not easily guessable

   The binding mechanism SHOULD allow the use of publication URIs that
   are not easily guessable.

4.9 Security

   The binding mechanism MUST allow a client to authenticate the source
   of a publication URI.  The mechanism MAY allow a publication URI
   provider to authenticate clients.  The mechanism MUST allow a client
   to ensure that publication URIs have not been tampered with.

5. Security Considerations

   We make the working assumption that service publication bindings are
   somewhat public knowledge.  This document does not contain strong
   requirements for confidential transmission of bindings.  On the
   contrary, algorithmic transformations, DNS approaches, etc.  could
   cause such bindings to be completely public.

   The service data to be published may, on the other hand, be very
   sensitive.  Security of published data is in general an aspect of the
   publication method, and is out of scope for this document.  But it is



Campbell                Expires October 31, 2002                [Page 5]


Internet-Draft      Service Data Binding Requirements           May 2002


   very important that a client can determine that a publication binding
   comes from a known source, and has not been tampered with.
   Otherwise, it would be possible for an attacker to provide a false
   binding, and trick a client into publishing potentially sensitive
   data to an unauthorized party.

6. Acknowledgements

   Robert Sparks, Adam Roach, Sean Olson, Henning Schulzrinne, Jonathan
   Rosenburg, and James Undery all contributed substantially to the
   discussion about this subject.

References

   [1]  Rosenberg, J. and H. Schulzrinne, "SIP: Session Initiation
        Protocol", draft-ietf-sip-rfc2543bis-09 (work in progress),
        February 2002.

   [2]  Lennox, J. and H. Schulzrinne, "Call Processing Language
        Framework and Requirements", RFC 2824, May 2000.

   [3]  Rosenberg, J., "Session Initiation Protocol (SIP) Extensions for
        Presence", draft-ietf-simple-presence-06 (work in progress),
        April 2002.


Author's Address

   Ben Campbell
   dynamicsoft
   5100 Tennyson Parkway
   Suite 1200
   Plano, TX  75024

   EMail: bcampbell@dynamicsoft.com
















Campbell                Expires October 31, 2002                [Page 6]


Internet-Draft      Service Data Binding Requirements           May 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Campbell                Expires October 31, 2002                [Page 7]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/