Subject: Re: [sipcore] Draft new version: SIP Push -26 - the pull request

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

Hi,

Based on Ben's comments, I have created a pull request:

https://github.com/cdh4u/draft-sip-push/pull/38

I also added an example with the 'sip.pnsreg' media feature tag and feature-capability indicator, as requested by Yehoshua.

If people are ok with the changes, I'd prefer to merge the pull request and submit a new version of the draft before it goes to AUTH48 etc.

Regards,

Christer

On 01/03/2019, 12.37, "sipcore on behalf of Christer Holmberg" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,
    
        >>>   §4.1:
        >>> 
        >>>   - "For privacy and security reasons, a UA MUST NOT insert the SIP URI
        >>>   parameters (except for the pn-purr parameter)”
        >>> 
        >>>   The “except for the pn-purr parameter”part is part of the normative requirement. Please don’t bury it in a parenthetical phrase.
        >>> 
        >>>   - "in non-REGISTER request"
        >>> 
        >>>   Plural Disagreement
        >> 
        >> Can you suggest better wording?
        >
        > either “in non-REGISTER requests” or “in a non-REGISTER request”.
        
        Aaah, now I get it. The intention was so say "in non-REGISTER requests". I will fix it.
    
        ---
         
        >>>   - "request that
        >>>   a push notification is sent”
        >>> 
        >>>   s/is/be  (note that this pattern occurs many times in the draft.)
        >> 
        >> As I indicated to Jean, the wording is the outcome of the previous discussions associated with Ekr's IESG review.
        >
        > I’d be highly surprised if ekr objected to “be”.  it is more grammatically correct than “is”. The subjunctive “be" form is indicated by the fact that we talk about a request for something to happen, not a statement that something is true.
        >
        > I’m not going to block things over it, but I would bet a beer that the RFC editor changes it. :-)
        
        So, you want to say "request that a push notification be sent"?
    
        If that's more grammatically correct I will fix as suggested.
    
        ---
            
        >>>   - "A binding expiration interval MUST be considered too short if the
        >>>   binding would expire before the proxy would request that a push
        >>>   notification is sent to the UA”
        >>> 
        >>>   I’m not sure what to make of that sentence. Presumably the proxy will request the PN when it needs to
        >>>  do so. Perhaps the “would” in “proxy would request” should be “can”? (That is, the interval is so short the
        >>>  proxy is unable to request a PN in time?)
    
        Seems like I skipped this in my earlier reply. I agree that "can" is better, so I will fix as suggested.
    
        ---

        >>>   §5.6.1.2 and §5.6.2: Are the lists of procedure steps supposed to have bullets or numbers?
        >> 
        >> No
        >> 
        >> I think the procedures are very clear thanks to the paragraph separation.
        >
        > Do you mean the indentation? Traditionally indentation has been used in RFCs to show parenthetical explanations or sidebars. 
        > Also, the use of the indented list removes the white space between the paragraphs, which makes them harder to read.
        >
        > Bullets would make them easier to read, and would be more consistent with similar procedure lists earlier in the draft.
        
        Aaaah.... I see what you mean (seems like I was too tired when I replied yesterday).
    
        Yes, the indented procedures shall have bullets. That was the intention. I checked the XML, and the test is a <list>, but I have forgotten 
        to add the bullets. I will do that.
    
        Regards,
    
        Christer 
    
    _______________________________________________
    sipcore mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/sipcore