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
