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

From: Christer Holmberg <[email-masked]>
Date: Sun, 24 Feb 2019 18:21:24 +0000

Hi,

I have submitted a new version (-26) of SIP Push. It contains editorial fixes provided by Jean.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Wed, 27 Feb 2019 17:58:40 -0600

I have a few minor (mostly editorial) comments. These can be addressed if there is a next release prior to approval, or during AUTH48:

Thanks!

Ben.

-------------------------

§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

§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.)

- "request that
a push notification is sent”

s/is/be  (note that this pattern occurs many times in the draft.)

§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”

- "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?

§5.6.1.2: "This will inform proxies between the proxy and the
registrar”
s/proxies/“any other proxies”

§5.6.2:
- "SIP requests in the queue”

There’s a remaining “queue” reference that has resisted being bucketized.

- (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…”

- Figure 3: Will the response to the last REGISTER request contain PURR?

> On Feb 24, 2019, at 12:21 PM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Yehoshua Gev <[email-masked]>
Date: Thu, 28 Feb 2019 16:23:26 +0200

Hi Christer,

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?

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)?

Thanks,
Yehoshua

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 28 Feb 2019 14:49:47 +0000

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

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: Christer Holmberg <[email-masked]>
Date: Thu, 28 Feb 2019 19:41:43 +0000

Hi Ben,

Thanks for your comments! Please see inline.
    
>    - "in non-REGISTER request"
  
Can you suggest better wording?

---
  
>    That MUST is a statement of fact. (The normative requirement was in the previous sentence.)

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

---

>    s/“a proxy”/“another proxy”
  
I will fix as suggested.

>    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. 
  
---

>    s/proxies/“any other proxies”
  
Will fix as suggested.

---

>    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

---

From: Ben Campbell <[email-masked]>
Date: Thu, 28 Feb 2019 14:05:04 -0600

> On Feb 28, 2019, at 1:41 PM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Ben,
> 

either “in non-REGISTER requests” or “in a non-REGISTER request”.

> I suggest s/MUST/needs to.

WFM.

> 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. :-)

[…]

> 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.

[…]