Subject: [Ecrit] Review of LoST-04, part 1

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 13 Feb 2007 15:53:00 -0500

I've hardly started to put out comments, but given the contentious 
nature of definitions, I figured this should hit the list now. I'm not 
wedded to the proposed definitions, but I think they capture the usage 
within LoST-04.

1. Organization of the document
-------------------------------

I find that the presentation in lost-03 has a few things out of place:

-- Section 3 is specific to usage of the <findService> message, so it
really belongs in the introduction to section 7.

-- Section 5 is specific to the <findServiceResponse> message, so it
belongs in section 7.4, immediately after section 7.4.1. A high-level
understanding of the intent of <mapping> is all that is needed up to
that point.

Bearing these comments in mind, please note that subsequent comments use 
the existing section numbering in LoST-04. In the case of proposed text, 
that numbering may have to be changed if these comments are accepted. 
This possibility is flagged by enclosing section numbers in proposed 
text in quotes.

Section 1
---------

para 3: LoST doesn't cache -- it supports caching.

", para 4: Delete "The relationship between", so that the sentence 
starts "Other functions ...". Not sure I'd call architecture a function, 
but I can't think of another word at the moment.

Section 2
---------

Little terminology from [18] is really used in this document. For 
instance, "mapping" is more general in this document than in [18], and 
should likely be defined explicitly here. Here is a stab at some text:

<proposed text>

Mapping

Mapping is a process that takes a location and a service identifier as 
inputs and returns one or more URIs that point to a host providing that 
service or acting as an intermediary to establish communication with the 
serving entity. This definition is a generalization of the term 
"mapping" as used in [18], because of the potential for LoST to be used 
for non-emergency services.

Mapping is performed in LoST through exchange of the <findService> and 
<findServiceResponse> messages as defined in section "7".

LoST Client and Server

"LoST client" is the role played by a host that sends LoST query 
messages and receives LoST response messages. "LoST server" is the role 
played by a host that receives LoST query messages and sends LoST 
response messages. In recursive operation, the same host may play both 
roles. This document also uses the term "authoritative server" to 
designate a host that acts in the LoST server role only and successfully 
resolves the input location and service identifier to a URI or set of URIs.

Service Boundary

A service boundary is the boundary or set of boundaries of a geographic 
region, respectively set of geographic regions, within which all 
locations will map to the same URI or set of URIs for a given service.

In LoST, service boundaries are expressed using ...

Validation

The term "validation" as used in this document is a concrete realization 
of the term "location validation" as defined in section 3.5 of [18].

</proposed text>

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 22 Feb 2007 21:05:29 +0100

Hi Tom,

thanks for your review and your text proposals. Please find my response 
below:

> 1. Organization of the document

You are right.

I, however, think that we should extend Section 3 by including the other 
message exchanges to give an overview what will be described later.

> understanding of the intent of <mapping> is all that is needed up to
That's certainly possible. When we decided to move the <mapping> element 
section we thought that it would be useful since it is one of the core 
building blocks.

> Bearing these comments in mind, please note that subsequent comments 
> use the existing section numbering in LoST-04. In the case of proposed 
> text, that numbering may have to be changed if these comments are 
> accepted. This possibility is flagged by enclosing section numbers in 
> proposed text in quotes.
>
> Section 1
> ---------
>
Fixed.

> starts "Other functions ...". Not sure I'd call architecture a 
> function, but I can't think of another word at the moment.
>
Fixed.

> inputs and returns one or more URIs that point to a host providing 
> that service or acting as an intermediary to establish communication 
> with the serving entity. This definition is a generalization of the 
> term "mapping" as used in [18], because of the potential for LoST to 
> be used for non-emergency services.
>
> messages and receives LoST response messages. "LoST server" is the 
> role played by a host that receives LoST query messages and sends LoST 
> designate a host that acts in the LoST server role only and 
> successfully resolves the input location and service identifier to a 
> URI or set of URIs.
>
> Service Boundary
>
> A service boundary is the boundary or set of boundaries of a 
> geographic region, respectively set of geographic regions, within 
> which all locations will map to the same URI or set of URIs for a 
> given service.
>
> The term "validation" as used in this document is a concrete 
> realization of the term "location validation" as defined in section 
> 3.5 of [18].
>
> </proposed text>

Thanks for the text. Looks good to me (with some minor modifications). 
By including these terms into the LoST draft we have a bit of repetition 
but it could improve the readability of the draft.

Ciao
Hannes

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 23 Feb 2007 07:13:07 -0500

Hi. One remark.

> section we thought that it would be useful since it is one of the core 

