OK. Adam has persuaded me that overlap with relevant existing event
packages is negligible (none, or perhaps KPML - more on that later) and
that recommending that new ones be created to support two mechanisms is
a bad idea.
So that leaves the question of whether to nail down a negotiation
mechanism for "info-packages".
The obvious first case to consider is DTMF. The problem of course is
that we already have two standard methods for transfering DTMF
(telephone-events in RTP, and KPML subscriptions.) So standardizing use
of INFO for this would mean standardizing a *different* way than KPML.
And most likely it would be different than the non-standard way(s?) of
using INFO for DTMF in the wild. Is that going to do anybody any good,
or just give people more heartburn? Perhaps we should either bless what
is being used or else continue to treat it with benign neglect.
Once you get past that one, I think we might as well wait until somebody
has something else they want to exchange this way to before getting too
caught up in inventing machinery.
Paul
Adam Roach wrote:
On 10/30/07 10:52 AM, Hadriel Kaplan wrote:
I do assume from a SIP stack model perspective and its application
user that there would need to be some form of clear differentiation of
subscription Event Package support/usage, and one for Info-Packages.
So I guess separating these from Subscription-type Event packages
makes sense in that context. But does that mean one can't define a
new package that works both ways?
One could. [1]
My argument is that one shouldn't. Because when one does, one creates
two ways to do the same thing. Which means that implementors either
choose a single mechanism (and fail to work with the other -- this is
bad) or are forced to implement both mechanisms (doubling implementation
cost -- this is also bad).
Why are we putting forth mechanisms that force implementors to choose
between two bad options?
The examples you cite clearly work better in an INVITE context -- so
define them that way, and leave SUBSCRIBE out of it.
/a
----
[1] One can also pound screws into wood with a hammer -- the measure of
whether to do something isn't "can we", but "what happens if we do?"
_______________________________________________
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
