Network Working Group                                           A. Niemi
Internet-Draft                                                     Nokia
Expires: March 21, 2003                               September 20, 2002


                SIP Specific Data Publication Framework
                draft-niemi-simple-publish-framework-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 March 21, 2003.

Copyright Notice

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

Abstract

   This document describes an extension to the Session Initiation
   Protocol (SIP).  The purpose of this extension is to provide an
   extensible framework for publication of SIP specific data.  This
   extension derives from the recent Internet Draft defining the PUBLISH
   method, but instead of using the SIP events framework, it introduces
   a specific publication framework for the publish mechanism.  The main
   motivations for decoupling publications from events are that the
   event framework is not overloaded, and the applicability of the
   PUBLISH method to problem sets similar to those surfacing in the
   publication of event state is improved.  The SIP publication
   framework is neither intended for general data manipulation, nor is
   it intended to foster any discussion on the issue of using SIP for



Niemi                    Expires March 21, 2003                 [Page 1]


Internet-Draft           Publication Framework            September 2002


   everything.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1 Motivations  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2 Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.3 Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  4
   2.1 Publisher  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.2 Composer . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Publication Packages . . . . . . . . . . . . . . . . . . . . .  6
   3.1 Identification . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.2 Applicability Considerations . . . . . . . . . . . . . . . . .  7
   3.3 Publication Template Package . . . . . . . . . . . . . . . . .  7
   3.4 Publication Information  . . . . . . . . . . . . . . . . . . .  7
   3.5 PUBLISH bodies . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.6 Publication Package Responsibilities . . . . . . . . . . . . .  8
   4.  Proposal for a Way Forward . . . . . . . . . . . . . . . . . .  8
   5.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
       Normative References . . . . . . . . . . . . . . . . . . . . .  9
       Informative References . . . . . . . . . . . . . . . . . . . .  9
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  9
   A.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11
























Niemi                    Expires March 21, 2003                 [Page 2]


Internet-Draft           Publication Framework            September 2002


1. Introduction

   Standardizing a publication mechanism for SIP related service objects
   has historically received a mixed response from the SIP community.
   The reception has oscillated for quite some time between favouring a
   SIP based solution to opposing one.  The latest effort [4] has been
   scoped reasonably well to have a good chance of reaching rough
   working group consensus.  It proposes a SIP based mechanism for event
   state publication, e.g., publication of presence state.  More
   specifically, the I-D proposes a new PUBLISH method for publishing
   event state, and is specified on top of the SIP events framework [3].

   This memo bears close resemblance to the contents of the PUBLISH
   Internet Draft [4], and in fact copies much of the components from
   it.  However, this memo generalizes on the ideas presented in the I-D
   by introducing an extensible framework for SIP specific publications.

   The publication framework in turn closely follows the SIP events
   framework.  The intention is to define a framework by which new
   extension publications called publication packages can be defined.

1.1 Motivations

   Currently, the PUBLISH method is used on top of the SIP events
   framework.  That is, the published event package is identified by the
   "Event" header, and support for publication of state for a certain
   event package is indicated using the "Allow-Events" header.  This is
   unnecessary overloading of the event headers, and instead there needs
   to be a proper way for indicating support for PUBLISH, as well as
   identifying the objects in the PUBLISH request.

   The PUBLISH method is also intended solely for publsihing event
   state.  Such a scope is well justified, since the problem of general
   data manipulation will most probably not be addressed with the
   PUBLISH method [6].  Especially in absence of a set process for
   defining the applications of the PUBLISH method, such a wide scope of
   applicability could be seen to render the mechanism useless.

   However, by creating a framework and a process for the definition of
   PUBLISH applications similar to the ones used for SIP events will
   make it possible to address the current needs for publishing event
   state, without ruling out any future applications which share the
   characteristics of event state publication.

   In conclusion, defining a SIP specific publication framework seems to
   introduce clear benefits without changing the properties of the
   original PUBLISH proposal.




Niemi                    Expires March 21, 2003                 [Page 3]


Internet-Draft           Publication Framework            September 2002


1.2 Conventions

   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 RFC 2119 [1].

1.3 Terminology

   This chapter gives a brief overview of the terminology used in this
   document:

   Composer
      A user agent which receives PUBLISH requests from publishers.

   Publication
      A publication is the act of a publisher sending a PUBLISH request
      to a composer, containing the data being published.

   Publication Package
      An additional specification containing the specific set of
      information needed to be sent from a publisher to a composer.

   Publisher
      A user agent sending a PUBLISH request.


