SIPCORE, 81st IETF, Québec, QC, Canada

Status and Agenda

Agenda accepted as proposed. Status presented as shown in slides.

Keith Drage requested that the chairs take care to use the new draft tracker tool to track the status of workig group items.

Error corrections and clarifications to RFC3265

Document updated per detailed review on mailing list by Christer Holmberg (details in slides)

Robert Sparks spoke in support of event parameter uniqueness clarification, indicating that the change was not just better for IANA, but actually makes implementation simpler.

All other proposed changes accepted without comment.

Keith Drage asked the chairs why the document state isn't yet in the draft tracker tool. Adam (as chair) indicated that the tool is still somewhat cumbersome to use at the moment.

Adam Roach indicated that the document is ready for last call, and solicited opinions to the contrary.

Delivering request-URI and parameters to UAS via proxy

Issue 1: Semantics of "rc" Parameter

Room discussion indicated that the document needs clarification regarding how severs know that a redirection necessarily pertains to the same user.

Issue 2: "tel:" URL Handling

Document needs additional text to indicate how the History-Info mechanism interacts with "tel:" URLs.

Christer Holmberg offered to supply text that addresses this situation.

Issue 3: Index Values Following a Missing Entry

Participants in the room generally agreed with proposal on the slide (i.e., use "0" to indicate a missing entry).

Issue 4: Document Structure

Issue (from slides): "draft-ietf-sipcore-rfc4244bis-05 has no normative text surrounding its use in specific applications."

In summary, Cullen wants to see normative text for at least one useful use case. He also asserts that the first security requirement and the privacy requirements are not satified, and suggests that they should be removed from the document. Conversation to continue on-list.

Detailed conversation points follow.

Cullen Jennings: This document does not meet the requirements _in_this_document_

Adam Roach: Those were present in 4244, and we are not chartered for general work on 4244 -- only those that pertain to delivering UA parameters.

Cullen: Like to see how to normatively specify something reasonably to do (e.g., get to the right voice mailbox)

Mary: these documents

Cullen (objecting): need to put the how-to text normatively

Adam: Do you believe the procedure is adequately described in the callflows document?

Cullen: I believe that if it were described adequately, you would find that it couldn’t be done.

Dale Worley: I believe that the algorithms in section 11 are incorrect. I sent specific comments, but no one has commented on them. Whether normative or not (don’t care), but do care that all of the pieces of it are included.

Cullen: I'm not saying that the previous document met security & privacy concerns. We don’t meet the first security requirement we don’t meet the privacy requirement. Just was to not be wishy-washy on this.

Hadriel: I agree (w/Cullen), also why bring this up now, and not on the mailing list?

Cullen: I have brought it up before (may have been 5 yrs ago). I want this draft to show the things that this draft is useful for. Just an algorithm that could be implemented by an implementor and once done, that would result in interoperable systems. That there is enough text there that an implementer could read and effectively implement.

Mary: We have that text in the examples – maybe not detailed enough. You want the text put into the main draft – don’t care about the call flows (they should probably remain in a separate document).

Cullen: I think it’s extremely unwise that you send a document to Last Call containing requirements that there’s no way that it could meet.

Adam: Cullen, please summarize your specific issues on the list, so that we can have a meaningful discussion around this.

Cullen to summarize his outstanding issues on the mailing list.

Requirements for a mechanism to indicate proxy capabilities

Main points under discussion are REQ-4 and REQ-9.

Robert Sparks: Proposed re-wording of REQ-4 (see slides) gives it a different meaning. Both might need to be present as two separate requirements.

Cullen Jennings: Would like a requirement regarding feature allocation policy. Also, would like to remove parameters from feature indication (basically, make it like options tags).

Andrew Allen: Curious about the structure of REQ-9, since that's not the way things work today.

Christer: We're talking about something that parallels the use of options tags, which don't indicate activation.

Robert: This is why we wanted to discuss requirements instead of mechanism.

Adam: Indication of feature activation is not something we agreed to take on as a working group item.

Andrew: I want something that indicates, for example "I've forked." Maybe this really belongs in History-Info.

Christer: I think we should try to keep that separate from the currently agreed-to scope.

Adam: If we do work on indication of feature activation, that would be a different work effort, and we would need to add another milestone for it.

Andrew (new topic): Right now, the document is all IMS use cases. I think I have some others we can include, such as those involving the PSTN.

Christer, Dale, Dave, and Andrew to work through additional use cases and bring them to the working group.