geopriv@ietf.org: July 2009

Friday, July 31, 2009

Re: [Geopriv] [geopriv] #14: uncertainty specification

> I think that uncertainty should be speicified in meters, independent > from the CRS, and the members of the WG that i have spoken to seem to > agree.
I agree too.

With uncertainty expressed in degrees one has to understand whether that means:

1. (lat+/-u', lon+/-u')

i.e. the region bounded by (lat-u -> lat+u, lon-u -> lon+u). The shape of
and area of this region depends on where you are on the globe, and you also
get large problems with wrap-around at the poles.

or

2. (lat, lon) +/- u'

i.e. anywhere within the 3d-chord specified with center (lat, lon) subtending
u degrees. This is a circular region that has almost the same shape and area
everywhere (WGS84 ellipsoid notwithstanding).

It's slightly tricky - personally if someone said " (51'N, 1'W) +/- 1' " I'd probably assume definition 1 above, and take that to mean "50 - 52 N, 2 - 0 W".

However IMHO definition 2 is more intuitive. It's also much more consistent with specifying the uncertainty in meters.

Ray

Re: [Geopriv] [geopriv] #5: Client guidance about the datum field

Just a couple of reminders:

-The consensus after the virtual interim was the following (http://www.ietf.org/mail-archive/web/geopriv/current/msg07207.html
):

The bis should provide guidance about what clients should do when they
receive a datum they do not understand. For example, the document
could recommend ignoring the bits that are not understood.

-Here's the thread from the last time we discussed this: http://www.ietf.org/mail-archive/web/geopriv/current/msg07090.html

Alissa

On Jul 29, 2009, at 11:15 AM, Ray.Bellis@nominet.org.uk wrote:

>
> > no, it actually isn't. We assume it's WGS84 - as it's the most
> common
> > CRS and the one everyone is moving towards, that's the safest way
> > forward considering what I say next.
>
> Unfortunately 3825 doesn't say that either.
>
> If that *is* the way forward, that would mitigate the effect of the
> version flags, although one would hope that a trivial "datum = value
> & 0x07" will make that unnecessary on future client implementations.
>
> > yeah Ray, but he isn't writing a bis that adds the concept of
> > versioning the second time around.
>
> Agreed.
>
> > If this were (time-machine alert) 2004, then this should have been
> > written into 3825. I agree. But it's not 2004 -- and we shouldn't
> > knowingly reduce the number of clients that get location they will
> > keep without having the ability to inform anyone/thing there's a
> > problem. Not when it affects emergency calling, which we all know
> > your stance will affect it adversely.
>
> My stance is based on an (implicit) understanding that clients would
> already suffer this problem if a new datum were introduced in future
> revisions of 3825.
>
> > wow -- that's quality Monday morning quarterbacking 5 years later.
>
> I apologise, that was poorly worded.
>
> > Perhaps you shouldn't make you attacks so personal until you've
> > written your own RFCs for others to thrash.
>
> The first one is in the queue and due for publication September.
>
> Ray
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Thursday, July 30, 2009

Re: [Geopriv] [geopriv] #14: uncertainty specification

> Short question: What would be the semantics of a negative
> "uncertainty"
> value?

Please disregard that question, Martin. Plenary brain drain :-/

Alex
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] #14: uncertainty specification

> > <figure><artwork><![CDATA[
> > p = crsp / uncertaintyp / parameter
> > uncertaintyp = ";uncertainty=" pnum
> > num = [ "-" ] pnum
> > pnum = 1*DIGIT [ "." 1*DIGIT ]
> > ]]></artwork></figure>

Short question: What would be the semantics of a negative "uncertainty"
value?

Alex
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] #14: uncertainty specification

> Apologies, but can someone clarify, if Richard's question about
> expressing uncertainty in degrees has been answered. With the
> beautiful amount of detail in recent answers; I may have missed it.

Hi Stephen,

It was Ivan posing the question. My most recent response to this was
(Ivan's text quoted at top):

--- snip ---

>
> Also note that when transforming from a given CRS to WGS 84, the
> transformation of the associated uncertainty may be non-trivial.

Correct. That's why i am in favour in *always* expressing uncertainty in
meters - which would

--- snip ---

I think that uncertainty should be speicified in meters, independent
from the CRS, and the members of the WG that i have spoken to seem to
agree.

Alex
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] #14: uncertainty specification

Apologies, but can someone clarify, if Richard's question about
expressing uncertainty in degrees has been answered. With the
beautiful amount of detail in recent answers; I may have missed it.

Kind regards

Stephen

2009/7/29 Ivan Shmakov <oneingray@gmail.com>:
>>>>>> Richard Barnes <rbarnes@bbn.com> writes:
>
> >> Q) shall the draft specify such uncertainty, or shall it leave that
> >> to an external specification?
>
> > The draft should specify an uncertainty radius in meters, either as a
> > basic element or as a parameter.
>
> And once again, I wonder, how uncertainty in meters is supposed
> to be mapped to uncertainty in degrees?
>
> Please consider the following examples.
>
> * Assignment #1: drawing uncertainty on a world map
>
> Given the world map drawn in (longitude, latitude) coordinate
> system with WGS 84 as the datum (you may use the world.dat file
> shipped with Gnuplot for a crude ``continents only'' world map),
> draw the shape corresponding to a spherical circle of the given
> radius, with the given point as its center.
>
> You will get more credits if you use a Mercator-projection map
> instead.
>
> * point: 83.75N 53.36E, radius: 500000 m.
>
> * Use case #1: omit insignificant digits
>
> How do you transform a geo: URI specifying both location (using
> `wgs84' as the coordinate system) and uncertainty (in meters) so
> that the insignificant digits will be omitted?
>
> * geo:53.36,83.75;crs=wgs84;uncertaintyradius=50000
>
> * Use case #2: spatial relationship
>
> The application is given a number of geo: URIs specifying both
> location (`wgs84') and uncertainty (meters; varies.) Is there a
> simple way to find how the locations given are related? Do
> these URI specify completely distinct locations, or can some of
> them, taking the uncertainty into account, indeed code the same
> location?
>
> As an example, could you please point the URIs out of the
> following list that can be suspected of being related to the
> same object, just expressed with different precision?
>
> * geo:53.36,83.75;crs=wgs84;uncertaintyradius=30000
> geo:53.3,83.7;crs=wgs84;uncertaintyradius=10000
> geo:52.53,85.17;crs=wgs84;uncertaintyradius=20000
>
> * Use case #3: mapping geo: URIs to mapping services
>
> The current version of the draft reads:
>
> --cut: http://www.ietf.org/id/draft-ietf-geopriv-geo-uri-01.txt --
> <p>one of Vienna's popular sights is the <a href='geo:
> 48.198634,16.371648;crs=wgs84'>Karlskirche</a>.
>
> A web brower could extract the coordinates from the HTML snippet, and
> offer the user various options (based on configuration, context), for
> example:
>
> ...
>
> o switch to a mapping service of the user's choice once the link is
> selected
> --cut: http://www.ietf.org/id/draft-ietf-geopriv-geo-uri-01.txt --
>
> The URL to switch to Google Maps could be constructed as
> follows:
>
> http://maps.google.com/maps?ll=LATITUDE,LONGITUDE&spn=LAT-SPAN,LON-SPAN
>
> where LATITUDE and LONGITUDE are the coordinates, and LAT-SPAN,
> LON-SPAN give the extent of the map (``spans''; in degrees) to
> be displayed.
>
> The uncertainty specified within the geo: URI could be related
> to the scale (i. e., LAT-SPAN, LON-SPAN) of the map. How do you
> calculate the spans given some uncertainty expressed in meters?
>
> * Use case #4: travelling to Kemerovo
>
> Before travelling to Kemerovo you have taken a look at its
> Wikipedia page [1] and learned its geo: URI:
>
> geo:55.36083,86.08889;crs=wgs84;uncertaintyradius=5000
>
> [1] http://en.wikipedia.org/wiki/Kemerovo
>
> Travelling to Kemerovo by car, you've glanced at your GPS and
> read:
>
> geo:55.38400,86.09200;crs=wgs84;uncertaintyradius=42
>
> Do you expect to see the city around, or not yet?
>
> * Use case #1 re-visited: absolute uncertainty
>
> --cut: http://www.av8n.com/physics/uncertainty.htm --
> 1.2 How Should Uncertainty Be Expressed?
>
> If you want to express the uncertainty, express it separately and
> explicitly. For example, absolute uncertainty can be properly
> expressed as 1.234(55) or equivalently 1.234+-0.055. Relative
> uncertainty can be expressed as 2900+-13%.
> --cut: http://www.av8n.com/physics/uncertainty.htm --
>
> Given the following geo: URI, how could the absolute uncertainty
> of the coordinates be calculated?
>
> geo:53.36,83.75;crs=wgs84;uncertaintyradius=50000
>
> * And finally, ...
>
> ... given how trivial the cases above become when the
> uncertainty is expressed using the same units as used for the
> coordinates, why should the obstacles be invented?
>
> --
> FSF associate member #7257
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] #14: uncertainty specification

