Subject: [Geopriv] Resolving a design philosophy tension

From: Ted Hardie <[email-masked]>
Date: Tue, 14 Aug 2007 09:52:47 -0700

I think there is an underlying tension here on how to do protocol
design.  Let's call the two design philosophies "best fit" and 
"best basis".  The "best fit" design philosophy starts when you have
a very particular application in mind, and you tailor the protocol
to be the best fit to that protocol.  Any bells, whistles, or application
UI aspects that are present in the application should be reflected
in the protocol, so that all of the parties to the application (Client
and server, peers, multicast groups, what have you) all share
an exact knowledge of the application's state. 

The "best basis" design philosophy says that you build a protocol
so that it can serve as a basis for many different applications, each
of which may have different bells, whistles, or application UIs.
Rather than starting from the application and heading down, in
other words, you start from the primitives from what you to believe
to be a class of applications, and put those in.  Those primitives
get implemented by everyone who uses the protocol, for whatever
application.  Any aspects which are specific to a single application
get implemented as extensions.  There's always a tension in this
design philosophy over which bits are true primitives and which
are good candidate extensions.  Since adopting things which ought
to be extensions into the core protocol pushes the development
burden onto everyone, it's a big question.  It's even more of a
question when a particular aspect may have big design implications
for implementation and deployment.

Many protocol efforts are a blend of these two approaches;
there are few that are really completely one or the other.  Most
"best basis" protocol efforts are driven by use cases, and most "best fit"
protocol efforts recognize that there will be some change in the
application over time.  But the tension between these approaches is
real, and I believe it is one of the underlying tensions in this group.

