Re: [Geopriv] HELD comment on responseTime parameter

From: Henning Schulzrinne ^lt;hgs@cs.columbia.edu>
Date: Mon Jul 30 2007 - 06:22:25 EDT

I'll add to the discussion that relying on long-delayed HTTP responses
is unwise in the presence of NATs. I've seen hotel NATs that time out
TCP state after 30 seconds of inactivity.

I think the semantics of this are sufficiently ill-defined that this
seems like a good candidate for a protocol extension. It will only be
relevant for some subset of location technologies in any event.

I hope we would agree that neither client nor server would have to
insert or observe such a parameter.

It might also be more useful to have some indication in the protocol
that says something along the lines of "this information is preliminary;
if you ask again in a minute, I'll have better data available".

Like Brian, I have no clue what value a client can usefully specify,
beyond "I need it NOW" (since I'm dialing 9-1-1 right now and just
turned on the phone) and "give me the best you got, however long it
takes" (since I'm just turning on the phone and want to do a pre-need
LoST mapping).

If anything, a client cares about the available accuracy, as in "give me
at least 100 m accuracy since anything less isn't useful to me" (and
take whatever time you need). After all, timing out with continent-level
accuracy after 10 seconds is not terribly useful for pizza delivery or
emergency calls, particularly if the client has no clue whether waiting
for 11 seconds will yield a street-precise location or not. It also
doesn't tell the client whether asking again later will yield better
accuracy or not.

Thus, we should think about how a client can ask for information that is
useful to it. A timing parameter may not be that way. As noted, this can
be done at a later stage.

Henning

