Re: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-02

[Mary Barnes <[e-mail]>]

I totally agree that escaping the Reason header is a hack, but that
was a hack that was agreed way long ago.  While it does warp the
definition of the Reason header, I do not think it breaks anything and
this document does NOT define any new values for the Reason header.
The definition of new values is entirely out of scope and orthogonal
to the History-Info header.  The WG does have control over whether new
values are defined.  And, there has still been no conclusion to the
long time discussion as to whether the use of Reason headers is
appropriate in Responses.

I personally feel that this is a rathole and that we will never finish
4244bis if we continue debating this issue.

Regards,
Mary.


On Sun, Nov 7, 2010 at 7:41 PM, Paul Kyzivat <[e-mail]> wrote:
>
>
> On 11/7/2010 6:39 PM, Mary Barnes wrote:
>>
>> I think there is still some confusion here - the Reason is NOT a URI
>> parameter. It is a SIP header field that is escaped in the URI for
>> compactness.
>
> I don't think there is any real confusion. Its just that the terminology is
> awkward. We have parameters to headers, and we have headers that are
> parameters to URIs.
>
>> In earlier versions, we had a separate parameter in the
>> SIP History-Info header for Reason, but Rohan suggested to just escape
>> the existing Reason header in the URI so as not to redefine Reason
>> parameters.
>
> I even remember him making that suggestion. Too bad he isn't around so we
> can wring his neck. I thought it was a hack at the time, but didn't then
> realize how much trouble it would cause.
>
>> 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.
>
>> We originally had two URIs for each hi-entry (the old and
>> the new) . The idea of capturing the "new" is so that you already have
>> the old entry when you do the retarget, noting that when an entity
>> goes to process History-Info, the last entry isn't typically useful,
>> since it should always be the URI in the received request.  So,
>> logically, for each request that is retargeted, you have the "old" and
>> "new", so they really are related and .
>>
>> Also, note that we cannot change this now even if it were the right
>> thing to do due to backwards compatibility.
>
> 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?
>
>        Thanks,
>        Paul
>
>> Mary.
>>
>> On Sun, Nov 7, 2010 at 9:05 AM, Paul Kyzivat<[e-mail]>  wrote:
>>>
>>> The following is giving me heartburn:
>>>
>>> On 11/2/2010 3:25 PM, Mary Barnes wrote:
>>>
>>>>> 2. There is some confusion concerning Reason - sometimes it is referred
>>>>> to as a parameter (e.g., 7.1 3rd bullet, 7.1 last paragraph), sometimes
>>>>> as
>>>>> reason header, sometimes as reason, sometimes as Reason header,
>>>>> sometimes as
>>>>> Reason...
>>>>
>>>> [MB] Logically, Reason is a "parameter" for the hi-entries. However,
>>>> rather than redefine the "parameter", we reuse the Reason header by
>>>> escaping it in the URI - the term Reason header was used for brevity.
>>>> I did add text in the -02 to clarify that in cases where it is
>>>> confusing. I can change all instances to refer to "escape a Reason
>>>> header in the hi-targeted-uri" rather than just "add a Reason header".
>>>> [/MB]
>>>
>>>>> 4. As another general comment, there are too many normative statements
>>>>> using the passive voice, and therefore hard to understand. To quote one
>>>>> example of the sort of ambiguity that can arise from using passive, in
>>>>> 7.3.2:
>>>>> "For retargets that are the result of an explicit SIP response, a
>>>>>   Reason MUST be associated with the hi-targeted-to-uri."
>>>>> Is this saying that an entity that inserts History-Info MUST include in
>>>>> hi-targeted-uri an escaped Reason header field? Or is this saying that
>>>>> a
>>>>> recipient of Reason MUST associate it with an hi-targeted-to-uri. I
>>>>> guess
>>>>> the first interpretation is more plausible, but why not say what is
>>>>> meant,
>>>>> rather than fudging it?
>>>>
>>>> [MB] The Reason header is added to the hi-entry whose
>>>> hi-targeted-to-URI is being retargeted due to the response.  It is
>>>> added by the entity receiving the response.  Note that it is added to
>>>> the entry prior to the entry that is being added as a result of the
>>>> retargeting due to the response - i.e., it's not added to the
>>>> "current" hi-entry.  It's added to the previous.  The sentences
>>>> following the one that you highlight are intended to say just that.
>>>> That's why the term "associated" is loosely used because the next
>>>> sentences are the normative part. So, really, that first sentence
>>>> shouldn't be "MUST be" and would be more accurate to say "is". [/MB]
>>>
>>> I guess this isn't a new concern - its been there all along, but it seems
>>> very wrong to me. (Warning - this is long.) Specifically,
>>>
>>> There is a real difference between Reason as a parameter of an H-I entry
>>> and
>>> an H-I entry containing a URI that contains a Reason header as a URI
>>> parameter. A URI parameter has a specific meaning - it specifies a Header
>>> that is to be incorporated into a request that uses that URI as an R-URI.
>>>
>>> Depending on details of how H-I entries are constructed during
>>> retargeting,
>>> it may be that a retarget URI would contain URI parameters, and those
>>> would
>>> end up in an H-I entry. There could be a Reason header included in the
>>> retarget URI. I *think* the procedures for UAC and proxy imply that the
>>> retargeted request would be constructed first - thus removing embedded
>>> parameters and making them headers in the request - *before* capturing
>>> the
>>> R-URI for H-I, but I'm not certain of that. If not, then there could be
>>> ambiguity about the origin and meaning of a Reason header in an H-I URI.
>>>
>>> Even if that is not a problem, there are potential problems if an H-I
>>> entry
>>> is ever used to construct a new request. For instance, if someone were to
>>> analyze H-I to identify the URI of some entity (say the caller) in order
>>> to
>>> send a new request there, it would lift the URI from H-I and put it into
>>> a
>>> new request. Then the Reason URI parameter would, according to 3261, be
>>> removed and be added as a header to that new request. That isn't
>>> catastrophic, but I think its at least misleading, because:
>>>
>>> The reason is on the wrong URI. The Reason explains why the retargeted
>>> URI
>>> is being used, so it belongs in the message addressed to that URI. It
>>> makes
>>> no sense that it be in a request to the R-URI that, in some prior usage,
>>> was
>>> eventually retargeted.
>>>
>>> Bottom line: the H-I use of Reason as a URI header parameter is a hack
>>> and
>>> an abuse of that mechanism. It might be benign and forgivable if it were
>>> consistent with the intended use of that mechanism. But it seems it is
>>> not -
>>> that it is at best the re-purposing of that mechanism in a case where it,
>>> arguably, might be thought not to conflict with legitimate use of the URI
>>> header parameter mechanism. I'll argue it isn't that benign - that there
>>> are
>>> overlaps where the uses overlap.
>>>
>>> H-I should have had its own header field parameter for this purpose - not
>>> use the Reason header.
>>>
>>> This has ripple effects. Now we have
>>> draft-mohali-sipcore-reason-call-forwarding which is defining new reason
>>> codes which are intended specifically for use with H-I, without any
>>> contemplation of their use in a real Reason header in a request. This is
>>> insanity - but not for the author who is just trying to work within the
>>> existing system. Its just an example of the mess created by the abuse of
>>> repurposing Reason within H-I.
>>>
>>> I commented to the author of draft-mohali-sipcore-reason-call-forwarding
>>> that I felt any extensions to Reason needed to be justified in their own
>>> right, without reference to H-I. In fact what is proposed there *does*
>>> make
>>> sense in its own right, without regard to H-I *if* it is used in the
>>> retargeted request, rather than the request that is about to be
>>> retargeted.
>>>
>>> This could be fitted into H-I. When retargeting, it could be specified
>>> that
>>> a Reason header should be added to the new request, explaining why it was
>>> retargeted. Then whoever makes the H-I entry for that could include in
>>> the
>>> H-I entry for that request the R-URI of the request with any Reason
>>> headers
>>> in that request added to the entry as URI parameters. However this would
>>> be
>>> incompatible with 4244 because it would change which entry contains the
>>> reason.
>>>
>>>        Thanks,
>>>        Paul
>>> _______________________________________________
>>> sipcore mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>
>>
>