SIP PUBLISH Method Jonathan Rosenberg dynamicsoft

Versioning Current draft using information in the body to provide versioning –Need relative orders across publishers of the same tuple This requires global clock synchronization – bad Proposal: –Cseq orders publications from a particular client –Server assigns a timestamp for each tuple, returned in 200 OK to PUBLISH –PUBLISH has If-Unmodified-Since when updating a tuple – will fail with a 412 if someone else has modified that tuple since I last did –If doc contains multiple tuples, If-Modified-Since applies to all –An automata will not override (by omitting the If-Unmodified- Since) without human interaction

Number of Tuples Can you have a PUBLISH with a PIDF doc with multiple tuples? –Alternative: each is a separate PUBLISH Nice to have the atomicity of the publications (tuple) match what you send in each PUBLISH (a tuple) –Otherwise, to which one does a header apply? I.e., Expires, If-Unmodified-Since, etc.

Label vs. id What uniquely identifies a tuple ? –Current draft says the id attribute However, this requires a lot of semantics for id not defined in PIDF –Chosen uniquely by publishers –Persistent for long periods of time –May be overriden by another publisher Could also use RPIDS label Proposal: have the spec describe these additional semantics to id, and also eliminate label from RPIDS –Plays a similar role

Number of documents The scope of PUBLISH is for any event package –Document specifies things that need to be done to use PUBLISH for any package Should we therefore have one doc for PUBLISH, and then another for the details for presence? Proposal: no – just have a separate section in the same doc

Deletion with Expires: 0 Right now, the tuple ID is part of the presence document To delete a tuple, you send PUBLISH with Expires: 0 –How to identify the tuple you are deleting?? Only solution now is to include a body that has the tuple with its id –Value of the tuple is irrelevant Other solution is that identification of the tuple is done with a header, and the body only contains the value of the tuple (when needed) – not a full PIDF doc

Cseq and Call-ID Spec says client should reuse the same Call- ID and increment Cseq by one However, server never looks at these –Unlike REGISTER With versioning proposal, only tuple ID and server timestamp matter Do we keep current Cseq/CallID rules? –No – will confuse people

Call Forwarding Scenario: –user enables call forwarding from AOR X to AOR Y –PUBLISH to X therefore gets forwarded to Y –ESC looks at To field to determine AOR that is being published-to But this no longer matches the domain of the ESC ESC rejects PUBLISH!

Call Forwarding Solution: –ESC should only use request-URI to determine identity of AOR to which publish applies In the case of a UA that registered, this is the AOR against which the register was made –This doesn’t always work in the call forwarding case Don’t want to delegate SUBSCRIBE and PUBLISH for short- lived call forwarding Solution: call forwarding apps probably only should look at INVITE – not clear where, if anywhere, that would get handled

Migration When migrating subscriptions to a UA, the UA needs to have the state of the presentity If other users are publishing for that presentity, you want the PUBLISH to migrate too However, there will be an interval between when a SUBSCRIBE gets migrated, and the UA has received all PUBLISHes –During this interval, its state will be wrong –Proposal: ignore this problem

Caller Prefs Presence spec recommends clients REGISTER with caller-prefs params to indicate that they support SUBSCRIBE Should the PUBLISH spec recommend the same for PUBLISH? –Yes – should be aligned

Requirement 19 Requirement 19 says: –There must be a way for a publisher to tell a presence agent that a piece of published presence should be passed on to watchers wtihout modification We don’t have such a mechanism Idea 1: S/MIME signature in PUBLISH implies that –Also implies that the presence doc is not composed with anythng else? –But what if the S/MIME is to sign it for consumption by the PA? Idea 2: remove requirement Idea 3: Require header

Requirement 14 Requirement 14 reads –PUAs MUST have a capability that allows them to query for the identifiers of all of the segments of presence information that have currently been published for a presentity (provided that the PUA is authorized to receive this information) We don’t have this Proposal 1: abandon requirement Proposal 2: 200 OK to PUBLISH contains “raw” aggregated presence document with all published tuples Proposal 3: SUBSCRIBE to that event package gives you that data – almost

Hard State How is hard state “default” presence documents specified? I believe we concluded at San Francisco that this is done with data manipulation Making sure… PUBLISH spec should probably mention collecting tuples from non-PUBLISH sources, like xcap