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

[Paul Kyzivat <[e-mail]>]

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
>>
>