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

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

I changed the subject line, since we've strayed a bit from the  
original topic, even though this is still motivated by the topic. Let  
me try again to work through the steps:

- We currently use profiles for both sending and receiving location,  
namely for <location-info> when requesting a mapping and in the  
<serviceBoundary> when such a mapping is being returned. The  
discussion is only about the former, not about the latter.

- In "regular" presence, there is no profile information. In other  
words, if I use RFC 4119, the receiver of presence information has to  
recognize the namespace indicators and the XML tags, as in all other  
XML applications. This has not generated any particular controversy,  
as far as I can tell.

Indeed, http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo- 
profile-06 continues that tradition. There is no profile information,  
just, say, <gml:Polygon> or <gml:Prism>. The receiver of such  
information, e.g., in a NOTIFY, would simply recognize <Polygon> or  
<Prism> and parse it accordingly.

- We agree that for the <location-info>, the profile information only  
provides a hint. The receiver (here, the LoST server) still has to  
recognize the XML tags and has to be prepared to deal with XML that  
doesn't actually follow the profile.

- The XML is self-sufficient. In other words, once you have the GML  
tag, the profile doesn't provide any additional information.

- We all agree, I think, that we should avoid a proliferation of data  
formats, so that the profile in draft-ietf-geopriv-pdif-lo-profile-06  
and similar efforts should guide implementors of PIDF-LO-using  
systems, but this affects producers of LOs and their final consumers.  
LoST clients just copy them.

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

Thus, I believe that using the location-profile for LoST queries, in  
<location-info>, serves no purpose and simply makes system upgrades  
hard or impossible.

Henning


On Apr 24, 2007, at 7:16 AM, Andrew Newton wrote:

> On Apr 23, 2007, at 5:10 PM, Henning Schulzrinne wrote:
>
> > 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.
>
> This then leaves the server to guess about the type of location  
> information.  I don't understand your reasoning for believing  
> servers should not need to know the profile, but that clients do.   
> If one guesses at the type of information it is receiving, then  
> they both can.  And it doesn't sound too helpful to

I'm not sure where you got the notion from the above that "servers  
should not need to know the profile, but clients do". It's the opposite.

> do at either end.  And I'm confused about the relevance of this to  
> the current discussion.
>
> -andy


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