Re: [sipcore] An alternate to the requirements section in proxy-feature-02

(as individual)

Comments inline.

On 6/14/2011 1:38 AM, Christer Holmberg wrote:
>
> Hi Robert,
>
>> (As an individual contributor)
>>
>> I appreciate version -02 of this document adding a
>> requirements section.
>>
>> I believe it will be important to get a common understanding
>> of what's needed in order to be able to understand the impact
>> of the proposed mechanism and whatever it may evolve into.
>>
>> So far, I'm still having a hard time teasing out the
>> requirements from the text.
>>
>> Here's a stab at a mechanism free statement of the
>> requirements that I can infer from the proposed mechanism,
>> along with several questions. Please help clarify the
>> requirements where my inferences are wrong. Please also point
>> out where there is a requirement these don't cover.
>>
>> 1) There is a requirement for a proxy to be able to
>>    indicate support for a capability to other proxies
>>    in the path of a dialog forming transaction and to
>>    the two endpoints of that transaction.
>
> Correct.
>
>> 2) There is a requirement for a proxy to be able to
>>    indicate support for a capability to other proxies
>>    in the path of a REGISTER transaction, and to both
>>    the registering endpoint and the registrar.
>
> Correct.
>
>> 3) There is a requirement for a proxy to be able to
>>    indicate that the support for the capability applies
>>    only to one of the endpoints establishing a dialog.
>
> Partly correct. The requirement talks about only to one DIRECTION. That includes both one of the endpoints, but also possible proxies in between.
>
>
>> Question 1: Is there a requirement for a proxy to be able
>>    to indicate that support for a capability applies
>>    only to the other proxies between it and one of the
>>    endpoints?
>
> Currently there is no such requirement.
>
> But, having said that, it's probably something we need to add text about in the draft.
>
>
>> Question 2: Is there a requirement for a proxy between
>>    Alice and Bob to hide that it's supporting a capability
>>    for Alice from Bob, or is the requirement only that
>>    Bob be able to tell this statement was not for him?
>
> Currently there is no explicit requirement to be able to hide the support.
>
> But, when we start to discuss how to implement the direction requirement, that could of course be one possible solution.

That seems backward.
Either there is a requirement, or not.
Ideally all the requirements can be identified *before* discussing the 
mechanism. Of course its not unheard of to discover missing requirements 
while discussing mechanism, but we probably should not be expecting that 
to happen.

The resulting mechanism may of course have properties not discussed in 
the requirements. But they only have bearing if there are competing 
mechanisms that meet the requirements.

>> 4) There is a requirement that a proxy indicating support
>>    for a capability in a dialog forming transaction will
>>    support that capability for the duration of all dialogs
>>    the transaction may create.
>
> The intention is that whatever applies to a UA also applies to a proxy.
>
> See more on this in my reply to 6).

*If* we were talking about mechanism now, and in particular about 
extending an existing mechanism, then architectural consistency might be 
an important issue.  (E.g. the mechanism should behave the same way when 
applied to proxies as it does when applied to UAs.)

But we are talking about *requirements* now. So there either is such a 
requirement, or not. The presence or absence of the requirement can 
affect the mechanism choice.

So, is there such a requirement, or not?

>> 5) There is a requirement that other proxies be able to
>>    use the indication from 1) or 2) to affect routing
>>    decisions and other proxy handling of the request
>>    (such as choosing which capabilities these other proxies
>>     may choose to indicate as part of this transaction)
>
> There is no explicit requirement for that.
>
> But, proxies can do routing decission etc based on whatever policies and message information in my opinion.

Again, either there is a requirement, or not.

There *is* precedent for mechanisms that *could* be used for routing but 
that explicitly control the right of proxies to do so.

So I think it is a fair question to ask.

>> 6) There is no requirement that the capabilities supported
>>    at any proxies involved in a dialog be able to change
>>    in the course of the dialog.
>
> Again, the intention is that whatever applies to a UA also applies to a proxy.

