[14:50:26] --- bnsmith has joined
[15:48:20] --- lemmakin has joined
[16:01:46] --- mlepinski has joined
[16:02:39] --- rwatro has joined
[16:03:10] --- m_ersue has joined
[16:04:57] --- AdamUzelac has joined
[16:05:10] --- hardie@jabber.psg.com has joined
[16:05:15] --- spencerdawkins has joined
[16:05:19] <hardie@jabber.psg.com> Chairs welcome the group
[16:05:25] <hardie@jabber.psg.com> The Note well is presented
[16:05:30] --- miki has joined
[16:05:31] <hardie@jabber.psg.com> Andy does not sing the note well.
[16:05:35] <hardie@jabber.psg.com> the group is relieved
[16:05:39] <hardie@jabber.psg.com> The agenda is shown
[16:05:42] <hardie@jabber.psg.com> Bashing available.
[16:05:56] --- ysuzuki has joined
[16:06:10] <hardie@jabber.psg.com> To the jabber room: If you want something reflected to the room, please preface it with Room:
[16:06:22] <hardie@jabber.psg.com> Reviewing agenda
[16:06:49] <hardie@jabber.psg.com> Agenda agreed
[16:07:09] <hardie@jabber.psg.com> Document status reviewed : ecrit requirements, service-urn, and security-threats are all sent to IESG
[16:07:35] <hardie@jabber.psg.com> Proto write-up has happened.
[16:08:04] <hardie@jabber.psg.com> Milestone review:
[16:08:20] <hardie@jabber.psg.com> Three Jul 2006 milestones done
[16:08:36] --- anewton has joined
[16:08:36] <hardie@jabber.psg.com> Running close to milestones on LoST & Architecture doc
[16:08:59] --- Barbara has joined
[16:09:05] <hardie@jabber.psg.com> Notes supplementary web page and the issue tracker: http://www.ietf-ecrit.org/implementation.html
[16:09:05] <anewton> actually, Henning requested that I sing it.
[16:09:58] <hardie@jabber.psg.com> sorry, www.ietf-ecrit.org for blog and issue tracker; implementation page specific for contacts of projects implementors
[16:10:05] <hardie@jabber.psg.com> First Presentation now.
[16:10:20] <hardie@jabber.psg.com> SDO emergency services coordination workshop review
[16:10:26] <hardie@jabber.psg.com> Hannes reports
[16:11:05] <hardie@jabber.psg.com> Acknowledgements (host, presenters, participants)
[16:13:42] <hardie@jabber.psg.com> Summarizing 3gpp2, ieee802 presentations (pointers to each of these presentations are at the proceedings site)
[16:13:52] <hardie@jabber.psg.com> lldp, IETF now summarized
[16:14:16] --- Antoin has joined
[16:14:52] <hardie@jabber.psg.com> http://www.ietf-ecrit.org/EmergencyWorkshop2006/ base URI of these pointers
[16:15:41] --- hb47713 has joined
[16:17:14] --- richard.barnes has joined
[16:17:34] --- dumdidum has joined
[16:18:56] <hardie@jabber.psg.com> Open Issues:
[16:19:16] <hardie@jabber.psg.com> Archtiectural approach (access network provider tie-in to voice service provider)
[16:19:23] <hardie@jabber.psg.com> Sending location to the end host
[16:19:29] <hardie@jabber.psg.com> Who should develop the protocols
[16:19:34] <hardie@jabber.psg.com> Role of a "global coordinator"
[16:20:17] <hardie@jabber.psg.com> Next Steps: schedule another workshop
[16:20:26] <hardie@jabber.psg.com> Min 6 months, potential host: US DoT
[16:20:38] --- ogud has joined
[16:20:56] --- hb47713 has left
[16:21:14] <hardie@jabber.psg.com> Further steps: inform other SDOs about the work (es-coordination@cs.columbia.edu), register for that at https://lists.cs.columbia.edu/cucslists/listinfo/es-coordination/
[16:21:43] <hardie@jabber.psg.com> Request feedback from other SDOs regarding our documents
[16:21:48] <hardie@jabber.psg.com> Setups topic-specific liaisons
[16:22:03] <hardie@jabber.psg.com> Perform workshops with SDOs on selected topics (e.g. OMA and IEEE)
[16:22:38] <hardie@jabber.psg.com> Report about the SDO Emergency Services Coordination Workshop - Hannes Tschofenig concluded
[16:22:49] <hardie@jabber.psg.com> Questions at the mic
[16:23:10] <hardie@jabber.psg.com> Peter Blatherwick notes that the streaming method for attendance did work
[16:23:42] <hardie@jabber.psg.com> Henning Schulzrinne notes that there is a versioning problem--are we supporting existing PSAPs, NENA i2, or something else?
[16:24:07] <hardie@jabber.psg.com> Time horizons for i3 also somewhat misperceived for NENA.
[16:24:19] <hardie@jabber.psg.com> (Does i2 hold us over for a large number of years?)
[16:24:53] <hardie@jabber.psg.com> Mark notes that i2 is also being stretched to cover us for a large number of years
[16:25:24] <hardie@jabber.psg.com> Brian Rosen speaking now as chair of i3, says that the effort in NENA is to get i3 deployed as quickly as possible
[16:25:26] --- ttfr has joined
[16:25:37] --- nan_626 has joined
[16:25:43] <hardie@jabber.psg.com> The funding issues associated are pretty serious, but there is a top-to-bottom agreement on that.
[16:26:12] <hardie@jabber.psg.com> People agree that there is something we can do with the current system (that's i2) vs. next generation stuff (that's i3, a redo of the system from beginning to end)
[16:26:38] <hardie@jabber.psg.com> Maybe at first i3 was "someday", but not it is more immediate, and funding constrained rather than constrained by desire to complete.
[16:26:53] --- hb47713 has joined
[16:27:01] <hardie@jabber.psg.com> He was optimistic coming out of the workshop. There is work for us to do (I believe he has shifted to "us" as ecrit wg)
[16:27:44] <hardie@jabber.psg.com> Henning asked what was new; Brian replied that the WiMax folks made lots of connections to ongoing work, as one example
[16:28:03] <hardie@jabber.psg.com> Needs follow up
[16:28:17] --- jr111 has joined
[16:28:38] <hardie@jabber.psg.com> Hannes responds to Brian that it is important to keep in mind that WiMax != IEEE
[16:29:21] <hardie@jabber.psg.com> Steve Norris says what came out on the slides was list of issues to be resolved. At the workshop, there was a strong sense of synergy and a sense of similarity among solutions being done in lots of places .
[16:29:27] <hardie@jabber.psg.com> "Pushing at an open door" at this.
[16:29:55] <hardie@jabber.psg.com> Bernard Aboba (liaison for IEEE 802). What liaison activities are needed and what should we be doing at this point?
[16:30:26] <hardie@jabber.psg.com> Hannes starts discussing the usefulness of liaison
[16:30:53] <hardie@jabber.psg.com> Brian interrupts to note that the previously scheduled 3gpp/IETF joint meeting was very useful; a similar thing with IEEE would be great.
[16:31:18] <hardie@jabber.psg.com> Bernard notes that the IEEE groups may not be talking to each other
[16:32:23] <hardie@jabber.psg.com> Jonathan R. notes that it was generally group, but it should be recognized that the 3gpp architecture and IETF/ECRIT architectures do diverge, and we do need to do work to make sure that we create the best convergence we can.
[16:33:00] <hardie@jabber.psg.com> Bernard notes that the WG can create letters, and send that to 802/other SDOs; getting the concerns down on paper is useful.
[16:33:22] --- cullenfluffyjennings@gmail.com has joined
[16:33:30] <hardie@jabber.psg.com> Hannes says IEEE conversations will be relatively easy; other sdo conversations may be different
[16:33:51] <hardie@jabber.psg.com> Brian suggests that the big picture architecture document may be the right first thing to throw over the wall
[16:33:51] --- florent.parent@gmail.com has joined
[16:33:56] <hardie@jabber.psg.com> A Location-to-Service Translation Protocol (LoST) - Andy Newton starts
[16:34:27] <hardie@jabber.psg.com> First reviewing request/response pattern
[16:35:02] <hardie@jabber.psg.com> Discusses the added include attribute
[16:35:35] <hardie@jabber.psg.com> Goes through an example of the validation response
[16:36:30] <hardie@jabber.psg.com> Notes that the example in the presenation may change if the group adopts changes proposed later in the presenations
[16:36:48] <hardie@jabber.psg.com> Discusses Service Boundary References (preference to receive using include)
[16:37:14] <hardie@jabber.psg.com> Brian Rosen questions the usefulness
[16:37:31] <hardie@jabber.psg.com> of having serviceBoundaryReference
[16:37:50] <hardie@jabber.psg.com> Henning questions Brian's premise that you have to retrieve it.
[16:38:19] <hardie@jabber.psg.com> He aruges that the service boundaries are long term stable
[16:38:52] <hardie@jabber.psg.com> That allows you to leverage difference in ttl between these and specific query responses.
[16:38:58] --- dumdidum has left: Replaced by new connection
[16:39:14] <hardie@jabber.psg.com> Cullen asks whether we are imagine large, complex boundaries or simple boundaries.
[16:39:31] <hardie@jabber.psg.com> Henning says at least one option is to send regular county-type boundary
[16:40:04] <hardie@jabber.psg.com> Can be up to 8 kilobytes or so, but you can inscribe a simpler polygon to cut that down drastically
[16:40:18] <hardie@jabber.psg.com> That loses complex borders--creates, if you like, a corner case
[16:41:35] --- dumdidum has joined
[16:42:09] <hardie@jabber.psg.com> Brian Rosen thinks that it would like to indicate from client to server of what complexity you like
[16:42:09] <hardie@jabber.psg.com> Henning and Andy believe that this is "interesting" in many ways
[16:42:09] <hardie@jabber.psg.com> Discussion of boundary references to the list?
[16:42:09] <hardie@jabber.psg.com> Hannes takes the floor mic, so that he can point out that we discussed this at previous meeting
[16:42:09] <hardie@jabber.psg.com> Request for reference was explicit
[16:42:37] <hardie@jabber.psg.com> Complexity of this mechanism (the reference) is low, so including the mechanism does not seem to be extreme
[16:43:07] <hardie@jabber.psg.com> Andy and Henning discuss the level of effort here, and agree that it is low
[16:43:15] <hardie@jabber.psg.com> Address validation is discussed
[16:43:25] <hardie@jabber.psg.com> <valid><invalid><unchecked>
[16:43:39] <hardie@jabber.psg.com> Brian Rosen is happy with unchecked
[16:44:03] <hardie@jabber.psg.com> Then jumps forward to an open issue, which is defered
[16:44:13] <hardie@jabber.psg.com> Location profiles discussed
[16:44:29] <hardie@jabber.psg.com> With Geo, in particular, there may be may be multiple location profiles
[16:44:35] <hardie@jabber.psg.com> (reference to well known profile)
[16:44:47] <hardie@jabber.psg.com> URN now, but it might become a token in an IANA registry
[16:45:55] <hardie@jabber.psg.com> Rohan Mahy says he like the approach in the current draft; a token is fine too. The mandatory-to-implement is very useful combined with the extensible
[16:46:14] <hardie@jabber.psg.com> Brian asks whether we want to replicate this out to other places (e.g. SIP conveyance?)
[16:46:23] <hardie@jabber.psg.com> Andy agrees that it is an issue.
[16:46:35] <hardie@jabber.psg.com> Might be sip conveyance issue or a general geopriv issue
[16:46:46] <hardie@jabber.psg.com> Location profile example
[16:47:53] <hardie@jabber.psg.com> James Winterbottom notes that the geoshapes stuff only defines a few dozen shapes; if we want to limit to those, this is more complex than needed.
[16:48:12] --- mlepinski has left: Computer went to sleep
[16:48:27] <hardie@jabber.psg.com> Andy replies that this sets a baseline, and the extension mechanism is there for more complex shapes.
[16:48:29] --- dcrocker has joined
[16:48:41] <hardie@jabber.psg.com> The return value issues, in particular, have not been defined
[16:49:10] <hardie@jabber.psg.com> Andy says geoshapes is not going to be the end of it, and this extension will be available for that
[16:49:37] <hardie@jabber.psg.com> Hannes notes that this might also be used for 2d plus floor type combinations
[16:49:43] <hardie@jabber.psg.com> MUST implement profiles reviewed
[16:49:51] --- mlepinski has joined
[16:50:06] <hardie@jabber.psg.com> Andy now goes over how to define a location profile
[16:50:31] <hardie@jabber.psg.com> Now reviews basic interaction rules.
[16:51:08] <hardie@jabber.psg.com> Now on to review Open Issues
[16:51:38] <hardie@jabber.psg.com> Error responses
[16:51:41] <hardie@jabber.psg.com> time to live
[16:51:46] <hardie@jabber.psg.com> include attribute processing
[16:51:52] <hardie@jabber.psg.com> ordering of element names
[16:52:03] <hardie@jabber.psg.com> order preference of location profiles
[16:52:38] <hardie@jabber.psg.com> Ordering of element names--proposal is to add guidance on how to define country-specific orders
[16:52:50] <hardie@jabber.psg.com> algorithm for adding via
[16:52:55] <hardie@jabber.psg.com> loosen service boundary key
[16:52:59] <hardie@jabber.psg.com> signing of service boundaries
[16:53:28] <hardie@jabber.psg.com> Rohan will post to issue tracker: multiple display names (e.g. Flemish/French in Belgium)
[16:53:37] <hardie@jabber.psg.com> Errors vs. Warnings slides
[16:54:04] <hardie@jabber.psg.com> separation of errors and warnings (errors=you get nothing; warning=you got a response, but not clean processing)
[16:54:20] <hardie@jabber.psg.com> Steven norris is still slightly worried about it
[16:54:53] --- miki has left
[16:55:02] <hardie@jabber.psg.com> Concerned that the error messages requiring human action are worrying in this circumstance
[16:55:16] --- AdamUzelac has left
[16:55:16] --- AdamUzelac has joined
[16:55:22] --- mlepinski has left: Computer went to sleep
[16:55:22] <hardie@jabber.psg.com> Henning says that the basically goal is to always return something useful
[16:55:33] <hardie@jabber.psg.com> But if there is a real failure, we have to make it known
[16:56:09] <hardie@jabber.psg.com> The big change here, though, is that this need not happen at the time of the call; so any real error MAY be resolvable in advance of emergency
[16:56:29] <hardie@jabber.psg.com> Steve asks if these are general location errors?
[16:56:45] --- AdamUzelac has left
[16:57:32] <hardie@jabber.psg.com> Henning says that they may be: protocol errors, location style errors (a coordinate off planet); for the latter, a default value is the right choice if one is available
[16:57:41] --- mlepinski has joined
[16:58:08] <hardie@jabber.psg.com> Now, an example of the Find Service/Warning Example
[16:58:35] <hardie@jabber.psg.com> Shows new <mapping ttl=> syntax
[16:59:22] <hardie@jabber.psg.com> Reasons: improves the context of errors and warnings, enable insertion of data by resolvers,absolute ttl and more modular to accommodate future work on signatures
[16:59:28] <hardie@jabber.psg.com> not to be done for this pass!
[16:59:43] <hardie@jabber.psg.com> List Services Query issue (Shida Shubert's coment)
[17:00:17] <hardie@jabber.psg.com> proposal to make <location> optional to specify which semantic.
[17:01:31] <hardie@jabber.psg.com> Ted notes that there may be other choices for this--discussion
[17:02:02] <hardie@jabber.psg.com> Brian notes that this is a good document, but it is missing the forest guides elements
[17:02:23] --- m_ersue has left
[17:02:37] --- dumdidum has left
[17:02:42] <hardie@jabber.psg.com> Henning replies to Brian that since we are at the charter date for this item, we really need to get this done. All known items have been addressed in proposals; if they are accepted, the next step would be a document which needs editorial review but is hopefully complete
[17:03:19] <hardie@jabber.psg.com> A next step would be creating a "forest guide discovery protocol" document--that's not yet chartered, but this work should not block on it, since it may take time.
[17:03:51] <hardie@jabber.psg.com> Henning thinks this is not that complicated, but that it does need more work than a couple of months
[17:03:53] --- ogud has left
[17:04:06] <hardie@jabber.psg.com> Authors suggest new fresh eyes plus WGLC is need
[17:04:17] <hardie@jabber.psg.com> Keith raises error question mapping
[17:04:29] <hardie@jabber.psg.com> sorry, question of mapping errors
[17:04:56] <hardie@jabber.psg.com> Henning proposes that for errors which are fatal, that conveying protocols should be sent across as is
[17:05:29] <hardie@jabber.psg.com> The other issue is similar to isup; a lost flag + mappings to an externally referenceable code
[17:05:55] <hardie@jabber.psg.com> Obviously, this is verbal whiteboarding, but it needs to be in a real draft
[17:06:07] <hardie@jabber.psg.com> Keith repeats need for generality here.
[17:06:47] <hardie@jabber.psg.com> Chairs ask for show of hands for folks who have reviewed current draft--encourage new review
[17:07:00] <hardie@jabber.psg.com> Send chairs names of expert reviewerds
[17:07:08] <hardie@jabber.psg.com> Tom, Charles, Shida volunteer
[17:07:29] <hardie@jabber.psg.com> Location-to-URL Mapping Architecture and Framework - Henning Schulzrinne
[17:07:32] <hardie@jabber.psg.com> 2 minute referesher
[17:08:09] <hardie@jabber.psg.com> seekers, resolvers, forest guides, trees
[17:09:13] <hardie@jabber.psg.com> forest guides know who has authoritative information on particular regions
[17:09:43] <hardie@jabber.psg.com> Shows picture from slide 3
[17:10:12] <hardie@jabber.psg.com> Note that some of the logical entitites are clusters
[17:10:21] <hardie@jabber.psg.com> for redundancy, resiliency, etc.
[17:10:39] <hardie@jabber.psg.com> Goes through caching theory
[17:11:31] <hardie@jabber.psg.com> Status and next steps: basic text is stable, but needs some tweaking needed to generalize
[17:11:44] <hardie@jabber.psg.com> Also needs to move operational guidance to BCP
[17:11:57] <hardie@jabber.psg.com> From there to WGLC
[17:13:06] <hardie@jabber.psg.com> Brian says that he is not sure whether publishing now is useful; he says put it on ice until the protocol goop is done, so that we know whether we got it right
[17:13:45] <hardie@jabber.psg.com> Raj, Rohan, Richard Barnes volunteer to review the -01
[17:14:04] <hardie@jabber.psg.com> Andy asks if waiting means until *all* the work is done?
[17:14:06] <hardie@jabber.psg.com> Brian says yes
[17:14:13] <hardie@jabber.psg.com> Andy says waiting that much not useful
[17:14:38] --- dumdidum has joined
[17:15:00] <cullenfluffyjennings@gmail.com> Brian - glad work is done - just want to wait for protocols until done
[17:15:08] <hardie@jabber.psg.com> Hannes says that we had this discussion before, and brian argued the other is done
[17:15:27] --- keyajima has joined
[17:15:30] <cullenfluffyjennings@gmail.com> Henning - comprimise - when we have the bits nailed down of the protocols, they shut lid and ship it off
[17:15:49] --- hb47713 has left
[17:16:02] <cullenfluffyjennings@gmail.com> JDR - With brian - looked at prvision version - this is hard stuff - think it will take some cycles to make sure we got ti right
[17:16:19] <cullenfluffyjennings@gmail.com> Switching to Brian Rosen ecrit -framework document
[17:16:35] <cullenfluffyjennings@gmail.com> main changes moving text betwwen framewokr and phonebcp
[17:16:43] <cullenfluffyjennings@gmail.com> normative text in phonebcp
[17:16:43] --- dcrocker has left
[17:16:51] <cullenfluffyjennings@gmail.com> big picture is in framework
[17:17:15] <cullenfluffyjennings@gmail.com> (On the Changes since last version slide)
[17:17:37] <cullenfluffyjennings@gmail.com> Onto open issues slides
[17:17:45] <cullenfluffyjennings@gmail.com> Issues on Marking -
[17:17:51] <cullenfluffyjennings@gmail.com> have not had enough review yet
[17:17:55] <cullenfluffyjennings@gmail.com> not ready for WGLC
[17:18:06] <cullenfluffyjennings@gmail.com> need to check mechismsi are going to work and need to wait
[17:18:35] <cullenfluffyjennings@gmail.com> Hannes - charter says need to be done by Decemebr
[17:18:53] <cullenfluffyjennings@gmail.com> Would like to get feedback from external org but for that it needs to be good
[17:19:17] <cullenfluffyjennings@gmail.com> Asking for exper review
[17:19:33] <cullenfluffyjennings@gmail.com> peter volentteered ???
[17:19:44] --- miki has joined
[17:19:51] <cullenfluffyjennings@gmail.com> Jonathan, Peter B,
[17:20:08] <cullenfluffyjennings@gmail.com> Andy on markinging issues
[17:21:04] <cullenfluffyjennings@gmail.com> Brian - the marking will be in both framework and phonebcp
[17:21:17] <cullenfluffyjennings@gmail.com> Marking is only known open issue
[17:21:31] <cullenfluffyjennings@gmail.com> Would like to talk as agenda item
[17:21:45] <cullenfluffyjennings@gmail.com> Keith D - Do we need to say anything about callback of emergcy calls
[17:22:08] <cullenfluffyjennings@gmail.com> Brain - 2 issues - call back identer and marking the call back call or are they maked
[17:22:16] <cullenfluffyjennings@gmail.com> First done, second part of marking issue
[17:22:21] <cullenfluffyjennings@gmail.com> Moving on to phonecp
[17:22:26] <cullenfluffyjennings@gmail.com> On the what changed slide
[17:22:53] <cullenfluffyjennings@gmail.com> Added stuff for pringle cans, lies, lies, and damm lies
[17:23:09] <cullenfluffyjennings@gmail.com> We need the comunity to reivew
[17:23:23] <cullenfluffyjennings@gmail.com> Hannes : Will need to send to other organizations
[17:23:44] <cullenfluffyjennings@gmail.com> Keith - there are requirements ffrom Japan around identity which we are not reiviwing
[17:24:08] <cullenfluffyjennings@gmail.com> Keith - we need to do international - if there are requirements we can't meet, we need it in this doc
[17:25:35] <cullenfluffyjennings@gmail.com> The draft has requirements for phone and proxy and we might need to change name. No plan to break into two documents - should give guidance to carrier or enteriprise of what they need to do - if it does nto do this, Mail to listg and we will fix
[17:26:18] <hardie@jabber.psg.com> DHCP LoST Discovery Procedure - Henning Schulzrinne
[17:26:18] <cullenfluffyjennings@gmail.com> Moving on DHCP based LOST
[17:26:39] <hardie@jabber.psg.com> He notes that there may be multiple solutions
[17:26:51] <hardie@jabber.psg.com> DHCP is an easy case, but it will not always work
[17:27:08] <hardie@jabber.psg.com> (e.g. when the access network is not the provider)
[17:27:29] <hardie@jabber.psg.com> Overview: option, len, 1035 label sequence
[17:28:10] <hardie@jabber.psg.com> He has contacted the dhc chairs, and they agree that this is the right way to deal with dns names in dhcp
[17:28:33] <hardie@jabber.psg.com> Major change: one server returned, cannot use multiple options, concatenated
[17:28:57] <hardie@jabber.psg.com> Other options (e.g. NAPTR) if you need ore
[17:29:08] <hardie@jabber.psg.com> Joint last call with DHC would be required?
[17:29:10] <hardie@jabber.psg.com> yes
[17:29:49] <hardie@jabber.psg.com> Hannes said that they had talked to DHC chairs, and agreed on a review mechanism.
[17:29:58] <hardie@jabber.psg.com> Asked for folks who have read the draft--a dozen or so?
[17:30:11] <hardie@jabber.psg.com> First ask whether it should be a working group item.
[17:30:27] <hardie@jabber.psg.com> First question--should it be a working group item?
[17:30:34] <hardie@jabber.psg.com> That is approved
[17:30:47] <hardie@jabber.psg.com> Further processing from there.
[17:31:41] <hardie@jabber.psg.com> James Polk comes to the front
[17:32:52] <hardie@jabber.psg.com> Resource priority header for emergency calling
[17:33:04] <hardie@jabber.psg.com> (sorry, no pointer yet)
[17:33:10] <hardie@jabber.psg.com> Fred&Barney
[17:33:27] <hardie@jabber.psg.com> sos, ecrit, psap, les are other potential namespaces
[17:34:28] <hardie@jabber.psg.com> Resource priority headers require a standards track rfc
[17:34:45] <hardie@jabber.psg.com> esc and puc are the other namespace proposals
[17:35:05] <hardie@jabber.psg.com> wild aspects: multiple priorities?
[17:35:16] <hardie@jabber.psg.com> That is not a solid proposal
[17:35:16] --- cullenfluffyjennings@gmail.com has left
[17:36:14] <hardie@jabber.psg.com> Can be taken out, if people think that it is unlikely that the psap-to-psap will cross paths with others
[17:36:48] <hardie@jabber.psg.com> Jonathan says he believes that this will be redundant to other markings, without as good as authorization
[17:37:06] <hardie@jabber.psg.com> Using the uri seems better, since it is unspoofable
[17:37:21] <hardie@jabber.psg.com> Jonathan asks to be marked opposed, because of the authorization problem
[17:37:49] <hardie@jabber.psg.com> Henning restates his objection from the mailing list--this conflates user-to-authority and authority-to-authority is a problem
[17:38:45] <hardie@jabber.psg.com> Henning also shares the concern with allowing this as the marking of emergency calls
[17:38:56] <hardie@jabber.psg.com> Bundling this with authorization seems required
[17:40:04] <hardie@jabber.psg.com> Brian Stucker adds that this would not be an authorization problem if used in callbacks
[17:40:22] --- mlepinski has left
[17:41:43] --- hardie@jabber.psg.com has left
[17:42:21] --- Antoin has left
[17:47:44] --- lemmakin has left
[17:51:58] --- miki has left
[17:54:12] --- anewton has left
[17:54:57] --- ttfr has left
[17:59:18] --- richard.barnes has left
[18:00:45] --- jr111 has left
[18:01:02] --- keyajima has left
[18:01:51] --- florent.parent@gmail.com has left
[18:02:15] --- Barbara has left
[18:03:57] --- ysuzuki has left
[18:06:46] --- rwatro has left
[18:10:21] --- dumdidum has left
[18:10:53] --- nan_626 has left: Disconnected.
[18:13:18] --- spencerdawkins has left
[18:14:48] --- ysuzuki has joined
[18:18:06] --- miki has joined
[18:18:14] --- miki has left
[18:27:24] --- isudo has joined
[18:31:54] --- ysuzuki has left
[18:35:24] --- isudo has left: Replaced by new connection
[18:41:11] --- Jabber-Wile has joined
[18:43:00] --- Jabber-Wile has left