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

[Robert Sparks <[e-mail]>]

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