Re: [secdir] secdir review of draft-forte-lost-extensions-06.txt

[Carl Wallace <[e-mail]>]

A few responses are inline.  Generally your responses are fine but I think
including your thoughts in the draft would be helpful.

On Tue, Aug 9, 2011 at 12:33 PM, Andrea G. Forte <[e-mail]> wrote:

> <snip>
> >
> >
> >The draft does not discuss error handling at all.  Some types of errors
> >associated with the extensions do not seem to fit into the errors
> >described in RFC 5222.  For example, could a server return an error when a
> >requested area was too large for a query?  Is the server allowed to place
> >its own limits less than a client requests?  These concerns may not arise
> >in
> >the 5222 context, where non-overlapping service regions are a mitigation.
>
>
> [AGF]
> I am not convinced we need additional error messages.
> Generally speaking, I do not think the draft should limit what the server
> can do with its content. Given a large area, a server could decide to
> return the highest rated POIs only, or perhaps a fixed subset, or all of
> them. I do not think that we can classify such behaviors as LoST errors.
> These seem to be policy issues rather than errors.
>
> [CW] It doesn't seem necessarily true to me that the extensions do not
introduce new error conditions, but highlighting the expectation that a
server can adjust a request in order to provide service would be helpful.
 Does there need to be some means for the server to indicate to the client
that there may be some additional related responses that can't be retrieved
using the provided request?  If not, it seems like there may be some blind
spots for some queries.


> >
> >Given the commercial focus of the draft, the potential for stale
> >information to be returned by a server seems high and probably worth a
> >mention.  For example, a pizza service may have closed.
>
>
> [AGF]
> This draft addresses extensions to the protocol used to convey information
> about location-based services. The way this information is maintained is
> out of scope.
> Similarly, for emergency services, if the boundaries of a PSAP change they
> have to be updated in the DB used by the LoST server. The way these are
> updated is not in the scope of RFC5222.
>
> [CW]
My point was the information is likely more volatile in the commercial
context and noting this is worthwhile since the issues probably does not
arise (at least as frequently) in the RFC 5222 context.  As with the others,
it seems worth noting somewhere even if the way the update is performed is
out of scope.


> <snip>
>