Subject: RE: OCP Core version head_sid6 available

From: "Martin Stecher" <[email-masked]>
Date: Tue, 20 May 2003 15:06:41 +0200

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:[email-masked]]
> 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).
> 
>

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 20 May 2003 10:04:13 -0600 (MDT)

On Tue, 20 May 2003, Martin Stecher wrote:

> <snip>

I agree with your comments and will fix the BNF like you suggested
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)

The current text lacks any guidance due to time constraints.  Some
rules must be added, of course. I agree that it makes little
implementation sense to support both abbreviated and full versions. I
am not sure what is the best way to eliminate full names from
implementations while having both computer- and human-friendly version
documented. Here is what I was going to add to the draft as the first
attempt:

	1a. Implementations MUST send and recognize abbreviated names.
	1b. Implementations MUST NOT send or recognize full names.
	2a. Full names exist exclusively for human-friendly interfaces.
	    Documentation and debugging tools may use full names. For
	    example, most examples in this specification use full
	    names.
	3a. Abbreviations are collision-prone.
	    Extensions outside of IETF standards track MUST NOT
	    invent new abbreviations.
	3b. IETF standards track documents MAY add new abbreviations.

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

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

That would work and is probably better than any other single
character. Do you not like the {curly braces} approach though? Here
are the current options to consider:

	0. name parameters payload .        (current syntax)
	1. name parameters payload !        (Martin's proposal)
	2. {name parameters payload}        (XML-like)
	3. name parameters END              (BEEP-like)

If "." is to be replaced, I slightly prefer "{}" over "!". "END" seems
too wasteful to me. Other opinions?

>   named-parameter = CRLF name ":" SP value

Agreed, except lets wait for more feedback regarding the terminator
choice above.

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?

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

Will fix.

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

OK. Let's leave it as decimal unless somebody else objects.

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

Yes, always mapped to multiple data-have messages. The data-have
message overhead is so small that (IMO) it is better to keep things
simple: one message, one payload.

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

I would like to avoid versioning and use profile negotiations instead.
We have to support negotiations anyway. As far as I can tell, there
are two reasons to add versioning: support changes in message syntax
(major version change) and support new minor features/defaults (minor
version change). The former should not be done through versioning
(IMO). The latter is better done through profile negotiation (IMO).
Other comments/opinions?

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

Should we clean the current mess and rely exclusively on dedicated
messages? Their overhead is small and this approach will keep the
protocol cleaner and implementations a bit simpler. What do you think?

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

Will fix/add.

> Is missing an abbreviation in section 7.4

Will add.

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

And see above. We need to be consistent. The current approach is not.
Connection, transaction, and application message determine "scope".
Some state changes may need to be scoped (e.g., services applied to
this transaction should not affect other transactions on the same
connection).

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

Probably yes, for consistency reasons. We should let implementations
to use identical mechanisms (i.e., the same code) to exchange data and
metadata.

> The description still talks about copy-am-id which is not longer defined

Will fix.

>    bare-value = 1*safe-OCTET

Will fix (all occurrences).

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

Hmm... You are right, but I am not sure what the correct fix is. I
cannot understand whether writing just 0-2147483647 is allowed in
ABNF. BEEP uses that, but I cannot see anything in RFC 2234 that would
make such a range a valid ABNF terminal. We can use 1*DIGIT instead
and add more restricting prose. Does anybody know what the right thing
to do is?

>  -we should make sure that linear white spaces are not allowed in
>  between some elements (not sure whether this is automatically
>  given)

The following text has been accidently removed from the spec:

     There are no "implied spaces" common to MIME-based grammars. The
     syntax is restricted to spaces allowed by the above BNF.

Will polish and add.

Thanks a lot,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 20 May 2003 12:00:52 -0600 (MDT)

On Tue, 20 May 2003, Alex Rousskov wrote:

> Here are the current options to consider:
>

Adding a SP before the terminator will solve the problem of 1. being
parsed as "1.0" and not "1" followed by a terminating dot. So,

  	4. name parameters payload SP .

Here are some examples:

	app-message-start 123 1.
	app-message-start 123 1!
	app-message-start 123 1 .
	{app-message-start 123 1}
	app-message-start 123 1 END

Alex.