[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sip] INFO Framework - one pakage per INFO


> -----Original Message-----
> From: Dean Willis [mailto:dean.willis at softarmor.com]
> 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip