I'm pretty (actually extremely) unhappy with the idea, but I'll try
not to throw myself on the tracks in front of it.
Taking a tumble down the slope:
These info packages need to be separate from event packages - there
may be some
where you just derive an info package from an event package with a
trival rfc, but it will
_not_ be the case that it will make sense to throw any old event
package's payload into
an INFO like thing like this (think of the mess you'll get into with
anything with a partial
payload, and the bigger mess when you get into the infrastructure of
the framework, including winfo
and eventlists).
And we'd need to specify quite concretely what happens when one of
these INFOs gets rejected.
In most cases, the call is going to have to go away, and I bet that's
going to make a lot of people unhappy.
RjS
On Oct 25, 2007, at 3:06 PM, Adam Roach wrote:
On 10/24/07 2:18 PM, Dean Willis wrote:
I propose we develop a new RFC that extends RFC 3265 and obsoletes
RFC 2976.
This RFC will document use of event bodies in INFO messages
exchanged in dialog usages established by SIP INVITE transactions.
This will include definition of the "Send-Events" and "Recv-
Events" header fields, use of those header fields in INVITE
transactions to provide an offer/answer exchange, definition and
use of a new option tag for this extension, and the needed changes
to the registry established by RFC 3265.
I can support such a plan.
I will continue to argue that the event packages and info packages
should be independent of each other, but that's a minor detail. I
generally agree with the larger picture.
/a
_______________________________________________
Sip mailing list https://www1.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://www1.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
