Re: [decade] Remote Get Object Message

["Rahman, Akbar" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf
Of Woundy, Richard
Sent: Friday, March 30, 2012 10:37 AM
To: [e-mail]
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