Re: [sipcore] Syntax of Feature-Caps header - suggestion to remove Feature-Caps header field in REGISTER 555 responses - the pull request

[Christer Holmberg <[e-mail]>]

Hi,

Since nobody has objected to the suggested change, I intend to merge the PR and submit a new version of the draft.

Change: No longer allowed to insert Feature-Caps (and the associated sip.pns feature-capability indicator) in a 555 response.
Reason: RFC 6809 only allows F-C in REGISTER 200 responses.

Regards,

Christer


On 07/03/2019, 12.58, "sipcore on behalf of Christer Holmberg" <[e-mail] on behalf of [e-mail]> wrote:

    The pull request:
    
    https://github.com/cdh4u/draft-sip-push/pull/40
    
    Regards,
    
    Christer
    
    On 07/03/2019, 10.59, "sipcore on behalf of Christer Holmberg" <[e-mail] on behalf of [e-mail]> wrote:
    
        Hi,
        
        I will go ahead and suggest that we REMOVE the usage of the Feature-Caps header field in REGISTER 555 responses. This means that the network cannot inform the UA about supported PNSs in a 555 REGISTER response, but the network can still do it in a 200 REGISTER response (query mode).
        
        Please let me know asap if you disagree with such approach. I will prepare a PR during the day.
        
        Regards,
        
        Christer
        
        
        
        
        
        
        On 06/03/2019, 17.20, "sipcore on behalf of Christer Holmberg" <[e-mail] on behalf of [e-mail]> wrote:
        
            Hi Yehoshua,
            
            >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).
            
            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
            >thought of this use case.
            
            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:[e-mail]> 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 <mailto:[e-mail]> on behalf of Christer Holmberg <mailto:[e-mail]>
            Date: Thursday, 28 February 2019 at 16.50
            To: Yehoshua Gev <mailto:[e-mail]>
            Cc: "mailto:[e-mail]" <mailto:[e-mail]>
            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
             
            
            _______________________________________________
            sipcore mailing list
            [e-mail]
            https://www.ietf.org/mailman/listinfo/sipcore
            
        
        _______________________________________________
        sipcore mailing list
        [e-mail]
        https://www.ietf.org/mailman/listinfo/sipcore
        
    
    _______________________________________________
    sipcore mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/sipcore