Ad-hoc Resource Lists using SUBSCRIBE 58th IETF Meeting SIMPLE WG Ad-hoc Resource Lists using SUBSCRIBE draft-levin-simple-adhoc-list-00.txt by Orit Levin oritl@microsoft.com IETF58 / SIMPLE WG

Motivation The ietf-simple-event-list-04 solves an acute problem of BATCHED notifications by introducing the RLMI schema. This mechanism cannot be deployed in an interoperable manner without standard creation of “soft” or “hard” lists. “Soft” list is required by many Presence applications. IETF58 / SIMPLE WG

Problem Definition The ad-hoc list is dynamically created and modified by a Watcher The list creates a “soft state” in the Server (RLS) The list exists only for the life-time of a SUBSCRIBE dialog Notifications are being sent in any dynamically agreed format (PIDF, RLMI, etc.) IETF58 / SIMPLE WG

The Proposed Solution Option Tag Name: adhoclist MIME Media Type Name: application MIME subtype name: adrl+xml IETF58 / SIMPLE WG

The Proposed Solution IETF58 / SIMPLE WG Watcher Server PUA | F1 SUBSCRIBE [ADRL] | | |------------------------------------->| | | F2 200 OK | | |<-------------------------------------| | | F3 NOTIFY [RLMI] | | | F4 200 OK | | | | F5 Update presence | | |<---------------------------------- | | F6 NOTIFY [RLMI] | | | F7 200 OK | | | F8 SUBSCRIBE [ADRL] | | | F9 200 OK | | | F10 NOTIFY [PIDF] | | | F11 200 OK | | IETF58 / SIMPLE WG

Example Messages Flow IETF58 / SIMPLE WG F1 Watcher Server PUA | F1 SUBSCRIBE | | |-------------------------->| | | F2 200 OK | | |<--------------------------| | | F3 NOTIFY | | | F4 200 OK | | | | F5 Update presence | |<--------------- | | F6 NOTIFY | | | F7 200 OK | | | F8 SUBSCRIBE | | | F9 200 OK | | | F10 NOTIFY | | | F11 200 OK | | F1 SUBSCRIBE sip:user@pres.example.com SIP/2.0 To: <sip:user@pres.example.com> From: <sip:user@example.com>;tag=22222 Call-ID: 2345@terminal.example.com Event: presence Require: adhoclist Accept: application/cpim-pidf+xml Accept: application/rlmi+xml Contact: <sip:user@terminal.example.com> Content-Type: application/adrl+xml Content-Length: ... [ADRL Document] F2 SIP/2.0 200 OK To:<sip:user@pres.example.com>;tag=33333 Accept: application/adrl+xml Contact: sip:pres.example.com Content-Length: 0 IETF58 / SIMPLE WG

Detailed Example Messages Flow Watcher Server PUA | F1 SUBSCRIBE | | |-------------------------->| | | F2 200 OK | | |<--------------------------| | | F3 NOTIFY | | | F4 200 OK | | | | F5 Update presence | |<--------------- | | F6 NOTIFY | | | F7 200 OK | | | F8 SUBSCRIBE | | | F9 200 OK | | | F10 NOTIFY | | | F11 200 OK | | F3 NOTIFY sip:user@terminal.example.com SIP/2.0 From: <sip:user@pres.example.com>;tag=33333 To: <sip:user@example.com>;tag=22222 Call-ID: 2345@terminal.example.com Event: presence Subscription-State: active;expires=750 Contact: sip:pres.example.com Content-Type: application/rlmi+xml Content-Length: ... [RLMI Document] F4 SIP/2.0 200 OK From: <sip:user@example.com>;tag=33333 To: <sip:user@pres.example.com>;tag=22222 Content-Length: 0 IETF58 / SIMPLE WG

