Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators

From: Christer Holmberg <[email-masked]>
Date: Fri, 25 Oct 2013 18:03:55 +0000

(Moving to the SIPCORE list)

Hi,

> Also all the FCIs in the same Featire-Caps header field apply to the same entity.
>
> E.g. that for
>
> Feature-Caps: *, +FCI1; +FCI2, *; +FCI3; +FCI4
>
> FCI1 and FCI2 apply to one logical entity
> and FCI3 and FCI4 apply to a different logical entity

Correct.

But, in general, keep in mind that a FCI value with an address does NOT automatically indicates the address of the entity supporting the feature - unless you explicitly say so in the FCI definition. It only provides an address associated with a feature, and you need to define the semantics of it in the FCI defintion.

Example:

I support the find-Paul feature, and I insert a FCI:

    Feature-Caps: *, +g.find-paul="sip:[email-masked]"

Now, in this case the address does NOT point to my entity, but to Paul's entity. My entity supports a feature, which provides Paul's address.

So, if the FCI says:

    Feature-Caps: *, +g.find-paul="sip:[email-masked]";+sip.methods="invite"

...it doesn't automatically mean that I can contact Paul using INVITE. By default it means that MY entity supports the INVITE method - which from the find-paul feature perspective is useless information.

So, in the FCI specification for +g.find-paul, I would have to explictily describe how the FCI works in conjunction with other FCIs. I would have to explicitly say that, when used together +sip.methods, the +sip.methods indicates which SIP methods I can use to contact Paul (using the address provide in the +g.find-paul FCI).

Section 5.3.8 in RFC 6809 also says:

    "If there is additional information about the feature-capability
       indicator, it is recommended to describe such information.  It can
       include, for example, names of related feature-capability indicators."

So, in your case, I think the +g.3gpp.see_trans FCI specifiction would have to specify how the FCI is used in conjuntion with other FCIs, including the +sip.method FCI.

Something like: "When the session transfer request is sent to the address indicated by the FCI value, the +sip.method FCI indicates which SIP methods can be used."

Regards,

Christer

From: Christer Holmberg [mailto:[email-masked]]
Sent: Friday, October 25, 2013 12:01 PM Central Standard Time
To: Andrew Allen; Paul Kyzivat <[email-masked]>; Gonzalo Camarillo <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators

Hi,

>I think we can have an FCI
>
>Feature-Caps: *;+g.3ggp.sess_trans=”sip:[email-masked];gr”
>
>Indicating that the entity supports 3GPP session transfer and the address where you send the session transfer request is sip:[email-masked];gr<mailto:[email-masked];gr>

Correct. The FCI itself indicates support of session transfer feature, and the FCI value indicates the address associatd with the feature.

>Also if I have:
>
>Feature-Caps: *;+g.3ggp.sess_trans=sip:[email-masked];gr; +sip.extensions=”replaces, tdialog”; +sip.methods=”invite, refer, bye, options, update, prack”
>
> This means the entity supports 3GPP session transfer and the address where you send the session transfer request is sip:[email-masked];gr<mailto:[email-masked];gr>...

Correct.

> ...supports the replaces and target dialog extensions and supports the following methods - invite, refer, bye, options, update, prack.

Technically, what it means is that there is *AN* entity which supports the features listed above, and the address is where you are to send the session transfer request in order to trigger the 3GPP session transfer feature.

Regards,

Christer

From: Christer Holmberg [mailto:[email-masked]]
Sent: Friday, October 25, 2013 10:25 AM
To: Paul Kyzivat; Andrew Allen; Gonzalo Camarillo
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators

Hi,

As Paul said, if one needs to provide address information associated with a FCI, the address information cannot be a FCI of its own. It needs to be a value of the FCI for which it is associated.

Something like:

Feature-Caps: *;+audio="sip:[email-masked]"

(Also note that the "+" sign is mandatory for all FCIs - no matter which registry tree they belong to)

Regards,

Christer

________________________________
From: Paul Kyzivat [[email-masked]]
Sent: Friday, 25 October 2013 5:06 PM
To: Andrew Allen; Gonzalo Camarillo
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Christer Holmberg; [email-masked]<mailto:[email-masked]>
Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators
Andrew,

(I see this is still on the private thread. I'll reply here, but this
exchange should probably be reposted to the sipcore list as part of the
public discussion of the draft.)

On 10/24/13 10:41 PM, Andrew Allen wrote:
>
> Paul
>
> I am happy to do a revision with more details on the semantics of the capability indicators. However I don't think it should be held to a very much higher bar than the details in RFC 3840 and the other media feature tag RFCs regarding the meaning of those tags.

Keep in mind that the driving force for the definition of feature tags
in 3840 was in support of callerprefs (3841). So the context for the use
of feature tags was that they would be placed on Contacts in REGISTER
requests. So you can interpret the definitions in that context: that a
request sent to an AOR using callerprefs can affect the choice of which
device the request goes to according to the capabilities it wants. In
that context audio, video, isfocus all make sense.

Their use on Contacts in dialogs was derivative to that: because
callerpref support is optional, there is no guarantee that the device
you reach via callerprefs will have the capabilities you requested. So
the values in the contact help confirm what you got.

Of course they have since been used other ways. And the descriptions of
them don't necessarily reflect that. IMO that is a defect due to the
evolution of use.

I'm looking for the same sort of context for use with the feature-caps.

In private discussion you indicated to me that you expected the feature
caps to be grouped - with one of them giving the URI of the device that
the other tags apply to. I guess this would end up looking something like:

   Feature-Caps: *;g.uri="sip:[email-masked]";audio
   Feature-Caps: *;g.uri="sip:[email-masked]";audio;video;isfocus
   Feature-Caps: *;g.uri="sip:[email-masked]";text

