IETF 84 Minutes - ECRIT 
Date: 7/31/2012 
Start time: 13:00
End time: 15:00
Notetaker: Martin Thomson

Administrivia
Old chair: Richard Barnes
New chair: Roger Marshall
Status
RjS (AD): what is the plan for advancing the service-urn-policy draft?
A few people have read the draft, no real concerns about it.  Chairs will do last call soon.
Chairs reviewed the mature milestones for the group and promised to provide a revised set of milestones soon.
-phone-bcp
GC (AD): Will be submitted next week for IETF last call.  Needs to wait for loopback.
-psap-callback
Christer presented the latest in a long line of proposals: SIP Priority header.
MT: is this giving up?
CH: yup
BR: obviously, there are still mechanisms using Contact and gruu that can be used to link things, but those are up to the networks.
JP: Concerned about use of Priority because it only indicates what the UAC thinks about the priority of the call.  'emergency' is not appropriate.
CH: normally this causes the bypass of certain services.
JP: does this happen any time that someone tags a call with this tag? emergency means many things to many people
HT: since we are expecting intermediaries to look at these, why not define a different service URI
HK: but the request URI should point to the user
CH: the GRUU for the device must be the request URI in the callback if the call gets back
HT: what about the Route header?
HK: wont work, but at some point the registrar needs to do the final routing at the end and that information needs to get to the end device
HT: both
HK: not both, too much
HK: there are middleboxes that might cause this callback to fail
HK: proxys can look at the header, there is no problem with that; it seems like the right header to use
AA: none of this is authenticated, so this is giving up; we aren't using an authenticated token, so the actual token we use doesn't matter.  this is just a 
hint and those that act based on this can use other things to get the authentication
PK: ditto, this is exactly what priority is for..."local policy"...
BR: this is a fine solution, use 'emergency', a new value would be OK if we can agree on that.  don't do Route header
HK: the networks that support this varied behaviour based on this header will be able to apply policy in various ways, probably using the same mechanisms as for P-Asserted-Identity and other such things
KD: Reusing an existing value with existing semantics is not appropriate
CH: would anyone object to a new value?
JP: agree with KD
MT: argument is bogus
RG: there is nothing preventing anyone from using the new value
HT: blahblah html5 blah
Chairs: plan to resolve soon
-data-only-ea
RG: I sent some comments, nothing major, maybe a name change to media-less.
RB: does this define a media type for cap?
BR: yes
-additional-data
MT: draft uses chaining to link blocks, which is weird
RG: one URI per block, or multiple call-info headers
HK: agree, just make it multiple headers; then you can switch cid: and 
https: URIs transparently
MT: make more purposes
-rough-loc
richard was prophetic
talked about changes, and about new LoST LbyR proposal
-priv-loc
hannes talks about the competing HELD LoST proposal
font selection was sub-optimal
RG: concern that the owner-operated LIS was another motivation for this
RB: the device CAN convey information without harm
HT: this comes back to the location spoofing problem
BR: there is no good identifier for the VSP to use
MT: likes LbyR in LoST but we need to resolve the issue that we can't return location without the stakeholders being involved
BR: also likes LbyR in LoST
ML: what can the proxy/VSP do?
BR: in this model, the end point doesn't do anything at all
RJ: we have regulatory and privacy constraints
RB: does this include routing information as well as location?
BR: this assumes a relationship between VSP and LIS
RB: if you don't allow the end device to mediate between access provider and VSP, then you have to establish an out of band channel
JP: decentralized architecture of LoST make these bilateral relationships difficult
RB: architectural issues
lost the thread of the argument here...
RB: a really cogent point on this that was far too complex to capture in the minutes
RB: we should address the issues of who gets location and how third parties perform routing separately as much as possible
-rtcweb-ecrit
RB: accuracy of geolocation API depends on the underlying provider; data indicates that 80% confidence is pretty good, but it gets much worse very quickly
BR: what about the signaling
KD: more interested in the PSAP doing WebRTC than this stuff
BA: call takers using WebRTC would be a big deal
RB: describes consequences of PSAP presenting an HTTP URI along with its SIP URI to provide a WebRTC enabled site for making the emergency call
-ecall
HT: this document doesn't define anything new, which is important, it's just stuff being put together ... apart from the service URNs
RG: this has a call, but there is extra data, -data-only is when there is no call
KD: mimicking 3GPP ecall means that you have a different call type with a different sos subtype.  the problem is that you might want to tag with the ecall type and some other type.  This is another problem with the existing subtypes - you can't do two at once.
RG: I submitted a review, that included moving the URN under sos.  Let the ESINET make the final determination.
BR: we need to deal with the ecall problem, but doesn't have anything concrete, undecided on the subtype
KD: this matches with the top-level sub type of urn:service:sos
BR: we need to work out what goes after the dot then
BR: proposed to rev based on this discussion and come around again; ensuring that the set of documents (-data-only, -ecall, etc..) are in sync
-rough-loc again
ML: should we move rough-loc ahead as it stands
RB & MT: we should keep it open until we can resolve this issue