[email protected]
[Top] [All Lists]

Re: [Ecrit] comments on LoST

Subject: Re: [Ecrit] comments on LoST
From: Shida Schubert
Date: Thu, 15 Feb 2007 09:26:25 -0800

Andrew Newton wrote:

On Feb 15, 2007, at 1:00 AM, Shida Schubert wrote:
So if support simply implies that server understands the profile <notFound> is really useless and some additional information should be provided to aid the client in making
an intelligent decision.
If it can't return an error, some sort of warning that provides the seeker with a hint
implying which profile is needed for the resolution may be desirable.

This implies that the client making the query in geo also has the same location in civic and vice versa. That's a pretty big assumption. We have discussed this issue in great detail on this list, and the consensus was that if a client has location in both geo and civic and wishes to get an answer for both, the client will simply make two separate queries -- one for geo and one for civic. A <notFound> for one query will not prevent it from getting the information for the other.
No! Client may not have the same location in civic and geo, the location that these two profiles may overlap but probably has different accuracy. My geo location that I get from my GPS may be very accurate to a point and because of its accuracy would be the preferred
location to be used when my UA sends a LoST query.

According to your comment, there is a possibility that geo may not resolve to any URI even when recursive="true", because none of the authoritative servers responsible for the region
may hold the resolution data for geo.

If I obtain an error <notFound> but I know from <listServicesByRegionResponse> that resolution for the service I want is provided, I may want to re-try query with inaccurate civic location
information I obtain through DHCP.

If resolution for civic is available, at least I get some URI to contact the service I am interested in,
accurate location information can be provided then.

* I really hope that for an emergency case(service:sos), there will be a text in phone-bcp mandating the administrator of LoST to maintain mapping data for both geo/civic within the region so client only supporting geo or vice versa will at least get some kind of resolution. Furthermore, to increase the chance of obtaining the mapping data, I would also recommend recursive=true
at all time.

One question was unanswered..

If resolution is provided only for non mandatory-to-implement profile, would it still be listed in the <listServicesResponse> as service supported? If so I do think that's problematic.

Although I am aware that it is out of scope of protocol definition, but if
there is no indication of which profile is supported(data available)/service, some text imposing /recommending the server to provide resolution in at least one of the base profile should exist
for the protocol to be useful...

Further, it would be useful to have the ability to express the "profile type supported"/service
in <listServiceResponse> as well as <listServiceByRegion>.

I'm indifferent to this idea.  If others support it, we could add it in.

After I wrote this I looked at the schema and saw that defaultValue for
recursive is "true" but section 7.3.3 says it's default value is "false". I am
a bit confused is the default "false" or "true"?

-- Text from section 7.3.3 --
"A value of "true" indicates a recursive query, with the default being
"false" when the attribute is omitted.

That'll have to get fixed.  I'm inclined to have it default to true.
I am inclined to have it default to true as well.



Ecrit mailing list
[email protected]

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