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

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 4 Mar 2003 18:12:14 -0500

It's not my place to stifle discussion on this mailing list, but I fear this
is a very counterproductive line of inquiry.

I am afraid that your note below provides no substantial evidence of
advantages to your model, it merely hints that HTTP (and potentially SOAP)
are superior to SIP as data tranfer protocol. So what properties would we
derive from the use of these other protocols that we cannot garner from the
PUBLISH method model, exactly? 'It uses SOAP' is not innately persuasive. 

A solution based on integrating HTTP sessions into SIP for publication does
have limitations, in my opinion. For one thing, SIP PUBLISH requests would
be routed on a per-transaction basis, which creates more dynamism than we
would realize from the establishment of a persistent pair of HTTP endpoints
through the session initiation model - in this second case the
application-layer routing benefits only the session initiation messages, not
the publications themselves. The draft does speak in some detail to why this
dynamism is desirable. One material need for application-layer routing of
publications is the standard NAT traversal issue - sending publications
through the SIP proxy hierarchy makes this manageable, but there is no
guarantee that any given HTTP client and server will be able to communicate
with one another directly. This is especially troublesome, as the draft
notes, when a PA is operated on an end-user device.

I am moreover not inclined to think that presence information is 'session'
data at all. I believe that the sorts of sessions that are established by
SIP are real-time communications sessions, peer-to-peer - not sessions with
intermediaries (i.e. compositors) for the purposes of relaying something
like presence information. I believe this understanding of 'sessions' is
amply substantiated by RFC3261; I would refer you to the definition of
'session' in Section 6.

And also, I do not think that publication deviates from SIP's mission in the
slightest. The Introduction of RFC3261 identifies two purposes for the SIP
protocol - one being the session management function you describe below, the
other being the discovery function (which in the context of RFC3261 refers
to REGISTER and associated behavior). PUBLISH jibes well with that second
aspect of SIP.

Finally, I would note that PUBLISH has already become a WG item of SIMPLE.
These are not the first versions of this draft to be produced, and we chairs
believed that there was rough consensus to pursue this direction. You are of
course welcome to submit your own counterproposal, and it will be given due
attention in the WG, but this will not halt the progress of the PUBLISH
draft.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Neil Deason [mailto:[email-masked]]
> Sent: Tuesday, March 04, 2003 2:12 PM
> To: Peterson, Jon; [email-masked]
> Subject: RE: [Simple] SIP and HTTP for presence publication
> 
> 
> Hi Jon.
> 
> > Well, I'm really loath to re-open this discussion... we've
> > already moved
> 
> 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.
> 
> 
> > 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: Wed, 5 Mar 2003 10:14:38 -0800

> From: Peterson, Jon [mailto:[email-masked]]
>
<snip>

> PUBLISH method model, exactly? 'It uses SOAP' is not innately

Potential for SOAP usage is not my major point - merely a note of an
observation made in the reqs draft itself. What I am saying is that if
SIP application routing is required in presence data publication then
utilise that feature without adding complexity and baggage to SIP
itself. SIP is not a data transfer protocol. I believe that is widely
accepted. There are good technical reasons for this from the fact that
UDP can be used as transport providing concerns over congestion control
and message fragmentation. There are also fundamental issues here:
Protocols that do not have a bounded scope become overly complex and
tend to fail. Hence the IETF approach to have modular protocols that can
work together. SIP is not meant as replacement for HTTP, so don't add a
POST method to SIP if you can just use POST in the first place. It is
not that you cannot do this within SIP through PUBLISH, but that you
should not.

> dynamism is desirable.

If you mean Section 1.2.2 I don't believe it makes case for such
dynamism. There is nothing there that shows the overhead of managing
mobility a the session level through SIP would be too great and that you
need to use a series of discrete SIP request/response transactions
instead. How much do you expect the compositors to move around? The
example given is a compositor running on a device using dynamic IP
addresses obtained from DHCP. A PUBLISH gets routed according to a
reREGISTERed address when the IP address changes, just as an INVITE
would. This is the inherent mobility support for SIP. If you don't
believe in that it is time for RTP/INFO for every SIP phone using DHCP
;) What section 1.2.2 actually makes a case for is the discovery
capability of SIP. That is already there and you do not need to reinvent
parts of HTTP within SIP to use it.

> One material need for
> application-layer routing of

I think it a very reasonable assumption that the end devices will
support HTTP clients that can contact servers, even through FWs/NAT.

> amply substantiated by RFC3261; I would refer you to the definition of

Sure it takes the definition of session from SDP which refers to data
streams between senders and receivers. If you look at RFC 2327 you will
see that the supported media types defined there for sessions are
"audio", "video", "application", "data" and "control". This usage being
a valid example of a data session. But I think we digress.

> to REGISTER and associated behavior). PUBLISH jibes well with

Disagree - REGISTER is about enabling the discovery mechanism. PUBLISH
it is about data transfer leveraging that discovery mechanism. You can
still leverage the discovery part for data transfer without needing to
add yet more complexity to SIP.

> attention in the WG, but this will not halt the progress of

What I would actually like to see is a cleaner requirements draft. The
current iteration has hangovers from being split out from the PUBLISH
draft. A requirements draft should not have a conclusion as to what the
solution is. Drafts proposing solutions should state how they meet
requirements. It should not be a requirement for a solution to extend
define a new SIP method. The actual underlying requirement seems to be
for a compositor discovery mechanism. The protocol analysis of SIP and
HTTP in the requirements is incomplete as the option of combining SIP
and HTTP is not discussed. Finally imho the requirements draft fails to
justify the conclusion that adding SIP style application logic to HTTP
is wrong, but adding POST like data transfer to SIP is right.

Cheers,
Neil.