Subject: RE: [Ecrit] Comments/Questions on draft-ietf-ecrit-03

From: "Reese, Theresa E" <[email-masked]>
Date: Wed, 7 Feb 2007 11:49:09 -0500

Henning -

Thank you for addressing my concerns.
Some additional thoughts, in-line.

Terry Reese

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Tuesday, February 06, 2007 10:14 PM
To: Hannes Tschofenig
Cc: Reese, Theresa E; [email-masked]
Subject: Re: [Ecrit] Comments/Questions on draft-ietf-ecrit-03

Some additional comments inline.

On Feb 6, 2007, at 3:15 PM, Hannes Tschofenig wrote:

>>
> You concerned that someone asks for validation but the server does  
> not support it.
> I personally believe that an error message has to be returned in  
> the sense that the mapping is provided by the  LoST server  states  
> that  it was unable to  perform validation.  What do you think  
> about something like:
>
>
>  <warnings source="lost:authoritative.example">
>    <noValidation
>        message="Unable to perform validation."
>        xml:lang="en"/>
>  </warnings>
>

I don't think the warning is strictly necessary. If I ask for  
validation and the server doesn't return the corresponding  
validation, I know that the server doesn't support it. After all,  
we're presumably not having teenagers operate servers: "I don't feel  
like it and you can't make me do it".

My concern about adding these types of warnings is that this just  
adds another special case to consider: What if there is no warning  
and no validation? Does this mean something different?

[TER]  As I indicated in my original e-mail, Section 7.4.2 of lost-03
states that the server MUST include validation information in the
response if the 'validateLocation' attribute in the request is set to
"true."  If the absence of such information in the response is
considered an abnormal condition, then a warning seems appropriate.  If
the absence of such information in the response is NOT considered
abnormal, then perhaps the text in Section 7.4.2 should be changed from
"MUST" to "MAY".

>
> In some environments it is not necessary to include the  
> serviceNumber or the displayName. This is true, for example, in the  
> 3GPP architecture where LoST could be used between the E-CSCF (a  
> SIP proxy) and the LoST server.
>

Also, it is not clear that long-term, all services will have a  
service number. After all, we may eventually outgrow the notion of a  
12-button keypad. Certainly, for non-emergency service URNs, there  
may no such number at all. (What number would you assign to  
urn:service:restaurant?)

[TER] So are you suggesting that it will be up to the LoST server to
determine whether serviceNumber and displayName will be returned, based
on local policy?

> If LoST is run with the end host then it would perfectly make sense  
> to always include this information.
>

Subject to the qualification above.

>
>>  4.	Section 5.3 indicates that on occasion, a resolver will be
>> forced to return an expired mapping if it cannot reach the  
>> authoritative
>> server or cannot get useful information from the authoritative  
>> server.
>> Is this information flagged as expired (e.g., by including some  
>> kind of
>> warning in the message) or is it up to the client to check the  
>> date each
>> time to make sure the information is valid before using it?
>>
>>
>
> Another good point.
> Both approaches are possible but the current draft version  
> currently only allows a check of the expires attribute.
>
> I believe that the Phone BCP document should mandate some behavior  
> for emergency services.

The client has to check the expiration date in any event, so I would  
not include a warning. The expiration date indicates this  
unambiguously. (Otherwise, you can get strange cases, where, due to a  
slight clock offset, the data appears expired, but there's no  
warning, or vice versa. Again, that would be yet another unhelpful  
special case to deal with.)

>
>> 6.	Can the "forbidden" error defined in Section 12 also be used if
>> the LoST server receives a query from an entity that is not
>> allowed/authorized to receive the requested information?  (This is an
>> error case that can occur in the context of the NENA i3 Solution.) As
>> indicated in item 5 above, what is the appropriate error to return if
>> some requested information is available, but other requested  
>> information
>> is not available?
>>
>
> It might be necessary to include more error messages. Hence, it is  
> good that you raise them now.
> I could imagine that it is necessary to address these two error  
> cases in separate error messages
> For example, one could use "unauthorized" a LoST client is not  
> allowed to retrieve the requested information.
> On the other hand, when would you use this error message? Would you  
> deny access to a LoST database to an emergency caller?

For the reasons I mentioned above, I don't think it's helpful to  
include error messages for partial information. The only case I could  
see where this is useful where you get different information when you  
"log in" vs. without login.

But I'd like to understand a real use case before adding complexity.  
(I think having a design where somebody would try without login, then  
get partial information, then supply credentials, is needlessly  
complex. It would be better to have a separate server that requires  
authorization, if that's necessary.)

[TER] As Hannes suggested, these are really two different cases.  In the
case of the unauthenticated user, no information would be returned, so
an error indication would be appropriate, based on the text in the first
paragraph of Section 12.  If partial information is returned, the text
in the first paragraph of Section 12 says that a <warnings> element
should be returned as part another response element, if the LoST server
was able to respond in part, but the response was not what the client
desired.

>
>
> Thanks a lot for your review.

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 7 Feb 2007 13:31:30 -0500

> abnormal, then perhaps the text in Section 7.4.2 should be changed  

I agree that this needs to be clarified. I think it should be  
something like

"SHOULD return, unless the server does not support validation for  
that particular address"

or something along those lines.

> determine whether serviceNumber and displayName will be returned,  

I wouldn't call it "local policy" since this implies a choice, so  
it's rather more like "available data". Some mappings for some  
services just may not have a meaningful displayName or service number.

> was able to respond in part, but the response was not what the client

As I mentioned before, I don't see the need for a warning, as it just  
adds another variation that client code needs to handle. The only  
reason to distinguish between "not available" and "not available to  
you" is if adding credentials makes a difference. However, with HTTP  
Digest, that doesn't work, since you can't easily say "challenge  
me!" (and with Basic, it probably doesn't work, either, due to realm  
issues).

Henning