SIPCORE, 77th IETF Anaheim, CA, USA

Status and Agenda

No agenda changes

Work item overview - went through items one by one.

199: Token with document author.

Location conveyance

re-invite: Token SIPCORE chairs; WGLC finished.

invite fix: WGLC done; token SIPCORE chairs.

example security flows: token document authors. should be done by mid summer.

keep-alives: token with WG. Nothing has happened this year. Do we feel it is important?

Christer: technical issues identified. not done yet. I have not had he time to do anything since info stuff has taken up a lot of time. 3GPP has interest in it. did send a new version to keep expired one alive. Will send a new version in the near future. Some things need to be discussed and will raise on the list.

Christer will raise issues to list and resolve, then issue a new version, which should be appropriate for a WGLC

sip events rate control: token SIPCORE chairs.

presence scaling requirements: token IESG/simple WG.

Chairs recognized Cullen Jennings for his RAI AD service.

History-Info Header Field.

Went through the slides. Doc ready for WGLC.

Since ietf 76: editorial changes, name change to reflect WG adoption. Redirect server behavior fix: redirect server adds new URI param and removed text that said redirect server adds HI. URI param removed as HI is added.

<Discussion ensued in how to best implement services and how a protocol should support primitives to allow the multi-vendor systems to interoperate and whether normative text is appropriate in informational documents.>

Cullen: looking for normative text, still seems to have problems - want to know what to do. Alternatives are bad

Mary: configure your system for one or the other

Cullen: that doesn't help

Mary: maybe we need BCP

Cullen: need normative text that is unambiguous, applies to all examples, not just VM. Need to be able to build interoperable systems

Mary: depends on the characteristics of the systems involved

Cullen: not convinced this solves a useful problem

John E: where is the policy? How does VM know which entry to look for to apply policy?

Mary: we will add more text. Can't be normative, only recommendations

Cullen: why not?

Spencer: are we saying we should or shouldn't have normative text, or is it possible or not to specify normative text

Mary: it's a "should we" in my opinion

Chairs: drive this issue to conclusion on list

The document is nearly ready for WGLC. Need list discussion on, among other things, normative statements around specific services.

RjS: When reviewing this, please invent new test scenarios to put stress on this at the next SIPit.

Adam: seems to be at least one issue to reach consensus on. Need to close this before going to WGLC.

rfc3265bis: SIP events redux

Went through changes from -00.

Open issues

202: Adam has posted text he intends to incorporate based on interop issues seen at SIPit. Make sure people read the text and send email if disagree.

allow-events and templates: not advertised, endpoints may probe.

Keith: what is fundamentally broken for interoperability? That is what this draft should cover.

Adam: don't know what is actually implemented

Robert: they are probing

Adam: should not be nebulous

Robert: should not just "academically" change and strand existing implementations

Adam: agree, think we did that

Timer N and re-subscribe messages: proposal for clarifying text presented on mailing list, will be incorporated into document.

All three issues will be resolved as proposed on mailing list unless objections are raised.

Protocol and Document Improvements

Clarify handling of Route/Record-Route in NOTIFY

Eliminate Implicit Subscriptions (REFER grandfathered in)

Deprecated Dialog Re-use. Notifiers use GRUUs for local target. Text for using Target-Dialog.

Paul K: What does this do to backwards compatibility?

Adam: it's in there

Robert: Look through implementations to see if dialog re-use is used for a different kind of subscription. Don't think there are any. Report if you find one

Christer: what about REFER? Dialog reuse of REFER initiated subscriptions

Adam: Not allowed

Robert: Be careful with what you say - can't outlaw existing implementations

Adam: yes, 3265 compliant implementations work with -bis implementations

Robert: means new implementations of Transfer need out of dialog subscription

Rationalized Dialog Creation: Dialog created when NOTIFY arrives, rather than when 200 occurs.

Christer: okay, but what about REFER? When is the dialog created?

Adam: good question. Need to analyze.

Paul: no refer sub wouldn't work otherwise

Hadriel: What does this mean - for a B2BUA for example

Robert: long hallway conversation needed

Adam: probably no or little changes

Refactor Behavior Sections

Clarified sections that need to be present in event packages

Make CANCEL handling more explicit

Remove "State Agent" terminology

Resolution of reported bugs

Unless there are objections on the list, the draft will go into WGLC with these changes.

SIP Table 2 / 3

Table 2 / 3 summarize what fields must, must not and may appear in a given SIP request or response. as new methods and header fields were added, this table was updated rather haphazardly. ended up with a lot of gaps.

Two ways to clean this up:

1) come up with a complete table 2 and update IANA procedures for registering new header fields and new methods to require completion to table 2.

2) issue a document that updates rfc3261 for the purpose of deprecating table 2.

Creating a unified table will be complex: at least 144 rows, with 14 methods each.

Keith: No one understands from the table the purpose of what Mandatory, Optional means. RFCs ought to be explicit.

Adam: agree that prose has to be there and be correct. Do we need the table?

