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]