Subject: [Ecrit] LoST 05

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 11 Mar 2007 16:23:01 -0400

LoST 05 is now in the archives, with the following changes based on  
ECRIT list discussion:

* Added the terms 'Mapping', 'LoST Client and Server', 'Service  
Boundary', and 'Validation' to the terminology section
* Extended the description in Section 3 "Overview of Protocol Usage".
* Fixed a bug in the example of Section 4 "LoST servers and Their  
Resolution"
* Removed the 'version' attribute of Section 5.1, from the Relax NG  
schema and from the examples.
* Modified the schema to prevent empty <path> elements.
* Updated text in Section 5.5. "Defining the Service Region with the  
<serviceBoundary> Element",
"5.6. Service Boundaries by Reference: the <serviceBoundaryReference>  
Element",
"7.3.4. Service Boundary", and
"7.4.2. Civic Address Validation: the <locationValidation> Element"
* Fixed a bug in the examples with respect to the srsName
* Updated Section 12. "Errors, Warnings, and Redirects"
* Changed the default value for the recursion attribute from 'true'  
to 'false".

* Added Jonathan's intro paragraph.
* Took out the optional <path> for responses.
* Added NO-CACHE and NO-EXPIRATION for expires attribute with  
corresponding text in Section 5.2.

* Modified the description in Section 6 "Path of a Request"
* Modified the description in Section 7.3.3. "Recursion and Iteration"

* Update to location profiles in  Section 11.1. "Location Profile  
Usage" and in
Section 11.2. "Two Dimensional Geodetic Profile"

There is still a need for a bit of clean-up in the examples, which  
didn't quite get done in the rush to meet the I-D deadline. We'll  
also add an error for an invalid/unknown SRS. Otherwise, we believe  
this to reflect list comments, so it would be particularly useful if  
those that have provided comments take a look at their main concerns  
and make sure that these have been addressed.

Henning
(on behalf of the LoST author team)

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

---

From: "Reese, Theresa E" <[email-masked]>
Date: Mon, 12 Mar 2007 13:29:57 -0400

LoST Author Team:

I want to take this opportunity to thank you for all your hard work on
the LoST Internet Draft.  I have reviewed lost-05 in detail and find it
to be quite complete.  I just have a few additional minor comments for
your consideration.

1.	Editorial comments:  

Section 3, first paragraph under <findService> and <findServiceResponse>

Change the first sentence to read:  "This message pattern allows for the
retrieval of contact URIs based on location information together with a
service identifier."

Section 3, first paragraph under <getServiceBoundary> and
<getServiceBoundaryResponse>

Change the first sentence to read: "This message pattern supports a
query for a service boundary.  The details can be found in Section 8."

Section 5.6, last paragraph, last line:  remove the extra "the".

Section 11.1, item 3, first sentence:  Change "profiles of derived" to
"profiles if derived".

Section 13, second paragraph:  Add a period at the end of the sentence.

2.	Section 6, third paragraph states, "If a query is answered
iteratively, the querier includes all servers."

The only "querier" in an iterative example is the original client.  The
authoritative (responding) server will only identify itself in this
scenario, so the <path> element should contain only the <via>
corresponding to the responding server.  Perhaps this could be clarified
in the text.

3.	Section 7.3.3, second paragraph states, "In iterative mode, the
server contacted returns a redirection response indicating the next
server to be queried."

Must a redirection response always be provided?  Wouldn't that only be
necessary if the first server could not respond to the request?

4.	Figure 7, Figure 9, Figure 17

Based on Section 5.1, hasn't the "version" attribute been removed from
the Data Source information in <findServiceResponse> messages?  

5. Section 12, first paragraph states, "This document does not define
warnings."  

This sentence seems to conflict with the last sentence in the same
paragraph which states, "Unless otherwise noted, all elements below can
be either an error or a warning, depending on whether a default
response, such as a mapping, is included."  What is intent of the
statement that says that this document does not define warnings?  Is the
idea that warnings are not explicitly defined AT THIS TIME (i.e., that
they will be addressed in the future), or that warnings should not be
used at all.  I think warnings could be very useful.  The last sentence
of Section 12.2 seems to imply the former.  (I noticed that there was no
pattern provided in the Relax NG Schema in Section 14 for "Warning".)

