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
