Subject: Re: [sipcore] Syntax of Feature-Caps header

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Mar 2019 11:22:25 +0000

Hi,

I also noted that adding the ‘+’ is not enough. Note that the Feature-Caps header field syntax also mandates the ‘*’.

So, the correct way is:

Feature-Caps: *;+sip.608

Regards,

Christer

From: sipcore <[email-masked]> on behalf of Christer Holmberg <[email-masked]>
Date: Thursday, 28 February 2019 at 16.50
To: Yehoshua Gev <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [sipcore] Syntax of Feature-Caps header

HI Yehoshua,

Please see inline.

>I have a question regarding the syntax of the Feature-Caps header since I've not managed to find any real examples of its usage.
>
>The ABNF in RFC 6809 is defined as:
>   Feature-Caps = "Feature-Caps" HCOLON fc-value
>                   *(COMMA fc-value)
>   fc-value     = "*" *(SEMI feature-cap)
>   feature-cap       =  "+" fcap-name [EQUAL LDQUOT (fcap-value-list
>                            / fcap-string-value ) RDQUOT]
>
> Following this syntax, I guess that for sip-push the header will look like:
>   Feature-Caps: *;+sip.pns="webpush"
>
>
>One example I could find is on https://tools.ietf.org/html/draft-ietf-sipcore-rejected-03:
>   Feature-Caps: sip.608
>Without the asterisk and the plus sign.
>
> Which one is correct?

The sip.pns example is correct. The sip.608 example needs to be corrected.

(I THINK I had previously commented on this when reading sipcore-rejected, but I may be wrong…)

>Due to the lack of examples, would it be possible to add an example to the sip-push draft that includes feature capabilities
>and media tags (especially that sip.pnsreg is used for both)?

I will look into it. I guess that could be done when addressing Ben’s comments.

Regards,

Christer

---

From: Yehoshua Gev <[email-masked]>
Date: Wed, 6 Mar 2019 16:59:16 +0200

Hi Christer,

Thanks for the additional examples.

The last fix you made in the example made me re-read RFC 6809.
I noticed that the RFC indicates that:

   The Feature-Caps header field can be used within a SIP REGISTER
   request and within the 200 (OK) response associated with such a
   request.

Although not explicitly forbidden, a Feature-Caps header is not expected to
be included in non-200 responses.
In the draft, there are cases that do include Feature-Caps header in such
responses (like 555).

I believe that the draft makes a correct use of the header, but it might be
worth thinking why RFC 6809 has not
thought of this use case.

Best,
Yehoshua

On Fri, Mar 1, 2019 at 1:22 PM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
>
>
> I also noted that adding the ‘+’ is not enough. Note that the Feature-Caps
> header field syntax also mandates the ‘*’.
>
>
>
> So, the correct way is:
>
>
>
> Feature-Caps: *;+sip.608
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
> *From: *sipcore <[email-masked]> on behalf of Christer Holmberg
> <[email-masked]>
> *Date: *Thursday, 28 February 2019 at 16.50
> *To: *Yehoshua Gev <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [sipcore] Syntax of Feature-Caps header
>
>
>
> HI Yehoshua,
>
>
>
> Please see inline.
>
>
>
> >I have a question regarding the syntax of the Feature-Caps header since
> I've not managed to find any real examples of its usage.
>
> >
>
> *>   Feature-Caps: *;+sip.pns="webpush"*
>
> >
>
> >
>
> >One example I could find is on
> https://tools.ietf.org/html/draft-ietf-sipcore-rejected-03:
>
> *>   Feature-Caps: sip.608*
>
> >Due to the lack of examples, would it be possible to add an example to
> the sip-push draft that includes feature capabilities
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 6 Mar 2019 15:20:12 +0000

Hi Yehoshua,

> Although not explicitly forbidden, a Feature-Caps header is not expected to be included in non-200 responses.
> In the draft, there are cases that do include Feature-Caps header in such responses (like 555).

Correct. Good catch.

>I believe that the draft makes a correct use of the header, but it might be worth thinking why RFC 6809 has not

I assume the reason is that the scope of a feature-capability indicator is the binding created by a REGISTER/200.

One option would be to say that sip-push updates 6809 by allowing the Feature-Caps header in 555.

Another option would be to remove the Feature-Caps header from 555 responses. It wouldn't affect the mechanism in general, as it only provides additional information (and, including F-C in 555 is only a SHOULD). If a UA supports multiple PNSs it can always perform a query to find out what PNSs the network support. If the UA only supports one PNS, and the network doesn't support it and sends 555, it doesn't really matter to the UA what PNS the network supports.

Regards,

Christer

On Fri, Mar 1, 2019 at 1:22 PM Christer Holmberg <mailto:[email-masked]> wrote:
Hi,

So, the correct way is:
 
Feature-Caps: *;+sip.608
 
Regards,
 
Christer

From: sipcore <mailto:[email-masked]> on behalf of Christer Holmberg <mailto:[email-masked]>
Date: Thursday, 28 February 2019 at 16.50
To: Yehoshua Gev <mailto:[email-masked]>
Cc: "mailto:[email-masked]" <mailto:[email-masked]>
Subject: Re: [sipcore] Syntax of Feature-Caps header
 
HI Yehoshua,
 
Please see inline.

 

 
Regards,
 
Christer