> -----Original Message----- > From: Pete Cordell [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 09, 2008 8:15 AM > > > Malformated INFOs should be hanlde like any other malformed SIP method. > > But only the application (and not the SIP layer) knows whether it is > malformed or not. So the SIP layer needs to ask the application whether > it > will accept the message before giving a response.
That's not necessarily true. I could have a firewall-type checker in the SIP layer that verifies XML syntax is valid, which knows nothing about the semantics of the elements/attributes themselves, before passing it on to an app layer. And before anyone says "but we can't require it to do so and we have to accommodate a layered model only understanding the content in the app-layer" - that's NOT the issue. Of course we have to allow for only the app-layer understanding content - we should even *assume* it. But the reality is that we already allow a 4xx response to be sent for a bunch of sip-layer error reasons. Because of that, the app-layer *sender* of an INFO request has to accommodate "delivery-failure" based on a 4xx response already. Period. Therefore, an _integrated_ model *receiver* would simply send one of those 4xx responses if it failed content formatting error checks when it receives an INFO request, because from a functional app-layer perspective to the INFO *sender* it is no different than a delivery-failure. There is nothing we can do to stop that behavior, because there's nothing broken with that behavior, either in terms of interop or semantics. We can try to say "even if the content is malformed you MUST send back 200 and then a new INFO with an error code", but that will be summarily ignored. So the question is simply if we want a specific response code for content formatting errors, such as 488, to help troubleshooting - or if they should just send 400 or 415 as they do today. Again, this doesn't prevent a fully layered model from sending 200 back and then some INFO request upstream with an error code - it just makes it easier to troubleshoot what an integrated model can already do by sending back a 400 or 415. -hadriel _______________________________________________ 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
