1. SIP PUBLISH draft-ietf-simple-publish-01 Aki Niemi aki.niemi@nokia.com

2. Overview Framework for the publication of event state Fills a current gap in the SIP events framework First application is presence publication Not intended for transport of arbitrary data Better tools available (HTTP, FTP, etc.) Extensible to other event packages Each package has to meet certain prerequisites Published event state is soft-state Expires in a negotiated amount of time Needs to be refreshed

3. New definitions EPA = Event Publication Agent UAC issuing the PUBLISH request For presence, corresponds to a PUA ESC = Event State Compositor UAS processing the PUBLSIH request Composites the published event state For presence, corresponds to a PA

4. Versioning Inherited from HTTP validation model Identifying a particular representation of a resource using an opaque entity-tag 1)State changes 2)EPA issues a PUBLISH request with event state 3)ESC assigns a version identifier ETag header of 200 OK carries an entity-tag Etags are opaque to the client Etag may simply be a counter 4)EPA adds a versioning precondition to PUBLISH refreshes If-Match header of PUBLISH request carries the entity-tag No body – entity-tag enough to identity event state Deleting a publication equal to a refresh with “0” expiration 5)In case of collision, precondition fails Request fails with 412 (Precondition Failed) EPA gives up

5. Open Issues: Collision recovery How to recover when a collision occurs? How to avoid the case of battling automata? Currently in the draft: Query principal for further action MAY subscribe to the event package for current composite state Is this enough? Proposal: Yes – leave it as it is

6. Open Issues: PUBLISH and dialogs Question raised in sip-implementors In current examples, subscription precedes publications Do not share the dialog – it’s simply a coincidence However, current draft is silent about reusing dialogs Proposal: Add text about using existing dialogs Add a disclaimer – the other end of the dialog may not be the ESC

7. Open Issue: Atomicity (again) PUBLISH body needs to represent an atomic element of the published state A single segment (I.e., tuple) per request Without pipelining, this is expensive Three options 1. Relax restriction about overlapping requests 2. Batch segments, and have PUBLISH response carry detailed results 3. Batch segments, and in case of collision fall back to atomic publications Proposal to go with option 1 How important is the restriction on not allowing overlapping requests? Even with #3, option 1 would still probably be a good idea

8. Final note Review and comments much appreciated – let’s get this finished! Thank you!