80 likes | 236 Views
SIP PUBLISH draft-ietf-simple-publish-01. Aki Niemi aki.niemi@nokia.com. 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
E N D
SIP PUBLISHdraft-ietf-simple-publish-01 Aki Niemi aki.niemi@nokia.com
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 Overview
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
Versioning • Inherited from HTTP validation model • Identifying a particular representation of a resource using an opaque entity-tag • State changes • EPA issues a PUBLISH request with event state • 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 • 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 • In case of collision, precondition fails • Request fails with 412 (Precondition Failed) • EPA gives up
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
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
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 • Relax restriction about overlapping requests • Batch segments, and have PUBLISH response carry detailed results • 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
Final note • Review and comments much appreciated – let’s get this finished! • Thank you!