Subject: RE: capability negotiations

From: "Martin Stecher" <[email-masked]>
Date: Wed, 8 Oct 2003 21:13:37 +0200

> 
> > I do not really like that a structure does now start with either SP
> > or CRLF right after the bracket.
> 
> I like it 50%. The leading SP is indeed a bug that should be fixed.
> 
> Leading CRLF is intentional -- it allows the parser to switch to
> named-value parsing mode by looking ahead one character only.
> Incidently, it makes syntax constructs simpler and also follows
> classic C formatting style.

I got the same idea after posting the last message.
Although I think it could be handled without the CRLF (parse a value,
check whether it is also a name and followed by a colon, if yes switch
to named-parameter), I agree, that an indication in front is better.
We have it for all other elements in OCP, so we should have it here too.

> How about this compromise (get rid of
> leading SP, leave leading CRLF):
> 
>   message = name [SP anonym-parameters]
> 	[CRLF named-parameters CRLF]
> 	[CRLF payload]
> 	";" CRLF
> 
>   anonym-parameters = value *(SP value)               ; spaced values
>   named-parameters = named-value *(CRLF named-value)  ; 
> CRLF-separated values
>   list-parameters = value *("," value)                ; 
> comma-separated
>   payload = data
> 
>   value = atom / structure / list
>   named-value = name ":" SP value
>   atom = bare-value / quoted-value
>   structure = "{" [anonym-parameters] [CRLF named-parameters CRLF] "}"
>   list =      "(" [list-parameters] ")"
> 
> The above is (should be) identical to your proposal, except:
> 
> 	- named-parameters always start with CRLF,
> 	  making parsing optimizations possible
> 
> 	- named-parameters always end with CRLF,
> 	  making the layout classic C-like and
> 	  allowing for easier MIME-style payload
> 	  identification (CRLFCRLF or CRLF; terminates
> 	  "headers"), a very useful parsing optimization
> 
> For example,
> 
> 	CMD1;
> 
>         CMD2 {
>                 n1: v1
>                 n2: {
>                         n21: {v21a v21b}
>                         n22: (v22a,v22b)
>                 }
>         };
> 
> 	CMD3 1 2 3
> 	n1: v1
> 	n2: v2
> 	;
> 

Agreed, regarding the syntax of structures.

> 
> I think we actually migrated to an even cleaner/simpler syntax with
> all these named-members-related changes! Any corrections or
> objections?
> 

Almost perfect, IMO.
I don't like yet that payload is separated with an empty line from headers in case of named parameters but starts on a new line if there are only anonymous params. And the semicolon should either always or never start on a new line, I think.
So, how about this little change?

  message = name [SP anonym-parameters] CRLF
            [named-parameters CRLF]
            [payload CRLF]
            ";" CRLF

Every element, but anonymous parameters, starts on a new line.

Regards
Martin

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 8 Oct 2003 14:49:41 -0600 (MDT)

> Agreed, regarding the syntax of structures.

Great.

> I don't like yet that payload is separated with an empty line from
> headers in case of named parameters but starts on a new line if
> there are only anonymous params.

Yeah.

> And the semicolon should either always or never start on a new line,
> I think.

I like being able to write simple messages on one line

	CMD 1 2 3 4;

This would look worse, IMO:

	CMD 1 2 3 4
	;

There is virtually no difference for the parser, I think. This is a
purely visual/presentational effect. One-liners are nice when you brag
about how compact OCP can be.

> Every element, but anonymous parameters, starts on a new line.

This does not allow for fast separation of "header" and payload using
a unique CRLFCRLF sequence. The latter is useful to make avoid parsing
partial input buffers until they are likely to contain complete
message headers.

I would like to keep simple messages on one line. How about always
separating payload with CRLFCRLF while still allowing for one-liners:

	     [CRLF named-parameters]
	     [CRLF CRLF payload]
             ";" CRLF

Every element, including anonymous parameters, starts with its own
unique sequence: SP, CRLF, and CRLFCRLF, and ;CRLF.
This would result in a very simple logic:

	1. Parse name.
	2. parse anonym-parameters if the next character is SP
	3. parse named-parameters if next characters are CRLF
	   but not CRLFCRLF
	4. parse payload if next characters are CRLFCRLF
	5. parse trailer: ;CRLF

while allowing for an optimization:
	- Keep buffering until CRLFCRLF or ;CRLF is found
	  or the buffer is full.

We can go further and replace
	[CRLF CRLF payload]
with
	[":" CRLF payload]
to avoid the "but not CRLFCRLF" clause above, but let's make MIME
fans comfortable, I guess.

This is probably equivalent to your last proposal except I preserved
one-liners and made payload easier to find without parsing.

Objections or further improvements?

Thanks,

Alex.