RE: [Geopriv] Response time use cases (was: HELD comment onresponseTime parameter)

From: Brian Rosen ^lt;br@brianrosen.net>
Date: Tue Aug 07 2007 - 20:11:42 EDT

In your example, is the seven seconds a cold start time: you open your
laptop in a new location, and you will wait 7 seconds to avoid typing your
location manually? If it is, then you have somewhat of a use case. The 7
seconds will actually be useful for a "quick fix" kind of location measuring
system. On the other hand, what accuracy do you need?

Actually the biggest part of the problem is that we all understand there is
a speed/accuracy tradeoff, but somehow the proponents only want to talk
about speed. I think there are many more use cases for a specified accuracy
than a specified response time.

If 300 meters or so of accuracy is enough, then a quick fix might work. If
you need to know an accurate civic location (street address), it won't work.

I think the Boolean is a good start. I think 99% of applications will find
it acceptable. I think we'll need an accuracy parameter before we need a
time parameter.

OTOH, I won't go to the mat on it. If we need to compromise, I'll
compromise. It's not that important; it's just, in my opinion, useless.

Brian

> -----Original Message-----
> From: Lisa Dusseault [mailto:lisa@osafoundation.org]
> Sent: Tuesday, August 07, 2007 7:55 PM
> To: Mary Barnes
> Cc: geopriv@ietf.org; Dawson, Martin; Henning Schulzrinne
> Subject: [Geopriv] Response time use cases (was: HELD comment
> onresponseTime parameter)
>
> For what it's worth, I get the end-user use cases now, although I
> don't always understand the back-end architecture as it affects the
> information available and at what time delay, and I don't yet see
> how the use cases dictate one particular architecture.
>
> Here's my own use case variation that is neither "ASAP" or "AGAP":
> - Twitter users could have a location publishing and friend finding
> application, usually to be used on a mobile device, which may be a
> laptop, which may sometimes be connected to a physical network but
> sometimes be 802.11 and sometimes cell. Ideally this application
> would get a civic location because "nearby" is different when you're
> in Northern Ontario or driving down a highway than when you're in
> downtown San Francisco on foot. Coordinate location could be a
> fallback.
> - For this application, when running as an unattended location
> publishing process, no timeouts are needed. However when the user
> wants to do something active and the location is not yet known, users
> are willing to spend an average of seven seconds of wait time in
> order to avoid typing in a location manually. For times above seven
> seconds, the application should just let the user type in a location.
>
> This use case, like many others, could be handled a number of ways.
> 1. The application to set its limit to "infinite" or "7s" depending
> on context, and send that limit in the location request to the
> server, aka the main proposal geopriv is considering
> 2. This particular use case could be handled by asking for a civic
> location and drop the connection (or at least changing the UI to
> prompt text entry) if a time limit is reached. If the civic location
> doesn't return within a few seconds the client could send a second
> request for geo, and the geo request could also be dropped.
> 3. The client could ask the server what location information it has
> available and at what expected time delays in one request-- like
> asking for an index-- then in a second request ask for one of those
> location responses. If all the times are too long, the client goes
> straight to text entry without even waiting seven seconds.
> 4. Hybrids of the above solutions...
>
> I'm sure there's more approaches, and I can't see how we could gather
> use cases in sufficient detail to really dictate a choice of approach
> since this is standards work, not a spec for one particular
> application. I'm not sure further discussion on use cases is going
> to sway technical choices though it may sway consensus on whether to
> address the response time problem.
>
> The question of what is easiest to do in HTTP, and what works best
> with proxies and other intermediaries, is somewhat more conducive to
> an answer, although the answer still varies depending on whether you
> have more or less control over the client or the server code bases.
>
> The question of whether we have a consensus to address any response
> time use cases at all, or the question of what approach we have a
> consensus to use assuming the first consensus, is even more conducive
> to an answer, that is if we're ready to try to find that consensus.
>
> Lisa
>
>
> On Aug 7, 2007, at 4:02 PM, Mary Barnes wrote:
>
> > We didn't reach consensus at IETF-69, per the minutes and the
> > discussion
> > captured in the Jabber log (at the end):
> > http://www3.ietf.org/meetings/ietf-logs/geopriv/2007-07-25.html
> > There were certainly folks that were okay with the compromise, but the
> > APP area advisor mentioned that the responseTime wasn't compatible
> > with
> > HTTP architecture and she wanted more use cases. And, the discussion
> > that has continued on the list since IETF-69 also doesn't seem to
> > indicate consensus had been reached (i.e., I didn't see the opponents
> > backing down and agreeing to the compromise). I'm still struggling
> > myself to understand the use cases provided, as like others, I
> > can't see
> > how the client can know what time is acceptable. I understand that
> > there are locations that take varying amounts of time to gather and
> > that
> > a client might have a particular preference for a more accurate
> > location
> > depending upon the situation. That all said, I don't object to the
> > current specification of the responseTime in the document, as it is
> > optional and quite loosely specified, for example:
> > "The value of this attribute is indicative
> > only, the LCS is under no obligation to strictly adhere to the time
> > limit implied; any enforcement of the time limit is left to the
> > requesting Device."
> > and:
> > "The LCS MUST provide the most accurate LI that can be determined
> > within the specified interval. This parameter could be used as
> > input
> > when selecting the method of location determination, where multiple
> > such methods exist."
> > So, in the end, I can't see that it will do harm, but the concept of
> > time does seem arbitrary given the objective (to be able to get a
> > location with a certain level of accuracy).
> >
> > Mary
> >
> > -----Original Message-----
> > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
> > Sent: Tuesday, August 07, 2007 2:14 PM
> > To: Richard Barnes; Henning Schulzrinne
> > Cc: geopriv@ietf.org; Dawson, Martin; Barnes, Mary (RICH2:AR00)
> > Subject: RE: [Geopriv] HELD comment on responseTime parameter
> >
> >
> > This is what I believed that the consensus was also.
> >
> >
> >> -----Original Message-----
> >> From: Richard Barnes [mailto:rbarnes@bbn.com]
> >> Sent: Tuesday, 7 August 2007 10:24 PM
> >> To: Henning Schulzrinne
> >> Cc: geopriv@ietf.org; Dawson, Martin; Mary Barnes
> >> Subject: Re: [Geopriv] HELD comment on responseTime parameter
> >>
> >> I thought that there was some agreement on the compromise proposal to
> >> keep the responseTime parameter, but make it optional and make the
> >> default to return ASAP. Do people have disagreements with that?
> >>
> >> --Richard
> >>
> >>
> >>
> >>
> >> Henning Schulzrinne wrote:
> >>> As I stated before, the basic IETF protocol design rule is that
> > adding
> >>> features requires rough consensus. I don't see such rough consensus
> >> here.
> >>>
> >>> On Aug 7, 2007, at 4:37 AM, Dawson, Martin wrote:
> >>>
> >>>> I'm hoping that the silence might mean that people are feeling more
> >>>> sympathetic to supporting this parameter - with the agreed default
> >>>> semantics.
> >>>>
> >>>> Am I overly optimistic?
> >>>>
> >>>> Cheers,
> >>>> Martin
> >>>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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]
> >
> >
> >
> > _______________________________________________
> > 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 Tue, 7 Aug 2007 20:11:42 -0400

This archive was generated by hypermail 2.1.8 : Tue Aug 07 2007 - 20:13:40 EDT