Subject: RE: [Simple] PUBLISH: a dialog?

From: "Brian Stucker" <[email-masked]>
Date: Wed, 5 Feb 2003 15:23:24 -0600

More comments from left field...

I'd argue that we keep the idea of a token (ala Stream) that identifies a
particular source, 
and not try to hassle with the overhead of a dialog. Here's the scenario
that I'm looking
at:

We have several PUAs all publishing their presence information into a
compositor, but the
compositor is using this information to provide both a per-PUA indication of
status, and
an overall presence status. If this is the case then a policy may be used
based on the
per-PUA presence information to come up with the overall view of that user's
presence.

The trouble begins when we bring reality into the picture. Let's say one of
the PUA clients
crashes, or loses network connectivity for long periods of time (which I'm
sure we won't
run into often as all software is highly reliable, and all networks never
experience
intermittant outages to a particular node on the network), so here's the
rub: how do we
know where to restore their presence information back to?

If we have a simple, globally-unique (or as unique as we can make it)
identifier, that 
identifies a UNIQUE INSTANCE of a particular PUA, and not just a particular
run-time instance
(ie. it's set once, and never reset ever again, like a serial number), we
can correctly
continue to compose an overall presence document even though the client may
crash, the
network may crap out, or some other unforseen tragedy befalls our poor PUA.

Although I agree with the idea of having something dialog-like to preserve
ordering, etc., I
think we've already shown that it can be handled in other ways. Similiarly,
I would rather
not solve the need to have a way to identify a particular PUA instance by
coupling it with the
transport mechanism it uses to get that information to us. 

If we say that they simply need to initiate a dialog, we can't necessarily
say that the PUA
will be able to recover from the dialogue being dropped without making
demands that the callid
and tags being used must be used from now on, forever, and ever, amen, which
is pretty much 
what we get around with having a Stream header. Besides, what if we're
getting the information
forwarded to us at the compositor through some sort of BBUA (which, they
will) and they're
not using a deterministic algorithm that always maps an input callid and tag
to the same output
tag and call id across dialogs?

Thoughts?

Brian

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Wednesday, February 05, 2003 5:09 AM
To: Simpletons (E-mail)
Subject: [Simple] PUBLISH: a dialog?

The SIMPLE minutes reflect a consensus in the room at IETF 55 that the
PUBLISH method should initiate a dialog. In preparation for a revision of
the PUBLISH document, this matter merits some further discussion.

Some identifiers associated with publication persist beyond the scope of a
particular SIP transaction. For example, it is useful for a compositor to
know that a set of PUBLISH requests all came from the same device, and to
know the order in which they were sent. It may also be desirable to let one
device overwrite presence information that was published by a different
device, which entails some shared identifiers outside the context of a
dialog.

draft-olson-simple-publish-01 contains a Stream header that provides a
longer-term identifier than the ordinary instance identification methods of
a dialog (the tags in the To and From headers and the Call-ID). It has also
been argued that the sequencing of publications need not rely on something
like a CSeq header, since the Date header or something internal to the
presence information body (for example, the <timestamp> element in PIDF
bodies) could provide temporal ordering information. For these reasons,
draft-olson-simple-publish-01 states that PUBLISH does not establish a
dialog.

However, it isn't clear today if it is necessary to have a longer-term
identifier in the headers of the PUBLISH method, considering that the
presence information itself may contain its own identifiers (like the tuple
ID in PIDF) that could be reused as needed (such as the case in which one
device overwrites presence published by another). When we were first working
on PUBLISH, we were influenced by a use case in which a presence compositor
combined presence documents without actually reading their contents (perhaps
because the presence information is encrypted, or the documents used a
format that the compositor didn't understand), which would argue that the
longer-term identifier used by the compositor should not be placed in the
presence information itself. Ultimately, this use case might not be that
significant, though; a compositor that cannot understand presence
information might not be able to do its job for unrelated reasons. If at all
possible, we should avoid authoring a new header that establishes a
pseudo-dialog - REGISTER has taught us that creating a one-off from the
dialog model is ill advised.

So, we'd like some opinions on this. Should PUBLISH initiate a dialog, and
use traditional dialog identifiers instead of the existing Stream header? 

Jon Peterson
NeuStar, Inc.
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 6 Feb 2003 00:25:35 -0600

Although I'm agreeing with you in principle, why do we want to tie ourselves
to the callid/cseq?

We have no idea what perils may befall those fields as they are not
guaranteed to be opaque as they traverse a network with things like BBUAs in
them.

Why not have the Stream field left in so we know for sure nobody's mucking
with our unique identifier?

-----Original Message-----
From: Sean Olson [mailto:[email-masked]]
Sent: Wednesday, February 05, 2003 11:46 PM
To: 'Jonathan Rosenberg'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Simple] PUBLISH: a dialog?

Dialog state for PUBLISH will be a mistake. The more I think about it,
the clearer it
becomes to me that PUBLISH should be a fixed-up REGISTER. The hardest
problem is figuring
out when and how to tear down dialog state for PUBLISH particularly if
it is the compositor
that wants to tear down the dialog. I am recommending that we use
Call-ID/CSeq in PUBLISH in
an analogous way to the way it is used in REGISTER itself.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Rosenberg
Sent: Wednesday, February 05, 2003 8:25 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Simple] PUBLISH: a dialog?