> What about shortening the "uncertainty" parameter name for brevity, for
> example to "u"?

Fine with me.

> > 
>
> Well. This circles around the issue of "allowing" vs "not precluding".
> I
> deliberately left that out of the current specification, and would have
> expected documents adding new CRSes to update the "crsp" component of
> the ABNF - and would remove the need for a "crs" parameter value
> registry at this point (with being just one CRS defined).
>
> This is a question how "open" we want to be at this point.

From what I've seen, the ABNF is left open, but the text is more restrictive. That means that implementations of the base spec don't choke on extensions if they strictly follow the BNF. You've already done that for parameters, so it's just a matter of consistently applying the principle.

> Can we refer to some previous work on how "uncertainty" is defined?

I have an informational doc, but we never seem to get around to discussing adopting it.

http://tools.ietf.org/html/draft-thomson-geopriv-uncertainty

In fact, I've never actually presented it. I'd like to, one of these days.

--Martin
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] #14: uncertainty specification

Martin,

Thanks for that work - i will incorporate it soon into a new revision.
Some comments inline

> <figure><artwork><![CDATA[
> p = crsp / uncertaintyp / parameter
> uncertaintyp = ";uncertainty=" pnum
> num = [ "-" ] pnum
> pnum = 1*DIGIT [ "." 1*DIGIT ]
> ]]></artwork></figure>

What about shortening the "uncertainty" parameter name for brevity, for
example to "u"?

>

Well. This circles around the issue of "allowing" vs "not precluding". I
deliberately left that out of the current specification, and would have
expected documents adding new CRSes to update the "crsp" component of
the ABNF - and would remove the need for a "crs" parameter value
registry at this point (with being just one CRS defined).

This is a question how "open" we want to be at this point.

> 
>
> <section title="Location Uncertainty">
> <t>The 'uncertainty' parameter indicates the amount of
> uncertainty in the location as a value in meters. Where a
> geo URI is used to identify the location of a particular
> subject, uncertainty indicates the uncertainty with which the
> location of the subject is known.
> </t>
>
> <t>The 'uncertainty' parameter is optional and it can appear
> only once. If no uncertainty is specified, this indicates
> that uncertainty is unknown or unspecified. If the intent is
> to indicate a specific point in space, uncertainty MAY be set
> to zero. Zero uncertainty and absent uncertainty are never
> the same thing.
> </t>
> </section>

Can we refer to some previous work on how "uncertainty" is defined?

>

Ack.

>

Ack. Will change.

>

Ack.

> 
>
> <section title="2D GML 'Point'">
> <t>A 2D GML <xref target="RFC5491">'Point'</xref> is
> constructed from a 'geo' URI that has two coordinates and an
> uncertainty parameter that is absent or zero. A GML point is
> always converted to a 'geo' URI that has no uncertainty parameter.
> </t>
> <figure><preamble>'geo' URI:</preamble>
> <artwork><![CDATA[
> geo:%lat%,%lon%
> ]]></artwork></figure>
> <figure><preamble>GML document:</preamble>
> <artwork><![CDATA[
> <Point srsName="urn:ogc:def:crs:EPSG::4326"
> xmlns="http://www.opengis.net/gml">
> <pos>%lat% %lon%</pos>
> </Point>
> ]]></artwork></figure>
>
> <t>Note that a 'geo' URI with an uncertainty value of zero is
> converted to a GML 'Point', but a GML 'Point' cannot be
> translated to a 'geo' URI with zero uncertainty.
> </t>

You saying that the uncertainty parameter must be left out, because GML
does not specify it?

> </section>
>
> <section title="3D GML 'Point'">
> <t>A 3D GML <xref target="RFC5491">'Point'</xref> is
> constructed from a 'geo' URI that has three coordinates and
> an uncertainty parameter that is absent or zero. A GML point
> is always converted to a 'geo' URI that has no uncertainty parameter.
> </t>
> <figure><preamble>'geo' URI:</preamble>
> <artwork><![CDATA[
> geo:%lat%,%lon%,%alt%
> ]]></artwork></figure>
> <figure><preamble>GML document:</preamble>
> <artwork><![CDATA[
> <Point srsName="urn:ogc:def:crs:EPSG::4979"
> xmlns="http://www.opengis.net/gml">
> <pos>%lat% %lon% %alt%</pos>
> </Point>
> ]]></artwork></figure>
>
> </section>
> <section title="GML 'Circle'">
> <t>A GML <xref target="RFC5491">'Circle'</xref> is
> constructed from a 'geo' URI that has two coordinates and an
> uncertainty parameter that is present and non-zero.
> </t>
> <figure><preamble>'geo' URI:</preamble>
> <artwork><![CDATA[
> geo:%lat%,%lon%;uncertainty=%unc%
> ]]></artwork></figure>
> <figure><preamble>GML document:</preamble>
> <artwork><![CDATA[
> <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326"
> xmlns:gml="http://www.opengis.net/gml"
> xmlns:gs="http://www.opengis.net/pidflo/1.0">
> <gml:pos>%lat% %lon%</gml:pos>
> <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
> %unc%
> </gs:radius>
> </gs:Circle>
> ]]></artwork></figure>
>
> </section>
>
> <section title="GML 'Sphere'">
> <t>A GML <xref target="RFC5491">'sphere'</xref> is
> constructed from a 'geo' URI that has three coordinates and
> an uncertainty parameter that is present and non-zero.
> </t>
> <figure><preamble>'geo' URI:</preamble>
> <artwork><![CDATA[
> geo:%lat%,%lon%,%alt%;uncertainty=%unc%
> ]]></artwork></figure>
> <figure><preamble>GML document:</preamble>
> <artwork><![CDATA[
> <gs:Sphere srsName="urn:ogc:def:crs:EPSG::4979"
> xmlns:gml="http://www.opengis.net/gml"
> xmlns:gs="http://www.opengis.net/pidflo/1.0">
> <gml:pos>%lat% %lon% %alt%</gml:pos>
> <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
> %unc%
> </gs:radius>
> </gs:Sphere>
> ]]></artwork></figure>
>
> </section>
>
> <-- I think that's it. I'm in two mins on the need for
> including anything special in comparison. On the one hand, I
> don't like the idea that each parameter gets special
> treatment. And special treatment is not possible for any
> extensions made to the format, making this a form of
> favouritism. On the other hand, numerical comparison makes
> sense for this parameter... -->

Yes, it's a hard issue. But given that we cannot foresee what future
parameters will be created, i don't think we can create generic language
on parameter comparison (unless we reduce it to textual comparison on
_all_ parameters).

Thanks again for the great (and amazingly quick!) work.

Alex
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] #14: uncertainty specification

<section title="Location Uncertainty">
<t>The 'uncertainty' parameter indicates the amount of uncertainty in the location as a value in meters. Where a geo URI is used to identify the location of a particular subject, uncertainty indicates the uncertainty with which the location of the subject is known.
</t>

<t>The 'uncertainty' parameter is optional and it can appear only once. If no uncertainty is specified, this indicates that uncertainty is unknown or unspecified. If the intent is to indicate a specific point in space, uncertainty MAY be set to zero. Zero uncertainty and absent uncertainty are never the same thing.
</t>
</section>

