Subject: [Ecrit] [issue5] PSAP Boundary Hint

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 05 Jun 2006 17:42:01 +0000

New submission from Hannes Tschofenig <[email-masked]>:

The response message may provide information about the PSAP boundary. 

First question: Should the LoST client indicate whether it wants to have the 
PSAP boundary as hint included in the response message? Alternatively, we could 
include this information per-default in a mobility environment (see Geopriv-L7 
discussion). 

Current protocol proposals focused on the distribution of a polygon (when 
geospatial location information is used in the query) to express the PSAP 
boundary. 

Second question: While it is quite simple what to return for geospatial 
location information it seems to be more complicated for civic location 
information. Has someone already thought about civic info? Is there existing 
work outside the IETF we can leverage?

----------
assignedto: hannes
messages: 7
nosy: ecrit, hannes
priority: critical
status: unread
title: PSAP Boundary Hint

__________________________________________________
LoST Issue Tracker <[email-masked]>
<http://www.tschofenig.priv.at:8080/lost/issue5>
__________________________________________________

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 05 Jun 2006 16:13:45 -0400

The only reason not to include it would be to save space in the 
response. In mobile cases, the client would almost always have to query 
for this anyway, to know when to ask for a mapping again, so I don't see 
much advantage of keeping it separate as the total protocol overhead 
would only increase.

As to civic: This is actually fairly easy if we remember that the 
boundary region doesn't have to be complete. In other words, returning a 
subregion is harmless and just results in some additional queries that 
wouldn't be strictly necessary.

Thus, if almost the whole county is covered by a PSAP, you'd just return 
the next-lower A* level (municipality), even though this is a subset of 
the actual coverage region. Since civic information is most useful for 
nomadic and stationary devices and these devices don't tend to move more 
than a few times a day, the impact on query load will be modest.

If we adopt this approach, the descriptor for a civic region is likely 
to be small and thus there doesn't seem to be a reason to have another 
special query.

Henning