RE: Start on OPES protocol work

["Martin Stecher" <martin.stecher@xxxxxxxxxxxxx>]

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@xxxxxxxxxxxxx]
> Sent: Tuesday, February 18, 2003 1:01 AM
> To: Martin Stecher
> Cc: ietf-openproxy@xxxxxxx
> 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
> 
>