Subject: [Ecrit] Consensus Call: Precise Location Information not available to End Host

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 20 Apr 2007 10:50:01 +0200

Hi all, 

let me try it again (I got it wrong in my previous mail). 

Henning and Brian suggested an approach that 
* works nicely with the emergency services architecture we
investigated over the past few years, and
* addresses the case where a network operator 
does not want to disclose precise location information. 

Here is the procedure:

1. The endpoint uses an LCP to request location.  The LIS returns an LbyR
2. The endpoint dereferences the LbyR.  
3. The LIS, noticing that the dereference request is from the endpoint (or
at least not from any entity that is entitled to get fine grained location),
takes the fine grained location and uses LoST to determine the PSAP that
serves that location.
4. The LIS returns to the endpoint a location which, if submitted to LoST,
would return the same PSAP URI the fine grained location would.  In some
circumstances, this could be a civic with only a country.  An alternative
that works for all circumstances is to return the polygon that defines the
service boundary of the PSAP (which LoST can return).  Is essential that the
PSAP URI returned from a LoST query with whatever the LIS gives the endpoint
would be the same PSAP URI any querier using the fine grained location would
get.
5. The endpoint uses the (coarse) location value it obtains to query LoST.
It gets the (correct) PSAP URI
6. This is repeated at call time.  The endpoint has a valid LbyR and a valid
PSAP URI, which it uses to construct the emergency call
7. A VSP wishing to validate the PSAP URI takes the LbyR and dereferences
it.  The result will be the same (coarse) location the endpoint got.  The
VSP does a LoST query with that location, and should get the same PSAP URI
that is in the Request URI on the call.  This validation works for coarse or
fine validation, and of course works for LbyV without the dereference step.
8. The PSAP (or ESRP) which is the target of the PSAP URI gets the call.  It
dereferences the LbyR but gets the fine grained location; the LIS must have
a relationship with the ESRP/PSAP to assure this.
9. Any succeeding ESRPs or PSAPs can also dereference and get fine grained
location.

QUESTION: Is this approach acceptable for you? 

Ciao
Hannes

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Liess, Laura" <[email-masked]>
Date: Fri, 20 Apr 2007 12:31:54 +0200

Hi,

> Here is the procedure:
> 
> 1. The endpoint uses an LCP to request location.  The LIS
> returns an LbyR 2. The endpoint dereferences the LbyR.  
> 3. The LIS, noticing that the dereference request is from the 
> endpoint (or at least not from any entity that is entitled to 
> get fine grained location), takes the fine grained location 
> and uses LoST to determine the PSAP that serves that 
> location. 4. The LIS returns to the endpoint a location 
> which, if submitted to LoST, would return the the same PSAP URI 
> the fine grained location would or . In some circumstances, this 
> could be a civic with only a country.  An alternative that 
> works for all circumstances is to return the polygon that 
> defines the service boundary of the PSAP (which LoST can 
> return).  Is essential that the PSAP URI returned from a LoST 
> query with whatever the LIS gives the endpoint would be the 
> same PSAP URI any querier using the fine grained location 
> would get. 5. The endpoint uses the (coarse) location value 
> it obtains to query LoST. It gets the (correct) PSAP URI 6. 

Does this mean that if for a country the LOST directory has an entry DE
resolving to an ESRP_DE, more fine grained LOST entries as Frankfurt
either a)must  resolve to the same ESRP_DE as the DE entry or b)if the
Frankfurt entry resolves to a local PSAP-_Frankfurt every ASP/ISP MUST
return for locations in Frankfurt the local PSAP_Frankfurt or c) there
are no more fine grained entries? 

Or did I miss something? 

Thanks a lot
Laura

> This is repeated at call time.  The endpoint has a valid LbyR
> and a valid PSAP URI, which it uses to construct the 
> emergency call 7. A VSP wishing to validate the PSAP URI 
> takes the LbyR and dereferences it.  The result will be the 
> same (coarse) location the endpoint got.  The VSP does a LoST 
> query with that location, and should get the same PSAP URI 
> that is in the Request URI on the call.  This validation 
> works for coarse or fine validation, and of course works for 
> LbyV without the dereference step. 8. The PSAP (or ESRP) 
> which is the target of the PSAP URI gets the call.  It 
> dereferences the LbyR but gets the fine grained location; the 
> LIS must have a relationship with the ESRP/PSAP to assure 
> this. 9. Any succeeding ESRPs or PSAPs can also dereference 
> and get fine grained location.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 20 Apr 2007 07:44:39 -0400

> are no more fine grained entries?

I'm not really sure I understand your question, but let me tell you how I
think this will work in North America:

There will be state level ESRPs (we won't be able to have a national ESRP,
and we probably wouldn't want one anyway).  All calls in New Jersey would go
to the New Jersey ESRP.  The LoST entries for every location in New Jersey
will have the New Jersey ESRP as the URI.

The New Jersey ESRP will have another service, which will only be available
inside the Emergency Services IP Network, and thus to any ESRP or PSAP in
New Jersey, which supplies the URI of the actual PSAP that gets the call.
The ESRP will make a LoST query with that service to route the call onward.
That same mechanism will be used by the PSAP to query for the responder
agencies (police, fire, ems).  A regular LoST query to
urn:service:sos.police would return the New Jersey ESRP. 

In some areas, there will be a second level of ESRP, perhaps at the county
level.  The state ESRP will route to the county ESRP, the county ESRP will
route to PSAP.

This means that the LIS will effectively reveal the state the caller is in,
but not the city, since the service boundary returned by LoST for
urn:service:sos would be the state boundary.  Of course in a smaller
country, you may have a country level ESRP.

Does that answer your question?  If it does not, perhaps you could explain
what you mean more fully.

Brian

---

From: "Liess, Laura" <[email-masked]>
Date: Fri, 20 Apr 2007 16:36:46 +0200

Brian,

yes, that answers my question and I am OK with this approach. 

Thanks a lot
Laura   

> -----Ursprüngliche Nachricht-----
> Von: Brian Rosen [mailto:[email-masked]] 
> Gesendet: Freitag, 20. April 2007 13:45
> An: Liess, Laura; [email-masked]; [email-masked]
> Betreff: RE: [Ecrit] Consensus Call: Precise Location 
> Information notavailable to End Host
> 
> 
> > Does this mean that if for a country the LOST directory has 
> an entry 
> > DE resolving to an ESRP_DE, more fine grained LOST entries as 
> > Frankfurt either a)must  resolve to the same ESRP_DE as the 
> DE entry 
> > or b)if the Frankfurt entry resolves to a local 
> PSAP-_Frankfurt every 
> > ASP/ISP MUST return for locations in Frankfurt the local 
> > PSAP_Frankfurt or c) there are no more fine grained entries?
> 
> I'm not really sure I understand your question, but let me 
> tell you how I think this will work in North America:
> 
> There will be state level ESRPs (we won't be able to have a 
> national ESRP, and we probably wouldn't want one anyway).  
> All calls in New Jersey would go to the New Jersey ESRP.  The 
> LoST entries for every location in New Jersey will have the 
> New Jersey ESRP as the URI.
> 
> The New Jersey ESRP will have another service, which will 
> only be available inside the Emergency Services IP Network, 
> and thus to any ESRP or PSAP in New Jersey, which supplies 
> the URI of the actual PSAP that gets the call. The ESRP will 
> make a LoST query with that service to route the call onward. 
> That same mechanism will be used by the PSAP to query for the 
> responder agencies (police, fire, ems).  A regular LoST query 
> to urn:service:sos.police would return the New Jersey ESRP. 
> 
> In some areas, there will be a second level of ESRP, perhaps 
> at the county level.  The state ESRP will route to the county 
> ESRP, the county ESRP will route to PSAP.
> 
> This means that the LIS will effectively reveal the state the 
> caller is in, but not the city, since the service boundary 
> returned by LoST for urn:service:sos would be the state 
> boundary.  Of course in a smaller country, you may have a 
> country level ESRP.
> 
> Does that answer your question?  If it does not, perhaps you 
> could explain what you mean more fully.
> 
> Brian
> 
>

---

From: Andrew Newton <[email-masked]>
Date: Fri, 20 Apr 2007 11:16:04 -0400

> QUESTION: Is this approach acceptable for you?

I'm not sure you want us to chime in again, but yes.

-andy

---

From: Richard Barnes <[email-masked]>
Date: Fri, 20 Apr 2007 11:22:10 -0400

Hannes,

I haven't had time to keep up with the hailstorm of discussion, but I 
have a several concerns about this approach:

1. Confusion over location semantics
This approach has two different types of location objects (LbyV) -- one 
that describes the actual location of the endpoint, and one that guides 
the LoST query.  This makes me worry about the two getting mixed up: 
E.g., LIS provides not a service boundary (too big) but an arbitrary 
point within the service boundary, and PSAP routes first responders to 
that point.  Even requiring that the LIS always provide a service 
boundary isn't enough, since the party that consumes the LO has no way 
to know that it's a service boundary and not an estimate of the hosts 
location.  So there needs to be some explicit syntax here to 
differentiate these two cases (e.g., a "service-boundary" tag on the LO 
or on the Geolocation header, or a Service-area: SIP header).

2. Assumptions about the LIS (privacy concerns)
This approach assumes that the LIS is willing to give out any location 
information at all to unauthenticated/unauthorized parties (e.g., the 
client and the VSP).  I think this is a big assumption: Since a VSP can 
be any host on the Internet (from the LIS's perspective), this approach 
requires the LIS to give information on a client's location to anyone on 
the internet, a massive privacy risk.  Moreover, if a client runs into a 
LIS that doesn't give out course location (for whatever reason), then 
it's out of luck -- it has no idea where to turn for help.

3. Mixing of LoST and Location Dereference
This approach requires the LIS to do a LoST query with only location -- 
without any knowledge of what service is desired.  For example: Even if 
it queries for all available services, it could get back different 
service areas for each -- which service area should it return to the 
client?  It can't return the union (that would lead to LoST mis-routes), 
and returning the intersection adds to the granularity of the location 
provided.

So, I guess in summary,
 > QUESTION: Is this approach acceptable for you?
No.

--Richard

Hannes Tschofenig wrote:
> Henning and Brian suggested an approach that * works nicely with the 
> emergency services architecture we
> * addresses the case where a network operator does not want to disclose 
> precise location information.
> Here is the procedure:
> 
> 2. The endpoint dereferences the LbyR.  3. The LIS, noticing that the 
> dereference request is from the endpoint (or

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 20 Apr 2007 11:36:52 -0400

On Apr 20, 2007, at 11:22 AM, Richard Barnes wrote:

> Hannes,
>
> I haven't had time to keep up with the hailstorm of discussion, but  
> I have a several concerns about this approach:
>
> This approach has two different types of location objects (LbyV) --  
> one that describes the actual location of the endpoint, and one  
> that guides the LoST query.  This makes me worry about the two  
> getting mixed up: E.g., LIS provides not a service boundary (too  
> big) but an arbitrary point within the service boundary, and PSAP  
> routes first responders to that point.  Even requiring that the LIS  
> always provide a service boundary isn't enough, since the party  
> that consumes the LO has no way to know that it's a service  
> boundary and not an estimate of the hosts location.  So there needs  
> to be some explicit syntax here to differentiate these two cases  
> (e.g., a "service-boundary" tag on the LO or on the Geolocation  
> header, or a Service-area: SIP header).

This doesn't seem fundamentally different from having a wireless  
provider provide the outline of a sector or other large coverage  
region. We have not proposed a separate label for that.

> This approach assumes that the LIS is willing to give out any  
> location information at all to unauthenticated/unauthorized parties  
> (e.g., the client and the VSP).  I think this is a big assumption:  
> Since a VSP can be any host on the Internet (from the LIS's  
> perspective), this approach requires the LIS to give information on  
> a client's location to anyone on the internet, a massive privacy  
> risk.  Moreover, if a client runs into a LIS that doesn't give out  
> course location (for whatever reason), then it's out of luck -- it  
> has no idea where to turn for help.

You seem to be mis-understanding the proposal. The LIS only hands out  
location information sufficient to identify the PSAP/ESRP to  
unauthenticated users. All proposals so far have involved handing out  
the PSAP URL, so this is exactly equivalent in terms of location  
revealed.

> This approach requires the LIS to do a LoST query with only  
> location -- without any knowledge of what service is desired.  For  
> example: Even if it queries for all available services, it could  
> get back different service areas for each -- which service area  
> should it return to the client?  It can't return the union (that  
> would lead to LoST mis-routes), and returning the intersection adds  
> to the granularity of the location provided.

Again, this seems to be a misreading of the proposal. The LIS makes  
no LoST queries in this proposal; the UA does this as normal.

> > QUESTION: Is this approach acceptable for you?

If you have alternatives that satisfy the requirements and has a  
precise description of behavior that includes both hiding and non- 
hiding cases, please describe it. So far, alternatives have all  
failed one or more of:

- No business or trust relationship between ISPs and VSPs.

- VSPs can be outside the jurisdiction of the PSAP and can be Joe's  
Bakery and Car Repair.

- No magic configuration for UAs.

- Multiple LoST server hierarchies, with resolvers that have no trust  
relationship with the PSAP or the ISP.

- Minimal impact on UAs; in particular, fail-and-try-something-else  
is not acceptable.

Bonus points for avoiding modifications to LoST, SIP location  
conveyance, DHCP.

I'm not claiming elegance for the solution, but "least bad" status.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 20 Apr 2007 11:42:19 -0400

Woah Nellie.

You don't understand the proposal.

The endpoint gets an LbyR.  It can dereference to get an LbyV, but it puts
the LbyR on the call.  That should be normal behavior.  No one forwards the
LbyV to anyone.  If they have permission, they forward the LbyR.

As we have observed, you have to treat an LbyR with the same degree of care
you treat an LbyV.  No one hands out the LbyR to anyone except as per the
user's privacy policy (as modified by local laws, which apply in the
emergency case). 

The LIS provides the polygon as the location, not a point in it.  The target
is somewhere in the polygon.  This polygon is an acceptable location to
route emergency calls on; if used in a LoST query (by the endpoint for
example), it will yield the correct PSAP URI.

It is true that we are dependent on the LIS giving out coarse location to
its subscriber.  We are asking access network operators if that is
acceptable.  So far, it appears they are okay.  If you know different,
please cite an example.  If they refuse to supply any form of location, the
whole scheme fails.  I note that if they give out a PSAP URI, that is
equivalent to the polygon we are talking about.  Regardless of who does the
LoST query, if the endpoint gets back a PSAP URI, they can, with little
effort, determine the coarse location.

There is a pretty simple fix for the boundary-per-service issue.  The
algorithm used by LoST to deal with a polygon as input is defined.  The LIS
can produce a polygon that yields a correct answer for all the services
while still providing quite coarse location.  It's a little more work for
the LIS, but not a whole lot.   It could return a point, but I think that
would be very misleading and it should not do that.

Brian

> -----Original Message-----
> From: Richard Barnes [mailto:[email-masked]]
> Sent: Friday, April 20, 2007 11:22 AM
> To: Hannes Tschofenig
> Cc: ECRIT
> Subject: Re: [Ecrit] Consensus Call: Precise Location Information not
> availableto End Host
> 
> Hannes,
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 20 Apr 2007 12:10:24 -0400

> provider provide the outline of a sector or other large coverage region. 
> We have not proposed a separate label for that.

The fundamental difference is that a sector (or similar region) is 
intended to communicate the location of the endpoint, whereas the 
location returned by the LIS in response to an unauthorized dereference 
request is intended, in effect, to communicate the identity of a PSAP. 
Depending on both of these semantics without clear differentiation risks 
confusing the two purposes, and is an abuse of location by reference to 
effectively do LoST.

> the PSAP URL, so this is exactly equivalent in terms of location revealed.

You're correct, provided that only one service area or PSAP URL is 
handed out, or that all PSAP URLs or service areas returned are the 
same.  However, where there are several autonomous emergency services 
with different service areas, the service returned has to be the 
intersection of all these service areas, to ensure that LoST routing 
works right for all of them.  Depending on how service areas overlay, 
this could be a small area.

This wouldn't be a big problem, except that this area doesn't just get 
returned to the client, but to any unauthenticated/unauthorized 
dereference client.  The client has no control over how his location 
information (in this rough form) is disseminated.

> Again, this seems to be a misreading of the proposal. The LIS makes no 
> LoST queries in this proposal; the UA does this as normal.

Hannes' description says that the LIS "takes the fine grained location 
and uses LoST to determine the PSAP that serves that location," but I 
understand your point; the LIS doesn't necessarily need to do a LoST 
query for every dereference.  Nonetheless, the LIS needs some way to 
determine what service area(s) to return, so it will likely need to use 
LoST at some point.

> If you have alternatives that satisfy the requirements and has a precise 
> description of behavior that includes both hiding and non-hiding cases, 
> please describe it. 

I've proposed one alternative, but I think I need to restate myself more 
clearly.  I'll give another try in a separate message.

--Richard

> So far, alternatives have all failed one or more of:
> 
> - Minimal impact on UAs; in particular, fail-and-try-something-else is 
> not acceptable.
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 20 Apr 2007 12:25:56 -0400

> LbyV to anyone.  If they have permission, they forward the LbyR.

I agree that not transmitting the LbyV helps somewhat, since it forces 
location recipients to dereference.  But in the end, it doesn't really 
matter if the LbyV gets transmitted or not, since any party that wants 
it can get it by dereferencing the LbyR.

> user's privacy policy (as modified by local laws, which apply in the

As has been argued before (and I thought we agreed in the LbyR design 
team), this is not a tenable as a universal policy.  E.g., SIP has no 
protection for headers, so any eavesdropper to a SIP call would have 
access to an LbyR included in a Geolocation header.  In addition, since 
the LbyR has no syntax for privacy rules, such a policy would force 
everyone who receives an LbyR to dereference it before doing anything 
with it.

> example), it will yield the correct PSAP URI.

