RE: [Geopriv] HELD comment on responseTime parameter

From: Winterbottom, James ^lt;>
Date: Fri Aug 17 2007 - 17:52:02 EDT

Thanks Carl, I could not agree with you more. From one location application deployer to another experience speaks volumes. Cheers James > -----Original Message----- > From: Carl Reed OGC Account [] > Sent: Saturday, 18 August 2007 1:17 AM > To: Stark, Barbara; Cullen Jennings; Dawson, Martin > Cc: GEOPRIV > Subject: Re: [Geopriv] HELD comment on responseTime parameter > > As HELD appears (to me anyway) to be application independent, and given > that > there is strong dialogue for/against/ambivalent for the parameter, I would > suggest that you make responseTime optional. Guaranteed that if you do not > include this parameter, then one or more developers will ask for this > parameter in a very short period of time. Even more so as the LG could be > any sort of location enabled sensor, any mobile device whose location can > be > determined by triangulation, GPS etc, and so forth. From my geo > perspective, > the LG does not have to be part of the communications network or > infrastructure. > > FYI, we learned the hard way regarding time in the development of GeoRSS: > The initial version of GeoRSS had geometry (GML) and feature description > but > no time. The first enhancement requested was for temporal elements. > > Regards > > Carl > > > ----- Original Message ----- > From: "Stark, Barbara" <> > To: "Cullen Jennings" <>; "Dawson, Martin" > <> > Cc: "GEOPRIV" <> > Sent: Wednesday, August 15, 2007 10:59 AM > Subject: RE: [Geopriv] HELD comment on responseTime parameter > > > > So long as I can have really simple rules for emergency call > > applications, I'm happy. I want to be able to have really simple rules > > for devices and for the LIS. I regret to admit, the devices and network > > elements I specify don't tend to do a lot of "thinking" and don't really > > "know" much, outside of what I tell them. And since I don't know or > > think too much (if I can help it), that makes them pretty limited. > > > > As has been mentioned, the longer the time the application may be > > willing to wait, the more likely it is that other time-outs (e.g., open > > port in a NAT) will time-out first. Right now, I don't realistically > > expect http ports without traffic to stay open for too long, in a NATted > > consumer environment. I'm thinking it's best not to bet on anything over > > 60 seconds in this environment. And I know I don't have enough knowledge > > or thinking ability to intelligently design an app that can properly > > determine a good value that's less than 60 seconds, other than "ASAP". > > I'd be a little worried if my app somehow knew this, when I sure don't. > > But, since I recognize that HELD can be used in other environments for > > other applications, I have to step beyond my dumb NATted consumer bias > > and admit that I really don't care. So long as I can have my simple, > > unthinking, un-knowing rule. And so long as we keep the text that says > > my LIS (or whatever the heck it's called) is allowed to use this value > > as something that provides guidance, rather than as an absolute limit (I > > prefer not to think too hard about LIS specifications, either). Under no > > circumstances, can I accept something that forces additional complexity > > on me. Optional complexity is ok. I'll just opt out. > > > > I hope somebody cries "uncle" soon on the current debate, so we can get > > on with some new and more exciting challenge. Maybe we can discuss how > > to deal with "accuracy vs. response time" needs in relation to > > references, rather than HELD. That would be such fun -- I'm really > > looking forward to it. > > Barbara > > > > > > _______________________________________________ > > Geopriv mailing list > > > > > > > > > > _______________________________________________ > Geopriv mailing list > > ------------------------------------------------------------------------------------------------ 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
Received on Fri, 17 Aug 2007 16:52:02 -0500

This archive was generated by hypermail 2.1.8 : Fri Aug 17 2007 - 17:54:01 EDT