>>>>> IЯaki Baz Castillo <[EMAIL PROTECTED]> wrote:

> b)
> ------------------------------------------------------------
> Content-Length                                        :
>      
>                               
>                                               46
> ------------------------------------------------------------


> Both a) and b) are correct, and b) is not more human readable at all. Also a) 
> is 400 times easier to parse than b) so, why allow b) ?

Because IETF is grammatist realm. If something is supposed to use
text format, it's allowed to use free form syntax. Your example
(b) is too radical, it's better to compare with something like:

=== c)
INVITE sip:[EMAIL PROTECTED] SIP/2.0
From                    : alice <[EMAIL PROTECTED]>;             tag=1
To                      : white rabbit <[EMAIL PROTECTED]>;     tag=2
i                       : [EMAIL PROTECTED]
===

which isn't much worse than non-spaced form.

Grammatist approach is that if something can be declared as
grammar, declare this grammar and then allow any text which
allowed by some grammar, without artificial limits. If you e.g.
declare that some spacing can't exceed 20 spaces, it's artificial
limit. Compare with recommended limit of 1300 bytes per message,
which is transport-specific limit. Generally message generators
don't add wasting spaces and other curlicues because this increase
probability of transport limit overflow.

> Ok, I understand that SIP was born from HTTP and so, but anyway I hope in a 
> future SIP/X.0 appears eliminating so many and innecesary permissive syntax.

If to invent such, this already won't be text format, and with
avoiding of freeform format one really has to invent binary-like
format. Even if this format, unlike real binary format, isn't
allowed to carry arbitrary byte values, it has binary format
limitations by definition. There were cases of such approach (e.g.
FTN message and packet formats) and I can't definitely say this
experience is positive.

-- 
Valentin Nechayev
PortaOne Inc., Software Engineer
mailto:[EMAIL PROTECTED]

_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to