So, we can stop everything and have a giant meta discussion on which
design philosophy is dominant in this effort, maybe fix up the charter
so that it reflects that (it's way out of date anyway), and engage in
whatever crystal ball efforts it takes to see where this work will be
taken as it moves out of the working group and into the world.  Or,
we can try to talk in each others languages as be we can.

Trying my own hand at interpretation, I hear a "best fit" statement
like this:  "My application has a specific need for expressing a client timeout, 
which is used by the server to pick a level of accuracy which can be returned."
I hear a "best basis" response of "There are two primitives there:  `desired
accuracy' and `time a client will wait'.  Why are they tied together? Wouldn't
the usefulness/generality of the protocol be better if they were not?"
The replies to that have been in application/use-case specific terms, but
I hear the response essentially as "The application context ties them together,
as the lack of response at a specific time triggers the use of a different mechanism
(e.g. default routing to a PSAP, in the emergency use case)".  I believe
everyone accepts that to be true for that specific application, but that there
is a further concern that this will force *all* deployments to create similar
application contexts that tie  the two primitives into a single expression.

The proposed compromise, which makes this a core part of the protocol
(not an extension), but optional, papers over the issue.  If this were the
end of the design discussion, I would say paper it over and be done.  But
I am concerned that this design tension will continue to be a problem.  I'd ask
each person who has been involved in *this* discussion to strongly consider
how to express this problem and any proposed resolution in terms of both
design philosophies. I suspect this will be good practice for later.

To wind down this long-winded statement with full disclosure:  I tend to
fall on the "best basis" side of protocol design, as I have seen a lot of 
protocol re-use in my time.  Making things re-usable early tends to avoid
a lot of pain later, and it means getting primitives right is worthwhile.
On this particular issue, I do see two primitives:  desired accuracy and
client wait time.  Having one expressed without the other does imply a default
(Give me the location ($DEFAULT="best available) within 20 seconds) and
(Give me 1m accuracy within ($DEFAULT="forever" ), and those defaults
may look silly in particular application contexts.  But that does not mean
they are not useful primitives in any context, and they clearly are
separable.

If we do go the route of separating them, rather than papering this over,
then we have to do some real work in describing how to relate the two.
I think that discussion would be a lot more valuable than the one we
have been having, and I hope others agree.
				regards,
					Ted Hardie  

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 14 Aug 2007 13:55:13 -0400

I think "best basis" is most appropriate for this protocol.

I proposed a very generalized mechanism that gives the client the exact
capability the server can deliver.  It designed to have a default which
everyone implemented: the binary fast/accurate parameter, with an extension
that provided the client with the server capabilities so that the client
could intelligently pick one.

When you have two separate scalers for time and accuracy, you miss the point
that there are multiple mechanisms and EACH MECHANISM can have a
time/accuracy tradeoff.  

I think the problem we are having is that the Andrew folks think that the
client has the model that drives the protocol and the server should adapt to
the needs of the client.  I think that the server is the one with the real
constraints and the client should adapt to the capability of the server.
I don't think clients have hard rules.  I think they have a "it depends"
view of the time/accuracy tradeoff.

I think that when you have a fairly big issue like this, we're better off
just telling the client what the server can actually do, and let the client
deal with it.  There is no comparable way for us to tell the server what the
client can do and let the server deal with it.  The client doesn't have
actual constraints.

Brian

> -----Original Message-----
> From: Ted Hardie [mailto:[email-masked]]
> Sent: Tuesday, August 14, 2007 12:53 PM
> To: [email-masked]
> Subject: [Geopriv] Resolving a design philosophy tension
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 14 Aug 2007 15:41:16 -0500

Hi Ted,

It is not clear to me why best available is any more "basic" than I can
only wait 5 seconds. Best available is still an application definition,
it makes no sense outside of an application context (the fact that it
has a timeout as defined below is proof of the need for a response
time). So if you want an absolute bare-bones basic then should not
support anything other than ASAP.

Personally I think this is silly, as we know that this will not be
satisfactory for anything that is not tied to a desk. Just looking at
one application, the last time I checked, more calls in the US were
generated from mobile devices than wireline devices, for which the
"basic" functionality described would be unsatisfactory and regress from
existing BCP. I find a proposal suggesting this as the preferred course
unsatisfactory.

I totally object to the notion of enumerations being provided for ASAP
and AGAP. Experience with using enumerations like this in wireless has
shown this.

The only arguments that I have heard against the responseTime start with
statements like "I can't imagine...".  I think that that is also perhaps
the summary. 

I believe that "best basis" includes the responseTime as it allows
location acquisition BCP in environments, other than the
tethered-desktop, to be at least maintained. That is, I subscribe to the
premise of no-worse than current solutions, the proposed binary approach
below does not fit this requirement no matter how brightly it is
painted.

Cheers
James

> Sent: Wednesday, 15 August 2007 2:53 AM
> To: [email-masked]
> like this:  "My application has a specific need for expressing a
client
> timeout,
> as the lack of response at a specific time triggers the use of a
different
> mechanism
> everyone accepts that to be true for that specific application, but
that
> there

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

---

From: Ted Hardie <[email-masked]>
Date: Tue, 14 Aug 2007 14:02:20 -0700

James,
	You seem to me to be starting from a specific application:
making a phone call for which location-based routing is desirable.
HELD, as it is currently described, could be far more general purpose.
Try to look at the abstract as if you were reading it for the first time:

   A Layer 7 Location Configuration Protocol (L7 LCP) is described that
   is used for retrieving location information from a server within an
   access network.  The protocol includes options for retrieving
   location information either by-value or by-reference.  The protocol
   supports mobile and nomadic devices through Location URIs.  The
   protocol is an application-layer protocol that is independent of
   session-layer; an HTTP, web services binding is specified.

That could be used in a host of application context where location-related
services are desired.  Not all of those have UIs or users, and not all of those
have the constraints of location-based routing in a phone call.

I was hoping we could step back and look at the design process a bit.  Are
we designing just for one application?  Or are we expecting this to get
re-used in multiple contexts by a variety of systems?  I don't want us
wrapped around the axle of a meta-discussion, but I was hoping that
question would prompt folks to step back up level.  I hope that will
lead us to the conclusion that the elements of what you want might be
needed in lots of places, and that the relationship of those elements might
be different in different application contexts.  If we can resolve our
design tension at least that much, in other words, we might be able
to make progress without quite so much treading over the same ground
at each design decision.

Does that make sense to you at all?
				Ted

---

From: "Stuard, Doug" <[email-masked]>
Date: Tue, 14 Aug 2007 17:36:06 -0400

As I read Ted's post concerning "best basis" and "best fit" I was
thinking "but most cases are a blend of the two!" ... and then Ted said
essentially the same thing.  I disagree with Brian in that I think the
client absolutely should define its requirements, while the server
determines the appropriate response (rather than forcing the client
choose from a laundry list).  It is not necessary (nor desirable) for
the client to understand the server's technology selection process
(which indeed can be quite complex, often involving time and situation
dependencies as well as initial coarse location).

While my carefully crafted comments have perhaps been somewhat taken
over by events, I'll offer them here for what they're worth...

The client knows his application and hence the associated the time
and/or accuracy constraints.  The server knows what positioning
technologies are available in at a given time in a given area and their
associated accuracy/time characteristics, and is thus in the best
position to make the decision as to which technology (or technologies)
to invoke given the constraints imposed by the client.  It is not up to
the client to educate the server on the nuances of its application,
likewise it is not up to the server to educate the client on the
subtleties of time /accuracy tradeoffs and available location
technologies. 
 
While there is at least tacit agreement that at least a two-tiered
approach is called for, I think we need to be more flexible than that.
What seems to be the issue is how what requirements are specified and by
which entity.

CALL ROUTING:  This is the "give me the best you've got, but give it to
me fast" scenario, and is driven primarily by the emergency use case,
but, as Martin pointed out, is applicable to a number of commercial
location-based routing applications as well.
  
The decision as to how fast is required is up to the client, and it is
the client that is best able to determine if the returned
location/accuracy is sufficient for his needs.  For its part, the server
is obligated to return something within the specified time limit, even
if at a gross level of accuracy (the estimate of which should be part of
the response), and it is the server that is best able to make the
decision as to what the best method to do that is.

The key element in determining permissible wait time for call routing is
allowable call setup time/post-dial delay (ultimately, human factors
related).  This is the driving force behind the "quick-fix" option
available in some wireless location systems, where a window in the order
of 3-5 seconds is typical (note that in practical implementations, a
quick fix is only judged to be useful/valid if its associated
uncertainty is less than would be expected for cell/sector or other
default response).  (BTW, I would hazard to guess that the quoted 30%
misroute figure quoted is based on cell/sector based routing, where
there is an inherent high degree of inaccuracy associated with sector
coverage areas as they relate to PSAP boundaries.  If Quick-Fix (with a
max uncertainty limit) were in use, I would expect misroutes to be
reduced significantly).

ACCURACY:  While some have argued that time is not a factor, practical
implementations dictate that it is.  Few applications would be willing
to wait 30 minutes for the "best available" location estimate unless it
first had a useable estimate prior to that.  While this implies an
accuracy target, an upper limit on time is still an element.

Going back to the above example, if after receiving the response from
the server, the client needs still better data, he can issue a follow-on
request with a longer window (if it is still time-sensitive, given that
he already has a preliminary estimate), or if absolute accuracy is
required, he could specify an open-ended accuracy requirement and wait
until the cows come home or he gives up.

RECOMMENDATION: What this boils down to (and what I believe Ted was also
saying) is to include both an (optional) time parameter specifying the
maximum time permitted for a response, as well as an (also optional)
desired accuracy parameter.  In combination these provide the
flexibility inherent in the "best basis" approach, while not burdening
systems and applications with various "best fit" detritus for which
these elements are not required.

The inclusion of accuracy and/or time parameters in a client request
would then result in the following response types:

1)	No stated requirement - Best achievable accuracy, no time limit
(Open ended - Response provided at convergence or on receipt of "that's
enough!" command). 
2)	Time limit only - Best achievable accuracy within specified time
limit. 
3)	Accuracy requirement only - Provide response when specified
accuracy reached, no time limit.
4)	Both time and accuracy - Provide response when specified
accuracy is reached or time limit expires, whichever comes first.
 
In all cases, an accuracy estimate should be included in the response.
This will allow the client to decide if further requests are necessary
based on the situation/application. 

In implementation, case 4 would be "first on wins".  You either achieve
your required accuracy within the time limit specified in the client
request, or you take the best that the server can provide when the clock
runs out.  If you then need additional time, you can re-issue the
request, either without the time parameter or with a longer time window.

Case 1 (and perhaps 3) is the equivalent of the "Accuracy" case, while
case 2 (with an arbitrarily short time value)is the "ASAP" case.  In
today's wireless E9-1-1 implementations, cases 2 and 4 are most
prevalent. You need the ability to specify time and/or accuracy
requirements. Trying to force all cases into either an "ASAP" or a
"AGAP" model is IMHO a glass slipper that just won't fit. 

Doug

_____________________________________________

> Subject: [Geopriv] Resolving a design philosophy tension
<<snip>>
> there are few that are really completely one or the other.  

<<snip>>

> they are not useful primitives in any context, and they clearly are

_____________________________________________ 

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Tuesday, August 14, 2007 1:55 PM
> To: 'Ted Hardie'; [email-masked]
> Subject: RE: [Geopriv] Resolving a design philosophy tension
> 
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 14 Aug 2007 16:40:53 -0500

Hi Ted,

I agree with almost everything you placed in this most recent email.
Your previous email proposed a binary mechanism for response time
something that I cannot agree to. So if the stepping back is going to
result in that proposal being the final solution, preconceived or
otherwise, then I see little point in progressing down a road that will
necessitate back-tracking.

If you agree that we want to use/re-use HELD in a wide range of location
applications it seems to me that we should not unnecessarily restrict
them ahead of time without having a solid fundamental reason for doing
so. I don't believe that the ability of some people in this forum to
"imagine an application making use of such a mechanism" meets the
fundamental reason criteria.

Ted, how do you see we proceed from here?

Cheers
James

> Sent: Wednesday, 15 August 2007 7:02 AM
> To: Winterbottom, James; [email-masked]
> services are desired.  Not all of those have UIs or users, and not all
of
> those
> >> "best basis" protocol efforts are driven by use cases, and most
"best
> >fit"
> >> which is used by the server to pick a level of accuracy which can
be
> >> returned."
> >> accuracy' and `time a client will wait'.  Why are they tied
together?
> >> Wouldn't
> >> The replies to that have been in application/use-case specific
terms,
> >but
> >> I hear the response essentially as "The application context ties
them
> >> together,
> >> is a further concern that this will force *all* deployments to
create
> >> similar
> >> (not an extension), but optional, papers over the issue.  If this
were
> >the
> >> end of the design discussion, I would say paper it over and be
done.
> >But
> >> I am concerned that this design tension will continue to be a
problem.
> >> I'd ask
> >> To wind down this long-winded statement with full disclosure:  I
tend
> >to
> >> fall on the "best basis" side of protocol design, as I have seen a
lot
> >of
> >> On this particular issue, I do see two primitives:  desired
accuracy
> >and
> >> client wait time.  Having one expressed without the other does
imply a
> >> default
> >> may look silly in particular application contexts.  But that does
not
> >mean
>-----------------------------------------------------------------------
--
> -----------------------
>-----------------------------------------------------------------------
--
> -----------------------

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 14 Aug 2007 18:41:49 -0400

I started writing a direct reply to Ted's latest, but this came in first, so
I'll take off from here.

I think that in order to deal with this reasonably, we're going to have to
have a bunch of use cases.  I think dealing with abstract applications are
getting us confused.  It's not enough to use the "best fit"/"best basis", we
need to figure out much more thoroughly what we need.  If we agree on a set
of use cases, we can compare mechanisms to the use cases.

Here are the ones I think we ought to build the mechanisms around:
1. Emergency call.  This is pretty well known.  The parameters are actually
fixed, there is no client variability, but the client would need to tell the
server it was an emergency call if we actually leave it fixed

2. Non emergency location based call.  This is like an emergency call in
nearly every respect except that the timing isn't really fixed.  It could be
exactly the same if it made sense.  Nearly all the cases have exactly the
same needs: a quick non-very-accurate location for call routing, and an
accurate location for dispatch.  It's the same for Pizza Hut as it is for a
PSAP.

3. Navigation/Tracking.  This is a continuous update.  It's not at all clear
if this is a good HELD application.  The cold start doesn't matter.

4. Some kind of one shot "I am here" thing, more or less what the geo-tag in
HTML is aimed at.  You might get some kind of personalized-to-location
content.  This is a human reaction time thing, but pretty short trigger; you
wouldn't, for example, wait 2 seconds for this.  The accuracy requirement is
hard to state, and may depend on exactly what is being personalized.
Interestingly, if you used HELD to get location, and something like the
geo-tag to give it to a web server, then the HELD client doesn't know what
it's being used for.  In this case, the client is clueless.

5. A subscription mechanism.  Think of a tornado alert, but for where your
daughter is instead of where you are.  You want what LoST gives you: a URI
to subscribe to, and a polygon representing the boundary where the URI is
still good.  This is tracking, but you have a start up.  I suspect the cold
start doesn't matter; wait a minute or 3 and the app still works.  It's not
the same as 4) above because the subscription, which is the initial location
isn't tied to user reaction time.

That's my initial list.  Let's get some more before we analyze.  Need apps
with different characteristics with respect to time/accuracy than these.

Brian

> From: Stuard, Doug [mailto:[email-masked]]
> Sent: Tuesday, August 14, 2007 5:36 PM
> To: Brian Rosen; Ted Hardie; [email-masked]

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 14 Aug 2007 18:28:36 -0500

Brian,

How do arrive at proposal for number 4?
This is more handwaving than I have seen in any proposal given thus far.
I see a "where am I down town app" being very useful. It certainly needs
better location than ASAP, and does not require AGAP in almost all
cases.
This application gets the location of the device in 2 to 5 second, then
renders that location on to a city map for the user to look at.

Alternatively, the user fires the provided location to a webapp, and
gets back a map of the local services they are interested in. I would
certainly wait 2-5 seconds for location in this situation also, and
possibly the same time again to render it.

Both of these services need better that a 10km radius of serving cell,
but may work fine with a 50m to 500m location determination technique
that is not AGAP. I can add to that that I would have paid for and used
such a service in Prague, and probably would in other places too.

We are talking about how to address these things in HELD, discussing
continuous tracking applications and subscription services is unhelpful
since I think we have all agreed, more than once, that there are more
efficient ways to do subscription and tracking. That is not to say that
these applications are not important, they are just not relevant to this
discussion now.

I would prefer not to include application service-type in the location
request for several reasons. Firstly I don't believe that there is a
finite set of service types, and when you do this you compartmentalize
applications which may not fit well in any of the "pre-configured"
services agreed to. Secondly, you need a service qualifier and some
other qualifier, which simply adds more complexity that can be achieved
with only one parameter, time.

Before we arrived at this proposal in HELD we spent a lot of time
looking at what current implementations did, and essentially what ended
up being default behaviour. Servers don't know what applications are
going to be deployed in their networks, and clients don't need to know
what determination techniques are available, if the application can
qualify its request no other negotiation is required. Since something is
better than nothing, the lowest common denominator for negotiation is
time.

Regards
James

> Sent: Wednesday, 15 August 2007 8:42 AM
> To: Stuard, Doug; 'Ted Hardie'; [email-masked]
> I started writing a direct reply to Ted's latest, but this came in
first,
> so
> getting us confused.  It's not enough to use the "best fit"/"best
basis",
> we
> need to figure out much more thoroughly what we need.  If we agree on
a
> set
> fixed, there is no client variability, but the client would need to
tell
> nearly every respect except that the timing isn't really fixed.  It
could
> accurate location for dispatch.  It's the same for Pizza Hut as it is
for
> a
> 4. Some kind of one shot "I am here" thing, more or less what the
geo-tag
> in
> content.  This is a human reaction time thing, but pretty short
trigger;
> you
> wouldn't, for example, wait 2 seconds for this.  The accuracy
requirement
> is
> start doesn't matter; wait a minute or 3 and the app still works.
It's
accuracy
imply a
> > > default
> > > (Give me the location ($DEFAULT="best available) within 20
seconds)
not
> > > I think the problem we are having is that the Andrew folks think
that
> > > the
> > > client has the model that drives the protocol and the server
should
> > > adapt to
> > > the needs of the client.  I think that the server is the one with
the
> > > real
------------------------------------------------------------------------
> > ----------------------
------------------------------------------------------------------------
> > ----------------------

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 14 Aug 2007 19:01:53 -0500

Hi Ted,

I have not been focussed on any particular application with respect to
proposals around a response time parameter. Actually, if I was focussed
on one specific application, I'd probably agree with the binary
parameter proposal.

I consider the scalar response time parameter to be best-basis as
opposed to best-fit precisely because it doesn't assume that there can
be a common understanding of what "ASAP" means. The binary parameter
makes assumptions about the relationship between the client and the
server to the extent that it assumes that both know what finite time
actually qualifies as "soon". Brian actually felt it necessary to
prescribe scalar values that equate to "soon" - and this is, hands down,
based on a best-fit presumption.

Now - the best-basis approach would also suggest that an "accuracy"
parameter is also a good idea. I have not been vocal about having such a
parameter but that has not been because of a "best-fit" application
perspective. Whether it is for emergency calling, friend-finders, fleet
tracking, or local information (nearest ATM) type services, the
experience has been that all of these services will take whatever
accuracy can be provided within their time constraint. Our mobile
location center product has a "strict QoS" switch. Since the protocols
don't support the semantics for a client to say - "here's an accuracy
target, but give me whatever accuracy you can achieve within my request
time limit", we have had to provide the switch that allows the location
server operator to provide this default behaviour. If the switch is
turned on, the protocol semantics are strictly honoured - a result is
only provided if the accuracy target is met. Our experience: "strict
QoS" is always turned off. So I'd have to say my view on the "accuracy"
parameter is based on empirical experience and not a strictly best-fit
approach. As I've said, though, if somebody felt that an accuracy
parameter is a good idea, then I'd not stonewall them. I would have an
opinion on what the default semantics should be however.

The "laundry list" mechanism that Brian proposed is another story
altogether. If it's "best-basis", it's on the presumption that the
client can actually make any kind of sensible decision on what location
technology to deploy. To test the proposition, I'd request that the
following location technologies be listed per the suggested scheme:

* cell-based location
* RTT multilateration
* Radio camera
* UTDOA

Fact is that there is no strict ordering of accuracy for these
technologies. Life simply isn't that simple. The process of obtaining
optimal accuracy in a given time-frame is a dynamic one. Some methods
provide asymptotically increasing accuracy as the integration/sampling
period extends. Where the asymptote lies depends on factors that vary
from request to request. When the sampling period and number of
iterations of an algorithm should cease is not an absolute - it needs to
be gated by some other constraint like how long it should go on.
Further, the location server needs to make decisions on which technology
to invoke, and for how long, based on internal considerations such as
resource availability (such as LMU channel measurement functions - how
much DSP capacity is available at this instant). This is not something
it can sign up to on a contractual basis with individual clients.

If the laundry list is "best-fit" then I'd argue that it's based on a
bad premise. I don't think the device wants to know about internal LIS
capabilities. I think the "best-fit" approach is for the client to
communicate in terms which are natural to it - response time and
accuracy.

Cheers,
Martin

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Wednesday, 15 August 2007 7:02 AM
To: Winterbottom, James; [email-masked]
Subject: RE: [Geopriv] Resolving a design philosophy tension

James,
	You seem to me to be starting from a specific application:
making a phone call for which location-based routing is desirable.
HELD, as it is currently described, could be far more general purpose.
Try to look at the abstract as if you were reading it for the first
time:

That could be used in a host of application context where
location-related
services are desired.  Not all of those have UIs or users, and not all
of those
have the constraints of location-based routing in a phone call.

I was hoping we could step back and look at the design process a bit.
Are
needed in lots of places, and that the relationship of those elements
might

were
problem.
lot
>> client wait time.  Having one expressed without the other does imply
a
>> have been having, and I hope others agree.
-------------------------
>this email is prohibited.
-------------------------

---

From: Ted Hardie <[email-masked]>
Date: Tue, 14 Aug 2007 21:30:58 -0700

>Ted, how do you see we proceed from here?

For the current issue, I believe the best way forward is to provide an optional
parameter for time the client is willing to wait, an optional parameter for accuracy
that the client desires, and to do the actual work of working how to relate the two.

I understand the points made by Doug and Martin in saying that accuracy
has always in their experience implied an upper bound.  That doesn't
worry me much, since it will be entirely possible to express such an
upper bound with both available, and when an application arises
that doesn't want such a bound it will have the protocol mechanisms
available to make it work. 

On the bigger point, I remain worried by the amount of talking past each other
we're able to do here, but I hope that Brian and Martin's agreement
that they both are aiming for "best basis" will help.  If we can easily
build a broader agreement to that effect, then I think we have some
hope of eventually resolving the design conflict in favor of a useful
middle ground ("best basis with benefits?") .  But there has to be a
willingness to examine our own assumptions and language here.
Reading through the past two thousand lines of fresh text sent to this
mailing list indicates to me we've got a ways to go.

				regards,
					Ted