Yeah I was thinking the same thing - if there are two ways someone will surely do one and not the other and we'll have problems. I was just thinking someone may come up with one that makes sense for both, in different usage contexts. But I guess that's really 2 different package types that may just happen to share a defining RFC or have the same registered package name, but are really two separate "things". Regardless, I think it's safer to say for now the two package types are unrelated. -hadriel
> -----Original Message----- > From: Adam Roach [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 30, 2007 12:08 PM > To: Hadriel Kaplan > Cc: Dean Willis; sip List > Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for > direction. > > 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
