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

[Paul Kyzivat <[e-mail]>]

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