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

[Hadriel Kaplan <HKaplan at acmepacket.com>]

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