[sipcore] Raw Minutes

[Peter Musgrave <[e-mail]>]

SIPCORE IETF79 Beijing

As per agenda..

== Location Conveyance ==
James Polk/John Peterson

424 issue: Martin - agrees with the proposal on the slide
Any disagreement?
No
Defer call for consensus until there is specific text

Rough ordering point: Is this ok?
Hadriel: Are we being too wishy washy? Should we be more specific? Is this unavoidable?
John: Consensus on list was to allow multiple location objects. 
Hadriel: Can we have a rule which is more specific?
(Some discussion of the past history and some of the corner cases which makes this hard)
Hans expressed support for chronological order, but rules to decide which one are hard. 
Martin - are we attaching semantics (e.g. with chrono order). Safer to just consider as a set. 
John - order might be easy and can say caveat emptier…don;t see the harm
Martin - either way is ok

Adam: Who is ok with putting text to say "insertion must be done at the end of the list"?
Ok? 18
Not? 0
(consensus)

geolocation option-tag?

Error codes were viewed as somewhat cumbersome (review by John Elwell). Idea is to use option-tag profiles.
List discussion very favourable. 
John Elwell: This is ok. Concern about use in Require…
JohnP: Leaving the door open, might not need it. 
Keith: What happens with multiple locations and end-to-end support of a tag…will option tag get changed
JohnP: You would add additional supported tags as it goes…in the case of intermediary. 
Hadriel: Concerned about putting this in Require. Do we want calls to fail in those cases? 
John: MIght be useful in error code. 
Martin: Use in requests might not make sense, but in responses seems appropriate (esp. 424)
Adam: Starting to see warts now that we've discussed…especially if we get two of these in a message etc. 
JohnP: A lot of this is an artifact of multiple locations, we could find some remedies e.g. tag on header instead of in supported. 
Martin: Request in geolocation has a URI, don't need to say how to use a particular URI. 
JohnP: Unless we're committed to one profile then we need multiple location cases. 
Martin: Let's put a new parameter in header with a new RFC…
JohnP: Gross profile solution might work…
Hadriel: option-tag is a hammer looking for nail…if it's in Suppored need to put in all all the time. 
JohnP: We conceded supported in request might not be useful, but in response it is.
James Polk: Just one location would solve this….the pain threshold for this is high. 
Hadriel: It's a collision of scheme - not solved by just one location. 

RJS: Can we make time for more discussion? 

Geolocation Header Errors:
Martin: Are the errors actionable?
James: We need these error codes.
Martin: But I can't do anything with the information. 
(Discussion about specific error codes…100, 424, 301, 302 etc.)
Martin: Lot of mechanism here - not sure it adds a lot of info other than better feedback. 
JohnP: What do the different subsides tell us?
James: Retention, Routing Allowed could result in 
James: Pizza hit case…(rapid steam of error codes), server could correct and retyr. 
Martin: Maybe, but the cost is high for this. 
Hadriel: Detailed error codes are for troubleshooting - not for self-healing. They do have value.
Richard: Maybe we don't need this detail in this doc. Just put in a separate doc. 
Keith:  May need another mechanism. Can we accept call but still convey a geolocation error?
JohnP: I think we still need these, want to get to smallest set - maybe we can a bit more. 
Hannes: Support for a separate doc seems good idea.

Chair: Extend discussion

James: Disagree with separate doc. 
James: Geopriv was very fixed on this…5606 is a bad case…
Allysa: Geopriv fields are directives for a recipient. 
Martin: They will take the call
(technical side track discussion - which I didn't follow)
Hadriel: Beware reason phrases - they do not localize
(more debate…)

JohnP: Let's take an expedient path. Leave what's in there. It does no harm.

Consensus Call: Should we leave in error codes as they are:
Adam: Consensus for leaving in. 

Adam: Let's try and do some interim work to get this done…watch the list for details. 

(some process description. )

RJS: Let's put text in the doc. 
Keith: Strong objection. 

== History Info & Target-Uri Support ==
Mary Barnes

Hadriel: Out-of-Dialog REFER could have H-I…
(ok - we'll remove the bullet)
Scatching it from NOTIFIES. 

Privacy (1) - any issues with this proposal?
(none)

Privacy (2) - Issue 4: "none" - Option 2 - ignore
PaulK - I'd like to think about this….
JohnP: Trying to apply 3323 is tough - it's an old doc…it does not affect these options. Option 2 is ok. 

Reason in HI
Adam: Agree with leaving it alone…anything else out of scope
Dale: In favour. (with explanation)
PaulK: Ok - I give up. 

Adam: Anyone against. 
(no)

== Proxy Features ==
Christer Holmberg

Dual-Direction Tags/Path:
Dale: Why does UA need info in Path. This is how to get to registrar…
Hadriel: No INVITE might not follow the same path. 
Christer: But this is a policy issue…in some cases yo do want the INV to follow the same path
Dale: Does this not happen by default?
(more discussion)
PaulK: Rat-hole. Let's move on to the mechanism.

(I tuned out here...some discussion about detecting interaction between intermediaries)

Adam: PLease keep the discussion going. We would need to add a MIlestone and make sure this is the right place for this work.

== Reason Header Extension for Applications ==

Mary-Anne

Not much feedback on the list…
PaulK: I thought this was germane since we're doing work on HI bis…
PaulK: Not clear how reason goes into H-I, there are no responses which allow Reason
Roland H: Reason in response is in Dispatch

Mary: we don't want to extend 4458
Paul: Is there an interaction with HI which needs to be dealt with
Mary: Don't think so. 
Dale: Many of the codes are straight-forward, but first has to do with paid services. Might want to be subdivided…
Cullen: Don't understand why we need this…

Adam: Work through on the list. Express interest….might not be sipcore….

Goodnight….