Subject: RE: [Sip] PUBLISH and presence compositor policy

From: [email-masked]
Date: Thu, 18 Dec 2003 14:03:20 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf 
> Of ext Aki
> Niemi
> Sent: 18.December.2003 10:23
> To: [email-masked]'
> Subject: [Sip] PUBLISH and presence compositor policy
> 
> 
> All,
> 
> There's one more issue with regards to PUBLISH, related to presence 
> publication. I've talked with our implementors, and the issue 
> also came 
> up in the recent SIMPLEt event. Currently, composer policy 
> for presence 
> seems underspecified, namely that the PUBLISH draft doesn't 
> talk about 
> how the composer should treat the published tuples, and also 
> gives few 
> tools for creating such policy.
> 
> For example:
> 
> - EPA publishes three tuples {X, Y, Z}, and receives etag Q for it
> - EPA modifies publication that matches 'Q', by sending two tuples
>    {X', Y'}
> 
> How can the ESC determine which tuples were just dropped, which ones 
> were modified/unmodified, and which ones are completely new ones?
> 
> The easy answer to this is of course to use the tuple-ids, 
> but we don't 
> mandate that the EPA keeps the tuple-ids consistent in its modifying 
> publications. It could generate new tuple-ids for all of the 
> tuples in 
> each round of modification.
> 
> All of this makes composer policy more complex, and especially 
> implementing partial-notify unnecessarily hard.
> 
> So my proposal is to add the following text to Chapter 4 
> "Considerations 
> for Event Packages using PUBLISH":
> 
>     In presence publication, the EPA MUST keep the tuple-ids
>     consistent within a publication cycle. If a particular tuple
>     is modified, it MUST maintain its original tuple-id.
>     Similarly, if a tuple is added, its tuple-id MUST NOT concide
>     with a tuple that is deleted. A publication cycle begins with
>     an initial publication, and ends when either the publication
>     expires, or is explicitly removed.

These were might thoughts as well. The issue of deleting tuples still remains. What does it mean if an EPA doesn't include a tuple in a PUBLISH refresh? Is it deleted? I would say no. You don't want every PUBLISH refresh to carry the same number of tuples. So we need a way to explicitly remove tuples.

This kinda mandates partial publishing.

/Hisham

> 
> While this doesn't spell out what a presence composer policy 
> should be, 
> it at least gives the composer more tools for deriving from 
> an incoming 
> publication the type of state change that occurred, and where 
> exactly it 
> occurred.
> 
> Thoughts?
> 
> Cheers,
> Aki
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Aki Niemi <[email-masked]>
Date: Thu, 18 Dec 2003 14:20:49 +0200

Khartabil Hisham (NMP-MSW/Helsinki) wrote:

>> "Considerations for Event Packages using PUBLISH":
>> 
>> In presence publication, the EPA MUST keep the tuple-ids consistent
>> within a publication cycle. If a particular tuple is modified, it
>> MUST maintain its original tuple-id. Similarly, if a tuple is
>> added, its tuple-id MUST NOT concide with a tuple that is deleted.
>> A publication cycle begins with an initial publication, and ends
>> when either the publication expires, or is explicitly removed.
> 
> 
> These were might thoughts as well. The issue of deleting tuples still
> remains. What does it mean if an EPA doesn't include a tuple in a
> PUBLISH refresh? Is it deleted? I would say no. 

I disagree. I really think all PUBLISH requests should have 'replace' 
semantics. That is, each modifying publication (i.e., a PUBLISH with a 
valid etag and a body of event state) replaces the previously published 
state associated with that particular etag. Now the issue is really how 
the composer determines what sort of a replacement it was.

So to delete a tuple, the EPA simply omits it from a PUBLISH. So if a 
tuple-id is missing compared to the previous publication, it is 
"deleted", i.e., missing relative to the existing state associated with 
the etag.

> You don't want every
> PUBLISH refresh to carry the same number of tuples. So we need a way
> to explicitly remove tuples.
> 

I agree with your thoughts about needing partial publishing to save 
bandwidth with the publications. But I see no reason why this can't be a 
function of the body which carries the event state (as it is in 
presence). In fact, for presence, we ought to be able to use 
"application/pidf-partial+xml" straight out of the box?

Cheers,
Aki

> /Hisham
> 
> 
>> While this doesn't spell out what a presence composer policy should
>> be, it at least gives the composer more tools for deriving from an
>> incoming publication the type of state change that occurred, and
>> where exactly it occurred.
>> 
>> Thoughts?
>> 
>> Cheers, Aki
>> 
>> 
>> 
>> _______________________________________________ Sip mailing list
>> https://www1.ietf.org/mailman/listinfo/sip This list is for NEW
>> development of the core SIP Protocol Use
>> [email-masked] for questions on current sip Use
>> [email-masked] for new developments on the application of sip
> 
>