I am still on the fence on this issue. Some responses and thoughts
inline:

[email-masked] wrote:
 > Hi All,
 >
 > I am supporting the dialog initiating PUBLISH method, since that  >
seems to be a step forward to meet some of the requirements posted to  >
SIMPLE list recently:  >
http://mailman.dynamicsoft.com/pipermail/simple/2002-December/002103.htm
l
 >  First, I believe the dialog concept would be preferable to provide
> "feedback" to the PUA about the actual result of the publishing  >
transaction, whether the published XML was successfully composed to  >
the presence document or not.

I agree with that, but I dont see why you need a dialog. I had in mind 
that the response to PUBLISH is a 200 OK if the published data was 
accepted, and the response contains the "raw" presence data from other 
publishers. This raw data could be used by a PUA to, for example, 
overwrite the presence data from another PUA.

 > Secondly, in a multi-PUA scenario, a
 > dialog would also be useful to provide feedback about other PUAs'  >
activities, e.g. the publishing PUA could learn the presence  >
information (including the tuple ids) published by other PUAs.

I am not as sure there is a need to know when the published data 
changes, as to be able to fetch it. Considering our one and only use 
case (going home and then setting the presence from my PC at work to 
unavailable, since i left it running), the home device doesn't need to 
know about changes in published information. It just needs to query to 
find out the set of published data.

Does anyone have some use cases to motivate a notification feature on 
the publication side?

> presence information itself may contain its own identifiers (like the 
> tuple ID in PIDF) that could be reused as needed (such as the case in 
> which one device overwrites presence published by another).

I think that, if the only thing you need sequencing for is to determine 
the most recent tuple or status, the identifiers in the tuples, along 
with the timestamps, will suffice. You also need to know the source of 
the publisher, but you don't need a dialog for that.

I would argue that the need for some kind of sequencing beyond the 
timestamps in the tuples arises if we support differential (not partial)

publication. In that case, I think you do need some kind of sequencing 
outside of the tuple id. But, if we don't do that, even partial 
publication doesn't need sequencing outside of the pidf.

The counter-arguments is that its probably a good thing to provide 
sequencing of published presence data independent of the document type. 
We may have other formats beyond pidf for specific vertical sources of 
presence data.

The real benefit of the dialog state is the efficiency of avoiding going

through proxies for updates and refreshes. You WILL need to refresh, 
because published presence is soft-state. Managing the soft-state may 
actually be hard if there is no sequencing provided by the SIP 
mechanism. The Call-ID/CSeq are required in REGISTER in order to do
this.

Here is an argument against dialogs. One can imagine that a PUA might 
actually be this big server that is, for example, collecting geolocation

for a large number of users and publishing it into the presence system. 
It would be nice to not require additional state on that box in order to

do the publication. If it could periodically sample the geoloc, 
construct a presence doc, timestamp it, and send it in a PUBLISH, 
without needing to remember the call-id or cseq, that would be a good 
thing, I think.

One final comment. If we do add dialog support, we need to add the 
machinery to clean them up. There needs to be a way for both sides to 
indicate termination of the dialog.

-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

---

From: [email-masked]
Date: Mon, 10 Feb 2003 11:05:49 +0200

Hi,

Inline.

> From: ext Anders Kristensen [mailto:[email-masked]]
> 
> Paul Kyzivat wrote:
> > I agree that this is a reasonable approach.
> > 
> > It does however open up some new issues that would need to 
> be sorted out 
> > - not a fundamental problem, just more work. Specifically, 
> what should a 
> > UAS do when receiving a "medialess" invitation? This 
> probably depends on 
> > the purpose of the invitation. In the case we are 
> discussing the purpose 
> > is simply to establish a dialog to carry PUBLISH messages, 
> but it could 
> > be preparatory to a reinvitation with media, or whatever. 
> If the UAS 
> > happens to be capable, should it alert?
> 
> The intent to send PUBLISH'es over a dialog could be "negotiated" 
> through an m= line of the sdp in the INVITE similar to what 
> we're doing 
> for session-mode MESSAGEs.