This would need to be specified to be the case.  Hannes' description 
just said that the LIS returns "a location which, if submitted to LoST,
would return the same PSAP URI the fine grained location would."  By 
this description, it could very well be any random point in the service 
area.

> please cite an example.  

I don't know different, but the operator's opinion is only half of the 
story.  It also needs to be OK with the client/target that the 
coarse-grained location get distributed.

> If they refuse to supply any form of location, the

When an endpoint does LoST with an LbyV, its location remains 
confidential to it and the LoST infrastructure; it only reveals its 
coarse location at emergency call time, and then only to entities that 
handle the call.  By contrast, if any unauth'ed dereference gives a PSAP 
service area, then this level of location is available to anyone who 
knows or can guess the LbyR, at all times.

A concrete example: Suppose I'm a location-based service operator, and 
the client provided his LbyR to me at one time.  Now, at any time 
thereafter, I can dereference that LbyR to get a coarse idea of his 
location.  This lets me wait until he leaves town to go and break into 
his house.  And the client has no way to turn this off.

> would be very misleading and it should not do that.

As I think about it, in order to ensure proper routing, the LIS would 
need to return the intersection of all the service boundaries, or a 
subset of it.  But as I've said, this introduces extra granularity into 
a location that is universally available.  I do agree that returning a 
point is a bad idea, but this would need to be specified.

--Richard

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 20 Apr 2007 11:27:46 -0500

Hannes

What you are detailing is a technical solution to a business 
decision, not a technical solution to a technical 
problem/requirement.  I am opposed to this compromise (i.e. cave).

At 03:50 AM 4/20/2007, Hannes Tschofenig wrote:
>* addresses the case where a network operator does not want to 
>disclose precise location information.
>Here is the procedure:
>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 20 Apr 2007 12:40:22 -0400

Correct me if I'm wrong, but I think you are objecting to LbyR, and not this
compromise on hiding location.  An LbyR which, when dereferenced by anyone,
would provide fine grained location has all of the issues you describe
(except the last issue on multiple services).  To address them, we would
have to not provide LbyR, right?

The algorithm in LoST to route on a polygon computes a centroid and routes
on the centroid.  A suitable algorithm would be to intersect all the
boundaries to create the largest polygon which is contained in all the
service boundaries, pick any point in that polygon, and return a circle with
that point as the center and a radius of 50kM.  The target would be within
that circle, and every service would yield the correct URI when that circle
was input to the LoST server.

Brian

> Sent: Friday, April 20, 2007 12:26 PM
> To: Brian Rosen
> Cc: 'Hannes Tschofenig'; 'ECRIT'
> >>> service boundary of the PSAP (which LoST can return).  Is essential
> that
> >>> the

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 20 Apr 2007 13:00:55 -0400

James,

I'm no friend of location hiding, as I've made amply clear, but I was  
trying to find a solution that does not actually impose any new  
requirements on user agents nor makes life more expensive for the  
rest of the world.

So far, all the alternatives I've seen either yield non-interoperable  
islands or impose cost shifting, where innocent third parties pay for  
the business decisions of the ISP. I'd like the requirement to go  
away, but it has apparently been a very convenient rationale for not  
playing along with the whole ECRIT architecture.

Henning

On Apr 20, 2007, at 12:27 PM, James M. Polk wrote:

> decision, not a technical solution to a technical problem/ 
> requirement.  I am opposed to this compromise (i.e. cave).
>
>> Henning and Brian suggested an approach that * works nicely with  
>> the emergency services architecture we
>> endpoint (or

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 20 Apr 2007 12:08:59 -0500

Henning

Doesn't this center around either location is given to the client for 
free or for fee?

If we agree there can be a fee, even if hidden (because service 
customers always end up paying for everything explicitly or 
implicitly), doesn't this "requirement" go away in most people's minds?

This was the point of Barbara last week - that AT&T is not going to 
deliver location for free. I don't think anyone I'm aware of 
suggested this infrastructure be put in place for free, to be used by 
other service companies for their use only.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 20 Apr 2007 13:28:20 -0400

If the requirement goes away, either by regulation or by paying a  
fee, no harm is done. As I said, the UA won't even notice. Thus, I  
consider this as "insurance" - it allows us to move forward and close  
our documents, rather than speculate what may or may not happen a  
year or two or five down the road. Your guess may well be right, but  
it remains, like my predictions on the ability to monetize location  
information, a prediction with high uncertainty. We all want to see  
IP-based emergency calling deployed sooner rather than after years of  
regulatory fights, particularly fights where the deck is stacked not  
necessarily in the consumer's favor. This is a (very small)  
contribution to removing one item to fight over.

If there were huge (complexity or infrastructure) costs associated  
with the proposal, I would share your concerns. But there aren't, as  
far as I can tell.

Henning

On Apr 20, 2007, at 1:08 PM, James M. Polk wrote:

> Henning
>
> Doesn't this center around either location is given to the client  
> for free or for fee?
>
> suggested this infrastructure be put in place for free, to be used  
> by other service companies for their use only.
>

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 20 Apr 2007 14:13:41 -0500

Henning

Please explain steps #4 & 5.  How does a course location return the 
Colleyville, Texas PSAP URI, or even the Tarrant county ESRP URI?

I live in Colleyville, Texas, one of 47 cities in Tarrant County - 
which contains Forth Worth (next to Dallas), for those wanting to 
understand the references I'm using. Each city in Tarrant county has 
a PSAP today. The metro area of Dallas/Ft. Worth (DFW) has an ERC 
that answers all 911 cell calls due to non-compliance with wireless 
phase I or II.

In all this, I'm wondering how my state level precision (suggested 
below as "the solution") gets my emergency call to where I want it to 
before I or a family member dies.

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 20 Apr 2007 15:27:47 -0400

This is more a question for NENA than IETF.

There probably WILL be a Texas ESRP, and all locations in Texas probably
will route to the Texas ESRP.

The Texas ESRP will do another LoST dip using a different service that NENA
will define.  This service, which will only operate within the Emergency
Services IP network where the ESRP is located, will return, possibly, a
Tarrant County ESRP URI.  The Tarrant County ESRP will do a similar
operation and return the Colleyville URI.  Each of the ESRPs will have to
dereference the LbyR, and each will query LoST.  The LIS will cache the
dereference result, so its response will be fast. 

Actually, I suspect that Tarrant County will not operate an ESRP, and the
Texas ESRP will route directly to Colleyville, but that is up to the Tarrant
County 9-1-1 Authority.  I know those guys, and they are up to speed on most
of this already.  You may very well have one of the first real "i3"
installations (although the Harris County guys may beat you).

