--On Thursday, April 02, 2009 19:46 -0400 Keith Moore
<[email protected]> wrote:
> not clear. IMHO, trying to specify every aspect of detail of
> a protocol syntax using a formal specification language can be
> misleading and cause more interop failures, than a looser
> specification written in ABNF plus some exceptions in the
> text. One reason for the additional failures when using the
> precise formal specification is that you don't really benefit
> from that specification unless you feed it to a program that
> will automatically generate the recognizer. And if you do
> automatically generate a recognizer from the formal
> specification, you often find that it doesn't report errors in
> the way that you'd like, doesn't perform as well as you want,
> etc.
Yes. And if the protocol is even nearly as complicated as SIP,
you need a formal language that can specify semantics as well as
syntax to get even close to a full description of the protocol.
Syntax alone just doesn't do it. I would slightly disagree with
Keith's characterization because those things can be good for
generating reference implementations that can be checked against
production ones to see if the latter are working correctly. But
I agree that such a reference implementation isn't likely to be
something one would like to use in production for the reasons he
gives.
I could suggest a few specification languages of that variety
from experience (and there are more in the literature), but, as
you point out...
>> But there is a big tradeoff there. At least many people are
>> capable of reading ABNF, and a reasonable number of those can
>> accurately understand what it means. A somewhat smaller, but
>> still significant, number can write it correctly. Its
>> important that the people involved in the standardization
>> process, and that implement the standard, be able to
>> understand it. A more powerful specification language, that
>> fewer people could understand, might not be such a great
>> choice.
>...
the languages that can be used to specify not just static syntax
but semantics and actions require serious work to understand how
to read and even more to be able to write, leading to only a
small population who can really understand such a specification.
That is usually considered bad news although I've been in
situations in which it is considered job security.
> The trick is to design the protocol in such a way that a
> precise formal syntax specification is not necessary. This
> implies having a certain degree of simplicity and regularity
> in the protocol.
Unfortunately, SIP probably fails the test that implies. And no
alternate choice of specification method is going to change that.
john
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
