Re: [Ecrit] Profiles (was: Consensus Call)

[Andrew Newton <andy at hxr.us>]

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

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