160 likes | 167 Views
58 th IETF Meeting SIMPLE WG. Ad-hoc Resource Lists using SUBSCRIBE. draft-levin-simple-adhoc-list-00.txt by Orit Levin oritl@microsoft.com. Motivation. The ietf-simple-event-list-04 solves an acute problem of BATCHED notifications by introducing the RLMI schema.
E N D
58th IETF Meeting SIMPLE WG Ad-hoc Resource Lists using SUBSCRIBE draft-levin-simple-adhoc-list-00.txt by Orit Levin oritl@microsoft.com
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.
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.)
The Proposed Solution • Option Tag Name: adhoclist • MIME Media Type Name: application • MIME subtype name: adrl+xml
The Proposed Solution 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 | | |------------------------------------->| |
Example Messages Flow 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 From: <sip:user@example.com>;tag=22222 Call-ID: 2345@terminal.example.com Event: presence 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 | | |-------------------------->| |
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 Call-ID: 2345@terminal.example.com Content-Length: 0
Detailed Example Messages Flow (Cont.) F5 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 Call-ID: 2345@terminal.example.com Event: presence Require: eventlist 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 | | |-------------------------->| |
Detailed Example Messages Flow (Cont.) F8 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 From: <sip:user@example.com>;tag=22222 Call-ID: 2345@terminal.example.com Event: presence 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 | | |-------------------------->| |
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 Call-ID: 2345@terminal.example.com Content-Length: 0
Relation todraft-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
Our Case: Ad-hoc Resource Lists using SUBSCRIBE Classification: • B2BUA • “Uninvolved exploders” • Inside a dialog
Our Case: Ad-hoc Resource Lists using SUBSCRIBE • It is an Excellent Study Case • Longtime identified requirements • Technically straightforward • No new security risks
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!
Points for Further Discussionon 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?