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

["Thomson, Martin" <[e-mail]>]

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:[e-mail]]
> Sent: Wednesday, 11 March 2009 1:53 PM
> To: Thomson, Martin
> Cc: GEOPRIV
> Subject: Re: Comments on draft-polk-geopriv-include-exclude-filters-00
> 
> 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
> 
> 
> >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.
> 
> perhaps you're right
> 
> 
> >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."
> 
> 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.
> 
> 
> >==Nits
> >
> >All the examples use the 4119 civil namespace; they should use the
> >5139 civic namespace.
> 
> fair nit
> 
> 
> >The examples use gml:location, which wont work since it's deprecated
> >and PIDF-LO profile uses other elements.
> 
> got me again
> 
> 
> >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]
> 

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