> -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > > On Oct 17, 2007, at 8:38 PM, Hadriel Kaplan wrote: > > >> There is a problem if the event type may (or must) use a body in the > >> subscribe. The kpml package falls into this category. :-( > >> The body could simply be included in the message carrying the > >> Exchange-Events header. But that potentially means a bunch of body > >> parts > >> with the recipient having the problem of deciding how each part > >> should > >> be matched to a particular event type. That is more or less the same > >> problem we are trying to solve here, so its not good. Also, it would > >> seem that every time you send a reinvite or update you might have to > >> send these again. > > > > Ya that's bad. If someone wants to define an info-event that needs > > such things, they can define it to exchange it in an INFO when they > > do. > > > > The trick here is to split it into two events packages -- one that > defines the input template, and another that generates key events > within that template.
Sure, but the event package offered in the Invite only needs to be one. And if someone were to actually go do this thing, you could define a parameter to indicate the attachment is the subscription information (vs. the event itself), so that there would need to be only one event name and other events could re-use the parameter instead of having to define 2 event names. But that's getting ahead of ourselves anyway. ;) > If the events in play change, I can't see NOT needing a reINVITE, or > classicaly, new SUBSCRIBE requests. Sure, Paul mentioned a re-Invite restarting the subscriptions, which seemed reasonable. -hadriel _______________________________________________ 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
