Subject: RE: OCP Core version head_sid6 available

From: "Martin Stecher" <[email-masked]>
Date: Wed, 21 May 2003 12:32:22 +0200

> [...]
> 
> I think this matches your proposal. However, I am worried that if we
> write examples with full names, implementors will start sending them
> on the wire. And if we avoid full names in examples, does it make
> sense to document full names at all? What do you think?
> 
> Perhaps we need a better term for "full name" and "abbreviated name"
> to emphasize that only the latter can appear on the wire?  "Command
> name" and "command code"?
> 

How about just calling the command with its full name and then only refering to the abbreviation as the code in the technical description.
Example

    7.1 The connection-start command

        command code: CS
        anonymous parameters: none
        ...

> [...]
> 
> Also, the named-parameter syntax allows only for one value. Do you
> think we should change that to
> 
> 	anonym-parameters = values
> 	named-parameter = CRLF name ":" values
> 	values = 1*(SP value)
> 
> to better match MIME capabilities? Or is one value per name enough?

Preparing for value lists is a good idea.
But what about using a different list separator character? Comma?
That could also allow to introduce lists as values for anonym-parameters if we'll ever need them.

> [...]

> 
> > If services is an optional xaction-start parameter, why not also
> > make it an optional parameter of connection-start? If OPES processor
> > wants to use the default service for a connection feature, it could
> > set it already with the connection-start message rather than sending
> > an extra connection-services message. Same for connection-priority?
> 
> I agree that the current specs are inconsistent. I am not sure what
> the right fix is though. We can limit support to a dedicated message
> for each state change (e.g., connection-priority) or we can have both
> dedicated messages and message parameters (e.g., priority parameter in
> a connection-start message). Note that dedicated messages are required
> because sometimes you want to change the state in the middle of a
> "process" (e.g., change priority or default services of an existing
> connection).

Can you give me an example where changing of priority or default service is required?

Thanks
Martin

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 21 May 2003 14:56:20 -0600 (MDT)

On Wed, 21 May 2003, Martin Stecher wrote:

> How about just calling the command with its full name and then only
> refering to the abbreviation as the code in the technical
> description.
> Example
>

Would you use "CS" or "connection-start" in the examples? Full names
make examples much more readable and make readers feel like they
immediately know what is going on...

Looking from the other point of view, what are the technical reasons
for NOT allowing full names on the wire? We can probably convince most
developers to use abbreviations while supporting full versions. The
amount of extra code or memory needed to support both versions is
minimal. Are we concerned with extra bandwidth and CPU cycles spent on
handling full versions if some broken implementation sends them?

Or are we primarily concerned that some implementations will end up
recognizing one version (full or abbreviated) and not the other?

Thanks,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 22 May 2003 11:31:26 -0600 (MDT)

Warning: This discussion may seem more complex than it really is.
Existing protocols such as HTTP, SMTP, or SOAP has similar issues but
MIME-based protocols often solve the same problem on a case-by-case
basis instead of defining a consistent solution. Case-by-case
decisions vary slightly, leading to complex and often incompatible
implementations. We are trying to come up with a consistent design,
nothing else.

On Wed, 21 May 2003, Martin Stecher wrote:

> Preparing for value lists is a good idea. But what about using a
> different list separator character? Comma? That could also allow to
> introduce lists as values for anonym-parameters if we'll ever need
> them.

SP can be used to separate positional arguments (if we want to support
them in named-parameters). Let's call positional "structures" because
in a structure, you usually know positions of every member. Comma
should be used to separate list items (if we want to support lists).

Structure: An ordered collection of items. Minimum size is known.
	   Each item usually has a different meaning. Extensions may
	   add items by "appending" them to the end of the collection.

List: An ordered collection of items. Minimum size is zero.
      Each item has the same type and meaning. Extensions are
      not possible (adding more items is the basic building mechanism
      not an extension).

There are several decisions to make:

	1. Should we allow structures?
		result: code phrase

	2. Should we allow lists?
		list: i1,i2,i3

	3a. Should we allow one-level nesting of non-atoms?
		list-of-lists: (i1,(j1,j2,j3),i3)
		list-of-structures: ({x1 y1},{x2 y2},{x3 y3})
		structure-of-lists: {(i1,i2) (x1,x2,x3)}

	3b. Should we allow deeper nesting?
		of-of-of: {({x1 y1},{x2 (y21,y22,y23)},{x3 y3}) b c {d e}}

