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

From: [email-masked]
Date: Wed, 5 Feb 2003 19:07:59 +0200

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.html
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.
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. By discovering the existing content of the presence document, the PUA could decide whether the data it wants to publish is considered as new or existing, so in the latter case the PUA would overwrite existing information (publish by using existing tuple id).

Thus, I imagine the PUBLISH dialog to be rather similar to SUBSCRIBE-NOTIFY, rather than INVITE. Probably, as soon as a PUA is alive and publishing, the PUBLISH dialog must also be kept alive. 
Comments?

Regards,
Krisztian

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, February 05, 2003 4:13 PM
> To: Peterson, Jon
> Cc: Simpletons (E-mail)
> Subject: Re: [Simple] PUBLISH: a dialog?
> 
> 
> Jon,
> 
> You seem to have made a case that neither an actual dialog nor a 
> pseudo-dialog is needed - that presence publications can be taken at 
> face value as the arrive, regardless of source.
> 
> If so, then the only reason for a dialog might be an 
> efficiency issue - 
> to establish the path between the publisher and the 
> compositor once. Is 
> that a good enough reason? If so, could it be optional? (E.g. the 
> PUBLISH might simply be permitted to piggyback on some 
> existing dialog, 
> without being dialog establishing.)
> 
> 	Paul
> 
> Peterson, Jon wrote:
> > 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
> > 
> 
> _______________________________________________
> 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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 05 Feb 2003 23:24:44 -0500

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

Jon Peterson wrote:
> 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).

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: "Sean Olson" <[email-masked]>
Date: Wed, 5 Feb 2003 21:46:26 -0800

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

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

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

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.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Feb 2003 10:36:55 -0500

I agree with Sean that we ought to think of PUBLISH as a fixed-up 
REGISTER. But I agree with Brian that using Call-ID/CSeq as they are 
used in REGISTER is  probably a mistake, and fails to learn from the 
mistakes of REGISTER.

It would be nice if use of dialogs for PUBLISH was optional. If there 
will be substantial traffic, then it may be useful to set up a dialog. 
If there isn't substantial traffic, or if the endpoints don't want to 
bear the cost (as in the case Jonathan described) it might be better to 
forego a dialog.

Using the dialog mechanism of 3261, there is the option of sending 
PUBLISH messages through a dialog established for some other purpose, 
such as a subscription. If we even want to *permit* that, then we can't 
use Call-ID/CSeq in some conflicting way.

What we don't get with 3261 is a way to have an "optionally dialog 
establishing" method. If PUBLISH isn't dialog establishing, but we want 
to use it in a dialog and don't have one already, there is no perfectly 
suited mechanism to get one. One possibility might be to make a 
medialess invite. But there are many problems with that. It seems like 
an ugly solution.

An obvious technique might be for the publisher to subscribe to its own 
presence - something that is likely to be common. Then it could send 
PUBLISH within the resulting dialog.

Or, we could consider a mechanism for "optionally dialog creating" methods.

	Paul

---

From: Sean Olson <[email-masked]>
Date: Sat, 8 Feb 2003 10:14:53 -0800 (PST)

If you really want dialog state for a PUBLISH,
I would suggest using INVITE to establish a
"signaling" session. Not a new concept ... one
we've needed for a very long time now. I believe
it is as elegant as the INVITE mechanism itself.
Personally, I don't see the utility or efficiency
gained from having PUBLISH within a dialog. As
numerous people have already pointed out, you have
everything you need in the presence doc. itself ...
more importantly, the presence doc. MUST be 
self-sufficient in providing the ordering and
versioning information you would get from a dialog.

--- Paul Kyzivat <[email-masked]> wrote:
> > From: [email-masked]
> [mailto:[email-masked]] On Behalf Of
> > Jonathan Rosenberg
> > It would be nice to not require additional state
> on 
=== message truncated ===

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple