Notes, SIPPING Session 1, IETF 61

Reported by Ben Campbell, Official Recorder


Announced: SBC Meeting 7-9 pm tuesday in Hemisphere

Agenda presented and not bashed.

Draft Status:

published 3824 and 3842
early media and early-session desc in edit queue
3gpp R5 req, qsig to sip, transcoding via 3pcc, reason header to IESG

Lots of last calls.

Proposed milestone changes--see chair slides

Issue: Some of the drafts (URI list work?) targeted for march are nearly ready. Why moving the milestones to march?
resolution: No penalty for early completion. Don't want to submit URI drafts is consent-framework still has issues. Don't want to overload wg on last calls. May wglc uri drafts prior to consent-framework.

Microphone problems...

Issue: How more times will this change? Location-req document now includes solution. Will this be an issue.
resolution: floggings will continue until morale improves.

Issue: Conferring stuff needs to be done sooner--critical 3gpp dependencies.

Keith: Conf requirements doc may no longer be a direct 3gpp dependency. Framework document primarily used for terminology. Not absolutely required, but nice to have. need cc-conference and conference package. (conf package missing, should be in january bundle.)

resolution: WGLC had considerable comments. Cannot commit to more agressive dates, unless wg is wishes to do so.

----Config Framework (Dan Petrie presenting)

Issue: General mechanism to allow UA to specify optional capabilities was requested, but not added. Proposed: Not absolutely necessary, can we push this off to future?

Resolution: No objection.

Issue: Is event header the proper place for parameters, rather than body?
Resolution: Leave as is? (Not clearly stated, but no one agreed to change anything.)

Plan to release new revision right after black out.
Ready to wglc, will be delayed until current batch of wglc expires.

-------Profile Datasets (still Dan)

technical problem with slides...

No recent changes

Issue: Complexity of specifying constraints vs. simplicity of parsing. Elements to contain properties vs attribute on property to express constraints. Elements require clients to have full xml parser--hard for low end devices. Attributes are simpler to parse but less expressive.

Some issues with constraint complexity itself, not just syntax. Merging hard for low end devices? Multi-variable constraint problems?

Need to work through some use cases, define specific profile data sets in other drafts.

resolution: work out reqs and use cases, keep it simple as possible.

Need some form of merging, but may not be as complex as some alternatives.

--------session independent policies (presenter name? volker?)

Presented slides...

Issue: Schema structure for constraints. Current draft based on xml containers (as in the profile data sets)
Proposal: Move to attribute based approach, values (mandatory, allow, deny).

Issue: handling default policies
Proposal: default policies for element in another element.

Issue: Conflict resolution. General mechanism out of scope.
Propose: specific rules in a policy schema. default behavior for unresolvable conflicts. special treatment emergency calls?

No significant discussion on the proposals--will be followed if their is no objection. (On list?)

-------session specific policies

Issue: when should policy server be contacted by user agent? (Offer, answer, bye?)
Proposal: PS provide indication on policy channel. Offer cycle mandatory. Flag for "answer-required". PS closes policy channel when done.

discussion about whether user agent needs to tell policy server about bye, but it may need to terminate channel. UAs provide info when it needs to get back an answer.

Issue: Cross domain stuff. One domain trying to control policy in another domain without some sort of authorization.

resolution: There is no communication between policy servers.

Comment (not sure if this is a conclusion): Policies should tell UA about things to use or avoid, but not detail things like specifying particular pinholes.

Issue: What is policy channel implementation?
proposal: policy channel is sub/not, offer/answer needs to be carried in subscribe/notify bodies.
resolution: No objections.

---------------------SIP URI-List services (aka exploder, Gonzalo)

Issue: What do you do with duplicate entries in a list?
Proposal: treat as single entry.
resolution: No objection, but need to specify how to compare. If the URIs compare the same based on the rules of the URI scheme.

Issue: Can a subsequent subscribe update a list? Options (1)yes, or (2)no (must not send, must ignore if received, new subscription required for update)
Proposal: (2)
Resolution: 2, but allow extensions to change it.

Issue: any 3pcc issues?
resolution: think about it.

Question: Will URI-List follow consent framework?
Answer: Text says you must address issues, consent-framework is one way to address them.
Resolution: consent-framework MUST implement, but other methods can be _used_. Will clarify text.

Issue: Overloading use of list to both drive exploder and render list to recipient.
Resolution: Different content type for rendering list to recipient. Will clarify in doc if needed.

------------------------Consent Framework (Gonzalo)

New req: UA should be able to figure out what server granted consent, and any credentials needed to revoke consent.

Issue: XCAP used to upload permissions. Other options? Usually binary yes/no decisions. Is xcap too heavy
Resolution: Must have something as mandatory to implement, but other mechanisms can be used. Need to explore whether we can come up with an xcap scheme simple enough for low-end clients.

Issue: Want to upload permission document preemptively at registration time, rather than waiting for someone to try to communicate.
resolution: take to list.

----------------------------- Transfer (Alan Johnston)

New draft demonstrate refers outside of dialog. Suggests grid parameter for correlation.
Issue: grid doesn't work.
Proposals: add parameters for correlation, or just go back to in-dialog refer and fix it later.

Comments: Do we need a general mechanism for dialog context correlation?

Resolution: will try to keep refers outside of dialog. We need a general dialog correlation solution for multiple uses.

Plan: resolve out-of-band- dialog refer issue, then WGLC.

-------------------------------End-to-Middle Security (could not understand name)

Requirements:

draft in WGLC until Nov 20. Feedback requested.

Mechanism:

Issue: How do you label the target body for middle?

options: A) use sip header, b) MIME header.

A1) New SIP header
A2) Parameter in an existing header
B1) new mime header
B2) New parameter in MIME header.

Presenter proposed A1.

Issue: new error codes? 493 can be used if proxy cannot view body. Need code for when the proxy wants integrity protection (i.e. 495 signature required?)

Issue: WG item?
Resolution: Should go to SIP instead of SIPPING. Consensus to ask AD to add to SIP.

Chair Comment: list participation light--please go look at this and give feedback.

---------------------------Caller Prefs Use Cases (Paul K.)
draft-ietf-sipping-callerprefs-usecases-03

Several changes. biggest change adding implemetation guidance for matching algorithm.

Issue: Algorithm simplification requires scrutiny.
Resolution: Call for volunteers--see chairs.

Proposal: wglc?
Resolution: wglc after current wglc backlog, volunteers for detailed review.

----------------------------Reg Event Package Extensions (Paul K)

some reg-event applications break when gruu is used because retuirned contract is not addressable.

Minor changes and clarifications since last version.

Issue: wg item? If so, does it stand alone or merge into GRUU draft?
Resolution: Don't mess with GRUU (No clear consensus.)

Question: Should this extension be a wglc item?

Resolution: will explore pursuing this as an informational.

------------------------------Sipping Conf Framework (Jonathan)

Issue: How does this relate to xcon framework document? There is significant scope overlap.

Lots of discussion on all sides. Jonathan volunteers to send a concrete proposal on delineating between docs.

Resolution: Chair and AD discussion to sort things out.