|
|
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
|
|