See below. Keith
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Hadriel Kaplan > Sent: Saturday, November 29, 2008 4:50 AM > To: Anders Kristensen > Cc: SIP List > Subject: Re: [Sip] INFO Framework - one pakage per INFO > > > > -----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". > Correct. And why do something different when MESSAGE already does it that way. > > > 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. Correct A 3xx to 6xx indicates failure to deliver the info package to the application above. The simplest error recovery case which seems to apply in existing usage is no information is sent in the reverse direction regarding application error handling, or it is handled as part of the application protocol, i.e. there is a message embedded in the package which in any case generates a response within the application. _______________________________________________ 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
