SIMPLE Open Issues Jonathan Rosenberg dynamicsoft IETF 52

Open Issues in Presence-04 Dependencies and duplication Alerts NOTIFY/200 race resolution Forking/migration Indicating subscription status

Dependencies Currently –Rfc2543 sip-events presence Problem –Sip-events is having to repeat more and more text from bis to keep up –Presence duplicates a lot of text from sip-events Proposal –bis sip-events presence –Bis is nearing completion so timing is not going to be much different –Requires cleanup of redundant text across all three docs – in progress

Alerts Would be nice to only be notified of change in presence, not actual presence –Actual presence could then be fetched with HTTP Why is this useful? –Large presence documents wouldnt get fragmented –Large presence docs could be fetched when time is good (I.e., not in a call) SUB sip:user Accept: application/uri-list, application/cpim-pidf+xml 200 OK NOTIFY C-T:application/uri-list C-L: … OK HTTP GET

Details SUBSCRIBE would have Accept header indicate support –Presence of application/uri-list –Still have to support application/cpim- pidf+xml –Can use q values to indicate preferences Would need to baseline HTTP as minimum mandatory URL –HTTPS, SOAP would be others

Issues with Alerts Broader than presence, probably belongs in sip- events –Presence would then state that its allowed\ Security issues –Just because SUB can be authenticated, doesnt mean HTTP can Transitive trust vs. e2e HTTP/SIP interactions –Requires a way for SIP server to manipulate content on web server Duration of URL validity –Need to specify – presumably subscription duration Proposal –Really useful, really simple –Add to sip-events and presence

NOTIFY/200 Race ASSUME you want to only accept one NOTIFY Sip-events says you should accept the one that matches 2xx to SUBSCRIBE What if NOTIFY beats 2xx back? SUB SUB 2xx NOTIFY SUB SUB 2xx NOTIFY 2xx

Proposals Buffer NOTIFYs until 2xx –Then 481 all but matching ones Accept all NOTIFYs –When 2xx arrives, refresh all non- matching –When those NOTIFY arrives, reject with 481 Accept first NOTIFY –SUB 2xx is ignored Accept first message –SUB 2xx if its first –NOTIFY if its first Probably also an issue for sip-events, not presence

Forking Definitely the biggest issue Some problems are not presence specific –HERFP User A Proxy User B User C |SUB | | | | >| | | | |SUB | | | | >| | | |SUB | | | | >| | |401 | | | |< | | | |200 | | | |< | |200 | | | |< | | |

Allow Forking Cons –Burden on sub to merge presence docs –Inability of sub to merge presence docs with proper watcher policy Especially for elements that are NOT per contact –Heterogenous error response forking problem (not presence specific) Makes it hard to authenticate SUBSCRIBE –Unknown billing models –No expectation that it is a requirement to support Pros –May happen anyway –Avoids requirement for proper network architecture to ensure functioning –Allows more flexible operation in scenario where there is no network PA Multiple clients

Disallow Forking Pros –Simplified clients –Correct operation I.e., full and correct presence state Cons –Need to mandate the existence of an aggregator for proper operation –May happen anyway, need to specify what to do –Doesnt allow for serverless distributed systems Will get partial presence or no presence

Proposal Domains SHOULD have aggregation in PA –Avoids forking through network design –Provides most correct and consistent operation If there is no PA, still works if there is just one PUA If there are multiple PUA, you get partial presence, no guarantees –Probably just one NOTIFY anyway because of HERFP Subscribers SHOULD accept only one NOTIFY –Should only need to based on the above But its SHOULD, not MUST –Burden is on the subscriber to implement merging if it wants –Wont generally be needed based on domain requirement, and frequently wont happen because of HERFP

Issue with this proposal Lets say we fix HERFP down the road –Can generate new spec which talks about serverless distributed domains –Warnings about policy issues How does presentity domain know subscriber wont merge, so aggregation is needed anyway? Ideas –If it cant merge, includes caller-prefs no-fork –It if can merge, include caller-prefs fork

Subscription Status NOTIFY needs to contain status of the subscription –Cant rely on 2xx to subscribe –May change later on (pending to accepted) Want to be explicit Adam added Subscription-Expires with reason values to sip-events Issue: need to align with watcherinfo –They are both about the same thing!

Statuses in winfo/sip- events Proposal for unification –Deactivated Subscription terminated Retry again –Probation Retry again, but much later Retry-After Covers maintenance –Rejected Dont bother retrying Policy change –Timeout Retry again if you want Wasnt refreshed –Giveup Couldnt obtain auth sip-events watcherinfo migration deactivated maint ? refused rejected timeout expired ? timeout

Watcherinfo Open Issues Events leading to terminated –See previous discussion… State maintenance for pending/waiting –Possible Dos? Sub is authenticated… –-01 will talk about setting policy for this Tradeoff between user experience and state storage Elements in data format –Next slide

Elements in Data Format Watcherinfo data –Uri of watcher –Status of subscription –Event which triggered notification –Duration: time in last state –First-subscribed –Most-recently-subscribed –Notify-address –Expiration

IMTP (with A. Houri, C. Huitema, R. Osborne)

Motivations for IMTP Requirements for IM transport –Congestion Control –Reliable, sequence delivery –Arbitrary sized messages –Framing –Per-IM content typing –E2e privacy, integrity, authenticity –Works through NAT –Rapid delivery –Lightweight –Parser Reuse –Compressible –Support for relay intermediaries –Muxing –Logging –Per message ACKs

The hard configuration Proxy PC Enterprise 1 Proxy PC Enterprise 2 Internet

How about SIP? Pros –Parser reuse –Proxies as intermediaries –NAT traversal easy –Logging, framing, sequencing all done Cons –SIP has features that would get in the way Record-routing Redirection Forking –Messages might go over UDP –Performance of Proxy as pure forwarding intermediary is poor

Idea: SIP subset IMTP proper subset of SIP –Remove uneeded features Forking, redirection, recursion, record- routing and route –Introduce restrictions Only TCP Change protocol field to IMTP/1.0 from SIP/2.0 –Most proxies wont route –BUT, one-liner to fix that –Want this to be explicit about what protocol is running Proxy with proper configuration can route IMTP –No forking, no record- routing, no redirect, TCP only Can use REGISTER to set up IMTP bindings!

User A Proxy IMTP Proxy IMTP User B P1 Relay P2 Relay R1 R2 | | | | | | |(1) INVITE | | | | | >| | | | | | |(2) REGISTER | | | | | >| | | | | |(3) 200 OK | | | | |< | | | | | |(4) INVITE | | | | | >| | | | | | |(5) REGISTER | | | | | >| | | | | |(6) 200 OK | | | | |< | | | | | |(7) INVITE | | | | | >| | | | |(8) 200 OK | | | | |< | | | | |(9) REGISTER | | | | | >| | | | | |(10) 200 OK | | | | |< | | | |(11) 200 OK | | | | |< | | | | |(12) REGISTER | | | | | >| | | | | |(13) 200 OK | | | | |< | | | | |(14) 200 OK | | | | |< | | | | | |(15) ACK | | | | | | >| | | | | | |(16) ACK | | | | | | >| | | | | | |(17) ACK | | | | | | >| |(18) MESSAGE | | | | | >| | | | | | |(19) MESSAGE | | | | | >| | | | | | |(20) MESSAGE | | | | | >| | | | | |(21) 200 OK | | | | |< | | | |(22) 200 OK | | | | |< | | |(23) 200 OK | | | | |< | | | | | | | | | |

Open Issues Is this the right approach? OPES-style authorization for intermediaries?