I have to disagree with the point here.
Some might describe me as a "grammatist", in that I prefer a formal
definition of the grammar to an informal one.
The issue isn't that the syntax is formally specified by a grammar. It
is what syntax was chosen to be formalized. It would be equally
grammatical to choose a simpler form.
There clearly are conflicting goals in choosing the syntax for a
protocol like sip. I wasn't there when it started, so I won't speak to
exactly what the motivations were for the choices made then. Clearly
there was a decision to model it after email. Once that choice was made
many of the things you don't like were preordained. With 20/20 hindsight
it is easy to see many things that should have been done differently.
But once the protocol had gained a toehold it became pretty much
impossible to fix those things.
Regarding the # in the url, I can't remember for certain, but I believe
the character set is limited by the syntax of "generic" URLs. Its my
understanding that it is important to preserve that syntax in order that
sip URLs can be processed by applications that treat them generically.
We already have places in sip that allow generic URLs, and the same is
likely to be true of other protocols. And IIUC there are "URL police"
(grammatist?) who can and will block the approval of a draft that define
a non-conforming URL syntax.
I happen to agree with you that putting human-friendly syntax into
protocols to be read by machines is a waste. But that is something to
save for the next time we are defining a new protocol from scratch.
Thanks,
Paul
Valentin Nechayev wrote:
>>>>>> IЯaki Baz Castillo <[EMAIL PROTECTED]> wrote:
>
>> Anyway, if SIP wouldn't be SOOOOO permissive, if it would be more
>> restrictive,
>> implementations would be easier, more effective and with better performance.
>> But no, instead of that let's allow any kind of symbols, escaping,
>> ridiculous
>> URI headers, painful URI comparissions that NOBODY implements (19.1.4), etc
>> etc...
>
> This is common IETF problem: it's occupied by grammatists with
> paranoia of permissive approach.
> Another example is case-insensitive matching in text protocols,
> which requires to spend memory for copy of any header, field or
> attribute name which is written in non-canonic form (e.g.
> "Call-ID" vs. "call-id"), field name aliases, etc.
>
> The greatest example of grammatists' defeat was RFC822 which had
> got NONE fully correct implementation among widespreaded ones. But
> this didn't give them any experience.
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
