|Date:||Tuesday, 15-Nov-2011, 1710-1810|
|Chairs:||Adam Roach, Paul Kyzivat|
Agenda accepted as proposed. Status presented as shown in slides.
Robert Sparks: Asked about difference between REQ-8 and REQ-9
Christer Holmberg: Not sure - will clarify with Dale
Robert Sparks: REQ-10 should be that the indications must be visible.
Robert Sparks: REQ-8 needs to be rewritten to be on the mechanism, not on existing entities
Robert Sparks: REQ-13 should say need to avoid collisions of names
Chairs asked who had read the document
Chairs asked if anyone thought more requirements were needed
Hadriel Kaplan: What about users of this mechanism
Cullen Jennings: document doesn't say what is this going to be used for, and how could it be used?
Robert as individual: one use case is useful, the other one is opaque
Robert Sparks: is there a significant architectural impact of this extension? Still vague even after working on requirements. Answer affects whether it needs to be done in SIPCORE or just anywhere. Question: is reasonable use to indicate Energy Star compliance?
Christer Holmberg: OK if doesn't affect session at all
Robert Sparks: Is this stated clearly in requirements?
Christer Holmberg: REQ-8 and REQ-9 do this.
Hadriel Kaplan: Could just state this in draft
Cullen Jennings: Not sure you really want this in all use cases. How to decide on uses
Hadriel Kaplan: Could have expert review on uses
Gonzalo Camarillo: Superset or subset of existing feature tags?
Christer Holmberg: Only new feature tags, not existing ones
Robert Sparks: Which requirement rules out History-Info as the mechanism
Christer Holmberg: Direction usage requirement makes History-Info difficult. Also can't use in REGISTER
Mary Barnes: History-Info can be used in REGISTER
Hadriel Kaplan: History-Info can be inserted by elements that can not use this mechanism since they not in the dialog
Cullen Jennings: Is that in requirement?
Hadriel Kaplan: We could add this requirement to say session stateful or B2BUA only use this mechanism
Christer Holmberg: Could say elements using this mechanism must Record-Route
Robert Sparks: Sounds like a requirement on the mechanism
Chairs: Any objections to this new requirement?
New requirement will be added to the document to reflect this agreement.
Chairs: We can now move onto the mechanism and move this doc to WGLC
Cullen Jennings: Don't call all non-UAs B2BUAs
Cullen Jennings: These aren't feature tags so create new IANA registry. Need better guidelines on how and when they are used, or need IETF consensus expert review
Robert Sparks: Agree with Cullen. Which working group should work on this? Does it need architectural review by SIPCORE?
Christer Holmberg: Registry must reference spec that says what the feature means
Hadriel Kaplan: We need expert review. Hard to decide if Energy Star example is valid
Cullen Jennings: Hard to write expert review text. This approach might evolve.
Jon Peterson: Worried about interoperability. Need conservative registration process
Adam Roach as individual: How does this work if UAs understand tags? Will behavior change?
Christer Holmberg: Can include option tags in feature tags
Hadriel Kaplan: Example of switching handoff feature.
Robert Sparks: Example of intermediary storing dialog state, allowing UA to subscribe to get this information. Is this valid?
Christer Holmberg: This is a valid use case. It doesn't change the existing dialog.
Jon Peterson: This doesn't relate to SIP option tags since intermediaries and proxies cannot do this.
Cullen Jennings: Another SDO could use these feature caps to circumvent IETF option tag processes. What prevents this?
Robert Sparks: Can tags be parameterized or include a URI?
Christer Holmberg: If URI is needed, then a URI parameter would be used
Hadriel Kaplan: Expert review could solve this.