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
