Subject: [Sip] PUBLISH and presence compositor policy

From: Aki Niemi <[email-masked]>
Date: Thu, 18 Dec 2003 10:22:41 +0200

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.

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

---

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

> -----Original Message-----
> From: Aki Niemi [mailto:[email-masked]]
> Sent: 18.December.2003 14:21
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: [email-masked]; Lonnfors Mikko (NRC/Helsinki)
> Subject: Re: [Sip] PUBLISH and presence compositor policy
> 
> 
> 
> 
> Khartabil Hisham (NMP-MSW/Helsinki) wrote:
> 
> >> 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. 
> 
> 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.

Sorry, I didn't make my point very clear. I was talking about partial publishing, not full publishing. I agree with your statement above.

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

I don't see any reason why not.

/Hisham

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