Re: [Geopriv] Long review of draft-ietf-geopriv-loc-filters-07
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Geopriv] Long review of draft-ietf-geopriv-loc-filters-07
That's a useful addition. I added the paragraph.
-------- Original-Nachricht --------
> Datum: Wed, 04 Nov 2009 01:05:34 -0600
> Von: "James M. Polk" <jmpolk at cisco.com>
> An: "Hannes Tschofenig" <Hannes.Tschofenig at gmx.net>, "\'Hannes Tschofenig\'" <Hannes.Tschofenig at gmx.net>, "\'Brian Rosen\'" <br at brianrosen.net>, geopriv at ietf.org
> Betreff: RE: [Geopriv] Long review of draft-ietf-geopriv-loc-filters-07
> Hannes
>
> in-line
>
> At 06:36 PM 11/3/2009, Hannes Tschofenig wrote:
> >Here is another one:
> >
> >
> >Draft Text:
> >
> >-----
> >
> >3.3. Element Value Changes
> >Changes in values, for example related to civic location information,
> >is provided by the base functionality offered with RFC 4661 utilizing
> >the <changed> element.
> >Figure 3 shows an example where a notification is sent when the civic
> >address tokens A1, A2, A3, or PC change (all 4 must change in order
> >to let the <trigger> element evaluate to TRUE).
> >
> >------
> >
> >Wow do I not
> >want that limitation. I want to be able to
> >tell when the device has crossed a city
> >boundary (into another city) while still
> >looking to see it the device has changed
> >states/territories yet.
> >I understand that PC changes might be
> >too often (but not always).
> >Is the alternative to have 4 separate
> ><changes> filters to get what I'm
> >describing here?
> >That seems clumbersome.
> >
> >-----
> >
> >This is how RFC 4661 works. Telling whether more than one PC changed
> >independently requires multiple <changes> filters.
>
> ah -- but this is something I don't see in the XML schema, but I may
> have missed it.
>
> Can you verify that the text says that it is possible to have
> multiple <changes> filters.
>
> This could be a short paragraph saying something like:
>
> In times where you want to know if individual CAtypes change,
> put them into separate <changes> filters to ensure you are
> notified when any of the element values change.
>
> James
>
>
> >Ciao
> >Hannes
> >
> >
> > >-----Original Message-----
> > >From: Hannes Tschofenig [mailto:Hannes.Tschofenig at gmx.net]
> > >Sent: 03 November, 2009 16:30
> > >To: 'Brian Rosen'; 'James Polk'; 'geopriv at ietf.org'
> > >Subject: RE: [Geopriv] Long review of draft-ietf-geopriv-loc-filters-07
> > >
> > >Hi James,
> > >
> > >Thanks for your detailed review. I am in the process of
> > >updating it and have comments here and there.
> > >
> > >Here is one:
> > >
> > >Draft Text:
> > >
> > >--------
> > >
> > ><?xml version="1.0" encoding="UTF-8"?>
> > ><filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
> > > <ns-bindings>
> > > <ns-binding prefix="dyn"
> > > urn="urn:ietf:params:xml:schema:pidf:dynamic"/>
> > > </ns-bindings>
> > > <filter id="123" uri="sip:presentity at example.com">
> > > <trigger>
> > > <changed by="3"> [<---James]
> > > //dyn:speed
> > > </changed>
> > > </trigger>
> > > </filter>
> > ></filter-set>
> > >
> > >------
> > >
> > >[James]
> > >
> > >I get the XML,
> > >but I don't see what the speed now is of the device/target?
> > >What if this device is moving at 200kmph, where would that be
> > >placed in the XML?
> > >Of, is this left for the application at the subscriber to calculate?
> > >If the latter is true, something needs to be said about this
> > >expectation.
> > >
> > >------
> > >
> > >The filter would not tell you what the current speed is.
> > >
> > >The current document only supports 'by' and hence you cannot
> > >say something like 'tell me when he goes faster than 100kmph'.
> > >
> > >Ciao
> > >Hannes
> > >
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.