RE: [Geopriv] GC Comments ondraft-ietf-geopriv-http-location-delivery-01.txt

From: Brian Rosen ^lt;>
Date: Mon Oct 01 2007 - 15:36:10 EDT

> [GC] I don't think is should be left as "implementation dependent" if
> ubiquitous UA-to-LIS interoperability is a goal here. I think this spec
> should define exactly what the expected behaviour here is.
I'm not sure I see the connection. If you don't specify a time, then the
client should be capable of handling whatever the server can throw at him.
I think in most cases it will be pretty obvious what the most appropriate
result will be when no ResponseTime is provided. There is always a curve
(or a set of curves) and it won't be too hard to find something that is
reasonable. If the client has limitations, that is what the parameter is
there for. If it says nothing, it's up to the server to choose.

I do think we ought to put a warning in the text that real response times in
the order of 30 seconds or more must be expected. I've said many times that
the whole notion that request/response is appropriate when response times
are tens of seconds is seriously wrong, but that's what actually happens

> I do recognize that there is the problem that if you specify locationType,
> get it, and then try and use it for emergency call, it will fail. The
> suggestion above (exact="false") is a way to avoid the problem. It may be
> worth having a warning if you set exact="true" and specify a locationType
> not supported by the local emergency call service.
> [GC] This may be a way out if the setting of the "exact" attribute is
> always controlled by a human that understands what it does. Is it the
> assumption here?

No, I would think not. But then, I think if someone is coding to
exact="true" then you should expect the application to know what it is
doing. If you have a more general purpose location API, as I've talked
about for all the LCPs, then it wouldn't use exact="true". If you were
specifically writing for emergency call, you would use whatever we decide is
the answer here, and I'll put whatever that is in -phonebcp.

> If you use the distinguished values in ResponseTime, the only error you
> can
> get is cannotProvideLiType; you can't get the timeout error. I think it
> is
> proper that you get the cannotProvideLiType.
> [GC] Fine. Maybe the spec should be clear on the non-applicability of the
> timeout code then. I agree that cannotProvideLiType should be returnable
> in this case but my concern still remains if no LI is provided in that
> case. Is it another case of trying with more relax rules here again? If
> so, let's say so.
Yes, it's another case of retry with more relaxed rules. Don't have a
problem with saying so, but I for one would think that is obvious.

> The document should specify MUST IMPLEMENT. See RFC3261 for an example:
> Proxy servers, redirect servers, and registrars MUST implement TLS,
> and MUST support both mutual and one-way authentication.
> [GC] If this means that not using TLS makes the implementation non-
> standard, then, I prefer "RECOMMENDS". If it means that the HELD-enabled
> LIS must at least support an implementation with HTTPS but could support
> HTTP as well, then I'm ok.
MUST implement means the code has to implement TLS, but doesn't have to use
it. That means your second definition; you implement both http and https.


Geopriv mailing list
Received on Mon, 1 Oct 2007 15:36:10 -0400

This archive was generated by hypermail 2.1.8 : Mon Oct 01 2007 - 15:37:10 EDT