Re: INFO Framework - one pakage per INFO

inline.

	Paul

P.S. Its a pity that we haven't anything better to do on a holiday 
weekend. :-)

Hadriel Kaplan wrote:
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On Behalf Of Paul
>> Kyzivat
>> Sent: Friday, November 28, 2008 5:22 PM
>>
>> If you want to do it that way, then I suggest we use C-D (with a new
>> disposition type) to define the info-package, and make that new
>> disposition type be the default CD for INFO messages.
> 
> Hmm... interesting idea.  So define a single, global C-D value like "package", which all packages use? 

Yes, that is what I had in mind.

> Wouldn't that limit what a specific package could do? (like how would you get a package that wants render, vs. icon, vs. one which wants signal?)

If it wants bodies like that, which are processed based on their type 
and disposition, it can just include them for processing in their own 
right independent of the method.

For actual info package bodies, the handling should be determined by the 
  definition of the info package, not by the content disposition. If we 
are identifying the body of the info package via cid, then the c-d of 
the info package should be by-reference as defined in the body handling 
draft.

>>> 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?
> 
> -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