RE: [Geopriv] Resolving a design philosophy tension

From: Winterbottom, James ^lt;James.Winterbottom@andrew.com>
Date: Tue Aug 14 2007 - 17:40:53 EDT

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 > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Wednesday, 15 August 2007 7:02 AM > To: Winterbottom, James; geopriv@ietf.org > 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: > > 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 > > At 3:41 PM -0500 8/14/07, Winterbottom, James wrote: > >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 > > > > > > > > > > > > > >> -----Original Message----- > >> From: Ted Hardie [mailto:hardie@qualcomm.com] > >> Sent: Wednesday, 15 August 2007 2:53 AM > >> To: geopriv@ietf.org > >> Subject: [Geopriv] Resolving a design philosophy tension > >> > >> 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 > >> 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
Received on Tue, 14 Aug 2007 16:40:53 -0500

This archive was generated by hypermail 2.1.8 : Tue Aug 14 2007 - 17:42:47 EDT