Re: INFO Framework - one pakage per INFO

Eric Burger wrote:
> PROBLEM 1: If you want to receive package Foo, and Foo has asymmetric 
> information going the other way, then you want to send Foo-Response. 
> Like you say, Foo is not the same as Foo-Response.  Look at KPML as an 
> example of how to do this right.

OK, it can be done using two packages. It seems a bit clumsy to me but 
it'll work.

> 
> PROBLEM 2: You've got it in one! The correlation MUST be at the 
> application layer.  If you have a package that has asymmetric 
> information flows, then you have two choices.  The first is that you are 
> using a dialog-related application-to-application messaging protocol 
> (INFO) because you want to send messages related to *this* dialog. Any 
> response belongs to the request. Fairly straight forward.  Otherwise, if 

I think we're talking past each other. The problem is not correlating to 
the dialog, it's correlating the app-level response to a particular 
app-level request within a given dialog.

> you have a package that is really using INFO for tunneling, then it is 
> most likely already doing some sort of multiplexing, which means you 
> already need some way of identifying what the messages are for and about.
> 
> PROBLEM 3: Another winner! If you care at all about performance, you 
> would NEVER use INFO!!!!  Come on guys - let's look at DTMF: one to 
> sixteen bytes of payload, two thousand bytes of SIP overhead.

I don't think I buy that. If something can be accomplished with one INFO 
request people are going to wonder why they have to have two.

> 
> Of course, the problems listed below are sort of hyper-theoretical.  If 
> a UAC cannot get a message as simple as DTMF right, getting an error 
> message from the UAS saying the UAC got it wrong is not going to help.  
> I'll bet my next $100 dollars that a UAC that needs hints inside of a 
> package to get something as easy as DTMF right will core dump when it 
> gets an error.

Obviously, DTMF is not the problem. If you're only targeting 
applications as simple as DTMF then there's no problem. I think we have 
to expect it'll be used for all sorts of things, though, including 
request-response type apps.

Anders

> 
> I feel as if I am swimming upstream with a school of Red Herrings ;-)
> 
> 
> On Nov 30, 2008, at 4:44 PM, Anders Kristensen wrote:
> 
>> Eric,
>>
>> I understand what you're saying but as I said I think it's problematic 
>> or at least warrants some discussion in terms of where it leads. My 
>> worry is that it makes it significantly more tedious to build on the 
>> info-events work and hence invites people to either ignore the whole 
>> thing or the parts with which they disagree.
>>
>> So let's take the ubiquitous DTMF example. Someone defines a DTMF info 
>> event package and they want the recipient of DTMF events to be able to 
>> indicate to the sender that a particular event could not be decoded. 
>> If I understand you correctly, the error indication would have to be 
>> carried in an INFO going in the opposite direction of the DTMF itself.
>>
>> PROBLEM 1: If errors are to be returned this way it means that both 
>> parties must signal both "Send-Info: dtmf" and "Recv-Info: dtmf". 
>> Hence there's no distinction between the sender of DTMF events and the 
>> sender of responses to DTMF events. Unless the dtmf package is modeled 
>> as two separate INFO event packages.
>>
>> PROBLEM 2: In some cases (most likely more often than not) it will be 
>> necessary to correlate responses to requests. In your model this 
>> correlation has to be done at the app level, that is, in the INFO 
>> payload. However, that will make it difficult to use existing formats 
>> that don't have a convenient place to put such an ID. My employer's 
>> INFO DTMF payload doesn't have a place to put it.  Another frequently 
>> used example is the exchange of JPG images for whatever purpose. 
>> Again, no place to put an app level ID in the INFO payload. You could 
>> put it in the INFO header put that would be a layer violation, right?
>>
>> PROBLEM 3: If all events require a response you end up with twice as 
>> many INFO transactions as is really necessary. That's difficult to 
>> swallow without a really good reason. We could allow 200 respones to 
>> INFO to carry INFO package responses with no adverse affects to 
>> layering so that's not it.
>>
>> Thanks,
>> Anders
>>
>> Eric Burger wrote:
>>> Let us try again.
>>> INFO is a method that *transports* Application-Level "messages".
>>> INFO is NOT a method of Application-Level messaging.
>>> What is the difference?  In TCP, if I send a message, "SIP/2.blah 
>>> blech" to port 5060, TCP will acknowledge delivery of that packet.  
>>> That is like a "200 OK" in SIP.  The process monitoring port 5060, on 
>>> the other hand, will hopefully come back with some sort of "4xx you 
>>> suck" message, encapsulated over TCP, which TCP will acknowledge 
>>> delivery of.
>>> It is bad enough that we are proving Oran's Law: any well-deployed 
>>> protocol becomes a transport protocol. Let us not make it worse and 
>>> make SIP look like Bluetooth with its dozens of profiles for whether 
>>> you are a data device, a speaker, a microphone, a headset (yes, which 
>>> is different than a speaker and a microphone), and so on.
>>> Let INFO be INFO: something that *transports* messages through a SIP 
>>> Proxy network.  Note I say "through a SIP Proxy network."  If you do 
>>> not want to traverse Proxies, use TCP :-)
>>> On Nov 29, 2008, at 2:03 AM, Anders Kristensen wrote:
>>>>
>>>>
>>>> Hadriel Kaplan wrote:
>>>>>> -----Original Message-----
>>>>>> From: Anders Kristensen [mailto:[email protected]]
>>>>>> Sent: Friday, November 28, 2008 9:44 PM
>>>>>>
>>>>>> In any event (no pun intended) I don't think the draft adequately 
>>>>>> deals
>>>>>> with the implications of this model. If errors occurring at higher
>>>>>> layers aren't reported as failure of the INFO request itself, it 
>>>>>> pretty
>>>>>> much follows that the 200 response to the INFO must include a payload
>>>>>> that carries info (sorry, pun not intended here either) on the error.
>>>>> No I think the logic that Eric's arguing for is "you asked for 
>>>>> delivery of this package, and I'm responding with 200 ok because it 
>>>>> was delivered".  In other words treat INFO as a delivery vehicle, 
>>>>> like MESSAGE, and as long as the package was delivered you send a 
>>>>> 200 ok, with no correlation to if/when the package was opened and 
>>>>> read successfully or not by a higher-layer info-package "consumer".
>>>>>> The alternatives would be:
>>>>>> 1) Don't report app-level errors. Perhaps OK for simple packages.
>>>>>> 2) Report outcome in separate INFO requests going in the opposite
>>>>>> direction. Seems wasteful and requires additional app-level 
>>>>>> correlation.
>>>>> Yeah, I think Eric's argument is for (2).  If they need it, they 
>>>>> pay for it.
>>>>
>>>> Well, in the case of (2) I'd say they'd be overpaying. In my view 
>>>> it's a non-starter. People will want to be able to send app-level 
>>>> responses and they won't want to go through a lot of extra trouble 
>>>> to do it. And why should they? I'm thinking we should allow 
>>>> app-level errors to be signalled with INFO error codes and/or allow 
>>>> INFO responses to carry responses along the lines of what CSTA does.
>>>>
>>>> I'll be applying the flame retardant now...
>>>>
>>>> Anders
> 
_______________________________________________
Sip mailing list  https://www.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