Re: [Geopriv] HELD comment on responseTime parameter

From: Carl Reed OGC Account ^lt;creed@opengeospatial.org>
Date: Fri Aug 17 2007 - 11:17:18 EDT

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" <bs7652@att.com>
To: "Cullen Jennings" <fluffy@cisco.com>; "Dawson, Martin"
<Martin.Dawson@andrew.com>
Cc: "GEOPRIV" <geopriv@ietf.org>
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@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Fri, 17 Aug 2007 09:17:18 -0600

This archive was generated by hypermail 2.1.8 : Fri Aug 17 2007 - 11:22:17 EDT