Subject: RE: [Simple] PUBLISH requirements

From: [email-masked]
Date: Tue, 7 Jan 2003 21:22:45 +0200

Jonathan, Ben, Dean,

Thanks for the replies. Please see inline:

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

The use case for 'partial publication' would be the 'large direct content in presence document', namely the problem of 'individual tuple that is several hundred bytes'. This might be a potential use case in 3G, if the security & charging problems of content indirection could not be resolved. It is true that REQ1 implicitly sets a requirement for partial publication. Instead of each PUA would publish its own view of state of the presentity, there would be a need for add/modify/remove operations (the minimum data element one publish operation could change would be the <tuple> element or other elements under <presence> element).

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

Yes, this is the intention of REQ2.

> >> 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.
> 
> I assumed this meant that there was a baseline standard, 
> i.e., everyone 
> has to support PIDF.

Right. All implementations are required to support the default content type.
 
> >> 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.
> 
> 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.

This is again the issue whether direct content is possible or not. If possible, then PUBLISH is probably affected by new content-types (e.g. MIME Multipart/Related).

> >> REQ5: The publication mechanism must allow publishing from 
> multiple 
> >> 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 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.
> 
> 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.

I would also prefer this latter interpretation.
 
> 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

These requirements sound good to me. At the same time, this might bring a lot of new issues related to publication authorization. I mean e.g. the following: 
- when there is a tuple collision, the conflicting PUAs could be informed about the situation 
- the conflict could be resolved somehow by deciding which PUA wins and which PUA is ignored 
- the result could be communicated to the PUAs
- as a summary, the presentity could control its PUAs and authorize them to publish.
Probably this would cause more problems than solve, so I am not convinced if this is really needed. As I understand, you are proposing to solve the conflict with simple rules. 
Taking the example of the desktop PC (which keeps refreshing state even if there is no activity on the PC), the IF-MODIFIED-SINCE rule would mean that the publication from the desktop PC could be just ignored if it contains the same state since e.g. one hour AND there is another PUA which intends to overwrite the same tuple. Correct? Is this satisfying? 

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

Dean wrote:
> I think what you mean here is that the invocation of the publishing
> mechanism should not, by default, erase any previously published 
> information. For example, if many different tuples exist for a 
> presentity, that publishing a single new tuple should not 
> normally cause 
> the other previously published tuples to be discarded. Right?

I think there is a requirement for the compositor that it is obligated to always provide some sort of presence document to watchers instead of notifying that 'presence document is not available as it is expired'. 
Furthermore, I think what Dean wrote is also needed. In case of expiry, the compositor policy shouldn't say, by default, to forget about the information, it should rather set a default value, if there is any, or remember e.g. only the tuple name. 

> >> 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?
> 
> Well, by itself this requirement just says it has to know whether it 
> worked or not.

Yes, this requirement only refers to the case how the PUA discovers whether the published document was e.g. a well-formed PIDF. That's another issue how the PUA learns the actual tuple names on the publication side.

Regards,
Krisztian

> 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.
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: [email-masked]
Date: Tue, 14 Jan 2003 16:40:06 +0200

[Resending - was using the old list the last time]

Hi,

Comments inline.

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

Exactly. And in addition, I think there is actually some hard state that needs to be configured along with such a policy. For example, if none of my PUAs are publishing, what will my presence document say? Will it have an offline "cell-phone" tuple, or no such tuple at all. 

This sort of configuration of a presence "profile" (I know, horribly mis/overused term, but can't think of a better one now...), including some sort of default state or fall-back tuple, attached policy and such really seems not to fit the current scope of PUBLISH, although seems to be implicitly in there. So how about clearly separating the requirements for the soft-state updating, and any hard-state, or configuration of presence, and then see what is in scope for the PUBLISH mechanism?
 
>  > 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.

It very well may be. But yes, that is pretty much what I was suggesting. But I do realize that this sort of configuration is really not in the scope of PUBLISH, although so far has sort of been implicitly included as the "composer policy". For clarity's sake, I think we will also need to document the hard-state portion of the presence publishing requirements.
 
>  > 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.

I guess the ability to only publish the note portion of a PIDF doc solves the problem, at least most of it. I'd still like to get a handle on exactly how this jives with expiration. I.e., I go on vacation and publish a note saying exactly that. This note should be persistent over any publication in the mean time that has no note element in it...

Cheers,
Aki