[PTT] This goes to the heart of one of Jonathan's remarks. You are 
thinking of data structures, where I assumed LoST-04 was documentation 
of a protocol. Viewed in that latter light, no matter how much effort 
went into the definition of <mapping>, it is just one information 
element of just one of the messages in the protocol, and (I think) 
should be documented in its proper place relative to that protocol 
description.

...

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 23 Feb 2007 17:50:21 +0100

Hi Tom,

~snip~

> should be documented in its proper place relative to that protocol 
It is fine for me to move the section.
There are different ways to write a document and the protocol machinery 
behind LoST is not complex. Hence, there are a number of element and 
attribute descriptions.

If you take a look at OASIS documents that are full of XML stuff then 
you will notice a very similar document style.

Ciao
Hannes

---

From: Shida Schubert <[email-masked]>
Date: Mon, 26 Feb 2007 14:43:34 -0800

Hi Hannes;

 Here is my review on version 04.

 You mentioned OASIS, and your draft on SAML usage in
SIP although based on OASIS protocol covers a good deal of
entity behavior.. So I wonder what's so different with LoST.

 Anyhow, I listed things that lack the minimum normative text
which could lead to a guessing game among implementors.

 Section 5.7:
  Section 5.6 has normative text noting it is mandatory to include at least
one <serviceBounary> element. But there is no normative text about
<serviceBoundaryReference>.

 I can assume it to be true for by-reference case as well but it's not
explicitly stated.
 
  If the following text meant that it's mandatory for both modality then
I think the text should be elaborated to be explicit about this fact. 
It's odd though
to have this in <serviceBoundary> element section.. It almost feel like 
there should
be a parent section called service boundary which describes most of 
what's written
in <serviceBoundary> that covers both modality.

"The response MUST contain at least one service
   boundary using the same profile as the request."

 Section 7.3:
  It talks about attributes that governs the response and it looks like 
there is
some expectation by the following text but it's not a normative text.

 "which elements must be contained in the response."
 > Shouldn't this be "MUST be contained in the response."?

 Also, it's not clear who is responsible for this response. One 
generally assumes
this to be a server but someone creative may think otherwise.

 Section 7.3.3:

 For when recursion is true there is no normative text as to whether 
server has to
recurse the request or not. One would assume that its based on the 
implementation.
   > Some server may always return response without recursion.. As "via" 
is not
       mandatory to set according to the text, client will have no way 
to know whether
       the request with recursive=true was actually executed.
   > As mentioned text here says "recursive is false by default" but 
schema says otherwise.
 
 via element > Doesn't have any text mandating that authoritative server
               which received the recursive query has to add this element.

 * This section although describing about the component of the 
request(attribute called
    recursive which asks the server to recurse.), it has normative text 
for the server.
    (e.g. MUST NOT recuse if the attribute is "false") I find it a bit odd.
 * Section 7.3 is somewhat confusing because element that can be set in 
request and
    attributes that can be set in those elements are at the same 
hierarchy. If you are going
    to keep it the way it is. I would at least change the title of 
section 7.3.3 and 7.3.4, 7.3.5
    to "Recursion attribute", "Service Boundary attribute" and 
"ValidateLocation" attribute
    so it's a bit more clear. If you are wanting to describe the general 
semantics of Location
    Validation, Recursion etc. then I think it should go in a different 
section. May be prior
    to <mapping> element describing general features and characteristics 
of LoST protocol.

 If you want to describe the attribute's semantics in one section I 
think it needs to clarify
this by saying something like "If this attribute is in request, it 
indicates that client wishes
to..." and clarify what goes on at the server side..
 
Section 7.3.4
 The following text is somewhat confusing especially because the text 
prior to
this is saying what server returns is at server's discretion..

 "Servers SHOULD NOT return a by-value service boundaries
if the querier requested a reference. "

 Yes I understand it's a SHOULD NOT strength so there is exception
but it still seems to contradict the text below which is a preliminary
text to what's mentioned above. Further default for value for this
attribute is "reference" which makes the text seem even more contradictory.

"The querier can express a preference
   for one or the other modality with the 'serviceBoundary' attribute in
   the <findService> request, but the server makes the final decision as
   to whether to return a reference or a value."

 Also, it talks about querier is able to express preference for both 
modality but it doesn't map the value to use for each response. I believe  
that text describing "serviceBoundary=reference indicates request for 
<serviceBoundaryReference>" and "serviceBoundary=value indicates request 
for <serviceBoundary>" should be added. Let's not forget that non-English 
speaker reads these documents too..

 Regards
  Shida 

