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

[Paul Kyzivat <[e-mail]>]

On 11/24/2010 3:27 PM, Christer Holmberg wrote:
> 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?

I don't currently see a problem with permitting this (though I'm 
interested to hear if somebody else sees an issue).

But IMO the current text doesn't suggest to me that this is valid.
So if the desire is for it to be valid it would be good to have some 
text that makes it so.

	Thanks,
	Paul