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

Hadriel,

OK, I guess I'm way late on this.

This bis is a chance to fix problems isn't it?
We should at least talk about the problems and see if we can figure some 
way around them. We may have to grandfather some behavior, but couldn't 
we define a better alternative and deprecate the broken stuff?

And if 3gpp is doing something that isn't even consistent with 4244, 
that is *their* problem, and Acme's opportunity.

	Thanks,
	Paul

On 11/7/2010 8:05 PM, Hadriel Kaplan wrote:
>
> Yes, it sucks.  And it's wrong.  I raised it last year here:
> http://www.ietf.org/mail-archive/web/sipcore/current/msg00612.html
>
> But we're stuck with it for backwards compatibility.
>
> And it's even worse than you think.  Apparently 3gpp uses H-I with a "cause" URI param a la RFC 4458, rather than an embedded Reason header's cause param.
>
> On the other hand all of this will help me sell more boxes, so I think I'll shut up now...
>
> -hadriel
>
> On Nov 7, 2010, at 10:05 AM, Paul Kyzivat 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
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>
>