Howdy, Inline... > -----Original Message----- > From: Adam Roach [mailto:[EMAIL PROTECTED] > Sent: Saturday, October 13, 2007 11:28 AM > To: Hadriel Kaplan > Cc: Francois Audet; IETF SIP List > Subject: Re: What are we arguing about when we say INFO? (was Re: [Sip] > INFO) > > Answering a little bit of your scenario and a little bit of Francois': > > 1. Support must be explicit. Everything described so far makes > indication of the ability to receive an INVITE
I assume you mean INFO, not INVITE? > (or NOTIFY in > Francois' case) implicit in circumstances where such an > implication can be accidental. There are legitimate situations in > which any of the proposed heuristics used to perform such an > implication may legitimately exist and yet not mean that the > recipient is requesting INFO (or NOTIFY) requests. I didn't mean to imply there wouldn't be explicit indication of INFO support for specific event packages. I was saying that's what's missing now and would have to be standardized. > 2. Dialog re-use causes problems. Having multiple usages within a > dialog causes all kinds of confusing interactions between the > usages. Even the ones that are well documented are seldom > implemented correctly. (e.g., if I send a re-INVITE in a dialog > that is shared with a SUBSCRIBE and get a 481, what is gone? The > INVITE usage or the dialog? The dialog, as before, and also the subscription, since the subscription would be tied to the invite's dialog. They would share fate. > What it it's a 480? A 500? Even if > _you_ know where to look it up, will implementors? Even if they > do, are the rules sufficiently labyrinthine that the chances of > misimplementation are high?) The "pushing my buttons" comment came > from your implication that INFO was basically the same as NOTIFY > in this context -- which is imperfect in myriad ways. For example: > such a statement would mean that the INFO usage survives the > termination of the INVITE dialog > (draft-ietf-sipping-dialogusage-06, section 4.2). Yes, it's > probably not what you meant, but (except at the most superficial > level) it's so far away from what you might actually want as to be > a very poor starting point. Right, it's not what I meant. :) > Can this be salvaged? Yes -- and Dean's earlier proposal for INFO > packages does so by making such things explicit. There's another > question about whether it's worth salvaging, and I think that's a little > less cut-and-dried (despite my strong opinion on the topic) -- but I'm > boggled by the extreme pushback to making this negotiation explicit in > the face of clear examples of how things break when we don't. I don't think anyone is pushing back against making negotiation explicit. > (For the record: "Allow-Event" in an INVITE has very well defined > semantics -- it means, "if you send me a SUBSCRIBE for this event > package, I can send NOTIFYs". It is exactly backwards from the meaning > "I can receive NOTIFYs of this type".) Yes I agree... didn't say otherwise. :) -hadriel _______________________________________________ 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
