Subject: [Simple] PUBLISH: a dialog?

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 5 Feb 2003 06:08:49 -0500

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: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Feb 2003 09:12:36 -0500

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