Thank you again for all your hard work and your patience in addressing
my comments and those of the others on the ECRIT list.

Terry Reese

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Sunday, March 11, 2007 4:23 PM
To: ECRIT
Subject: [Ecrit] LoST 05

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 12 Mar 2007 20:27:12 -0400

Theresa,

thanks again for your careful review. I will be editing -06 based on  
these comments; please see inline.

> retrieval of contact URIs based on location information together  

Reworded.

> query for a service boundary.  The details can be found in Section 8."

Fixed.

> Section 13, second paragraph:  Add a period at the end of the  

Fixed.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 12 Mar 2007 20:36:08 -0400

> corresponding to the responding server.  Perhaps this could be  

The idea was that the query would contain all the servers the client  
has contacted so far. This allows a mixture of iterative and  
recursive resolution, if desired, without losing the loop protection  
mechanism. For example, if client C has contact X and Y so far, where  
X has redirected C to Y and Y to Z, C would send a message to Z:

<path>
   <via>X</via>
   <via>Y</via>
</path>

I don't know if this is helpful or necessary, but it seems at least  
harmless.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 12 Mar 2007 20:45:18 -0400

> necessary if the first server could not respond to the request?

Indeed. Added

if the server contacted connot provide an answer itself

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 12 Mar 2007 20:55:56 -0400

> the Data Source information in <findServiceResponse> messages?

This is a bug; fixed.

> pattern provided in the Relax NG Schema in Section 14 for "Warning".)

This is an incomplete discussion. We had started to discuss the idea  
you quote, namely that the same condition can lead to both an error  
or a warning, depending on the circumstances. However, this does not  
appear to be the case for any of the errors defined in the document,  
i.e., for none of the errors listed would it be possible to return a  
(partial) answer, as far as I can tell.

Maybe my co-authors have a different perspective.

Henning

---

From: Andrew Newton <[email-masked]>
Date: Mon, 12 Mar 2007 23:14:27 -0400

On Mar 12, 2007, at 8:55 PM, Henning Schulzrinne wrote:
> This is an incomplete discussion. We had started to discuss the  
> idea you quote, namely that the same condition can lead to both an  
> error or a warning, depending on the circumstances. However, this  
> does not appear to be the case for any of the errors defined in the  
> document, i.e., for none of the errors listed would it be possible  
> to return a (partial) answer, as far as I can tell.
>

Apparently we seem to be circling on this issue.  I think the case  
could be made that a server that for some reason could not get to its  
RDBMS data store might want to return a default configured answer and  
an <internalError> warning, because the policy of the server is to  
respond on a best effort basis.  Similarly, a server operator may  
want to issue a <badRequest> warning and return some sort of default  
answer for queries that just cannot be parsed -- again as part of a  
best effort basis.  Some server operators may not want to do that.   
I'm not saying either way is right or wrong.  It's a matter policy,  
and it's one I'd feel more comfortable putting in the hands of the  
operators and not making in a protocol.  The important thing from a  
protocol perspective is that a client acts upon an answer with  
warnings in the same exact way that it would act upon the answer if  
no warnings were given.  Warnings are strictly for postmortem analysis.

Incidentally, <warnings> is defined in the Relax NG, page 43 of the  
draft.  It is part of the commonResponsePattern.

-andy

---

From: Ted Hardie <[email-masked]>
Date: Mon, 12 Mar 2007 21:10:31 -0700

At 11:14 PM -0400 3/12/07, Andrew Newton wrote:
>Apparently we seem to be circling on this issue.  I think the case could be made that a server that for some reason could not get to its RDBMS data store might want to return a default configured answer and an <internalError> warning, because the policy of the server is to respond on a best effort basis.  Similarly, a server operator may want to issue a <badRequest> warning and return some sort of default answer for queries that just cannot be parsed -- again as part of a best effort basis.  Some server operators may not want to do that.  
>I'm not saying either way is right or wrong.  It's a matter policy, and it's one I'd feel more comfortable putting in the hands of the operators and not making in a protocol.  The important thing from a protocol perspective is that a client acts upon an answer with warnings in the same exact way that it would act upon the answer if no warnings were given.  Warnings are strictly for postmortem analysis.
>
>Incidentally, <warnings> is defined in the Relax NG, page 43 of the draft.  It is part of the commonResponsePattern.

