ietf-openproxy
[Top] [All Lists]

RE: Start on OPES protocol work

2003-02-18 08:43:10

Hi Andre,

I think that the channel concept meets all requirements
from section 3.4. The general channel concept may even
be exactly what we have in 3.4. 

There is one detail in the channel concept in BEEP that I
find so important that I like to repeat it because I don't
see that we have a real requirement for it in the draft:

Due to the sequence number, channel number and message size
all given in the header of each message, the concept strictly
implies that every fragment of an application message is sent
within its own message.

Example:
If a HTTP message is received in chunked encoding and the OPES
processor wants to forward some first chunks while the rest
did not yet arrive, it has to use a complete message which ends
after this first HTTP message part.
Later chunks that are received come within their own callout
message.

This way, a multiple preview concept and implementations that
are not susceptible to the out-of-sync problem become easy.

Do you share this view? 
Do you agree with me that this is an important feature we have
to add to the OPES protocol?

Regards
Martin

-----Original Message-----
From: Andre Beck [mailto:abeck(_at_)bell-labs(_dot_)com]
Sent: Tuesday, February 18, 2003 1:01 AM
To: Martin Stecher
Cc: ietf-openproxy(_at_)imc(_dot_)org
Subject: Re: Start on OPES protocol work


Hi Martin,

draft-ietf-opes-protocol-reqs-03 does not mention the 
"channels", does it?

The -03 version of the draft refers to them as callout 
connections (see 
section 3.4 of the draft). I believe the callout connection 
concept as 
described in the draft is very similar to the channel concept in BEEP.

-Andre



<Prev in Thread] Current Thread [Next in Thread>