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

[Shida Schubert <shida at ntt-at.com>]

Henning;

My comments inline..

Henning Schulzrinne wrote:
>
> On Feb 1, 2007, at 2:43 PM, Shida Schubert wrote:
>> 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
>> obvious.
>
> Concrete suggestions are most appreciated, keeping in mind that we
> want to avoid writing a 150-page document.
I don't think we need to worry about this in the LoST spec itself.
I will have a look at the next revision of phoneBCP and comment there if
necessary.
>
>
>>
>> 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..).
>
> The server should do service substitution in that case, as discussed
> in the document.
>
It's at server's discretion right now to return an error or an alternative.
If the behavior is recommended as in your comment with a "SHOULD", it's
all good.
Again wait for phoneBCP I guess.
>
>
>>
>> - "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).
>
> For any error, it is unknowable of whether repeating the same request
> some time in the future will succeed. After all, even asking for an
> "unknown" location a day later may succeed, after the road has been
> built or the database has been updated. There are even syntax errors
> that might "fix" themselves, e.g., after a client or server
> implementation gets updated with the next automatic software update.
>
> Thus, unless you have a crystal ball protocol we should reference, I
> don't see how this can be made more concrete.
I understand.
Again if the loop was caused by recursive search for sub-services the
spec can possibly
states to recommend returning a substitution if the server knows such
information.
>
>
>>
>> - "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
>> redirect
>> with URI of LoST servers that can serve the request or ensure
>> alternative is
>> sent back.
>
> We can't fix broken implementations. You are essentially duplicating
> the existing mechanism here.
Well this is not always returned when the implementation is broken.
AFAIK from the text, server can return this error if the server does not
support
the service client requested. There is a possibility that it knows of
other server that
support the service requested in which case it should return a reference
and return
an alternative if one exists. Again a topic for phoneBCP.
>
>> Do you envision this VSP-provided call center URL provided through means
>> such as
>> DHCP/Sip configuration framework?
>>
>
> Yes, with SIP configuration being the more likely case since VSPs are
> unlikely to operate DHCP servers unless they are also ISPs.
>
>
>> 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
>> some
>> entity on the signaling path will be able to do the resolution on UA's
>> behalf).
>>
>> Also I agree that phone BCP is probably a good place to include the
>> normative behavior.
>
> As you say, this belongs in the phone BCP, not the LoST protocol spec.
Agree. phone BCP it is.
>
> Henning
>
>
>


_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit