Subject: Re: [Simple] PUBLISH requirements

From: Ben Campbell <[email-masked]>
Date: Thu, 02 Jan 2003 16:37:57 -0600

[email-masked] wrote:
> Hi All,
> 
> In order to help to progress the PUBLISH requirements work, here is a collection of requirements as a discussion opener. Comments are more than welcome.
> 
> REQ1: It must be possible for the PUA to add elements to the presence information as well as remove or modify existing elements of the presence information. 
> 
> REQ2: The publish mechanism must allow a PUA to change only part of the presentity's presence information. For example, a PUA must be able to only publish one single <tuple> element of the presentity's PIDF document, while the document contains several <tuple> elements.
> 
> REQ3: There must be one default content type for the publish mechanism.  

I am not sure if this means there should be a default that is assumed if 
the type is not specified, or that their should be a common type that 
all implementations are required to understand.
> 
> REQ4: It must be possible for the presentity to publish multimedia contents along with their communication means. 

I am not sure what communication type means here. Are we talking about 
content published indirectly? If so, then the descriminator should be 
"large content" or "indirect content" rather than multimedia content.

> 
> REQ5: The publication mechanism must allow publishing from multiple PUAs of a single presentity. 
> 
> REQ6: The PUA must be able to publish to a specific piece of presence, shared among many PUAs (the number of sources must neither be limited nor pre-defined). This means that the published tuples need to be identified across all of the PUAs of a presentity. 

I am not sure I understand this one. What do you mean by the phrase 
"specific piece of presence"? I tend to assume that this means a 
specific tuple, but the latter part of the requirement seems to 
contradict that.

> 
> REQ7: Presence information must be always available. This means that in case the PUAs do not refresh presence information, some information must remain available for watchers, as - for example - the remaining information is hard-state data by nature or soft-state data but it has default value when data expired. 

This has a lot of interesting permutations. Is it enough that a watcher 
remembers the last presence document it saw before the expiration? If a 
presence document has expired, is the compositor obligated to keep it 
around forever, in case someone asks for it that may not have received 
the latest known document?

> 
> REQ8: The PUA must be able to receive feedback about the result of a publishing transaction, the feedback must contain enough information for the principal controlling the presentity to know that the published presence information was successfully composed into the presence document by the Presence Server.

Does this imply a requirement that the PUA receive the final composed 
document as part of the feedback? Or is it enough just to return a 
response code, and say the PUA must subscribe to the presence doc if it 
cares?