<section title="2D GML 'Point'">
<t>A 2D GML <xref target="RFC5491">'Point'</xref> is constructed from a 'geo' URI that has two coordinates and an uncertainty parameter that is absent or zero. A GML point is always converted to a 'geo' URI that has no uncertainty parameter.
</t>
<figure><preamble>'geo' URI:</preamble>
<artwork><![CDATA[
geo:%lat%,%lon%
]]></artwork></figure>
<figure><preamble>GML document:</preamble>
<artwork><![CDATA[
<Point srsName="urn:ogc:def:crs:EPSG::4326"
xmlns="http://www.opengis.net/gml">
<pos>%lat% %lon%</pos>
</Point>
]]></artwork></figure>

<t>Note that a 'geo' URI with an uncertainty value of zero is converted to a GML 'Point', but a GML 'Point' cannot be translated to a 'geo' URI with zero uncertainty.
</t>

</section>

<section title="3D GML 'Point'">
<t>A 3D GML <xref target="RFC5491">'Point'</xref> is constructed from a 'geo' URI that has three coordinates and an uncertainty parameter that is absent or zero. A GML point is always converted to a 'geo' URI that has no uncertainty parameter.
</t>
<figure><preamble>'geo' URI:</preamble>
<artwork><![CDATA[
geo:%lat%,%lon%,%alt%
]]></artwork></figure>
<figure><preamble>GML document:</preamble>
<artwork><![CDATA[
<Point srsName="urn:ogc:def:crs:EPSG::4979"
xmlns="http://www.opengis.net/gml">
<pos>%lat% %lon% %alt%</pos>
</Point>
]]></artwork></figure>

</section>
<section title="GML 'Circle'">
<t>A GML <xref target="RFC5491">'Circle'</xref> is constructed from a 'geo' URI that has two coordinates and an uncertainty parameter that is present and non-zero.
</t>
<figure><preamble>'geo' URI:</preamble>
<artwork><![CDATA[
geo:%lat%,%lon%;uncertainty=%unc%
]]></artwork></figure>
<figure><preamble>GML document:</preamble>
<artwork><![CDATA[
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0">
<gml:pos>%lat% %lon%</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
%unc%
</gs:radius>
</gs:Circle>
]]></artwork></figure>

</section>

<section title="GML 'Sphere'">
<t>A GML <xref target="RFC5491">'sphere'</xref> is constructed from a 'geo' URI that has three coordinates and an uncertainty parameter that is present and non-zero.
</t>
<figure><preamble>'geo' URI:</preamble>
<artwork><![CDATA[
geo:%lat%,%lon%,%alt%;uncertainty=%unc%
]]></artwork></figure>
<figure><preamble>GML document:</preamble>
<artwork><![CDATA[
<gs:Sphere srsName="urn:ogc:def:crs:EPSG::4979"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0">
<gml:pos>%lat% %lon% %alt%</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
%unc%
</gs:radius>
</gs:Sphere>
]]></artwork></figure>

</section>

<-- I think that's it. I'm in two mins on the need for including anything special in comparison. On the one hand, I don't like the idea that each parameter gets special treatment. And special treatment is not possible for any extensions made to the format, making this a form of favouritism. On the other hand, numerical comparison makes sense for this parameter... -->

--Martin

> -----Original Message-----
> From: Alexander Mayrhofer [mailto:alexander.mayrhofer@nic.at]
> Sent: Thursday, 30 July 2009 11:19 AM
> To: Thomson, Martin; Richard Barnes; trac@localhost.amsl.com
> Cc: geopriv@ietf.org
> Subject: RE: [Geopriv] [geopriv] #14: uncertainty specification
>
>
> Richard, Martin,
>
> Are you willing to provide text for the "uncertainty" parameter?
>
> ;-)
>
> Alex
>
>
> > -----Original Message-----
> > From: geopriv-bounces@ietf.org
> > [mailto:geopriv-bounces@ietf.org] On Behalf Of Thomson, Martin
> > Sent: Thursday, July 30, 2009 11:10 AM
> > To: Richard Barnes; trac@localhost.amsl.com
> > Cc: geopriv@ietf.org
> > Subject: Re: [Geopriv] [geopriv] #14: uncertainty specification
> >
> > I would like to see this included, but suggest that the
> > uncertainty is best left as a parameter. It fits better
> > there. I don't know what you mean by "basic element", but if
> > it's part of the core list of numbers, then that would risk
> > the data from being mistaken for coordinate data (e.g. the
> > 4th dimension).
> >
> > > -----Original Message-----
> > > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> > > Behalf Of Richard Barnes
> > > Sent: Wednesday, 29 July 2009 3:56 PM
> > > To: trac@localhost.amsl.com
> > > Cc: geopriv@ietf.org
> > > Subject: Re: [Geopriv] [geopriv] #14: uncertainty specification
> > >
> > > > Q) shall the draft specify such uncertainty, or shall it
> > leave that
> > > to an
> > > > external specification?
> > >
> > > The draft should specify an uncertainty radius in meters,
> > either as a
> > > basic element or as a parameter.
> > > _______________________________________________
> > > Geopriv mailing list
> > > Geopriv@ietf.org
> > > https://www.ietf.org/mailman/listinfo/geopriv
> >
> > --------------------------------------------------------------
> > ----------------------------------
> > This message is for the designated recipient only and may
> > contain privileged, proprietary, or otherwise private information.
> > If you have received it in error, please notify the sender
> > immediately and delete the original. Any unauthorized use of
> > this email is prohibited.
> > --------------------------------------------------------------
> > ----------------------------------
> > [mf2]
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www.ietf.org/mailman/listinfo/geopriv
> >
> >
> >

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Geo URI - recap and way forward

> My point is that the geo: URIs may actually be useful in
> metadata entries. When the data these entries describe uses
> non-WGS 84 CRS (which is true for most of the raster data sets
> derived from satellite observations; check Landsat 7 data on
> http://www.landcover.org/, for instance, or you may refer to the
> vast variety of data sets available through
> https://wist.echo.nasa.gov/), it seems to be inappropriate to
> use WGS 84. Especially when both the sender and receiver of the
> geo: URI use non-WGS 84 CRS internally (consider, e. g.,
> MapServer showing Landsat 7 data.)

As you outlined below, the "professional" GIS world has multiple options
available when conveying spatial information in a variety of CRSes. The
"geo" URI specification aims at filling the gap that there's no simple,
easy to use and human readable format that's well standardized.

Simplicity is a key feature for me in the scheme. If you want
complexity, there are enough other schemes to go with.

> There, of course, exist other ways to express such information
> (like GML, for instance) while preserving the CRS, which,
> however, seem to me somewhat cumbersome, when compared to a URN
> with one more URN embedded within it.
>
> Also note that when transforming from a given CRS to WGS 84, the
> transformation of the associated uncertainty may be non-trivial.

Correct. That's why i am in favour in *always* expressing uncertainty in
meters - which would

A) not require any transformations on the uncertainty value
B) make the uncertainty parameter independent from the crs parameter
C) make uncertainty understandable and measureable to non-GIS people too
(my mum understands +/+100 meters, but not +/-0.03 degrees)

> Having said that, I believe that the specification, if allowing
> the use of non-WGS 84 CRSes, should warn about possible
> interoperability problems and generally recommend /against/ such
> CRSes, except for the special cases (like, e. g., passing the
> locations between two agents that already use non-WGS 84 CRS
> internally.)
>
> > Regarding uncertainty

I would leave that to the specifications which define the additional
CRSes.

Alex
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Geo URI - recap and way forward

>>>>> Alexander Mayrhofer <alexander.mayrhofer@nic.at> writes:

[...]

> Regarding the specification of Coordinate Reference Systems:

[...]

> Ted Hardie then proposed that we should not *preclude* the potential
> future use of other reference systems:

> http://www.ietf.org/mail-archive/web/vcarddav/current/msg00989.html

