Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction.

[Adam Roach <adam at nostrum.com>]

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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip