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

From: "Reese, Theresa E" <[email-masked]>
Date: Wed, 7 Feb 2007 13:50:25 -0500

Henning -

One additional comment regarding the optional return of displayName and
serviceNumber in a LoST <findServiceResponse> - -

It may be that the return of such information may be useful to some
types of clients and not to others who are accessing the SAME service.
For example, a serviceNumber will not be useful to an ESRP, but may be
useful information for end user equipment (where both types of clients
are accessing the same service).  Doesn't this imply that a choice must
be made by the server about whether or not to return the information?

Terry

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Wednesday, February 07, 2007 1:32 PM
To: Reese, Theresa E
Cc: [email-masked]
Subject: Re: [Ecrit] Comments/Questions on draft-ietf-ecrit-03

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

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.

>
> [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?
>

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.

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

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

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 7 Feb 2007 14:48:34 -0500

Terry,

After some back-and-forth, I think we arrived at the design choice  
that there's not much advantage in having lots of querier  
configuration for the answer except for validation and boundaries, as  
those are relatively expensive for the server or large in byte  
volume. We want to be able to return signed mappings eventually and  
use caching now, so the more variations (with/without displayName,  
with/without service number, etc.), the more effort will be required  
for signing and the less well caching works.

Thus, I think the right model is that clients ignore information they  
don't need and that servers return all the information they have.

Henning

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 07 Feb 2007 22:16:38 +0100

Hi Terry,

> be made by the server about whether or not to return the information?
The LoST server could make such a differentiation given the information 
it has. You mentioned that the ESRP has to authenticate to the LoST 
server and the end host hopefully doesn't need todo that. To me that 
sounds like an easy way to differentiate.
Even if the LoST server sends the two elements always it does not hurt 
-- I doubt that the bandwidth between the ESRP and the LoST server will 
be  limited.

Ciao
Hannes