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

From: "Elwell, John" <[email-masked]>
Date: Fri, 1 Jul 2011 14:30:51 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Robert Sparks
> Sent: 13 June 2011 23:10
> To: SIPCORE (Session Initiation Protocol Core) WG
> Subject: [sipcore] An alternate to the requirements section 
> in proxy-feature-02
> 
> (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.
[JRE] I don't think this makes it clear whether the indication of support is intended to mean:
a) there is a proxy somewhere on the path that supports this feature; or
b) a particular proxy (as identified somehow) supports this feature.
Section 4 of the draft, although not entirely clear, seems to hint at b) because of the mechanisms it suggests, whereas Robert's text leaves it completely open. I think we need to nail down this aspect of the requirement better.

John

> 
> 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? 
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 2 Jul 2011 01:08:44 +0200

Hi,

Please note that I have submitted draft-ietf-sipcore-proxy-feature-reqs-00.

>Section 4 of the draft, although not entirely clear, seems to hint at b) because of the mechanisms it suggests, whereas Robert's text leaves it completely open. I think we need to nail down this asp…

The intention is b). I'll look how to clarify it.

Regards,

Christer