Brian 

> From: James M. Polk [mailto:[email-masked]]
> Sent: Friday, April 20, 2007 3:14 PM
> To: Henning Schulzrinne
> Cc: ECRIT
> Subject: Re: [Ecrit] Consensus Call: Precise Location Information
> notavailable to End Host
> 
> Henning
>

---

From: Andrew Newton <[email-masked]>
Date: Fri, 20 Apr 2007 15:50:28 -0400

After having some more time to noodle on this...

> fine validation, and of course works for LbyV without the  

This works without modification of LoST for civic, but I think it  
requires a modification of LoST for geo.  The LoST geodetic-2d  
location profile takes a point as input, not an area.

That being said, I'm willing to live with the change to LoST to  
accommodate this requirement.  We could create a new location profile  
or modify geodetic-2d, but then every geodetic (or non-civic)  
location profile would have to accommodate this use case.  If we are  
to do this, I'd rather have a more generic mechanism that requires no  
changes to location profiles by re-using the service boundary  
reference.  Such a service boundary reference could be conveyed in a  
PIDF-LO in a new element.  That also allows LoST resolvers to  
optimize their lookup to a simple key vs. the more complex location  
information.  The VSP wouldn't use the <findService> query for  
policing, but the <getServiceBoundary> query.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 20 Apr 2007 16:21:43 -0400

We had talked about a more generic 2D polygon description earlier,  
primarily for wireless cases, so we may just get to do it now rather  
than later.

We already have the necessary location profile (polygon), as it is  
used for the boundary.

I don't see how re-using the service boundary reference helps. The UA  
still has to understand the reference and polygon. Can you describe  
exactly how this would work? I'd rather avoid special-casing this  
particular use case ("do one thing when you get a reference to a  
point, do something completely different when you get a reference to  
a polygon").

On Apr 20, 2007, at 3:50 PM, Andrew Newton wrote:

> accommodate this requirement.  We could create a new location  
> profile or modify geodetic-2d, but then every geodetic (or non- 
> civic) location profile would have to accommodate this use case.   
> If we are to do this, I'd rather have a more generic mechanism that  
> requires no changes to location profiles by re-using the service  
> boundary reference.  Such a service boundary reference could be  
> conveyed in a PIDF-LO in a new element.  That also allows LoST  
> resolvers to optimize their lookup to a simple key vs. the more  
> complex location information.  The VSP wouldn't use the  
> <findService> query for policing, but the <getServiceBoundary> query.
>
> -andy
>

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 20 Apr 2007 15:51:38 -0400

This is ok for me.
Barbara 

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Friday, April 20, 2007 4:50 AM
To: ECRIT
Subject: [Ecrit] Consensus Call: Precise Location Information not
available to End Host

Hi all, 

Henning and Brian suggested an approach that
* works nicely with the emergency services architecture we investigated
over the past few years, and
* addresses the case where a network operator does not want to disclose
precise location information. 

Here is the procedure:

1. The endpoint uses an LCP to request location.  The LIS returns an
LbyR 2. The endpoint dereferences the LbyR.  
3. The LIS, noticing that the dereference request is from the endpoint
(or at least not from any entity that is entitled to get fine grained
location), takes the fine grained location and uses LoST to determine
the PSAP that serves that location.
4. The LIS returns to the endpoint a location which, if submitted to
LoST, would return the same PSAP URI the fine grained location would.
In some circumstances, this could be a civic with only a country.  An
alternative that works for all circumstances is to return the polygon
that defines the service boundary of the PSAP (which LoST can return).
Is essential that the PSAP URI returned from a LoST query with whatever
the LIS gives the endpoint would be the same PSAP URI any querier using
the fine grained location would get.
5. The endpoint uses the (coarse) location value it obtains to query
LoST.
It gets the (correct) PSAP URI
6. This is repeated at call time.  The endpoint has a valid LbyR and a
valid PSAP URI, which it uses to construct the emergency call 7. A VSP
wishing to validate the PSAP URI takes the LbyR and dereferences it.
The result will be the same (coarse) location the endpoint got.  The VSP
does a LoST query with that location, and should get the same PSAP URI
that is in the Request URI on the call.  This validation works for
coarse or fine validation, and of course works for LbyV without the
dereference step.
8. The PSAP (or ESRP) which is the target of the PSAP URI gets the call.
It dereferences the LbyR but gets the fine grained location; the LIS
must have a relationship with the ESRP/PSAP to assure this.
9. Any succeeding ESRPs or PSAPs can also dereference and get fine
grained location.

Ciao
Hannes

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

---

From: Andrew Newton <[email-masked]>
Date: Fri, 20 Apr 2007 17:29:54 -0400

Well, the point I was trying to make was that each new location  
profile would have to account for location providing.  So, if we do  
geodetic-3d or rfc3825 or linser-locrel or whatever else comes along,  
we have to account for the fact that output has to also be the  
input.  I know that may not be such a big deal, but we never really  
know.  A simple key is easier on databases than the complex searching  
needed for location information, especially as the location profiles  
get more complex.

I agree about the special case.  But the behavior does not have to be  
a special case, it can be done all the time.  Essentially, a  
reference always exists inside a LoST mapping.  Anytime a LoST  
mapping is converted into a PIDF-LO, such as when the LIS is trying  
to get a the service boundary for a PSAP to use as location  
information, that reference goes along with it.  Later on, a VSP or  
whoever can simply use that reference to check the PSAP URI vs. using  
the location.

I admit, this is an optimization.  But we already have to change LoST  
a little bit.  We might as well try to make the subsequent policing  
against abuse as low cost as possible.

-andy

On Apr 20, 2007, at 4:21 PM, Henning Schulzrinne wrote:

> primarily for wireless cases, so we may just get to do it now  
> rather than later.
>
> I don't see how re-using the service boundary reference helps. The  
> UA still has to understand the reference and polygon. Can you  
> describe exactly how this would work? I'd rather avoid special- 
> casing this particular use case ("do one thing when you get a  
> reference to a point, do something completely different when you  
> get a reference to a polygon").
>
>> If we are to do this, I'd rather have a more generic mechanism  
>> that requires no changes to location profiles by re-using the  
>> service boundary reference.  Such a service boundary reference  
>> could be conveyed in a PIDF-LO in a new element.  That also allows  
>> LoST resolvers to optimize their lookup to a simple key vs. the  
>> more complex location information.  The VSP wouldn't use the

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 20 Apr 2007 19:13:02 -0400

I think one of the objectives should be that a UA can copy location  
information from a PIDF-LO-speaking protocol to LoST without knowing  
anything about the content. It really doesn't care and it won't  
really be able to manipulate location information in any event. I'm  
not sure this is currently as easy as it could be. Obviously, LCP  
can't just dump random stuff into LoST queries, as this is likely to  
fail, but the number of LoST servers is always going to be much  
smaller than the number of clients (and LoST servers are more likely  
to be upgradeable).

On Apr 20, 2007, at 5:29 PM, Andrew Newton wrote:

> geodetic-3d or rfc3825 or linser-locrel or whatever else comes  
> along, we have to account for the fact that output has to also be  
> the input.  I know that may not be such a big deal, but we never  
> really know.  A simple key is easier on databases than the complex  
> searching needed for location information, especially as the  
> location profiles get more complex.
>
> I agree about the special case.  But the behavior does not have to  
> be a special case, it can be done all the time.  Essentially, a  
> whoever can simply use that reference to check the PSAP URI vs.  
> using the location.
>
> I admit, this is an optimization.  But we already have to change  
> LoST a little bit.  We might as well try to make the subsequent  
> policing against abuse as low cost as possible.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 21 Apr 2007 17:25:53 +0200

Hi Andy, 

> > coarse or

You are right. Good catch.

> or modify geodetic-2d,

True. 

 but then every geodetic (or non-civic)  
> location profile would have to accommodate this use case. 

What do you mean? 

 If we are  
> policing, but the <getServiceBoundary> query.

I am not sure about this approach. 

>From a PIDF-LO point of view there is no difference between conveying a point or an area.

Ciao
Hannes

---

From: Andrew Newton <[email-masked]>
Date: Sat, 21 Apr 2007 13:16:06 -0400

>> location profile would have to accommodate this use case.

Every non-civic location type will have to be able to take in the  
equivalent of a service boundary as input.  Assuming exact service  
boundaries are the input every time, we have no problem.  However,  
what's a resolver to do if the input (a polygon in geodetic-2d or  
perhaps an ellipse in geodetic-3d) crosses boundaries, which would  
now be perfectly legal.  We've been down this path before and nobody  
has been able to explain the behavior of this case satisfactorily.

> conveying a point or an area.

Well, I did screw up a few details.  We'd have to define a new LoST  
query, like <getMapping>.  And there is potential for gaming this,  
though I think the whole fraud issue here is not that big of a deal  
(speaking as somebody who will have to deal with it). But this  
approach is less likely to cause a resolver any problems and result  
in faster database lookups during the VSP check.

-andy

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 22 Apr 2007 21:52:36 +0200

Tiny remark:

Henning Schulzrinne wrote:
> anything about the content.

Currently it has to understand at least a little bit since the location 
shapes are much simpler than the stuff provided in
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-06.txt

The translation from DHCP civic is without problems a copy-and-paste 
operation.
The translation from DHCP geo isn't a problem if we do not consider 
compound location information and if we ignore the topic of resolution.
The latter aspect caused a lot of discussion.....

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 22 Apr 2007 21:57:16 +0200

> primarily for wireless cases, so we may just get to do it now rather 
We could do that. That's true.
For the cellular case we could support the full 
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-06.txt. 
I would, however, leave this as an extension for later.
For the service boundary case we could obviously go for a much simpler 
approach.

> We already have the necessary location profile (polygon), as it is 
Yes.
> point, do something completely different when you get a reference to a 
> polygon").

I also believe that defining a new location profile (or extending an 
existing one) would be much simpler.

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 22 Apr 2007 19:34:16 -0500

> has been able to explain the behavior of this case satisfactorily.

There is a solution.  However, there were concerns about the implications of the solution.   That is, forking of LoST queries would be required.  I can't see a way out of that particular problem.
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Andrew Newton <[email-masked]>
Date: Sun, 22 Apr 2007 20:50:33 -0400

On Apr 22, 2007, at 8:34 PM, Thomson, Martin wrote:

>
> There is a solution.  However, there were concerns about the  
> implications of the solution.   That is, forking of LoST queries  
> would be required.  I can't see a way out of that particular problem.

Exactly, we are now full circle back to that problem.

One other point about using a mapping or service boundary reference,  
it allows the data hiding to be as granular or fine as the LIS  
desires.  Currently, the "unauthorized" LbyR cannot be more granular  
than the PSAP service boundary of the endpoint.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Sun, 22 Apr 2007 20:56:44 -0400

On Apr 22, 2007, at 3:57 PM, Hannes Tschofenig wrote:

> I also believe that defining a new location profile (or extending  
> an existing one) would be much simpler.

Can you explain "simpler"?  How do you arrive at that conclusion?   
Defining a new location profile or extending an existing one is  
certainly simpler for the current specification and probably the on- 
the-wire LoST protocol.  But the server implementations are not  
simpler.  At the authoritative server, a "is this polygon inside this  
polygon" query is more compute intensive (though I realize it is just  
an iterative form of "is this point inside this polygon"), and at the  
resolvers there is now the possibility of forking (which might  
require protocol changes anyway).

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 23 Apr 2007 09:15:07 -0400

Maybe I'm dense.  I thought we do a simple geometry calculation that yields
a single result.  That result may not always be correct, but then, no
algorithm we know of would yield a single correct answer.

When we have a true case of uncertainty that creates a situation where the
target could reasonably be in more than one PSAP service area, you pick one,
send the call there and let them deal with it.   It's much more important to
be decisive (and predictable) than to try to achieve perfection if it costs
time and could stress already stressed systems.  You never send the call to
two places.  Flipping a coin is okay if there is roughly equal probability
of being in two service areas.

It should be possible to avoid the problem in the "hiding" case of course;
we're just talking about the consequences of allowing all the shapes in
-profile to be a location.

Brian 