> 
> Regards,
> Krisztian
> 
> 
>>-----Original Message-----
>>From: ext Jonathan Rosenberg [mailto:[email-masked]]
>>Sent: Friday, December 13, 2002 7:36 AM
>>To: Niemi Aki (NET/Espoo)
>>Cc: [email-masked]
>>Subject: Re: [Simple] PUBLISH requirements
>>
>>
>>
>>
>>[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
>>
>>_______________________________________________
>>simple mailing list
>>[email-masked]
>>http://mailman.dynamicsoft.com/mailman/listinfo/simple
>>
> 
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 03 Jan 2003 01:04:22 -0500

inline.

Ben Campbell wrote:
>> In order to help to progress the PUBLISH requirements work, here is a 
>> collection of requirements as a discussion opener. Comments are more 
>> than welcome.
>>
>> REQ1: It must be possible for the PUA to add elements to the presence 
>> information as well as remove or modify existing elements of the 
>> presence information.

I think you need to be careful here. I don't think the requirement is 
that it be able to explicitly say "add this tuple". I think that each 
PUA should publish its own view of the state of the presentity, and that 
the compositor combine all such views together.

I am not convinced that there is a need, out of the gate, to be able to 
do differential publication on a PUAs own view. That is, PUA1 publishes 
tuples A and B, and PUA2 publishes tuples C and D. The composite 
presence document has all four. I believe that PUA1, when it updates its 
view of tuple B, would send A and B again. There need not be a way to 
publish just the differential to B.

I don't think such a thing is bad, I just think its not critical at this 
time.

>> REQ2: The publish mechanism must allow a PUA to change only part of 
>> the presentity's presence information. For example, a PUA must be able 
>> to only publish one single <tuple> element of the presentity's PIDF 
>> document, while the document contains several <tuple> elements.

Again, based on the above, I agree that a PUA need only publish its view 
of the presentity state, which is by definition only a partial view.

> all implementations are required to understand.

I assumed this meant that there was a baseline standard, i.e., everyone 
has to support PIDF.

> 
>>
>> REQ4: It must be possible for the presentity to publish multimedia 
>> contents along with their communication means. 
> 
> 

I agree we should allow for URI references to things like pictures and 
vcards. But, that seems more an issue for the PIDF extension work than 
PUBLISH.

>> PUAs of a single presentity.

No doubt.

>> REQ6: The PUA must be able to publish to a specific piece of presence, 
>> shared among many PUAs (the number of sources must neither be limited 
>> nor pre-defined). This means that the published tuples need to be 
>> identified across all of the PUAs of a presentity. 
> 
> 

I think I understand. The idea is that I may have one tuple, 
representing my work desktop presence. If I leave it on, I should be 
able to go home, and publish from my laptop, an update to that state. 
This requires some kind of broadly scoped tuple naming and discovery 
mechanisms. A PUA would need to be able to find the tuple name for the 
work PC, and then PUBLISH an update to it.

Now, there are two views for what it means for two PUA to publish to the 
same tuple. One interpretation is that the status's between the two are 
to be combined. So, for example, if my work PC was publishing 
<basic>OPEN</basic> for that tuple, and my laptop at home published 
<simple:newstatus>alive</simple:newstatus> for that tuple, the 
compositor would act as if it had received a single tuple with both 
statuses (of course during composition it may discard one or the other, 
but the publication intent is clear.)

Another interpretation is that one of them "wins". So that, in the 
example above, my laptop would now "win" and the compositor would act as 
if it had received a single tuple with JUST the simple:newstatus status. 
I personally prefer this interpretation, but I suppose one could argue 
for either one.

Assuming we do go for this "replace" semantic, this also means that 
subsequent publishes by the desktop PC need to be rejected (assuming it 
automatically refreshes). Something like IF-MODIFIED-SINCE (from acap) 
as part of the publication process would work for that. Credit goes to 
Robert Sparks for suggesting that to me privately.

So, I would actually expand this into several requirements:

* There must be a way to uniquely identify tuples across all PUA for a 
particular presentity

* There must be a way for a PUA to discover the tuple names for those 
tuples currently active from other PUA for that presentity. I will note 
that Krisztian has presented this requirement in the past, and in the 
past, I have questioned it. I am now convinced that these tuple names 
live **ONLY** on the publication side, so that it is not sufficient to 
subscribe to the presence of the presentity in order to learn them. 
Thus, I now accept this requirement.

* There must be a way to allow two PUA to publish data for the same 
tuple (i.e, the same name)

* There must be a way to publish with a "forced write" so that the 
published tuple overrides any existing tuple with the same name

* There must be a way to reject a published tuple from a PUA because it 
has been replaced by one published from another PUA

> 
>>
>> REQ7: Presence information must be always available. This means that 
>> in case the PUAs do not refresh presence information, some information 
>> must remain available for watchers, as - for example - the remaining 
>> information is hard-state data by nature or soft-state data but it has 
>> default value when data expired. 
> 
> 

I think its compositor policy about what to do here. I believe published 
presence documents are fundamentally soft-state. If they expire, the 
"input" to the compositor disappears. How the compositor reacts to this 
is policy dependent. It might choose to drop those tuples from the 
overall presentity document. Or, it might drop them until all published 
inputs have expired, and then resort to some provisioned "default" 
presence status. I don't think we can or should specify this.

> 
> 
>>
>> REQ8: The PUA must be able to receive feedback about the result of a 
>> publishing transaction, the feedback must contain enough information 
>> for the principal controlling the presentity to know that the 
>> published presence information was successfully composed into the 
>> presence document by the Presence Server.
> 
> 

Well, by itself this requirement just says it has to know whether it 
worked or not.

It may be, because of the requirement I suggest above about learning the 
other published tuple names, that the PUBLISH response return the 
current "input" tuple set. But, thats an implementation approach not a 
requirement.

-Jonathan R.

---

From: "Dean Willis" <[email-masked]>
Date: Sat, 4 Jan 2003 12:50:00 -0600

> I don't think such a thing is bad, I just think its not 

Well, there are some 3G people thinking that they want to use very large
direct (not indirect) presence documents. There might be, say, 500 tuples,
or individual tuples that are several hundred bytes in size, all sourced
from a single PUA.  There might be a tuple changing every minute or so.
Given an expensive, low-bandwidth connection, it doesn't seem like a good
idea to have to keep republishing all the tuples that didn't change.

I tend to envision the tuple-space as something like a database. From the
PUA's perspective, each tuple is a record in that database. The composition
function is also somewhat like a "view" operation on a database. The records
selected from a "view" (an output function) may be somewhat different from
those submitted into the database. The compositor function can be though of
as something like a stored procedure that does a join-and-merge operation to
generate a view.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 05 Jan 2003 21:21:38 -0500

inline.

> idea to have to keep republishing all the tuples that didn't change.

Given these assumptions, I would be inclined to agree. However, I cannot 
imagine what application would use 500 tuples. I have no problem 
developing standards to solve real problems, but not ones to solve 
potential issues that there are no real use cases for.

> as something like a stored procedure that does a join-and-merge operation to

I think the notion of a view is close, but different. DB views give you 
access to a subset of the database. With presence, the "view" seen by 
any particular subscriber may be totally different, containing different 
values for the same rows, even.

-Jonathan R.