Robert: Table 2 causes damage, get rid of it. Could have a registry, but would it be normative, and how do we handle documents from other SDOs? Document pointers are already there from the name of the header.

Christer: if we don't have a registry, we keep the problem we have

Robert: I propose we don't have a table 2 at all, just use the prose

Adam: if we did do a registry, it would be very complex for IANA to maintain

John E: agree need to do something, agree that IANA registry would be too complex. But there are things that are in Table 2 that are NOT in text.

Dale: The table is of no value and should be disposed of. The structure of the table hides more complex actual implementation issues.

Paul: Been persuaded of the impracticality of IANA registry. Deprecating has issues where the table 2 entry is the only normative statement. Will need to be careful in work going forward to make sure prose is explicit.

Mary: Table isn't useful. Believe new work beyond 3261 has explicit prose

Christer: if we do this, we have to verify that we have the normative text. No need to decide how to do this. Maybe need a "design team".

Spencer: While I liked them when I first read them, I have seen the error of my ways

Keith: "Support" part is not in prose often. Not as confident that the prose is there. Deprecating Table 2 would mean normative changes to all other documents

Jon P: don't need to deprecate. Just not do it going forward

Gonzalo: agree, don't have to deprecate, just stop adding new "entries"

Chairs to formulate potential options for path forward; poll for consensus among viable options.

SIP Table 2 / 3, Continued

Chairs call for consensus between two options: (1) Produce an artifact stating that documents defining new header fields and methods define semantics in prose, and will no longer extend Table 2, or (2) Produce an RFC that defines new procedures for adding elements to Table 2 as new header fields and methods are defined

Discussion about the form to be used if we publish item 2:

Adam: we're not defining this yet.

Keith Drage: what will be the form for item 2 -- webpage?

Adam: It wouldn't be the webpage I put up.

Jonathan Lennox: can we write a document that says that table 2 is no longer normative?

Adam: We're not deciding that yet.

Further discussion of the nature of the options:

James Polk: asking for clarification - does this affect anything that is already published?

Adam Roach: Let's just work out what we do with new stuff or stuff we're working on right now "in flight" work. Updating past work is separable.

Robert Sparks: second option is to provide better guidance for the creation of table 2 extensions

Jonathan Lennox: Do people want to update all the old documents? Feeling seemed to be no but out of scope.

Gonzalo Camarillo: we don't need a framework for all rfcs, don't need anything that is thorough

Adam Roach: agree

Strong consensus in room to support option (1).

Gonzalo: let's make sure that we don't just go update things for completeness - address when there are real (e.g., interop problems)

The SIP OPTIONS Method

OPTIONS Response Codes

Should a UA interpret an options request as an invite to the point that an existing call causes an options request to be rejected?

John Elwell: let's have a more general discussion - do we want to spend time on addressing problems with options, or should we restrict its usage?

Christer Holmberg: we should look at the problems

Joe Hildebrand: An alternative way to do options would be to use http://xmpp.org/extensions/xep-0115.html -- This allows you to send around lists of features. If we decide to go down that path, this group should coordinate with xmpp WG.

Christer Holmberg: We should consider this if we decide to do anything

Adam Roach: agree with John E. - we need to have a meta discussion about whether this is work we want to do before we dive into details. But, other aspects of options are dependent on call state.

Christer Holmberg: is this based on your current state - or is this more general. need to get an answer for implementers. we don't have to solve these, but we should look at whether we should

In-dialog OPTIONS with no matching dialog

If the OPTIONS request contains a TO tag, but no associated dialog exists, procs seem to allow both 481 and 200 responses and even cause dialog to be recreated.

Q: Do we need to clarify behavior?

Proposal: If dialog does not exist, return a 481.

Keith Drage: 481 is rejecting the request as though it were another method, not providing the desired info. there is flexibility here, if you want to respond with 200

Christer Holmberg: are you talking about ignoring the TO tag?

Keith Drage: no, this refers to the previous slide and discussion

Robert Sparks: Keith isn't arguing against this case. There is nothing special about OPTIONS

Brett Tate: Lack of clarity (ie. not requiring 481)

Robert Sparks: RFC 5057 implications might have to be considered

Adam Roach (Chair): Let's not focus so much on the details of the solution. We need to figure out whether this is worth spending time on before we spend too much time on it.

Use of "Accept-Contact"

Problem: Accept-contact. 3841 states that a request can be rejected if UAS doesn't support feature tags in Accept-contact

Forking Problems

[refer to slides for details of problems]

Robert Sparks: (on forking and multiple 200 responses) bad idea

Cullen Jennings: there was agreement that this was a bad idea (this being the header to indicate multiple 200 would be returned)

Meta-Discussion: Should SIPCORE work on OPTIONS?

Adam Roach: wants to discuss whether the problems are worth solving, not to discuss the specific proposals presented

Christer Holmberg: presents alternatives slide

Adam Roach: this is a little too specific - we need to determine whether it's worth trying to find solutions

John Elwell: can't decide on options presented; if we do produce a BCP, try to keep it simple because options is not necessarily reliable

Cullen Jennings: it will be impossible to get consensus on these sorts of issues, strongly favors the "do nothing" approach

James Polk: do enough people need interoperable solutions for these problems? This could be complex

Christer Holmberg: for instance, a TO tag could recreate a dialog

James Polk: disagree

Adam Roach: 2543 might have had that, but 3261 doesn't

Hadriel Kaplan: agree with James Polk, there are interoperability problems, but these aren't them. Some of these are features instead, which have backwards compatibility problems. Favors option 1

Christer Holmberg: if we choose option 1, is the 3xx response allowed

Hadriel Kaplan: I'm not sure what would happen if a UA received a 3xx response to OPTIONS...you need negotiation, this this is a new feature

Christer Holmberg: agrees this is distinct from other "problems"

Brett Tate: doesn't think that this is useful to capture the information that preconditions could

Christer Holmberg: Agree - you need something else if you want to do beyond what OPTIONS does.

Brett Tate: not necessarily going to be routed in the same way that an INVITE would

Christer Holmberg: could use contacts, GRUUs, ...

Adam Roach: we're back to discussing fiddly bits - need to discuss meta issue.

Postscripts

Robert Sparks: taking group down rathole about the use of BCP - it's abused. Go read RFC 2026

Keith Drage: wants to see I-D before we discuss this again

Chairs to take issue to list, call for consensus on mailing list

Draft-sipcore-location-conveyance

Proposing to simplfy: there's been a gradual accumulation of parmeters, error codes, etc. The proposed reduction would reduce scope to cover only necessary cases, and improve predictability from the perspective of the UA.

Important use case: Proxies asserting location

The crux of the proposal is to allow proxies to add to or replace PIDF-LO bodies by sending new bodies back to UA in a 424 response. UAs would then re-issue the request with the new PIDF-LO body. All the parameters, etc. on who added what can be included in PIDF-LO, thus architectural separation from SIP.

If we do this, there is no need for "used-for-routing", "inserted-by", etc. [Refer to slides for details]

James Winterbottom: there are use cases in NENA where you need both location by value and location by reference, this is particularly useful for mobile use cases where the value is used for routing and the reference is used for find the target later

John Elwell: Have we considered looping?

Jon Peterson: Sure we can account for looping. There are other uses cases for having a proxy be able to assert Policy

John Elwell: If the PIDF contains a marker that identifies the source, that might help

Jon Peterson: that's possible

Keith Drage: This is not a good idea, we should not do this. Does not support all the use cases we need to.

Adam Roach: Could you clarify the use cases that aren't supported?

Keith Drage: Wants it so only the LR ever determines which of two things are best locations

Jon Peterson: Points out his proposal does this

Keith Drage: what if UAC doesn't include a header, would that also use a 424.

Jon Peterson: depends on support of the feature, the proxy is in the position to make a decision based on whether it thinks that the UA supports (or not) the feature

Hadriel Kaplan: nice idea in theory, but there's already stuff that is deployed. In reality, UAs don't support "jack".

Hadriel Kaplan: This idea is great, but too late, proxies are deployed. in the real world, UA don't support _anything_.

Jon Peterson: in emergency case, sensibilities are ignored, this cruft was there for the emergency use case only

Hadriel Kaplan: Proxies are inserting PIDF-LO and just forwarding it along. The guy that is receiving this stuff should be the one doing all the work to get the information.

Jon Peterson: You don't really care about these headers being removed since they're included in PIDF LO (i.e., who inserted). Anything that SIP doesn't need for routing should be in PIDF-LO

Christer Holmberg: not going to work if UA doesn't support this specification

Jon Peterson: If ua adds location, then it will support 424, and if it does not add one, it does not. There is no problem, works fine. We're not changing the semantics of what is in the current draft.

James Polk: for Christer's concern, as long as a proxy's location is included, then other doesn't matter

Jon Peterson: any proxy could reject a PIDF they did not like. This is not new

Martin Thomson: Have not been convinced by any of the arguments against the proposal. May be problems with stuff that is already deployed.

James Winterbottom: ordering of elements in PIDF-LO has an impact, might need to look at RFC 5491. Need to look at the strong language about what should be included, and need to keep some of that.

Jon Peterson: the data model should be able to resolve that

James Polk: there can be multiple PIDF LOs in request. Maybe should do a 403...This might be okay if you agree to accept limitations.

Cullen Jennings: ..concern over end quality of what gets deployed. Thinks this is far simpler - easier to get right. Understand impact on what's existingly deployed. This should finish much sooner than what we have now.

James Polk: proposes that we see -03 and have a back-out option

Jon Peterson: need a solution, closure

James Polk: about time

Cullen Jennings: timeliness and impact on deployments are important; quality is much better and should be easier ...and quicker

Meeting ran out of time -- discussion should continue on list.