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
