Re: [decade] Remote Get Object Message

[Richard Alimi <[e-mail]>]

I'm late to the game, but I agree that using the proxy concept for
remote-get and standard (simple) operations for the others seems
pretty clean.

Rich

On Tue, Apr 17, 2012 at 7:23 PM, Songhaibin <[e-mail]> wrote:
> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
> Rahman, Akbar
> Sent: Tuesday, April 03, 2012 9:55 PM
>
>
> To: Woundy, Richard
> Cc: [e-mail]
> 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
>
>
>
>
>
>
>
> From: Woundy, Richard [mailto:[e-mail]]
> Sent: Monday, April 02, 2012 3:53 PM
> To: Rahman, Akbar
> Cc: [e-mail]; 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
>
>
>
> From: Rahman, Akbar [mailto:[e-mail]]
> Sent: Friday, March 30, 2012 8:40 PM
> To: Woundy, Richard
> Cc: [e-mail]
> 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: [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> and
> <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