SIPCORE Minutes

Status and Agenda

Essential Corrections

Should we abandon the essential corrections process?

Keith Drage: we do not proclude drafts from going forward. Small changes should be done in the EC (changes that do not require RFC).

David Brian: The name essential corrections answers the question.

Dean Willis: We should edit 3261

Keith Drage: there is a definition of EC in Keith's draft.

John Ellwell (Jabber): agrees with David Brian

Jon Peterson: Hesitant to say that we should abandon EC

Gonzalo Camarillo: The question is whether we should bundle together the drafts or proceed on drafts on their own.

Camarillo: We will proceed on drafts individually (3-4 drafts) we should discuss later how to do other changes.

Adam: we should see in the list notes about changes of milestones.

Drage: some of the drafts of the EC went via WGLC already.

Camarillo: we will give one week for latest comments.

Consensus: Will work on 3-4 distinct drafts right now; will decide how to proceed over the next few weeks. Will update milestones to reflect individual draft deliverable, instead of bundle.

Secflows Draft

Chairs: This draft needs more reviews -- we've worked on it for 7 years, and believe it to be done.

Robert Sparks: Should we publish sec-flows or shoot in the head?

Mary Barnes: do early security direct review on sec-flows

Keith Drage: we were waiting for certificates.

Robert Sparks: bit of disconnect between open SSL and the draft. tends to be difficult

Keith Drage: we need to review the certificates

Robert Sparks: we need to make sure that the certificates and headers are populated correctly.

Volunteers to review draft-ietf-sipcore-sec-flows: Ben Campbell, Bob Moskowitz

Indication of Support for Keep-Alive

Central open issue is: What does "adjacent" mean?

Consensus (pretty quiet, though) is Option 2 from slides: “Nodes which are adjacent in a route set/registration path”

Draft will be updated and go to WGLC during August

Hadriel does not like allowing CRLF for keep-alive, as it breaks things in the field. François points out CRLF is allowed in Outbound. Further discussion to take place on list.

History Info & Target URI

Drafts have had a lot of revision since last IETF meeting

Summary: Need use cases somewhere; still discussing where to put them: in document or separate document(s). Put major use cases into document; can always put new ones into a separate document.

Dean Willis: question on scope - intended to solve use case of delviery of parameters from uac to uas?

François Audet: yes

Keith Drage: entire target uri not only params.

Cullen Jennings: says very little on how to read info from headers. Is it still a todo?

François Audet: yes, still a todo item

Mary Barnes: last bullet was misleading

Hadriel Kaplan: we need to make these things more explicit

François Audet: are the use cases in a separate doc?

Hadriel: we need the use case text in order to understand the draft

François Audet: there are many use cases. we need to decide what to put where.

Cullen Jennings: we need to say in these use cases this is what you have to do. functions should be normative. No idea what service means here.

Mary Barnes: we never define services only in BCP

Christopher: need to describe in high level how to do things.

Spencer Dawkins: use cases should be treated as normative.

Hadriel: there are specific app usages that need to be documented somewhere. e.g. voice mail. Not sure that should be in the document, although hard to understand the document without these.

Keith Drage: Not convincing that rendering to app or users should be described as normative.

Hadriel: should be separate document.

Philippe Fouquart: Comment on list regarding removing of reason when there was a time-out. This doesn't seem to be addressed in your presentation.

François Audet: I probably missed it. Please bring to the list.

Issue 1: AOR tag

Hadriel: Virtually everything about an AOR is ambigous.

François Audet: At the end of the day, it is an AOR since the proxy says that it is an AOR.

Hadriel: Does not agree. Number translation is a counter-example. Every strict router will be an AOR

François Audet: Strict routing was not the highest priority. Need to discuss.

Keith: Concentrate on what you need for 4244. A lot of the dicsussion is 3261

Hadriel: agrees.

Jon Peterson: Agrees with Hadriel. Need to find a different name for what the history draft calls "AOR", and define its properties.

François Audet: The ones that are not marked AOR are less usaable

Jon Peterson: Definition of aor is not what is in the 4244bis draft.

Jon Elwell (via Jabber): 3xx - do they tag URIs and AORs?

François Audet: Depends on whether the entity is responsible for this or not.

Adam Roach (from floor): Why are we worried about strict routing? Do we really thing we'll have people implementing 4244 but still being on 2543?

Hadriel: So many deivces will call routing strict even if it is not.

Robert: Strict routing is 2543 only.

Hadriel: We meant something else in the list.

