Re: [sipcore] Draft new version: SIP Push -26

[Christer Holmberg <[e-mail]>]

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