(I'm making up g.uri for the example.)

And then presumably somebody on the signaling path will "shop" in the
feature caps for the capabilities it wants, and then send a request to
that URI, with the expectation that the UA responding will have those
capabilities.

> The semantics should be no different than those of  the corresponding existing media  feature tag if it is present in the Contact header.

Note that 6809 says:

    When a SIP entity receives a SIP request, or response, that contains
    one or more Feature-Caps header fields, the feature-capability
    indicators in the header field inform the entity about the features
    and capabilities supported by entities in the SIP message signaling
    path.  The procedure by which features and capabilities are invoked
    are outside the scope of this specification and MUST be described by
    individual feature-capability indicator specifications.

    A Feature-Caps header field value cannot convey the address of the
    SIP entity that inserted the Feature-Caps header field.  If
    additional data about a supported feature needs to be conveyed, such
    as the address of the SIP entity that indicated support of the
    feature, then the feature definition needs to define a way to convey
    that information as a value of the associated feature-capability
    indicator.

This was discussed at length while that RFC was under consideration. Yet
the definitions of the tags in *this* draft don't specify that.

> The registration templates currently reference the RFC 3840 and the other RFCs that define the other media feature tags that correspond to these feature capability indicators.

And those definitions were written to be understood in the context of
3840/3841. They make sense in that context, but not in *this* context.

        Thanks,
        Paul

> But if more explicit detail is required then I can add some more text  or alternatively remove the less important ones if they are going to become rat holes. The ones I regard as really important and urgent are sip.methods, sip.extensions and sip.events the meaning of which I think should be quite clear.
>
> Andrew
>
> ----- Original Message -----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, October 24, 2013 04:44 PM Central Standard Time
> To: Andrew Allen; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Paul Kyzivat <[email-masked]<mailto:[email-masked]>>
> Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators
>
> On 10/24/13 4:07 PM, Andrew Allen wrote:
>>
>> Paul
>>
>> Ok
>>
>> So we are basically where I thought we were at when I submitted the draft.
>>
>> Maybe you, Adam, Gonzalo, Richard, Christer and I (plus anyone else who indicates interest) can have some offline discussion in Vancouver on whether and how to progress this.
>
> As I indicated again on the sipcore list, I found the that the draft
> didn't explain nearly enough to allow meaningful use of these.
> I know you replied, and I will continue the conversation there.
> But I will be opposed to these until and unless the draft (and notably
> the descriptions of the tags) are clear about how one could figure out
> what can do in the presence of the tags that one couldn't do without
> them. AND, that the behavior that suggests doesn't "break" sip. (E.g.,
> by advocating a new and incompatible way to do something.)
>
> We can continue this on the sipcore list.
>
>        Thanks,
>        Paul
>
>> Andrew
>>
>> ----- Original Message -----
>> From: Paul Kyzivat [mailto:[email-masked]]
>> Sent: Thursday, October 24, 2013 02:54 PM Central Standard Time
>> To: Andrew Allen; Gonzalo Camarillo <[email-masked]<mailto:[email-masked]>>
>> Cc: Richard Barnes ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; Adam Roach ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; Christer Holmberg ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; Mary Barnes ([email-masked]<mailto:[email-masked]>) < [email-masked]<mailto:[email-masked]>>
>> Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators
>>
>> On 10/24/13 2:17 PM, Andrew Allen wrote:
>>> Paul
>>>
>>> That is fine. Although Mary in her reply to me seemed to indicate maybe there was a possibility to use some of the DISPATCH spare time for a SIPCORE session for this. Is that a possibility?
>>>
>>> I already replied to your post
>>
>> I discussed that with Adam. We decided we can't set a precedent to spin
>> up a session to discuss a draft that hasn't had substantial (any) list
>> discussion.
>>
>> But list discussion is always welcome.
>>
>>       Sorry,
>>       Paul
>>
>>> Andrew
>>>
>>> -----Original Message-----
>>> From: Paul Kyzivat [mailto:[email-masked]]
>>> Sent: Thursday, October 24, 2013 1:31 PM
>>> To: Andrew Allen; Gonzalo Camarillo
>>> Cc: Richard Barnes ([email-masked]<mailto:[email-masked]>); Adam Roach ([email-masked]<mailto:[email-masked]>); Christer Holmberg ([email-masked]<mailto:[email-masked]>)
>>> Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators
>>>
>>> Andrew,
>>>
>>> I spoke with Mary about it, and we concluded that dispatch isn't right for this. (In addition to being clearly sipcore, it didn't meet the deadline for dispatch.) I was wrong to encourage you that way.
>>>
>>> So no official live discussion in Vancouver. (But informal discussion
>>> fine.)
>>>
>>> I'll resend my private comments to the sipcore list to kickstart some discussion there.
>>>
>>>      Thanks,
>>>      Paul
>>>
>>> On 10/24/13 1:01 PM, Andrew Allen wrote:
>>>> I just emailed Mary asking for agenda time. Should I cancel that request?
>>>>
>>>> -----Original Message-----
>>>> From: Gonzalo Camarillo [mailto:[email-masked]]
>>>> Sent: Thursday, October 24, 2013 1:00 PM
>>>> To: Paul Kyzivat
>>>> Cc: Andrew Allen; Richard Barnes ([email-masked]<mailto:[email-masked]>); Adam Roach
>>>> ([email-masked]<mailto:[email-masked]>); Christer Holmberg ([email-masked]<mailto:[email-masked]>)
>>>> Subject: Re: New sipcore draft submission
>>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>>
>>>> Hi Paul,
>>>>
>>>> given that you think this belongs to SIPCORE, I do not see the need to run it through DISPATCH. Please, start technical discussions on the draft on the SIPCORE list.
>>>>
>>>> Thanks,
>>>>
>>>> Gonzalo
>>>>
>>>> On 22/10/2013 9:11 PM, Paul Kyzivat wrote:
>>>>> On 10/22/13 1:00 PM, Andrew Allen wrote:
>>>>>> Paul
>>>>>>
>>>>>> Thanks for reviewing the draft already and giving me early feedback.
>>>>>>
>>>>>> My responses below inline (prepended with [AA).
>>>>>>
>>>>>> Can I ask the ADs to determine ASAP if this needs to go to DISPATCH
>>>>>> first or not. As outlined below my view is that it is unnecessary
>>>>>> for every little thing to go to DISPATCH as this just creates
>>>>>> additional delay and overhead. If it is to be discussed in DISPATCH
>>>>>> then I definitely would want agenda time atIETF#88 for this.
>>>>>
>>>>> Having now seen Andrew's responses to my initial questions, I think
>>>>> this
>>>>> *needs* to be carefully considered by sipcore. IMO this has the
>>>>> potential to create a dialect of sip that is incompatible with normal
>>>>> usage. (Maybe IMS has already done that. But this will make it
>>>>> worse.)
>>>>>
>>>>> But if there is a desire to discuss it publicly in Vancouver then
>>>>> dispatch is the opportunity and so some discussion on the dispatch
>>>>> list in advance of that would be appropriate.
>>>>>
>>>>> I'll defer to the ADs on this.
>>>>>
>>>>> More inline.
>>>>>
>>>>>> Andrew
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Paul Kyzivat [mailto:[email-masked]]
>>>>>> Sent: Tuesday, October 22, 2013 10:33 AM
>>>>>> To: Andrew Allen; Richard Barnes ([email-masked]<mailto:[email-masked]>); Gonzalo Camarillo
>>>>>> ([email-masked]<mailto:[email-masked]>); Adam Roach ([email-masked]<mailto:[email-masked]>)
>>>>>> Subject: Re: New sipcore draft submission
>>>>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>>>>
>>>>>> Andrew,
>>>>>>
>>>>>> On a legalistic note, its questionable to me whether this kind of
>>>>>> action falls within the scope of sipcore. OTOH, among existing wgs,
>>>>>> sipcore is probably the best suited to discuss the proposal. We
>>>>>> could take it to DISPATCH. I think DISPATCH has extra time in its
>>>>>> agenda for Vancouver, so that might be one option for you. But then
>>>>>> I don't know where dispatch would dispatch it. It may be that AD
>>>>>> sponsored is the best way to go.
>>>>>>
>>>>>> [AA] It seemed to me that sipcore was the right place. This draft
>>>>>> registers feature-capability indicators in a registry that was
>>>>>> created by a sipcore RFC (RFC 6809). You could in my view make an
>>>>>> argument that this should even have been done as part of RFC 6809.
>>>>>
>>>>> If this was just a matter of registering some new feature caps that
>>>>> were not controversial, then I don't think sipcore needs to be involved.
>>>>>
>>>>> But as I mentioned above, I do consider these controversial.
>>>>>
>>>>>> Discussing it now on the dispatch list would be a good start toward
>>>>>> discussing it at the dispatch session.
>>>>>>
>>>>>> [AA] Can I ask the ADs to determine if this needs to go to DISPATCH
>>>>>> first or not. My view is that it is unnecessary for every little
>>>>>> thing to go to DISPATCH as this just creates additional delay and overhead.
>>>>>> This just registers some indicators in an existing IANA registry and
>>>>>> is not (or should not be IMHO) a major project.
>>>>>
>>>>> To me this is a matter of whether you want to be opportunistic.
>>>>> If this went to dispatch I would now recommend that it be dispatched
>>>>> to sipcore. So its a matter of whether you want to talk about it in
>>>>> the dispatch meeting.
>>>>>
>>>>>> Regarding substance, this draft troubles me. It takes feature-caps
>>>>>> in exactly the direction that I found most concerning about the
>>>>>> mechanism in the first place.
>>>>>>
>>>>>> Your draft partitions the existing media feature tags into two sets
>>>>>> - those that would be useful as feature-capability-indicators, and
>>>>>> those that aren't. But I see no explanation of the criteria used to
>>>>>> make this distinction, nor can I think of one.
>>>>>>
>>>>>> [AA] I based this decision on the following criteria: If a feature
>>>>>> tag was potentially at all useful for an intermediary to indicate it
>>>>>> then include it in the registry. The ones not included are either
>>>>>> directly associated with the user (intermediaries are not  directly
>>>>>> associated with the user) or would only ever have one value (e.g
>>>>>> automata).  I am not sure that every feature-capability indicator
>>>>>> proposed to be registered is actually useful but then I don't think
>>>>>> every media feature tag registered by RFC 3840 is either (I doubt
>>>>>> very much if there are implementation using the sip.application or
>>>>>> sip.control feature tags). I don't think RFC 3840 goes into a lot of
>>>>>> details justifying of ever registered media feature tag and
>>>>>> specifying the details of how they would be used either.  I am
>>>>>> willing to remove any feature-capability indicators that are
>>>>>> controversial except that I think we definitely need sip.extensions, sip.methods and sip.events.
>>>>>> There is a significant overhead to writing an
>>>>> d progressing internet drafts so my view is lets register all that
>>>>> might be remotely useful in the same document.
>>>>>
>>>>> The judgement of "useful" is reasonable. But I still can't discern
>>>>> what the use is from the iana registration descriptions.
>>>>>
>>>>>> For the ones that you have requested feature capability indicators,
>>>>>> I cannot figure out what using them would mean. For example, when I
>>>>>> see isFocus on a Contact header I know I am in a conference, and
>>>>>> that I can subscribe to the conference event package at the contact
>>>>>> URI. If I see isFocus in a Feature-Caps header, what does it mean?
>>>>>> What can I do once I know this?
>>>>>>
>>>>>> Section 5.14 of this draft says:
>>>>>>
>>>>>>             This Feature-capability indicator indicates that the intermediary
>>>>>>             is a conference server, also known as a focus, and is capable of
>>>>>>             mixing together the media for all calls to the same URI.
>>>>>> ...
>>>>>>                Examples of typical use: A conference bridge indicating
>>>>>> that it
>>>>>>                is a conference bridge and is capable of acting as a
>>>>>> conference
>>>>>>                focus for this session.
>>>>>>
>>>>>> [AA] the presence of isfocus in a Feature-Caps header field means
>>>>>> that a UA can initiate a conference by sending a REFER request to
>>>>>> the intermediary to invite another user and create a multi user
>>>>>> conference from the 1-1 session.
>>>>>>
>>>>>> Note that Feature-Caps doesn't indicate which entity has this
>>>>>> capability, only that something does. And since this would
>>>>>> presumably only be used if it wasn't the UAC of the request, sending
>>>>>> a subscribe to the contact address of the UAC wouldn't make sense.
>>>>>>
>>>>>> [AA] Yes the GRUU of the intermediary would be needed but I consider
>>>>>> this application specific and so this would be included in a feature
>>>>>> tag registered in the global tree as stated in the draft "RFC 6809
>>>>>> [1] provides that addresses of intermediaries can be communicated as
>>>>>> a value of an associated feature-capability indicator so it would be
>>>>>> appropriate to define feature capability indicators as part of the
>>>>>> global tree to communicate the GRUU of the intermediary and hence
>>>>>> this is outside the scope of this document."  - RFC 6809 states " If
>>>>>> additional data about a supported feature needs to be conveyed, such
>>>>>> as the address of the SIP entity that indicated support of the
>>>>>> feature, then the feature definition needs to define a way to convey
>>>>>> that information as a value of the associated feature-capability
>>>>>> indicator." However I think the SIP specific capability indicators
>>>>>> such as methods, extensions and events should appropriately be
>>>>>> registered in the SIP tree not as proprietary indicator
>>>>> s in the global tree.
>>>>>
>>>>> So you have defined a sip tree feature tag that is only useful in
>>>>> conjunction with another feature tag from the global tree.
>>>>> And the description of this feature tag doesn't even mention that.
>>>>>
>>>>> And this all implies a completely non-standard call model - doing
>>>>> conferencing in a way inconsistent with RFC 4579.
>>>>>
>>>>> ISTM that if 4579 doesn't work for you then you should be back
>>>>> proposing extensions/revisions to it.
>>>>>
>>>>>> If there is a conference bridge in the signaling path, then I would
>>>>>> expect it to be the UAC.
>>>>>>
>>>>>> [AA] Although a "standard" way to invoke a conference is to send a
>>>>>> REFER to the other UAs to invite them to the conference focus,  in
>>>>>> many deployments a scenario exists where a call involves an IP-PBX
>>>>>> or Telephony Application Server (TAS) that can act as a focus for
>>>>>> the conference. A participant of a call can then create a conference
>>>>>> by sending a REFER request in dialog to the IP-PBX or TAS to use
>>>>>> 3PCC to Invite other users to a conference. Reasons for this are 1.
>>>>>> Not all UAs support REFER,
>>>>>
>>>>> So you are saying the intermediary isn't a focus (its a B2BUA), but
>>>>> it *could become* a focus.
>>>>>
>>>>> The concept that a dialog may contain intermediaries that can be
>>>>> addressed to do stuff is not part of any sip standard that I am aware
>>>>> of. I don't care too much as long as the "stuff" is application stuff
>>>>> that is outside the scope of sip. But when it is alternative ways to
>>>>> do stuff that sip supports, then I get upset.
>>>>>
>>>>>> 2. Many SBCs reject REFER requests going outside domains because of
>>>>>> the potential for charging fraud (referring to a premium rate number
>>>>>> etc) 3. A User receiving a REFER and then using an INVITE to join
>>>>>> the conference may be charged for initiating  the call when the
>>>>>> scenario is that the initiator of the conference should be charged.
>>>>>> 4. No need to obtain and distribute conference URIs.
>>>>>> Problem is how to achieve the same behavior without dialog reuse
>>>>>> which has been deprecated by RFC 6665?
>>>>>
>>>>> Then maybe the problem needs to be brought up, and a standard
>>>>> solution proposed, rather than simply enabling a proprietary mechanism.
>>>>>
>>>>>> As another example, consider section 5.1:
>>>>>>
>>>>>>             Descrition:
>>>>>>             This Feature-capability indicator indicates that the intermediary
>>>>>>             supports audio as a streaming media type.
>>>>>> ...
>>>>>>                Examples of typical use: An IP PBX indicating that it is
>>>>>>                capable of accepting and initiating sessions with audio as a
>>>>>>                streaming media type.
>>>>>>
>>>>>> This definition *implies* an assumption about the working
>>>>>> environment
>>>>>> - one that AFAIK is new. It implies that you need to know that
>>>>>> intermediaries support a media type before you can use it. Would it
>>>>>> be bad if there were no intermediaries, and so none indicated this?
>>>>>> What if some intermediary *did* indicate support, but some other
>>>>>> doesn't, but doesn't indicate that it doesn't?
>>>>>>
>>>>>> Bottom line: how would the presence or absence of this feature tag
>>>>>> affect subsequent usage?
>>>>>>
>>>>>> [AA] The absence of the streaming types does not indicate that the
>>>>>> intermediary does not support the media type and SDP offer answer
>>>>>> will ultimately determine what can or cannot be used if another
>>>>>> session is initiated involving the intermediary. However the
>>>>>> presence of the media type in a Feature-caps header field does
>>>>>> explictly confirm that the intermediary does support the media type
>>>>>> and in the scenario where a UA has a choice of multiple
>>>>>> intermediaries it could use for a conference it might choose to use
>>>>>> the one that explicitly indicates it supports the media types the UA wants to use.
>>>>>
>>>>> So the UA will be able to discover that *some* intermediary supports
>>>>> media it is interested in. And it can tell that *some* intermediary
>>>>> says it is a focus. It doesn't know if they are the same intermediary.
>>>>>
>>>>> And then via some other feature tag it obtains the URI of *some*
>>>>> intermediary on the signaling path. Or maybe it gets more than one of
>>>>> these.
>>>>>
>>>>> It then makes a leap of faith and conflates all those things, to
>>>>> determine that the URI identifies a focus that supports this media type.
>>>>>
>>>>> Even then, exactly what does that mean? It may or may not mean that
>>>>> it supports mixing that media type in a conference.
>>>>>
>>>>>> As I stated already I don't care that much about these streaming
>>>>>> media types.
>>>>>
>>>>>> I could go on, but this is enough for now.
>>>>>>
>>>>>> [AA] My motivation for this is that currently 3GPP are updating
>>>>>> their specifications to use RFC 6665 instead of RFC 3265.
>>>>>
>>>>>> 3GPP has a lot of dialog reuse with SUBSCRIBE and REFER with
>>>>>> intermediaries accepting the REFER or SUBSCRIBE request rather than
>>>>>> forwarding it all the way to the remote UA.
>>>>>
>>>>> And 6665 deprecates dial reuse in most of those cases.
>>>>> Without dialog reuse, the intermediaries don't get an opportunity to
>>>>> intercept those.
>>>>>
>>>>>> In order to know that an intermediary supports the target dialog
>>>>>> mechanism  needed for a REFER request sent outside the dialog to
>>>>>> work we need sip.extensions as a feature-capability indicator. In
>>>>>> order to know that the needed event package is supported by the
>>>>>> intermediary so we can SUBSCROBE outside the dialog to an
>>>>>> intermediary we need sip.events as a feature-capability indicator.
>>>>>
>>>>> Then I think you should be back here with a problem statement and a
>>>>> request for how to get sip to solve it.
>>>>>
>>>>> And you should touch base with Christer on this. He may have a
>>>>> different opinion on the relevance of feature-caps as a solution.
>>>>>
>>>>>         Thanks,
>>>>>         Paul
>>>>>
>>>>>> On 10/22/13 3:44 AM, Andrew Allen wrote:
>>>>>>> Adam, Paul, Richard, Gonzalo
>>>>>>>
>>>>>>> I have submitted a new draft to sipcore  to register a number of
>>>>>>> feature capability indicators in the SIP tree (based upon some of
>>>>>>> the existing SIP media feature tags). The draft can be found at:
>>>>>>>
>>>>>>> http://www.ietf.org/id/draft-allen-sipcore-sip-tree-cap-indicators-00.
>>>>>>> txt
>>>>>>>
>>>>>>> Since there will not be a sipcore session at IETF#88  can we have
>>>>>>> an offline discussion on how to progress this draft (which
>>>>>>> hopefully is fairly straightforward as it just registers feature
>>>>>>> capabilities indicators with IANA). I wouldn't want to have to wait
>>>>>>> until March next year for a decision on progressing this.
>>>>>>>
>>>>>>> Andrew
>>>>>>>
>>>>>>> -------------------------------------------------------------------
>>>>>>> -
>>>>>>> - This transmission (including any attachments) may contain
>>>>>>> confidential information, privileged material (including material
>>>>>>> protected by the solicitor-client or other applicable privileges),
>>>>>>> or constitute non-public information. Any use of this information
>>>>>>> by anyone other than the intended recipient is prohibited. If you
>>>>>>> have received this transmission in error, please immediately reply
>>>>>>> to the sender and delete this information from your system. Use,
>>>>>>> dissemination, distribution, or reproduction of this transmission
>>>>>>> by unintended recipients is not authorized and may be unlawful.
>>>>>>
>>>>>> --------------------------------------------------------------------
>>>>>> - This transmission (including any attachments) may contain
>>>>>> confidential information, privileged material (including material
>>>>>> protected by the solicitor-client or other applicable privileges),
>>>>>> or constitute non-public information. Any use of this information by
>>>>>> anyone other than the intended recipient is prohibited. If you have
>>>>>> received this transmission in error, please immediately reply to the
>>>>>> sender and delete this information from your system. Use,
>>>>>> dissemination, distribution, or reproduction of this transmission by
>>>>>> unintended recipients is not authorized and may be unlawful.
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>
>>
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>
>
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 25 Oct 2013 14:49:47 -0400

On 10/25/13 2:03 PM, Christer Holmberg wrote:
> But, in general, keep in mind that a FCI value with an address
> does NOT automatically indicates the address of the entity supporting
> the feature - unless you explicitly say so in the FCI definition. It
> only provides an address associated with a feature, and you need to
> define the semantics of it in the FCI defintion.
>
> /Example:/
>
> Now, in this case the address does NOT point to my entity, but to Paul's
> entity. My entity supports a feature, which provides Paul's address.
>
> So, if the FCI says:
>
>      Feature-Caps: *,
> +g.find-paul="sip:[email-masked]";+sip.methods="invite"
>
> ...it doesn't automatically mean that I can contact Paul using INVITE.
> By default it means that MY entity supports the INVITE method - which
> from the find-paul feature perspective is useless information.
>
> So, in the FCI specification for +g.find-paul, I would have to
> explictily describe how the FCI works in conjunction with other FCIs. I
> would have to explicitly say that, when used together +sip.methods, the
> +sip.methods indicates which SIP methods I can use to contact Paul
> (using the address provide in the +g.find-paul FCI).

So far I agree.

But suppose there is also a find-christer FCI. So we have:

Feature-Caps: *
    ;+g.find-paul="sip:[email-masked]"
    ;+g.find-paul="sip:[email-masked]"
    ;+sip.methods="invite"

And both find-paul and find-christer want to define the use of other 
FCIs. Then things start to become ambiguous.

Should the description of find-paul specify what other FCIs "pertain" to 
it? Or should the description of sip.methods specify what FCI(s) provide 
the address at which it applies? Or both? What if paul and christer 
support different methods?

	Thanks,
	Paul

>         include, for example, *names of related feature-capability
> indicators*."
>
> So, in your case, I think the +g.3gpp.see_trans FCI specifiction would
> have to specify how the FCI is used in conjuntion with other FCIs,
> including the +sip.method FCI.
>
> Something like: "When the session transfer request is sent to the
> address indicated by the FCI value, the +sip.method FCI indicates which
> SIP methods can be used."
>
> Regards,
>
> Christer
>
>
>
> *From*: Christer Holmberg [mailto:[email-masked]]
> *Sent*: Friday, October 25, 2013 12:01 PM Central Standard Time
> *To*: Andrew Allen; Paul Kyzivat <[email-masked]>; Gonzalo
> Camarillo <[email-masked]>
> *Cc*: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>;
> [email-masked] <[email-masked]>
> *Subject*: RE: New sipcore draft submission
>>Indicating that the entity supports 3GPP session transfer and the address where you send the session transfer request is  sip:[email-masked];gr <mailto:[email-masked];gr>
>
> Correct. The FCI itself indicates support of session transfer feature,
> and the FCI value indicates the address associatd with the feature.
>
>>Also if I have:
>
>>
>
>>Feature-Caps: *;+g.3ggp.sess_trans=sip:[email-masked];gr; +sip.extensions=”replaces, tdialog”;
> +sip.methods=”invite, refer, bye, options, update, prack”
>
>>
>
>> This means the entity supports 3GPP session transfer and the address where you send the session transfer request is  sip:[email-masked];gr <mailto:[email-masked];gr>...
>
> Correct.
>
> Technically, what it means is that there is *AN* entity which supports
> the features listed above, and the address is where you are to send the
> session transfer request in order to trigger the 3GPP session transfer
> feature.
>
> Regards,
>
> Christer
>
> *From:*Christer Holmberg [mailto:[email-masked]]
> *Sent:* Friday, October 25, 2013 10:25 AM
> *To:* Paul Kyzivat; Andrew Allen; Gonzalo Camarillo
> *Cc:* [email-masked]; [email-masked]; [email-masked]
> *Subject:* RE: New sipcore draft submission
> As Paul said, if one needs to provide address information associated
> with a FCI, the address information cannot be a FCI of its own. It needs
> to be a value of the FCI for which it is associated.
>
> Something like:
>
> ------------------------------------------------------------------------
>
> *From:*Paul Kyzivat [[email-masked]]
> *Sent:* Friday, 25 October 2013 5:06 PM
> *To:* Andrew Allen; Gonzalo Camarillo
> *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; Christer Holmberg; [email-masked]
> <mailto:[email-masked]>
> *Subject:* Re: New sipcore draft submission
>> To: Andrew Allen;[email-masked] <mailto:[email-masked]>
> <[email-masked] <mailto:[email-masked]>>
>> Cc:[email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>;
> [email-masked] <mailto:[email-masked]> <[email-masked]
> <mailto:[email-masked]>>; [email-masked]
> <mailto:[email-masked]> <[email-masked]
> <mailto:[email-masked]>>; [email-masked]
> <mailto:[email-masked]> <[email-masked]
> <mailto:[email-masked]>>; Paul Kyzivat
> <[email-masked] <mailto:[email-masked]>>
>>> To: Andrew Allen; Gonzalo Camarillo <[email-masked] <mailto:[email-masked]>>
>>> Cc: Richard Barnes ([email-masked] <mailto:[email-masked]>) <[email-masked] <mailto:[email-masked]>>; Adam
> Roach ([email-masked] <mailto:[email-masked]>) <[email-masked]
> <mailto:[email-masked]>>; Christer Holmberg
> ([email-masked] <mailto:[email-masked]>)
> <[email-masked]
> <mailto:[email-masked]>>; Mary Barnes
> ([email-masked] <mailto:[email-masked]>) <
> [email-masked] <mailto:[email-masked]>>
>>>> Cc: Richard Barnes ([email-masked] <mailto:[email-masked]>); Adam Roach ([email-masked]
> <mailto:[email-masked]>); Christer Holmberg
> ([email-masked] <mailto:[email-masked]>)
>>>>> Cc: Andrew Allen; Richard Barnes ([email-masked] <mailto:[email-masked]>); Adam Roach
>>>>> ([email-masked] <mailto:[email-masked]>); Christer Holmberg
> ([email-masked] <mailto:[email-masked]>)
>>>>>>> To: Andrew Allen; Richard Barnes ([email-masked] <mailto:[email-masked]>); Gonzalo Camarillo
>>>>>>> ([email-masked] <mailto:[email-masked]>);
> Adam Roach ([email-masked] <mailto:[email-masked]>)
>>>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information  by anyone other than the intended recipient is prohibited. If you have
> sender and delete this information from your system. Use, dissemination,
> distribution, or reproduction of this transmission by unintended
> recipients is not authorized and may be unlawful.
>>>>>
>>>>>
>>>>
>>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information  by anyone other than the intended recipient is prohibited. If you have
> sender and delete this information from your system. Use, dissemination,
> distribution, or reproduction of this transmission by unintended
> recipients is not authorized and may be unlawful.
>>>>
>>>>
>>>
>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information  by anyone other than the intended recipient is prohibited. If you have
> sender and delete this information from your system. Use, dissemination,
> distribution, or reproduction of this transmission by unintended
> recipients is not authorized and may be unlawful.
>>>
>>>
>>
>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information  by anyone other than the intended recipient is prohibited. If you have
> sender and delete this information from your system. Use, dissemination,
> distribution, or reproduction of this transmission by unintended
> recipients is not authorized and may be unlawful.
>>
>>
>
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other than
> the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and delete
> this information from your system. Use, dissemination, distribution, or
> reproduction of this transmission by unintended recipients is not
> authorized and may be unlawful.
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other than
> the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and delete
> this information from your system. Use, dissemination, distribution, or
> reproduction of this transmission by unintended recipients is not
> authorized and may be unlawful.
>
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 25 Oct 2013 18:57:11 +0000

Hi,

....

> support different methods?

In that case you would need to have two different Feature-Caps header fields:

    Feature-Caps: *;+g.find-paul="sip:[email-masked]";+sip.methods="invite"
    Feature-Caps: *;+g.find-paul="sip:[email-masked]";+sip.methods="message"

In your example you had two instances of the same FCI (is that even allowed?), but there could also have been a case with two different FCIs, both using +sip.methods, in which case you may have to put them into separate Feature-Caps header fields.

These things would have to be clearly specified.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 25 Oct 2013 16:28:09 -0400

Inline.

On 10/25/13 2:57 PM, Christer Holmberg wrote:
>      Feature-Caps:
> *;+g.find-paul="sip:[email-masked]";+sip.methods="invite"
>      Feature-Caps:
> *;+g.find-paul="sip:[email-masked]";+sip.methods="message"

That seemingly solves the problem, but if the same entity inserts them 
both then its a questionable use of Feature-caps isn't it?

> In your example you had two instances of the same FCI (is that even
> allowed?),

I did? find-paul and find-christer are two different FCIs.
(But that sort of naming will be troublesome for the registry and for 
the expert who has to approve entries in it.:-)

  but there could also have been a case with two different
> FCIs, both using +sip.methods, in which case you may have to put them
> into separate Feature-Caps header fields.
>

Very definitely.

	Thanks,
	Paul

>>> I am happy to do a revision with more details on the semantics of the capability indicators. However I don't think it should be held to a very much higher bar than the details in RFC 3840 and the other media feature tag RFCs regarding the meaning of thosetags.
>>
>>>>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this informationby anyone other than the intended recipient is prohibited. If you have
>>>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this informationby anyone other than the intended recipient is prohibited. If you have
>>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this informationby anyone other than the intended recipient is prohibited. If you have
>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this informationby anyone other than the intended recipient is prohibited. If you have

---

From: Andrew Allen <[email-masked]>
Date: Fri, 25 Oct 2013 20:38:41 +0000

In my view the basic premise of Feature-Caps is that an entity on the route is indicating that it supports a particular capability. Indicating support for features by other entities is rather problematic. I suppose a service proxy on the route could also indicate features supported by other physical servers that it has responsibility for that are not hosted physically by it.

I agree with Christer that if an entity needs to support multiple sets of features that do not all apply to the same server then it should do so in separate Feature-Caps header fields with only the features that are all hosted by the same entity being included in the same Feature-Caps header field.

I think entities advertising features that they are not responsible for and have nothing to do with is bogus.

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, October 25, 2013 4:28 PM
To: Christer Holmberg; [email-masked]
Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators

Inline.

On 10/25/13 2:57 PM, Christer Holmberg wrote:
>>> Now, in this case the address does NOT point to my entity, but to 
>>> Paul's entity. My entity supports a feature, which provides Paul's address.
>>>
>>> So, if the FCI says:
>>>
>>>      Feature-Caps: *,
>>> By default it means that MY entity supports the INVITE method - 
>>> which from the find-paul feature perspective is useless information.
>>>
>>> explictily describe how the FCI works in conjunction with other 
>>> FCIs. I would have to explicitly say that, when used together 
>>> +sip.methods, the
>> Should the description of find-paul specify what other FCIs "pertain" 
>> to it? Or should the description of sip.methods specify what FCI(s) 
>> provide the address at which it applies? Or both? What if paul and 
>> christer support different methods?
>

That seemingly solves the problem, but if the same entity inserts them both then its a questionable use of Feature-caps isn't it?

I did? find-paul and find-christer are two different FCIs.
(But that sort of naming will be troublesome for the registry and for the expert who has to approve entries in it.:-)

Very definitely.

	Thanks,
	Paul

>> So, in your case, I think the +g.3gpp.see_trans FCI specifiction 
>> would have to specify how the FCI is used in conjuntion with other 
>> FCIs, including the +sip.method FCI.
>>
>> address indicated by the FCI value, the +sip.method FCI indicates 
>> which SIP methods can be used."
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>>>Feature-Caps: *;+g.3ggp.sess_trans="sip:[email-masked];gr"
>>
>>>
>>
>>>Indicating that the entity supports 3GPP session transfer and the 
>>>address where you send the session transfer request is  
>>>sip:[email-masked];gr <mailto:[email-masked];gr>
>>
>> Correct. The FCI itself indicates support of session transfer 
>> feature, and the FCI value indicates the address associatd with the feature.
>>
>>>Also if I have:
>>
>>>
>>
>>>Feature-Caps: *;+g.3ggp.sess_trans=sip:[email-masked];gr; 
>>>+sip.extensions="replaces, tdialog";
>> +sip.methods="invite, refer, bye, options, update, prack"
>>
>>>
>>
>> Technically, what it means is that there is *AN* entity which 
>> supports the features listed above, and the address is where you are 
>> to send the session transfer request in order to trigger the 3GPP 
>> session transfer feature.
>>
>> Regards,
>>
>> Christer
>>
>> with a FCI, the address information cannot be a FCI of its own. It 
>> needs to be a value of the FCI for which it is associated.
>>
>> Something like:
>>
>> ---
>> <mailto:[email-masked]>; Christer Holmberg; 
>> [email-masked] <mailto:[email-masked]>
>> exchange should probably be reposted to the sipcore list as part of 
>> the public discussion of the draft.)
>>
>> Keep in mind that the driving force for the definition of feature 
>> tags in 3840 was in support of callerprefs (3841). So the context for 
>> the use of feature tags was that they would be placed on Contacts in 
>> REGISTER requests. So you can interpret the definitions in that 
>> context: that a request sent to an AOR using callerprefs can affect 
>> the choice of which device the request goes to according to the 
>> capabilities it wants. In that context audio, video, isfocus all make sense.
>>
>> you reach via callerprefs will have the capabilities you requested. 
>> So the values in the contact help confirm what you got.
>>
>> Of course they have since been used other ways. And the descriptions 
>> of them don't necessarily reflect that. IMO that is a defect due to 
>> the evolution of use.
>>
>> In private discussion you indicated to me that you expected the 
>> feature caps to be grouped - with one of them giving the URI of the 
>> device that the other tags apply to. I guess this would end up looking something like:
>>
>> feature caps for the capabilities it wants, and then send a request 
>> to that URI, with the expectation that the UA responding will have 
>> those capabilities.
>>
>> This was discussed at length while that RFC was under consideration. 
>> Yet the definitions of the tags in *this* draft don't specify that.
>>
>>> But I will be opposed to these until and unless the draft (and 
>>> notably the descriptions of the tags) are clear about how one could 
>>> figure out what can do in the presence of the tags that one couldn't 
>>> do without them. AND, that the behavior that suggests doesn't 
>>> "break" sip. (E.g., by advocating a new and incompatible way to do 
>>> something.)
>>>
>>>> I discussed that with Adam. We decided we can't set a precedent to 
>>>> spin up a session to discuss a draft that hasn't had substantial 
>>>> (any) list discussion.
>>>>
>>>>>> Cc: Andrew Allen; Richard Barnes ([email-masked] 
>>>>>> <mailto:[email-masked]>); Adam Roach ([email-masked] 
>>>>>>>> Can I ask the ADs to determine ASAP if this needs to go to 
>>>>>>>> DISPATCH first or not. As outlined below my view is that it is 
>>>>>>>> unnecessary for every little thing to go to DISPATCH as this 
>>>>>>>> just creates additional delay and overhead. If it is to be 
>>>>>>>> discussed in DISPATCH then I definitely would want agenda time atIETF#88 for this.
>>>>>>>
>>>>>>> Having now seen Andrew's responses to my initial questions, I 
>>>>>>> think this
>>>>>>> potential to create a dialect of sip that is incompatible with 
>>>>>>> normal usage. (Maybe IMS has already done that. But this will 
>>>>>>> make it
>>>>>>> worse.)
>>>>>>>
>>>>>>> But if there is a desire to discuss it publicly in Vancouver 
>>>>>>> then dispatch is the opportunity and so some discussion on the 
>>>>>>> dispatch list in advance of that would be appropriate.
>>>>>>>
>>>>>>>> ([email-masked] 
>>>>>>>> <mailto:[email-masked]>);
>>>>>>>> On a legalistic note, its questionable to me whether this kind 
>>>>>>>> of action falls within the scope of sipcore. OTOH, among 
>>>>>>>> existing wgs, sipcore is probably the best suited to discuss 
>>>>>>>> the proposal. We could take it to DISPATCH. I think DISPATCH 
>>>>>>>> has extra time in its agenda for Vancouver, so that might be 
>>>>>>>> one option for you. But then I don't know where dispatch would 
>>>>>>>> dispatch it. It may be that AD sponsored is the best way to go.
>>>>>>>>
>>>>>>>> [AA] It seemed to me that sipcore was the right place. This 
>>>>>>>> draft registers feature-capability indicators in a registry 
>>>>>>>> that was created by a sipcore RFC (RFC 6809). You could in my 
>>>>>>>> view make an argument that this should even have been done as part of RFC 6809.
>>>>>>>
>>>>>>> If this was just a matter of registering some new feature caps 
>>>>>>> that were not controversial, then I don't think sipcore needs to be involved.
>>>>>>>
>>>>>>>> Discussing it now on the dispatch list would be a good start 
>>>>>>>> toward discussing it at the dispatch session.
>>>>>>>>
>>>>>>>> [AA] Can I ask the ADs to determine if this needs to go to 
>>>>>>>> DISPATCH first or not. My view is that it is unnecessary for 
>>>>>>>> every little thing to go to DISPATCH as this just creates additional delay and overhead.
>>>>>>>> This just registers some indicators in an existing IANA 
>>>>>>>> registry and is not (or should not be IMHO) a major project.
>>>>>>>
>>>>>>> If this went to dispatch I would now recommend that it be 
>>>>>>> dispatched to sipcore. So its a matter of whether you want to 
>>>>>>> talk about it in the dispatch meeting.
>>>>>>>
>>>>>>>> Regarding substance, this draft troubles me. It takes 
>>>>>>>> feature-caps in exactly the direction that I found most 
>>>>>>>> concerning about the mechanism in the first place.
>>>>>>>>
>>>>>>>> - those that would be useful as feature-capability-indicators, 
>>>>>>>> and those that aren't. But I see no explanation of the criteria 
>>>>>>>> used to make this distinction, nor can I think of one.
>>>>>>>>
>>>>>>>> [AA] I based this decision on the following criteria: If a 
>>>>>>>> feature tag was potentially at all useful for an intermediary 
>>>>>>>> to indicate it then include it in the registry. The ones not 
>>>>>>>> included are either directly associated with the user 
>>>>>>>> (intermediaries are not  directly associated with the user) or 
>>>>>>>> would only ever have one value (e.g automata).  I am not sure 
>>>>>>>> that every feature-capability indicator proposed to be 
>>>>>>>> registered is actually useful but then I don't think every 
>>>>>>>> media feature tag registered by RFC 3840 is either (I doubt 
>>>>>>>> very much if there are implementation using the sip.application 
>>>>>>>> or sip.control feature tags). I don't think RFC 3840 goes into 
>>>>>>>> a lot of details justifying of ever registered media feature 
>>>>>>>> tag and specifying the details of how they would be used 
>>>>>>>> either.  I am willing to remove any feature-capability indicators that are controversial except that I think we definitely need sip.extensions, sip.methods and sip.events.
>>>>>>> d progressing internet drafts so my view is lets register all 
>>>>>>> that might be remotely useful in the same document.
>>>>>>>
>>>>>>> The judgement of "useful" is reasonable. But I still can't 
>>>>>>> discern what the use is from the iana registration descriptions.
>>>>>>>
>>>>>>>> For the ones that you have requested feature capability 
>>>>>>>> indicators, I cannot figure out what using them would mean. For 
>>>>>>>> example, when I see isFocus on a Contact header I know I am in 
>>>>>>>> a conference, and that I can subscribe to the conference event 
>>>>>>>> package at the contact URI. If I see isFocus in a Feature-Caps header, what does it mean?
>>>>>>>>                Examples of typical use: A conference bridge 
>>>>>>>> indicating that it
>>>>>>>>                is a conference bridge and is capable of acting 
>>>>>>>> as a conference
>>>>>>>>                focus for this session.
>>>>>>>>
>>>>>>>> [AA] the presence of isfocus in a Feature-Caps header field 
>>>>>>>> means that a UA can initiate a conference by sending a REFER 
>>>>>>>> request to the intermediary to invite another user and create a 
>>>>>>>> multi user conference from the 1-1 session.
>>>>>>>>
>>>>>>>> presumably only be used if it wasn't the UAC of the request, 
>>>>>>>> sending a subscribe to the contact address of the UAC wouldn't make sense.
>>>>>>>>
>>>>>>>> [AA] Yes the GRUU of the intermediary would be needed but I 
>>>>>>>> consider this application specific and so this would be 
>>>>>>>> included in a feature tag registered in the global tree as 
>>>>>>>> stated in the draft "RFC 6809 [1] provides that addresses of 
>>>>>>>> intermediaries can be communicated as a value of an associated 
>>>>>>>> feature-capability indicator so it would be appropriate to 
>>>>>>>> define feature capability indicators as part of the global tree 
>>>>>>>> to communicate the GRUU of the intermediary and hence this is 
>>>>>>>> outside the scope of this document."  - RFC 6809 states " If 
>>>>>>>> additional data about a supported feature needs to be conveyed, 
>>>>>>>> such as the address of the SIP entity that indicated support of 
>>>>>>>> the feature, then the feature definition needs to define a way 
>>>>>>>> to convey that information as a value of the associated 
>>>>>>>> feature-capability indicator." However I think the SIP specific 
>>>>>>>> capability indicators such as methods, extensions and events 
>>>>>>>> should appropriately be registered in the SIP tree not as 
>>>>>>>> proprietary indicator
>>>>>>> s in the global tree.
>>>>>>>
>>>>>>> So you have defined a sip tree feature tag that is only useful 
>>>>>>> in conjunction with another feature tag from the global tree.
>>>>>>> And this all implies a completely non-standard call model - 
>>>>>>> doing conferencing in a way inconsistent with RFC 4579.
>>>>>>>
>>>>>>>> If there is a conference bridge in the signaling path, then I 
>>>>>>>> would expect it to be the UAC.
>>>>>>>>
>>>>>>>> [AA] Although a "standard" way to invoke a conference is to 
>>>>>>>> send a REFER to the other UAs to invite them to the conference 
>>>>>>>> focus,  in many deployments a scenario exists where a call 
>>>>>>>> involves an IP-PBX or Telephony Application Server (TAS) that 
>>>>>>>> can act as a focus for the conference. A participant of a call 
>>>>>>>> can then create a conference by sending a REFER request in 
>>>>>>>> dialog to the IP-PBX or TAS to use 3PCC to Invite other users to a conference. Reasons for this are 1.
>>>>>>> So you are saying the intermediary isn't a focus (its a B2BUA), 
>>>>>>> but it *could become* a focus.
>>>>>>>
>>>>>>> addressed to do stuff is not part of any sip standard that I am 
>>>>>>> aware of. I don't care too much as long as the "stuff" is 
>>>>>>> application stuff that is outside the scope of sip. But when it 
>>>>>>> is alternative ways to do stuff that sip supports, then I get upset.
>>>>>>>
>>>>>>>> 2. Many SBCs reject REFER requests going outside domains 
>>>>>>>> because of the potential for charging fraud (referring to a 
>>>>>>>> premium rate number
>>>>>>>> etc) 3. A User receiving a REFER and then using an INVITE to 
>>>>>>>> join the conference may be charged for initiating  the call 
>>>>>>>> when the scenario is that the initiator of the conference should be charged.
>>>>>>>> Problem is how to achieve the same behavior without dialog 
>>>>>>>> reuse which has been deprecated by RFC 6665?
>>>>>>>
>>>>>>>> intermediaries support a media type before you can use it. 
>>>>>>>> Would it be bad if there were no intermediaries, and so none indicated this?
>>>>>>>> What if some intermediary *did* indicate support, but some 
>>>>>>>> other doesn't, but doesn't indicate that it doesn't?
>>>>>>>>
>>>>>>>> Bottom line: how would the presence or absence of this feature 
>>>>>>>> tag affect subsequent usage?
>>>>>>>>
>>>>>>>> [AA] The absence of the streaming types does not indicate that 
>>>>>>>> the intermediary does not support the media type and SDP offer 
>>>>>>>> answer will ultimately determine what can or cannot be used if 
>>>>>>>> another session is initiated involving the intermediary. 
>>>>>>>> However the presence of the media type in a Feature-caps header 
>>>>>>>> field does explictly confirm that the intermediary does support 
>>>>>>>> the media type and in the scenario where a UA has a choice of 
>>>>>>>> multiple intermediaries it could use for a conference it might 
>>>>>>>> choose to use the one that explicitly indicates it supports the media types the UA wants to use.
>>>>>>>
>>>>>>> So the UA will be able to discover that *some* intermediary 
>>>>>>> supports media it is interested in. And it can tell that *some* 
>>>>>>> intermediary says it is a focus. It doesn't know if they are the same intermediary.
>>>>>>>
>>>>>>> intermediary on the signaling path. Or maybe it gets more than 
>>>>>>> one of these.
>>>>>>>
>>>>>>> Even then, exactly what does that mean? It may or may not mean 
>>>>>>> that it supports mixing that media type in a conference.
>>>>>>>
>>>>>>>> As I stated already I don't care that much about these 
>>>>>>>> streaming media types.
>>>>>>>
>>>>>>>> intermediaries accepting the REFER or SUBSCRIBE request rather 
>>>>>>>> than forwarding it all the way to the remote UA.
>>>>>>>
>>>>>>> Without dialog reuse, the intermediaries don't get an 
>>>>>>> opportunity to intercept those.
>>>>>>>
>>>>>>>> In order to know that an intermediary supports the target 
>>>>>>>> dialog mechanism  needed for a REFER request sent outside the 
>>>>>>>> dialog to work we need sip.extensions as a feature-capability 
>>>>>>>> indicator. In order to know that the needed event package is 
>>>>>>>> supported by the intermediary so we can SUBSCROBE outside the 
>>>>>>>> dialog to an intermediary we need sip.events as a feature-capability indicator.
>>>>>>>
>>>>>>> Then I think you should be back here with a problem statement 
>>>>>>> and a request for how to get sip to solve it.
>>>>>>>
>>>>>>>>> I have submitted a new draft to sipcore  to register a number 
>>>>>>>>> of feature capability indicators in the SIP tree (based upon 
>>>>>>>>> some of the existing SIP media feature tags). The draft can be found at:
>>>>>>>>>
>>>>>>>>> Since there will not be a sipcore session at IETF#88  can we 
>>>>>>>>> have an offline discussion on how to progress this draft 
>>>>>>>>> (which hopefully is fairly straightforward as it just 
>>>>>>>>> registers feature capabilities indicators with IANA). I 
>>>>>>>>> wouldn't want to have to wait until March next year for a decision on progressing this.
>>>>>>>>>
>>>>>>>>> Andrew
>>>>>>>>>
>>>>>>>>> confidential information, privileged material (including 
>>>>>>>>> material protected by the solicitor-client or other applicable 
>>>>>>>>> privileges), or constitute non-public information. Any use of 
>>>>>>>>> this information by anyone other than the intended recipient 
>>>>>>>>> is prohibited. If you have received this transmission in 
>>>>>>>>> error, please immediately reply to the sender and delete this 
>>>>>>>>> information from your system. Use, dissemination, 
>>>>>>>>> distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>>>>>>>
>>>>>>>> confidential information, privileged material (including 
>>>>>>>> material protected by the solicitor-client or other applicable 
>>>>>>>> privileges), or constitute non-public information. Any use of 
>>>>>>>> this information by anyone other than the intended recipient is 
>>>>>>>> prohibited. If you have received this transmission in error, 
>>>>>>>> please immediately reply to the sender and delete this 
>>>>>>>> information from your system. Use, dissemination, distribution, 
>>>>>>>> or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> -----------------------------------------------------------------
>>>>>> ---- This transmission (including any attachments) may contain 
>>>>>> protected by the solicitor-client or other applicable 
>>>>>> privileges), or constitute non-public information. Any use of 
>>>>>> this informationby anyone other than the intended recipient is 
>>>>>> prohibited. If you have
>>>>> ------------------------------------------------------------------
>>>>> --- This transmission (including any attachments) may contain 
>>>>> or constitute non-public information. Any use of this 
>>>>> informationby anyone other than the intended recipient is 
>>>>> prohibited. If you have
>>>> -- This transmission (including any attachments) may contain 
>>>> or constitute non-public information. Any use of this informationby 
>>> or constitute non-public information. Any use of this informationby 
>> This transmission (including any attachments) may contain 
>> protected by the solicitor-client or other applicable privileges), or 
>> constitute non-public information. Any use of this information by 
>> This transmission (including any attachments) may contain 
>> protected by the solicitor-client or other applicable privileges), or 
>> constitute non-public information. Any use of this information by

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 25 Oct 2013 20:47:03 +0000