2. Overview of Operation

   (Some text in this chapter has been copied directly from [4] for
   clarity.)

   The PUBLISH method is used to push data to a set of composers, that
   may or may not consume the published data.  The method is constructed
   as an OPTIONS would be, and is allowed to fork.  The PUBLISH request
   does not create a dialog.  Figure 1 describes a typical message flow.
















Niemi                    Expires March 21, 2003                 [Page 4]


Internet-Draft           Publication Framework            September 2002


         Publisher             Composer
            |                     |
            |   (1) PUBLISH       |
            | ------------------> |
            |                     |
            |   (2) 200 OK        |
            | <------------------ |
            |                     |

   Figure 1: Typical message flow for PUBLISH.


   The request URI of the PUBLISH identifies the resource for whom this
   data is being published for.  As such, the sender of a PUBLISH may
   not know all of the endpoints that processed the request
   successfully, but will know if at least one endpoint accepted the
   request by way of the forking rules for isomorphic requests within
   SIP.

   Additionally, unlike the SUBSCRIBE method, the PUBLISH method does
   not create a SIP dialog as part of its processing.  Creation of a
   dialog implies that the sender and recipient need to track the state
   of the PUBLISH itself, which need not be necessary for its proper
   operation.  Therefore, there are no requirements on use/reuse of the
   Call-Id, or tags from PUBLISH to PUBLISH outside of the normal rules
   of SIP.

2.1 Publisher

   Identification of publications is provided by three pieces of
   information: Request-URI, Publication Type, and message body.  The
   Request-URI of a PUBLISH request contains enough information to route
   the request to its appropriate destination.  The rules for routing a
   request are outlined in RFC 3261 [2].

   Publishers MUST include exactly one "Publication" header to the
   PUBLISH request.  The type of the publication is indicated in the
   "Publication" header by a token, which will be registered with the
   Internet Assigned Nubmers Authority (IANA) [7].  Each registered
   token will correspond to a specific publication package, which
   documents the format and the semantics of a publication.  The
   "Publication" header can also contain one or more parameters, defined
   by the publication packages.

   A PUBLISH request MAY contain a body, using the standard MIME headers
   to identify the content.





Niemi                    Expires March 21, 2003                 [Page 5]


Internet-Draft           Publication Framework            September 2002


2.2 Composer

   If a composer is not able to understand the publication type
   indicated in the "Publication" header, it SHOULD return a response
   "490 (Bad Publication)".  Also, the composer SHOULD include in the
   response an "Allow-Publications" header, indicating the supported
   publication types.

3. Publication Packages

   This chapter defines the SIP publication packages.

3.1 Identification

   The definitions for the "Publication" header and the "Allow-
   Publications" header follow closely the definitions of the "Event"
   header and the "Allow-Events" header in SIP events [3]


       Publication          = "Publication" HCOLON publish-type
                              *( SEMI publish-param )
       publish-type         = token-nodot
       token-nodot          = 1*( alphanum / "-" / "!" / "%" / "*"
                                  / "_" / "+" / "`" / "'" / "~" )
       publish-param        = generic-param / pstream / ptype
       pstream              = "stream" EQUAL token
       ptype                = "type" EQUAL token

       Allow-Publications   = "Allow-Publications" HCOLON publish-type
                              * ( COMMA publish-type )


   Note that the semantics associated with elements "pstream" and
   "ptype" are defined as in [4].

   Additionally, a new response code for SIP is defined.  This response
   code is used by the publication agents to indicate lack of support
   for indicated publication.


       Response Code Number:    490
       Default Reason Phrase:   Bad Publication









Niemi                    Expires March 21, 2003                 [Page 6]


Internet-Draft           Publication Framework            September 2002


3.2 Applicability Considerations

   Each new design for a publication package should consider whether the
   SIP PUBLISH is the correct solution for the problem at hand.  There
   are numerous RPC mechanisms defined, which are seen far more suitable
   for manipulating data objects, even those relating to the services
   SIP provides.

      Extensions to this mechanism fall under the guidelines given in
      the document "Guidelines for Authors of SIP Extensions" [5].

   Specifically, a designer of an extension publication package should
   consider the exact benefits SIP would bring to the solution, compared
   to using any existing RPC mechanism, for example.  Simply because an
   application can be implemented with a SIP publication package doesn't
   mean it should.  For example, a need to make use of the routing
   capabilities of SIP would constitute a valid reason for using SIP
   PUBLISH for that particular application.

