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

From: Robert Sparks <[email-masked]>
Date: Mon, 13 Jun 2011 17:09:52 -0500

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

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.

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.

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?

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?

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. 

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)

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. 

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

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?

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?

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?

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Jun 2011 07:38:15 +0200

Hi Robert, 

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

Correct.
 
>   the registering endpoint and the registrar.

Correct.

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

>   only to the other proxies between it and one of the

Currently there is no such requirement.

But, having said that, it's probably something we need to add text about in the draft.

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

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

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

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

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

 
>Again, I'm sure I've missed some important requirements.

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.

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

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.

>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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Jun 2011 07:44:46 +0200

Hi Robert,

In my previous reply, I forgot to comment on your question 3) 

>  messages, what would break?

I am not sure whether any of the existing use-cases would break, but I'd need to look into it.

But, again, the intention is that what applies to UAs should also apply to proxies.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Jun 2011 09:09:30 -0400

(as individual)

Comments inline.

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

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

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

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

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.

> 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" o…

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

> 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

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Jun 2011 16:08:05 +0200

Hi Paul, 

>>But, when we start to discuss how to implement the 
>>direction requirement, that could of course be one possible solution.
> 
>That seems backward.
>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.

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

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

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

>> But, proxies can do routing decission etc based on whatever 
>> policies and message information in my opinion.
> 
>There *is* precedent for mechanisms that *could* be used for 
>routing but that explicitly control the right of proxies to do so.
> 

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

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

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

-----------

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