> From: Thomson, Martin [mailto:[email-masked]]
> Sent: Sunday, April 22, 2007 8:34 PM
> To: Andrew Newton; Hannes Tschofenig
> Cc: [email-masked]
> Subject: RE: [Ecrit] Consensus Call: Precise Location Information
> notavailableto End Host
> 
> >
> There is a solution.  However, there were concerns about the implications
> of the solution.   That is, forking of LoST queries would be required.  I
> can't see a way out of that particular problem.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 23 Apr 2007 09:19:25 -0400

I'm less worried about DHCP, but rather about PIDF-LO, as the  
variability and extensibility of that data element is much larger.  
One of the problems is that a device has to mark the location  
information with a profile, instead of just copying the data. I think  
it would be better to have the client provide the LO, and the server  
reject it if can't parse that particular GML-derived format.

This imposes little additional burden on the server, since it will  
have to check the LO in any event. After all, just because the client  
says it's sending 2D-geo doesn't mean that the XML actually contains  
no more than 2D-geo.

We still need to define a set of must-implement profiles for the  
server. Negotiation makes no sense in this case (due to the multi-hop  
nature of LoST), so this set is likely to remain fairly constant over  
long time periods.

(Obviously, a client still has to indicate what kind of service  
region information it understands.)

Henning

On Apr 22, 2007, at 3:52 PM, Hannes Tschofenig wrote:

>> I think one of the objectives should be that a UA can copy  
>> location information from a PIDF-LO-speaking protocol to LoST  
>> without knowing anything about the content.
>
> Currently it has to understand at least a little bit since the  
> location shapes are much simpler than the stuff provided in
> The translation from DHCP civic is without problems a copy-and- 
> paste operation.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 23 Apr 2007 09:22:50 -0400

You just do centroid computation on the location-describing polygon,  
which is very simple for polygons without holes. (Polygons with holes  
are only of interest for service regions, so they don't affect the  
problem in the subject line.)

On Apr 22, 2007, at 8:56 PM, Andrew Newton wrote:

> simpler.  At the authoritative server, a "is this polygon inside  
> this polygon" query is more compute intensive (though I realize it  
> is just an iterative form of "is this point inside this polygon"),  
> and at the resolvers there is now the possibility of forking (which  
> might require protocol changes anyway).
>
> -andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 23 Apr 2007 11:40:22 -0400

Let's not try to solve problems we don't have for this particular  
thread. So far, the location is at least as precise as the PSAP  
boundary.

Otherwise, as we had discussed before, the server takes the centroid  
as the most likely point and uses that for mapping. That works even  
if the location estimate should span multiple service regions. This  
beats returning no answer.

A while ago, I had written a long message as to why computations  
involving anything else (probabilities, etc.) are unlikely to be more  
precise, given the limitations of these approaches.

On Apr 22, 2007, at 8:50 PM, Andrew Newton wrote:

> One other point about using a mapping or service boundary  
> reference, it allows the data hiding to be as granular or fine as  
> the LIS desires.  Currently, the "unauthorized" LbyR cannot be more  
> granular than the PSAP service boundary of the endpoint.
>
> -andy
>

---

From: Andrew Newton <[email-masked]>
Date: Mon, 23 Apr 2007 12:24:34 -0400

On Apr 23, 2007, at 9:19 AM, Henning Schulzrinne wrote:

> information with a profile, instead of just copying the data. I  
> think it would be better to have the client provide the LO, and the  
> server reject it if can't parse that particular GML-derived format.

The entire LO?  I thought it was a part of our requirements that  
identifying information not be sent inside of LoST.  It just needs to  
copy the location information XML.  I don't really understand your  
concern.

BTW, while some of us implicitly understand this, do have it written  
anywhere that RFC 3825 without floor is geodetic-2d and that RFC 4776  
is the civic profile.

> have to check the LO in any event. After all, just because the  
> client says it's sending 2D-geo doesn't mean that the XML actually  
> contains no more than 2D-geo.

I agree.

> server. Negotiation makes no sense in this case (due to the multi- 
> hop nature of LoST), so this set is likely to remain fairly  
> constant over long time periods.

Huh?  Didn't we already discuss this?  geodetic-2d and civic are the  
two base profiles.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Mon, 23 Apr 2007 12:27:39 -0400

On Apr 23, 2007, at 9:22 AM, Henning Schulzrinne wrote:

> You just do centroid computation on the location-describing  
> polygon, which is very simple for polygons without holes. (Polygons  
> with holes are only of interest for service regions, so they don't  
> affect the problem in the subject line.)

I understand your argument.  There is a long, inconclusive email  
thread on it.  Your point about holes actually makes this a bit more  
troublesome though.  What do you mean by service regions?

-andy

---

From: Richard Barnes <[email-masked]>
Date: Mon, 23 Apr 2007 13:36:34 -0400

Could we save time by just having the LCP return both LbyR AND the rough 
location (by value)?

Pros:
+ Avoids dereference overhead
+ Avoids LIS having to authenticate endpoint
+ Avoids some confusion of having a dereference return two different 
values depending on authorization.
+ Think this is already supported by HELD

Cons:
- Don't know how well this works with DHCP

Result would be:
1. The endpoint uses an LCP to request location.
2-4. Unnecessary
5. The endpoint uses the (coarse) location value it obtains to query 
LoST. It gets the (correct) PSAP URI

As for step 7, we need a different mechanism that doesn't rely on rough 
location being returned by an unauthorized dereference.

--Richard

Hannes Tschofenig wrote:
> valid

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 23 Apr 2007 14:04:28 -0400

I don't know if the thread was inconclusive as such. I proposed the  
simple centroid rule, and, if I recall correctly, nobody offered an  
implementable alternative that was provably more accurate and did not  
involve forking.

Service regions is the region returned in the mapping, i.e.,  
<serviceBoundary>.

Holes in that boundary don't affect the centroid-based search. What  
will happen depends a bit on the way the information is stored. In  
simple cases, where the PSAPs serving the hole are stored in the same  
authoritative server (or represented as summaries in those servers),  
a point that hits that hole will generate two matches: the  
surrounding-area PSAP and the more specific one.  The server can then  
inspect the holes registered for the surrounding-area PSAP and  
discover easily that the special-case PSAP for the hole is the right  
answer. There are optimizations you can do to make this efficient, in  
particular since the area of the hole is by definition smaller than  
the surrounding area (without taking the whole into account).

Henning

On Apr 23, 2007, at 12:27 PM, Andrew Newton wrote:

