RE: OCP Core version head_sid6 available

["Martin Stecher" <martin.stecher@xxxxxxxxxxxxx>]

Hi,

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 named-parameters.
I propose a change of the syntax (see below)

- Abbreviations:
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 section 3.
Better move it to a more prominent place, maybe just on top of the message syntax.

- payload
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 decimal.
I think we should stick with decimal. Hex will usually not save more than one char.

- payloads
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?

- connection-start
I wonder whether we could need a version number.
Shouldn't we add one to the connection-start message? It may be useful in future.
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?

- connection-end
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.

- connection-services
Is missing an abbreviation in section 7.4

- xaction-start
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.

- meta-as-is
We have data-have and data-as-is.
We now also have meta-have but no meta-as-is. Needed?

- data-as-is
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)


Regards
Martin

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx]
> 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
> 
> 	http://www.measurement-factory.com/tmp/opes/
> 
> Please continue to comment and work on the to-do list.
> 
> 
> Thank you,
> 
> Alex.
> 
> -------------- 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
>       original text).
> 
>