I think this remains a tension we identified a long time ago; for most protocols,
a clear error when the server cannot process a request is a useful thing.  If
your life depends on it, *some* answer, however derived, is better than
nothing.  You don't care if the answer is old, the backup's backup, or what--it
gives you a better chance of reaching a call taker than nothing.

In the ECRIT version of LoST, in other words, we throw out protocol
purity in order to allow the server to be as robust as possible in the general
aim.  The warnings Andy identified would be there to tag the requests as somehow
sub-optimal, without refusing to provide some answer.  With a bit more experience,
we're likely to have a better shot at identifying what warnings will be useful.
In the meantime, I would personally suggest returning the answer you have,
without identifying its shortcomings explicitly at the moment (possibly
manipulating the expiry if it is a transient error).

				Ted

---

From: Andrew Newton <[email-masked]>
Date: Tue, 13 Mar 2007 09:52:28 -0400

> manipulating the expiry if it is a transient error).

Are you suggesting we get rid of the warnings?  Just trying to  
understand your last sentence.

We might want to put something in the draft, perhaps in an appendix,  
about best-effort answers.  Using the value NO-CACHE in the expiry  
attribute is the proper way of manipulating the expiry in this case,  
I believe.

-andy

---

From: "Reese, Theresa E" <[email-masked]>
Date: Tue, 13 Mar 2007 10:42:58 -0400

LoST Authors:

I believe warnings will be useful in situations where, for example, a
client sends an iterative <findService> query that includes a request
for location validation, and the server, while capable of returning
routing information, does not itself do location validation.  In this
instance, only the routing information would be included in the
response, but is would be useful to indicate via a warning that
validation information is not available.  This may trigger the client to
either send future queries requesting recursive service (with the idea
being that the server will have an arrangement with another server that
performs location validation), or to omit requests for validation from
future queries sent to the "routing only" server.  

I would like to see some additional work done to include warnings in a
future update to LoST.

Terry Reese

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Tuesday, March 13, 2007 9:52 AM
To: Ted Hardie
Cc: Henning Schulzrinne; Reese, Theresa E; ECRIT
Subject: Re: [Ecrit] LoST 05 #4, #5

-andy

---

From: Andrew Newton <[email-masked]>
Date: Tue, 13 Mar 2007 10:59:55 -0400

> future queries sent to the "routing only" server.

Theresa, the behavior you have specified seems to violate the rule  
that I called out.  Specifically, that warnings DO NOT change the  
behavior of clients.  Or were you suggesting that a human was the one  
observing the warning and changing recursive flag?

> I would like to see some additional work done to include warnings in a

The schema does allow the addition of warning from other XML  
namespaces without the need for specifically revising the LoST  
protocol to accommodate them.

-andy

---

From: "Reese, Theresa E" <[email-masked]>
Date: Tue, 13 Mar 2007 11:28:37 -0400

Andy -

I was thinking that the return of the warning could be logged (like the
return of an error indication), and that this could result in a human
potentially

modifying some settings.  Even if the modification didn't take place, I
was envisioning that the logging would.  It seems odd to me that if a
client makes an explicit request (e.g., for location validation), and
the server cannot accommodate it and so does not return the requested
information (even though it can and does return routing information),
that this would not be flagged as some kind of abnormal situation.

While the schema may allow for warnings from other XML namespaces, the
text in the document is currently ambiguous about whether they are
supported or not.

Terry

________________________________

From: Andrew Newton [mailto:[email-masked]] 
Sent: Tuesday, March 13, 2007 11:00 AM
To: Reese, Theresa E
Cc: Ted Hardie; Henning Schulzrinne; ECRIT
Subject: Re: [Ecrit] LoST 05 #4, #5

Theresa, the behavior you have specified seems to violate the rule that
I called out.  Specifically, that warnings DO NOT change the behavior of
clients.  Or were you suggesting that a human was the one observing the
warning and changing recursive flag?

future update to LoST.

The schema does allow the addition of warning from other XML namespaces
without the need for specifically revising the LoST protocol to
accommodate them.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Tue, 13 Mar 2007 11:46:47 -0400

On Mar 13, 2007, at 11:28 AM, Reese, Theresa E wrote:

