1. SIP Events: Changes and Open Issues IETF 50 / SIP Working Group Adam Roach adam.roach@ericsson.com

2. Excuses I intended to release a new events draft for this meeting… …but I had more important deliverables.

3. State Agents (née “Event Agents”) n Generalization of a “presence agent”. n May be aggregation points for state and/or surrogates for offline clients. n Base draft will describe migration of subscriptions from state agents to endpoints. n Package drafts will be required to define semantics (if any) for migration.

4. Out-of-band Subscriptions (aka “Unsolicited Notifications”) n Any subscription initiated by mechanism other than “SUBSCRIBE” method. n Discussion will be reduced to single sentence explicitly allowing them. (e.g. “Subscriptions may be created via mechanisms other than a SUBSCRIBE request.”) n Raises need for clarification: 481 responses to NOTIFY MUST remove all subscriptions, even those provisioned out-of-band.

5. PINT Backwards Compatibility n Addressed in current draft: no event header => PINT semantics. n No open issues. n Speak now or forever hold your peace.

6. Throttling of events n Consensus from interim meeting: each package will define a throttling mechanism appropriate to its specific events. n Next draft will remove this from “open issues” section. n Next draft will include requirement that packages include a discussion of notification throttling.

7. Instant Notification n A delay in the initial NOTIFY might otherwise convey additional information (e.g. user online, subscription manually rejected, etc). n Need to clarify that a NOTIFY with a default (innocuous) state will be sent immediately.

8. Authorization Issues (still open) n We need a general-purpose mechanism by which subscription authorization may be performed in a way which allows user interaction. n Is generalization of QAUTH the way to go, or should we use a notification of subscription attempt which can then result in a manual update of policy? n Proposal: subscription authorization issues will be handled in a separate draft. (Volunteers?)

9. SUBSCRIBE Response Codes (vaguely open) n 202 is noncommital: “wait for a NOTIFY” (which contains an “Expires: 0” if you’ve been rejected). n Is it allowable to return a “403” or “603” to mean “no way, bubba -- it just ain’t gonna happen; don’t even wait for a NOTIFY”? n Conversely, is it allowable to return a “200” to say “your subscription is 100% guaranteed to have been accepted, and I will send you a valid, successful NOTIFY post haste”?

10. Denial of Service Concerns (still open) n One SUBSCRIBE in, several SUBSCRIBE replies and several NOTIFY requests out is a recipe for disaster. n Proposed solution: keep no state for unauthenticated SUBSCRIBE messages. n Can be strengthened by allowing each userid/password combination to have only one pending SUBSCRIBE in each node. (Is this reasonable and viable?)

11. Forking (brace yourself) n Much discussion at interim meeting, but no conclusion. n Main sticking point seems to be concern that accepting multiple NOTIFY messages will disrupt route setups, since route setup will occur in SUBSCRIBE responses, and only one SUBSCRIBE response will be returned to subscriber.

12. Forking: Problem Diagram Subscriber Forking Proxy Notifier B Notifier A Subscription Stateful proxy 1 2 3 4 5 6 7 8 12 13 10 11 9 14 1. SUBSCRIBE 2. Request is forked to Notifier A (via proxy)… 3. … and to notifier B 4. Proxy record-routes and sends to notifier A… 5. …and notifier B sends a 202 response 6. Notifier A replies (202)... 7. …notifer B sends NOTIFY... 8. …and the proxy sends B’s 202 on. 9. The stateful proxy forwards A’s 202... 10. …notifier A sends a NOTIFY… 11. …and the subscriber replies (200) to B’s NOTIFY 12. The stateful proxy sends A’s NOTIFY to the subscriber 13. This is where the problem occurs: how do we reply? If we accept, refreshes might not go through the stateful proxy, since the subscriber never saw A’s 202 response to the SUBSCRIBE request. 14. The stateful proxy forwards the subscriber’s NOTIFY response.

13. Forking: Solution 1 Subscriber Forking Proxy Notifier B Notifier A Subscription Stateful proxy 1 2 3 4 5 6 7 8 12 13 10 11 9 14 Send a 481 for message 13 (NOTIFY reply), since message 8 (SUBSCRIBE 202) is on a different leg. Issue: message 7 (NOTIFY) can arrive before message 8 (SUBSCRIBE 202); we must wait before responding.

14. Forking: Solution 2 Subscriber Forking Proxy Notifier B Notifier A Subscription Stateful proxy 1 2 3 4 5 6 7 8 12 13 10 11 9 14 Send a 200 for message 13 (NOTIFY reply), and accept both subscriptions. I believe that we can count on the stateful proxy to include a “Record-Route” header in message 12 (NOTIFY), since the bis draft says it SHOULD. This will allow the subscriber to route refreshes.

15. What? “ 6.35.1 Operation The Record-Route request and response header field is added to a request by any proxy that insists on being in the path of subsequent requests for the same call leg. A proxy SHOULD add it to any request for robustness, but a request route, once established, persists until the end of the call leg, regardless of whether the Record-Route header is present in subsequent requests.” The Record-Route request and response header field is added to a request by any proxy that insists on being in the path of subsequent requests for the same call leg. A proxy SHOULD add it to any request for robustness, but a request route, once established, persists until the end of the call leg, regardless of whether the Record-Route header is present in subsequent requests.”

16. Forking Proposal n Allow subscribers to implement solution 1 or 2 according to preference and situation. n Event packages will be encouraged to specify a mode that makes the most sense for the state they convey. n Draft will strengthen “SHOULD” to “MUST” for proxies which intend to track subscription states.

17. Minor Changes n Next version will probably be “draft-ietf-sip- events-00.txt” (pending new WG charter). n To/From Tag usage will be clarified. n A-D suggestions –For greater visibility, move notice of “not a general purpose event subscription mechanism” into Abstract. –Strengthen section about “appropriate” applications: generally, those that rely on SIP user/terminal location. –Possibly create template for extension packages.

18. Event Mailing List n Moving off of Yahoo! Groups (they require too much personal information). n Announcement of new events mailing list will be made on the SIP mailing list Real Soon Now. n Presence should be discussed on the SIMPLE list; general event topics, on the events list.