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

From: "Brian Stucker" <[email-masked]>
Date: Fri, 16 Nov 2001 13:55:05 -0600

That's a good point you have with the 405/OPTIONS argument. I had thought
about putting in separate methods, but figured the header would be
easier to handle, given that it can be extended to include subactions for
a given service or services. For instance:

put.append
get.diff

I couldn't account for this with different methods, so I figured I'd use
a header instead. Maybe if we go the route of having the three basic
actions as methods, and then add some to the grammar for the service
header both can be accounted for more easily.

Is that why you refer to the HTTP/SIP URL translation?

Thanks,

Brian Stucker

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Thursday, November 15, 2001 10:12 PM
To: Stucker, Brian [NGB:B635:EXCH]
Cc: [email-masked]
Subject: Re: [Sipping] New I-D on Generic Service Data Publication

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:
> 
> 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
>

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Fri, 16 Nov 2001 15:04:29 -0500

> a given service or services. For instance:

Subactions, if truly needed, can still be made headers, if they only
modify the basic method. However, I have to admit that I'm somewhat
worried that we are re-inventing not just HTTP, but WebDAV while we're
at it. I think this upload mechanism is useful for atomic updates, not
to edit object in detail. Thus, I'd stay away from appending and diff's.

> header both can be accounted for more easily.

Something like that, yes. Might be best to get the simple, basic stuff
agreed-upon first. This has real potential for infinite complexity.

> Is that why you refer to the HTTP/SIP URL translation?

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. This was meant as an addition to your motivational
section, nothing more.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Nov 2001 15:51:38 -0500

"Henning G. Schulzrinne" wrote:
> 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.

	Paul