> But, having said that, I am not sure it is clear even for UAs. For example, if a UA indicates support of feature x in the initial INVITE, but does not indicate the support in a re-INVITE/UPDATE/whatever-target-update-request, does it mean that the UA does not support the feature anymore?
>
> So, maybe each feature definition (no matter if the feature tag is used by, or defined for, a UA or a proxy) should explictily specify the scope, when used as part of a dialog forming transaction and/or a registration transaction.

As time goes on we learn that much of what was defined in the past was 
underspecified. We are doing our best to learn from those mistakes and 
be more precise going forward.

So again, rather than making assumptions about the mechanism, can we 
just decide if this is a requirement or not? And if the requirement is 
that the duration of guarantee vary from capability to capability, then 
lets call it out that way.

>> 7) There is no requirement to negotiate support for a
>>     capability. (For example, there is no requirement for there
>>     to be a way for an initiating endpoint, or a proxy along the path
>>     to indicate "make this request fail unless something along
>>     the path supports X")
>
> Correct. For that you would need to define an option-tag, to be used with Require/Proxy-Require.
>
>
>> Question 3: It appears that the capability indication is
>>    only used when processing the initial request, and appears
>>    in subsequent in-dialog signalling in the current proposed
>>    mechanism because that's what 3261 requires. If the mechanism
>>    evolved such that the indication appeared only in the dialog
>>    establishing transaction, and not in any subsequent in-dialog
>>    messages, what would break?
>
>
>
>> --------
>>
>> Again, I'm sure I've missed some important requirements.
>> What are they?
>
> When reading your text, I am not sure we need additional requirements. However, it does seem that we DO need more clarfication text on certain topics. The intention is not to change the "meaning" of feature tags etc, simply allow them to also be included by proxies (in addition to UAs), and the only proxy specific issue (which I have identified so far) is that we need to deal with the direction issue - for which we do have a requirement.

Again, lets please set aside assumptions about the mechanism when 
discussing requirements.

>> The currently proposed mechanism appears to run against the
>> advice in RFC5897, particularly Do What I Say vs Do What I
>> Mean. It appears to provide a declarative service identifier
>> (such as g.3gpp.srvcc-alerting), and it's not clear yet what
>> an endpoint or intermediary that doesn't know what the
>> identifier means should or shouldn't do. Is it the intent to
>> require any element that doesn't recognize a value to behave
>> exactly as it would if there were no value present at all? If
>> so, what keeps us from having the same
>> service/feature/capability defined in separate namespaces
>> resulting in non-interoperable islands?
>
> The intention is to only indicate SUPPORT of a feature.

The point remains. Indicating support for something undefined has 
exactly the same issues as asking to do something undefined.

	Thanks,
	Paul

> It MUST NOT be assumed that other entities understand the feature tag (again, for that you would need an option-tag in a Require/Proxy-Require header field). If entities don't understand the feature that they should just go on as if the feature tag wasn't there.
>
> Again, that is the same as when a UA indicates support of a feature.
>
>
>
>> It's also easy to infer from the examples (like 1.3) that
>> there is a requirement for a proxy to say much more than "I
>> support capability X". In at least one case, it appears to be
>> saying "I am doing X - and other X-capable things MUST NOT do
>> X". It would be good to avoid the confusion associated with
>> when the presence of an option tag in Supported/Required
>> means that the extentions associated with the tag is actually
>> being used. Would it be acceptable to say that the presence
>> of a proxy capability indication says nothing about whether
>> the capability is being used?
>
> I will take a closer look at the examples and 3GPP use-cases. I have tried to make it very clear in 3GPP that the mechanism only provides a way to say:
>
> "I CAN do this"
>
> ...but not:
>
> "I AM doing this"
>
> Thank You very much for the excellent and productive feedback! :)
>
> Regards,
>
> Christer
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>