Subject: [Geopriv] Quick random comments on draft-ietf-geopriv-pdif-lo-profile-00

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 05 Jul 2005 16:33:58 -0400

This draft is very helpful and timely. A set of quick comments:

I don't see the point of allowing or recommending a variety of position 
representations. This just adds interoperability testing hassles without 
adding any value. Thus, why use (from the example)

<gml:coordinates>37:46:30N 122:25:10W</gml:coordinates>

at all if this is then called inappropriate and deprecated a section or 
two later?

On a more general level, I'm also doubtful about the wisdom of having 
partial civic (country and floor). I have a hard time picturing a real 
scenario where you would just have these two elements as opposed to both 
full civic (including city and street) and maybe geo. This offers much 
more value to recipients and avoids having to deal with various strange 
incomplete civic address objects. If floor and country is ok, why not 
have people send street number and directional only (125 S), just for 
the entertainment value :-)?

"If only a coverage area is required
    without a nominal central point requiring specification, then this
    form is ideal for representation using GML."

Reference of "this" is unclear.

In general, standards are about making choices. Thus, having a very 
simple set of recommended ways to doing each thing, with alternatives 
relegated to an appendix, will, in my opinion, avoid the needless 
complexity that we have incurred by using GML without sufficient detail. 
Other approaches (like Jabber) avoid this complexity altogether and we 
should strive to make GEOPRIV-based systems as easy to deploy and test.

Also, there are a few references to "emergency services" or "emergency 
routing" (not a clear term, btw). I don't think any of these 
recommendations would change if we were to use PIDF-LO to give 
directions to the local pizza parlor or the AAA tow truck. Thus, unless 
something truly technically depends on emergency services, I would 
remove the qualifiers, as this just leaves open the question what all 
the other uses of PIDF-LO should do to allow some minimal interoperability.

In short, the draft could be 20 pages shorter if it focused on 
recommendations, rather than exploring all alternatives. Putting the 
second-best alternatives in an appendix will at least avoid confusing 
implementors that only look at examples.

Henning

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

---

From: "Carl Reed OGC" <[email-masked]>
Date: Tue, 5 Jul 2005 19:51:32 -0600

Henning -

The OGC membership has developed a draft profile of GML for Point geometries 
and features. Very simple and light weight. It is in the process of going to 
public comment and then formal adoption as an OGC standard by later this 
year.

There is another GML profile also working its way through the OGC approval 
process and should be approved later this year also. It is a GML Simple 
Features profile. This profile of GML is for points, lines, polygons (2d and 
3d) and multi point, multiline, and multi-polygon.

Finally, I am a member of the OASIS Emergency Management Technical 
Committee. We are looking at using the a simple GML schema fragment for 
expressing polygon geometry in EDXL.

The reason I am sharing is that, as Henning points out, we are seeking 
simplicity, flexibility. but above all interoperability.

Cheers

Carl Reed
CTO
OGC

----- Original Message ----- 
From: "Henning Schulzrinne" <[email-masked]>
To: "GEOPRIV" <[email-masked]>
Sent: Tuesday, July 05, 2005 2:33 PM
Subject: [Geopriv] Quick random comments 
ondraft-ietf-geopriv-pdif-lo-profile-00

> incomplete civic address objects. If floor and country is ok, why not have 
> people send street number and directional only (125 S), just for the 
> entertainment value :-)?
>
> In general, standards are about making choices. Thus, having a very simple 
> set of recommended ways to doing each thing, with alternatives relegated 
> to an appendix, will, in my opinion, avoid the needless complexity that we 
> have incurred by using GML without sufficient detail. Other approaches 
> (like Jabber) avoid this complexity altogether and we should strive to 
> make GEOPRIV-based systems as easy to deploy and test.
>
> recommendations would change if we were to use PIDF-LO to give directions 
> to the local pizza parlor or the AAA tow truck. Thus, unless something 
> truly technically depends on emergency services, I would remove the 
> qualifiers, as this just leaves open the question what all the other uses 
> of PIDF-LO should do to allow some minimal interoperability.
>