Subject: [Simple] PUBLISH requirements

From: [email-masked]
Date: Wed, 11 Dec 2002 16:54:04 +0200

Hi All,

The discussion in the SIMPLE session in Atlanta lead us towards another round of PUBLISH requirements.  I think it would be good to look at some requirements that might be arising from the fact that the dynamics of publishing are distinctly different from the dynamics of notification.

In presence notification, there is a single source, and multiple watchers representing a number of sinks.  This of course is reflected in the PIDF format for presence documents, which states that each document contains complete state of the presentity, and tuples have unique IDs within that presence document, but carry no semantic value beyond that.

But in presence publishing, there are multiple sources for presence information, represented by the PUAs, and only a single sink, represented by the composer.  In order for the composer to make a coherent, single presence document out of the information coming from many sources, the composer should be able to identify the published information uniquely across all of the PUAs of a presentity.  

For example, if we say that a tuple is the base data unit of published presence information, then a specific tuple has to have a common ID across all PUAs of a presentity.  In other words, the tuple-id needs to have semantics associated with it.  This way the composer can merge two "im-inbox" publications into one single presence document tuple.  This seems like an additional requirement for PIDF when it is used in publishing presence state.

In addition to this, I think there may also be other requirements there related to expiration of state, and the fact that not all presence information is wrapped into a <tuple> element.  E.g., the presentity level <note> element is not dependent of any tuples.  How does one only publish a <note>?  Or remove it?

Thoughts?

Cheers,
Aki
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Dec 2002 00:35:56 -0500

[email-masked] wrote:

 > The discussion in the SIMPLE session in Atlanta lead us towards
 > another round of PUBLISH requirements.  I think it would be good to
 > look at some requirements that might be arising from the fact that
 > the dynamics of publishing are distinctly different from the dynamics
 > of notification.

Yes, I agree. Makes you glad we didn't go for NOTIFY as the publication 
mechanism...

  In order for the composer to make a
 > coherent, single presence document out of the information coming from
 > many sources, the composer should be able to identify the published
 > information uniquely across all of the PUAs of a presentity.

The information is needed by others too. A presentity might want to 
setup a policy that says "only Joe and Bob can see my cell phone". That 
requires some unique way for the composer to identify which tuple is the 
cell phone.

 >
 > For example, if we say that a tuple is the base data unit of
 > published presence information, then a specific tuple has to have a
 > common ID across all PUAs of a presentity.  In other words, the
 > tuple-id needs to have semantics associated with it.  This way the
 > composer can merge two "im-inbox" publications into one single
 > presence document tuple.  This seems like an additional requirement
 > for PIDF when it is used in publishing presence state.

I think this is a slightly different issue than above. One requirement 
is just identification of the tuples whose scope is broader than the id 
attribute. What you are suggesting here, I think, is almost to define 
different classes of tuples. THis way, if I have two PCs, each of which 
has an "im-inbox", the composer could know to combine (or treat in the 
appropriate manner) those two tuples. That seems more of a slippery slope.

 >
 > In addition to this, I think there may also be other requirements
 > there related to expiration of state, and the fact that not all
 > presence information is wrapped into a <tuple> element.  E.g., the
 > presentity level <note> element is not dependent of any tuples.  How
 > does one only publish a <note>?  Or remove it?

Well, PIDF is going to change to allow a document with just a note. I 
raised this issue in IMPP and folks were ok with the change.

Now, to remove a note, you'd presumably publish an empty document.

That is, the assumption is that, as far as each publication instance is 
concerned, each publication represents the complete presence state from 
that instance.

-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