>> polygon, which is very simple for polygons without holes.  
>> (Polygons with holes are only of interest for service regions, so  
>> they don't affect the problem in the subject line.)
>
> thread on it.  Your point about holes actually makes this a bit  
> more troublesome though.  What do you mean by service regions?
>
> -andy

---

From: Andrew Newton <[email-masked]>
Date: Mon, 23 Apr 2007 14:24:39 -0400

On Apr 23, 2007, at 2:04 PM, Henning Schulzrinne wrote:

> simple cases, where the PSAPs serving the hole are stored in the  
> same authoritative server (or represented as summaries in those  
> servers), a point that hits that hole will generate two matches:  
> the surrounding-area PSAP and the more specific one.  The server  
> can then inspect the holes registered for the surrounding-area PSAP  
> and discover easily that the special-case PSAP for the hole is the  
> right answer. There are optimizations you can do to make this  
> efficient, in particular since the area of the hole is by  
> definition smaller than the surrounding area (without taking the  
> whole into account).

So, how does a server know that the input polygon should match an  
exact polygon in the db (as is needed for the VSP test) vs a need to  
find the centroid before looking for a match (as would be needed for  
regular uses of LoST)?  In the first case, the VSP test will fail  
because it will match the more specific polygon, according to your  
description above.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 23 Apr 2007 17:10:54 -0400

On Apr 23, 2007, at 12:24 PM, Andrew Newton wrote:

>> think it would be better to have the client provide the LO, and  
>> the server reject it if can't parse that particular GML-derived  
>> format.
>
> identifying information not be sent inside of LoST.  It just needs  
> to copy the location information XML.  I don't really understand  
> your concern.

I was being imprecise. I'm talking about the <location-info> part of  
PIDF-LO only, not the rest. That part does not identify the profile  
to be used.

>
> BTW, while some of us implicitly understand this, do have it  
> written anywhere that RFC 3825 without floor is geodetic-2d and  
> that RFC 4776 is the civic profile.

A UA would presumably translate either into <location-info>, so I  
don't think we need to declare this explicitly, as the raw DHCP data  
isn't visible to the server.

> Huh?  Didn't we already discuss this?  geodetic-2d and civic are  
> the two base profiles.
>

Certainly; I was just commenting, in case that somebody was inferring  
the opposite, that we still need profiles. Just that having the  
client declare the profile of the location it is sending is not too  
useful.

In short, my proposal is simple:

- Remove the restriction that the profile used for sending data is  
the same as that used for processing the <serviceBoundary>. This  
avoids having thje client guess what profile a (new) <location-info>  
corresponds to.

- The profile declaration thus only applies to the allowable  
<serviceBoundary> responses.

- A server can continue to indicate the mapping point format it  
supports.

Henning

---

From: Andrew Newton <[email-masked]>
Date: Tue, 24 Apr 2007 07:16:00 -0400

On Apr 23, 2007, at 5:10 PM, Henning Schulzrinne wrote:

> avoids having thje client guess what profile a (new) <location- 
> info> corresponds to.
>

This then leaves the server to guess about the type of location  
information.  I don't understand your reasoning for believing servers  
should not need to know the profile, but that clients do.  If one  
guesses at the type of information it is receiving, then they both  
can.  And it doesn't sound too helpful to do at either end.  And I'm  
confused about the relevance of this to the current discussion.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 24 Apr 2007 12:08:42 -0400

I changed the subject line, since we've strayed a bit from the  
original topic, even though this is still motivated by the topic. Let  
me try again to work through the steps:

- We currently use profiles for both sending and receiving location,  
namely for <location-info> when requesting a mapping and in the  
<serviceBoundary> when such a mapping is being returned. The  
discussion is only about the former, not about the latter.

- In "regular" presence, there is no profile information. In other  
words, if I use RFC 4119, the receiver of presence information has to  
recognize the namespace indicators and the XML tags, as in all other  
XML applications. This has not generated any particular controversy,  
as far as I can tell.

Indeed, http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo- 
profile-06 continues that tradition. There is no profile information,  
just, say, <gml:Polygon> or <gml:Prism>. The receiver of such  
information, e.g., in a NOTIFY, would simply recognize <Polygon> or  
<Prism> and parse it accordingly.

- We agree that for the <location-info>, the profile information only  
provides a hint. The receiver (here, the LoST server) still has to  
recognize the XML tags and has to be prepared to deal with XML that  
doesn't actually follow the profile.

- The XML is self-sufficient. In other words, once you have the GML  
tag, the profile doesn't provide any additional information.

- We all agree, I think, that we should avoid a proliferation of data  
formats, so that the profile in draft-ietf-geopriv-pdif-lo-profile-06  
and similar efforts should guide implementors of PIDF-LO-using  
systems, but this affects producers of LOs and their final consumers.  
LoST clients just copy them.

- The core problem is that the profile notion makes it impossible to  
upgrade any LCP without upgrading all clients since a client (LCP  
querier and LoST seeker) would have to recognize the <location-info>  
format to insert the right profile information, even though the  
client doesn't touch the <location-info> and simply copies it from  
LCP to LoST verbatim.  As far as I know, HELD provides no way to  
request a specific LoST profile, either.

Thus, I believe that using the location-profile for LoST queries, in  
<location-info>, serves no purpose and simply makes system upgrades  
hard or impossible.

Henning

On Apr 24, 2007, at 7:16 AM, Andrew Newton wrote:

> information.  I don't understand your reasoning for believing  
> servers should not need to know the profile, but that clients do.   
> If one guesses at the type of information it is receiving, then  
> they both can.  And it doesn't sound too helpful to

I'm not sure where you got the notion from the above that "servers  
should not need to know the profile, but clients do". It's the opposite.

> do at either end.  And I'm confused about the relevance of this to  
> the current discussion.
>
> -andy

---

From: Andrew Newton <[email-masked]>
Date: Tue, 24 Apr 2007 14:07:22 -0400

On Apr 24, 2007, at 12:08 PM, Henning Schulzrinne wrote:
> - The core problem is that the profile notion makes it impossible  
> to upgrade any LCP without upgrading all clients since a client  
> (LCP querier and LoST seeker) would have to recognize the <location- 
> info> format to insert the right profile information, even though  
> the client doesn't touch the <location-info> and simply copies it  
> from LCP to LoST verbatim.  As far as I know, HELD provides no way  
> to request a specific LoST profile, either.

Actually, this introduces more problems as the server has to guess at  
the meaning of the data.  Take for instance a future location profile  
based on RFC 3825... and you find this in draft-ietf-geopriv-lo- 
profile-06:

<gml:Point srsName="urn:ogc:def:crs:EPSG::4326"
   <gml:pos>-43.5723 153.21760</gml:pos>
</gml:Point>
<cl:civicAddress>
   <cl:FLR>2</cl:FLR>
</cl:civicAddress>

Just looking at the GML XML namespace is not enough to know that the  
format is 3825.

Also, there's the problem I brought up yesterday.  If a server sees  
this input, where a polygon has a whole in it:

<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
   <gml:exterior>
     <gml:LinearRing>
        ...
     </gml:LinearRing>
   </gml:exterior>
   <gml:interior>
     <gml:LinearRing>
        ...
     </gml:LinearRing>
   </gml:interiorr>
</gml:Polygon>

Now, is the server to find the centroid of the polygon or is it  
suppose to look for an exact match of the polygon?

I do understand your concern.  You don't want the clients to have to  
know much of anything; they should just do a copy and paste.  Well,  
with DHCP they have to be smarter than that just because of the  
difference in protocols (binary vs. XML).  But an XML based LCP can  
almost be that simple (almost, XML namespaces do require  
normalization).  And I agree, that would be good.

However, the way to approach this is to subtly change the way we do  
profile identifiers.  Essentially, if we move them out of the  
<location-info> element and into their own child element, this bit of  
data can be shuttled around with the location information without any  
specific knowledge of the client.

So, a location hiding LIS queries LoST for the PSAPs polygon.  It  
gets back:

<lost:location-info>
   <lost_metadata:profile name="geodetic2d-exact" />
   <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
        ...
   </gml:Polygon>
</lost:location-info>

The LIS has a simple algorithm; copy all elements inside the  
<location-info> element.  It then hands the following information  
over to the client:

   <lost_metadata:profile name="geodetic2d-exact" />
   <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
        ...
   </gml:Polygon>

The client information gets passed along, eventually being re-input  
into a LoST server (the VSP verification step) where the intention of  
this data is known.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 24 Apr 2007 21:04:43 -0400

There seem to be several different topics here, so I'll split my  
response.

On Apr 24, 2007, at 2:07 PM, Andrew Newton wrote:

>> (LCP querier and LoST seeker) would have to recognize the  
>> <location-info> format to insert the right profile information,  
>> even though the client doesn't touch the <location-info> and  
>> simply copies it from LCP to LoST verbatim.  As far as I know,  
>> HELD provides no way to request a specific LoST profile, either.
>
> Actually, this introduces more problems as the server has to guess  
> at the meaning of the data.  Take for instance a future location  
> profile based on RFC 3825... and you find this in draft-ietf- 
> geopriv-lo-profile-06:
>
> Just looking at the GML XML namespace is not enough to know that  
> the format is 3825.

The receiver doesn't care that the format is derived from RFC 3825.  
The namespace declaration (which you elided in your example)

   xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"

identifies the schema, so the receiver can easily tell whether it  
should ignore or handle the XML tags or not (or decide that it needs  
to give up instead). Thus, it can tell what meaning FLR has and  
whether it knows anything about that particular XML tag.

Henning

---

From: Andrew Newton <[email-masked]>
Date: Tue, 24 Apr 2007 21:22:06 -0400

On Apr 24, 2007, at 9:04 PM, Henning Schulzrinne wrote:
> should ignore or handle the XML tags or not (or decide that it  
> needs to give up instead). Thus, it can tell what meaning FLR has  
> and whether it knows anything about that particular XML tag.

No.  The way you are describing it, it must recognize both the GML  
and the civicAddr namespaces.  And a 3825 based location profile  
could easily use urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc for  
the namespace identifier.  It would be better if the sender let the  
receiver in on what type of location it is sending.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 24 Apr 2007 21:30:19 -0400

> suppose to look for an exact match of the polygon?

That seems like a completely different question compared to the  
profile issue, or at least I'm missing the connection.

This is indeed a real problem, but only if the location of the  
querier itself has a hole. There is no problem for the case where the  
service boundary has one or more holes. The location-with-hole case  
only occurs in the location hiding case, as far as I can tell, and is  
relatively uncommon even there.

There are two solutions, neither of which is totally satisfying.

(1) Exact match, as you indicate. In other words, a LoST server first  
tries to find an exact match for the boundary. For the location- 
hiding case, this will always work.

Advantage: The client doesn't have to know.
Disadvantage: LoST servers need a special case.

(2) Transformation in LIS: The carrier that wants to hide a location  
creates a convex location region that has no holes and includes the  
location of the UA. A very simple way to do this is to return a  
triangle (square, circle, ...) that includes the caller's location  
(not in the center) and whose centroid falls into the PSAP service  
area. This has to be done only once (unless the PSAP boundary  
changes), so the computational burden is trivial.

Advantage: No special case in LoST servers.
Disadvantage: Requires some special geometric treatment for special  
cases.

I have some preference for (2), since it's a bit cleaner and it's  
conceptually no different from a wireless location system with a very  
imprecise location technology, such as cell-face only. It requires no  
standardization as such, as long as we standardize the centroid  
behavior.

Henning

---

From: Andrew Newton <[email-masked]>
Date: Tue, 24 Apr 2007 22:12:10 -0400

On Apr 24, 2007, at 9:30 PM, Henning Schulzrinne wrote:
> (2) Transformation in LIS: The carrier that wants to hide a  
> location creates a convex location region that has no holes and  
> includes the location of the UA. A very simple way to do this is to  
> return a triangle (square, circle, ...) that includes the caller's  
> location (not in the center) and whose centroid falls into the PSAP  
> service area. This has to be done only once (unless the PSAP  
> boundary changes), so the computational burden is trivial.

Well, that's certainly a creative approach, and complex.  And it  
screws with the caching and periodic requery at the end point.  The  
created shape must fall entirely within service boundary.  If any  
part of it overlaps the service boundary, then there is the potential  
for a misrouted call.  If the created shape falls within the service  
boundary, it will be less than the area of the service boundary and  
cause needless requerys by the endpoints, which will believe they may  
have crossed from one service boundary to another when, in fact, they  
haven't.

That seems like a lot of extra burden on the system, when we could  
just add some meta-data to the service boundary and allow LoST  
servers to do exact matches.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 24 Apr 2007 22:32:44 -0400

On Apr 24, 2007, at 10:12 PM, Andrew Newton wrote:

>> includes the location of the UA. A very simple way to do this is  
>> to return a triangle (square, circle, ...) that includes the  
>> caller's location (not in the center) and whose centroid falls  
>> into the PSAP service area. This has to be done only once (unless  
>> the PSAP boundary changes), so the computational burden is trivial.
>
> part of it overlaps the service

Not really; caching works just as before. The created shape does  
*not* have to fall completely within the service boundary, given the  
centroid computation that determines matching. As per the previous  
discussion, any non-point shape will need to be transformed to a  
point (centroid) by the LoST server.

> boundary, then there is the potential for a misrouted call.  If the  
> created shape falls within the service boundary, it will be less  
> than the area of the service boundary and cause needless requerys  
> by the endpoints, which will believe they may have crossed from one  
> service boundary to another when, in fact, they haven't.
>

This would not be the service boundary, but it would have to be the  
<location-info> element, so it would have to be a PIDF-LO extension,  
which seems rather strange.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 24 Apr 2007 22:39:12 -0400

I don't understand your comment. The namespace better identify  
completely the list of XML tags that are permissible, as something is  
terribly wrong with the XML validity otherwise.

I also don't see why a purely civic address would need a GML name  
space, but that's a separate issue.

On Apr 24, 2007, at 9:22 PM, Andrew Newton wrote:

>> The receiver doesn't care that the format is derived from RFC  
>> 3825. The namespace declaration (which you elided in your example)
>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 24 Apr 2007 22:43:43 -0400

>
> I do understand your concern.  You don't want the clients to have  
> to know much of anything; they should just do a copy and paste.   
> Well, with DHCP they have to be smarter than that just because of  
> the difference in protocols (binary vs. XML).  But an XML based LCP  
> can almost be that simple (almost, XML namespaces do require  

The XML namespaces can just be copied, as far as I can tell. I don't  
know what you mean by normalization, except that you'd have to make  
sure that name clashes are avoided. (If LoST uses namespace short  
hand X, you have to transform the LO namespaces to something other  
than X, but that's a purely mechanical and blind transformation.) I.e.,

<cl:civicAddress>

may become

<xy:civicAddress>

if LoST happens to be using 'cl'.

> <location-info> element and into their own child element, this bit  
> of data can be shuttled around with the location information  
> without any specific knowledge of the client.
>

> into a LoST server (the VSP verification step) where the intention  
> of this data is known.

This requires an addition to PIDF-LO, namely a LoST profile  
identifier, which serves no purpose and is specific to LoST. I'm  
opposed to such a solution.

Henning

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 24 Apr 2007 22:40:23 -0500

Depending on how you see LoST being used it may be easiest just to not
allow holes in location being proffered to the LoST server.

In PIDF-LO profile we made the assumption that the location being
described was that of the device/user hence a hole was not required.

Holes in service boundaries is a different issue and I think that this
can easily be addressed with the exception case described by Martin
Thomson.

I don't like the concept of LoST truncating data down to a point in
order to do the service mapping, and I have stated my reasons for this
on numerous occasions, misrouting being one of them. I also don't buy
the argument that the complexity to do area overlaps is hard, it is my
understanding that most commercial GIS systems can do this type of
calculation today without batting an eyelid.

I accept that this is not the current profile, and that there is scope
in LoST for future profiles, and this why I don't see this last point as
a show stopper for LoST.

Cheers
James

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, 25 April 2007 12:33 PM
> To: Andrew Newton
> Cc: ECRIT
> Subject: Re: [Ecrit] Profiles (was: Consensus Call) - hole
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 24 Apr 2007 23:47:37 -0400

> allow holes in location being proffered to the LoST server.

I fully agree with that.

> calculation today without batting an eyelid.

You have never answered my extensive description of why this is hard  
and useless. This has nothing to do with GIS systems, but rather with  
issues of forking and with the fake accuracy implied by such  
mappings, which have nothing to do with measured reality. In other  
words, lots of complexity for nothing except symbolic gains. Please  
review my message on the notions of probability implied by such  
mappings.

> in LoST for future profiles, and this why I don't see this last  

I'm not sure what this has to do with profiles.

Henning

---

From: Andrew Newton <[email-masked]>
Date: Wed, 25 Apr 2007 09:42:34 -0400

On Apr 24, 2007, at 10:32 PM, Henning Schulzrinne wrote:

> <location-info> element, so it would have to be a PIDF-LO  
> extension, which seems rather strange.

PIDF-LO allows multiple elements from other namespaces inside the  
<location-info>.  That is not strange, that is very common in XML.   
The meta-data is not an extension to PIDF-LO itself.  That is a  
mischaracterization.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Wed, 25 Apr 2007 09:47:17 -0400

XML validity and XML namespaces are separate features.  XML validity,  
in the form of DTDs, existed before XML namespaces.  It just so  
happens that the more modern XML schema languages, such as Relax NG  
and XML Schema, account for XML namespaces and allow the validity to  
check the namespace, which wasn't possible with DTDs.

However, validation checking will not solve this problem, as each XML  
fragment is valid against its schema.  This means such validation  
must be done by the application.

-andy

On Apr 24, 2007, at 10:39 PM, Henning Schulzrinne wrote:

> completely the list of XML tags that are permissible, as something  
> is terribly wrong with the XML validity otherwise.
>
>> could easily use urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc  
>> for the namespace identifier.  It would be better if the sender  
>> let the receiver in on what type of location it is sending.
>>
>> -andy
>

---

From: Andrew Newton <[email-masked]>
Date: Wed, 25 Apr 2007 09:53:01 -0400

On Apr 24, 2007, at 10:43 PM, Henning Schulzrinne wrote:
> The XML namespaces can just be copied, as far as I can tell. I  
> don't know what you mean by normalization, except that you'd have  
> to make sure that name clashes are avoided. (If LoST uses namespace  
> short hand X, you have to transform the LO namespaces to something  
> other than X, but that's a purely mechanical and blind  
> transformation.) I.e.,
>
> <cl:civicAddress>
>
> may become
>
> <xy:civicAddress>
>

I don't think we are in disagreement here.  The algorithm for the  
transformation is the same regardless of profile.  This isn't even a  
LoST or PIDF-LO issue... its a general XML issue.

> opposed to such a solution.

Again, it is not an addition to PIDF-LO.  And I gave you a good  
reason why we need the profile identifiers, its just that you would  
rather have a LIS contort LoST service boundaries, which is a less  
straight forward way of handling this.

-andy

---

From: Richard Barnes <[email-masked]>
Date: Wed, 25 Apr 2007 10:24:53 -0400

Just want to note that since LoST does allow for multiple services for a 
given location, and since the LIS doesn't know which an endpoint might 
try to get via LoST, the area that the LIS returns will have to be a 
subset of the intersection of all the service areas that contain the 
endpoint's location

In particular, you can't do an exact match in general, since the LIS 
can't be relied on to provide the exact service area for any particular 
service.

--Richard

Henning Schulzrinne wrote:
> That seems like a completely different question compared to the profile 
> issue, or at least I'm missing the connection.
> 
> This is indeed a real problem, but only if the location of the querier 
> itself has a hole. There is no problem for the case where the service 
> boundary has one or more holes. The location-with-hole case only occurs 
> in the location hiding case, as far as I can tell, and is relatively 
> uncommon even there.
> 
> tries to find an exact match for the boundary. For the location-hiding 
> case, this will always work.
> 
> location of the UA. A very simple way to do this is to return a triangle 
> (square, circle, ...) that includes the caller's location (not in the 
> center) and whose centroid falls into the PSAP service area. This has to 
> be done only once (unless the PSAP boundary changes), so the 
> computational burden is trivial.
> 
> Disadvantage: Requires some special geometric treatment for special cases.
> 
> standardization as such, as long as we standardize the centroid behavior.
> 
> Henning
> 
> 
> 
> 
> 
>

---

From: Andrew Newton <[email-masked]>
Date: Wed, 25 Apr 2007 11:04:06 -0400

Well, that's an interesting wrinkle.  I don't think this is specific  
to exact match of service boundaries or the convex location.  This is  
born out of the fact that the LIS doesn't know the service that may  
be queried, and the assumption in this entire location hiding idea  
has been that the LIS and the LoST seeker are using the querying for  
the same service -- something that can't actually be assumed.

Back to the drawing board!

-andy

On Apr 25, 2007, at 10:24 AM, Richard Barnes wrote:

> Just want to note that since LoST does allow for multiple services  
> for a given location, and since the LIS doesn't know which an  
> endpoint might try to get via LoST, the area that the LIS returns  
> will have to be a subset of the intersection of all the service  
> areas that contain the endpoint's location
>
> In particular, you can't do an exact match in general, since the  
> LIS can't be relied on to provide the exact service area for any  
> particular service.
>
> --Richard
>
>
>>> Also, there's the problem I brought up yesterday.  If a server  
>>> sees this input, where a polygon has a whole in it:
>>>
>> querier itself has a hole. There is no problem for the case where  
>> the service boundary has one or more holes. The location-with-hole  
>> case only occurs in the location hiding case, as far as I can  
>> tell, and is relatively uncommon even there.
>> (1) Exact match, as you indicate. In other words, a LoST server  
>> first tries to find an exact match for the boundary. For the  
>> location-hiding case, this will always work.
>> conceptually no different from a wireless location system with a  
>> very imprecise location technology, such as cell-face only. It  
>> requires no standardization as such, as long as we standardize the  
>> centroid behavior.
>> Henning

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 25 Apr 2007 12:32:08 -0500

Isn't this in part a function of what the LCP can provide?
It was my understanding that access providers don't mind providing the
actual location of an end-point, but that they want to charge for the
privilege. 

This would mean to me, that I can expect emergency services to work, but
not pizza delivery or other local-routing type services. This seems
reasonable, and shrinks the applicability down substantially. The
problem manifests itself for emergency services where the services
themselves are addressed individually, that is fire is different to
ambulance etc. Is this what you were getting at Richard and Andy?

Cheers
James

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Thursday, 26 April 2007 1:04 AM
> To: Richard Barnes
> Cc: ECRIT
> Subject: Re: [Ecrit] Profiles
>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 25 Apr 2007 14:26:00 -0400

I gave an example of an algorithm that solves this problem:
Intersect all the (emergency) services boundaries, computing the largest
polygon contained in all boundaries.  Pick any point in the polygon.  Use
that as the center of a circle with 50kM radius

Brian

> From: Winterbottom, James [mailto:[email-masked]]
> Sent: Wednesday, April 25, 2007 1:32 PM
> To: Andrew Newton; Richard Barnes
> Cc: ECRIT
> Subject: RE: [Ecrit] Profiles
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 25 Apr 2007 17:46:48 -0400

Brian,

that's roughly (modulo some different shapes) the suggestion I made  
yesterday, so I'm confused.

James,

I don't think this is a matter of charging, except maybe in theory. I  
don't think anybody has illusions about per-dip charging, given the  
complexity of setting up a micropayment system. (Also, in many cases,  
it's not the target that would gain value from location information,  
but rather the recipient, which makes this even more challenging.)

Henning

On Apr 25, 2007, at 2:26 PM, Brian Rosen wrote:

>> --------------------------------------------------------------------- 
>> -----
>> ----------------------
>> --------------------------------------------------------------------- 
>> -----
>> ----------------------
>> [mf2]
>>
>>

---

From: Andrew Newton <[email-masked]>
Date: Wed, 25 Apr 2007 20:36:18 -0400

> that as the center of a circle with 50kM radius

That assumes all polygons intersect.  That may not be the case.  Plus  
LoST services can be more than emergency services.  How is a LIS  
suppose to know.

I'm beginning to see Martin's point.  We seem to be bending over  
backwards to avoid doing dereferences in LoST.  Perhaps that is the  
real answer.

-andy

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 25 Apr 2007 19:59:07 -0500

Or you have to include services in the request to the LIS, which is a
hack!

> Sent: Thursday, 26 April 2007 10:36 AM
> To: Brian Rosen
> Cc: Winterbottom, James; 'Richard Barnes'; 'ECRIT'

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 25 Apr 2007 22:03:09 -0400

On Apr 25, 2007, at 8:36 PM, Andrew Newton wrote:

> That assumes all polygons intersect.  That may not be the case.

They have to intersect at the location of the caller, at least, since  
every single service polygon covers the caller's location by  
definition. Can you give an example where they would not intersect?

> Plus LoST services can be more than emergency services.  How is a  
> LIS suppose to know.
>

But that has its own set of problems, amply discussed earlier. The  
problem gets worse if you have multiple non-emergency services since  
they can be provided by multiple independent LoST hierarchies.

I think we need to be somewhat practical. We can imagine all kinds of  
strange scenarios, but it seems unwise to create a whole lot of  
machinery for a special case (location hiding) that is hopefully rare  
or transient, and then optimize corner cases of that scenario.  
Clearly, in the US, there's only a single 9-1-1 service.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 25 Apr 2007 23:12:09 -0400

> straight forward way of handling this.

I don't see what this has to do with profiles. If I understood you  
correctly, you were suggesting a flag indicating a modification of  
the matching algorithm (point vs. whole polygon), which seems  
orthogonal to profiles. Subsequent discussion seems to indicate that  
this may not work in all cases.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 25 Apr 2007 23:14:26 -0400

The point I'm making is that the namespace identifier is sufficient  
to determine what XML is valid, since you can determine the  
corresponding schema, whether expressed in RelaxNG or XML Schema. We  
are not using DTD.

Thus, I fail to see what this has to do with another label. We don't  
have profile labels in SIP presence, for example, and the problem is  
pretty much the same.

On Apr 25, 2007, at 9:47 AM, Andrew Newton wrote:

> XML validity and XML namespaces are separate features.  XML  
> validity, in the form of DTDs, existed before XML namespaces.  It  
> just so happens that the more modern XML schema languages, such as  
> Relax NG and XML Schema, account for XML namespaces and allow the  
> validity to check the namespace, which wasn't possible with DTDs.
>
> However, validation checking will not solve this problem, as each  
> XML fragment is valid against its schema.  This means such  
> validation must be done by the application.
>
> -andy
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 25 Apr 2007 23:16:29 -0400

We seem to be talking past each other. The strange part is that this  
extension is specific to LoST usage and makes no sense elsewhere.  
Obviously, there is no syntactic problem.

You still haven't answered what purpose the identifier serves, given  
that all other 4119 applications seem to survive just fine without it.

On Apr 25, 2007, at 9:42 AM, Andrew Newton wrote:

>>> That seems like a lot of extra burden on the system, when we  
>>> could just add some meta-data to the service boundary and allow  
>>> LoST servers to do exact matches.
>>
>> This would not be the service boundary, but it would have to be  
>> the <location-info> element, so it would have to be a PIDF-LO

---

From: Andrew Newton <[email-masked]>
Date: Thu, 26 Apr 2007 11:57:51 -0400

On Apr 25, 2007, at 10:03 PM, Henning Schulzrinne wrote:
> They have to intersect at the location of the caller, at least,  
> since every single service polygon covers the caller's location by  

Sorry.  You are right.  I was thinking of separate mappings per  
service.  Still, that does not get around...

>> Plus LoST services can be more than emergency services.  How is a  

this.

>> backwards to avoid doing dereferences in LoST.  Perhaps that is  
>> the real answer.
>
> problem gets worse if you have multiple non-emergency services  
> since they can be provided by multiple independent LoST hierarchies.

I don't understand this point.

> I think we need to be somewhat practical. We can imagine all kinds  
> of strange scenarios, but it seems unwise to create a whole lot of  
> machinery for a special case (location hiding) that is hopefully  
> rare or transient, and then optimize corner cases of that scenario.  

Just because a couple of technologists believe it is a rare or  
transient use case, doesn't make it so.  After all, some of these  
same technologists believed that legislatures would simply require  
the location information to flow unimpeded.  But now that seems to be  
an unlikely reality.  Given the size of some of the access networks  
that have expressed interest in location hiding, I doubt it will be  
rare.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Thu, 26 Apr 2007 12:44:30 -0400

On Apr 25, 2007, at 11:12 PM, Henning Schulzrinne wrote:

> orthogonal to profiles. Subsequent discussion seems to indicate  
> that this may not work in all cases.

Ok.  That is another way of solving the problem.  But the subsequent  
discussion was not about the flag or matching, but rather about the  
fact that there are different boundaries for different services and  
that the LIS does not know the service type being queried via LoST.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Thu, 26 Apr 2007 12:45:45 -0400

So you are advocating the creation of a schema that glues the two  
different schemas together, so it can be validated via the XML  
namespace?  If so, ok.  But that is just one step further than a  
profile identifier.

-andy

On Apr 25, 2007, at 11:14 PM, Henning Schulzrinne wrote:

> corresponding schema, whether expressed in RelaxNG or XML Schema.  
> We are not using DTD.
>
> Thus, I fail to see what this has to do with another label. We  
> don't have profile labels in SIP presence, for example, and the  
> problem is pretty much the same.
>

---

From: Andrew Newton <[email-masked]>
Date: Thu, 26 Apr 2007 12:47:20 -0400

On Apr 25, 2007, at 11:16 PM, Henning Schulzrinne wrote:

> We seem to be talking past each other. The strange part is that  
> this extension is specific to LoST usage and makes no sense  
> elsewhere. Obviously, there is no syntactic problem.

I'm glad we are past this point.  :)

> You still haven't answered what purpose the identifier serves,  
> given that all other 4119 applications seem to survive just fine  
> without it.

To identify the validity of the combination of data from two  
different schemas.  What are the other widely deployed 4119  
applications?

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Apr 2007 12:49:39 -0400

Right - but the multiple-service problem makes an exact-match flag no  
longer particularly helpful.

On Apr 26, 2007, at 12:44 PM, Andrew Newton wrote:

> Ok.  That is another way of solving the problem.  But the  
> subsequent discussion was not about the flag or matching, but  
> rather about the fact that there are different boundaries for  
> different services and that the LIS does not know the service type  
> being queried via LoST.
>
> -andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Apr 2007 12:52:40 -0400

> different schemas.  What are the other widely deployed 4119  

Widely deployed is probably the wrong phrase for any of these things,  
but plain old presence, as in RFC 4079.

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 26 Apr 2007 13:11:55 -0400

> >> Plus LoST services can be more than emergency services.  How is a
I think this is simple: it doesn't, and it doesn't care.  A paying customer
will get fine grained location, and can use LoST.  "Paying customer" could
be the endpoint or the VSP.

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Apr 2007 14:02:24 -0400

I'm somehow missing the problem. All namespaces, and thus, the  
corresponding schema, are already identified in the XML instance, for  
GML and the other LoST components. What additional information would  
I need to provide? Why would I need to glue together the schema?

As far as I know, a single XML document can have components from  
multiple schema. This seems common for XML documents, including the  
work in XMPP or NetConf. Neither, as far as I know, has the notion of  
a profile.

On Apr 26, 2007, at 12:45 PM, Andrew Newton wrote:

>> The point I'm making is that the namespace identifier is  
>> sufficient to determine what XML is valid, since you can determine  
>> the corresponding schema, whether expressed in RelaxNG or XML  
>> Schema. We are not using DTD.
>>
>>> just so happens that the more modern XML schema languages, such  
>>> as Relax NG and XML Schema, account for XML namespaces and allow  
>>> the validity to check the namespace, which wasn't possible with  
>>> DTDs.
>>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Apr 2007 14:10:31 -0400

> I don't understand this point.

I'm assuming that the LoST resolver would need to convert a reference  
to a value. I'm also assuming that different services use different  
LoST hierarchies, as currently defined in the architecture spec. For  
example, the urn:service:food.pizza might have a different tree than  
emergency services.

There are now two choices:

(1) The ISP has to run LoST resolvers for every possible service,  
including pizza. It also has to decide which services get location  
information and which don't.

(2) If not, there have to be two resolvers, at least. Now, there's a  
fairly complicated set of steps:

(a) UA gets LbyR; it has no way of knowing whether the LbyR provides  
coarse location, fine-grained location or no location at all. Thus,  
the UA has to try to resolve the reference, getting a failure,  
according to Richard's proposal. Another round-trip delay added. With  
that failure, it now proceeds to step 2. (If there were no failure,  
it would presumably include the location value returned in the LoST  
query, since it has no way of knowing whether the LIS restricts  
access to the reference by IP address, as proposed by Richard, so it  
can't know whether the LoST server would actually be able to resolve  
a reference handed to it by the LIS.)

(b) Let's assume that the standard process is to directly issue a  
LoST query or that this happens after a failure. The UA has no idea  
which services are supported by the ISP-provided LoST server  [it can  
find this out with yet another LoST query] and which services allow  
fine-grained location. These two sets may not be the same.

Indeed, it has no good way to find such a server. (DHCP may not cut  
it, as it has the same issues that are leading us to using L7 LCP.)

Now, the LoST server may or may not be able to dereference or be  
willing to provide fine-grained location for that service. Thus, the  
LoST query might fail. At that point, the device might try to use  
other location-information or maybe a different LoST server, maybe  
derived from mapping its IP address. Even if it succeeds, the  
reference may or may not be dereferencable by the service provider,  
but that's something the UA can't know ahead of time, either.

This all seems pretty messy to me, with a low chance of working in  
real life, but lots of chances for a very frustrating user experience  
and calls to the help line. Just testing all these combinations of  
cases seems like a nightmare.

>> rare or transient, and then optimize corner cases of that  
>> scenario. Clearly, in the US, there's only a single 9-1-1 service.
>
> the location information to flow unimpeded.  But now that seems to  
> be an unlikely reality.  Given the size of some of the access  
> networks that have expressed interest in location hiding, I doubt  
> it will be rare.

Location hiding may or may not be rare, but only the combination of  
hiding with multiple services causes some complexity. However, with  
Brian's proposal, the complexity is limited to the service provider  
in that case, which is in a much better position to deal with it. In  
the vast majority of cases (single emergency number, no holes) things  
work fine. In the other cases, there's more effort required, but no  
new protocol work and no additional client complexity or call setup  
delay.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 26 Apr 2007 16:12:34 -0700

>
>Location hiding may or may not be rare, but only the combination of hiding with multiple services causes some complexity.

Are there other services for which the kind of location-is-hidden-but-service-supported
tricks we're planning for ECRIT  make any sense?  I've been trying to find something
that fits that, and my imagination is failing.  It seems more likely that the service
will simply be unsupported if someone hasn't paid for location in those cases.

The hack James suggested, of including the service in the request to the LIS,
begins to look like a reasonable choice, if there are no others.  Have the request
to the LIS include an appropriate emergency service flag if appropriate seems
to simplify the problem at least some.
				Ted

---

From: Andrew Newton <[email-masked]>
Date: Thu, 26 Apr 2007 22:50:48 -0400

There is validation about the XML components being glued together.  A  
LoST server must assume that civicAddr XML preceded by GML is 3825  
location information.  Having software make assumptions is usually  
not a good idea.

-andy

On Apr 26, 2007, at 2:02 PM, Henning Schulzrinne wrote:

> corresponding schema, are already identified in the XML instance,  
> for GML and the other LoST components. What additional information  
> would I need to provide? Why would I need to glue together the schema?
>
> work in XMPP or NetConf. Neither, as far as I know, has the notion  
> of a profile.
>
>>> sufficient to determine what XML is valid, since you can  
>>> determine the corresponding schema, whether expressed in RelaxNG  
>>> or XML Schema. We are not using DTD.
>>>
>>>> validity, in the form of DTDs, existed before XML namespaces.   
>>>> It just so happens that the more modern XML schema languages,  
>>>> such as Relax NG and XML Schema, account for XML namespaces and  
>>>> allow the validity to check the namespace, which wasn't possible  
>>>> with DTDs.
>>>>
>>>> However, validation checking will not solve this problem, as  
>>>> each XML fragment is valid against its schema.  This means such

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Apr 2007 22:53:16 -0400

I've asked a few times, but why would LoST care that the civicAddr is  
derived from DHCP as opposed to, say, entered manually? Obviously,  
the current profile doesn't convey that information, either.

On Apr 26, 2007, at 10:50 PM, Andrew Newton wrote:

> There is validation about the XML components being glued together.   
> A LoST server must assume that civicAddr XML preceded by GML is  
> 3825 location information.  Having software make assumptions is  
> usually not a good idea.
>
> -andy
>

---

From: Andrew Newton <[email-masked]>
Date: Thu, 26 Apr 2007 22:58:00 -0400

> be the endpoint or the VSP.

For clarification, are you applying this to emergency services, or to  
other services?

-andy

---

From: Andrew Newton <[email-masked]>
Date: Thu, 26 Apr 2007 22:59:49 -0400

> to simplify the problem at least some.

I'm not against this.  I thought others were, including James.  I  
don't know how it would work with DHCP and LLDP-MED.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Thu, 26 Apr 2007 23:03:37 -0400

On Apr 26, 2007, at 10:53 PM, Henning Schulzrinne wrote:

> I've asked a few times, but why would LoST care that the civicAddr  
> is derived from DHCP as opposed to, say, entered manually?  
> Obviously, the current profile doesn't convey that information,  
> either.

I don't think it should care.  The point wasn't that it came from  
DHCP, the point was that it was a 3825-like compound location.  Sorry  
if that was confusing.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Apr 2007 23:26:46 -0400

Maybe we need to restart this discussion, as I'm lost. I still  
haven't heard a single technical argument as to what additional  
information a profile name, outside the XML, contains that would not  
be visible in the namespace and tag declarations. I was taught that  
XML documents could stand alone, without additional meta information,  
once you have pointers to the namespaces. Do you have a citation that  
indicates that this is wrong?

I'm looking at Walmsley, "Definitive XML Schema" and it says:

"Instances can be related to schemas in a variety of ways ...

* ...
* dereferencing the namespace. The namespace can be dereferenced to  
retrieve a schema document or resource directory."

In this case, this is a URN and all relevant schema will be known to  
the receiver and we have a one-to-one relationship between namespace  
and schema, so there's no ambiguity. (Walmsley points out various  
reasons why an HTTP-like namespace identifier may not be a good idea,  
but none of them seem to apply here.)

Also, as I mentioned before, XMPP seems to follow roughly the same  
model as 4119. E.g., the core spec defines a schema and namespace  
urn:ietf:params:xml:ns:xmpp-sasl and urn:ietf:params:xml:ns:xmpp-tls.  
There is no profile indication, as far as I can tell, even for the  
various extensions (say, namespace jabber:x:data).

Can you please provide a reference or other authority that supports  
or explains your view?

Henning

On Apr 26, 2007, at 11:03 PM, Andrew Newton wrote:

> DHCP, the point was that it was a 3825-like compound location.   
> Sorry if that was confusing.
>
> -andy

---

From: Andrew Newton <[email-masked]>
Date: Thu, 26 Apr 2007 23:54:21 -0400

Perhaps we do need to restart the discussion.  I was never arguing  
for anything as strong as XML validity.  That was one of your  
arguments.  However, if you take a schema that has the following  
definition (pasted from 4119):

     <xs:sequence>
       <xs:any namespace="##other" processContents="lax" minOccurs="0"
          maxOccurs="unbounded"/>
     </xs:sequence>

Now take a look at the following from draft-ietf-geopriv-pdif-lo- 
profile:

          <gp:geopriv>
            <gp:location-info>
            </gp:location-info>
            <gp:usage-rules/>
          </gp:geopriv>

What is there to say that <cl:civicAddress> can legally follow  
<gml:Point>?  Nothing.  From an XML processors perspective, it could  
be GML followed by some other stuff that can be ignored (look at  
processContents="lax").  What's the cue to the application that it  
shouldn't ignore <cl:civicAddress>?  How does it know that is  
important information, if even it may not have the schema in its  
catalog?

-andy

On Apr 26, 2007, at 11:26 PM, Henning Schulzrinne wrote:

> information a profile name, outside the XML, contains that would  
> not be visible in the namespace and tag declarations. I was taught  
> that XML documents could stand alone, without additional meta  
> information, once you have pointers to the namespaces. Do you have  
> a citation that indicates that this is wrong?
>
> In this case, this is a URN and all relevant schema will be known  
> to the receiver and we have a one-to-one relationship between  
> namespace and schema, so there's no ambiguity. (Walmsley points out  
> various reasons why an HTTP-like namespace identifier may not be a  
> good idea, but none of them seem to apply here.)
>
> urn:ietf:params:xml:ns:xmpp-sasl and urn:ietf:params:xml:ns:xmpp- 
> tls. There is no profile indication, as far as I can tell, even for  
> the various extensions (say, namespace jabber:x:data).
>
>>> I've asked a few times, but why would LoST care that the  
>>> civicAddr is derived from DHCP as opposed to, say, entered  
>>> manually? Obviously, the current profile doesn't convey that  
>>> information, either.
>>

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 27 Apr 2007 00:07:11 -0500

