Subject: [Geopriv] Comments on draft-polk-geopriv-include-exclude-filters-00

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 10 Mar 2009 17:25:33 -0500

Hi James,

==General

After some initial confusion about the goals of the document (which I'll get to), I think that this could be a useful document.  I see this as a howto - describing how to achieve a basic set of common goals using subscriptions.  It's a shame that the loc-filters is how it is (see previous discussions on using 4661 for loc-filters), because it would be nice to incorporate those in this as well.

I don't see that this document does anything new.  All the stated objectives in Section 3 can be achieved with the base filters specification.  Therefore, I'd suggest informational or bcp instead of standards track.

There's a lot of work to be done before this could be usable, but I think there is potential.

==Substantive

I don't think that the introductory text sets the right expectations.  Sections 1 and 2 are quite a bit longer than they need to be.

Section 1 could be replaced with an expanded statement to the effect:

  "This document aims to document how location can be retrieved using a SIP subscription.  This document describes how the presence event package [RFC3856] and the XML presence filters specification [RFC4661] can be applied to common location use cases."

Section 2 could be used to enumerate the goals - location type, desired accuracy, 2d v 3d, etc...  (I'll say more about each goal later.)  Section 3 could provide more detail - explain the intent of each filter and describe how each filter achieves the intended goals.

No need for Section 5.

==More detailed

There are a large number of filters described in the draft.  I get the impression that this was a dump of all that you thought might be useful, so that's OK.  Some of these are useful, but I don't think all of these are necessary.

For instance, 2d/3d is something better done by a location recipient.  If 4661 alone was employed, specifying one would mean no location information is provided if only the other is available.  This would be a job for loc-filters.  I'd be include to argue against including such an option.  3d can be trivially converted to 2d; the converse is rarely possible.

I can see no point in asking for location with altitude in kilometres.  If the recipient is unable to divide by 1000, then they are not fit to be operating a computer.

Limiting to specific shapes is not a bad suggestion.  Easy to do with 4661.  No point mentioning Linear Rings though - that's a necessary consequence of using GML to represent Polygons.

Selecting civic elements again can be achieved with 4661, however optional elements is potentially something for loc-filters.

==Nits

All the examples use the 4119 civil namespace; they should use the 5139 civic namespace.

The examples use gml:location, which wont work since it's deprecated and PIDF-LO profile uses other elements.

The examples bind the rpid namespace without using it.

Cheers,
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]

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 10 Mar 2009 21:53:22 -0500

At 05:25 PM 3/10/2009, Thomson, Martin wrote:
>Hi James,
>
>==General
>
>After some initial confusion about the goals of the document (which 
>I'll get to), I think that this could be a useful document.

thanks

>I see this as a howto

yes, one that I believe is necessary to avoid confusion

>- describing how to achieve a basic set of common goals using 
>subscriptions.  It's a shame that the loc-filters is how it is (see 
>previous discussions on using 4661 for loc-filters),

yeah - I was just going to write a section Brian could put into his 
filters ID when I figured out (ok, I'm slow) that I couldn't do that, 
and that a new doc was necessary - given the stated objectives of the 
filters doc.

>because it would be nice to incorporate those in this as well.

see above, that was my original plan...

>I don't see that this document does anything new.

Probably not yet, but I also didn't capture all that I wanted to 
capture -- and in discussing this ID with Adam Roach, he seemed to 
think this was a small but clear update to 4661.

>All the stated objectives in Section 3 can be achieved with the base 
>filters specification.

see my comment above (but what Adam said, and my admission that I 
don't have everything in the ID at this point.

>Therefore, I'd suggest informational or bcp instead of standards track.

if you're right, then info or bcp is the right direction.  If Adam is 
right, the PS is the direction... i'm not pushing this aspect now, 
the doc is just too incomplete

>I don't think that the introductory text sets the right 
>expectations.  Sections 1 and 2 are quite a bit longer than they need to be.

perhaps you're right

>   "This document aims to document how location can be retrieved 
> using a SIP subscription.  This document describes how the presence 
> event package [RFC3856] and the XML presence filters specification 
> [RFC4661] can be applied to common location use cases."

this is good. thanks

>Section 2 could be used to enumerate the goals - location type, 
>desired accuracy, 2d v 3d, etc...  (I'll say more about each goal 
>later.)  Section 3 could provide more detail - explain the intent of 
>each filter and describe how each filter achieves the intended goals.

I agree with this

>No need for Section 5.
>
>==More detailed
>
>There are a large number of filters described in the draft.  I get 
>the impression that this was a dump of all that you thought might be 
>useful, so that's OK.  Some of these are useful, but I don't think 
>all of these are necessary.
>
>For instance, 2d/3d is something better done by a location recipient.

but what about the seeker that wants 3D, and the normal responses are 
in 2D. how does the seeker ask for altitude?  this is why this is there.

>  If 4661 alone was employed, specifying one would mean no location 
> information is provided if only the other is available.

perhaps this is a desired result because an implementation cannot do 
anything with the otehr format, so why waste the BW sending what 
can't/won't be processed.

>This would be a job for loc-filters.  I'd be include to argue 
>against including such an option.  3d can be trivially converted to 
>2d; the converse is rarely possible.

yeah - but now I'm confused with what you said above. Are you 
suggesting "always ask for 3D, and the LR can convert back to 
2D"?  If so, then I agree with what you say here.

>I can see no point in asking for location with altitude in 
>kilometres.  If the recipient is unable to divide by 1000, then they 
>are not fit to be operating a computer.

hehe... ok, kilometers is out.

>Limiting to specific shapes is not a bad suggestion.

I thought so

>Easy to do with 4661.  No point mentioning Linear Rings though - 
>that's a necessary consequence of using GML to represent Polygons.

ok

>Selecting civic elements again can be achieved with 4661, however 
>optional elements is potentially something for loc-filters.

loc-filters is for "interesting events (like movement and speed)... I 
don't see how that doc applies to a stationary object.

BTW - I call these optional elements the really desirable ones, 
contrary to the mandatory ones.

BTW II - I see the mention of the optional vs mandatory filters, but 
the examples are hard to figure out how to manipulate into examples I 
wanted to use.

>All the examples use the 4119 civil namespace; they should use the 

fair nit

>and PIDF-LO profile uses other elements.

got me again

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 10 Mar 2009 22:10:51 -0500

Looks like we are mostly in agreement, aside from a few questions.

Most of the questions relate to "optional" components.  4661 provides all-or-nothing type of semantics.  Anything "optional" actually relates to quality.

Take altitude - you can require it all you like, but if the PA doesn't actually have any way of getting it, you're only going to miss out on the information that it does have.  In a lot of cases, you want to say: "I'd like this thanks if you have it."  

For instance, if you want 3D, using 4661 naively you could inadvertently prevent the PA from sending you any location at all.  If it can't give you altitude, then it can't give you altitude.  In this case, as with those related to location quality, I prefer that a "soft" filter be defined.  I think that we can do some of that with 4661, but not all.  In actual fact, it might not be appropriate to put those examples in this document.

I'd recommend reading of draft-thomson-simple-cont-presence-val-req and draft-thomson-geopriv-location-quality, which deal with the issue of quality, soft filters and other related issues.

Cheers,
Martin

> -----Original Message-----
> From: James M. Polk [mailto:[email-masked]]
> Sent: Wednesday, 11 March 2009 1:53 PM
> To: Thomson, Martin
> Cc: GEOPRIV
> Subject: Re: Comments on draft-polk-geopriv-include-exclude-filters-00
>

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 10 Mar 2009 22:52:14 -0500

At 10:10 PM 3/10/2009, Thomson, Martin wrote:
>Most of the questions relate to "optional" components.  4661 
>provides all-or-nothing type of semantics.  Anything "optional" 
>actually relates to quality.

perhaps this is the update part to 4661?

i.e., "I must have these 6 elements, and want these other 4"

>Take altitude - you can require it all you like, but if the PA 
>doesn't actually have any way of getting it,

I agree with this so far, but this is something that ought to have an 
error associated with it - similar to the Require header in SIP, 
verses the Supported header. If you put something (an option-tag) in 
the Require header and the UAS doesn't support that option-tag, the 
request is rejected (per 3261).

>you're only going to miss out on the information that it does 
>have.  In a lot of cases, you want to say: "I'd like this thanks if 
>you have it."

yes, and I'd like to make that explicit, instead of implicit -- 
avoiding a situation of the a response not carrying something that 
would have been useful that the requested entity didn't bother to include.

>For instance, if you want 3D, using 4661 naively you could 
>inadvertently prevent the PA from sending you any location at all.

I think we need to describe exactly how to avoid this scenario.

>  If it can't give you altitude, then it can't give you 
> altitude.  In this case, as with those related to location quality, 
> I prefer that a "soft" filter be defined.  I think that we can do 
> some of that with 4661, but not all.  In actual fact, it might not 
> be appropriate to put those examples in this document.
>
>I'd recommend reading of draft-thomson-simple-cont-presence-val-req 
>and draft-thomson-geopriv-location-quality, which deal with the 
>issue of quality, soft filters and other related issues.

will do

Thanks
James

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 12 Mar 2009 10:28:59 -0400

Just a note on loc-filters.  I have most of the text edited to make it 4661
compatible.  My XML knowledge ran out trying to create the schema which uses
the 4661 extension point, and I was unable to find an example of doing this.
I asked someone for help, but so far, I haven't got something to work from.
As soon as I figure out how to create the schema, I will publish an update
to loc-filters that extends 4661.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of James M. Polk
Sent: Tuesday, March 10, 2009 10:53 PM
To: Thomson, Martin
Cc: GEOPRIV
Subject: Re: [Geopriv] Comments on
draft-polk-geopriv-include-exclude-filters-00

thanks

perhaps you're right

this is good. thanks

I agree with this

I thought so

ok

fair nit

got me again

>The examples bind the rpid namespace without using it.

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