My first thought was to agree with Dale, and in fact I already suggested
use of sipfrag. But I already have experience from the refer NOTIFY that
sipfrag info is difficult to take advantage of if you have no guarantee
of what will be included.
IIRC this 199 work was explicitly not expected to solve the full HERFP
problem. Yet if it could serve for that it would be a good thing. Its
just that thrashing out everything that is needed will take a bunch of time.
Also, sending back the whole message will make more data to send in
cases where it often isn't useful.
We could allow a body containing *either* message/sip or
message/sipfrag, and make them both conditional on presence of a
corresponding Accept header in the request. If there was no Accept
header for either then no body would be included. If there was an accept
for both, message/sip would be be preferred. When a sipfrag is returned
in a 199, we could require that it include at least the header line, and
the rest would be at the discretion of the proxy.
Paul
Francois Audet wrote:
> 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
