Subject: RE: [Simple] SIP and HTTP for presence publication

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 4 Mar 2003 16:01:45 -0500

Well, I'm really loath to re-open this discussion... we've already moved
pretty far down one path, and it isn't clear that any other has genuine
advantages over our current direction.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Neil Deason [mailto:[email-masked]]
> Sent: Monday, March 03, 2003 9:37 AM
> To: [email-masked]
> Subject: [Simple] SIP and HTTP for presence publication
> 
> 
> draft-ietf-simple-publish-reqs-00 discusses the use of either HTTP or
> SIP for presence state publication as if they have to be mutually
> exclusive.
> 
> As the draft points out HTTP provides a much better data transfer
> mechanism than SIP. SIP has application layer routing 
> richness that HTTP
> does not. So why not use SIP to initiate/modify/terminate a presence
> state data transfer session that uses HTTP?
> 
> Cheers,
> Neil.
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Neil Deason" <[email-masked]>
Date: Tue, 4 Mar 2003 14:12:00 -0800

Hi Jon.

> Well, I'm really loath to re-open this discussion... we've

Can you provide a pointer to the discussion of SIP *and* HTTP for
presence publication, not SIP *or* HTTP. That is all that is discussed
in draft-ietf-simple-publish-reqs-00, maybe I missed something on the
list?

> pretty far down one path, and it isn't clear that any other
> has genuine advantages over our current direction.

Well I believe I can give advantages of SIP *and* HTTP. The reason that
the requirements draft gives for using SIP alone is that it provides a
solution that can leverage the power of SIP's application layer routing.
Well so does using an INVITE to set up a HTTP session. Furthermore,
using HTTP is the right thing for the job of data transfer, the draft
itself acknowledges this. If you then accept the premise that the HTTP
session could transport SOAP you are entering a realm of possibilities
more sophisticated than a new SIP method offers.

So combining HTTP and SIP could offer the best of both worlds and is in
keeping with the IETF principal of designing modular protocols that work
together. Contrast that with bad thing of adding methods to SIP that
deviate from the protocols stated objective of initiating, modifying and
terminating sessions. There are already well known examples of this in
place, but we do not need to use that as precedent for solving every
problem we come across in the communications space directly within SIP.
The idea of adding a "POST" method to SIP is just as misguided as trying
to add SIP-style routing features for HTTP proxies.

Cheers,
Neil.