Re: [sipcore] Reason as a parameter rather than an escaped header

[Christer Holmberg <[e-mail]>]

Hi,

>> I would suggest that the best way forward is that we keep the current
>> text as is and note that any additional Reason headers that are defined
>> in the future MUST be interpreted in the same manner.  However, I do NOT
>> think we should hold up 4244bis until we get full agreement on adding
>> new Reason header values for applications as I firmly believe it is
>> orthogonal - it can work based upon the current normative approach and
>> interpretation of the Reason in the hi-entries.  We can debate till the
>> end of time (or the end of SIPCORE WG as we did with other broken things
>> in SIP) that this wasn't the right approach, but it is what it is and I
>> think it's time to move forward.
>
>I agree that 4244bis should not be held up because of the new reason
>values draft(s?).
>
>At this point I would just like some clarity whether the *way* reasons
>are used in the examples in
>draft-mohali-sipcore-reason-extension-application-00 - reasons without
>responses - is thought to be *valid* in the context of 4244bis. If the
>answer is NO, then I'll shut up, and let Marianne or somebody else from
>3gpp complain if they think it should be.
>
>If the answer is YES - that usage is considered valid according to
>4244bis, then I still want to know why, and perhaps see some additional
>text to make it clear.

I think we should ask ourselves: assuming we allowed to do what Marianne is proposing, would anything break?

Does anyone really care whether a H-I entry was inserted based on a "real" or "virtual" response? Aren't people more interested in the actual reason value?

Regards,

Christer