[email protected]
[Top] [All Lists]

Re: [Ecrit] Review of draft-ietf-ecrit-lost-03.txt - part 1

Subject: Re: [Ecrit] Review of draft-ietf-ecrit-lost-03.txt - part 1
From: Shida Schubert
Date: Thu, 01 Feb 2007 11:43:50 -0800
Hi Henning;

My comments inline..

Henning Schulzrinne wrote:
> Shida,
> thanks for your comments; please see some initial responses and
> questions inline. I'll skip items that I'll try to integrate directly.
> On Feb 1, 2007, at 5:25 AM, Shida Schubert wrote:
>>> For example, what is client to do if it receives any of the
>> errors in section 12.1? If we don't provide some sort of
>> recommendation, things are likely to get messy and simply not work.
> I don't know what one can say in this case. In some cases, the client
> has to fix the address submitted, possibly with human input. In other
> cases, such as a system failures, a client will either have to retry
> later or use stale cached data. It seems fairly obvious in most cases
> what behavior is appropriate; we have been rightly admonished that the
> spec is somewhat wordy as is, so I'm reluctant to belabor the obvious.
> Can you identify places where an implementor would be in doubt what to
> do?
Probably for most cases, I am likely to come up with a conclusion analogous
to yours and implementors are likely to be smarter than I, so may be I am
simply over concerned here.

Anyhow, I don't think it's a bad practice to lay out some
recommendations to
ensure every effort is made for emergency call to succeed. After all
people can
get quite creative with their way of thinking/interpreting the so called
>> 2. Errors shouldn't be sent on its own.
>>> I strongly believe that for some of the errors either it
>> should be recommended to attach a default URI for the service
>> requested(notFound,loop) or send the error with the
>> potential redirect targets(serviceNotImplemented,
>> locationProfileUnrecognized,internalError,loop,notFound).
> I don't understand what you're suggesting here. Unless you posit a
> general worldwide emergency call service, where you can send calls if
> all else fails, I don't see how this can work. If a LoST system
> doesn't understand an address at all, for example, it has no clue
> whether you are in England or Estonia. I think provider-specific
> fall-back call center information should probably be conveyed outside
> of LoST, as it is SIP-level configuration.

I will try to paraphrase the problem that I see with few examples.

- "serverError"
If serverError is returned to a client as a result of a recursive query for
service:sos:police and LoST server happens to know of a URI that can map
service:sos(but not service:sos:police thus the recursion)/location, URI
representing service:sos, I believe should be returned.

Rather than just returning an error=serverError(Which I believe is useless
without any details of error..).

- "loop"
I am not sure what client is supposed to get out of this? If it looped once
will it loop again for the same request? Is this a dead end? This error
I believe
is useful for debugging purposes but means nothing to a client(UA).

- "serviceNotImplemented"
According to the text in the draft, server may return these errors even
when there is an alternative. It may return these errors even if the server
is aware of a server that can serve the request righteously.

Rather than returning this error, it may be better to respond with a
with URI of LoST servers that can serve the request or ensure
alternative is
sent back.

>> 3. Do we really want to send an error at all?
>>> I vaguely remember the talk about sending a default PSAP URIs
>> rather than sending an error and stalling an emergency call.
> See above. I think the phone BCP should specify what happens if a
> device has no usable mapping at the time of an emergency call. As
> noted above, I think that will mean falling back to a VSP-provided
> call center URL.
Do you envision this VSP-provided call center URL provided through means
such as
DHCP/Sip configuration framework?

As I noted in my comments below, I think the problem that's giving me
the stomach
pain will be nonexistent if client(UA) is not acting as a resolver itself.

I guess if above URL that you mentioned is not provided through means
such as DHCP/
Sip configuration, some text needs to recommend the UA to try sending
out an INVITE
with service URN despite its own attempt to resolve fails(And hope that
entity on the signaling path will be able to do the resolution on UA's

Also I agree that phone BCP is probably a good place to include the
normative behavior.
>> * 2 and 3 may not be a problem if the client(UA) is not trying
>> to contact the LoST server directly. In which case resolver is
>> likely to have some useful cache. I am worried about a case where
>> UA boots up and has no cache, sends a query to LoST server and
>> fails. Where does it go then?
> Again, see above.
> To be continued.
> Henning

Ecrit mailing list
[email protected]

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