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

[Christer Holmberg <[e-mail]>]

Hi Ben,

Thanks for your comments! Please see inline.
    
>    §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?

---
  
>    §4.1.4:
>    - "The indicator value indicates
>    the minimum time (given in seconds), prior to the binding expiration
>    when the UA MUST send the REGISTER request.”
>    
>    That MUST is a statement of fact. (The normative requirement was in the previous sentence.)

I suggest s/MUST/needs to.
    
>    - "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.

---

>    §5.6.1.1:
>    - “it indicates that a proxy between this proxy and the UA supports the
>    type of PNS supported by the UA”
>    s/“a proxy”/“another proxy”
  
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?)
    
>    §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. 
  
---

>    §5.6.1.2: "This will inform proxies between the proxy and the
>    registrar”
>    s/proxies/“any other proxies”
  
Will fix as suggested.

---

>    §5.6.2:
>    - "SIP requests in the queue”
>    
>    There’s a remaining “queue” reference that has resisted being bucketized.
  
I did search for all queues, but it seems I missed one after all... I will fix it.

---
  
>    - (substantive): "If the proxy is able to authenticate the sender of the REGISTER  request”
>    
>    I realize you changed this due to my comment, but I don’t think that removing “authorize” completely 
>    was the right answer. The proxy has to know the authorization policy in addition to authenticating; just 
>    because the message is authenticated doesn’t mean it is allowed. I suggest something to the effect of “If 
>   the proxy is able to authenticate the sender of the REGISTER request and verify that it is allowed by authorization policy…”

That looks good. I will fix as suggested.
    
>    - Figure 3: Will the response to the last REGISTER request contain PURR?
  
Yes. I will add it.

---

Thanks!

Regards,

Christer