Subject: RE: Capability Negotiation for OCP

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 17 Apr 2003 14:42:41 -0700

Hilarie

That's how SDP's offer/answer work and its one of its disadvantages. The
authors themselves indicate that in RFC3264.

"
Since SDP has no way to indicate that the message is for
   the purpose of capability indication, this is determined from the
   context of the higher layer protocol.  The ability of baseline SDP to
   indicate capabilities is very limited.  It cannot express allowed
   parameter ranges or values, and can not be done in parallel with an
   offer/answer itself.  Extensions might address such limitations in
   the future."

That's why I extended a little bit by adapting some ideas from PPP. 

Regards,

Reinaldo

> -----Original Message-----
> From: The Purple Streak, Hilarie Orman [mailto:[email-masked]] 
> Sent: Thursday, April 17, 2003 4:53 PM
> To: Penno, Reinaldo [BL60:0430:EXCH]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Capability Negotiation for OCP
> 
> 
> "Channel" and "device" are not terms of reference that I've 
> seen for OPES before.  What are they, how do they relate to 
> the architecture?
> 
> Why aren't two messages ("menu offer" and "menu selection") 
> sufficient? Many IETF protocols use this method and live happy lives.
> 
> Hilarie
>

---

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

Oskar,
 
We can not decide on BEEP now.
We have to eliminate other candidates like SOAP first.
Basically, u r right, this is only a Pause.

Abbie

-----Original Message-----
From: Oskar Batuner [mailto:[email-masked]] 
Sent: Monday, April 21, 2003 9:35 AM
To: Barbir, Abbie [CAR:1A00:EXCH]; Alex Rousskov; [email-masked]
Subject: RE: Capability Negotiation for OCP

Did 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, 
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 

> From: Alex Rousskov [mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Thursday, April 17, 2003 2:58 PM 
> To: [email-masked] 
> 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: "Abbie Barbir" <[email-masked]>
Date: Mon, 21 Apr 2003 11:01:18 -0400

Alex,
agreed,

abbie

> From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Monday, April 21, 2003 11:00 AM
> 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.
>