Hi,

> both then its a questionable use of Feature-caps isn't it?

I am not sure. In fact, I think it even more highlights the fact that the FCI mechanism itself doesn't say anything about which entity supports the listed features. It only says that AN entity supports them, and two "AN entity" could be the same "AN entity" :)

> I did? find-paul and find-christer are two different FCIs.

Yes, but there was no find-christer in your example :)

> the expert who has to approve entries in it.:-)

Sure. A more realistic example could be e.g. find-helpdesk, which is provided to you when you call into a conference. Then, if you have a problem with the conference, you could call the helpdesk to ask for help. And, again, that could be a different entity than the one who indicated support of the feature.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 25 Oct 2013 16:50:22 -0400

> In my view the basic premise of Feature-Caps is that an entity on the route is indicating that it supports a particular capability. Indicating support for features by other entities is rather probl…

It was also a basic premise of feature-caps that it didn't specify the 
address of the thing reporting the capabilities.

The explanation at the time was that it wasn't necessary - that it was 
only necessary that there was something on the path that had those 
capabilities.

> I think entities advertising features that they are not responsible for and have nothing to do with is bogus.

I agree with that.

Then what does it mean for something on the path to insert an FCI 
containing a URI? That seems ok as long as you don't infer that other 
FCIs with it apply to the thing with that URI.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 25 Oct 2013 20:55:05 +0000

Hi,

>In my view the basic premise of Feature-Caps is that an entity on the route is indicating that it supports a particular capability. Indicating support for features

> by other entities is rather problematic. I suppose a service proxy on the route could also indicate features supported by other physical servers that it has

> responsibility for that are not hosted physically by it.
>
> I agree with Christer that if an entity needs to support multiple sets of features that do not all apply to the same server then it should do so in separate

> Feature-Caps header fields with only the features that are all hosted by the same entity being included in the same Feature-Caps header field.
>

It depends on what you mean by "responsible for". Even if the feature logic is not executed by the same physical entity that handles the SIP signaling, the SIP signaling entity can still be "responsible", e.g. if "responsible" means dispatching and distributing functions which will execute features.

Having said that, in most cases I assume that the entity indicating support of a feature actually IS the same entity that also executes the feature, but it is nowhere mandated to be that way.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, October 25, 2013 4:28 PM
To: Christer Holmberg; [email-masked]
Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators

Inline.

Very definitely.

        Thanks,
        Paul

---

From: Andrew Allen <[email-masked]>
Date: Mon, 28 Oct 2013 20:22:34 +0000

Paul

In actual usage many feature capability indicators (FCIs) are being used to communicate URIs. The ones that communicate URIs listed below are just from one 3GPP 3GPP specification (and there are several other specifications that define feature capability indicators) and many of these FCIs were defined by the authors of RFC 6809. So I think it has been found to be necessary to communicate URIs in FCIs. Usually these URIs are used as the Request-URI of a SIP request and the URI is hosted by the server that included the FCI.

