sounds like a fair proposal.
Hilarie, can u give an example
Alex, same toy you.
ps: SOAP is out so no work for me
> -----Original Message-----
> From: Martin Stecher [mailto:martin.stecher@xxxxxxxxxxxxx]
> Sent: Thursday, April 24, 2003 12:40 PM
> To: Alex Rousskov; ietf-openproxy@xxxxxxx
> Subject: RE: OCP transport nomination
> could you already give some real life examples how OCP over
> BEEP will look like?
> I am not sure how much XML and Content-Type statements will
> be necessary to be BEEP compatible.
> While I like many of the BEEP concepts and agree that they
> are very useful for OCP, I am not sure that I will like the
> protocol's look and feel. This may change by seeing a real
> example, or it will encourage me to create an alternate proposal ;-)
> That's why I am also very interested how OCPTRAN could look like.
> > -----Original Message-----
> > From: Alex Rousskov [mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx]
> > Sent: Thursday, April 24, 2003 5:41 PM
> > To: ietf-openproxy@xxxxxxx
> > Subject: OCP transport nomination
> > I would like to nominate BEEP as the only OCP transport. My primary
> > reasons for nominating BEEP are:
> > - reuse of BEEP negotiation capabilities for
> > transport encryption and such
> > - availability of efficient transfer for
> > opaque ("binary") data
> > There are several issues that we would need to resolve if BEEP is
> > selected by the group (e.g., selecting BEEP message
> exchange model and
> > defining OCP message encoding), but I would like to hear other
> > protocol nominations (Hilarie?) or any objections to BEEP before
> > discussing BEEP-specific details.
> > I hope I am not making a mistake by giving BEEP a preference over
> > SOAP. I would really like to use SOAP because that is what web
> > services world is using, and we are doing something very similar.
> > Unfortunately, SOAP suffers from a legacy of being started
> as an RPC
> > protocol and has no standard way of handling large opaque data
> > [efficiently]. If BEEP is selected, we would essentially trade
> > "efficient transfer" for "current deployment". I hope that is the
> > right choice, especially since SOAP can still be used as another
> > callout protocol in environments where efficient transfer is not
> > important. If you think otherwise, please speak up now.
> > We have talked about all known transport candidates except
> > OCPTRAN. Let's move this discussion to a closure. OCP work cannot
> > proceed much further without the transport selection.
> > Thank you,
> > Alex.