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
