Hi, I assume there aren't going to be that many headers in the non-2xx error response, and I think most will be identical to what will be used in the 199 anyway - To, From, Call-ID etc.
I am ok with also talking about SIP headers, in addition to response code and possible SDP body, but I don't think we should make this too complex. And, to answer Dale, the intention IS to use sipfrag - no matter how much/little information of the final response we include in the 199. Regards, Christer -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Francois Audet Sent: 13. kesäkuuta 2008 6:23 To: [EMAIL PROTECTED]; SIP IETF Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt And do you think we should specify what are the minimum headers thatshould be carried? What about MIME bodies? There might be cases where they are really important, no? I'm a little worried that the proxy may remove important information. Especially when we extend SIP. Maybe instead we should list the removable headers (e.g., all the ones that are identical to their counterpart in the 199 itself), and then explain "don't remove what you don't understand"? Opinions? On Jun12 2008 20:05 , "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > From: "Francois Audet" <[EMAIL PROTECTED]> > > I really think that this draft should make the inclusion of the original > non-2XX final response in the 199 MANDATORY by the forking proxy. > This would > be in a message/sip body as described in sectin 23.4/RFC 3261. > > (This is outside the scope of the I-D itself.) > > If we envision having the 199 carry information from the associated > failure response, I suggest we use a message/sipfrag body excerpted > from the failure response, rather than copying headers from the > failure response into the 199's headers, or copying the entire failure > response as the body of the 199. > > The syntax of sipfrag is unambiguous but extremely flexible (RFC > 3420): > > sipfrag = [ start-line ] > *message-header > [ CRLF [ message-body ] ] > > Essentially, it is any subset of the headers of the response, > optionally followed by the body. This subsetting capability allows > small responses (e.g., omit the Via's, Call-Id, To, From, > Record-Route's, etc.), as well as making topology-hiding > straightforward. > > It's also inherently extensible, in that if a proxy/UAS decides to add > more headers to the sipfrag, the UAC knows how to identify and/or > ignore them. > > It's also terse, in that carrying any header from the response in a > message/sipfrag body is no longer than carrying it as a header of the > 199 response. > > Dale > _______________________________________________ > 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
