Internet DRAFT - draft-donovan-publish-requirements
draft-donovan-publish-requirements
Transport Working Group S. Donovan
Internet-Draft dynamicsoft
Expires: May 22, 2002 November 21, 2001
Requirements for Publication of SIP related service data
draft-donovan-publish-requirements-01.txt
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 May 22, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document defines the requirements for a proposed extension to
the Session Initiation Protocol [1]. This extension would provide a
general-purpose mechanism for uploading service related data. For
instance, there is currently the need to upload or publish CPL to SIP
Proxies and presence documents to SIP Presence Servers.
This document does NOT outline an extension to SIP to handle these
requirements. The author is attempting to follow the guidelines that
requirements should be defined and agreed to before work on the an
extension begins.
Donovan Expires May 22, 2002 [Page 1]
Internet-Draft SIP Publication Requirements November 2001
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Why SIP? . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Why not SIP? . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1 Publication Data Requirements . . . . . . . . . . . . . . . . 5
5.2 Authentication and Authorization Requirements . . . . . . . . 5
5.3 Data Handling Requirements . . . . . . . . . . . . . . . . . . 5
5.4 Privacy Requirements . . . . . . . . . . . . . . . . . . . . . 6
5.5 Error Cases . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9
Donovan Expires May 22, 2002 [Page 2]
Internet-Draft SIP Publication Requirements November 2001
1. Introduction
This document defines the requirements for a proposed extension to
the Session Initiation Protocol [1]. This extension would provide
for a general-purpose mechanism for uploading service related data.
For instance, there is currently the need to upload or publish CPL to
SIP Proxies and presence documents to SIP Presence Servers.
Note that CPL is currently uploaded using the SIP REGISTER request.
It is thought that the REGISTER request, which was designed
specifically for publishing Contacts which are in turn used to
control routing of SIP requests, is not sufficiently general purpose
to handle the uploading of generic service related data. For
instance, there is currently no clean mechanism for reporting on the
failure to upload CPL while the registration of Contacts is
successful.
While this draft proposes that the solution to the requirements
outlined in this document should be based on SIP, it is recognized
that there is currently no consensus that SIP is the correct protocol
to be used for the generic publishing of service related data. If
there is consensus that something other than SIP should be used, then
the requirements in this document still apply to whatever solution is
selected.
2. Motivation
There are various situations where SIP clients need the ability to
supply service related information to SIP servers in order for the
services supplied by the SIP servers to operate properly.
The following are two well understood examples:
o Call Processing Language - Clients load Call Processing Language
(CPL) scripts to SIP Proxies. The SIP Proxies then use the CPL
scripts to control the routing of subsequent SIP requests.
o Presence Documents - Clients load Presence Documents to Presence
Servers. The Presence Servers then use the presence documents
when notifying watchers of the clients presence state.
It is felt that there is the need for a general-purpose mechanism for
uploading of SIP service information. Furthermore, it is felt that
the SIP REGISTER request is NOT the appropriate mechanism for handing
this loading of SIP service information. The semantics of the
REGISTER request are tightly coupled with the handling of the
contacts contained in the REGISTER request. There is not a clean way
to define handling of other service data without also effecting the
Donovan Expires May 22, 2002 [Page 3]
Internet-Draft SIP Publication Requirements November 2001
handling of REGISTERed contacts.
3. Why SIP?
It is valid to ask why the loading of service data should be defined
using the SIP protocol.
The primary reason for basing it on SIP is that both of the user's of
the information, the SIP client that creates it and the SIP server
that consumes it, already have SIP implementations running on them.
In addition, it might not be easy to put another protocol engine on
these devices, especially SIP phones.
The other possible reason to base it on SIP is that there is not
necessarily a clear mapping between the address of a SIP server that
would handle the publication of a CPL script and the address of
another protocol's server. As such, there will be additional
configuration complexity in the client associated with the ability to
send the message to a different server.
It can also be argued that SIP already supports a publication
mechanism in the REGISTER request. The only problem is that the
REGISTER request is not a general-purpose publication mechanism. So
all that is being proposed is a generalization of something that is
already in SIP (although this draft does NOT propose deprecating the
use of REGISTER for the original purpose of associating contacts with
a SIP url).
4. Why not SIP?
It is fairly easy to model the publication of SIP service information
as an HTTP PUT operation.
In fact, the draft "Guidelines for Authors of SIP Extensions" [2]
explicitly says:
"SIP is not a transfer protocol. It is not meant to send large
amounts of data unrelated to SIPs operation. It is not meant as a
replacement for HTTP..."
However, the same draft also says that REGISTER is an exception to
this rule, and this draft proposes a generalization of the REGISTER
function. In addition, the data being published is clearly related
to SIPs operation. This draft does NOT propose that this mechanism
apply to any and all uploads of data.
Donovan Expires May 22, 2002 [Page 4]
Internet-Draft SIP Publication Requirements November 2001
5. Requirements
This section contains the requirements for the proposed SIP
extension.
5.1 Publication Data Requirements
The extension MUST support the ability to carry arbitrary message
bodies, here-after called publication data.
The extension MUST support the ability to associate publication data
contained in a message body with a service.
For instance, presence and cpl are services.
The extension MUST support the ability to identify the
format/encoding of the publication data.
5.2 Authentication and Authorization Requirements
The extension MUST support the ability to identify the user to which
the publication data applies.
The extension MUST support the ability to authenticate the source of
the publication requests.
The extension MUST support the ability to determine the authorization
of the source of the publication request to publish data for the user
effected by the publication data.
The extension MUST support the ability for the user determined to be
the source of the publication request to be different than the user
determined to be the target of the publication request.
Another way of saying this it that the third party registration
concept currently supported for registrations must also be supported
for publications.
5.3 Data Handling Requirements
The extension MUST support the ability to treat the published data as
hard state.
CPL is an example of data that would be treated as hard state. As
such, it should not have an expiration period applied to it and it is
kept in place until it is replaced or explicitly removed.
The extension MUST support the ability for the server to indicate
Donovan Expires May 22, 2002 [Page 5]
Internet-Draft SIP Publication Requirements November 2001
that a request to store published data as hard state will not be
honored.
The server might not want to be told to store something forever. It
is envisioned that this could be achieved by including an expires
timer in the response, much has would be done in the soft state case
discussed in the next requirement.
The extension MUST support the ability to treat the published data
as soft state. As such, the extension MUST support the ability to
associate an expiration time with a message body.
There are times that a presence document could be considered to be
soft state, with the explicit requirement that there is an explicit
period of time that the presence document is valid. If this is the
case then the presentity publishing the data would be required to
refresh the publication in order to keep it in effect.
The extension MUST support the ability to query or retrieve
publication data associated with a service.
The extension MUST support the ability to define a desired action to
be taken on the published data. Example actions are replace, remove,
append and merge. Each service that uses the publication capability
must define the actions that apply to that service.
The extension MUST allow for the list of actions to be extensible.
Note: It is not clear that the action to be taken should be part of
the extension or should be a part of the message body containing the
publication data. Making it a part of the message body makes it a
service/application specific definition, which might make for a
cleaner separation from the publication extension and the service to
which the publication is targeted.
5.4 Privacy Requirements
The extension MUST support the ability to encrypt the publication
data.
The extension MUST support the ability for the response to
unauthorized requests to hide the fact that the source user is not
authorized to publish for the target user.
It is anticipated that there will be cases where returning a response
indicating that the source user is not authorized will supply
information about either the server or the target user of the server
that could enable attacks on one or the other. As such, it is
Donovan Expires May 22, 2002 [Page 6]
Internet-Draft SIP Publication Requirements November 2001
envisioned that a generic "accepted" response, that can be
differentiated from "successful" and "unauthorized", would be useful
in this case
5.5 Error Cases
The extension MUST support the ability to reject the publication
request when the contents of the publication data are malformed or
erroneous.
The extension MUST support the ability to reject the publication
request because the source user is not authorized to access the
particular service. This rejection should indicate the services that
the server supports.
The extension MUST support the ability to reject the publication
request because the source is not allowed to publish data for the
target user.
The extension MUST support the ability to reject the publication
request because the target user is not known to the server.
The extension MUST support the ability to reject the publication
because the type of the indicated service is not supported. This
rejection should indicate the services that the server supports.
The extension MUST support the ability to reject the publication
because the type of the data is not supported. This rejection
should indicate the services for which publication is allowed.
The extension MUST support the ability to reject the publication
because the operation (replace, remove, append and merge) is not
permitted for the particular service.
6. Security Considerations
The security considerations are addressed in the Authentication,
Authorization and Privacy requirements.
References
[1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"The Session Initiation Protocol", RFC 2543, March 1999.
[2] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of SIP
Extensions", RFC Guidelines, March 2001.
Donovan Expires May 22, 2002 [Page 7]
Internet-Draft SIP Publication Requirements November 2001
Author's Address
Steven R. Donovan
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, TX 75024
US
EMail: sdonovan@dynamicsoft.com
Donovan Expires May 22, 2002 [Page 8]
Internet-Draft SIP Publication Requirements November 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). 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.
Donovan Expires May 22, 2002 [Page 9]
