> -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 10, 2008 2:02 AM > > I'm worried that people are going to take this as evidence that the > SIP Stack SHOULD go to great lengths to validate content. For example, > are we going to require every SIP UA have HTTP so that it can retrieve > XML schemae, and an XML validtory to check body parts with, and then > validate every XML body part before handing it ti the application? > What response code should SIP send if a body part un-MIMEs ok, but the > SIP UA can't find the schema needed to validate the body? What if some > application data used invalid XML in his body? > > I'd really rather not have this as protocol considerations for SIP. > The SIP stack has to be able to pull the content out of its (possibly > multipart) MIME wrapper. If the MIME wrapping is good and there's an > application to hand the payload off to, I think SIP should be happy to > send a 200 OK.
Of course it should. I think you're missing the point (or I'm missing yours) - there's no debate that we have to allow a SIP request with valid SIP-layer stuff and valid mime wrapper and all be responded to with a 200 ok. Or at least I'm not debating that. It would be silly to mandate a SIP stack to do any more than that. But I also think we really shouldn't explicitly disallow me to send you back a 4xx. It's a non-sequitur. I can send a 4xx anyway, and as long as the resultant behavior is the same, who's the wiser? I have really not delivered it to an app-layer; there is no recovering from this condition (it's not like you can programmatically re-format it and hope this time I understand it); and whatever action you take due to a delivery-failure is really the right action to take in this case too. I think your point is that we shouldn't explicitly point this out, for fear of people thinking they need to do it? So that rules out creating a new specific response code for it, and just letting 415 or 400 cover that case. (that's essentially what all the other SIP specs do too - don't mention it, leave it implementation specific) I don't see people having interop issues with it so that's fine, though it makes troubleshooting a bit more laborious. -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
