Re: INFO Framework - one pakage per INFO

Hadriel Kaplan wrote:
>>> Send the 200 OK and let the application sort out the body.  SIP has done
>>> its job - don't be a layer violator and conflate an application error
>>> with a transport error!
>> I don't think I agree with this, but it could stand some further
>> discussion. Are you asserting this behavior is special for INFO? Or that
>> it is true for all messages?
>> I don't find anything in 2976 that calls for a success response when the
>> content of the body is incorrect.
> 
> Yeah there's no debate that SIP expects INVITE/UPDATE to be handled integral with body processing.  What's always been argued is how to handle things like MESSAGE, SUB/NOT and INFO.  Several people have argued the body part content of those was at a higher layer.  The text in SUB/NOT RFC only defined a response code for bad Event-types or unknown body content-types I think, but left body processing failure out of it.  And none of the packages seem to go any deeper as far as I can tell.
> 
> Of course in practice some (many?) devices respond with failure codes when body processing fails no matter the method.
> 
> Wasn't this debated a couple few ago on this list?

I sort of see the logic although I'm also not 100% convinced by it.

In any event (no pun intended) I don't think the draft adequately deals 
with the implications of this model. If errors occurring at higher 
layers aren't reported as failure of the INFO request itself, it pretty 
much follows that the 200 response to the INFO must include a payload 
that carries info (sorry, pun not intended here either) on the error.

The alternatives would be:
1) Don't report app-level errors. Perhaps OK for simple packages.
2) Report outcome in separate INFO requests going in the opposite 
direction. Seems wasteful and requires additional app-level correlation.

AFAICT the draft has no discussion on how to carry app-level success or 
failure indications. In fact, the table in sec 5.2 indicates that 
Info-Package is allowed in requests only.

Assuming an event package specifies that all INFO requests result in a 
response which is carried in the 200 response, what does that mean for 
the info package negotiation? An implementation might be able to act as 
a sender of this type of INFO but not as a receiver. It still needs to 
understand the INFO responses but presumably it needn't list the info 
pkg in Recv-Info header fields it generates.

Just as an FYI ECMA has defined TR/87, a SIP INFO binding for the 
computer-supported telecommunications applications (CSTA) CTI standard, 
which uses exactly that model. CSTA requests and events are carried in 
SIP INFOs and these INFO requests succeed even if the CSTA request 
fails. For CSTA requests the 200 response to INFO always carry a CSTA 
response and for CSTA events the INFO response has no payload. The spec 
is available from 
http://www.ecma-international.org/publications/techreports/E-TR-087.htm.

Thanks,
Anders
_______________________________________________
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