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. 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)
Actually there are cases where a server should fix broken messages. If a method value
is
missing in a received CSeq header field a server should fill it in or if a server
receives a
Request-URI that contains a SIP URL with transport-param, maddr-param, ttl-param, or
headers
elements it should removes them before further processing. If people wanted perhaps
this
could be extened into adding missing Content-Length etc but I am not sure how far you
can
sensibly take that approach by defining things to fix in the spec. I would be happy to
leave
it as an implementors decision as to how hard you try before responding 400.
> > 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
> ...
There is nothing to stop you setting the reason phrase in a 400 response to any of
these
comments.
Cheers,
Neil
--
Ubiquity Software Corporation http://www.ubiquity.net