My current preferences are
	1. yes, but add curly braces: {x y}
	2. yes, but add parens: (i1,i2,i3)
	3. yes, but discourage casual use and limit depth to 3-4 levels.

Arguments regarding structures
------------------------------

	OCP already uses structures for anonymous parameters (or, at
	least, current use can be interpreted that way). Result
	reporting can use a {code prase} structure. Negotiation may
	benefit from structures because they are handy to express
	[min,max] ranges (as a {min max} structure).

	I would like to add curly braces to make structures visually
	explicit and to simplify parsing.

Arguments regarding lists
-------------------------

	OCP already needs lists to represent, for example, a list of
	service IDs to be applied or a list of service IDs that have
	been applied to an application message. Negotiation mechanism
	may benefit from lists of "allowed profiles" as well.

	In my experience, relying on parameter name repetition to
	represent multiple values is error prone because implementors
	forget which name can be repeated or just fail to handle
	repetitions right. We have seen many violations related
	to this technique in HTTP. One name, one (possibly complex)
	value is a better technique, IMO.

	I would like to add parens to make lists visually explicit and
	to simplify parsing.

Arguments regarding nesting
---------------------------

	I would rather not allow nesting, but I have a specific
	example that may require nesting. I expect more examples
	like that will crop up later.

	During negotiations, a processor needs to offer a list of
	"profiles" to the callout server. Each profile is a
	{feature-id parameters} structure. The server may not
	be able to make a selection (select the best profile)
	without seeing the entire list first. We have two
	options to implement this:

	a) multiple messages with a special grouping mechanism:
		P: group-start;
		P: offer profile1;
		P: offer profile2;
		P: offer profile3;
		P: group-end;

		S: ack profile2;

	b) allow nesting:
		P: offer (profile1,profile2,profile3);
		S: ack profile2;

	Clearly, option (b) is much more natural. From implementation
	point of view option (a) is likely to be supported using
	some kind of profile list anyway. However, with (a) we
	have a lot more implicit state to worry about.

	On the other hand, if we allow nesting, then the job of
	skipping irrelevant/unsupported parameters will be more
	difficult. This is especially true if we allow multiple
	levels of nesting. That is why I would recommend limiting
	nesting levels at 3 or 4: MUST support N levels and MUST
	treat more than N levels as syntactically invalid.

Resulting syntax
----------------

	anonym-parameters = SP value
	named-parameters = 1*named-parameter
	named-parameter = CRLF name ":" SP value

	value = integral / structure / list
	integral = bare-value / quoted-value
	structure = "{" *(SP  value) "}"   ; spaced values
	list =      "(" *("," value) "}"   ; comma-separated values

Examples
--------

	connection-start;
	i-am-here {};
	i-am-here {xid};
	i-am-here {xid amid};
	offer ({url1 p1},{url2 p21 p22 p23});
	ack {url1 p1};

Please comment.

Thank you,

Alex.

---

From: jfcm <[email-masked]>
Date: Fri, 23 May 2003 16:55:05 +0200

I come across the following customer request. I think it may help checking 
OCP can be used and can support this.

There are four systems involved.
1. A: an automated system (oil station pump)
2. B; a remote management station
3. C: a considered ticketing service
4. D: a possible OPES

B polls A once a day
When A has an incident it calls B.
But B is management not support

So the idea is D as an OPES between A and B branching into C via OCP.

1. when A has a problem, the call is blocked by D and C is told.
2. C manages the incident (may take hours)
3. when the incident has been repaired, C can authorize D to forward the 
call as "treated".

I would like to understand if all this is orthodox as far as OCP which will 
be used between D and C.

1. is there a problem about qualifying this as an OPES?

2. A only knows to say "I have a problem" and to report its status upon 
request from B (IP address) and respond.

     D's IP would replace B's IP in A table. So the dialog would actually 
be A-D.
     So, if B and C call, D should make the calls coming from D.

     there are three reasons to call A:

     - normal administrative calls by B
     - calls by D when receiving the alarm: to check the reason of the call 
(D may decide to discard if it is a repetitive call)
     - calls be C: as part of the ticketing status control and reporting to 
technicians

     Calls by D and C are part of the OPES service. Is that dialog with the 
caller permitted?

3. there would be a need for a multiple "continuations" of A calls to be 
received by B.

     Sequence:
     - A calls to say I have a problem : this is the data transmitted that 
is going to be modified.
     - B should receive that data as a continuity of different blocks, may 
be over hours
       - 1st block: there is an alarm info to follow
       - 2. this alarms has been taken over by the ticketing service
       - 3. the ticketing service may pass different reports
       - 4. report "the problem has been addressed as follows: ...."

