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

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

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

> On Apr 23, 2007, at 9:19 AM, Henning Schulzrinne wrote:
>
> > 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.
>
> 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.

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.


> > 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.
>
> 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







> -andy


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