Subject: [Sipping] New I-D on Generic Service Data Publication

From: "Brian Stucker" <[email-masked]>
Date: Wed, 14 Nov 2001 14:55:35 -0600

Hello all,

I wanted to give everyone a head's up that I've just submitted a new I-D
to the IESG archives regarding a way of publishing generic service data
information using something other than the REGISTER method (based off
the requirements that Steve Donovan had eariler sent in).

Knowing that the IESG editor may be a bit bogged with submissions ahead 
of IETF-52, you can pick it up at:

http://www.obsidian97.com/draft-stucker-sipping-publish-00.txt

I've included the abstract below. This draft hopes to give a more 
concrete example of a method of publishing generic SIP service data in 
order to help resolve the dependencies on the current (identified as
not working well) REGISTER method. It is based off the requirements
gathered by Steven Donovan in his draft: draft-donovan-publish-
requirements-00.txt.

Regards,

Brian Stucker
Nortel Networks

---
Abstract:

This document describes an extension to the Session Initiation Protocol
(SIP). 
The purpose of this extension is to create a means for publishing and
retrieving 
information regarding services in the network by using SIP. The methods
described 
in this document allow a framework by which arbitrary service data can be
transported 
into the network for use by services running in the network. It is not
intended to 
be a general-purpose mechanism for transport of arbitrary data as there are
better 
suited mechanisms for this purpose (ftp, etc.), but is intended to be a
simple, 
light-weight, mechanism that employs SIP in order to support SIP-related
services. 
It is envisioned that each service that employs this method may extend and
provide 
more detail as to how that service interacts with the mechanisms put forth
in this 
draft.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 15 Nov 2001 23:11:57 -0500

Thanks for getting this written up. My personal preference would be one
method for each 'action', as this makes handling in various places much
easier. For example, it is then easy to indicate that a particular UA
doesn't support a particular action (i.e., method) via 405, rather than
inventing a new status code. OPTIONS can then be used to discover
capabilities (via Allow), etc.

This also greatly simplifies logging and authorization, which is
typically on a per-method basis. (One may, for example, only allow GET,
not PUT or DELETE.)

There is no fee for additional method names, despite the claims of the
INFO crowd :-)

Section 4.9 of the sip-guidelines document speaks to this and is
applicable here. A GET is a very different operation from a PUT.

The main reason for having this type of mechanism is that it avoids
having to do addressing translation to reach the same destination (e.g.,
from SIP URL to HTTP URL). This, I believe, should be made clearer.

> Brian Stucker wrote:

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 16 Nov 2001 12:03:34 -0500 (EST)

> the requirements that Steve Donovan had eariler sent in).

Thanks for doing this.  This is definitely a lot cleaner than the earlier
REGISTER thing I wrote up, which was always too complicated when it came to
disentangling the various conditions and clauses.

I agree with Henning -- there's no tax on extra method names.  I'm inclined
to go all the way and adopt HTTP's GET/PUT/DELETE methods here.

Some further points:

I really think you need the If-Unmodified-Since logic I had in my
REGISTER-payload draft.  If you've used GET to retrieve a service script,
and then edited it locally, you want a way to make sure that no one else has
modified the script when you PUT or DELETE it.  See RFC 2616 for
If-Unmodified-Since in HTTP, and
<http://www.cs.columbia.edu/~lennox/draft-lennox-sip-reg-payload-01.txt> for
my old REGISTER payload draft.

This will also probably mean you need the Content-Disposition header with a
modification-date field, since Date means "current time" in SIP, not
"timestamp of resource" as it does in HTTP.

Should there be a defined way of querying which services are available,
other than sending a PUT with a service tag you expect to be invalid?

You mention that a PUT of a zero-length file shouldn't be used as a
substitute for DELETE.  This is true, but that doesn't mean that a client
MUST NOT send a zero-length PUT.  A zero-length content may well be valid
for some services, presumably meaning "execute the service with its default
behavior" or some such.

If this goes forward, should some one-page drafts be written for services
such as CPL, SIP CGI, etc?

-- 
Jonathan Lennox
[email-masked]