ecrit@ietf.org
[Top] [All Lists]

Re: [Ecrit] Review of LoST-04, part 1

Subject: Re: [Ecrit] Review of LoST-04, part 1
From: Shida Schubert
Date: Tue, 27 Feb 2007 15:40:05 -0800

Hi Henning;

My comments inline..

Henning Schulzrinne wrote:
Just some selective comments:


As noted in the text that reference the draft, one would perceive that "serviceboundary" is always included. If the server can include nothing then the statement above should be changed to reflect this fact. I just don't know how caching would work if there is no serviceboudary.. But as caching is out of scope of this document, I guess that's irrelevant.

I agree that caching would not work in general; this should be noted. Note that a server that doesn't have service boundaries can always return the query location itself as a service boundary. This isn't too useful for geodetic coordinates (since the likelihood of getting the exact same query again is zero), but modestly useful for civic coordinates.

Yes that could work at least for civic coordinate. So are you saying you want to keep the following statement as is?

"The response MUST contain at least one service boundary using the same profile as the request."

I am okay with this as long as something is clarified about what it means to the client when
it asks for a particular information and it does not get returned.
> I guess currently as you stand it could have two semantics.
  > 1. Doesn't support it.
  > 2. Can't provide the information currently but support it.

It can mean any of these things, in addition to "I don't like the way you look and I'm not going to give the data to you" or "It's Friday afternoon, and I'm too lazy to bother".

I don't think we want to distinguish these cases; from a client perspective, it doesn't matter and it is unclear what is really means to "support" a feature, but not be able to return an answer. I don't much care if the LoST server software has a particular feature, but the feature was disabled or the data necessary for the feature isn't available. We are not a jury trying to determine the motive for a crime.
I envisioned people implementing a smart(dumb?) querier which changes its query and information it asks for based on the response it got from the server(logs the capabilities of resolver). For example, the resolver receiving no validation may decide to ask for no validation(Don't ask me why..) in the next query it sends. But come to think of it, either ways its quite harmless so you are right the clarification is probably unnecessary.

Regards
 Shida


Henning




_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit

<Prev in Thread] Current Thread [Next in Thread>