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

From: [email-masked]
Date: Fri, 19 Dec 2003 11:52:05 +0200

Inline

> -----Original Message-----
> From: Aki Niemi [mailto:[email-masked]] 
> Sent: Thursday, December 18, 2003 2:21 PM
> 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.
> 
> > 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?

'application/pidf-partial+xml' should work 'out of the box'. However, I
think there are some issues which needs to be documented if you want to
do that. Draft-ietf-simple-partial-notify specifies how
'application/pidf-partial+xml' is used with SUB/NOT i.e. when watcher
and PS should use 'full' and 'partial' state notifications. I think
something similar is needed if you want to use this with PUBLISH. In
practice this probably means documenting how EAP should use 'full' and
'partial' state in the context of etag.

- Mikko

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

_______________________________________________
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: Fri, 19 Dec 2003 14:00:04 +0200

> 'partial' state in the context of etag.

That sounds very straight forward to me. However, specifying partial 
publishing falls out of scope for the PUBLISH specification, so I think 
we are talking about a presence publication extension that will have to 
be addressed separately in the future.

Cheers,
Aki