4. what is also interesting is that A, B, D are in the same domain of 
security While C is an externalized service. So OCP relations would have to 
be secure. Also, C may change into C1, C2, etc as the complexity/type of 
incident management is handled.

Thank you.
jfc

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 23 May 2003 10:43:11 -0600 (MDT)

Jfc,

	Here is my interpretation of the primary part of your problem:

	A emits messages using format/protocol pA
	A is configured to talk D as its "next hop" for pA

	B is interested in A's state but understands
	  (or prefers) messages in format/protocol pB, not pA

	D accepts messages in pA from A,
	D adapts messages in pA to messages in pB, possibly using C,
	D forwards adapted messages (in pB) to B

	C is in a different administrative domain than D

An OPES system can support the format/protocol adaptation above, IMO.
OCP already handles the case when one message from A is converted to
multiple messages to B (to address your concern #3).

The other part of your problem is communication in the other direction
(B, D, and C talking to A). I believe such communication is not
prohibited by OPES rules, but otherwise is outside of OPES scope.

HTH,

Alex.

---

From: jfcm <[email-masked]>
Date: Fri, 23 May 2003 23:24:06 +0200

>         Here is my interpretation of the primary part of your problem:

I am afraid I was not clear enough. The system exists. It runs well and is 
designed to have A respondng  B an XML status report. This is all what A 
knows doing. It checks the calling IP address and respons. This permits B 
to discover that A has a problem from the daily status report. The only 
improvement is that A will call when it has a problem (an empty XML message).

>         A emits messages using format/protocol pA

Yes. Empty XML.

>         A is configured to talk D as its "next hop" for pA

It calls B. But because it uses IP addresses, the address listed as B has 
to be D address.
Or better - but how will that work. D fakes being B.

>           (or prefers) messages in format/protocol pB, not pA

Yes. The message is unique. A full A XML status report

>         D forwards adapted messages (in pB) to B

Yes but you by pass all what is interesting:
          - multiple sending in one very long cession
          - possible changes in who is C
          - necessary calls from C to A to be able to complete the service 
on the pA to B call.

>multiple messages to B (to address your concern #3).

           - even if it is a "long cession" are there no timers anywhere 
which may influence?
           - no impact if there are reboots of D?

>prohibited by OPES rules, but otherwise is outside of OPES scope.

           - problem in having them totally supported under OCP you would 
think of?

Interest is that if I got the funding it might help developping OCP functions
and test them. Also, to put me back in the OCP stuff (I am out of scope
right now with the load with my ICANN oriented load). Low chances to get
a budget, so is it worth a try? Or are there enough resources already
commited in here?

Thx
jfc

>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.483 / Virus Database: 279 - Release Date: 19/05/03

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 23 May 2003 15:51:30 -0600 (MDT)

On Fri, 23 May 2003, jfcm wrote:

> I am afraid I was not clear enough. The system exists. It runs well
> and is designed to have A respondng B an XML status report. This is
> all what A knows doing. It checks the calling IP address and
> respons. This permits B to discover that A has a problem from the
> daily status report. The only improvement is that A will call when
> it has a problem (an empty XML message).

I do not think the above details affect correctness of my response.

> It calls B. But because it uses IP addresses, the address listed as
> B has to be D address. Or better - but how will that work. D fakes
> being B.

A talks to D. Whether D represents, fakes, or forwards messages to B
is of no importance at this point. D is the "next hop" for A, using
pA.

>           - multiple sending in one very long cession

I already commented on that: OCP supports multiple adapted responses
and OPES must not prohibit them.

>           - possible changes in who is C

Not a problem from OPES/OCP point of view, as long as D and C can
handle that. For example, D can close the existing OCP connection to
C1 and establish a new connection to C2, transparently for A and B.

>           - necessary calls from C to A to be able to complete the service

I already commented on that: this is not prohibited by OPES but is
beyond OPES scope. In other words, C is free to do that, using
whatever means necessary.

>            - even if it is a "long cession" are there no timers anywhere

OCP timeouts are not defined yet, but will be fully
configurable/negotiable, of course. The duration of an OCP connection
does not matter from OCP point of view (as long as all OCP agents
involved are OK with long-lived connections).

There may be some interesting things one can do on transport level to
make long-lived OCP connections efficient and robust (e.g., smooth TCP
connection termination and resumption using custom OCP messages).

>            - no impact if there are reboots of D?

No impact from OPES/OCP point of view. However, raw TCP may not be
appropriate transport for OCP in this case, and D has to be able to
keep state across reboots. These are not OPES/OCP issues though. These
are issues for D state storage and for OCP transport.

>            - problem in having them totally supported under OCP you would

OCP does not know of these "communications in the other direction". If
A, B, D, and C want to use OCP for "communication in the other
direction", they can. I am not sure it would be the best choice
though. Don't they already have a protocol that B, D, and C use to
query A? Perhaps I misunderstand your question/concern?

> Interest is that if I got the funding it might help developping OCP
> functions and test them. Also, to put me back in the OCP stuff (I am
> out of scope right now with the load with my ICANN oriented load).
> Low chances to get a budget, so is it worth a try? Or are there
> enough resources already commited in here?

Are you kidding? There are never enough resources! If you get funding
and will be willing to share money and/or results, the group will
benefit, of course. For example, it can speed up building a decent
reference implementation.

Alex.

---

From: jfcm <[email-masked]>
Date: Sat, 24 May 2003 01:43:38 +0200

Thinking of your last response I come back on  a few point.
I will try to make the selling - target could be septembre thought.

>whatever means necessary.

This is the point. Relation between A and D and D and B woul dbe http.
As thay are toway. EVERY relation betweeen D and C should be OCP.
Several reasons:
- homogenity
- security (one single port)
and
- money (this is where I could get the money for the development) :-)

My main interest is to see up to where OCP may be used.

>connection termination and resumption using custom OCP messages).

