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

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 5 Mar 2003 17:35:48 -0500

Some notes inline.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Neil Deason [mailto:[email-masked]]
> Sent: Wednesday, March 05, 2003 10:15 AM
> To: Peterson, Jon; [email-masked]
> Subject: RE: [Simple] SIP and HTTP for presence publication
> 
> 
[snip]
> 
> 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
> utilize 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.
> 

I'm afraid I disagree with much of this. SIP is widely acknowledged to be
reasonable protocol for transporting SDP. What makes PIDF, say, so different
from SDP? There's no question in my mind that SIP is not a media transfer
protocol, and that SIP should not be used to carry real-time communications
data itself, sure. But I don't see why this extends to PIDF. Why REGISTER is
not also like POST is obscure to me; I think all of this clearly falls
within existing SIP boundaries, and is not symptomatic of unnecessary bloat.

If your concern is that PIDF would, say, be radically larger than SDP, then
look to requirement 9, which is essentially a requirement for content
indirection. In fact, content indirection may give you many of the virtues
of combining SIP and HTTP without some of the vices I see in the
sessions-of-HTTP approach. Would that be sufficient for you?

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

Right, the difference is that you send an INVITE to establish a persistent
relationship over which successive publications of presence information will
be sent. PUBLISH, on the other hand, would be routed on a per-transaction
basis. In order for the INVITE-based approach to be routed on a
per-publication basis, you would be setting up and terminating a session
every time you published, which seems very cumbersome to me from a messaging
perspective.

Consider as well that some have expressed a desire for PUBLISH to fork. The
implications for that to the session-based model should be obvious. 

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

Possibly. It would be nice for the purposes of content indirection.

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

Presence publication is not about enabling the discovery mechanism? I find
that a bit difficult to accept. Presence is an incremental step forward in
the management of discovery above REGISTER, and presence publication is in
many ways a generalization of registration. You use presence information to
decide which communications interfaces associated with a user you will
attempt to contact, based on their disposition.

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

The purposes of supplying that text about SIP v. HTTP was to preempt the
religious arguments about this that previously prevented us from making
progress. In the publication design team, we ultimately found that there
were too few criteria for a strong case to be made for either option.
Eventually, this becomes a matter of choosing vanilla or chocolate.
Hopefully content indirection can blend the two flavors sufficiently.

> Cheers,
> Neil.
> 
> > 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 16:27:14 -0800

inline too...

> From: Peterson, Jon [mailto:[email-masked]]
>
> Some notes inline.
>

[snip]

> from SDP?

The difference is that SDP is directly tied to the raison
d'etre of SIP - initiate, modify, terminate sessions.
Transport of presence data to a compositor is not. It is
a problem that can be addressed by SIP, but appears
unnecessary to do so. To come at this another way - if I
can use PUBLISH for PIDF can I also use it to transport
SEACAP?

<snip>
> sessions-of-HTTP approach. Would that be sufficient for you?

Not really because the problem I have is the extension to SIP.
This just proves the existence of HTTP connectivity between
publisher and connectivity - so use it rather than add
include HTTP POST semantics to SIP. This is how modular
IETF protocols are supposed to work together.

> every time you published, which seems very cumbersome to me

We agree on the difference here - but what is your use case
for requiring this level of per publication application
layer routing. I take it you accept the DHCP example in the
reqs draft does not provide it. I don't see the level of
persistence of publication sessions to a compositor as
being so short lived that it is not comparable to say
instant messaging sessions. I would more typically
expect the compositor to be less dynamic than the
publishers. In which case an INVITE for the publisher to set up a
publication session to the compositor terminated with
a BYE when it is going away is a good fit.

> implications for that to the session-based model should be obvious.

Actually the wider implications of forking PUBLISH might be a
reason you do not want to use a SIP method. Need to see
a motivating requirement clarified to appraise this point.
Do you have text in mind for a reqs-01 draft for this?

<snip>
> attempt to contact, based on their disposition.

Differentiate between presence publication and PUBLISH
as the mechanism. As has been noted by others before many
people would have REGISTER on the list of stuff that would
be done differently given the time over. This doesn't make
a good precedent for PUBLISH.

> Hopefully content indirection can blend the two flavors sufficiently.

Well call me greedy but I will have each in its own right ;)
I am sure you see what I am saying by now - you don't
have to choose between them and then extend one to compenstate
for missing functionality provided by the other. Use both
without adding anything more to either. Other than the possible
open issue re: frequency of presence publication vs. overhead of
managing publication within a session format, I have yet to see
a reason to do otherwise.

Cheers,
Neil.

<snip>