Subject: [Ecrit] Construction of LoST findService response path element?

From: Larry Reeder <[email-masked]>
Date: Tue, 18 Oct 2011 16:51:41 -0600

We've got a question regarding the construction of the path element in
the LoST findServiceResponse.

Consider the simple case where the first server contacted by the
client is the authoritative server.  RFC-5222 says this about path
construction:

"The server that answers the request instead of forwarding it, such as
the authoritative server, copies the <path> element verbatim into the
response.  The <path> element is not modified in responses as the
responses traverses the server chain back to the querying client."

In my reading, this paragraph says the LoST client (or any LoST
servers recursing to other LoST servers)  must include the <path> with
a <via> for the server it is contacting in findService, and that the
authoritative server must copy what the client sent into its
findServiceResponse.    However, none of the findService request
examples in RFC 5222 contain a path element, so it's unclear how the
findServiceResponse path element was generated.

Anyone have any guidance on this?

Regards.............                   Larry

-- 
Larry Reeder
EVS Software Team Lead
www.inetwork.com
Office: 303.228.8805
[email-masked]

1855 Blake Street, Suite 101
Denver, CO 80202
inetwork is a division of Bandwidth

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 19 Oct 2011 10:17:17 -0400

Hi Larry,

It seems to me that the answer is contained in the following paragraph:
"
If a query is answered iteratively, the querier includes all servers that it has already contacted.
"
So the first query the client sends goes out without a <path> element, but if the client gets back a redirect, then it adds a <path> to the second query.  For example, if Server1 delegates to Server2 and Server2 is authoritative:

Client->Server1
<findService>...</findService>

Server1->Client
<redirect target="Server2">

Client->Server2
<findService>
  ...
  <path>
    <via>Server1</via>
  </path>
</findService>

Server2->Client
<findServiceResponse>
  <mapping>...</mapping>
  <path>
    <via>Server1</via>
  </path>
</findServiceResponse>

Hope this helps,
--Richard

On Oct 18, 2011, at 6:51 PM, Larry Reeder wrote:

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

---

From: Avery Penniston <[email-masked]>
Date: Wed, 19 Oct 2011 15:20:11 +0000

I had a couple questions/comments to add:

1.) Shouldn't the response in your example also include a via element for the answering server? What happens when the recursion goes more than 1 level deep; how would the original querier know who answered the query?  

<findServiceResponse>
  <mapping>...</mapping>
  <path>
    <via>Server1</via>
    <via>Server2</via>
  </path>
</findServiceResponse>

2.) What if the initial query which contained no path was sent to Server1 and Server1 is the authoritative source? The RELAX NG Schema for LoST indicates that requests can optionally have a path, but responses MUST have one, and the path has ONE or more vias.

My personal opinion is that when a LoST server receives a request it should append the path with its own application unique string before either returning a response, or sending the request on to another LoST server in recursion.  This opinion does go against this line in section 6, "The server that answers the request instead of forwarding it, such as  the authoritative server, copies the <path> element verbatim into the  response."

This could be remedied by changing that line to something like " The server that answers the request instead of forwarding it, such as  the authoritative server, copies the <path> element's <via> elements verbatim into the  response, and appends its own application unique string as the last <via> element."

Perhaps I'm missing something here, but why does the client LoST server in a recursive query need to put the target server's application unique string at the end of the request path before even sending it?  Shouldn't the target server do that?

Avery Penniston 
Software Developer
GeoComm Inc.
601 W. Saint Germain St., Saint Cloud, MN 56301
Office: 320.240.0040 
www.geo-comm.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard L. Barnes
Sent: Wednesday, October 19, 2011 9:17 AM
To: Larry Reeder
Cc: [email-masked]
Subject: Re: [Ecrit] Construction of LoST findService response path element?

Hi Larry,

Client->Server1

Server1->Client

Client->Server2
<findService>
  ...
  <path>
    <via>Server1</via>
  </path>
</findService>

Server2->Client
<findServiceResponse>
  <mapping>...</mapping>
  <path>
    <via>Server1</via>
  </path>
</findServiceResponse>

Hope this helps,
--Richard

---

From: Larry Reeder <[email-masked]>
Date: Thu, 20 Oct 2011 13:42:03 -0600

Hey Richard,

What you say makes sense for an ECRF and client acting in iterative mode,
and is probably the only way for that system to provide loop detection
given the current LoST schema.  Since you can't put path info in a
redirect, it would be up to the client to update the request with path
info.   However, what Avery says still holds for recursive mode.  Given the
examples, the server must put a path in its response, otherwise the
response breaks the schema.

It's true that a client acting in recursive mode could create or update the
path with the ECRF it's about to connect to, and then the authoritative
ECRF could return the path verbatim in its response.  If that's the
recommended approach, the examples should be updated to show this.
However, the intent in the LoST schema seems to be that the server should
maintain the path element. because the request (client) doesn't need to
provide a path, but the response (server) does.

The other problem with expecting the client to maintain the path is that a
misbehaving client could put the invalid ECRF string (or no string) in its
request, leading to an extra node being traversed in a loop situation
because the first ECRF in the loop wouldn't recognize itself in the via
list.

Thanks...............        Larry

On Wed, Oct 19, 2011 at 9:20 AM, Avery Penniston <[email-masked]>wrote:

> 1.) Shouldn't the response in your example also include a via element for
> the answering server? What happens when the recursion goes more than 1
> level deep; how would the original querier know who answered the query?
>
> <findServiceResponse>
>  <mapping>...</mapping>
>  <path>
>    <via>Server1</via>
>     <via>Server2</via>
>  </path>
> </findServiceResponse>
>
>
> 2.) What if the initial query which contained no path was sent to Server1
> and Server1 is the authoritative source? The RELAX NG Schema for LoST
> indicates that requests can optionally have a path, but responses MUST have
> one, and the path has ONE or more vias.
>
>
> My personal opinion is that when a LoST server receives a request it
> should append the path with its own application unique string before either
> returning a response, or sending the request on to another LoST server in
> recursion.  This opinion does go against this line in section 6, "The
> server that answers the request instead of forwarding it, such as  the
> authoritative server, copies the <path> element verbatim into the
>  response."
>
> This could be remedied by changing that line to something like " The
> server that answers the request instead of forwarding it, such as  the
> authoritative server, copies the <path> element's <via> elements verbatim
> into the  response, and appends its own application unique string as the
> last <via> element."
>
> Perhaps I'm missing something here, but why does the client LoST server in
> a recursive query need to put the target server's application unique string
> at the end of the request path before even sending it?  Shouldn't the
> target server do that?
>
>
> Avery Penniston
> Software Developer
> GeoComm Inc.
> So the first query the client sends goes out without a <path> element, but
> if the client gets back a redirect, then it adds a <path> to the second
> query.  For example, if Server1 delegates to Server2 and Server2 is
> authoritative:
>
> Client->Server1

-- 
Larry Reeder
EVS Software Team Lead
www.inetwork.com
Office: 303.228.8805
[email-masked]