Richard Barnes wrote:
> - The HTTP timers say how quickly the client wants an HTTP response.
> - HELD responses are in 1-1 correspondence with HTTP responses.
> * Ergo, the HTTP timers say how quickly the client wants a HELD response.
>
> It's a duplication of functionality to have a timer within HELD when
> there's already a semantically equivalent mechanism in HTTP.
>
> --Richard
>
>
>
>
> Dawson, Martin wrote:
>> Because the application layer semantics are specifically for a client to
>> tell the location server how quickly it wants a location fix. It's a
>> layer violation to use HTTP timers for this. I don't know what the
>> default response time for HTTP is but based on how long browsers
>> typically hang around waiting for a response, it's a long time. I think
>> a location client wants immediate control over the location service
>> response time and not to rely on the artefacts of an underlying
>> transport protocol.
>>
>> Cheers,
>> Martin
>> -----Original Message-----
>> From: Richard Barnes [mailto:richard.barnes@gmail.com] Sent: Tuesday,
>> 24 July 2007 7:19 AM
>> To: Winterbottom, James
>> Cc: Brian Rosen; Dawson, Martin; Stark, Barbara; Mary Barnes;
>> geopriv@ietf.org
>> Subject: Re: [Geopriv] HELD comment on responseTime parameter
>>
>> Doesn't this then raise the question of whether time-out of requests
>> is a "transport layer" issue (where, from the perspective of HELD, the
>> transport layer includes HTTP and SIP). If you're getting location
>> from a SIP subscription, we already know how to set the response time.
>> I think there are mechanisms for varying the HTTP time-out as well.
>>
>> Why do this at a higher layer as well?
>>
>> --Richard
>>
>>
>>
>> On 7/23/07, Winterbottom, James <James.Winterbottom@andrew.com> wrote:
>>> Hi Richard,
>>>
>>> I think you are mixing transport timeouts with application timeouts.
>>> If I bind an application protocol to a different transport I will
>> still
>>> want the application timeouts to be the same, and these may be shorter
>>> than what the transport protocol allows as its maximum.
>>>
>>> Cheers
>>> James
>>>
>>>> -----Original Message-----
>>>> From: Richard Barnes [mailto:richard.barnes@gmail.com]
>>>> Sent: Tuesday, 24 July 2007 5:03 AM
>>>> To: Winterbottom, James
>>>> Cc: Brian Rosen; Dawson, Martin; Stark, Barbara; Mary Barnes;
>>>> geopriv@ietf.org
>>>> Subject: Re: [Geopriv] HELD comment on responseTime parameter
>>>>
>>>> Maybe the disconnect is this: In other protocols, time-outs are
>> fixed
>>>> in the standard, not set differently from one transaction to
>> another.
>>>> For instance, RFC 3261 sets a whole host of timers to default
>> values,
>>>> and says, essentially, "Don't deviate from these defaults unless you
>>>> have a really good reason." I think that HTTP sets similar
>>>> time-outs.
>>>>
>>>> The question is, why should HELD behave differently?
>>>>
>>>> --Richard
>>>>
>>>>
>>>>
>>>> On 7/23/07, Winterbottom, James <James.Winterbottom@andrew.com>
>> wrote:
>>>>> Brian,
>>>>>
>>>>> You have repeatedly stated an arbitrary 30 second I will give up
>>> time.
>>>>> I can see applications saying 20 second best you can give please.
>>>>> Having the scalar allows you to still achieve what you want, it
>>> provides
>>>>> flexibility for other applications developed by people with far
>> more
>>>>> imagine than you or I.
>>>>>
>>>>> If the LIS/LCS knows when the client is likely to give up, then it
>>> has
>>>>> the opportunity to forestall that and fallback. Without it the
>> query
>>>>> simply fails.
>>>>>
>>>>> Cheers
>>>>> James
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Brian Rosen [mailto:br@brianrosen.net]
>>>>>> Sent: Tuesday, 24 July 2007 4:51 AM
>>>>>> To: Dawson, Martin; 'Stark, Barbara'; 'Mary Barnes';
>>> geopriv@ietf.org
>>>>>> Subject: RE: [Geopriv] HELD comment on responseTime parameter
>>>>>>
>>>>>> I don't wish to be obstinate, or obstructionist.
>>>>>>
>>>>>> I'm simply asking for a use case. I can't think of one.
>>>>>>
>>>>>> I get the notion that if you force the issue, the client
>>> eventually
>>>>> wants
>>>>>> to
>>>>>> give up and get the best location it can. I think it has GREAT
>>>>> difficulty
>>>>>> in coming up with a numeric limit which has time frames measured
>>> in
>>>>>> seconds.
>>>>>> I don't know how a client would do that.
>>>>>>
>>>>>> I think the best way forward is to cut, not expand complexity.
>>>>>>
>>>>>> Request timeouts are short in code; a point you wish to ignore.
>>> They
>>>>> are
>>>>>> much shorter than 30 seconds. Most are shorter than a second.
>>> When
>>>>> you
>>>>>> need to wait longer than that, you need to do something complex,
>>> like
>>>>>> create
>>>>>> a polling loop, or spin off a thread or something. I know how
>> to
>>>>> write
>>>>>> this
>>>>>> kind of code. Code doesn't block for 30 seconds.
>>>>>>
>>>>>> I don't want a protocol that takes 30 seconds to complete single
>>>>>> request/response cycle. I don't think code is written that way.
>>> I
>>>>> want
>>>>>> an
>>>>>> event or call back mechanism for that. If all I got was
>>> effectively,
>>>>>> "now",
>>>>>> that is enough. We need a mechanism that does event
>> notification
>>> or
>>>>> call
>>>>>> back for updates. Use that if "now" won't work. In nearly
>> every
>>> real
>>>>>> system, "now" always works; it's just that the location
>>> information
>>>>> may be
>>>>>> rough (like cell site/sector), the first time you request it.
>>>>>>
>>>>>> I think we have two mechanisms: an LCP and a dereference
>>> mechanism.
>>>>> The
>>>>>> dereference mechanism needs a notification or call back. That
>> is
>>>>>> sufficient. I'd like to stop there, rather than have a value
>>>>> mechanism
>>>>>> with
>>>>>> a call back or event other than dereference.
>>>>>>
>>>>>> I propose to eliminate the parameter entirely. You get an
>>> "immediate"
>>>>>> response, a value or a reference.
>>>>>>
>>>>>> Brian
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
>>>>>>> Sent: Monday, July 23, 2007 2:09 AM
>>>>>>> To: Brian Rosen; Stark, Barbara; Mary Barnes; geopriv@ietf.org
>>>>>>> Subject: RE: [Geopriv] HELD comment on responseTime parameter
>>>>>>>
>>>>>>> Well, that's rubbish. If a VoIP phone sends a request for
>>> location,
>>>>> are
>>>>>>> you suggesting it will be prepared to wait forever before
>>> attempting
>>>>> to
>>>>>>> make the call anyway or cancelling the operation or whatever?
>>>>> Perhaps
>>>>>>> you've never written client code. It just needs to provide the
>>> same,
>>>>> or
>>>>>>> lower, time to the location server as the one associated with
>>> its
>>>>>>> request timeout.
>>>>>>>
>>>>>>> In any case, there's another approach that will give you your
>>>>> desired
>>>>>>> semantics and still maintain what I consider to be the
>> essential
>>>>> scalar
>>>>>>> parameter.
>>>>>>>
>>>>>>> A response value of zero is essentially meaningless - no
>> result
>>> can
>>>>> be
>>>>>>> returned in zero time. So, how about the value of zero be
>> given
>>>>> special
>>>>>>> semantics. This would be your "right away" semantics - that
>> is,
>>> the
>>>>>>> location server will return the fastest (and possibly least
>>>>> accurate)
>>>>>>> location that it can muster and return that - however long it
>>> takes.
>>>>>>> How to deal with your other semantic "take as long as you like
>>> but
>>>>> get
>>>>>>> me the best, most accurate, location that you can muster" is a
>>> bit
>>>>>>> different.
>>>>>>>
>>>>>>> It's hard to see how to explicitly indicate that but, if the
>>>>> response
>>>>>>> time parameter is made optional, then it could be the default
>>>>> semantic
>>>>>>> in the case of the response time not being provided.
>>>>>>>
>>>>>>> How does that sound as a compromise?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Martin
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Brian Rosen [mailto:br@brianrosen.net]
>>>>>>> Sent: Monday, 23 July 2007 10:18 AM
>>>>>>> To: Dawson, Martin; 'Stark, Barbara'; 'Mary Barnes';
>>>>> geopriv@ietf.org
>>>>>>> Subject: RE: [Geopriv] HELD comment on responseTime parameter
>>>>>>>
>>>>>>> No, I want a use case: some application where the client has
>>> some
>>>>> notion
>>>>>>> of
>>>>>>> how long it can wait expressed in some kind of scalar.
>>>>>>>
>>>>>>> I can't think of an application where the client has some
>>> threshold
>>>>> of
>>>>>>> waiting which it has regardless of what the server can do, and
>>> it
>>>>> can
>>>>>>> usefully construct a value to put in a scalar.
>>>>>>>
>>>>>>> Brian
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
>>>>>>>> Sent: Sunday, July 22, 2007 6:35 PM
>>>>>>>> To: Brian Rosen; Stark, Barbara; Mary Barnes;
>> geopriv@ietf.org
>>>>>>>> Subject: RE: [Geopriv] HELD comment on responseTime
>> parameter
>>>>>>>> Client advises server that it can wait 5 seconds for a
>>> response to
>>>>> be
>>>>>>>> used in a routing application. Server invokes first higher
>>> level
>>>>> of
>>>>>>>> accuracy calculation (rather than fastest / least accurate).
>>>>> Client
>>>>>>>> receives more accurate location [than if it had asked for an
>>>>> immediate
>>>>>>>> response]. Routing application receives a more accurate
>>> location
>>>>> than
>>>>>>> it
>>>>>>>> may have otherwise. Routing accuracy for the application is
>>>>> therefore
>>>>>>>> improved.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Martin
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Brian Rosen [mailto:br@brianrosen.net]
>>>>>>>> Sent: Monday, 23 July 2007 6:54 AM
>>>>>>>> To: Dawson, Martin; 'Stark, Barbara'; 'Mary Barnes';
>>>>> geopriv@ietf.org
>>>>>>>> Subject: RE: [Geopriv] HELD comment on responseTime
>> parameter
>>>>>>>> Please supply a use case for an L7 Location Configuration
>>> Protocol
>>>>>>> that
>>>>>>>> can
>>>>>>>> profitably use a scalar.
>>>>>>>>
>>>>>>>> Brian
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
>>>>>>>>> Sent: Sunday, July 22, 2007 2:13 AM
>>>>>>>>> To: Brian Rosen; Stark, Barbara; Mary Barnes;
>>> geopriv@ietf.org
>>>>>>>>> Subject: RE: [Geopriv] HELD comment on responseTime
>>> parameter
>>>>>>>>> All the client has to know is how long it is prepared to
>>> wait
>>>>> for a
>>>>>>>>> result. That's it.
>>>>>>>>>
>>>>>>>>> I don't see any new information in your post - a couple of
>>>>> things I
>>>>>>>>> disagree with but none that are really relevant to how the
>>> delay
>>>>>>>>> tolerance should be prescribed. I vote for a scalar
>>> parameter.
>>>>>>>>> Cheers,
>>>>>>>>> Martin
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Brian Rosen [mailto:br@brianrosen.net]
>>>>>>>>> Sent: Sunday, 22 July 2007 6:27 AM
>>>>>>>>> To: Dawson, Martin; 'Stark, Barbara'; 'Mary Barnes';
>>>>>>> geopriv@ietf.org
>>>>>>>>> Subject: RE: [Geopriv] HELD comment on responseTime
>>> parameter
>>>>>>>>> I'm sorry, but this still makes no sense to me.
>>>>>>>>>
>>>>>>>>> I'm having difficulty figuring out how any application can
>>> use
>>>>> any
>>>>>>>>> values
>>>>>>>>> other than "now" and "when it's good", especially with no
>>>>> accuracy
>>>>>>>>> parameters. Whether "when it's good" is 5 seconds, 15
>>> seconds,
>>>>> 30
>>>>>>>>> seconds
>>>>>>>>> or any other value, I still don't see how you can really
>> use
>>> it.
>>>>>>>>> I understand that the methods for measurement are varied,
>>> and
>>>>> have
>>>>>>>>> different
>>>>>>>>> response times. I don't see how a client of the protocol
>>> can
>>>>> make
>>>>>>> use
>>>>>>>>> of
>>>>>>>>> that acknowledged fact. All of the apps that use location
>>> that
>>>>> I
>>>>>>> can
>>>>>>>>> think
>>>>>>>>> of only can use "now" or "when it's good", as long as they
>>> can
>>>>> give
>>>>>>> up
>>>>>>>>> on
>>>>>>>>> the "when it's good".
>>>>>>>>>
>>>>>>>>> If we were trying to more closely match what actually
>>> happens
>>>>> with
>>>>>>>>> measurement based location determination, or which GPS is
>>> the
>>>>>>> easiest
>>>>>>>>> example to work with, we would have the protocol deal with
>>> start
>>>>> up
>>>>>>>>> issues.
>>>>>>>>> The characteristic of GPS is that there is a significant
>>> start
>>>>> up
>>>>>>>> time,
>>>>>>>>> but
>>>>>>>>> after that, location updates equivalent to "now" is what
>> you
>>>>> get.
>>>>>>>>> Most triangulation mechanisms have some kind of start up,
>>> most
>>>>> have
>>>>>>>>> updates
>>>>>>>>> equivalent to "now", but some don't (some triangulation
>>> really
>>>>> is a
>>>>>>>>> triggered measurement, which has finite, non trivial time
>> to
>>>>>>> complete
>>>>>>>> a
>>>>>>>>> measurement).
>>>>>>>>>
>>>>>>>>> When there is a delay for an accurate measurement, the
>>> server
>>>>> knows
>>>>>>>> what
>>>>>>>>> the
>>>>>>>>> delay is. If we were trying to really get both sides to
>> do
>>>>>>> something
>>>>>>>>> reasonably optimal, we'd have the server tell the client
>>> what it
>>>>> can
>>>>>>>> do,
>>>>>>>>> and
>>>>>>>>> have the client react in some reasonable way.
>>>>>>>>>
>>>>>>>>> When there is a startup issue, and sometimes when there is
>> a
>>>>>>>> significant
>>>>>>>>> time to complete a measurement, there can be intermediate,
>>> less
>>>>> than
>>>>>>>>> full
>>>>>>>>> accuracy results. Again, if we were trying to make
>> optimal
>>>>>>>>> applications,
>>>>>>>>> the server would have some way to tell the client what it
>>> could
>>>>> do,
>>>>>>>> and
>>>>>>>>> have
>>>>>>>>> the client react.
>>>>>>>>>
>>>>>>>>> No matter what the measurement methodology, there is very
>>> little
>>>>>>>>> variability
>>>>>>>>> on the server side. It's built to do what it does, and it
>>> can't
>>>>>>>>> actually
>>>>>>>>> vary much. Having the client tell the server what it
>> wants
>>> is
>>>>>>>>> backwards:
>>>>>>>>> the server can't actually react; all it can do is do what
>> it
>>>>> does,
>>>>>>> and
>>>>>>>>> drop
>>>>>>>>> some kind of response when the timer expires. Actually,
>> in
>>>>> nearly
>>>>>>>> every
>>>>>>>>> case, it can predict what happens, but that doesn't help
>> the
>>>>> client
>>>>>>>> any.
>>>>>>>>> The client, if it really cares, could react to what the
>>> server
>>>>> can
>>>>>>> do,
>>>>>>>> a
>>>>>>>>> lot
>>>>>>>>> more usefully than having the server react to what the
>>> client is
>>>>>>>> asking
>>>>>>>>> for.
>>>>>>>>> If the server tells it that it has a startup problem, and
>>> will
>>>>> have
>>>>>>>>> accurate
>>>>>>>>> results in 30 seconds, the client could display some
>> useful
>>>>>>> feedback,
>>>>>>>> as
>>>>>>>>> an
>>>>>>>>> example.
>>>>>>>>>
>>>>>>>>> Finally, most measurement systems have a time/accuracy
>>> tradeoff,
>>>>>>>>> especially
>>>>>>>>> if the target is not moving. The longer you wait, the
>> more
>>>>> accurate
>>>>>>>> the
>>>>>>>>> measurement. If the measurement mechanism is triggered,
>> you
>>>>> restart
>>>>>>>> the
>>>>>>>>> time/accuracy clock. So, asking for a measurement with a
>>>>> timeout
>>>>>>>> would
>>>>>>>>> not
>>>>>>>>> allow you to use a triggered measurement with a
>>> time/accuracy
>>>>>>>> tradeoff.
>>>>>>>>> The
>>>>>>>>> client doesn't understand that if it either lengthened the
>>> time,
>>>>> or
>>>>>>>>> lengthened the time between requests, it would get more
>>>>> accuracy.
>>>>>>> If
>>>>>>>> we
>>>>>>>>> were trying to get both sides to do something optimal, the
>>>>> server
>>>>>>>> would
>>>>>>>>> tell
>>>>>>>>> the client that retriggering resets the time/accuracy
>>> tradeoff,
>>>>> and
>>>>>>> it
>>>>>>>>> would
>>>>>>>>> tell the client what the time/accuracy function looked
>> like.
>>>>>>>>> Let me also react to "web servers take seconds". Sure.
>> But
>>>>> there
>>>>>>> are
>>>>>>>>> humans involved. Protocol mechanisms that take seconds
>> are
>>> best
>>>>>>> done
>>>>>>>>> with
>>>>>>>>> event notification or call back mechanisms. If you don't
>> do
>>>>> that,
>>>>>>> you
>>>>>>>>> have
>>>>>>>>> to use threads or polling, or some other ugliness to not
>>> block
>>>>> on
>>>>>>> the
>>>>>>>>> exchange.
>>>>>>>>>
>>>>>>>>> Brian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
>>>>>>>>>> Sent: Saturday, July 21, 2007 12:40 PM
>>>>>>>>>> To: Brian Rosen; Stark, Barbara; Mary Barnes;
>>> geopriv@ietf.org
>>>>>>>>>> Subject: RE: [Geopriv] HELD comment on responseTime
>>> parameter
>>>>>>>>>> Hi Brian,
>>>>>>>>>>
>>>>>>>>>> I think the fact that you feel the need to quantify
>> "right
>>>>> away"
>>>>>>> and
>>>>>>>>>> "I'll wait" is revealing in itself. Of course "right
>> away"
>>>>>>> literally
>>>>>>>>>> means zero wait and "I'll wait" is any time up to
>>> infinity.
>>>>> The
>>>>>>>> values
>>>>>>>>>> you "prescribe" are based on your here/now understanding
>>> and
>>>>>>>>> presumption
>>>>>>>>>> of specific applications.
>>>>>>>>>>
>>>>>>>>>> Requesting location in a WCDMA UTRAN can involve
>> relating
>>> the
>>>>>>>> serving
>>>>>>>>>> cell directly to a nominal area of coverage (msec),
>>> putting
>>>>> the
>>>>>>>> device
>>>>>>>>>> into soft handoff to collect a set of round-trip time
>>>>> measurements
>>>>>>>>> from
>>>>>>>>>> in-range base stations (a few seconds), or doing A-GPS
>> (up
>>> to,
>>>>>>> say,
>>>>>>>> 30
>>>>>>>>>> seconds). Each places different demands on network
>>> resources.
>>>>>>>>>> The cell-based location may be adequate for accurate
>> PSAP
>>>>> routing
>>>>>>>> 67%
>>>>>>>>>> while RTT may be accurate 99.9% of time. Other
>>> applications
>>>>> will
>>>>>>>>>> similarly be sensitive to accuracy variations. Tolerance
>>> for
>>>>>>>> response
>>>>>>>>>> delays isn't something you can claim to be able to
>> predict
>>> for
>>>>> all
>>>>>>>>>> applications today and forever.
>>>>>>>>>>
>>>>>>>>>> It's no good saying that an application that asked for a
>>> four
>>>>>>> second
>>>>>>>>>> response might say "oh - if I'd known I could have had
>> the
>>>>> result
>>>>>>> in
>>>>>>>>>> five seconds, I'd have been OK to wait." If it is OK to
>>> wait
>>>>> five
>>>>>>>>>> seconds, then it should request a response time of at
>>> least
>>>>> five
>>>>>>>>>> seconds.
>>>>>>>>>>
>>>>>>>>>> As we've explained before, our experience has shown that
>>> the
>>>>>>>> Low-delay
>>>>>>>>>> or Delay-tolerant choices that the 3GPP protocols
>> provide
>>> have
>>>>>>> been
>>>>>>>>>> problematic. At least in that case there has been an
>>>>> accompanying
>>>>>>>>>> (scalar) accuracy requirement to go along with the QoS.
>>> The
>>>>> latter
>>>>>>>> has
>>>>>>>>>> at least facilitated some ability to arbitrate between
>>>>> location
>>>>>>>>>> techniques and order of fallback. With just a binary
>>> response
>>>>> time
>>>>>>>>>> requirement, it would be impossible to do any
>> arbitration.
>>>>>>>>>> If you assume you know everything now and force a binary
>>>>> choice
>>>>>>> into
>>>>>>>>> the
>>>>>>>>>> semantics, then you can't undo that if it's a mistake.
>> If
>>> the
>>>>>>>>> semantics
>>>>>>>>>> support a scalar response time and it turns out that
>>> 100msec
>>>>> and
>>>>>>>> 30sec
>>>>>>>>>> is all anyone ever needs then, at worst, that is what
>> ends
>>> up
>>>>>>> being
>>>>>>>>> put
>>>>>>>>>> in all the HELD requests.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Martin
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Brian Rosen [mailto:br@brianrosen.net]
>>>>>>>>>> Sent: Saturday, 21 July 2007 4:35 AM
>>>>>>>>>> To: 'Stark, Barbara'; 'Mary Barnes'; geopriv@ietf.org
>>>>>>>>>> Subject: RE: [Geopriv] HELD comment on responseTime
>>> parameter
>>>>>>>>>> Hehe
>>>>>>>>>>
>>>>>>>>>> As you know, I am in the binary "gimme what you got now,
>>> gotta
>>>>>>> route
>>>>>>>>>> this
>>>>>>>>>> call" or "I need a good location, I'll wait for it"
>> camp.
>>>>>>>>>> I have a really hard time coming up with a use case
>> where
>>> you
>>>>> have
>>>>>>> a
>>>>>>>>>> value,
>>>>>>>>>> and not knowing anything about what the other end can
>> do,
>>> I
>>>>> think
>>>>>>> a
>>>>>>>>>> value is
>>>>>>>>>> pretty useless.
>>>>>>>>>>
>>>>>>>>>> Please keep in mind that "right away" is order of
>>> milliseconds
>>>>> and
>>>>>>>>> "I'll
>>>>>>>>>> wait" can be 30 sec give or take for a typical assisted
>>> GPS
>>>>> start
>>>>>>>> up,
>>>>>>>>>> and a
>>>>>>>>>> couple of minutes for a cold start GPS. Right away is
>>>>> protocol
>>>>>>>>>> request/response territory. Anything that has tens of
>>> seconds
>>>>> or
>>>>>>>> more
>>>>>>>>>> in it
>>>>>>>>>> is an async event notification/call back kind of thing.
>>>>>>>>>>
>>>>>>>>>> Brian
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Stark, Barbara [mailto:bs7652@att.com]
>>>>>>>>>>> Sent: Friday, July 20, 2007 2:25 PM
>>>>>>>>>>> To: Mary Barnes; geopriv@ietf.org
>>>>>>>>>>> Subject: [Geopriv] HELD comment on responseTime
>>> parameter
>>>>>>>>>>> I'm probably opening a can of worms with this comment,
>>> but
>>>>> I'll
>>>>>>>> make
>>>>>>>>>> it
>>>>>>>>>>> anyway...
>>>>>>>>>>>
>>>>>>>>>>> There have been discussions elsewhere as to whether
>> it's
>>>>> really
>>>>>>>>>>> useful/meaningful to specify a desired response time,
>> or
>>>>> whether
>>>>>>>>> it's
>>>>>>>>>>> better to specify that the response is needed right
>> away
>>>>>>>> (presumably
>>>>>>>>>> for
>>>>>>>>>>> routing purposes) or the device can wait a little to
>> get
>>> a
>>>>> more
>>>>>>>>>> precise
>>>>>>>>>>> location.
>>>>>>>>>>>
>>>>>>>>>>> Should we have that conversation here, about this
>>> parameter?
>>>>>>>>>>> Barbara
>>>>>>>>>>>
>>>>>>>>>>> *****
>>>>>>>>>>>
>>>>>>>>>>> The information transmitted is intended only for the
>>> person
>>>>> or
>>>>>>>>> entity
>>>>>>>>>> to
>>>>>>>>>>> which it is addressed and may contain confidential,
>>>>> proprietary,
>>>>>>>>>> and/or
>>>>>>>>>>> privileged material. Any review, retransmission,
>>>>> dissemination
>>>>>>> or
>>>>>>>>>> other
>>>>>>>>>>> use of, or taking of any action in reliance upon this
>>>>>>> information
>>>>>>>> by
>>>>>>>>>>> persons or entities other than the intended recipient
>> is
>>>>>>>> prohibited.
>>>>>>>>>> If
>>>>>>>>>>> you received this in error, please contact the sender
>>> and
>>>>> delete
>>>>>>>> the
>>>>>>>>>>> material from all computers. GA623
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Geopriv mailing list
>>>>>>>>>>> Geopriv@ietf.org
>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/geopriv
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Geopriv mailing list
>>>>>>>>>> Geopriv@ietf.org
>>>>>>>>>> https://www1.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]
>>>>>>>>>
>>>>>>>>>
>> ------------------------------------------------------------------------
>>>>>>>> --
>>>>>>>>> ----------------------
>>>>>>>>> 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]
>>>>>>>
>>>>>>>
>> ------------------------------------------------------------------------
>>>>>> --
>>>>>>> ----------------------
>>>>>>> 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://www1.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://www1.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]
>>>
>>>
>>
>> ------------------------------------------------------------------------------------------------
>>
>> 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://www1.ietf.org/mailman/listinfo/geopriv
>>
>>
>
>
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Mon, 30 Jul 2007 12:22:25 +0200

This archive was generated by hypermail 2.1.8 : Mon Jul 30 2007 - 06:22:46 EDT