On 10/23/07 11:24 AM, Dean Willis wrote:
On Oct 22, 2007, at 8:37 AM, Paul Kyzivat wrote:
So, I think the next question is whether there should be a single
event package definition mechanism for this new approach and for the
3265 type of events, or if these should be entirely disjoint. I
realize existing event package definitions won't be applicable
without at least some tweaks, and not all event types are suitable
for both mechanisms. But I do think there are event types that are
suitable for both mechanisms (e.g. dtmf and dialog) and it would be
better if we didn't require independent definitions for them in both
contexts.
I also favor a single class of event package registrations, and
leaving it to each event package to whether and how it works in each mode.
I think this is a bit odd and potentially dangerous.
If you look at an event package, it defines two classes of information:
a lot of stuff that's pretty specific to 3265 mechanisms, and a syntax
for conveying information. I think the syntax (i.e., MIME type) has a
good chance of being re-usable between event packages and INFO packages.
Everything else won't apply.
The danger come in trying to crowbar in various 3265-related extensions
and applying them to INFO. Partial notifications? Throttling? Filtering?
Etags? You want to figure out how all of those work with INVITE/INFO?
You take on making these things event packages straight up, and that's
where we'll end up.
Define a different set of INFO packages for things that make sense in
INFO, and things are much cleaner. I think you'll find the set of
existing event packages that make sense to "optimize" using INFO is very
small -- with so little overlap, I don't believe you gain anything.
/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
