Subject: RE: Start on OPES protocol work

From: jfcm <[email-masked]>
Date: Sat, 15 Feb 2003 15:51:54 +0100

I am quite disturbed by the lack of modelization of all this. I do not 
really understand what an OPES means to be as I understand it starts as a 
very general process (modification of the data flow) but limited to a 
peripheral architecture (edge) and to a very limited set of protocols.

My personal reading of this is that OPES belong to what I call for years 
"open network extended services" (ONES) that I specified, operated and/or 
sold some for nearly 20 years over various environments (pubic net, X.25, 
Minitel, fax..).

The notion of callout protocol is exciting because it permits to 
standardize things I ran on a per application basis and to interoperate 
with third party services.

But I am afraid that lack of modelization (where does all that fit in the 
OSI or an extended OSI model) leads to some confusion between different layers.

I suppose everyone will accept I suppose there are at least two global 
layers involved;

- a layer concerned by the object transportation aspects (I suggest 
Hardware + layers 1-7 OSI)
- a layer concerned by the interapplication levels and above (operators, 
decisions, etc) (I suggest above OSI)

To respond to your suggestion I would suggest:

1. we take advantage from the different propositions (XML, SOAP, ...) to 
understand what the web service (and others) layer provides making a 
difference between what is common to all of them ...

2. and we take advantage from the features each of them to decide if
     - it is something we would expert from the other too (so it should be 
added to the socket)
     - of if this is something something belonging to the callout protocol 
level.

3. from then on we can list all what they contributed to what is specific 
to a callout protocol and what is missing both in a strict OPES environment 
- and in the more global ONES environment (what should help us not to miss 
possible extensions).

This should result in a fairly good description of
- which "transport" protocols are possible to use
- how to plug them in
- what some protocol should support to become OPES compatible.
- the specification for any compact or more specific inter-ONES 
transportation protocol

- the description of the callout specific functions.

Let take the two maximum cases Hilarie and you consider:
- two CPU interacting together under QNX in the same rack
- two web services by different operators on different continents through 
the internet

SOAP may not be the best solution in the first case but mandatory in the 
second one. Yet the metadata to be exchanged to perform the service will be 
the same (except that dialog/signaling will demand probably a 
synchronization adapted to each). Telematic synchronization/decoupling of 
the applications will probably be a very important issue in all this.

To come back on performance related points, I suppose it may be more 
complex than just hardware considerations - two examples:

1. we will need to "receive" information that have not been sent.  Very 
simple example: every page of a site has a gif logo which may have to be 
changed in jpeg. The protocol should be able to say "I do not transmit a 
data you will read where I told you to store it" and to handle the error 
case and verifications..

2. we should be able to zap data. Example: a security control center 
becomes overloaded by the data pouring in from a blown-up plant. An OPES 
extracts and format data for the remote controller of a door. Delayed infos 
tell that the door flaps. The system reacts adding to the traffic, while 
there may not be any door anymore. All that junk information should have 
been zapped.

jfc

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.454 / Virus Database: 253 - Release Date: 10/02/03

---

From: "Martin Stecher" <[email-masked]>
Date: Mon, 17 Feb 2003 12:00:12 +0100

> 
> Hello Martin,
> 
> I guess that a server could also end a transaction early for security
> reasons...say, wouldn't sequence numbers + handshake + timers 
> policy ala TCP
> take care of this. It seems to me ( if I captured your 
> thoughts right) kind
> of the same problem we have in TCP when one end closes a 
> connection and
> there are still packets in flight.
> 
> regards,
> 
> Reinaldo

Hi Reinaldo,

the sequence number helps if we can also settle these requirments:

- each application message's fragment comes with its own sequence number

- there is a way to determine that a new sequence for a new callout
  transaction on the same callout connection starts, e.g. by also
  assigning a second sequence number to callout transactions.

(This is the "channels" concept? Or didn't I get it still?)

The important difference to TCP is that we want to finish a transaction
but keep the connection alive.

Regards
Martin

---

From: "Abbie Barbir" <[email-masked]>
Date: Mon, 17 Feb 2003 13:58:43 -0500

hilarie,
yes indeed.

abbie

> -----Original Message-----
> From: The Purple Streak, Hilarie Orman [mailto:[email-masked]] 
> Sent: Monday, February 17, 2003 1:24 PM
> To: Barbir, Abbie [CAR:1A00:EXCH]
> Cc: [email-masked]
> Subject: RE: Start on OPES protocol work
> 
> 
> My bookmarks are of the form: www.ietf-opes.org/index.htm.  
> This does not get transparently redirected, it gets 
> translated to 
> http://standards.nortelnetworks.com/opes/index> .htm/index.htm 
> and that gets a 404 error.  If Nortel would 
> update the DNS records for ietf-opes.org through the 
> registrar, the domain would work as it did before.
> 
> Hilarie
> 
>

---

From: "Martin Stecher" <[email-masked]>
Date: Tue, 18 Feb 2003 16:40:03 +0100

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

> From: Andre Beck [mailto:[email-masked]]
> Sent: Tuesday, February 18, 2003 1:01 AM
> To: Martin Stecher
> 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
> 
>