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: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".-----Original Message----- From: Anders Kristensen [mailto:[EMAIL PROTECTED] Sent: Friday, November 28, 2008 9:44 PMIn any event (no pun intended) I don't think the draft adequately dealswith the implications of this model. If errors occurring at higherlayers 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.Yeah, I think Eric's argument is for (2). If they need it, they pay for it.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 oppositedirection. Seems wasteful and requires additional app-level correlation.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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