3.3 Publication Template Package

   A publication template package is a publication package capable of
   being associated with any other publication package, including
   itself.

      OPEN ISSUE: Although template packages for publications would be
      possible to have in the publication framework, is there need for
      such things?


3.4 Publication Information

   The design of publication packages needs to take into consideration
   the amount and type of data to be published.  In some cases, data can
   be published in its entirety, whereas in some cases, the data can be
   published in smaller pieces.

   The interaction of such pieces of published data needs to be
   consistent with the application, and needs to be defined and
   documented by the publication package.

3.5 PUBLISH bodies

   Most publication packages probably define syntax and semantics for
   the PUBLISH body.  The body of the PUBLISH will usually deliver the
   data to be published to the composer.  Additionally, mechanisms such
   as XML Path Language (XPath) [8] could additionally be used to impose
   further semantics to the body.



Niemi                    Expires March 21, 2003                 [Page 7]


Internet-Draft           Publication Framework            September 2002


3.6 Publication Package Responsibilities

   Specification of extensions, or publication packages need to adhere
   to a set process.  Each publication package needs to define a name
   for the package, any parameters used in the "Publication" header, the
   body of the PUBLISH method, and any behavior that extends or modifies
   the behavior of the PUBLISH mechanism.

   A publication package is identified by a token in the "Publication"
   header.  The namespace for the token needs a central coordination
   body, which in this case is the Internet Assigned Numbers Authority
   (IANA) [7].

      OPEN ISSUE: The exact details of the process of defining and
      registering new publication packages (and template packages) is
      yet to be defined.


4. Proposal for a Way Forward

   This document takes the PUBLISH method [4] as a basis for the
   publication framework.  The proposal is to evaluate the feasibility
   of the publication framework introduced in this document, and
   incorporate the work into the PUBLISH work.  Note that this document
   is not complete in its definition of the publication framework, but
   should give enough details for continuing the work.

5. Open Issues

   Open issues in this document:

   o  Are template packages a viable concept for publications?

   o  Details of the publication package framework is still to be done.


6. Security Considerations

   This specification adds no new security considerations to the
   documents to which it refers.  Security issues for the publication
   framework will need to be addressed in future versions of this work,
   similarly to [4] and [3].

7. IANA Considerations

   This document specifies two new header fields in SIP, namely
   "Publication" and "Allow-Publications".  Future versions of this work
   need to define the exact IANA considerations of these new header



Niemi                    Expires March 21, 2003                 [Page 8]


Internet-Draft           Publication Framework            September 2002


   fields, the new publication package namespace, the new response code,
   and include the definition of the new SIP method "PUBLISH" from [4].
   These are omitted from this document for now.

Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

   [3]  Roach, A., "Session Initiation Protocol (SIP)-Specific Event
        Notification", RFC 3265, June 2002.

   [4]  Campbell, B., "SIMPLE Presence Publication Mechanism", draft-
        olson-simple-publish-00 (work in progress), June 2002.

Informative References

   [5]  Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of
        Extensions to the Session Initiation Protocol  (SIP)", draft-
        ietf-sip-guidelines-05 (work in progress), June 2002.

   [6]  Rosenberg, J. and M. Isomaki, "Requirements for Manipulation of
        Data Elements in SIMPLE Systems", draft-rosenberg-simple-data-
        req-00 (work in progress), June 2002.

   [7]  http://www.iana.org, "Assigned Numbers", September 2002.

   [8]  http://www.w3c.org/TR/xpath, "XML Path Language", September
        2002.


Author's Address

   Aki Niemi
   Nokia
   P.O. Box 301
   NOKIA GROUP, FIN  00045
   Finland

   Phone: +358 50 389 1644
   EMail: aki.niemi@nokia.com






Niemi                    Expires March 21, 2003                 [Page 9]


Internet-Draft           Publication Framework            September 2002


Appendix A. Acknowledgements

   The author would like to thank Markus Isomaki and Pekka Pessi for
   their comments and suggestions.















































Niemi                    Expires March 21, 2003                [Page 10]


Internet-Draft           Publication Framework            September 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.



















Niemi                    Expires March 21, 2003                [Page 11]