Re: INFO Framework - one pakage per INFO
Dean Willis <[email protected]>
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <[email protected]> |
On Dec 9, 2008, at 12:54 PM, Hadriel Kaplan wrote: > > >> -----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. It had damn well better do that only for an application/xml body type. If it sees something that sort of looks like XML and then tries to check it (and it isn't really XML), we're back to coupling applications to the SIP protocol (or worse yet, to the SBC . ..) > > > 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. I would say it as something like "If the UAS cannot decode the MIME structure of the body because of formatting errors, it returns a 606. If the UAS can decode the MIME structure of the body but does not know what to do with the body parts, either because they are of an unrecognized type or because there is no application to consume those body parts, the UAS returns a 415. Otherwise, the UAS delivers the body part to the application and returns a 200 OK." I would leave discussion of application-level rejection of body parts entirely out of the discussion. -- Dean _______________________________________________ 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