If a UA indicates a URI hosted by it and a UA also indicates certain capabilities such as he supported SIP methods and SIP extensions I think you can infer that the UA supports those methods and extensions and the UA can be contacted at the URI.  When contacting the UA at the indicated URI it seems to me to be a reasonable assumption to make that the methods and extensions also indicated are going to be supported.

If the physical entity inserting the FCIs has different URIs that represent logically different UAs (with different SIP methods and extensions supported) then the different logical UAs and their associated capabilities should be indicated in different  Feature-Caps header fields.

List of FCIs from 3GPP TS 24.237 that have a URI as a value:

----------------------------
Table C.4-1: ABNF syntax of values of the g.3gpp.atcf feature-capability indicator
g-3gpp-atcf-in-path = STN-SR
STN-SR = "<" addr-spec ">"

The feature-capability indicator is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature-capability indicator is used to indicate support of the ATCF.
Examples of typical use: Indicating the presence and support of an ATCF on the routing path of the SIP REGISTER request and SIP response to the SIP REGISTER request and providing the session transfer number allocated to this ATCF.
----------------------------

----------------------------
Table C.6-1: ABNF syntax of values of the g.3gpp.atcf-mgmt-uri feature-capability indicator
g-3gpp-atcf-mgmt-uri-in-path = "<" SIP-URI ">"

