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

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 7 Mar 2003 03:16:19 -0500

A few more incidental comments below, but unsurprisingly, I don't think
we're going to come to any quick agreement about this. As I said before, if
you really strongly about the matter, I would recommend counterproposing.

Jon Peterson
NeuStar, Inc.

> > > -----Original Message-----
> > > From: Neil Deason [mailto:[email-masked]]
> 
> [snip]
> 
> > What makes PIDF, say, so different 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?
> 

Again, I disagree with your assertion that SIP has a single purpose rather
than two. Frankly, I don't think that any argument to the contrary is
tenable. There is simply too much text to this effect in the base
specification. I don't think the difference between the use of SIP for
carrying registrations and the use of SIP for carrying presence information
is radically different. I note you haven't been picking on the NOTIFY method
- do you think it would be better to replace NOTIFY for presence with a
PA->UAS HTTP connection set up with an INVITE?

The PUBLISH method has been developed specifically for presence publication.
We have not shut the door on other usages, but I do share your concern that
PUBLISH could be applied inappropriately. Before the work is complete, there
will need to be some defense against that at a process level.

> <snip>
> > 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?
> 
> Not really because the problem I have is the extension to SIP.

I thought the problem you had was that HTTP is better, somehow. If your only
problem is that we are extending SIP unnnecessarily, that's a somewhat
lesser concern (but I am not insensitive to SIP bloat). If there were some
properties we would get from HTTP that would make this all work better, that
would be one thing. But so far I'm not sure you've volunteered any, which
brings us back to chocolate and vanilla.

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

Well, it doesn't prove that connectivity exists, it assumes it - and no
doubt in some instances that assumption will be misguided. 

In any event, I find it somewhat unlikely that the content of presence
publications will be large. Each individual PUA probably has knowledge of
only a relatively small chunk of presence information. Notifications that
contain the composed presence of many PUAs have a potential to become quite
large indeed, but I doubt that PUBLISHes will. So maybe content indirection
will not be so widely used here.

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

I think the DHCP example is intended to motivate this, yes. I don't feel
strongly either way about that use case - I don't think it's totally
implausible, but nor do I feel it's monumentally important. But I think it
provides one instance in which per-transaction routing of publications is
significant. Maybe there are others. Co-authors, any thoughts?

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

I guess the text about forking ended up in simple-publish-00, not in
simple-publish-reqs-00. There's a certain amount of 'why use a new SIP
method' material in simple-publish-00. Probably this forking text, with a
commensurate requirement, should be moved back to simple-publish-reqs-00. Or
maybe, as you previously suggested, all of the HTTP vs. SIP text should be
moved forward to simple-publish-00.

Incidentally, the implications of forking for the sessions-of-HTTP model are
worse, I think, than any implications for the PUBLISH method.

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

The problems with REGISTER are not intrinsic - the problem is not that SIP
supports a registration capability at all. There are a set of specific
deficiencies (like the overloading of Contact headers) in REGISTER that
merit correction, and if backwards compatibility weren't a concern they
could be rectified fairly easily. There is no doubt in my mind that SIP
needs to have access to a registration capability.

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

It would be hard to shake me from the opinion that sessions-of-HTTP is
misguided, at least significantly moreso than adding a SIP method for
publication.

But I think we understand one another, here. Maybe we can talk more about
this in SF, in a higher-bandwidth medium.

> Cheers,
> Neil.
> <snip>
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 10 Mar 2003 00:50:31 -0500

I just want to chime in here in support of Jon on this particular topic. 
I think that PUBLISH is as intrinsic to the sip events story as SUB/NOT 
itself, and that if you think SIP is a poor choice for PUBLISH, you must 
conclude that it is also a poor choice for SIP events, or at least, that 
we should throw away rfc3265 in favor of an INVITE-based mechanism.

I, for one, am not interested in doing that. I also believe that a 
"mixed" model, whereby publication is handled using an INVITE-initiated 
session, but notification is with SUB/NOT, achieves nothing but awkward 
implementations.

As for PUBLISH vs. SEACAP, these are very different things. SEACAP is 
about database operations. PUBLISH is about a blind push of data into a 
huge policy system, which is not at all like a database. Publications 
from third parties are critical (we have several examples of that so far 
- publication of presence on a web site, AOL warning capabilities, 
etc.), whereas that makes no sense to me in a SEACAP type of system. 
This results in differing requirements for routing and in basic semantics.

So, as long as the PUBLISH draft is clear in terms of scope, and 
explains the above issues well, I am not worried about feature creep 
into PUBLISH.

Thanks,
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