SIP PUBLISH draft-ietf-simple-publish-01

1
SIP PUBLISH draft-ietf-simple-publish-01

• Aki Niemi
• aki.niemi_at_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
• 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

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

8
Final note

• Review and comments much appreciated lets get
  this finished!
• Thank you!