Re: INFO Framework - one pakage per INFO

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.

I guess you are asserting the above, right?

Its possible that is what the original authors of INFO intended, though 
it isn't entirely clear to me if that is the case.

But the whole problem we have now is that INFO has evolved into 
something that may be different from what was originally intended. At 
this point we are trying to reverse engineer a better defined 
replacement to what INFO has become. If we don't accommodate the usage 
people need, then there will have been no point in doing it at all.

I honestly don't know at this point whether what you specify above is 
sufficient. At the very least, I think we need to *permit* the receiving 
application to signal a problem with the content of the package in the 
response to the info message. Perhaps we don't need to *require* that 
any problem with the content be signaled that way. However I do think it 
would be good to distinguish the case where the content is good from the 
case where the content hasn't yet been acted upon - probably using the 
200/202 response distinction that is used elsewhere.

And I do think we should at least specify how problems with the content 
may be reported in the info response - which error code(s) should be 
used. (For example, 415 has a very specific role here - if the C-T is 
incorrect for the package. But if the C-T is correct and:
(1) the content of the body part is inconsistent with the type
(2) the content of the body part is consistent with the type,
     but the content is semantically inappropriate
then the response to use is not clear. We could extend the definition of 
488 and/or 606 for this purpose, or we could pick something new. But we 
at least ought to make it clear what should be used for these cases.

Anders has argued for allowing content in the body of the INFO response 
to be significant. That is certainly a possibility, but I am not certain 
if the added complexity is justified. If so, then I think it should be 
the responsibility of the info package definition to specify which types 
go in requests, and which (if any) go in responses. But the info-package 
draft will still need to specify that this is legal, and how the body 
part carrying the response is indicated in the response message.

Beyond that, if there is a need for delayed responses I am fine with 
requiring that it be negotiated as distinct packages in each direction.

	Thanks,
	Paul

> 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
_______________________________________________
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