String with an equality relationship. When used in a Feature-Caps header field, the value is string following the syntax as described in table C.6-1 for g-3gpp-atcf-mgmt-uri-in-path.
The feature-capability indicator is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature-capability indicator is used to indicate the management URI of the ATCF for receiving SIP requests where the ATCF performs the UAS role.
----------------------------

----------------------------
Table C.8-1: ABNF syntax of values of the g.3gpp.atcf-path feature-capability indicator
g-3gpp-atcf-path = "<" SIP-URI ">"

Values appropriate for use with this feature-capability indicator: 
String with an equality relationship. When used in a Feature-Caps header field, the value is a SIP URI of ATCF, the ATCF URI for terminating requests, identifying the registration path following the syntax as described in table C.8-1 for g-3gpp-atcf-path.
----------------------------

----------------------------
Table C.9A-1: ABNF syntax of string values of the g.3gpp.cs2ps-srvcc feature-capability indicator
g.3gpp.cs2ps-srvcc-value = STI-rSR
STI-rSR = "<" addr-spec ">"
When the value is string, the value contains the session transfer identifier for CS to PS SRVCC and follows the syntax as described in table C.9A-1 for g.3gpp.cs2ps-srvcc-value.
----------------------------

----------------------------
Table C.17-1: ABNF syntax of values of the g.3gpp.dynamic-stn feature-capability indicator
g-3gpp-dynamic-stn = TEL-URI
TEL-URI = "<tel:" global-number-digits ">" ; global-number-digits as specified in IETF RFC 3966[79]
String with an equality relationship. When used in a Feature-Caps header field in SIP INVITE request or SIP response, the value is string containing the digit string in tel URI format of the dynamic STN to be used to establish a CS call in order to transfer the session to the CS domain following the syntax as described in table C.17-1 for g-3gpp-dynamic-stn.The feature-capability indicator is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature-capability indicator is used to indicate support to transfer the session to the CS domain using the digit string of the dynamic STN.
----------------------------

Andrew

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, October 25, 2013 4:50 PM
To: Andrew Allen; Christer Holmberg; [email-masked]
Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators

> In my view the basic premise of Feature-Caps is that an entity on the route is indicating that it supports a particular capability. Indicating support for features by other entities is rather probl…

It was also a basic premise of feature-caps that it didn't specify the address of the thing reporting the capabilities.

The explanation at the time was that it wasn't necessary - that it was only necessary that there was something on the path that had those capabilities.

I agree with that.

Then what does it mean for something on the path to insert an FCI containing a URI? That seems ok as long as you don't infer that other FCIs with it apply to the thing with that URI.

	Thanks,
	Paul

