Re: INFO Framework - one pakage per INFO

That all sounds good to me.

Thanks,
Anders

Paul Kyzivat wrote:
> 
> 
> Hadriel Kaplan wrote:
>> Right, so that's one possible direction to go for INFO as well: don't 
>> mandate any model in the base spec.  Keep it simple.  Let the packages 
>> do their own dirty work, under review.
>> -hadriel
> 
> I'm fine with that, as long as we leave some basic hooks for the 
> packages to use. In particular:
> 
> - *some* error code that can be returned as the response to INFO,
>   which indicates: I didn't like the *content* of the package.
>   If we have a single response that can be used for that, then
>   I expect that Reason can be used to refine it.
> 
> - don't define the meaning of a body in the response, but
>   don't forbid it either. Let the significance be defined by
>   the package.
> 
> - perhaps draw the distinction between 200 and 202 responses,
>   where 200 means the package has been "accepted" by the receiving
>   application and 202 means the package has simply been "queued"
>   for the receiving app. (I don't know if this distinction is
>   useful here or not.)
> 
>     Thanks,
>     Paul
> 
>>> -----Original Message-----
>>> From: DRAGE, Keith (Keith) [mailto:[email protected]]
>>> Sent: Tuesday, December 02, 2008 8:40 AM
>>> To: Hadriel Kaplan; Eric Burger; Anders Kristensen
>>> Cc: SIP List
>>> Subject: RE: [Sip] INFO Framework - one pakage per INFO
>>>
>>> I don't remember any history of this, but would contend that the way RFC
>>> 3903 text is written in regards to bodies in responses is tantamount to
>>> saying "bodies in responses is for further study". It is basically
>>> trying to say, if in implementing this you receive a body in a response,
>>> then don't start failing things at the SIP transaction level.
>>>
>>> And remember, this requires an event package to define the usage, and
>>> you need RFCs to define event packages, so I suspect any expert review
>>> or above would take a very deep look at any such definition.
>>>
>>> Keith
>> _______________________________________________
>> 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