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

From: "Brian Stucker" <[email-masked]>
Date: Fri, 16 Nov 2001 09:10:08 -0600

Just to add some confusion.. This draft went into the archives as
 
draft-stucker-sip-publish-00.txt
 
The title will be changed to sipping after IETF-52.
 
Regards,
 
Brian

-----Original Message-----
From: Stucker, Brian [NGB:B635:EXCH] 
Sent: Wednesday, November 14, 2001 2:56 PM
To: [email-masked]
Subject: [Sipping] New I-D on Generic Service Data Publication

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
<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: "Sean Olson (EUS)" <[email-masked]>
Date: Fri, 16 Nov 2001 13:49:56 -0600

So basically, the idea is take HTTP and replace
the protocol field with "SIP/1.0". Could someone
please explain the big wins here in using SIP instead
of HTTP? I see the potential for using SIP's routing
infrastructure, but that doesn't seem to be worth
the effort in duplicating HTTP. (I'm now putting on
my asbestos suit -- flame away)

/sean

>On Wednesday, November 14 2001, "Brian Stucker" wrote to 
>"[email-masked]" saying:
>
>> Hello all,
>> 
>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-payloa
d-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]

_______________________________________________
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 Rosenberg <[email-masked]>
Date: Mon, 19 Nov 2001 00:55:31 -0500

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, November 16, 2001 3:52 PM
> To: Henning G. Schulzrinne
> Cc: Brian Stucker; [email-masked]
> Subject: Re: [Sipping] New I-D on Generic Service Data Publication
> 
> 
> "Henning G. Schulzrinne" wrote:
> > 
> > No, that's a different problem. One of the motivations for 
> doing all of
> > this is that, without this, we'd have to find a way to say 
> "use HTTP URL
> > X to update information for SIP URL Y". Once you take into 
> account the
> > various translation mechanisms in SIP, this can become non-trivial
> > pretty quickly. 
> 
> How about pursuing that direction for a bit...
> 
> Suppose you could send an OPTIONS, and get back a result that includes
> http CONTACT headers. These could be qualified some way (perhaps using
> callerprefs) so you could decide which CONTACT to use for a particular
> purpose. Or headers in the OPTIONS could be used to select 
> which CONTACT
> headers are returned.
> 
> Once the appropriate contact is obtained, then go ahead and 
> use http (or
> ftp, or whatever the url says to use) to get or update the data.

Or, even simpler, put an http header into the HTTP request that contains the
sip url of the user whose data you are trying to update:

POST http://foo.com/database HTTP/1.1
Subscriber: sip:[email-masked]

That solves the problem completely. SOAP/HTTP, with the URL of the
subscriber in the body of the soap request, would also seem to work. 

I have this worrying feeling in the pit of my stomache that IESG would take
a look at all of this and say "ok, so the sip group is now using sip as a
way to do simple database manipulations, just because they need something
that addresses a sip URL? I don't think so". Indeed, what we are really
after is a subscriber oriented way to modify/read a database, and certainly
the world is full of lots of database protocols. I still don't think we have
a firm enough grasp on why the requirements really dictate a sip solution;
Henning has provided one reason (subscriber identified with a sip URL), but
it seems a weak one given its easily resolved in several ways....

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com