If this is the best way to address the problem then sobeit, though it
would not be my first choice of solution.
I agree with your analysis on DHCP and LLDP-MED in that I don't know how
to make it work with them either, does it have to?
Some functionality is simply going to be more easily accomplished using
one solution over another.

Cheers
James 

> Sent: Friday, 27 April 2007 1:00 PM
> To: Ted Hardie
> Cc: ECRIT

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Apr 2007 07:36:22 -0400

We need a solution for emergency calls.
If we use the "return coarse information" then the coarse information is for
emergency calls, and may not work for any other purpose

If we have another solution for emergency calls, such as LoST dereference,
we may not need coarse location.

Brian

> Sent: Thursday, April 26, 2007 10:58 PM
> To: Brian Rosen
> Cc: 'Henning Schulzrinne'; 'ECRIT'

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Apr 2007 07:41:25 -0400

I think that location hiders will use HELD, and we don't need to bend the
other LCPs to make them work with location hiding.

I don't think we need the service in the request to the LIS.  I don't like
the implications of this for endpoint code in an area that has multiple
emergency services.  It would have to query the LIS for each service.

If we use the "find the common polygon, pick a point in it, return an area
with that point" works without this hack.

Brian

> Sent: Friday, April 27, 2007 1:07 AM
> To: Andrew Newton; Ted Hardie
> Cc: ECRIT