Hannes Tschofenig wrote:
>> thinking of data structures, where I assumed LoST-04 was 
>> documentation of a protocol. Viewed in that latter light, no matter 
>> how much effort went into the definition of <mapping>, it is just one 
>> information element of just one of the messages in the protocol, and 
>> (I think) should be documented in its proper place relative to that 
>> protocol description.
>>
> There are different ways to write a document and the protocol 
> machinery behind LoST is not complex. Hence, there are a number of 
> element and attribute descriptions.
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Feb 2007 10:18:46 +0100

Hi Shida,

thanks for your review. Please find my response below:

> entity behavior.. So I wonder what's so different with LoST.
To clarify: I mentioned OASIS and SAML in the context of the document 
writing style. Neither SAML nor any other OASIS work is referenced in 
the LoST document.

All I wanted to say is that there are different ways of writing 
documents and the way how "we" write document seems to have changed a 
bit since XML is heavily used in protocols. By "we" I refer to protocol 
designers.

> I can assume it to be true for by-reference case as well but it's not
This needs to be fixed.
> to have this in <serviceBoundary> element section.. It almost feel 
> like there should

Just to make sure that I properly understand you. There are three things 
you could do in a response:
* Include a <serviceBoundary> element
* Include a <serviceBoundaryReference> element
* Include nothing.

Ideally, one might want to return the service boundary in a location 
profile that is understood by the client.
Hence, utilizing the information about location profiles from the 
request seems to be reasonable. Stating something along these lines is 
helpful, I guess.

> > Shouldn't this be "MUST be contained in the response."?
This statement refers to attributes like 'serviceBoundary'.

By setting these attributes the LoST client expresses a preference but 
the LoST server might still decide todo something different, for 
example, because it cannot store references to service boundaries anymore.

I believe that the sentence should be softened to something like:
"
7.3. Components of the <findService> Request

The <findService> request includes attributes that govern whether the 
request is handled iteratively or recursively, whether location 
validation is performed and which elements should be contained in the 
response.
"

> this to be a server but someone creative may think otherwise.
Maybe some additional lines would not hurt in Section 7.3. Something like
* LoST client provides hints want it wants
* LoST server should follow these hints unless there are good reasons 
not todo so.

We don't want to have the LoST server to return an error just because it 
cannot return a reference to a service boundary.
Instead, it might just return nothing or the value.

>   > Some server may always return response without recursion.. As 
> "via" is not
Good catch.

>               which received the recursive query has to add this element.
As noted by several people the <via> element needs more text.

>    (e.g. MUST NOT recuse if the attribute is "false") I find it a bit 
I am not sure whether it is such a big thing whether this statement is 
in this section in a different one (and then which one)

>    so it's a bit more clear. If you are wanting to describe the 
> general semantics of Location
>    to <mapping> element describing general features and 
> characteristics of LoST protocol.
>
It is OK for me to rename Section 7.3.3, 7.3.4, and 7.3.5 as indicated.

> modality but it doesn't map the value to use for each response. I 
> believe  that text describing "serviceBoundary=reference indicates 
> request for <serviceBoundaryReference>" and "serviceBoundary=value 
> indicates request for <serviceBoundary>" should be added. Let's not 
> forget that non-English speaker reads these documents too..
I will add the text.

The general concept expressed in this Section 7.3.4 is what we would 
like to have. Maybe the sentence
"Servers SHOULD NOT return a by-value service boundaries if the querier 
requested a reference. "
could be changed into
"It is RECOMMENDED that LoST servers follow the preference of the LoST 
clients indicated in the query."

Ciao
Hannes

>>> how much effort went into the definition of <mapping>, it is just 
>>> one information element of just one of the messages in the protocol, 
>>> and (I think) should be documented in its proper place relative to 
>>> that protocol description.
>>>

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 27 Feb 2007 08:25:16 -0500

I note that recursion has come up in the discussion again. I myself 
found the text on recursion confusing and apparently contradictory.

I haven't returned to detailed review, but my general impression was 
that the message-specific sections on recursion should refer to section 
4 and not repeat material covered there. This would improve consistency.

...

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Feb 2007 19:59:21 +0100

We are working on next draft version. I hope to have something for you 
to look at very soon. The tentative version can be found here:
http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/

Ciao
Hannes

Tom-PT Taylor wrote:
> that the message-specific sections on recursion should refer to 
> section 4 and not repeat material covered there. This would improve 
> consistency.
>
> Hannes Tschofenig wrote:
>> Hi Shida,
>>
> ...

---

From: Shida Schubert <[email-masked]>
Date: Tue, 27 Feb 2007 12:05:32 -0800

