Yes I think that makes a lot of sense.  So an RFC for event foo, would say 
whether it applies to Invite-usage and can be sent in an INFO.  But what if a 
new event does not make sense in a true Subscribe model?  Would 3265 mandate 
that an event definition support the event in a Subscribe-based usage?  I can 
think of at least two event types that would make sense in an INFO model but 
not in a Sub/Not.

-hadriel


> -----Original Message-----
> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 22, 2007 9:37 AM
> To: Brian Stucker
> Cc: Michael Procter; Hadriel Kaplan; Elwell, John; sip; Adam Roach
> Subject: Re: [Sip] INFO
>
> I'm clearly in the minority here, in preferring NOTIFY over INFO.
> (Minority of one?)
>
> I agree that it is impossible to make definitive claims that something
> is easy to implement when talking about some hypothetical sip stack. So
> I will refrain from making such a claim from now on.
>
> I also agree that the name of the method is secondary to getting the
> functionality right. So I am fine with leaving the decision about the
> method until everything else is worked out.
>
> 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.
>
> What do others think of that?
>
>         Thanks,
>         Paul
>
> Brian Stucker wrote:


_______________________________________________
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

Reply via email to