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

[Henning Schulzrinne <hgs at cs.columbia.edu>]

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?


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


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


>    * 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
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit