Re: INFO Framework - one pakage per INFO

I agree with Handriel and Anders.

The distinction that Dean is trying to draw is a very fuzzy one when you 
dig into it. Remember that a multipart is also just a body type, and 
taking it apart is body processing. We could argue that the specific 
degree of multipart parsing that is required to identify the individual 
elements is required in order to respond to the sip message, but parsing 
of other parts, even other multipart parts is not, and so failures there 
must not be reported. But then what about a stack that decomposes the 
entire tree of multiparts first and then deals out the parsed parts to 
the "invite" application and the other applications? What if there is a 
multipart/alternative with C-D of "session"? Is it ok to return a 488 if 
that can't be decomposed into its contained parts, or a 415 if the 
contained parts don't contain SDP?

I think we need to work this so there is some latitude for how the 
application layers the processing.

	Thanks,
	Paul

Anders Kristensen wrote:
> 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