Robert: Strict routing refers exp. to when there is no ;lr only.

François Audet: Slarifies what strict routing meant.

Hadriel: need to find another word for what I meant by strict routing.

Jonathan Lennox: if i receive somethign with aor tag, what it means?

Dean Willis: 'AOR' here means that there is been a rerouting operaiton executed by a proxy.

François Audet: does not fully agree

Nassen (?): mark as aor enum

Keith Drage: What was described is not a use case. We have an app that needs to distinguish uris.

Jon Peterson: Agrees with Keith. Does not agree with Dean. We need to identify the property for the app that needs to distinguish between URIs.

François Audet: There are pieces of information that we can convey.

Jon: Any forwarding is a location service. Wrote seciton 10 of rfc 3261

François Audet: How to distinguish uris?

Jon: Uris usefulness depends on the context in which they are dereferenced. Uris do not have essential property.

Robert: Can put contact in business card and can be useful depends on context.

Jon: Uris are contextual. Fundamentally what uris are.

Keith Drage: marking of uris dependent of application is not always true. e.g. isdn diversion service.

François Audet: Authors think that it helps to solve their problem.

Hadriel: URIs are not really knowable to machines.

John Ellwell (via jabber): agrees with Jon Peterson. Tagging as URI as 'AOR' does more harm then good.

Jon: This is a tremendously difficult problem to solve. If we can solve this, we will be able to solve the security issue. We need to concentrate on the requirments of the end entity.

Robert: impedence mismatch. the receiver does not always have the same meaning as the sending proxy.

No Consensus. Will continue discussion on the list.

Issue 2: rc/cc/rt Tags

Summary: two people want precise definition for the tags (slide option 1); some on list said “call it what it is” (slide option 2). No consensus, except limiting to these two options.

Hadriel: Loves option 4 but can not be done in a backwards-compatible fashion.

(Brief discussion of voicemail use case)

