Sean Olson wrote:
>
> > > "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.
Agreed.
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)
Yes, and a number of such services exist for HTML. Not that anyone uses
them, of course ;-). AFAIK, no such service exists for XML because the
rigor of that format makes it unnecessary. Actually, even with HTML it
is my impression that the problem is diminishing as better tools become
available.
>
>
> > 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.
Hmm, maybe. I guess the comparison only goes so far.
>
> > 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
> ...