Detailed Example Messages Flow (Cont.) Resources’ information on the RLS is updated by SIP or non-SIP means. (Details are out of scope. ) F6 NOTIFY sip:user@terminal.example.com SIP/2.0 From:<sip:user@pres.example.com>;tag=33333 To: <sip:user@example.com>;tag=22222 Call-ID: 2345@terminal.example.com Event: presence Subscription-State: active;expires=750 Contact: sip:pres.example.com Content-Type: application/rlmi+xml Content-Length: ... [RLMI Document] F7 SIP/2.0 200 OK To: <sip:user@pres.example.com>;tag=33333 From: <sip:user@example.com>;tag=22222 Require: eventlist Content-Length: 0 Watcher Server PUA | F1 SUBSCRIBE | | |-------------------------->| | | F2 200 OK | | |<--------------------------| | | F3 NOTIFY | | | F4 200 OK | | | | F5 Update presence | |<--------------- | | F6 NOTIFY | | | F7 200 OK | | | F8 SUBSCRIBE | | | F9 200 OK | | | F10 NOTIFY | | | F11 200 OK | | IETF58 / SIMPLE WG

Detailed Example Messages Flow (Cont.) SUBSCRIBE sip:user@pres.example.com SIP/2.0 To: <sip:user@pres.example.com> From: <sip:user@example.com>;tag=22222 Call-ID: 2345@terminal.example.com Event: presence Require: adhoclist Accept: application/cpim-pidf+xml Accept: application/rlmi+xml Contact: <sip:user@terminal.example.com> Content-Type: application/adrl+xml Content-Length: ... [ADRL Document] F9 SIP/2.0 200 OK To: <sip:user@pres.example.com>;tag=33333 Accept: application/adrl+xml Contact: sip:pres.example.com Content-Length: 0 Watcher Server PUA | F1 SUBSCRIBE | | |-------------------------->| | | F2 200 OK | | |<--------------------------| | | F3 NOTIFY | | | F4 200 OK | | | | F5 Update presence | |<--------------- | | F6 NOTIFY | | | F7 200 OK | | | F8 SUBSCRIBE | | | F9 200 OK | | | F10 NOTIFY | | | F11 200 OK | | IETF58 / SIMPLE WG

Detailed Example Messages Flow (Cont.) Watcher Server PUA | F1 SUBSCRIBE | | |-------------------------->| | | F2 200 OK | | |<--------------------------| | | F3 NOTIFY | | | F4 200 OK | | | | F5 Update presence | |<--------------- | | F6 NOTIFY | | | F7 200 OK | | | F8 SUBSCRIBE | | | F9 200 OK | | | F10 NOTIFY | | | F11 200 OK | | F10 NOTIFY sip:user@terminal.example.com SIP/2.0 From:<sip:user@pres.example.com>;tag=33333 To: <sip:user@example.com>;tag=22222 Call-ID: 2345@terminal.example.com Event: presence Subscription-State: active;expires=650 Contact: sip:pres.example.com Content-Type: application/rlmi+xml Content-Length: ... [RLMI Document] F11 SIP/2.0 200 OK From: <sip:user@example.com>;tag=33333 To: <sip:user@pres.example.com>;tag=22222 Content-Length: 0 IETF58 / SIMPLE WG

Relation to draft-camarillo-sipping-exploders-solution-00.txt The draft proposes the following: Generalization of the requirements for any method Inside a dialog / No dialog Identifying the different possible Server modes Involved / Uninvolved IETF58 / SIMPLE WG

Our Case: Ad-hoc Resource Lists using SUBSCRIBE Classification: B2BUA “Uninvolved exploders” Inside a dialog IETF58 / SIMPLE WG

Our Case: Ad-hoc Resource Lists using SUBSCRIBE It is an Excellent Study Case Longtime identified requirements Technically straightforward No new security risks IETF58 / SIMPLE WG

Proposed Next Steps Define as a WG Working Item in SIMPLE The first “exploder” application and study case The mechanisms for AD-HOC LIST definition and maintenance MUST be general Start polishing the specification details on the list The standardization timing is crucial here! IETF58 / SIMPLE WG

Points for Further Discussion on the List List unique identification Stand-alone identifier? Bind to a dialog? Version numbering Required? Reflects the notifications numbering Full list always vs. deltas are allowed Are refreshes of the list required? IETF58 / SIMPLE WG

Thank you! IETF58 / SIMPLE WG