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

[Henning Schulzrinne <hgs at cs.columbia.edu>]

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:

> Tiny remark:
>
> Henning Schulzrinne 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
> 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


_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit