I think the 488 precedent was unfortunate. If you send SDP offer in a reliable provisional response or a 2xx response, 488 isn't available to you (except I suppose you could put a Reason header in the PRACK or ACK request, but I don't really want to go there).
So I don't think we need we need a way of indicating in an INFO response problems with body content in the request. Let the application send an INFO request in the reverse direction. John > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Paul Kyzivat > Sent: 05 December 2008 05:35 > To: DRAGE, Keith (Keith) > Cc: SIP List > Subject: Re: [Sip] INFO Framework - one pakage per INFO > > Keith, > > OK, I am willing to give up on the Reason phrase. > We already have precedent (488) for a 4xx response indicating trouble > with the content of a body. At the moment it seems to be > specific to SDP. > > The question is: > - can we use 488/606 to mean trouble with some other kind of body? > - or must we reserve 488/606 for SDP. If it is only for SDP: > - can we have a different code to mean "other body trouble"? > - or must we settle for 400 for this? > > I'm willing to live with 400 if that is what others prefer. > I am ambivalent about generalizing 488. > Another code would be nice, but I think we will spin awhile getting > agreement on it. > > Thanks, > Paul > > DRAGE, Keith (Keith) wrote: > > 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 > _______________________________________________ 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
