Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field)

On 10/29/11 5:15 PM, Christer Holmberg wrote:
>
> Hi Cullen,
>
>> This started as something for a proxy to indicate what type of  things it could support that could show up in a Proxy-Require and allow a given proxy to indicate to downstream things an additional Proxy-Require level requirement. I thought that sounded like a reasonable idea but we needed to
>> nail down the details of what we were actually talking about.
>>
>> Since then it has slowly morphed into the type of DWIM vs DWIS mechanism that I thought we agreed we did not to do. Keep in mind any UA can act as an embedded proxy and this looks like the feature scheme that I thought was the roughly the core of the DWIM vs DWIS argument.
>
> The requirements clearly say (or, are supposed to say) that the proxy that inserts the support indication must not make any assumptions that a receiver will understand the meaning of it. It is only an "I can do this" indication - NOT an "I have done this" or "I expect you to do this" indication. That has been the intention from day one :)

I guess in this context, DWIS/DWIM stand for "*Does* what I say/mean", 
rather than "Do".

> In that way it is exactly the same as when a UA inserts a feature tag in the Contact header field. The proposal is to allow entities that do not insert a Contact header field to do the same. Nothing more - nothing less.

And there was a huge debate about DWIS/DWIM when 3840/3841 were developed.

The goal was that everybody be able to know what the features meant.
Its debatable whether we achieved that.

Later, a case about DWIS/DWIM came up around "service identification", 
though it wasn't directly connected to callee-caps/callerprefs. It 
culminated in:

RFC 5897: Identification of Communications Services in the Session 
Initiation Protocol (SIP) (Jonathan Rosenberg)

RFC 6050: A Session Initiation Protocol (SIP) Extension for the 
Identification of Services (P-Preferred-Service / P-Asserted-Service) 
(Keith Drage)

The latter includes:

    It should be noted that RFC 5897 [RFC5897] clearly states that
    declarative service identification -- the process by which a user
    agent inserts a moniker into a message that defines the desired
    service, separate from explicit and well-defined protocol mechanisms
    -- is harmful.

    During a session setup, proxies may need to understand what service
    the request is related to in order to know what application server to
    contact or other service logic to invoke.  The SIP INVITE request
    contains all of the information necessary to determine the service.
    However, the calculation of the service may be computational and
    database intensive.  For example, a given trust domain's definition
    of a service might include request authorization.  Moreover, the
    analysis may require examination of the Session Description Protocol
    (SDP).

    For example, an INVITE request with video SDP directed to a video-on-
    demand Request-URI could be marked as an IPTV session.  An INVITE
    request with push-to-talk over cellular (PoC) routes could be marked
    as a PoC session.  An INVITE request with a Require header field
    containing an option tag of "foogame" could be marked as a foogame
    session.

    NOTE: If the information contained within the SIP INVITE request is
    not sufficient to uniquely identify a service, the remedy is to
    extend the SIP signaling to capture the missing element.  RFC 5897
    [RFC5897] provides further explanation.

    By providing a mechanism to compute and store the results of the
    domain-specific service calculation, i.e., the derived service
    identification, this optimization allows a single trusted proxy to
    perform an analysis of the request and authorize the requestor's
    permission to request such a service.  The proxy may then include a
    service identifier that relieves other trusted proxies and trusted
    UAs from performing further duplicate analysis of the request for
    their service identification purposes.  In addition, this extension
    allows user agent clients outside the trust domain to provide a hint
    of the requested service.

RFC 6050 then goes on to define P-Preferred-Service and 
P-Asserted-Service header fields that carry "Service_IDs" represented as 
URNs. IIUC these URNs encapsulate IMS Communication Service Identifiers 
and Application Service Identifiers. It carefully explains that these 
are used simply for optimization and can be derived from other signaling.

But this does relate, because I find that there are also feature tags 
defined for these identifiers:

