Re: INFO Framework - one pakage per INFO

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