ietf-openproxy
[Top] [All Lists]

RE: OCP Core version head_sid6 available

2003-05-20 06:11:18

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(_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

      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).