Subject: RE: OCP transport nomination

From: "Martin Stecher" <[email-masked]>
Date: Mon, 5 May 2003 12:24:02 +0200

It got quite on this.

Does this mean that everybody feels just fine with BEEP?
No other nominations?
No OCPTRAN?
No more arguments?

Although BEEP seems to be a very good candidate to build OCP on,
I am still not convinced that it is the best choice.
I have little to no technical argumentation for this; it is more
personal gusto and ICAP support.

If we compare the work that needs to be done to adjust BEEP for OCP
plus the XML burdon that every implementor has to take with the
work that we'd need to do to define another transport protocol, is
there a huge difference?

As you know, I would like to see something that could be called
ICAP/2.0.
So maybe something that takes all the good elements of BEEP but
looks different, for example establishing a channel could look
like this:

	C:OPEN icap://my-OPES-service.org/translate ICAP/2.0
	C:Channel: 1
	C:
	S:ICAP/2.0 200 Channel Established
	S:Channel: 1
	S:
	
Regards
Martin

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]]
> Sent: Thursday, April 24, 2003 5:41 PM
> To: [email-masked]
> 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 Hilarie's
> OCPTRAN.  Let's move this discussion to a closure. OCP work cannot
> proceed much further without the transport selection.
> 
> Thank you,
> 
> Alex.
>

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 5 May 2003 10:36:23 -0600 (MDT)

> Does this mean that everybody feels just fine with BEEP?

Personally, I am waiting for feedback from others. Hilarie mentioned
OCPTRAN once, but has not provided any details/arguments since. I do
not want to spend time detailing OCPTRAN if nobody backs it. If
Hilarie argues for OCPTRAN and/or this discussion drives you towards
OCPTRAN, then there will be somebody backing it...

> Although BEEP seems to be a very good candidate to build OCP on, I
> am still not convinced that it is the best choice. I have little to
> no technical argumentation for this; it is more personal gusto and
> ICAP support.
>
> plus the XML burdon that every implementor has to take with the work
> that we'd need to do to define another transport protocol, is there
> a huge difference?

If two "average" OCP implementors start from scratch, I do not expect
a huge difference in implementation effort of OCP/BEEP versus
OCP/OCPTRAN. BEEP implementations will benefit from the existing code
and expertise, even if they do not use that code directly. OCPTRAN
implementors will benefit from a simpler, domain-specific protocol and
may benefit from existing ICAP code/expertise if OCPTRAN is similar to
ICAP.

I think a big difference is in supporting things like transport
encryption (e.g., TLS) and similar add-ons that BEEP gives us, the
protocol writers, for "free". It would take us a while to document
those things in OCPTRAN (or we would have to leave them unspecified
for the first version of the protocol). It would take implementors a
while to implement them without having much experience/code out there.

> As you know, I would like to see something that could be called

Political issues aside, I think it is possible to call OCP "ICAP/2.0"
regardless of the transport protocol choice. We are doing the same
conceptual thing ICAP does. Transport is just a low-level detail.

> looks different, for example establishing a channel could look like
> this:
>

Possible, if we are OK with losing existing BEEP support for session
encryption.

Also, one good thing about BEEP messages is that they all have a
known, easily-available size (encoded as an integer value in the first
line of a message). The above looks similar to HTTP and loses the
known-size advantage. The size can be added as a "Content-Length"
header, of course, but you have to parse a lot more to get to that.
Alternatively, we can add size to the first line and lose similarity
with ICAP/HTTP.

I think what we need to understand is whether you do not want BEEP
just because it uses XML or because it does not look like ICAP/HTTP.
Once we know the true obstacle, we can try to see how BEEP can be
modified to remove that obstacle.

For example, it is probably possible to define OCPTRAN as "XML-less"
BEEP while providing a simple BEEP-to-OCPTRAN conversion and, hence,
reusing (redefining without much effort) most of the existing BEEP
work. This approach would be similar to, say, binary XML that exist
for wireless protocols (binary XML gets virtually all the advantages
of XML but uses different representation for various performance
reasons).

Similarly, we can "convert" BEEP to HTTP-like BEEP.

Comments?

Alex.

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Mon, 5 May 2003 13:19:19 -0600

I'm trying to work my way through the issues here.  

Where is the definition of the TLS profile for BEEP?

There have been alllusions to XML licensing issues.  What are they?

Hilarie

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 5 May 2003 13:47:31 -0600 (MDT)

> Where is the definition of the TLS profile for BEEP?

See RFC 3080 (Sections 3.1 and 7.2, at least):

	<profile uri="http://xml.resource.org/profiles/TLS">
	   <ready />
	</profile>

> There have been alllusions to XML licensing issues.  What are they?

I am not aware of any; can you be more specific? If BEEP (an IETF
protocol) uses XML, we should be safe to do so, I guess.

Alex.

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Mon, 5 May 2003 14:22:17 -0600

Please show me how to use the URI to find the document.  I can use it to
find "404", but then, lots of things can find "404".

>	   <profile uri="http://xml.resource.org/profiles/TLS">

In this message you referred to "the MIT license"; what did you mean?

  From: Alex Rousskov <[email-masked]>
  To: [email-masked]
  Subject: Re: BEEP as OCP transport
  Date: Thu, 17 Apr 2003 12:22:09 -0600 (MDT)
  In-Reply-To: <[email-masked]>
  Message-ID: <[email-masked]>

---

From: Marshall Rose <[email-masked]>
Date: Mon, 5 May 2003 13:40:45 -0700

[ speaking as beep guy ... ]

> > ...

there is a school of thought that URIs can be used to uniquely-identify things,
and that those things don't necessarily have to be available via the web.

if you read 3080, it will tell you what to do when someone tries to start a
profile with the above-mentioned URI.

> In this message you referred to "the MIT license"; what did you mean?

a lot of open source stuff is published under an "the MIT license". although
i'm sure that lots of folks claim intellectual property rights with
respect to doing nifty things with xml, the actual 1.0 specification
itself, as far as anyone reasonably knows, is unencumbered.
    
/mtr

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Mon, 5 May 2003 15:49:46 -0600

OK, then there's no specification of the user-BEEP API for using TLS.
What support do the implementations of BEEP provide?  How are the
cryptographic preferences for each TLS connection specified?  My point
being that it would seem pretty easy for an OCPTRAN API implementor to
set up things in such a way that the user was responsible for opening
the correct kind of TLS connection and then passing the handle to it
to OCPTRAN.

Hilarie

---

From: Marshall Rose <[email-masked]>
Date: Mon, 5 May 2003 15:18:55 -0700

[ speaking as the beep guy... ]

> OK, then there's no specification of the user-BEEP API for using TLS.
    
there is no specification of the user-BEEP API for XYZ, regardless of
the value of XYZ.

> the correct kind of TLS connection and then passing the handle to it

isn't that sort of stuff up to each implementor? isn't the job of the
specification suppose to say things like what options are allowed,
without mandating a particular api, calling convention, etc.?
    
/mtr

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 5 May 2003 23:10:56 -0600 (MDT)

On Mon, 5 May 2003, The Purple Streak, Hilarie Orman wrote:

> My point being that it would seem pretty easy for an OCPTRAN API
> implementor to set up things in such a way that the user was
> responsible for opening the correct kind of TLS connection and then
> passing the handle to it to OCPTRAN.

This is probably true and smells similar to how HTTP can be wrapped in
TLS/SSL. Still, we would have to write some documents explaining how
TLS or other encodings are applied/negotiated/configured in OCP
context. BEEP folks did that legwork for us.

Alex.