Re: What are we arguing about when we say INFO? (was Re: [Sip] INFO)

[Adam Roach <[e-mail]>]

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 (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.

   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? 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.

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.

/a

(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".)

Hadriel Kaplan wrote:
> Yeah, that's what I meant when I said in an earlier email:
> "But I think that is something that could be standardized away if we needed to.  One way could be to define an Event package type model for it.  One could argue Info is essentially a Notify, except in a subscription implicitly created by, and tied to the dialog from, an Invite."
>
> But Adam didn't seem to like it.  Not sure why. Adam?
>
> -hadriel
>
>
>   
>> -----Original Message-----
>> From: Francois Audet [mailto:[e-mail]]
>> Sent: Wednesday, October 10, 2007 7:14 PM
>> To: Christer Holmberg; Dean Willis
>> Cc: IETF SIP List
>> Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip]
>> INFO)
>>
>>
>>     
>>> (d) they think it's a waste of resources to establish
>>> multiple additional subscription dialogs (there may be other
>>> type of data than DTMF they are willing to receive) which in
>>> many cases may not even be used during the call (it can not
>>> be assumed that the one sending the subscription always knows
>>> exactly when it will receive events). Maybe DTMF is not the
>>> best example in the world (my fault - I should have been more
>>> generic), but I am sure there could be events which would not
>>> be used in a very high percentage of all calls, but still the
>>> additional subscription dialog(s) would have to be
>>> established - just in case.
>>>       
>> Maybe a way to subscribe to packages within an INVITE dialog would
>> be suitable. You then would get the NOTIFYs withind the dialog, and
>> they wouldn't be out-of-the-blue because you would have subscribed
>> to those events explicitly with some Allow-Event in the INVITE.
>>
>> I know many people will hate this idea but, I do agree with Christer
>> that subscribing to an event package "just in case" when it normally
>> is not used is quite a huge overhead and explain why people just
>> use INFO instead.
>>
>>
>>     
>>> I still strongly think it would be much better to describe
>>> the issues/advantages/disadvantages with BOTH INFO and
>>> events, and study what possible needs to defined related to
>>> negotiation etc, instead of just ignoring the real world and
>>> providing flexibility to people using SIP for their applications...
>>>       
>> I think the idea above would address this and avoid the INFO pitfalls.
>>
>>
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use [e-mail] for questions on current sip
>> Use [e-mail] for new developments on the application of sip
>>     



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip