In particular, the required responseTime might be lower than the notifier is willing to accept in max-interval. If you want a response in less than 2s, using max-interval is likely to fail. This gives the notifier the control it needs without running afoul of event-rate constraints.
Further, keep in mind that responseTime has a hidden use - that of notifying the LG of how long it has. This helps the LG select the appropriate method so the information is available on time. This can also be applied to later notifications where the notifier needs to go to an LG.
--Martin
> -----Original Message-----
> From: James M. Polk [mailto:jmpolk@cisco.com]
> Sent: Tuesday, 28 July 2009 2:03 PM
> To: Thomson, Martin; Hannes Tschofenig; geopriv@ietf.org
> Subject: RE: [Geopriv] Another Update to draft-ietf-geopriv-loc-
> filters-05.txt
>
> At 05:56 AM 7/28/2009, Thomson, Martin wrote:
> >That's a good use case. It's certainly useful. There are some
> >issues to resolve, but those are minor. I think that this can be
> >resolved with the responseTime attribute and the event rate control
> mechanism.
>
> or... the subscription can be left open for the subsequent location
> update in a subsequent NOTIFY, which is easier, and covers non HELD
> cases - which any mechanism needs to.
>
>
> > > -----Original Message-----
> > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > > Sent: Tuesday, 28 July 2009 12:20 PM
> > > To: 'James M. Polk'; Thomson, Martin; geopriv@ietf.org
> > > Subject: RE: [Geopriv] Another Update to draft-ietf-geopriv-loc-
> > > filters-05.txt
> > >
> > > I was more focused on the following scenario:
> > >
> > > The SIP proxy gets a location URI via SIP. Now, it wants todo
> location
> > > based
> > > routing for the emergency call. It will dereference the location
> URI as
> > > you
> > > mention in Section 4.5 of your document. The LIS does not know that
> > > this is
> > > request is only for location sufficient for routing and it tries to
> > > determine location at a best possible extend. This takes time.
> Then,
> > > when
> > > location is available the NOTIFY is sent. The SIP proxy can route
> the
> > > call
> > > but had to wait longer (potentially longer than Brian states in
> Phone
> > > BCP
> > > regarding the maximum call setup time).
> > >
> > > If I understood the HELD mechanism correctly then there is a way to
> > > indicate
> > > what type of reference the URI should point to (this relates a bit
> to
> > > the
> > > HELD context document). And the same stuff is available in HELD
> deref
> > > as
> > > well.
> > >
> > > Now, I was wondering whether this would be useful in
> > > draft-ietf-geopriv-loc-filters-05.txt as well. Namely, to let the
> SIP
> > > proxy
> > > tell the LIS when it sends a SUBSCRIBE that it wants location for
> > > routing
> > > (and that typically means faster>
> > >
> > > If it does not make sense to anyone then I remove it from
> > > draft-ietf-geopriv-loc-filters-05.txt.
> > >
> > > Ciao
> > > Hannes
> > >
> > >
> > > >-----Original Message-----
> > > >From: James M. Polk [mailto:jmpolk@cisco.com]
> > > >Sent: 28 July, 2009 13:02
> > > >To: Hannes Tschofenig; 'Thomson, Martin'; geopriv@ietf.org
> > > >Subject: RE: [Geopriv] Another Update to
> > > >draft-ietf-geopriv-loc-filters-05.txt
> > > >
> > > >At 11:54 AM 7/27/2009, Hannes Tschofenig wrote:
> > > >>Hi James,
> > > >>
> > > >> >> >More seriously: I'm not entirely sure how to interpret
> > > >> >> >responseTime in the context of a SIP PA. This might work as
> you
> > > >> >> >have described, but I would suggest that it complicates
> things
> > > >> >considerably. There's
> > > >> >> >discussion on this point in my draft here:
> > > >> >> >
> > > >> >>
> > > >><http://tools.ietf.org/html/draft-thomson-simple-cont-presence-
> >va
> > > >> >> >l
> > > >> >> -req-02#section-4.6.1.1>
> > > >> >> >
> > > >> >> >I don't know how to solve this problem yet.
> > > >> >> >
> > > >> >>
> > > >> >>I am not sure I see the problems.
> > > >> >>
> > > >> >>Imagine a SIP proxy receives a SIP message with an LbyR
> > > >and wants to
> > > >> >>retrieve location information for routing. Depending on the
> > > >> >URI scheme
> > > >> >>(HTTP vs. SIP) he would either use
> > > >> >>http://tools.ietf.org/id/draft-winterbottom-geopriv-deref-prot
> > > >> >ocol-03.t
> > > >> >>xt
> > > >> >>Or
> > > >> >>http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-fil
> > > >> >ters-04.t
> > > >> >>xt
> > > >> >
> > > >> >I'm confused.
> > > >> >
> > > >> >For SIP, why would the filters doc be used when Conveyance
> already
> > > >> >has how a server dereferences a location URI for routing?
> > > >> >
> > > >> >This isn't a soliciting action requiring filters.
> > > >>
> > > >>How does SIP Location Conveyance dereference location URIs?
> > > >>My reading of draft-ietf-sip-location-conveyance was that it
> conveys
> > > >>location by value and/or by reference.
> > > >
> > > >I have a section on this. Specifically it is section 4.5
> > > >
> > > > "Using sip/sips/pres as a Dereference Scheme"
> > > >
> > > >I even have a pretty diagram.
> > > >
> > > >
> > > >>What "indication" is used in a SIP SUBSCRIBE to indicate "Please
> give
> > > >>me location information suitable for routing."?
> > > >
> > > >err, a proxy routes based on the location information it is
> > > >given (if it initiates a dereference transaction in the first
> > > >place, there is no "suitable-ness" to it.
> > > >
> > > >The location-based routing process asks for, and receives (or
> > > >not) the PIDF-LO of the Target, then processes the message
> > > >(i.e., making routing decisions) as if it were sent the
> > > >PIDF-LO in the original SIP request. There's no magic to a
> > > >location URI to get a routable location vs. an unroutable
> > > >location -- especially since there is no difference in our
> > > >that same proxy receives location by value.
> > > >
> > > >If you believe there needs to be a suitable-ness to location
> > > >information, then we need a new error code for cases in which
> > > >the supplied location isn't suitable, with exactly what an
> > > >inserter is supposed to do with that error code (i.e., in that
> > > >error code, there needs to be an indication what was missing -
> > > >other than the whole location - that needs to be in the
> > > >subsequent SIP request to make is worthy of being routed.
> > > >
> > > >Which do you want -
> > > >
> > > >#1 - route based on the available location supplied (by-value
> > > >or by-reference)?
> > > >or
> > > >#2 - a new error code and inserter behavior to know what to do
> > > >when insufficient location was provided in the initial SIP
> request?
> > > >
> > > >#1 is easy, cuz that's the way Conveyance is written now.
> > > >
> > > >#2 is much more complicated - both to the routing proxy, and
> > > >the burden on the location inserter to understand what isn't
> > > >enough location, and to correct for just that amount - to
> > > >satisfy the proxy's determination of what it thinks it needs
> > > >to route the message propoerly.
> > > >
> > > >James
> > > >
> > > >
> > > >>Ciao
> > > >>Hannes
> > > >
> > >
> >
> >----------------------------------------------------------------------
> --------------------------
> >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]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