> Andy –
>
>
>
> I was thinking that the return of the warning could be logged (like  
> the return of an error indication), and that this could result in a  
> human potentially
>
> modifying some settings.  Even if the modification didn’t take  
> place, I was envisioning that the logging would.  It seems odd to  
> me that if a client makes an explicit request (e.g., for location  
> validation), and the server cannot accommodate it and so does not  
> return the requested information (even though it can and does  
> return routing information), that this would not be flagged as some  
> kind of abnormal situation.

Ok.  So you were thinking along the same lines as I was.

I believe Henning has stated in the past that such logging could take  
place because the validation information would not be present and  
therefore no explicit warning is needed.  However, an explicit  
warning does provide a place to put appropriate descriptive text if  
that is desirable.  I see no harm in adding an  
<validationUnavailable> element as a compromise to this issue.   
Henning?  Anybody else?

>  While the schema may allow for warnings from other XML namespaces,  
> the text in the document is currently ambiguous about whether they  
> are supported or not.
Agreed.  Once we come to resolution, the text needs to be better  
about what is going on here.

-andy

---

From: Ted Hardie <[email-masked]>
Date: Tue, 13 Mar 2007 10:30:50 -0700

At 9:52 AM -0400 3/13/07, Andrew Newton wrote:
>Are you suggesting we get rid of the warnings?  Just trying to understand your last sentence.

Sorry, it was late and my cold medicine was kicking in.  I do not want to get
rid of the warnings.  I was trying to say that someone deploying now can just
return the answer it has, without worrying about providing a warning, if
they are not sure what warning to provide.  They might, as you suggest below,
use NO-CACHE to make sure that the answer is expired promptly.

					ted

>We might want to put something in the draft, perhaps in an appendix, about best-effort answers.  Using the value NO-CACHE in the expiry attribute is the proper way of manipulating the expiry in this case, I believe.
>
>-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 13 Mar 2007 13:42:35 -0400

I have no objection to providing additional diagnostic information,  
as long as it is optional for this particular case (no validation).  
In other words, a client should be able to ignore the warning and  
still function just fine.

On Mar 13, 2007, at 11:46 AM, Andrew Newton wrote:

>> I was thinking that the return of the warning could be logged  
>> (like the return of an error indication), and that this could  
>> result in a human potentially
>>
>> return routing information), that this would not be flagged as  
>> some kind of abnormal situation.
>
> I believe Henning has stated in the past that such logging could  
> take place because the validation information would not be present  
> and therefore no explicit warning is needed.  However, an explicit  
>>  While the schema may allow for warnings from other XML  
>> namespaces, the text in the document is currently ambiguous about  
>> whether they are supported or not.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 13 Mar 2007 13:46:35 -0400

I generally agree with the objective, but will point out practical  
limitations. It is not clear to me what useful answer can be returned  
by a local resolver, say, unless you return some global emergency  
calling center. In some cases, such as authoritative servers that are  
responsible only for a state, such a default answer is reasonable,  
since they wouldn't have been contacted unless somebody else believed  
the location to be in that state, say.

In any event, making the Warning optional and indicating its purpose  
for logging, while explaining the behavior should allow sufficient  
implementation flexibility for server writers without burdening  
clients with numerous additional code paths and special cases.

On Mar 13, 2007, at 12:10 AM, Ted Hardie wrote:

>> could be made that a server that for some reason could not get to  
>> its RDBMS data store might want to return a default configured  
>> answer and an <internalError> warning, because the policy of the  
>> server is to respond on a best effort basis.  Similarly, a server  
>> operator may want to issue a <badRequest> warning and return some  
>> sort of default answer for queries that just cannot be parsed --  
>> again as part of a best effort basis.  Some server operators may  
>> not want to do that.
>> I'm not saying either way is right or wrong.  It's a matter  
>> policy, and it's one I'd feel more comfortable putting in the  
>> hands of the operators and not making in a protocol.  The  
>> important thing from a protocol perspective is that a client acts  
>> upon an answer with warnings in the same exact way that it would  
>> act upon the answer if no warnings were given.  Warnings are  
>> strictly for postmortem analysis.
>>
>> Incidentally, <warnings> is defined in the Relax NG, page 43 of  
>> the draft.  It is part of the commonResponsePattern.
>