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

[Mary Barnes <[e-mail]>]

I think we are somewhat ratholing here.  A few responses inline below [MB].

On Thu, Nov 11, 2010 at 9:00 AM, Paul Kyzivat <[e-mail]> wrote:

> inline
>
>
> On 11/11/2010 5:09 PM, Worley, Dale R (Dale) wrote:
>
>  But it looks like we need to continue this hack for compatibility.  So let
>> us:
>> - publicly state this is a hack
>> - not repeat the mistake in other cases
>>
>
> yep
>
>
>  The Reason header is intended to tag the Reason why the hi-targeted-to
>>>> URI was retargeted and thus it goes with the "old" hi-entry versus the
>>>> "new" one.
>>>>
>>>
>>> Just stating it that was exposes the problem.
>>> The intent of the Reason header is specified in RFC3326.
>>> Any use that isn't consistent with that is an abuse.
>>> Its intended to indicate why a *request* is being sent.
>>>
>>
>> Yes, but it quickly mutated into a carrier in responses to provide
>> additional information as to why the response was generated.
>> Consider:
>>
>>    draft-jesske-dispatch-reason-in-responses-02
>>
>
> 1 - quickly? The Reason header is old.
> 2 - did I miss something? what is the status of the jesske draft?
>    isn't it still just an individual draft?
>
>
>  So then we allow it continue to metastasize, e.g. by defining new Reason
>>> values that aren't ever expected to be used in requests, and that
>>> wouldn't make any sense if they were?
>>>
>>
>> That seems likely.  It's probably a good thing.  It's a bit sketchy to use
>> the same header to describe why a request was generated and also why
>> a response was generated, but it's not going to cause confusion.
>>
>
> I disagree its a good thing.
>
> If we need new response codes we can define them, so we shouldn't in
> general need new response codes to clarify response codes.
>
> Perhaps the Q.850 stuff is a special case since we are there relating
> things from a different and independent namespace. Even then its a bit dicy.
>
> But my point wasn't reasons for requests vs. reasons for responses. It was
> about reasons for requests vs. reasons for H-I entries. And IIUC the reasons
> in Marianne's draft are *not* reasons for responses. They are reasons for
> retargeting, generally without there having been any response. They are
> indeed a reason for a request. And it is a reason for the request with the
> new target, not the reason for the request with the old target.
>
The intent of the Reason in the HI entries is to capture the reason a
request was retargeted.  The current normative text is the Reason (escaped
header, header field, whatever) in the HI-entry is populated based on SIP
Response codes and any other Reason header (e.g., Q.850) that might be
associated with the request.  The Reason is included in the hi-entry with
the hi-targeted-to-uri that was retargeted (i.e., the old) versus the
hi-targeted-to-uri in the hi-entry to which the Request is being sent.  We
should not change this due to backwards compatibility AND I think any new
Reason values that we want to add to the hi-entries need to be added
consistently.

Thus IF there is agreement to add new Reason header field values for
applications, then if those are used to populate the hi-entry, they should
also be interpreted in the hi-entries to correspond to the
hi-targeted-to-uri that was retargeted (i.e., the old URI that is lost)
based on a decision that the request be associated with a specific
application RATHER than the Reason being the application associated with the
hi-entry with the hi-targeted-to-uri to which the request is being sent
(i.e, the new URI).

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.

Regards,
Mary.


>
>        Thanks,
>        Paul
>