Subject: Re: [Ecrit] draft-ietf-ecrit-lost-01.txt - service area boundaries

From: Michael Haberler <[email-masked]>
Date: Thu, 14 Sep 2006 00:09:05 +0200

Brian

> with a civic, you likely would always get a civic.  When you get the new
> civic, you get a new postal code.  If it changed, ask for a new mapping.
you semi-answered my underlying question  - how do you do
out-of-service-area detection with civic address and civic area as
returned from LoST as hint?

can I interpret that as to mean:

1. the set of labels in the service area response is a proper subset of
the set of labels in the device's current location
2. the label values of that subset all match as strings

that algorithm would trigger as you decribed in setp 2 - is that what
you're saying?

-Michael

> Now, if you started with a geo, and you got an update, it will be a geo.
> Then you get a polygon.
>
> If you literally can roam through a public WiFi network, this likely will
> actually happen.  When they start doing triangulation between APs, you will
> likely get a geo.
>
> Either way, the LoST mechanism as currently defined, should work well.
>
> Brian
>
>   
>> -----Original Message-----
>> From: Michael Haberler [mailto:[email-masked]]
>> Sent: Tuesday, September 12, 2006 9:52 AM
>> To: Brian Rosen
>> Subject: Re: [Ecrit] draft-ietf-ecrit-lost-01.txt - service area
>> boundaries
>>
>> Brian Rosen schrieb:
>>     
>>> I would want a return like
>>>
>>>       
>>>> <A1>Bavaria</A1>
>>>> <A3>Munich</A3>
>>>> <PC>81675</PC>
>>>>
>>>>         
>>> To mean that as long as I was in 81675, Munich, I could use the same
>>>       
>> URI.
>>     
>>> If I got out of that area, I should ask for a new mapping.  I don't need
>>>       
>> a
>>     
>>> polygon for that.
>>>
>>>       
>> I believe *you* can distinguish "within 81675" from "outside 81675",
>> many poor souls having suffered through Muenchen-Perlach can...
>>     
>>> This is a very practical answer.  If you get a civic address, I don't
>>>       
>> think
>>     
>>> returning a polygon is practical.
>>>
>>>       
>> How do you then, practically, teach your *device* to do the
>> inside/outside discrimination based on the above data sample?
>>
>> The way I read the sample is - it's an area, not an address - hence
>> polygon. It's there for a reason - so the device can do something with
>> it - I just assumed it's more than saying on the screen "btw you are in
>> Muenchen, postal code 81675"
>>
>> My understanding was that area descriptor hint is used to tell a device
>> when it needs to re-query a LoST mapping - at least that's how I
>> interpreted under features, section 1 of  ecrit-lost-01: "Minimizes
>> round trips by caching individual mappings and by supporting return of
>> coverage regions ("hinting")."
>>
>> feeling LoST ,
>>
>> -Michael
>>
>> btw could we rename this protocol to have a less hair-raising name? this
>> sounds like a presales problem in the making.
>>
>>     
>>> Brian
>>>
>>>
>>>       
>>>> -----Original Message-----
>>>> From: Michael Haberler [mailto:[email-masked]]
>>>> Sent: Monday, September 11, 2006 9:58 PM
>>>> To: Hannes Tschofenig
>>>> Cc: ECRIT
>>>> Subject: Re: [Ecrit] draft-ietf-ecrit-lost-01.txt - service area
>>>> boundaries
>>>>
>>>> Hannes -
>>>>
>>>> comment on "Figure 7: Response Message Example providing Civic Location
>>>> Servic Boundary Hints":
>>>>
>>>> I think if a "service area" is returned, it should be possible to
>>>> interpret it without further processing as an unambiguous geospatial
>>>> object - assuming it should drive client behaviour (when do I need to
>>>> re-fetch psap destination?) EXCEPT if the intent is usage solely for
>>>> human consumption.
>>>>
>>>> if the former is the case, how do I interpret
>>>>
>>>> <A1>Bavaria</A1>
>>>> <A3>Munich</A3>
>>>> <PC>81675</PC>
>>>>
>>>> e.g as a polygon? I would assume that this could be the intersection of
>>>> shapes of A1,A3 and PC.
>>>>
>>>> That would require to fetch shapes for A1, A3 and PC "somehow" and
>>>> intersect them.
>>>> Or just PC? that would imply "smallest shape counts"; again fetching
>>>>         
>> the
>>     
>>>> shape needed, how?
>>>>
>>>> Suggestion: always return geo polygons, and optionally return the civic
>>>> name for use as a display name.
>>>>
>>>> -Michael
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> [email-masked]
>>>> https://www1.ietf.org/mailman/listinfo/ecrit
>>>>
>>>>         
>>>
>>>       
>
>
>   

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