> Which i have finally added to the draft. However, this was never
> intended as an "let all CRSes bloom" option for the URI - as outlined
> above, this was more intended as an "emergency exit" once WGS-84
> becomes obsolete (which is not going to happen anytime soon, as far
> as i understand - note that WGS-84 is being adopted over time -
> please don't fall for thinking that "84" in "WGS-84" has the same
> meaning as "95" in "Windows 95" - there's no need to "upgrade"!)

> I think that letting thousands of CRSes bloom for the URI is
> dangerous - it will clearly limit interopability, and impact the
> original goal of having something that's simple, human readable, and
> easy to use (even for people who don't even know what a CRS is, and
> just enter the coordinates into a mapping service or their car
> navigation system).

> So, please let's stay with primarily one CRS, and use the parameter
> as an "emergency exit" mechanism only. Obviously, that also means
> that i am opposing the use of an URI/URN as the specification of the
> CRS.

My point is that the geo: URIs may actually be useful in
metadata entries. When the data these entries describe uses
non-WGS 84 CRS (which is true for most of the raster data sets
derived from satellite observations; check Landsat 7 data on
http://www.landcover.org/, for instance, or you may refer to the
vast variety of data sets available through
https://wist.echo.nasa.gov/), it seems to be inappropriate to
use WGS 84. Especially when both the sender and receiver of the
geo: URI use non-WGS 84 CRS internally (consider, e. g.,
MapServer showing Landsat 7 data.)

There, of course, exist other ways to express such information
(like GML, for instance) while preserving the CRS, which,
however, seem to me somewhat cumbersome, when compared to a URN
with one more URN embedded within it.

Also note that when transforming from a given CRS to WGS 84, the
transformation of the associated uncertainty may be non-trivial.

Having said that, I believe that the specification, if allowing
the use of non-WGS 84 CRSes, should warn about possible
interoperability problems and generally recommend /against/ such
CRSes, except for the special cases (like, e. g., passing the
locations between two agents that already use non-WGS 84 CRS
internally.)

> Regarding uncertainty

[...]

> However, i would very much like to declare the "uncertainty"
> parameter out of scope of the current document, and create a
> different document for that parameter (Martin Thomson has indicated
> he would be willing to work on this?).

FWIW, I've no objections to this.

[...]

--
FSF associate member #7257
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] #14: uncertainty specification

Richard, Martin,

Are you willing to provide text for the "uncertainty" parameter?

;-)

Alex

> -----Original Message-----
> From: geopriv-bounces@ietf.org
> [mailto:geopriv-bounces@ietf.org] On Behalf Of Thomson, Martin
> Sent: Thursday, July 30, 2009 11:10 AM
> To: Richard Barnes; trac@localhost.amsl.com
> Cc: geopriv@ietf.org
> Subject: Re: [Geopriv] [geopriv] #14: uncertainty specification
>
> I would like to see this included, but suggest that the
> uncertainty is best left as a parameter. It fits better
> there. I don't know what you mean by "basic element", but if
> it's part of the core list of numbers, then that would risk
> the data from being mistaken for coordinate data (e.g. the
> 4th dimension).
>
> > -----Original Message-----
> > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> > Behalf Of Richard Barnes
> > Sent: Wednesday, 29 July 2009 3:56 PM
> > To: trac@localhost.amsl.com
> > Cc: geopriv@ietf.org
> > Subject: Re: [Geopriv] [geopriv] #14: uncertainty specification
> >
> > > Q) shall the draft specify such uncertainty, or shall it
> leave that
> > to an
> > > external specification?
> >
> > The draft should specify an uncertainty radius in meters,
> either as a
> > basic element or as a parameter.
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www.ietf.org/mailman/listinfo/geopriv
>
> --------------------------------------------------------------
> ----------------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original. Any unauthorized use of
> this email is prohibited.
> --------------------------------------------------------------
> ----------------------------------
> [mf2]
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>
>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] Geo URI - recap and way forward

(sorry, this is a bit long)

We had quite a lively dicussion on the list and in face to face meetings
over the last few days about the "geo" URI, and i'd like to get the
discussion back on track so that we can progress the document - much of
what was brought forward on the list veers off what imho we had agreed
in previous meetings and discussions.

Regarding the specification of Coordinate Reference Systems:
------------------------------------------------------------

In the session in San Francisco, there was concensus that simplicity is
one of the primary desireable properties of the format. In the
discussion, it was pointed out that it seems to be a good idea that
pushing the complexity to the sender rather than the receiver is good.
This led to the conclusion that using WGS-84 as the most widely used
reference system was a good thing, and there was consensus that
concentrating on a single reference system has less potential to confuse
authors and receivers.

http://www.ietf.org/mail-archive/web/vcarddav/current/msg00992.html
http://www.ietf.org/mail-archive/web/vcarddav/current/msg00966.html

It was noted that almost any reference system can easily be tranformed
into WGS-84 with freely available open source software (as Ivan has
pointed out as well), however, it is desireable to push the load of
transforming to senders rather than clients - clients might not have the
resources available.

*However*, concerns were raised that if in the future, another reference
system would become the predominant CRS, the scheme would still be stuck
with WGS-84 without an option to specify a different CRS (GLONASS and
Galileo were mentioned, however Carl Reed pointed out that the
differences are negligable:

http://www.ietf.org/mail-archive/web/geopriv/current/msg07302.html

Ted Hardie then proposed that we should not *preclude* the potential
future use of other reference systems:

http://www.ietf.org/mail-archive/web/vcarddav/current/msg00989.html

Which i have finally added to the draft. However, this was never
intended as an "let all CRSes bloom" option for the URI - as outlined
above, this was more intended as an "emergency exit" once WGS-84 becomes
obsolete (which is not going to happen anytime soon, as far as i
understand - note that WGS-84 is being adopted over time - please don't
fall for thinking that "84" in "WGS-84" has the same meaning as "95" in
"Windows 95" - there's no need to "upgrade"!)

I think that letting thousands of CRSes bloom for the URI is dangerous -
it will clearly limit interopability, and impact the original goal of
having something that's simple, human readable, and easy to use (even
for people who don't even know what a CRS is, and just enter the
coordinates into a mapping service or their car navigation system).

So, please let's stay with primarily one CRS, and use the parameter as
an "emergency exit" mechanism only.
Obviously, that also means that i am opposing the use of an URI/URN as
the specification of the CRS.

Regarding uncertainty
---------------------

This dicussion recently came up (and, the inclusion of URI parameters
actually opened that "can of worm"). Generally, i have the impression
that the general consensus is that such information would be useful.

However, i would very much like to declare the "uncertainty" parameter
out of scope of the current document, and create a different document
for that parameter (Martin Thomson has indicated he would be willing to
work on this?).

There are various issues with this, including:

- dimensionality
- units
- relation to "crs" parameter?
- comparison of two URIs?

And i am sure there are more. Again, we should take care here to not
violate the original goal of simplicity and brevity - we have an
established mechanism for conveying more complex geometries called
PIDF-LO anyway...

Way Forward
-----------

I have only heard back from very few people within the group, so will do
the following to the draft document:

- Add a registry specification for the URI parameters, specifying that
registry
- Clarify text that significant digits should not misinterpreted as
uncertainty
- Extend / clarify the motivation behind a default CRS
- Add text in the style agreed with the chairs in hallway discussions
about privacy

I'd really like to Last Call that before Hiroshima if possible,
especially since i might not be able to attend there.

Comments?

Alex
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] #14: uncertainty specification

I would like to see this included, but suggest that the uncertainty is best left as a parameter. It fits better there. I don't know what you mean by "basic element", but if it's part of the core list of numbers, then that would risk the data from being mistaken for coordinate data (e.g. the 4th dimension).

> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Richard Barnes
> Sent: Wednesday, 29 July 2009 3:56 PM
> To: trac@localhost.amsl.com
> Cc: geopriv@ietf.org
> Subject: Re: [Geopriv] [geopriv] #14: uncertainty specification
>
> > Q) shall the draft specify such uncertainty, or shall it leave that
> to an
> > external specification?
>
> The draft should specify an uncertainty radius in meters, either as a
> basic element or as a parameter.
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] #11: Registry for URI parameters?

I have the same response here as I had on #13. The registry is probably necessary, but standards action is a good choice.

> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of geopriv issue tracker
> Sent: Wednesday, 29 July 2009 3:32 PM
> To: alexander.mayrhofer@nic.at
> Cc: geopriv@ietf.org
> Subject: [Geopriv] [geopriv] #11: Registry for URI parameters?
>
> #11: Registry for URI parameters?
> ----------------------------------------+------------------------------
> -----
> Reporter: alexander.mayrhofer@nic.at | Owner:
> Type: defect | Status: new
> Priority: major | Milestone:
> Component: geo-uri | Version:
> Severity: Active WG Document | Keywords:
> ----------------------------------------+------------------------------
> -----
> Currently, the draft defines one URI parameter - "crs", as a
> compromise to
> not conclude the use of other CRSes
>
> Q1) should the draft define a IANA URI parameter registry for the
> "geo"
> URI, and register the single "crs" parameter
>
> Q2) If yes, what action should be required for registering a parameter
> name
>
> (Note: from experience with the Enumservices, i would strongly oppose
> "expert review", and go for "standards action")
>
> --
> Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/11>
> geopriv <http://tools.ietf.org/geopriv/>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] #13: registry for "crs" parameter

I take a different perspective. I take this to mean:

If crs=wgs84 :
...and there are three values: 4979,
...and there are two values: 4326,
...else, it's not valid.

New definitions might do the same, or they can be constrained to only one or other.

Currently, the draft only supports the creation of a new CRS code if it is of dimension 2 or 3. That's OK with me.

On the actual issue: we probably have to create the registry, and standards action is good.

--Martin

> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of James M. Polk
> Sent: Thursday, 30 July 2009 1:00 AM
> To: Richard Barnes; trac@localhost.amsl.com
> Cc: geopriv@ietf.org
> Subject: Re: [Geopriv] [geopriv] #13: registry for "crs" parameter
>
> At 08:53 AM 7/29/2009, Richard Barnes wrote:
> >> Q1) Shall the draft specify an IANA registry for the values of the
> "crs"
> >> parameter?
> >
> >Yes.
> >> Q2) if yes, what are the actions required to add a value to this
> registry?
> >
> >Specification Required
>
> if the answer is yes to any of the above, there has to be a registry.
>
> however, I think what Alexander wants is to NOT USE the datum
> identification of "WGS84", but instead specify one meaning
> "CRS:4326", and another meaning "CRS:4979".
>
>
> >_______________________________________________
> >Geopriv mailing list
> >Geopriv@ietf.org
> >https://www.ietf.org/mailman/listinfo/geopriv
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] #12: Query Strings

I agree. b) is best

--Martin

(I note that we need a better indication of when someone is chair or not. I contend that it is better to assume that contributions are made as an individual unless explicitly stated.)

> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Alissa Cooper
> Sent: Wednesday, 29 July 2009 4:52 PM
> To: trac@localhost.amsl.com
> Cc: geopriv@ietf.org
> Subject: Re: [Geopriv] [geopriv] #12: Query Strings
>
>
> > Currently, the draft says that query strings should be ignored by a
> > client
> > application, and they are not specified in the ABNF. Comments from
> > the URI
> > review list indicated that this should be changed.
> >
> > The options are as follows:
> >
> > a) keep the text as currently in the draft (not specified in the
> > ABNF, but
> > recommends clients to ignore if given)
> >
> > b) remove the offending text
> >
> > c) add query strings to the ABNF
>
>
> [chair hat off...]
>
> (b) is the best choice. It doesn't make sense to be querying a point
> in space, and the text as-is doesn't add any value.
>
> Alissa
>
>
>
>
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [sipcore] WGLC:draft-ietf-sipcore-location-conveyance-01.txt

I was going to write a longer comment, but Hannes has already said all that I would have anyway. All of it.

Instead, I'll just note that there are a few places where 2119 text is used to mandate behaviour that is outside the scope of the document and certainly not necessary to ensure interoperability.

For instance,

Implementations MAY choose whether or not to inform the user of this
error. The text string of "Retry Location Later with device updated
location" is RECOMMENDED, but not mandatory for usage in this
error. Implementation MAY use another text string to inform the
user that location was not received by the UAS (i.e., the called
party).

--Martin

> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Hannes Tschofenig
> Sent: Wednesday, 29 July 2009 8:24 PM
> To: 'Gonzalo Camarillo'; 'SIPCORE'
> Cc: geopriv@ietf.org
> Subject: Re: [Geopriv] [sipcore] WGLC:draft-ietf-sipcore-location-
> conveyance-01.txt
>
> Hi Gonzalo,
> Hi James, Hi Brian,
>
> I have done a review of the SIP Location Conveyance already earlier
> this
> year (in March 2009),
> see http://www.ietf.org/mail-archive/web/geopriv/current/msg06955.html.
> I
> re-did it
> for http://www.ietf.org/id/draft-ietf-sipcore-location-conveyance-
> 01.txt.
>
> * I believe that the document should try to avoid the term "using
> protocol"
> at all costs.
> As we know, this term is very confusing and adds no particular value.
>
> Example: Other protocols used in the Location URI MUST be reviewed
> against the RFC 3693 criteria for a Using Protocol.
>
> In human readable language this means: "You have to consider security
> and
> privacy with new extensions." Wow. What a surprising statement!
>
> * Don't understand why this document does not allow a HELD URI to be
> conveyed. I commented this already several times.
>
> Even the IANA registry appears unnecessary for me. You have error
> messages
> defined
> for the cases where the URI isn't understood.
> There aren't too many new protocols to be expected.
>
> * Based on the other list discusssions around this draft I suspect that
> information
> about what the location refers to will be described in a future version
> of
> the document.
>
> * This document is about the transport of a PIDF-LO and not about
> describing
>
> what deployments should do.
>
> Example:
> "
> Adding a new locationValue to an in-transit request SHOULD NOT
> occur for at least two reasons,
>
> #1 - SIP Servers are not the best Sighters, as defined by [RFC3693],
> of geographically where a UAC can be; meaning the location
> information is not necessarily the greatest. There MAY be
> exceptions, but this SHOULD be the rule of thumb.
>
> #2 - without appropriate caution to the fact that Location
> Recipients might not understand how to process more than one
> location, given this document's limited guidance as to what a
> Location Recipient should do when receiving more than one
> location (i.e., currently no priority instructions are given
> for which locationValue to use if there are more than one). A
> Location Recipient can easily be confused by too much location
> information, producing undesirable results. The <tuple id>
> element in the PIDF-LO XML indicates whose location is
> contained in the PIDF-LO.
> "
>
> This example also shows inappropriate usage of RFC2119 language, which
> should
> be used for interoperability.
>
> We know who wants some of this functionality and what the exact use
> case it.
>
> Btw, the term "sighter" is not defined anyway (and not in RFC3693
> either).
> Here is the relevant text part:
>
> This document gives no guidance how this is accomplished, given the
> number of ways a UAC can learn its location, or a SIP intermediary
> can **Sight** a UAC, as defined in [RFC3693].
>
> * In my previous review I complained about the error codes and the
> thought
> that went into them.
> I was wondering whether someone (maybe the authors?) has implemented
> this
> specification in the meanwhile and has gained some
> experience with the error handling already. Are the error codes
> suffient?
> Well enough described?
>
> * I might be too tired today already but the example shown in Section
> 5.1
> seems to be wrong.
>
> It says:
>
> "
> ...
> <gp:location-info>
> <gml:location>
> <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
> <gml:pos>33.001111 -96.68142</gml:pos>
> </gml:Point>
> </gml:location>
> </gp:location-info>
> ...
> "
>
> It should say:
>
> "
> ...
> <gp:location-info>
> <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
> <gml:pos>33.001111 -96.68142</gml:pos>
> </gml:Point>
> </gp:location-info>
> ...
> "
>
>
> *
> "
> Use of self-signed certificates is inappropriate for use in
> protecting a PIDF, as the sender does not have a secure identity of
> the recipient.
> "
>
> This sentence does not make a lot of sense to me. You can use self-
> signed
> certificates for protecting a PIDF before sending it to me.
> The important thing is to make your self-signed cert available to me.
>
> * This document does not need to repeat the text from other documents.
> Example:
> "
> When using LbyR, the location URI MUST NOT contain any user
> identifying information. For example, use something unidentifiable
> like
> "
>
> Already in the LbyR requirements document. Reference it -- no need to
> write new text. That's why we have written these other documents.
>
>
> * "
> If the Location Generator wishes to control whether any location
> included in the SIP request or added along the signaling path of
> this request can be viewed for routing decisions, the Location
> Generator adds a Geolocation header value including the
> "routing-allowed=no" parameter.
> "
>
> Replace "Location Generator" by "Rule Maker".
>
> * Remove useless statements. Example:
> "
> Unless stated otherwise by future standards-track publication(s), a
> LbyR URI only has meaning within the Geolocation header field and
> MUST NOT appear in any other SIP header field.
> "
>
> * Avoid author bias. Example:
>
> "Proxies inserting location for location-based routing are
> unable to meet this requirement, and such use is NOT RECOMMENDED."
>
> The document defines functionality to allow the proxy to add location
> and we
> know who is going to use this.
>
> The text further says:
> "
> Proxies
> conveying location using this extension MUST have the permission of
> the Target to do so.
> "
> Is a Service URN with a service:sos parameter good enough as a
> permission?
> Or what **permission** mechanism are you think about?
>
> *
> "
> Any idea of using SIP Identity is lost as soon as it is
> realized that the Geolocation header value can be added to by
> intermediaries in the signaling path.
> "
>
> That's not the problem. The problem is that the signature calculation
> of SIP
> Identity
> does not cover these new headers.
>
> * I like this acknowledgement "To Dave Oran for helping to shape this
> idea."
>
> The idea that location can be carried in SIP?
>
> * Geopriv Privacy Considerations
>
> This section is pretty useless but I wanted to ask one thing about the
> following text:
>
> "
> Quoting requirement #4 of [RFC3693]:
>
> "The Using Protocol has to obey the privacy and security
> instructions coded in the Location Object and in the
> corresponding Rules regarding the transmission and storage
> of the LO."
>
> This document requires that SIP entities sending or receiving
> location MUST obey such instructions.
> "
>
> What about a SIP node that does not understand SIP location conveyance?
> It sends and receives the messages related to location messages.
>
>
> * Avoid inappropriate treatment of subjects that are discussed
> somewhere
> else. You discuss topics that have been described elsewhere and are
> therefore
> clearly outside the scope of this document.
>
> "
> One facet within this extension is such that locations can be placed
> on a remote server, accessible with the possession of a URI. The
> concept of an LbyR URI has its own security considerations. It is
> tempting to assume that the dereference would have authentication,
> authorization and other security mechanisms that limit the access to
> information. Unfortunately, this might not be true. The access
> network the UAC is connected to can be the source of location
> reference, and it might not have any credentialing mechanism
> suitable for controlling access to location. Consider,
> specifically, a nomadic user connected to an access network in a
> hotel. The UAC has no way to provide a credential acceptable to
> the hotel Location Server (LS) to any of its intended Location
> Recipients. The recipient of a reference does not know if a
> reference has appropriate authorization policies or not. The LS
> should provide location to any requestor.
> "
>
> * I found this paragraph in the security consideration sections. It
> more
> or less argues that the authorization model based on access control
> does
> not work in a number of cases. This is sort of interesting, if one
> additional considers the other work that is being done in GEOPRIV with
> the
> DHCP-URI document where the argument goes into the opposite direction.
>
> "
> Because target locations can be placed on a remote server, called a
> Location Server accessible with the possession of a location URI,
> this URI has its own security considerations. It is tempting to
> assume that the dereference of this URI would have authentication,
> authorization and other security mechanisms that limit the access to
> information. Unfortunately, this might not be true. The access
> network the UAC is connected to can be the source of location
> reference, and it might not have any credentialing mechanism
> suitable for controlling access to a target's location. Consider,
> specifically, a nomadic user connected to an access network in a
> hotel. The UAC has no way to provide a credential acceptable of the
> hotel Location Server (LS) to any of its intended Location
> Recipients. The recipient of a reference does not know if a
> reference has appropriate authorization policies or not.
> "
>
> I am sure the security consideration section will get some more
> feedback
> as the document moves along. If you read through it essentially
> provides
> the following story:
>
> - Conveying location is privacy sensitive and hence the transport
> has to be protected.
> ==> Use S/MIME
> - Well, you cannot really use S/MIME since it isn't deployed.
> ==> Use TLS hop-by-hop.
> - TLS isn't good either since the SIP hops see the location and
> then there is also retargeting. The end host does not know
> the intermedia SIP proxies either so he might not trust them.
> ==> Use an unlinkable pseudonym by placing garbage in the
> entity attribute of the PIDF document.
> - Well. That does not work either.
> ==> Here is the solution: We just let the UA decide what todo. And
> there SHOULD be a way to ask for user consent. Users make good
> decisions!
>
> I would present the story differently:
>
> First, there are 2 important aspects to differentiate from a security
> point
> of view, namely:
> 1) Location Based Routing
> 2) Non-Location Based Routing
>
> With location based routing the idea is that intermedaries see the
> location
> since otherwise
> they cannot route according to it. So, hop-by-hop TLS is the best you
> can
> do. If you don't
> like the consequences of it then you really need to use something like
> LoST
> prior to the
> SIP exchange to discover the entity you need to route to.
>
> With non-location based routing you will have problems with retargeting
> and
> forking.
> The good thing is that nobody says that you have to send location with
> the
> first
> message. Most folks might use TLS for signaling (hopefully) and hence
> at
> least you can deal with
> entities that are eavesdropping (unless they are SIP signaling
> elements). If
> you are worried about
> these entities listening to the location flying by, then you will have
> to
> use S/MIME. To make it
> deployable you could use SIP CERT.
>
> What is probably more important from a threat point of view is the
> ability
> to observe someone's
> movements. This would be possible in a presence based environment (when
> you
> PUBLISH your location
> to a presence / location server). The draft does provide that
> functionality,
> if I correctly
> understand it, but does not discuss it. There, we have our policy work
> that
> deals with this problem,
> namely Common Policy and Geolocation Policy.
>
> Additionally, one might want to mention the attached policies that
> travel
> with location. You could
> also point to the loc-sec architecture document for this purpose (as an
> informative reference).
> If you mention these policies in the security consideration section
> then you
> could also delete the
> "Geopriv Privacy Considerations" section.
>
> Finally, you might want to say that the PIDF-LO is only bound to the
> SIP
> message if SIP Identity is
> used and the location is in the body of the message as the signature
> computation utilized by SIP
> Identity would not cover any of the header fields.
>
> Btw, I have provided text for the security consideration section in the
> past
> already. Luckily it was
> kindly ignored. So, don't expect me to write it again.
>
>
> Ciao
> Hannes
>
> >-----Original Message-----
> >From: sipcore-bounces@ietf.org
> >[mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo Camarillo
> >Sent: 20 July, 2009 10:59
> >To: SIPCORE
> >Subject: [sipcore] WGLC: draft-ietf-sipcore-location-conveyance-01.txt
> >
> >Folks,
> >
> >we would like to start the WGLC of the following draft:
> >
> >http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance-01
> >
> >This WGLC will end on August 7th.
> >
> >Note that there are ongoing threads discussing this draft on the list.
> >The idea is to take those comments as WGLC comments.
> >
> >Also note that we have another WGLC in parallel at this point
> >(info events, whose WGLC ends on July 29th). We have chosen to
> >have this partial overlap between the two WGLCs in order to
> >take advantage of the extra cycles people put in on reviewing
> >drafts during the pre-IETF week.
> >Given that we have canceled the second SIPCORE session in
> >Stockholm, we believe this is a reasonable amount of work for
> >folks following this WG.
> >
> >Keith will be the PROTO shepherd for this draft.
> >
> >Thanks,
> >
> >Gonzalo
> >SIPCORE co-chair
> >
> >_______________________________________________
> >sipcore mailing list
> >sipcore@ietf.org
> >https://www.ietf.org/mailman/listinfo/sipcore
> >
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] My concern with draft-ietf-geopriv-loc-filters-05.txt

