I don't want to go this way at all. I guess I could live with a 4xx - 6xx response being an implicit indication of failure of a INFO request, even it is caused by the application, rather than analysis at the SIP level.
As soon as you want detail of the failure, that has to be an application level information, and it has to be transferred as an INFO package body, and in my view that still has to go in another INFO request, and not in the response. And for the Reason header proposal/suggestion below, any standards track RFC can define the usage of Reason in response, but to my mind this changes the semantics of the Reason header way beyond its original intention. regards Keith > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Paul Kyzivat > Sent: Tuesday, December 02, 2008 8:28 PM > To: Hadriel Kaplan > Cc: SIP List > Subject: Re: [Sip] INFO Framework - one pakage per INFO > > > > Hadriel Kaplan wrote: > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > >> Sent: Tuesday, December 02, 2008 1:36 PM > >> > >> - *some* error code that can be returned as the response to INFO, > >> which indicates: I didn't like the *content* of the package. > >> If we have a single response that can be used for that, then > > > > Is there some reason you need a different response code > than 415 or 400? Do you think the UAC can take some > different automated action due to getting back a 488-type > response than a 400, for example? > > I hate using the -00 responses because they are so vague. If > worse comes to worse then 400 can be used with a phrase to > describe the actual problem. That can be enough for > debugging. (I don't really expect anybody is going to recover > from these errors.) But if somebody responds to me with this > sort of error I would like to be able to tell that is the > problem without having to talk to a developer of the > responding device. > > The main thing is to give guidance on what error should be used. > > > [I personally hate new response codes - middleboxes always > seems to be > > asked to map them to a different number.] > > > > > >> I expect that Reason can be used to refine it. > > > > Unless this has changed, I thought the Reason header was > only allowed > > in requests? (even though I know people put it in responses, and > > honestly it was silly to only apply it to requests to begin with) > > The Reason header field MAY appear in any request within > a dialog, in > any CANCEL request and in any response whose status code > explicitly > allows the presence of this header field. > > AFAIK there are no responses that allow it. But we could make > a normative change to do so, to whatever response code we > decide should be used. Or we can just punt this to the > reason-phrase of the response. > > Thanks, > Paul > _______________________________________________ > 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