We can also go down this path and forget PUBLISH altogether, and use a PDIF-over-TCP media - just like we've done away with MESSAGE in the message session work.

It seems to me we're going around in circles here. Where are the requirements driving this discussion? 

Cheers,
Aki

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 11 Feb 2003 02:00:38 -0500

A couple of comments here.

Firstly, I agree with Sean that publish is not 'media'. Personally, I
recognize an informal distinction between 'signaling' and 'media' (one that
is perhaps grounded too much in traditional PSTN thinking), where things
like SDP would count as signaling, whereas bearer (be it voice or instant
messages) would count as media. However, I think we should not use SDP to
set up sessions for exchanging signaling, and I think
publication/notification definitely falls into the 'signaling' category.

Second, I have a hard time justifying a 'medialess' dialog for PUBLISH. For
some other methods, it may make sense to use a pre-existing dialog that was
established for other purposes to send this sort of signaling information,
but there really isn't any reason why such a pre-existing dialog should be
established between a PUA and a compositor (subscribing to your own presence
for this reason doesn't seem right to me - strictly, that's subscribing to
the PA, not the compositor, and the two may not be composed).

I am happy with Jonathan's suggestion that we pass over dialogs in silence
for now. The question would then be, do we need the Stream header? Or would
the tuple IDs in PIDF (and presumably a similar attribute in any other
presence format) be sufficient to identify an atom of presence?

Jon Peterson
NeuStar, Inc.

> Sent: Monday, February 10, 2003 8:33 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> There is a disconnect here. You can rightfully
> argue that MESSAGE is media in the context of
> a IM "session" (INVITE dialog). However, what I
> was proposing is something much different. I was
> proposing a signaling session established by an
> INVITE. In this case, what is being exchanged is
> literally SIP messages -- there is no simpler 
> canonical form that can be transferred here such
> as CPIM/TCP. And unlike the CPIM case, what I
> am suggesting is that the PUBLISH request have
> all the same characteristics as the dialog within 
> which it is established, including Call-ID, route
> set, etc. This is definitely not media.
> 
> --- [email-masked] wrote:
> > I agree with what Aki's proposes. We purposefully
> > rejected the use of MESSAGE within a dialog for
> > various reasons including that; once you have
> > established a dialog, a SIP message carries way too
> > much information that it needs as a media protocol.
> > The reasons apply here also.
> > 
> > I personally don't have any strong opinions
> > regarding a PUBLISH having to do with dialogs. But
> > if it does, then I prefer for the PUBLISH to
> > establish the dialog rather than using SIP yet again
> > as another form of media protocol.
> > 
> > If it will be INVITE to establish the publishing
> > dialog, then, as Aki suggests, PIDF is the way to
> > go, IMHO.
> > 
> > Regards,
> > Hisham
> > 
> > > From: ext [email-masked]
> > [mailto:[email-masked]]
> > > Sent: Monday, February 10, 2003 11:06 AM
> > > To: [email-masked];
> > [email-masked]
> > > Cc: [email-masked]; [email-masked];
> > Kiss Krisztian
> > > (NRC/Tampere); [email-masked];
> > [email-masked]
> > > We can also go down this path and forget PUBLISH
> > altogether, 
> > > and use a PDIF-over-TCP media - just like we've
> > done away 
> > > with MESSAGE in the message session work.
> > > 
> > > It seems to me we're going around in circles here.
> > Where are 
> > > the requirements driving this discussion? 
> > > 
> > > Cheers,
> > > Aki
> > > 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
>

---

From: [email-masked]
Date: Tue, 11 Feb 2003 11:18:59 +0200

I am happy with Jonathan's suggestion as well.

Regarding the Stream header vs. tuple-id; we need a mechanism that can handle crash recovery (just like the REGISTER*). If that logic can be performed on tuple-id, then lets use that, but if it can't, then we need a stream-header.

*Extract from RFC3261 that I refer to:

"If the
         binding does not exist, it is tentatively added.  If the
         binding does exist, the registrar checks the Call-ID value.  If
         the Call-ID value in the existing binding differs from the
         Call-ID value in the request, the binding MUST be removed if
         the expiration time is zero and updated otherwise.  If they are
         the same, the registrar compares the CSeq value.  If the value
         is higher than that of the existing binding, it MUST update or
         remove the binding as above.  If not, the update MUST be
         aborted and the request fails."

Regards,
Hisham

> From: ext Peterson, Jon [mailto:[email-masked]]
> Sent: Tuesday, February 11, 2003 9:01 AM
> To: 'Sean Olson'; Khartabil Hisham (NMP/Helsinki); Niemi Aki
> (NMP/Helsinki); [email-masked]; [email-masked]
> Cc: [email-masked]; Kiss Krisztian (NRC/Tampere);
> [email-masked]