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

[Christer Holmberg <[e-mail]>]

Hi Paul, 

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

There is no requirement for hiding as such.

There is a requirement for the direction, so if we later choose to use hiding 
in order to implement that requirement, I don't think it would be adding a
new requirement. It would be a way to implement the existing direction 
requirement.


-------------


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

I agree.

I also think I read Robert's question wrong. I read that he asked
whether the indicated feature only applies to the current dialog, or also
to future dialogs, established as part of completely separate transactions 
and session establishements.

My suggestion would be to mandate the feature specification to indicate such scope, and provide the alternatives.

	"The feature specification MUST define whether the feature support indication applies to:

	1. The current dialog;
	2. Any dialog created by the current transaction; or
	3. Any dialog created outside the current transaction."


However, if the feature indication is inserted by a proxy in an initial request for a dialog, there is yet no dialog, so in that case I guess the proxy would not be able to include the support until it receives the response with a To tag.


-------------


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

Of course. But, the intention is not to specify a new mechanim for making 
routing decissions.

But, we could of course say:

	"Proxies MUST be able to make routing decissions based on a feature 
	support indication."


-------------


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


I see 3 alternatives here:

1. We specify that support for a feature can be changed during a dialog; or

2. We specify that support for a feature can never be changed during a dialog; or

3. We specify that the feature specification must define whether support for a feature can be changed during a dialog or not.


I would vote for alternative 1, so the requirement text would say:


	"It MUST be possible for a proxy, during a dialog, to change the indicated support for a feature."


-----------


>>> 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 intention is not to make assumptions about the mechanism, but I guess it's my fault when I talk about feture tags :)

So, please let me re-phrase:

The intention is not to change the "meaning" of existing feature support 
indications, simply allow feature support indications to also be included 
by proxies (in addition to UAs)

Maybe it could be covered by the following requirement:

	"A feature support indication MUST only be used to indicate
	support of a feature, and MUST NOT be used to indicate
	whether procedures associated with the features have been
	applied or not."


---------


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

I guess we could add the following requirement:

	"If a SIP entity receives a feature support indication that it does not 
	understand, it MUST act as if it hadn't received the feature support
	Indication."


Regards,

Christer