Mary Barnes: If we get to the next hop and see that the previous hop is not tagged, we want to add the aor (or whatever it's called) tag to the previous entry - I prefer alternative 1.

Keith Drage: 4244bis should be backward compatible.

Hadriel: Mary pointed to a bug, since if see aor i will think that it is the new version.

(discussion about this bug)

Keith Drage: Other information can be used by renderer. Should not use absence of typing for other meaning. Does not believe that it should say if it is the new version.

François Audet: Disagrees. Need to distinguish versions.

Hadriel: garbage in garbage out. diversion is important use case that should come out of this.

Mary Barnes : Agrees with last point. The need for this entry is for knowing the version of the previous proxy.

Adam Roach: agrees with Mary - option 1

Cullen Jennings: Need to focus on semantics that we want to deliver to the far end. Likes "fluff" for some obscure reason

(discussion between Cullen, Mary and François)

Hadriel: The use of distinct tags is like a reason phrase. More for logging. These should not be used for something else then logging.

François Audet: agrees that the proxy should not record the info based on these flags.

No Consensus, execept rejection of options 3 and 4. Will continue discussion on the list.

Issue 3: mp Tag

Discusion of semantics of mp tag -- currently, tags the URI after translation (the URI translated to), not the URI before the translation (the URI being translated from).

Hadriel: Is not always the one before the mp?

François: Yes.

Hadriel: Who would know to put the mp? e.g. does a redirect server tag the URI?

François: Tag to make sure that it is not removed.

Marked as open issue.

Keith: there will be multiple mapped to form different diversions.

François: Agrees that the 'to' is not as useful. use case for phone

Hadriel: So this is really a 'non fluff' tag.

Keith: Not sure that it works unless map-to and map-from are numbered.

Hadriel: There will be different names

Keith: If people will remove entries + URIs how to relate mapto and mapfrom?

François: There should be logic for this in the app

Mary: Indexing can help to corelate.

Leaning toward changing semantics to mapping both URIs. No clear consensus. Topic to be taken to list.

Issue 4: Algorithms for Retrieving Different Targets by the UAS

Need to clarify algorithms for different applications. If you have specific applications in mind, please bring them up so they can be looked at.

Issue 5: Privacy

Authors don't think it's really an issue. 3323 was written with a two-party model, didn't really anticipate privacy of intermediate identifiers. Current draft tries to clarify that privacy applies to entries, not messages.

People should look at existing text in 4244bis to make sure it meets their expectations.

Document Scope and Structure

Discussion of whether to continue to work on 4244bis and target-uri as separate documents

Shida: we should work on this as single doc

Hadriel: reading both drafts together is important but we need to separate use cases.

Keith: No reason not to continue in the same document. Make sure you have a clear split between normative and informative portions. We need to make sure that we agree on backward compatibilty.

François Audet: Current scope is to limit bis changes to satisfy target uri requirements.

Keith: Diversion? Need list of use cases.

François Audet: We'll limit use cases to those in history info and in target uri right now. We'll clearly separate normative from informative text, and put it in a separate part of the document so it can be split off if we later decide to publish them separately.

Weak consensus to move forward as a single document.

History-Info Applicability

Dean Willis: Is uac->uas information transfer in scope? Alan Johnston has a Call control UUI draft. If this solution doesn't meet those use cases, then it does not meet our charter goal.

François Audet: The proposal in 4244bis will work, but it is not the direction the UUI authors have chosen to pursue.

Dean: Then history info is useless

François Audet: No, history-info will work for UUI; the group simply hasn't chosen to use it for that purpose.

Tel-URIs

Hadriel: Tel-URI and escaped headers. Is is planned to solve in the draft?

François Audet: Thinks that it will be very hard. Thinks that it is out of scope. Willing to accept text if someone has a suggestion.

RFC 3265 bis

Just became a working group item -- revision addresses bugs and lessons learned since published. Also, original version reflected compromises that were necessary due to limitiations in SIP protocol at the time.

Open Issue: Allow-Events and Templates

Need to check how it was implemented.

Robert Sparks: At SIPits, people put the top-level events, and don't advertise winfo support. People just try winfo and fail. For winfo, this is okay -- for future event packages, it might. Propose we note that it's an issue, and address when we have a second template event package.

Adam Roach: So your advice to implementors would be to not advertise winfo?

Robert Sparks: My proposal is effectively "leave it a mess."

Adam Roach: That raises the question about why we advertise events at all?

Robert Sparks: At the moment, we have several event packages, and one template. People can probe for support for the template, and this doesn't cause deployment pain.

Adam Roach: So we wait for the pain?

Robert Sparks: We've had this for 8 years, and have only one template.

Adam Roach: If the advice is to not avertise templates, I'd like to make that explicit in the document.

Robert Sparks: Let's see if we can get consensus around it. It's not a great answer, but it's probably not worth the effort to get a great answer.

Will poll for consensus on the list

Open Issue: The Fate of 202

Because of HERFP, the 202 response is of limited utility. This has caused problems with implementors. Should we remove it? Or are people using it?

Theo: Just use 200.

Robert: Have explicit text acknowledging historical use of 202. Recommend that people use 200 and treat 202 as 200.

Adam: So, do you want a "SHOULD NOT send?"

Robert: Yes.

Keith: What is the problem? If people read the spec correctly then there is no interop issue.

Robert: (brief history of 202 and QAUTH). People make assumptions around auth policy. Tell people to look at the initial notify.

Keith: I dont see how removing 202 gives that guidance. You are asking for something else.

Robert: Repeats the suggestion regarding clarifying text.

Keith: There may be misinformation in the 202.

Andrew Allen: Do not remove 202. There are already deployments, and other specifications that include 202. Just recommend that you don't send a 202.

Christer Holmberg: does not see what 200 will solve.

Adam: What I've heard is mostly "leave it in the document, but recommend that it not be sent."

Avshalom: Deprecate but do not remove. Agrees with Robert.

Keith: Deprecate means removing. The problem is that people are using it inappropriately.

Andrew: Does not agree with deprecating, just include text that says new implementations send 200s.

Adam will compose text and send to the list.

Open Issue: New Timer and Resubscriptions

Proposal to have a new state machine timer L, 64*T1 to supervise NOTIFY state. Explicitly calling out the timer is good (RJS). Corner case: in middle of establishment when fires, do we reject it? BTW, INVITE-fix takes timer L; Adam will revise draft to use Timer N for Notify.

The question that arises is how to handle this timer expiring in the middle of a subscription.

Robert: Explicitly calling out the timer as applying in the middle of a subscription is useful. We should treat it like 408.

Drage: Suggests to take the issues to the list.

James Polk: Wait for the end of the originally accepted subscription.

Adam to take issue to list

Record-Route fix

One DISCUSS left. WG decided to send up as BCP. However, this draft does not fit BCP status per RFC 2026. Probably goint to publish it as a proposed standard.

Keith Drage: Just a reminder that the record-route-fix discussion is taking place on the SIP list. So, if you're interested in this topic, make sure you are still subscribed to the SIP list.