1)
" application message: A sequence of octets that OPES processor
designates for callout service processing. Usually, an
application message is the basic unit of application protocol
communication, as defined by that application protocol (e.g.,
HTTP/1.1 message). Before OCP is applied, OPES processor may
pre-process raw application messages to extract and manipulate
well-known parts (e.g., HTTP message headers or SMTP message body)
in order to subject just those parts to callout services. For the
purpose of OCP, the result of such preprocessing is an application
message. Naturally, OPES processor and callout services it is
configured to use must agree on what application messages are
acceptable. Establishing such an agreement is beyond OCP scope."
Everything after "Before OCP..." has nothing to do with the definition of
application message anymore. This has to do with the workings of the
protocol.
Although I suggest to rip out the last part of this definition I should say
that I disagree (if I understood correctly) with your statement
"Establishing such an agreement is beyond OCP scope". Capability negotiation
can help you establish what application messages are acceptable on each
connection or callout server as a whole.
Suggested version.
" application message: A sequence of octets that OPES processor
designates for callout service processing. Usually, an
application message is the basic unit of application protocol
communication, as defined by that application protocol (e.g.,
HTTP/1.1 message).
2)
"A callout server may send this data back to
the OPES processor, with or without modifications."
Suggestion
"A callout server may send or not this data back to the OPES processor. When
the callout server sends data back to the OPES processor, it can be modified
or not."
3)
"The primary purpose of OCP communications is modification of
application message payloads..."
Do not want to seem picky, but the primary purpose of OCP is to ship packets
back and forth between Callout Server and OPES Processor. Whatever is done
with message has nothing to do with OCP anymore. It is a function totally
contained within the callout server.
I guess you can say
"The primary purpose of the OCP is to send data to the callout server where
it will be examined and possibly changed"
4)
" OCP transaction is a logical sequence of OCP messages processing a
single original application message. The result of the processing may
be zero or more application messages, adapted from the original. A
typical transaction consists of two message flows: a flow from the
CLIENT to the SERVER (sending original application message) and a
flow from the SERVER to the CLIENT (sending adapted application
messages). The number of application messages produced by the SERVER
and whether the SERVER actually modifies original application message
depends on the requested callout service. The CLIENT or the SERVER
can terminate the transaction by sending a corresponding message to
the other side."
Hummm...I guess I'm not confortable with the idea of mixing the OCP
semantics per se and whatever it carries..The problem with this approach is
that we will start asking things like "what is the original application
message?". "Is the the whole HTTP 1.1 message before TCP fragmentation or
after?" , "And if is protocol X..and Y", etc, etc.
This is my (lean) suggestion using your definitions:
" An OCP transaction is a logical exchange of OCP messages.
A OCP transaction starts with a xaction-start message, followed
by zero or more data-xxx messages, zero or more appl-xxx and ends
with a xaction-end message. "
5)
"xid: OCP transaction identifier. Uniquely identifies an OCP
transaction originated by a given CLIENT. Since each transaction
deals with a single application message, "xid" also identifies
that application message."
As you can guess, IMHO the part ""xid" also identifies that application
message." is troublesome.
My suggestion
"xid: OCP transaction identifier. Uniquely identifies an OCP
transaction originated by a given CLIENT."
6)
"am-id: Application message identifier. Uniquely identifies an
application message within an OCP transaction."
I guess it is one more reason to make the modification I mention in number
5) above.
7)
" am-source: Information about the source of an application message.
For example, HTTP client or origin server IP address and TCP
connection ID.
am-destination: Information about the destination of an application
message. For example, HTTP client or origin server address."
I'm not sure I follow this...TCP connection ID? Information about the source
of an application message?
8)
"size: Application data size in octets. The value either applies to
the data attached to an OCP message or suggests data size to be
sent in response to an OCP message."
Is this the original value (which I guess before reaseembly it cannot be
known)? The value of the OCP payload?
9)
"modified: A boolean parameter indicating that the attached
application data has been modified by he SERVER. Only SERVER may
send this flag. This parameter can be used with any OCP message
that has am-id parameter."
Suggestion
"modified: A boolean parameter indicating that the attached
application data has been modified by the SERVER. Only the SERVER may
send this flag. This parameter can be used with any OCP message
that has am-id parameter."
I guess the caveat is that if you but the flag in one OCP message containing
am-id, you have to put in all of them for the same am-id.
10)
"copied: A flag indicating that a copy of the attached application
data is being kept at the CLIENT. Only the CLIENT may send this
flag. This parameter can be used with any OCP message that may
carry application message data. (XXX: it is yet unclear when
CLIENT commitment to preserve the data may end.)"
Same caveat as above.
11)
"sizep: Remaining application data size prediction in octets. The
value excludes data in the current OCP message, if any. The
prediction applies to a single application message. This parameter
can be used with any OCP message that has am-id parameter.
modp: Future data modification prediction in percents. A modp value
of 0 (zero) means the sender predicts that there will be no data
modifications. A value of 100 means the sender is predicts that
there will be data modifications. The value excludes data in the
current OCP message, if any. The prediction applies to a single
application message. This parameter can be used with any OCP
message that has am-id parameter."
I guess we need to hash this out in much for detail...
12)
"error: A flag indicating abnormal conditions at the sender that
cannot be expressed via result parameter. "
Such as? I guess maybe we could maintain the HTTP/SIP approach where we have
status code and reason phrases for everything.
"It is RECOMMENDED that
the recipient deletes all state associated with the corresponding
OCP message. For example, if the message is 'app-message-end' and
the application message contained user credentials, such
credentials should be deleted."
My suggestion
""It is RECOMMENDED that
the recipient deletes all state associated with the corresponding
OCP message."
13)
"feature: A OCP feature identifier with optional feature parameters.
Used to declare support and negotiate use of OCP optional features
(e.g., copying of data chunks at the CLIENT)."
I guess this is another one we need to iron out...
14)
"If a malformed message is received, the recipient MUST terminate
processing of the corresponding OCP connection using 'connection-end'
message with an error flag"
Why not send a status code and reason phrase instead of this error flag?
Just say "400 Bad Request"...or "400 Malformed Message"
15)
"This is the only OCP message that may carry application data. There
MUST NOT be any gaps in data supplied by data-have and data-as-is
messages (i.e., the offset of the next data message must be equal to
the offset+size of the previous data message) (XXX: we do not need
offset then; should we keep it as a validation mechanism?) (XXX:
document what to do when this MUST is violated). Zero size is
permitted and is useful for communicating predictions without sending
data."
Well, although we must not have gaps, we might loose packets...we need to be
able to recover and not throw all the OCP messages received so far away...
`
That's it for now..
I will send more comments later.
Regards,
Reinaldo