yeap. The interest is that the dispatcher (D) would serve as a kind of
signaling. It caould be called by applications to know if the OPES
service par C is closed. In case of a reboot, that would be of use to
know what is underprocess.

>are issues for D state storage and for OCP transport.

Problem is that this keeping of state (see above) should be maintained
on D, C, B to reinitiate the situation in the case one or two reboot.

In a way this would be documented bt B not having received the end of the
cession.

>query A? Perhaps I misunderstand your question/concern?

B querries A.
D comes in the between. So speks http bothe ways.
C speeks OCP with D.
No other relation. When C calls A itis through D (they are not in the same 
domain! D is its gateway).

>reference implementation.

This was my idea from the begining. So I am looking for netservices which 
could do the trick. One si the DNS application. But quite political to know 
about it. Europe could pay but the project is heavy.

Here the idea that I could have a grant of 50% of the development if I find 
a regular customer because it is R&D. Lot of paperwork and delays. Unless 
someone was interested in sharing? The money would come from the French 
Natinal Agency fo  Research. But again there may be some much paperwork and 
delays  that it would be very heady and the customer getting tired. I will 
try however when I have a good understanding of the whole OCP.

Is there not any other French on this list?
jfc

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 23 May 2003 22:57:05 -0600 (MDT)

On Sat, 24 May 2003, jfcm wrote:

> Thinking of your last response I come back on a few point. I will
> try to make the selling - target could be septembre thought.
>
> Relation between A and D and D and B would be http. As thay are
> toway. EVERY relation betweeen D and C should be OCP. Several
> reasons:
> - homogenity
> - security (one single port) and

OK. OPES covers a part of D-C relationship that deals with pA to pB
adaptation facilitated by OCP use. C and D can also agree to use OCP
for other purposes such as facilitating queries from C to A (via D).
Such OCP use is possible but is beyond OPES scope.

OCP is designed to facilitate message exchange and, hence, can be used
to exchange virtually any messages. After all, one can view response
generation as request adaptation!

> The interest is that the dispatcher (D) would serve as a kind of
> service par C is closed. In case of a reboot, that would be of use
> to know what is underprocess.
>
> Problem is that this keeping of state (see above) should be
> maintained on D, C, B to reinitiate the situation in the case one or
> two reboot.

OK. I guess there are several degrees of robustness here and several
ways to support them. One degree is being able to recover agent's last
state after a reboot without contacting other agents. There are known
techniques to do that, but they cannot handle a total agent
loss/replacement. If you make the state distributed/mirrored across
several agents, then you may be able to survive a total loss
(replacement) of one or more agents. Etc.,etc.  It all depends on how
important it is to be robust in your particular environment.

Note, however, that OPES and OCP Core have nothing to do with all that
state recovery, even if they are actively used before, during, and
after recovery! OCP is nothing more than a communication protocol.

> domain! D is its gateway).

I think I understand that. You want to use OCP for several purposes.
That's fine. Some of those purposes may be out of OPES scope, but it
is great if OCP can be reused outside of OPES scope!

Alex.