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

wouldn’t get fragmented– Large presence docs could

be fetched when time is good (I.e., not in a call)

SUB sip:userAccept: application/uri-list, application/cpim-pidf+xml

200 OK

NOTIFYC-T:application/uri-listC-L: …

http://www.getit.com

200 OK

HTTP GET http://www.getit.com

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, doesn’t 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

– Doesn’t 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

– Won’t generally be needed based on domain requirement, and frequently won’t 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 won’t merge, so aggregation is needed anyway?

• Ideas– If it can’t merge,

includes caller-prefs no-fork

– It if can merge, include caller-prefs fork

Subscription Status

• NOTIFY needs to contain status of the subscription– Can’t 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• Don’t bother retrying• Policy change

– Timeout• Retry again if you want• Wasn’t refreshed

– Giveup• Couldn’t 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 won’t 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?