> Subject: Re: [sipcore] New sipcore draft submission 
>>> (I see this is still on the private thread. I'll reply here, but 
>>> this exchange should probably be reposted to the sipcore list as 
>>> part of the public discussion of the draft.)
>>>
>>> tags in 3840 was in support of callerprefs (3841). So the context 
>>> for the use of feature tags was that they would be placed on 
>>> Contacts in REGISTER requests. So you can interpret the definitions 
>>> in that
>>> callerpref support is optional, there is no guarantee that the 
>>> device you reach via callerprefs will have the capabilities you requested.
>>> And then presumably somebody on the signaling path will "shop" in 
>>> the feature caps for the capabilities it wants, and then send a 
>>> request to that URI, with the expectation that the UA responding 
>>> will have those capabilities.
>>>
>>> And those definitions were written to be understood in the context 
>>> of 3840/3841. They make sense in that context, but not in *this* context.
>>>
>>>           Thanks,
>>>           Paul
>>>
>>>> As I indicated again on the sipcore list, I found the that the 
>>>> draft didn't explain nearly enough to allow meaningful use of these.
>>>> figure out what can do in the presence of the tags that one 
>>>> couldn't do without them. AND, that the behavior that suggests 
>>>> doesn't "break" sip. (E.g., by advocating a new and incompatible 
>>>> way to do
>>>> something.)
>>>>
>>>>>>>>> and those that aren't. But I see no explanation of the 
>>>>>>>>> criteria used to make this distinction, nor can I think of one.
>>>>>>>>>
>>>>>>>>> very much if there are implementation using the 
>>>>>>>>> sip.application or sip.control feature tags). I don't think 
>>>>>>>>> RFC 3840 goes into a lot of details justifying of ever 
>>>>>>>>> registered media feature tag and specifying the details of how 
>>>>>>>>> they would be used either.  I am willing to remove any feature-capability indicators that are controversial except that I think we definitely need sip.extensions, sip.methods and sip.events.
>>>>>>>>> indicators, I cannot figure out what using them would mean. 
>>>>>>>>> For example, when I see isFocus on a Contact header I know I 
>>>>>>>>> am in a conference, and that I can subscribe to the conference 
>>>>>>>>> event package at the contact URI. If I see isFocus in a Feature-Caps header, what does it mean?
>>>>>>>>>                 is a conference bridge and is capable of 
>>>>>>>>> acting as a conference
>>>>>>>>>                 focus for this session.
>>>>>>>>>
>>>>>>>>> request to the intermediary to invite another user and create 
>>>>>>>>> a multi user conference from the 1-1 session.
>>>>>>>>>
>>>>>>>>> define feature capability indicators as part of the global 
>>>>>>>>> tree to communicate the GRUU of the intermediary and hence 
>>>>>>>>> this is outside the scope of this document."  - RFC 6809 
>>>>>>>>> states " If additional data about a supported feature needs to 
>>>>>>>>> be conveyed, such as the address of the SIP entity that 
>>>>>>>>> indicated support of the feature, then the feature definition 
>>>>>>>>> needs to define a way to convey that information as a value of 
>>>>>>>>> the associated feature-capability indicator." However I think 
>>>>>>>>> the SIP specific capability indicators such as methods, 
>>>>>>>>> extensions and events should appropriately be registered in 
>>>>>>>>> the SIP tree not as proprietary indicator
>>>>>>>> s in the global tree.
>>>>>>>>
>>>>>>>> The concept that a dialog may contain intermediaries that can 
>>>>>>>> be addressed to do stuff is not part of any sip standard that I 
>>>>>>>> am aware of. I don't care too much as long as the "stuff" is 
>>>>>>>>> However the presence of the media type in a Feature-caps 
>>>>>>>>> header field does explictly confirm that the intermediary does 
>>>>>>>>> support the media type and in the scenario where a UA has a 
>>>>>>>>> choice of multiple intermediaries it could use for a 
>>>>>>>>> conference it might choose to use the one that explicitly indicates it supports the media types the UA wants to use.
>>>>>>>>
>>>>>>>> And then via some other feature tag it obtains the URI of 
>>>>>>>> *some* intermediary on the signaling path. Or maybe it gets 
>>>>>>>> more than one of these.
>>>>>>>>
>>>>>>>> It then makes a leap of faith and conflates all those things, 
>>>>>>>> to determine that the URI identifies a focus that supports this media type.
>>>>>>>>
>>>>>>>>> [AA] My motivation for this is that currently 3GPP are 
>>>>>>>>> updating their specifications to use RFC 6665 instead of RFC 3265.
>>>>>>>>
>>>>>>>>>> -------------------------------------------------------------
>>>>>>>>>> -
>>>>>>>>>> -----
>>>>>>>>>> -
>>>>>>>>>> material protected by the solicitor-client or other 
>>>>>>>>>> applicable privileges), or constitute non-public information. 
>>>>>>>>>> Any use of this information by anyone other than the intended 
>>>>>>>>>> recipient is prohibited. If you have received this 
>>>>>>>>>> transmission in error, please immediately reply to the sender 
>>>>>>>>>> and delete this information from your system. Use, 
>>>>>>>>>> dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>>>>>>>>
>>>>>>>>> --------------------------------------------------------------
>>>>>>>>> -
>>>>>>>>> -----

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 29 Oct 2013 07:47:41 +0000

Hi,

> In actual usage many feature capability indicators (FCIs) are being used to communicate URIs. The ones that communicate URIs listed below are just from one 3GPP 3GPP specification (and there are several other specifications that 
> define feature capability indicators) and many of these FCIs were defined by the authors of RFC 6809. So I think it has been found to be necessary to communicate URIs in FCIs. Usually these URIs are used as the Request-URI of a SIP 
> request and the URI is hosted by the server that included the FCI.
>
> If a UA indicates a URI hosted by it and a UA also indicates certain capabilities such as he supported SIP methods and SIP extensions I think you can infer that the UA supports those methods and extensions and the UA can be contacted at 
> the URI.  When contacting the UA at the indicated URI it seems to me to be a reasonable assumption to make that the methods and extensions also indicated are going to be supported.
>

Again, I don't think one should make such "default assumption". 

Instead, the g.xxx.yyy FCI specification needs to explicitly say that, when used in conjunction with the sip.methods FCI, the sip.methods FCI indicates which SIP methods can be used when using the URI provided by the g.xxx.yyy FCI.

(Of course, the g.xxx.yyy FCI specification itself can also define which SIP methods can be used, if the allowed methods are always the same, in which case there is no need for sip.methods). 

Regards,

Christer

---

From: Andrew Allen <[email-masked]>
Date: Tue, 29 Oct 2013 14:25:31 +0000

Christer

My responses inline

Andrew

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Tuesday, October 29, 2013 3:48 AM
To: Andrew Allen; Paul Kyzivat; [email-masked]
Subject: RE: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators

Hi,

> In actual usage many feature capability indicators (FCIs) are being 
> used to communicate URIs. The ones that communicate URIs listed below 
> are just from one 3GPP 3GPP specification (and there are several other specifications that define feature capability indicators) and many of these FCIs were defined by the authors of RFC 6809. So I think it has been found to be necessary to communicate URIs in FCIs. Usually these URIs are used as the Request-URI of a SIP request and the URI is hosted by the server that included the FCI.
>
> If a UA indicates a URI hosted by it and a UA also indicates certain 
> capabilities such as he supported SIP methods and SIP extensions I think you can infer that the UA supports those methods and extensions and the UA can be contacted at the URI.  When contacting the UA at the indicated URI it seems to me to be a reasonable assumption to make that the methods and extensions also indicated are going to be supported.
>
> If the physical entity inserting the FCIs has different URIs that 
> represent logically different UAs (with different SIP methods and extensions supported) then the different logical UAs and their associated capabilities should be indicated in different  Feature-Caps header fields.

[AA] I am OK to go the approach that we state whether the scope of the FCI (and the URI value of the FCI) is such that other FCIs in the SIP tree include in the same header field apply to that URI or not.

[AA] I am not happy with that approach - I think that is "hidden magic"  that some feature outside of SIP is defining what SIP features are supported.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Oct 2013 10:42:12 -0400

I would appreciate if the two of you would go off and come up with a 
proposal that you both agree is consistent with the language and intent 
of RFC 6809.

What Christer is suggesting *might* work, though I reserve judgement 
until I see that actual language that you settle on. If you go that way, 
then I want to see an explanation of how the sip tree tags are specified.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 29 Oct 2013 15:27:51 +0000

Hi,

>then I want to see an explanation of how the sip tree tags are specified.
I think we would have to say that the sip.x FCIs as such don't provide much information. Instead, they can be used together with OTHER FCIs, to provide additional information about those OTHER FCIs. But, the FCI specifcation of such OTHER FCI MUST describe which sip.x FCIs are used to provide additional information, and how.

Regards,

Chrsiter

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Oct 2013 12:09:41 -0400

Christer,

What you say below seems plausible as a way forward.

It does present a potential problem:

Suppose you do that. And then another tag g.xxx.foo is defined with a 
URI that identifies a foo server and a rule that says the presence or 
absence of +sip.audio and +sip.video indicates whether the foo server at 
the URI supports audio and video.

Then another tag g.xxx.bar is defined with a URI that identifies a bar 
server and a rule that says the presence or absence of +sip.audio and 
+sip.video indicates whether the foo server at the URI supports audio 
and video.

Then something inserts a Feature-Caps entry. It wants to indicate a foo 
server that supports audio, and a bar server that supports video. It 
can't do that in a single entry. It could emit two entries as Andrew 
suggested. Is that valid?

I think it will be necessary to spell out the rules for this sort of 
usage. And this won't necessarily be just for these tags in the sip 
tree. It could apply to other tags as well. If feels more like an 
extension (or maybe just a clarification) of 6809.

	Thanks,
	Paul

On 10/29/13 11:27 AM, Christer Holmberg wrote:
> I think we would have to say that the sip.x FCIs as such don't provide
> much information. Instead, they can be used together with OTHER FCIs, to
> provide additional information about those OTHER FCIs. But, the FCI
> specifcation of such OTHER FCI MUST describe which sip.x FCIs are used
> to provide additional information, and how.
> Regards,
> Chrsiter
>
>>> are just from one 3GPP 3GPP specification (and there are several other specifications that define feature capability indicators) and many of these FCIs were defined by the authors of RFC 6809. So I think it has been found to be necessary to communicate URIs  in FCIs. Usually these URIs are used as the Request-URI of a SIP

---

From: Andrew Allen <[email-masked]>
Date: Tue, 29 Oct 2013 16:57:11 +0000

Do we agree that if a UA indicates it supports a SIP Method or a SIP extension or a SIP event package then that UA supports that SIP Method or that SIP extension or that SIP event package?

If that same UA also indicates a URI that it can be reached at then that UA that can be reached at the advertised URI also supports that SIP Method or that SIP extension or that SIP event package - agree?

So to me the issue to clarify in the global tree FCI that advertises the URI is whether the URI is hosted by the same UA that also indicates the SIP capabilities in the SIP tree FCIs.

Does that make sense?

Andrew

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, October 29, 2013 12:10 PM
To: Christer Holmberg; Andrew Allen; [email-masked]
Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators

