some first comments:
- New-Line syntax:
The optional list of named-parameters starts with a CRLF and each
named-parameter has a CRLF at the end. I guess it should be one less. Each
named-parameter should start on a new line and if a message ends with a
named-parameter the the dot can be on that last parameter line.
Payload should also start on a new line not depending on the existince of
I propose a change of the syntax (see below)
I cannot find guidance whether message-name, message-abbreviation or both can
be used. I assume that abbreviations can be used. But does it make sens to
allow both variants? Full names are easier to read but if abbreviations are
allowed, many implementors will choose this so that debugging will need to deal
with abbreviations anyway. Why then forcing implementors to support both.
I vote for only using the abbreviations (see proposed syntax below)
- Message trailer
I like the dot as a native character to make stop a message but I share your
concerns in the note at the end of page 12. What about using the exlamation
mark character as message trailer? (see proposed syntax below)
- Proposed syntax change:
message = name-abbr. [anonym-parameters] [named-parameters] [payload] "!" CRLF
payload = CRLF data
named-parameters = *named-parameter
named-parameter = CRLF name ":" SP value
- Case sensitivity
The hint that OCP names are case sensitive is quite hidden at the end of
Better move it to a more prominent place, maybe just on top of the message
I found several HTTP and ICAP programmers being confused that chunk size in
these protocols is given in HEX digits while the Content-Length header is
I think we should stick with decimal. Hex will usually not save more than one
Is it possible that a message could benefit from multiple payload parts
following each other as in chunked transfer encoding? Or will those cases
always be mapped to multiple data-have messages?
I wonder whether we could need a version number.
Shouldn't we add one to the connection-start message? It may be useful in
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
Same for connection-priority?
Section 7.2 writes "senders: OPES processor only". That's wrong isn't it.
It should read: "senders: both OPES processor and callout server".
What about adding an optional error parameter here too? There are a few places
where OCP forces to send connection-end and closing of the connection in case
of an error. That parameter could help to debug which error has been detected.
Is missing an abbreviation in section 7.4
I always stumble on the optional services parameter. I am not yet convinced
that we need this on a transaction basis. I think we had this discussion
already; need to look up the old thread again.
We have data-have and data-as-is.
We now also have meta-have but no meta-as-is. Needed?
The description still talks about copy-am-id which is not longer defined
- ABNF glitches
I am not an ABNF expert but I think that
-there should be no brackets in the bare-value definition
bare-value = 1*safe-OCTET
-the definition of size is not correct because since CR can be defined as
%d13, the range %d0-2147483647 is not the ASCII decimal value representation
-we should make sure that linear white spaces are not allowed in between some
elements (not sure whether this is automatically given)
From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com]
Sent: Tuesday, May 20, 2003 1:20 AM
To: OPES Group
Subject: OCP Core version head_sid6 available
OCP syntax rules are now drafted in. The [major] change log is quoted
below. The latest snapshot, including XML sources for those doing
hands-on modifications, is available at
Please continue to comment and work on the to-do list.
-------------- change log ----------------
Appendix B. Change Log
o Added OCP message syntax. Reformatted message descriptions to
match new syntax concepts.
o Started adding meta-have message to exchange metadata details.
Removed negotiation messages for now (posted new messages to the
list for a discussion).
o Added Security Considerations section (based on Abbie Barbir's