> > "Barry (work)" writes:
> > >> >As a general point, about the need for parsers to be forgiving - there is
> > >an
> > >> >argument that 'over-aggressive' parsers are useful because they prevent
> > >> >unpredictable and potentially serious operational problems
> > >> >from arising in a complex interworking environment.
>
> I'm not sure the problem is that interoperability is at danger. As a lot
> of people have pointed out interoperability is helped by receivers being
> flexible in what they accept. I do think Barry has got a point, though,
> in that very flexible implementations does nothing to discourage
> breaking the standards as long as things work. An obvious example of
> where this has happened is the Web where extremely lax browsers has
> meant that a huge amount of malformed HTML is now in existence. People
> might run notepad, handwrite some malformed HTML, checks that it renders
> OK with Netscape, and then publish it.
>
While certainly possible, the risk of widespread hand generated SIP messages in the
network is probably pretty low :) Seriously though, while there is utility in being
pedantic about every possible deviance from the spec. in a bakeoff environment, I would
think twice about deploying anything that wasn't as flexible as possible. Think of it
as service: a "lint proxy" that cleans up your messages before sending them out to the
network :) (Yes, I know a proxy isn't supposed to do that)
> So one can certainly argue against browsers being so very liberal in
> what they accept, and a lot of people have done that. In fact, the
> designers of XML wanted to avoid the situation of HTML and so included
> text in the spec explicitly prohibiting parsers from accepting malformed
> XML documents, even when the intent might be guessed.
>
There are also performance issues involved with the XML design that don't show up in
SIP.
Being able to discard an XML document at the tokenizing/scanning level is very
important.
Doing this in SIP is questionable.
> Maybe it wouldn't be such a bad thing if implementations at the bakeoffs
> at least generated warning messages (does anyone use the Warning:
> header?) or something like that.
>
> Anders
>
Unfortunately for anything other than a SDP warning, there is a small miscellaneous
bucket that everything gets thrown into. I would be nice to create some new
warning codes for the more common non-SDP problems.
390 addr-spec missing angle brackets
391 Unterminated quoted-string
392 CSeq missing method
393 Incorrect case for method
394 Missing Content-Length
...
> --
> Anders Kristensen <[EMAIL PROTECTED]>,
> http://www-uk.hpl.hp.com/people/ak/
> Hewlett-Packard Labs, Bristol, UK
>
--
Sean Olson <[EMAIL PROTECTED]>
