Subject: RE: capability negotiations

From: "Martin Stecher" <[email-masked]>
Date: Fri, 10 Oct 2003 23:00:18 +0200

> 
> Adding a CRLF trailer to named-parameters would make it easier to
> optimize parsing of named-parameters and would make the {structure}
> look more consistent. A trailing CRLF is what our current examples use
> as well. If we go down this path, we should change the above message
> definition (again) to make CRLF named-parameter trailer mandatory
> everywhere:
> 
> message = name [SP anonym-parameters]
>   ( [CRLF named-parameters CRLF CRLF payload] | [CRLF CRLF payload] )
>   ";" CRLF

Olala.
Although being more consistent it looks very strange, I guess that people don't understand the motiviation here.
This is not an option for me.
Anyway let's call it option 1 for further reference.

> 
> Is there a more elegant/consistent way of doing this while keeping
> one-liners and CRLF CRLF as a body indication?

Yes, I think so, see below (option 4).
------------------

> Or should we accept
> some inconsistency and stick with a simpler:
> 
> message = name [SP anonym-parameters]
>           [CRLF named-parameters]
>           [CRLF CRLF payload]
>           ";" CRLF
> 
> structure = "{" [anonym-parameters] [CRLF named-parameters CRLF] "}"

I think this is indeed an option. Let's call it option 2.
It is a small inconsistency, but still looks good to me.

------------------

Option 3 is as shown in the OCP core in today's CVS version:

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

This option is consistent but has the non C-style closing bracket problem.

------------------

I would like to propose option 4, my favorite:

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

This is a consistent and symetric and easy syntax.
It allows for single line messages. Message rendering looks good.

Examples:

CS;
TS 88 10;

DUM 88 1 0
AM-Part: request-body

15:This is my body
;
DUM 88 2 0
20:no named params here
;
CE
Error: "13:Out of memory"
;

Cons: After scanning the anonymous params, the next element could either be a named param or payload (but we do not have a real-life case for this yet).
Pros: Semicolon is on the same line only for single line commands; otherwise it is always on its own line
      The only message with payload with know today is DUM, it will always have named params for HTTP and probably also for other applications; here it looks MIME-like (headers, empty line, body).

I think, scanning is still quite easy. If you want to have the universal scanner, that allows for payload without named parameters, just check for the character after the first CRLF. If it is a digit, then there are no named-params; otherwise use the algorithm that Alex presented earlier

Is this algorithm change acceptable for you?

What is your favorite?

Regards
Martin

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 10 Oct 2003 15:52:12 -0600 (MDT)

> It allows for single line messages. Message rendering looks good.

We have a winner, I think.

Fast-scanning for end-of-headers is more difficult with this option,
but is still simple enough, I guess. One just have to scan for:
	CRLF digit / ";" CRLF

I was too stuck on CRLF CRLF payload separator to see option 4 :-/.

I will commit the change.

Thank you,

Alex.