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
