Subject: RE: Capability Negotiation for OCP

From: "Abbie Barbir" <[email-masked]>
Date: Mon, 21 Apr 2003 09:06:19 -0400

hi,
how about Authentication/Authorization/encrytption.

how/when these will be negotiated/supported etc.
Are we talking about another encapsulation (like HTTPS or SASL) here or
what?

Abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Thursday, April 17, 2003 2:58 PM
> To: [email-masked]
> Subject: Re: Capability Negotiation for OCP
> 
> 
> 
> 
> On Thu, 17 Apr 2003, Reinaldo Penno wrote:
> 
> > These are my ideas on capability negotiation. They are a 
> mix of SDP's 
> > offer/answer, BGP and PPP.
> 
> Sounds like a great start to me. I am sure we will run into 
> arguments once the wording becomes more specific.
> 
> One high-level thing to consider now is scope (level) 
> definition: Do we want to have a fixed number of levels 
> associated with OCP entities like connection and transaction? 
> Or do we want to allow unlimited nesting? For example, is it 
> possible that something needs to be re-negotiated in the 
> middle of a transaction?
> 
> Another issue: are negotiations always limited in scope to a 
> single transport connection? Are we worried that two 
> connections to the same IP may not end up at the same callout 
> server? In other words, if an OPES processor wants to open 10 
> connections to a callout server, does it need to negotiate 
> each from scratch OR can it refer to earlier
> ("cached") negotiations?
> 
> Semantically, does <offer> describe sender characteristics "I 
> can use Foo" or can it describe sender desires (recipient 
> characteristics) "Please use Foo" as well? For example, how 
> can a callout server change OPES processor copying state from 
> "yes" to "no" in the middle of an OCP connection? Using 
> "Processor-uses-copying" property?
> 
> How is the order of negotiations determined -- what if both 
> OPES processor and callout server send <offer> messages "at once"?
> 
> Finally, can we define a complete set of parameters that MUST 
> be negotiated for OCP Core?
> 
> Let's not spent too much effort on what you call "packet 
> format" now. The choice of transport protocol and encoding 
> will have a major impact on that, I think.
> 
> Thank you,
> 
> Alex.
>

---

From: "Oskar Batuner" <[email-masked]>
Date: Mon, 21 Apr 2003 09:34:49 -0400

RE: Capability Negotiation for OCPDid we have made a decision on BEEP? The
BEEP discussion had no
conclusive end, in fact for me it looks more like a pause. There were
pros and cons discussed, more pros than cons, but no conclusion.

If we are going to adopt BEEP many things will be shaped by that.

Alex, what do you think?

Oskar
  -----Original Message-----
  From: [email-masked]
[mailto:[email-masked]]On Behalf Of Abbie Barbir
  Sent: Monday, April 21, 2003 9:06 AM
  To: Alex Rousskov; [email-masked]
  Subject: RE: Capability Negotiation for OCP

  hi,

  Abbie

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 21 Apr 2003 09:17:12 -0600 (MDT)

On Mon, 21 Apr 2003, Oskar Batuner wrote:

> Did we have made a decision on BEEP?

No.

> The BEEP discussion had no conclusive end, in fact for me it looks
> more like a pause. There were pros and cons discussed, more pros
> than cons, but no conclusion.

The discussion is not over. We now know at least two ways to map OCP
to BEEP. We still need to compare BEEP with other candidates.

> If we are going to adopt BEEP many things will be shaped by that.

Yes, as with any other existing transport protocol. At this time, I
have a more-or-less clear picture of how to map OCP to BEEP. I would
like proponents of other approaches (Abbie for SOAP and Hilarie for
OCPTRAN) to argue their positions, either "in general" or "relative to
BEEP", whatever format they prefer. I tried to ask a few questions
about SOAP and OCPTRAN to facilitate this discussion.

I would also like to hear Martin Stecher's opinion on transport
selection. As ICAP fan, Martin may want to push for HTTP as the
transport to make OCP look like ICAP/2.0. I did say that HTTP is not
ideal transport for OCP, but we have to keep many factors in mind when
selecting the protocol. If we consider SOAP because Web Services use
SOAP, we must consider HTTP because ICAP servers use HTTP.

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 21 Apr 2003 08:59:50 -0600 (MDT)

On Mon, 21 Apr 2003, Abbie Barbir wrote:

> how/when these will be negotiated/supported etc. Are we talking
> about another encapsulation (like HTTPS or SASL) here or what?

It would depend on the transport protocol selection, I think. If the
transport protocol already has mechanisms to support
Authentication/Authorization/encrytption, then those mechanisms should
be reused. IMO, possibility of this kind of reuse would be the primary
advantage of selecting an existing application transport (e.g., BEEP)
compared to new low-level OCPTRAN.

Since so many things depend on the transport now, we need to select
transport(s) as soon as possible.

Alex.