---

From: John Schnizlein <[email-masked]>
Date: Fri, 27 Apr 2007 09:23:13 -0400

What is "a 3825-like compound location"?  My understanding is that  
the XML for location obtained from the mechanism defined in RFC 3825  
is just latitude, longitude and altitude, each with the correct  
number of significant digits.

John

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 27 Apr 2007 09:23:18 -0400

> other LCPs to make them work with location hiding.

Agreed.

> emergency services.  It would have to query the LIS for each service.

This also has rather undesirable scaling properties: Since the UA  
can't know who is hiding location, it would have to query for all  
dozen or so emergency services, plus possibly non-emergency services  
individually.

Thus, the non-hiding ISPs would have to pay for the business model of  
their hiding competitors by suffering a tenfold increase in query  
load. That doesn't seem particularly fair.

A slightly better alternative is that the LIS would return service- 
specific polygons if they exist. In almost all cases, that would be  
one and only in specialized cases more than one. Still puts a burden  
of complexity on the UA, as the UA now has to track multiple polygons.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 27 Apr 2007 15:48:57 +0200

We used the term compound location when civic location and geodetic 
location information is mixed into one location object.
Look at Section 3.2 of 
http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile-06#page-8.

John Schnizlein wrote:
> What is "a 3825-like compound location"?  My understanding is that the 
> XML for location obtained from the mechanism defined in RFC 3825 is 
> just latitude, longitude and altitude, each with the correct number of 
> significant digits.
>
> John
>
>>> Obviously, the current profile doesn't convey that information, either.
>>

