I think we should just be honest and admit that we're doing no one any
favors by being very dogmatic about layering here. At the end of the day
SIP is not a transport protocol. Who says we need to be so strict about
separating SIP from app.
So Hadriel, I guess I agree with your conclusion but I agree with Dean
that it really is a layer violation. I just don't see it as such a big deal.
Anders
Hadriel Kaplan wrote:
-----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
_______________________________________________
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
