Subject: Re: [decade] Remote Get Object Message

From: "Woundy, Richard" <[email-masked]>
Date: Mon, 2 Apr 2012 19:53:26 +0000

> However, I guess this model breaks down if we are required to support a use case where "DECADE server-1" wants to exchange content with "DECADE server-2" without being triggered by a client.

Yes I would tend to agree. One *could* make this look like a proxy case by forcing server-1 to act as its own proxy, but that seems inelegant.

But then I would imagine that server-1 could obtain content from server-2 using a simple HTTP GET, and could push content to server-2 using a simple HTTP POST, right? We still wouldn't need a new X-DECADE-ORIGIN header or a new HTTP message, right?

-- Rich

From: Rahman, Akbar [mailto:[email-masked]]
Sent: Friday, March 30, 2012 8:40 PM
To: Woundy, Richard
Cc: [email-masked]
Subject: RE: [decade] Remote Get Object Message

Hi Rich,

I agree that using a classic HTTP GET request (instead of a new modified POST) to implement the "DECADE-compatible Remote Get Object" message is a good approach.

I also like your proposal for the local DECADE server to act as a non-transparent proxy when processing a request from a client.   (I.E. Client makes a request to "DECADE server-1" which then acts as a proxy by forwarding the request to "DECADE server-2").

However, I guess this model breaks down if we are required to support a use case where "DECADE server-1" wants to exchange content with "DECADE server-2" without being triggered by a client.

Do you agree?

Akbar

From: [email-masked] [mailto:[email-masked]] On Behalf Of Woundy, Richard
Sent: Friday, March 30, 2012 10:37 AM
To: [email-masked]
Subject: [decade] Remote Get Object Message

Folks,

In Thursday's session, we discussed how to implement the Remote Get Object message. One proposal is to use HTTP Post with a new X-DECADE-ORIGIN header; another proposal is to define a new HTTP message. See slide 3 of <http://www.ietf.org/proceedings/83/slides/slides-83-decade-4.pdf<http://www.ietf.org/proceedings/83/slides/slides-83-decade-4.pdf%3c>> and <http://tools.ietf.org/html/draft-wang-decade-drp-03#section-8<http://tools.ietf.org/html/draft-wang-decade-drp-03#section-8>>>.

My thought (as an individual contributor, not as co-chair) is to use existing HTTP Get headers and leverage the base functionality of an HTTP caching proxy in DECADE. The local "DECADE" server would act as a caching proxy (with additional functionality of course) in order to reach the remote "DECADE" server, and cache the contents of the reply in the "DECADE" storage. I have a "non-transparent proxy" behavior in mind, per the definition of "proxy" in RFC 2616 (http://tools.ietf.org/html/rfc2616#section-1.3). Also see <http://tools.ietf.org/html/rfc2616#section-13>, <http://tools.ietf.org/html/rfc3040>, and perhaps <http://tools.ietf.org/html/rfc3143> as well.

Did we fully explore this possibility? As a co-chair, I can assure you that it would be much better to leverage existing protocols and standards, versus inventing new ones.

-- Rich

---

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 3 Apr 2012 09:55:16 -0400

Hi Rich,

Yes, that is a good point.  I agree that for server-server
communications (without a client involved) then standard HTTP GETs, PUTs
and POSTs could be used without need for new headers or methods.

Akbar

From: Woundy, Richard [mailto:[email-masked]] 
Sent: Monday, April 02, 2012 3:53 PM
To: Rahman, Akbar
Cc: [email-masked]; Woundy, Richard
Subject: RE: [decade] Remote Get Object Message

> However, I guess this model breaks down if we are required to support
a use case where "DECADE server-1" wants to exchange content with
"DECADE server-2" without being triggered by a client.

Yes I would tend to agree. One *could* make this look like a proxy case
by forcing server-1 to act as its own proxy, but that seems inelegant.

But then I would imagine that server-1 could obtain content from
server-2 using a simple HTTP GET, and could push content to server-2
using a simple HTTP POST, right? We still wouldn't need a new
X-DECADE-ORIGIN header or a new HTTP message, right?

-- Rich

Hi Rich,

I agree that using a classic HTTP GET request (instead of a new modified
POST) to implement the "DECADE-compatible Remote Get Object" message is
a good approach.

I also like your proposal for the local DECADE server to act as a
non-transparent proxy when processing a request from a client.   (I.E.
Client makes a request to "DECADE server-1" which then acts as a proxy
by forwarding the request to "DECADE server-2").

However, I guess this model breaks down if we are required to support a
use case where "DECADE server-1" wants to exchange content with "DECADE
server-2" without being triggered by a client. 

Do you agree?

Akbar

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Woundy, Richard
Sent: Friday, March 30, 2012 10:37 AM
To: [email-masked]
Subject: [decade] Remote Get Object Message

Folks,

In Thursday's session, we discussed how to implement the Remote Get
Object message. One proposal is to use HTTP Post with a new
X-DECADE-ORIGIN header; another proposal is to define a new HTTP
message. See slide 3 of
<http://www.ietf.org/proceedings/83/slides/slides-83-decade-4.pdf
<http://www.ietf.org/proceedings/83/slides/slides-83-decade-4.pdf%3c> >
and <http://tools.ietf.org/html/draft-wang-decade-drp-03#section-8
<http://tools.ietf.org/html/draft-wang-decade-drp-03#section-8>> >.

My thought (as an individual contributor, not as co-chair) is to use
existing HTTP Get headers and leverage the base functionality of an HTTP
caching proxy in DECADE. The local "DECADE" server would act as a
caching proxy (with additional functionality of course) in order to
reach the remote "DECADE" server, and cache the contents of the reply in
the "DECADE" storage. I have a "non-transparent proxy" behavior in mind,
per the definition of "proxy" in RFC 2616
(http://tools.ietf.org/html/rfc2616#section-1.3). Also see
<http://tools.ietf.org/html/rfc2616#section-13>,
<http://tools.ietf.org/html/rfc3040>, and perhaps
<http://tools.ietf.org/html/rfc3143> as well.

Did we fully explore this possibility? As a co-chair, I can assure you
that it would be much better to leverage existing protocols and
standards, versus inventing new ones.

-- Rich

---

From: Songhaibin <[email-masked]>
Date: Wed, 18 Apr 2012 02:23:54 +0000

I also agree with that using standard HTTP GET and POST can be better for remote get behavior and server to server data communication than inventing new headers. I also agree with the non-transparent proxy concept.

BR,
-Haibin (as contributor)

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rahman, Akbar
Sent: Tuesday, April 03, 2012 9:55 PM
To: Woundy, Richard
Cc: [email-masked]
Subject: Re: [decade] Remote Get Object Message

Hi Rich,

Yes, that is a good point.  I agree that for server-server communications (without a client involved) then standard HTTP GETs, PUTs and POSTs could be used without need for new headers or methods.

Akbar

-- Rich

Hi Rich,

Do you agree?

Akbar

Folks,

-- Rich