Christer,

Suppose you do that. And then another tag g.xxx.foo is defined with a URI that identifies a foo server and a rule that says the presence or absence of +sip.audio and +sip.video indicates whether the foo server at the URI supports audio and video.

Then another tag g.xxx.bar is defined with a URI that identifies a bar server and a rule that says the presence or absence of +sip.audio and 
+sip.video indicates whether the foo server at the URI supports audio
and video.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Oct 2013 13:25:53 -0400

> Do we agree that if a UA indicates it supports a SIP Method or a SIP extension or a SIP event package then that UA supports that SIP Method or that SIP extension or that SIP event package?

Are you are asking this in the context of 3840?

This seems appropriate. But "supports" is a bit slippery.
I think we should be able to assume that support was there at the time 
the indication was made. But it won't necessarily remain true forever. 
And there is no specification of a minimum time that it must remain valid.

Also, "support" also can be nuanced in other ways. For instance isFocus 
may be true for certain dialogs and not others.

So the knowledge imparted by these is "fuzzy".

> If that same UA also indicates a URI that it can be reached at then that UA that can be reached at the advertised URI also supports that SIP Method or that SIP extension or that SIP event package -…

In the context of 3840, yes. (Given the caveats above.)

> So to me the issue to clarify in the global tree FCI that advertises the URI is whether the URI is hosted by the same UA that also indicates the SIP capabilities in the SIP tree FCIs.

I guess this would be an alternative approach to the one Christer 
suggested.

IIUC, you are saying that the definition of g.xxx.foo might say:
- the server posting this FC is a foo server
- the server posting this FC is reachable out of dialog
   at the supplied URI

And then the FCI sip.x tag descriptions would say that they describe 
capabilities of the server posting the FC entry.

This seems a little weird, but it might fly. I'd like to hear what other 
people think.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 29 Oct 2013 18:02:42 +0000

Hi,

In a Contact header field, the URI is a header field parameter, and any media feature tag is by definition associated with that URI.

In Feature-Caps, we don't have such "header field level" URI. If you define a URI value for a FCI, that URI is by default only associated with that FCI.

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: Paul Kyzivat [mailto:[email-masked]] 
Lähetetty: 29. lokakuuta 2013 19:26
Vastaanottaja: Andrew Allen; Christer Holmberg; [email-masked]
Aihe: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators

This seems appropriate. But "supports" is a bit slippery.
I think we should be able to assume that support was there at the time the indication was made. But it won't necessarily remain true forever. 
And there is no specification of a minimum time that it must remain valid.

Also, "support" also can be nuanced in other ways. For instance isFocus may be true for certain dialogs and not others.

> So to me the issue to clarify in the global tree FCI that advertises the URI is whether the URI is hosted by the same UA that also indicates the SIP capabilities in the SIP tree FCIs.

I guess this would be an alternative approach to the one Christer suggested.

And then the FCI sip.x tag descriptions would say that they describe capabilities of the server posting the FC entry.

This seems a little weird, but it might fly. I'd like to hear what other people think.

	Thanks,
	Paul

> Then something inserts a Feature-Caps entry. It wants to indicate a 
> foo server that supports audio, and a bar server that supports video. 
> It can't do that in a single entry. It could emit two entries as 
> Andrew suggested. Is that valid?
>
>>> proposal that you both agree is consistent with the language and 
>>> intent of RFC 6809.
>>>
>>> until I see that actual language that you settle on. If you go that 
>>> way, then I want to see an explanation of how the sip tree tags are specified.
>> I think we would have to say that the sip.x FCIs as such don't 
>> provide much information. Instead, they can be used together with 
>> OTHER FCIs, to provide additional information about those OTHER FCIs. 
>> But, the FCI specifcation of such OTHER FCI MUST describe which sip.x 
>> FCIs are used to provide additional information, and how.
>> Regards,
>> Chrsiter
>>
>>> Subject: RE: [sipcore] New sipcore draft submission 
>>>> used to communicate URIs. The ones that communicate URIs listed 
>>>> below are just from one 3GPP 3GPP specification (and there are 
>>>> several other specifications that define feature capability 
>>>> indicators) and many of these FCIs were defined by the authors of 
>>>> RFC 6809. So I think it has been found to be necessary to 
>>>> communicate URIs  in FCIs. Usually these URIs are used as the 
>>>> Request-URI of a SIP
>>>> If a UA indicates a URI hosted by it and a UA also indicates 
>>>> certain capabilities such as he supported SIP methods and SIP 
>>>> extensions I think you can infer that the UA supports those methods 
>>>> and extensions and the UA can be contacted at the URI.  When 
>>>> contacting the UA at the indicated URI it seems to me to be a 
>>>> reasonable  assumption to make that the methods and extensions also 
>>>> indicated are
>> going to be supported.
>>>>
>>> have

---

From: Andrew Allen <[email-masked]>
Date: Tue, 29 Oct 2013 18:16:12 +0000

However if the FCI defines that the URI is hosted by the entity that inserted it and the sip tree FCIs are also defined as being scoped to the entity that inserted them then they would be associated.

While an entity might indicate an FCI containing a URI not hosted by it I think it problematic for items from the SIP tree to be indicated on behalf of other entities as this would require quite detailed knowledge of the implementations of other entities and could change when ever software is updated on the other entity. E.G. A service proxy may well be aware (by configuration) that server foo supports foobar feature and that the foobar feature can be reached at sip:foobar.example.com;gr but the service proxy is unlikely to have reliable up to date information about all the SIP methods, SIP extensions and SIP event packages supported by foo nor what the media capabilities of foo are.

Andrew

----- Original Message -----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Tuesday, October 29, 2013 01:02 PM Central Standard Time
To: Paul Kyzivat <[email-masked]>; Andrew Allen; [email-masked] <[email-masked]>
Subject: VS: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators

Hi,

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: Paul Kyzivat [mailto:[email-masked]] 
Lähetetty: 29. lokakuuta 2013 19:26
Vastaanottaja: Andrew Allen; Christer Holmberg; [email-masked]
Aihe: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 29 Oct 2013 18:20:21 +0000

Hi,

>suggested. Is that valid?

In my opinion, yes. 6809 does not forbid an entity to insert more than one F-C entry.

Another alternative, of course, is to indicate the SIP methods (and/or whatever other information associated with the FCI) as part of the FCI value itself. Keep in mind that the FCI value can be a string value, so you can put more or less whatever you want in it.

Eg:

Feature-Caps:*;+3gpp.xxx="sip:[email-masked]:methods=INVITE,REFER"

...or something like that. Note, that in this case methods is not a URI parameter, it's just another part of the FCI string value (the syntax of the string value is defined in the FCI specification).

>extension (or maybe just a clarification) of 6809.

Perhaps we'll have to do that at some point. It's probably good to get some implementation feedback from 3GPP (and others) first.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 29 Oct 2013 18:22:12 +0000

Hi,

>However if the FCI defines that the URI is hosted by the entity that inserted it and the sip tree FCIs are also defined as being scoped to the entity that inserted them then they would be associated.

Absolutely. 

But, again, the FCI specification needs to explicitly define that :)

Regards,

Christer

----- Original Message -----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Tuesday, October 29, 2013 01:02 PM Central Standard Time
To: Paul Kyzivat <[email-masked]>; Andrew Allen; [email-masked] <[email-masked]>
Subject: VS: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators

Hi,

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: Paul Kyzivat [mailto:[email-masked]]
Lähetetty: 29. lokakuuta 2013 19:26
Vastaanottaja: Andrew Allen; Christer Holmberg; [email-masked]
Aihe: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 29 Oct 2013 18:25:04 +0000

> [AA] I am not happy with that approach - I think that is "hidden magic"  that some feature outside of SIP is defining what SIP features are supported.

I am not sure what you understand. If a FCI specification says that the URI value of the +g.xxx.yyy FCI can only be used for SIP method X, I don't see that as hidden magic.

Keep in mind that, unlike media feature tags, usage of feature-capability indicators are only defined for SIP. It's a pure SIP mechanism.

Regards,

Christer

---

From: Andrew Allen <[email-masked]>
Date: Tue, 29 Oct 2013 18:26:27 +0000

Paul

My responses below

Andrew

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, October 29, 2013 1:26 PM
To: Andrew Allen; Christer Holmberg; [email-masked]
Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators

[AA] I was really asking in the abstract

[AA] I think there is a difference between supports the capability and I am willing to use the capability. Generally support by a platform for a capability IMHO doesn't change that often (I suppose some devices may have plug in devices such as cameras and headsets that may modify some capabilities). Willingness to use a capability is something else.

[AA]

[AA] One man's weirdness is another mans logic!

	Thanks,
	Paul

---

From: Andrew Allen <[email-masked]>
Date: Tue, 29 Oct 2013 18:28:46 +0000

My proposal is that I modify my draft to define that the sip tree FCIs are scoped to the entity that inserts them.

Then if a global tree FCI is defined that has a URI that is hosted on the entity that inserts it that this is defined in the registration of the global tree FCI.

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Tuesday, October 29, 2013 2:22 PM
To: Andrew Allen; [email-masked]; [email-masked]
Subject: VS: VS: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators

Hi,

Absolutely. 

Regards,

Christer

----- Original Message -----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Tuesday, October 29, 2013 01:02 PM Central Standard Time
To: Paul Kyzivat <[email-masked]>; Andrew Allen; [email-masked] <[email-masked]>
Subject: VS: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators

Hi,

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: Paul Kyzivat [mailto:[email-masked]]
Lähetetty: 29. lokakuuta 2013 19:26
Vastaanottaja: Andrew Allen; Christer Holmberg; [email-masked]
Aihe: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators

	Thanks,
	Paul

---

From: Andrew Allen <[email-masked]>
Date: Tue, 29 Oct 2013 18:33:00 +0000

My view is being explicit is much better

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Tuesday, October 29, 2013 2:25 PM
To: Andrew Allen; Paul Kyzivat; [email-masked]
Subject: VS: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 29 Oct 2013 18:36:49 +0000

> My view is being explicit is much better

RFC 6809 says that the FCI specification needs to be explicit on how a FCI is used - either by defining the procedures, or referencing a specification (e.g. a 3GPP specification) where the procedures are defined.

And, those procedures obviously describe, among other things, which SIP methods can be used. So, if the same set of methods can always be used, there is no need to indicate them in the F-C header field. But, if the set of methods can vary, then it is of course information that needs to be added.

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Tuesday, October 29, 2013 2:25 PM
To: Andrew Allen; Paul Kyzivat; [email-masked]
Subject: VS: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators

Regards,

Christer