---

From: Andrew Newton <[email-masked]>
Date: Fri, 27 Apr 2007 11:00:30 -0400

By compound, I mean the combination of geodetic and civic components  
to form location information, such as is possible with RFC 3825.   
3825 is just one example.  Other types of compound location  
information are possible, such as civic address plus x distance  
relative.

-andy

On Apr 27, 2007, at 9:23 AM, John Schnizlein wrote:

> the XML for location obtained from the mechanism defined in RFC  
> 3825 is just latitude, longitude and altitude, each with the  
> correct number of significant digits.
>
> John
>

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 27 Apr 2007 11:36:45 -0400

> information are possible, such as civic address plus x 
> distance relative.
> 
> -andy
 
Self-inflicted by the decision to adopt the GML schema vs. defining a new
one, correct?

BTW, since the proposal for relative location is an *addition* to the civic
location, why are you considering it compound?

-Marc-

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 27 Apr 2007 11:53:37 -0400

I agree with this. We need a solution for emergency calls. 
Barbara

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, April 27, 2007 7:36 AM
To: 'Andrew Newton'
Cc: 'ECRIT'
Subject: RE: [Ecrit] Profiles

We need a solution for emergency calls.
If we use the "return coarse information" then the coarse information is
for emergency calls, and may not work for any other purpose

If we have another solution for emergency calls, such as LoST
dereference, we may not need coarse location.

Brian

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621

---

From: Andrew Newton <[email-masked]>
Date: Fri, 27 Apr 2007 12:11:40 -0400

> Self-inflicted by the decision to adopt the GML schema vs. defining  

Sure, that could be done.  Nobody seems to be proposing it though.

> location, why are you considering it compound?

Together, they are two different types of information.  Is there  
something wrong with that?  Is there something wrong with calling it  
compound?

-andy

---

From: Andrew Newton <[email-masked]>
Date: Fri, 27 Apr 2007 12:17:29 -0400

Just to be clear, I'm not disagreeing.  I just wanted to understand  
Brian's point.

-andy

On Apr 27, 2007, at 11:53 AM, Stark, Barbara wrote:

> The information transmitted is intended only for the person or  
> entity to which it is addressed and may contain confidential,  
> proprietary, and/or privileged material. Any review,  
> retransmission, dissemination or other use of, or taking of any  
> action in reliance upon this information by persons or entities  
> other than the intended recipient is prohibited. If you received  
> this in error, please contact the sender and delete the material  
> from all computers. GA621
>
>

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 27 Apr 2007 12:23:43 -0400

> > BTW, since the proposal for relative location is an 
> *addition* to the 
> > civic location, why are you considering it compound?
> 
> Together, they are two different types of information.  Is 
> there something wrong with that?  Is there something wrong 
> with calling it compound?

I am/was deriving the definition of *compound* from the 3825 illustration of
'part geo, part civic'.  Hence, relative location is *all* civic, therefore
didn't fit the derived definition.  But, it's certainly obvious by now that
I'm not a XML schema junkie.  Actually, I don't view relative location as
'different' from elements like: seat, cubicle, room, etc.  I intend to
define the scope/applicability of the relative loc better in the next
version of the draft.

-Marc-

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 27 Apr 2007 11:24:46 -0500

Then I strongly suggest that you go and re-read your own RFC John.
Altitude can be expressed in floors and this requires a compound
location of both civic and geodetic information in the resultant
PIDF-LO.
or is this a misinterpretation also?

> From: John Schnizlein [mailto:[email-masked]]
> Sent: Friday, 27 April 2007 11:23 PM
> To: Andrew Newton
> Cc: ECRIT
> Subject: Re: [Ecrit] Profiles (was: Consensus Call) - namespaces
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 27 Apr 2007 11:39:55 -0500

I know that I was off the air for a bit and I haven't been through the
whole 1500 emails that I got while I was out.

But what happened to the idea of doing a reverse URI lookup to arrive at
the corresponding service?

Cheers
James

> From: Stark, Barbara [mailto:[email-masked]]
> Sent: Saturday, 28 April 2007 1:54 AM
> To: Brian Rosen; Andrew Newton
> Cc: ECRIT
> The information transmitted is intended only for the person or entity
to
> which it is addressed and may contain confidential, proprietary,
and/or
> privileged material. Any review, retransmission, dissemination or
other
> use of, or taking of any action in reliance upon this information by
> persons or entities other than the intended recipient is prohibited.
If
> you received this in error, please contact the sender and delete the
> material from all computers. GA621
> 
> 
>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Apr 2007 12:45:55 -0400

Keep reading.

It's still on the list as a possible solution paired with the LCP+LoST query
as a single operation to a LIS.

I think that solution can be made to work, but is less attractive than the
"coarse location" deref solution.

Brian

> Sent: Friday, April 27, 2007 12:40 PM
> To: Stark, Barbara; Brian Rosen; Andrew Newton
> Cc: ECRIT

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 27 Apr 2007 11:48:18 -0500

>From a connected node perspective it certainly seems simpler to me.
But it may not be that simple to do in LoST I suppose.

> Sent: Saturday, 28 April 2007 2:46 AM
> To: Winterbottom, James; 'Stark, Barbara'; 'Andrew Newton'
> Cc: 'ECRIT'
> > > If we use the "return coarse information" then the coarse
information
> > is
entity
> > > material from all computers. GA621
------------------------------------------------------------------------
> --
------------------------------------------------------------------------
> --

---

From: Ted Hardie <[email-masked]>
Date: Fri, 27 Apr 2007 12:22:56 -0700

At 9:23 AM -0400 4/27/07, Henning Schulzrinne wrote:
>This also has rather undesirable scaling properties: Since the UA can't know who is hiding location, it would have to query for all dozen or so emergency services, plus possibly non-emergency services individually.

I was assuming the hack included which emergency service, which eliminates this.
				Ted

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 27 Apr 2007 17:18:16 -0400

I don't understand your comment. If the LIS query includes the  
service URN, the UA has to query for each of the dozen or so  
different emergency services  (urn:service:sos.fire, etc.).

On Apr 27, 2007, at 3:22 PM, Ted Hardie wrote:

>> dozen or so emergency services, plus possibly non-emergency  
>> services individually.
>

---

From: Ted Hardie <[email-masked]>
Date: Fri, 27 Apr 2007 15:02:06 -0700

At 5:18 PM -0400 4/27/07, Henning Schulzrinne wrote:
>I don't understand your comment. If the LIS query includes the service URN, the UA has to query for each of the dozen or so different emergency services  (urn:service:sos.fire, etc.).

If the LIS query includes the service urn:service.sos.fire, why would it need to
query for other emergencies?   Are you assuming that this occurring on boot,
and so has to be queried/retained for multiple emergency services in case any of them
come up?  For the call time use, this seems unlikely to be needed or useful.
			Ted

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 27 Apr 2007 17:54:42 -0500

But at boot time the end-point would simply say to the LIS "Gimme
emergency service stuff please", and it would get a bunch of URIs,
presumably one for each service that was distinguishably applicable for
the location. Certainly if I were designing and implementing this I
would not make it query for each one on the off chance that it yields a
different result. Once I have the initial set, then I can query based on
the service I require at call-time if need be.

Cheers
James

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Saturday, 28 April 2007 8:02 AM
> To: Henning Schulzrinne
> Cc: ECRIT
service
> URN, the UA has to query for each of the dozen or so different
emergency
> services  (urn:service:sos.fire, etc.).
> 
> If the LIS query includes the service urn:service.sos.fire, why would
it
> need to
> and so has to be queried/retained for multiple emergency services in
case
> any of them
> >>>>I don't think we need the service in the request to the LIS.  I
don't
> like
can't
> know who is hiding location, it would have to query for all dozen or
so
> emergency services, plus possibly non-emergency services individually.
> >>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 27 Apr 2007 20:15:22 -0400

One of the requirements has been to be able to determine location pre- 
call, to reduce call setup latency and the chance for errors. I agree  
that this is not a problem at call time.

---

From: Andrew Newton <[email-masked]>
Date: Fri, 27 Apr 2007 21:31:17 -0400

> presumably one for each service that was distinguishably applicable  

Interesting.  James Polk and I argued for just such a thing once upon  
a time.  He even wrote a draft about how to do it via DHCP.  But the  
group insisted that route determination must happen separately.  It  
seems some of the design decisions made early on this working group  
are now being dropped.  Perhaps James should revive his draft.  It  
would solve the problem of location hiding with DHCP.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 27 Apr 2007 22:35:30 -0400

This concrete example is helpful.

Since applications such as LoST don't typically do schema validation,  
maybe it's more helpful to look at what an application would actually  
do, such as using SAX and DOM.

Clearly, the application only has a limited repertoire of XML tags  
that it recognizes and then parses. It will presumably build up its  
internal data structure from those elements.

There are two cases:

(1) Senders can only generate certain orderings of elements, such as  
Point followed by civicAddress, even though the schema allows any  
ordering. A 'profile' specifies this.

(2) Any ordering permitted by the schema can appear in the XML document.

Doing (1) simplifies processing, since there are fewer elements that  
can occur at any given time, but with an event-based or DOM-based  
model, it doesn't seem to make a whole lot of difference.

We obviously do want to restrict the GML elements that can occur in  
the XML sent, but that's a standardization issue, not a labeling  
issue. Thus, I'm all in favor of defining profiles for the sender.

I just don't see how a profile label (beyond the namespace  
indications) would simplify the processing or improve error processing.

Henning

On Apr 26, 2007, at 11:54 PM, Andrew Newton wrote:

> <gml:Point>?  Nothing.  From an XML processors perspective, it  
> could be GML followed by some other stuff that can be ignored (look  
> at processContents="lax").  What's the cue to the application that  
> it shouldn't ignore <cl:civicAddress>?  How does it know that is  

Either LoST knows about a civicAddress or it doesn't. Just having the  
schema in the catalog doesn't make a difference, as it has to  
understand the semantics, e.g., to do matching and caching.

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 27 Apr 2007 22:35:24 -0500

I have no problem with that, and I don't think that I argued either for
or against such a proposal.

> Sent: Saturday, 28 April 2007 11:31 AM
> To: Winterbottom, James
> Cc: Ted Hardie; Henning Schulzrinne; ECRIT; James M. Polk