I very much agree with your suggestion that we constrain how 4661 is used. A profile would greatly help.

Of course, there is a concern that if we specify a profile, there will be consumers of filters that do not implement the full generic functionality. But I think that we can demonstrate that this complete implementation is unlikely or even impossible.

I reviewed 4661 late in the piece and made a comment about how difficult it would be to implement and how its generic nature was also its biggest weakness.

For instance, there is a requirement that if a required element is specified then that implicitly requires that all other XML nodes necessary to make the document valid. This is actually quite difficult to implement. As long as you have a simple schema, it's probably workable, but complex content models are something of a challenge. I can also give examples of cases where it is possible to specify an element in such a way that this could be achieved in several ways.

PIDF-LO is a great example of such a problem. //ca:A1 can be included, validly, in any of several trees, as you mentioned earlier.

Specifying values in the changed element is different. Implementation is relatively easy. All the filter does is establish a node set - and thereby a set of values - that the server extracts from documents and monitors for changes. That is fairly easily implementable.

I don't want this to head in a direction where we invite string matching or other such un-interoperable hacks. That is, I don't want someone to look for "//${ca}:A1" or something like that.

--Martin

> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Hannes Tschofenig
> Sent: Wednesday, 29 July 2009 8:40 PM
> To: 'Brian Rosen'; geopriv@ietf.org
> Subject: Re: [Geopriv] My concern with draft-ietf-geopriv-loc-filters-
> 05.txt
>
> I don't know how well RFC 4661 is interoperable.
>
> I care about the persons who have to implement this.
> Note that we are talking about dumping this functionality into a LIS.
> The
> LIS will most likely have to implement this functionality without
> potential
> for re-use with other applications.
>
> Maybe the implementation of RFC 4661 is simple and I am worried without
> a
> reason.
>
> Ciao
> Hannes
>
> >-----Original Message-----
> >From: Brian Rosen [mailto:br@brianrosen.net]
> >Sent: 29 July, 2009 20:52
> >To: 'Hannes Tschofenig'; geopriv@ietf.org
> >Subject: RE: [Geopriv] My concern with
> >draft-ietf-geopriv-loc-filters-05.txt
> >
> >Having looked at this, I'm wondering if restricting
> >(prohibiting) certain xpath constructions is wise. I agree
> >suggesting specific ways (the first in your examples) is preferred.
> >
> >Do you see an actual interoperability problem, or merely an
> >opportunity to provide a short cut method to avoid
> >implementing the full xpath?
> >
> >Brian
> >
> >> -----Original Message-----
> >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> >> Sent: Wednesday, July 29, 2009 1:02 PM
> >> To: 'Brian Rosen'; geopriv@ietf.org
> >> Subject: RE: [Geopriv] My concern with
> >draft-ietf-geopriv-loc-filters-
> >> 05.txt
> >>
> >> For example, RFC 4661 would allow you to detect changes in civic
> >> address tokens in the following way:
> >>
> >> <?xml version="1.0" encoding="UTF-8"?> <filter-set
> >> xmlns="urn:ietf:params:xml:ns:simple-filter">
> >> <ns-bindings>
> >> <ns-binding prefix="ca"
> >> urn="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/>
> >> </ns-bindings>
> >> <filter id="123" uri="sip:presentity@example.com">
> >> <trigger>
> >> <changed>//ca:A1</changed>
> >> </trigger>
> >> </filter>
> >> </filter-set>
> >>
> >> Or
> >>
> >> <?xml version="1.0" encoding="UTF-8"?> <filter-set
> >> xmlns="urn:ietf:params:xml:ns:simple-filter">
> >> <ns-bindings>
> >> <ns-binding prefix="pidf"
> urn="urn:ietf:params:xml:ns:pidf"/>
> >> <ns-binding prefix="gp"
> >> urn="urn:ietf:params:xml:ns:pidf:geopriv10"/>
> >> <ns-binding prefix="cl"
> >> urn="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"/>
> >> </ns-bindings>
> >> <filter id="1" uri="sip:presentity@example.com">
> >> <trigger>
> >> <changed>
> >>
> >> /pidf:presence/pidf:tuple/pidf:status/gp:geopriv/gp:location-
> >> info/cl:civicAd
> >> dress/cl:A1
> >> </changed>
> >> <changed>
> >>
> >> /pidf:presence/pidf:device/gp:geopriv/gp:location-
> >> info/cl:civicAddress/cl:A1
> >>
> >> </changed>
> >> <changed>
> >>
> >> /pidf:presence/pidf:person/gp:geopriv/gp:location-
> >> info/cl:civicAddress/cl:A1
> >>
> >> </changed>
> >> </trigger>
> >> </filter>
> >> </filter-set>
> >>
> >>
> >> Do we know anything about the implementation status of RFC 4661?
> >>
> >> Ciao
> >> Hannes
> >>
> >>
> >> >-----Original Message-----
> >> >From: Brian Rosen [mailto:br@brianrosen.net]
> >> >Sent: 29 July, 2009 18:21
> >> >To: 'Hannes Tschofenig'; geopriv@ietf.org
> >> >Subject: RE: [Geopriv] My concern with
> >> >draft-ietf-geopriv-loc-filters-05.txt
> >> >
> >> >Could you cite some examples, please.
> >> >
> >> >Brian
> >> >
> >> >> -----Original Message-----
> >> >> From: geopriv-bounces@ietf.org
> >[mailto:geopriv-bounces@ietf.org] On
> >> >> Behalf Of Hannes Tschofenig
> >> >> Sent: Wednesday, July 29, 2009 10:30 AM
> >> >> To: geopriv@ietf.org
> >> >> Subject: [Geopriv] My concern with
> >draft-ietf-geopriv-loc-filters-
> >> >> 05.txt
> >> >>
> >> >> Hi all,
> >> >>
> >> >> after reading RFC 4660 and RFC 4661, which is heavily used by
> >> >> draft-ietf-geopriv-loc-filters-05.txt I had some concerns.
> >> >RFC 4661 is
> >> >> a very generic format for event notification filtering and
> >> >it is good
> >> >> to re-use the work that was done there. There is, however, a
> >> >> problem with reusing it without putting additional restrictions
> on
> >> >its usage,
> >> >> namely one can accomplish the similar (if not the same) effect
> >> >> using many different ways (at least the XML documents look
> >> >> different that are sent in the SUBSCRIBE body).
> >> >>
> >> >> To me that sounds a lot like the issues we went through with GML.
> >> >> There we also wanted to make the life of the implementer
> >easier by
> >> >> restricting the available options down to an acceptable minimum.
> >> >>
> >> >> I believe we should do the same with
> >> >draft-ietf-geopriv-loc-filters as
> >> >> well.
> >> >> If we find a way how to accomplish a certain
> >functionality then the
> >> >> structure of the XML document is going to be described in detail
> >> >> and that's the way how it looks like and nothing else is allowed.
> >> >>
> >> >> Do others share my concerns?
> >> >>
> >> >> Ciao
> >> >> Hannes
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> Geopriv mailing list
> >> >> Geopriv@ietf.org
> >> >> https://www.ietf.org/mailman/listinfo/geopriv
> >> >
> >
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] My concern with draft-ietf-geopriv-loc-filters-05.txt

1. I think that you've confused this with something else, we're talking about SIP here as well. In effect, GEOPRIV are just adding location support to SIP presence.

2. That boat sailed with 4661.

--Martin

> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of ashok malhotra
> Sent: Thursday, 30 July 2009 12:45 AM
> To: Hannes Tschofenig
> Cc: geopriv@ietf.org
> Subject: Re: [Geopriv] My concern with draft-ietf-geopriv-loc-filters-
> 05.txt
>
> A couple of comments re. RFC 4661
>
> 1. As you know, RFC 4661 was written with the SIP protocol in mind.
> So,
> the filters it discusses are
> a bit different from what would be needed for Geopriv. So, I assume
> you
> are planning on using the spirit,
> not the letter of RFC 4661.
>
> 2. Please, please do not try and subset XPath. I realize that XPath
> is
> a complex specification but if you
> try and subset it you will open yourself to months of argumentation.
> Second, most vendors already have a
> XPath implementation and it's better to just use it rather than prepare
> an implementation for a subset of XPath
>
> All the best, Ashok
>
>
> Hannes Tschofenig wrote:
> > I don't know how well RFC 4661 is interoperable.
> >
> > I care about the persons who have to implement this.
> > Note that we are talking about dumping this functionality into a LIS.
> The
> > LIS will most likely have to implement this functionality without
> potential
> > for re-use with other applications.
> >
> > Maybe the implementation of RFC 4661 is simple and I am worried
> without a
> > reason.
> >
> > Ciao
> > Hannes
> >
> >
> >> -----Original Message-----
> >> From: Brian Rosen [mailto:br@brianrosen.net]
> >> Sent: 29 July, 2009 20:52
> >> To: 'Hannes Tschofenig'; geopriv@ietf.org
> >> Subject: RE: [Geopriv] My concern with
> >> draft-ietf-geopriv-loc-filters-05.txt
> >>
> >> Having looked at this, I'm wondering if restricting
> >> (prohibiting) certain xpath constructions is wise. I agree
> >> suggesting specific ways (the first in your examples) is preferred.
> >>
> >> Do you see an actual interoperability problem, or merely an
> >> opportunity to provide a short cut method to avoid
> >> implementing the full xpath?
> >>
> >> Brian
> >>
> >>
> >>> -----Original Message-----
> >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> >>> Sent: Wednesday, July 29, 2009 1:02 PM
> >>> To: 'Brian Rosen'; geopriv@ietf.org
> >>> Subject: RE: [Geopriv] My concern with
> >>>
> >> draft-ietf-geopriv-loc-filters-
> >>
> >>> 05.txt
> >>>
> >>> For example, RFC 4661 would allow you to detect changes in civic
> >>> address tokens in the following way:
> >>>
> >>> <?xml version="1.0" encoding="UTF-8"?> <filter-set
> >>> xmlns="urn:ietf:params:xml:ns:simple-filter">
> >>> <ns-bindings>
> >>> <ns-binding prefix="ca"
> >>> urn="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/>
> >>> </ns-bindings>
> >>> <filter id="123" uri="sip:presentity@example.com">
> >>> <trigger>
> >>> <changed>//ca:A1</changed>
> >>> </trigger>
> >>> </filter>
> >>> </filter-set>
> >>>
> >>> Or
> >>>
> >>> <?xml version="1.0" encoding="UTF-8"?> <filter-set
> >>> xmlns="urn:ietf:params:xml:ns:simple-filter">
> >>> <ns-bindings>
> >>> <ns-binding prefix="pidf"
> urn="urn:ietf:params:xml:ns:pidf"/>
> >>> <ns-binding prefix="gp"
> >>> urn="urn:ietf:params:xml:ns:pidf:geopriv10"/>
> >>> <ns-binding prefix="cl"
> >>> urn="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"/>
> >>> </ns-bindings>
> >>> <filter id="1" uri="sip:presentity@example.com">
> >>> <trigger>
> >>> <changed>
> >>>
> >>> /pidf:presence/pidf:tuple/pidf:status/gp:geopriv/gp:location-
> >>> info/cl:civicAd
> >>> dress/cl:A1
> >>> </changed>
> >>> <changed>
> >>>
> >>> /pidf:presence/pidf:device/gp:geopriv/gp:location-
> >>> info/cl:civicAddress/cl:A1
> >>>
> >>> </changed>
> >>> <changed>
> >>>
> >>> /pidf:presence/pidf:person/gp:geopriv/gp:location-
> >>> info/cl:civicAddress/cl:A1
> >>>
> >>> </changed>
> >>> </trigger>
> >>> </filter>
> >>> </filter-set>
> >>>
> >>>
> >>> Do we know anything about the implementation status of RFC 4661?
> >>>
> >>> Ciao
> >>> Hannes
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Brian Rosen [mailto:br@brianrosen.net]
> >>>> Sent: 29 July, 2009 18:21
> >>>> To: 'Hannes Tschofenig'; geopriv@ietf.org
> >>>> Subject: RE: [Geopriv] My concern with
> >>>> draft-ietf-geopriv-loc-filters-05.txt
> >>>>
> >>>> Could you cite some examples, please.
> >>>>
> >>>> Brian
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: geopriv-bounces@ietf.org
> >>>>>
> >> [mailto:geopriv-bounces@ietf.org] On
> >>
> >>>>> Behalf Of Hannes Tschofenig
> >>>>> Sent: Wednesday, July 29, 2009 10:30 AM
> >>>>> To: geopriv@ietf.org
> >>>>> Subject: [Geopriv] My concern with
> >>>>>
> >> draft-ietf-geopriv-loc-filters-
> >>
> >>>>> 05.txt
> >>>>>
> >>>>> Hi all,
> >>>>>
> >>>>> after reading RFC 4660 and RFC 4661, which is heavily used by
> >>>>> draft-ietf-geopriv-loc-filters-05.txt I had some concerns.
> >>>>>
> >>>> RFC 4661 is
> >>>>
> >>>>> a very generic format for event notification filtering and
> >>>>>
> >>>> it is good
> >>>>
> >>>>> to re-use the work that was done there. There is, however, a
> >>>>> problem with reusing it without putting additional restrictions
> on
> >>>>>
> >>>> its usage,
> >>>>
> >>>>> namely one can accomplish the similar (if not the same) effect
> >>>>> using many different ways (at least the XML documents look
> >>>>> different that are sent in the SUBSCRIBE body).
> >>>>>
> >>>>> To me that sounds a lot like the issues we went through with GML.
> >>>>> There we also wanted to make the life of the implementer
> >>>>>
> >> easier by
> >>
> >>>>> restricting the available options down to an acceptable minimum.
> >>>>>
> >>>>> I believe we should do the same with
> >>>>>
> >>>> draft-ietf-geopriv-loc-filters as
> >>>>
> >>>>> well.
> >>>>> If we find a way how to accomplish a certain
> >>>>>
> >> functionality then the
> >>
> >>>>> structure of the XML document is going to be described in detail
> >>>>> and that's the way how it looks like and nothing else is allowed.
> >>>>>
> >>>>> Do others share my concerns?
> >>>>>
> >>>>> Ciao
> >>>>> Hannes
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Geopriv mailing list
> >>>>> Geopriv@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/geopriv
> >>>>>
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www.ietf.org/mailman/listinfo/geopriv
> >
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

geopriv@ietf.org

Friday, July 31, 2009

Re: [Geopriv] [geopriv] #14: uncertainty specification

Re: [Geopriv] [geopriv] #5: Client guidance about the datum field

Thursday, July 30, 2009

Re: [Geopriv] [geopriv] #14: uncertainty specification

Re: [Geopriv] [geopriv] #14: uncertainty specification

Re: [Geopriv] [geopriv] #14: uncertainty specification

Re: [Geopriv] [geopriv] #14: uncertainty specification

Re: [Geopriv] [geopriv] #14: uncertainty specification

Re: [Geopriv] [geopriv] #14: uncertainty specification

Re: [Geopriv] [geopriv] #14: uncertainty specification

Re: [Geopriv] Geo URI - recap and way forward

Re: [Geopriv] Geo URI - recap and way forward

Re: [Geopriv] [geopriv] #14: uncertainty specification

[Geopriv] Geo URI - recap and way forward

Re: [Geopriv] [geopriv] #14: uncertainty specification

Re: [Geopriv] [geopriv] #11: Registry for URI parameters?

Re: [Geopriv] [geopriv] #13: registry for "crs" parameter

Re: [Geopriv] [geopriv] #12: Query Strings

Re: [Geopriv] [sipcore] WGLC:draft-ietf-sipcore-location-conveyance-01.txt

Re: [Geopriv] My concern with draft-ietf-geopriv-loc-filters-05.txt

Re: [Geopriv] My concern with draft-ietf-geopriv-loc-filters-05.txt

Followers

Blog Archive

Contributors