g.3gpp.icsi-ref: Each value of the Service Reference media feature-tag 
indicates the software applications supported by the agent. The values 
for this tag equal the IMS communication Service Identifier (ICSI) 
values supported by the agent. The Service Reference media feature tag 
is defined to fulfil the requirements for forking to an appropriate UE 
when multiple UEs are registered and dispatch to an appropriate 
application within the UE based upon the IMS communication Service 
Identifier (ICSI) values as stated in 3GPP TS 23.228.

g.3gpp.iari-ref: Each value of the Application Reference media 
feature-tag indicates the software applications supported by the agent. 
The values for this tag equal IMS Application Reference Identifier 
(IARI) values supported by the agent The Application Reference media 
feature tag is defined to fulfil the requirements for forking to an 
appropriate UE when multiple UEs are registered and dispatch to an 
appropriate application within the UE based upon and IMS Application 
Reference Identifier (IARI) values as stated in 3GPP TS 23.228.

Using these as feature tags seems to be an example of "declarative 
service identification" that RFC 5897 proscribes.

Of course that is all for UAs. The examples given in 
draft-ietf-sipcore-proxy-feature-reqs all appear to be of a similar 
nature - I suspect they may in fact *be* ICSIs. And in this case I don't 
see any intent that they be derivable from other signaling and used 
simply as an optimization.

So I think there is indeed something to be concerned with here regarding 
DWIS/DWIM.

	Thanks,
	Paul

> I am happy to add whatever text is needed to make that even more clear.
>
> Regards,
>
> Christer
>
>
>
>
>
>> Anyways, for any mechanisms of this sort, I will be strongly apposed unless the registration mechanism for new tags, features, options or whatever you call them is the same as it is for sip option tags. I have spoken at the mic several times in favor of  what Christer was presenting but it always
>> had that property. This does not and I am strongly opposed to it. Given the previous conversation were in the other context, whatever consensus they may or may not have had does not seem to apply here. If the goal is simply to change what is required to register option tags, I'd be happy to
>> have that conversation.
>
>
>
>
>
> On Oct 28, 2011, at 2:46 PM, Hadriel Kaplan wrote:
>
>> Howdy,
>> I've read this latest draft and I propose we make this a WG item.  I believe there has been strong consensus for this work, from even last year, but also from the following email thread from the SIPCORE Chairs asking for WG consensus:
>> http://www.ietf.org/mail-archive/web/sipcore/current/msg04104.html
>>
>> If this needs a new charter milestone, then I propose a new milestone be added for:
>> "A mechanism to indicate proxy/B2BUA capabilities to both endpoints and other proxies/B2BUAs in the path of a SIP REGISTER transaction or a dialog-forming transaction".
>>
>> There may be some nits/details to argue over in the draft, but I think we can do that as a WG draft/item.
>>
>> As often asked for by WG Chairs when considering new milestones: I also volunteer to spend time/effort in contributing to the work item, and helping the authors by providing text if needed.
>>
>> -hadriel
>>
>>
>> On Oct 28, 2011, at 6:09 AM, Christer Holmberg wrote:
>>
>>>
>>> Hi,
>>>
>>> I've submitted a new version (-03) of draft-holmberg-sipcore-proxy-feature, which suggests a solution based on the proxy feature requirements.
>>>
>>> The MAJOR CHANGE, based on the list discussions, is that the mechanism now uses a new header field, Feature-Caps, rather than existing header fields (Record-Route, Path etc).
>>>
>>> I did not include the "SIP-URI alternative" at this point.
>>>
>>> We will also have to think about the "proxy" terminology, as it has been indicated that entities using the mechanism might not be pure proxies. But, I don't think that should prevent us from moving forward the the mechanism as such.
>>>
>>> Thanks to everyone who has provided feedback and input!
>>>
>>> Regards,
>>>
>>> Christer
>>> _______________________________________________
>>> sipcore mailing list
>>> sipcore@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>