Hi Hannes;

 Thanks for prompt response, more comments inline..

Hannes Tschofenig wrote:
> Just to make sure that I properly understand you. There are three 
> things you could do in a response:
 As noted in the text that reference the draft, one would perceive that 
"serviceboundary" is always included.
If the server can include nothing then the statement above should be 
changed to reflect this fact. I just don't know
how caching would work if there is no serviceboudary.. But as caching is 
out of scope of this document, I guess that's irrelevant.
>
>>
>>
>> Section 7.3:
>>  It talks about attributes that governs the response and it looks 
>> like there is
 I am okay with this as long as something is clarified about what it 
means to the client when
it asks for a particular information and it does not get returned.
 > I guess currently as you stand it could have two semantics.
   > 1. Doesn't support it.
   > 2. Can't provide the information currently but support it.

> We don't want to have the LoST server to return an error just because 
> it cannot return a reference to a service boundary.
 I fully agree with your concern about LoST server returning an error 
just because it lacks support
for something or can't compute something at that given time. As long as 
it can return the most important
information(<uri>) I think it should.

> As noted by several people the <via> element needs more text.
 Looking forward to see the revised text.
>>    recursive which asks the server to recurse.), it has normative 
>> text for the server.
 It isn't a big deal. But the way it's written currently, it doesn't 
provide a clear borderline between
its semantics in request and response. It would be nice if you can 
clarify the text so the
semantics of the element in request and response is clarified.
> "Servers SHOULD NOT return a by-value service boundaries if the 
> querier requested a reference. "
> could be changed into
 I like the revised text.
>>>> one information element of just one of the messages in the 
>>>> protocol, and (I think) should be documented in its proper place 
>>>> relative to that protocol description.
>>>>
>>> If you take a look at OASIS documents that are full of XML stuff 
>>> then you will notice a very similar document style.
>>>
>>> Ciao
>>> Hannes
>>>
>>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 27 Feb 2007 18:09:26 -0500

Just some selective comments:

> As noted in the text that reference the draft, one would perceive  
> that "serviceboundary" is always included.
> If the server can include nothing then the statement above should  
> be changed to reflect this fact. I just don't know
> how caching would work if there is no serviceboudary.. But as  
> caching is out of scope of this document, I guess that's irrelevant.

I agree that caching would not work in general; this should be noted.  
Note that a server that doesn't have service boundaries can always  
return the query location itself as a service boundary. This isn't  
too useful for geodetic coordinates (since the likelihood of getting  
the exact same query again is zero), but modestly useful for civic  
coordinates.

>   > 2. Can't provide the information currently but support it.

It can mean any of these things, in addition to "I don't like the way  
you look and I'm not going to give the data to you" or "It's Friday  
afternoon, and I'm too lazy to bother".

I don't think we want to distinguish these cases; from a client  
perspective, it doesn't matter and it is unclear what is really means  
to "support" a feature, but not be able to return an answer. I don't  
much care if the LoST server software has a particular feature, but  
the feature was disabled or the data necessary for the feature isn't  
available. We are not a jury trying to determine the motive for a crime.

Henning

---

From: Shida Schubert <[email-masked]>
Date: Tue, 27 Feb 2007 15:40:05 -0800

Hi Henning;

 My comments inline..

Henning Schulzrinne wrote:
>> how caching would work if there is no serviceboudary.. But as caching 
>> is out of scope of this document, I guess that's irrelevant.
>
> return the query location itself as a service boundary. This isn't too 
> useful for geodetic coordinates (since the likelihood of getting the 
> exact same query again is zero), but modestly useful for civic 
> coordinates.
>
 Yes that could work at least for civic coordinate. So are you saying 
you want to keep the following statement as is?

 "The response MUST contain at least one service boundary using the same 
profile as the request."
> available. We are not a jury trying to determine the motive for a crime.
 I envisioned people implementing a smart(dumb?) querier which changes 
its query and information it asks for
based on the response it got from the server(logs the capabilities of 
resolver). For example, the resolver receiving
no validation may decide to ask for no validation(Don't ask me why..) in 
the next query it sends. But come to
think of it, either ways its quite harmless so you are right the 
clarification is probably unnecessary.

 Regards
  Shida

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 28 Feb 2007 04:30:07 -0500

> Yes that could work at least for civic coordinate. So are you  
> saying you want to keep the following statement as is?
>
> "The response MUST contain at least one service boundary using the  
> same profile as the request."
>>

Yes. We may want to add

(Without a service boundary, responses cannot be cached. If no other  
service boundary is known, the response MAY contain the query location.)

Henning