SIPPING Session 1 Chairs: Gonzalo Camarillo, Mary Barnes Recorders: Dean Willis, Spencer Dawkins Note; Np slides were posted to IETF Meeting Materials site as of the ; start of the meeting. Therefore, URLS to slides presented are ; not included in these notes by the recorder. Topic: Status and Agenda by Chairs Slides presented Chairs announce change in tools usage, including new WGLC tracking spreadsheet. Proposed updated charter reviewed. Agenda discussed and agreed as presented. RFCs published or agreed, and other work status, since last meeting reviewed. Topic: Config Framework by Dan Petrie Slides presented Changes since last meeting reviewed. Config framework split into two pieces -- xcap dependent and not xcap-dependent. Question: Is there any restriction on the usage of the new HTTP header Event statement? It seems to be just an event name, not a mechanism for subscribing to the document. Questioner had hoped it would provide a subscription hook. Issue: filters on event packages Question on changes: Are there two different event package names for 489 profile type rejections. This may be inconsistent with the normal usage of 489 in sip-events (noted by Adam Roach, sip-events editor). Noted that this "filter model" suggests that that 489 is inappropriate (the event type actually IS supported, contrary to the indication of 489), and we need some new kind of response to accommodate a filter disagreement. This will probably require a new response method and a header field. Jonathan suggests a"4xx something, bad filter, allowed filter, set of tokens". Open issue: Proposed multicast discovery technique. Does this need to be in this document, or is it appropriate for another draft? Chairs noted that we should avoid delays to this draft. Suggested from floor that if the text is "done" it can be included. Author noted that additional research is needed to finish the material. Also noted that P2PSIP has an overlap with multicast discovery. It may be appropriate to do it separately and align with or reuse multicast discovery from p2psip. Noted that given our history of delays, we just need to get this over with. Open Issue: With respect to the "network-user" parameter, what level of requirement should we have that the event server should authenticate the subscriber and verify the resource identifier in the "network-user" parameter? Noted that "SHOULD" is topical -- if it has clear guidance on why, and what happens if you don't, this might be adequate. Suggested that we split the current text into two clauses, such that one could be compliant with either the first or the second clause in any mode of operation. Noted that a simple SHOULD may not give the sort of guidance needed to phone implementors. Apparent consensus noted on this proposal. Open Issue: Do we need a mechanism to confirm that a device has applied a new profile it has received (note that we have a mechanism to confirm receipt). Noted that this has never been raised as a requirement before and should be clearly separable. Question: Did someone raise this as a problem? Martin Dolly reports that this really applies to the operator managing the device and wanting to know what profile a device is currently running, especially around a profile change. Noted that this feels much more like a management function, for which there is a separate body of work, and this is probably a part of that. Poll: Would anybody feel unhappy about just fixing the 489 and the MUST/SHOULD question as noted earlier, then proceeding with WGLC? There seems to be a consensus on this approach. Topic: Consent by Gonzalo Camarillo Slides presented Architectural model and changes since last rev reviewed. Question: Are new MIME parts optional? Answer: yes. Question: In the past, we have argued that MESSAGE is only to be rendered to a user, and we have it being consumed here by a server. Is this ok? Discussion followed -- the MESSAGE here has two parts, one renderable, one for an automata. Noted: This is a philosophical argument, but it does potentially change the precedent. Noted also that this requires a store-and-forward handler for MESSAGE, which is not assured. Noted also that the second body part is rendered by the automata to the user, so this may be less onerous than suggested. Open issue: How to obtain the URI to subscribe ti the "pending additions" event package? Comment: 3 cases, URI-list server, request contained, and a registrar models. In all cases, there is a SIP URI for the relay. So the proposal (from slides) is consistent with related usage. Noted that 403 response should be changed to 409, not 408 as suggested in slides. Question: Does the store-and-forward service still pre-cache permissions? If I change service providers, do I need to rebuild my permissions set? Discussion followed, and in general, no. The mechanism for adding a new 409 body element for extending resource usage was raised. We don't feel we need to discuss this with SIMPLE. Noted that we will need formal reviewers for this draft. Poll: How many read the draft: A fairly large number. Poll: Do these changes make the document simple enough to deal with? Seem to have strong consensus that the current level of simplification is adequate. Open issue: From which WG do we advance this? By RFC 3427, it probably goes from SIP. Topic: Session Policy Framework by Volker Hilt Slides presented. Changes since last meeting reviewed. All open issues believed closed by author. Author requests additional review. Open issue: whether to use body of SUBSCRIBE or something else. A similar thing is used in call control. and we should consider alignment. Noted that this is a slippery slope and will set a precedent. Discussion followed. Poll How many people have read this document: Only 4 or 5. Noted that RFC 3427 appears to require this document advance through SIP. Topic: Policy Package by Volker Hilt Slides presented Open issue 1: Body format for SUBSCRIBE/NOTIFY? Proposal 2 suggested on slides. Discussion followed. If we allow providing a subset of SDP in markup, is this determined out of band ahead of time? The draft would specify this ahead of time. Seems to be general consensus on this approach. Reviewers called for. Alan H. volunteered. Topic: Dialog Usages by Robert Sparks Slides presented Changes since last rev reviewed. Open issue on all messages in a single shared dialog in reliable provisional. Much discussion followed Paul Kyzivat restated the error case clearly but the recorder was unable to capture it (something about re-invite that fails). Requested that whether we choose to solve or not solve this sort of problem, we record this choice in the resulting informational draft. Much confusion ensued. Perhaps we should document something like "just don't get into these use cases". Noted that this can actually happen in cases like a desktop application that takes first part of a call then slings it off to a UA (with PRACK and UPDATE, eek), which occurs "in the wild". Proposed that we suggest not using reliable provisional responses in a re-invite -- just use update with preconditions. There appear to be 3GPP2 call flows that violate this guidance. Noted that some re-invite cases do NOT proceed immediately, as there may be user involvement. This does lead to reliable provisionals. Next step: build a list of normative changes needed, and work on executing them. as a single document (or whatever process SIP comes up with). Question: Do we have guidance for new error codes, making sure that we discuss the error code's impact on dialog usage. This MAY be in the guidelines RFC. Topic: Migration of Communications Services to SIP (MIGBOF) by Martin Dolly Slides Presented Noted that development of P-headers by another group is worrisome. Noted that we've already had the "SIPPING 16 effect" and we run the risk of convincing the outside world that only services with a BCP exist. Noted that if we don't spin out a new WG here, we continue to have half-focued efforts with a large pool of disinterested parties. Noted that this raises the whole question of "Service Packages" and whether or not one can make things work without rigourous definitions thereof. Noted that this also raises questions about the SIP Guidelines and SIP Change Process and whether the extension mechanism and model as described therein is appropriate. Much discussion of "P-header" approach followed. Noted that any P-Headers should be reviewed in SIPPING as usual. Noted several times that we really should focus on NOT doing P-Headers. Noted that BOF procedures are likely to be changed. Topic: Issue Trackers Proposed that the easiest way to do this is to mandate the authors manage their issues in whatever tracker we use.