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

[Ben Campbell <[e-mail]>]

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 <[e-mail]> wrote:
> 
> Hi,
> 
> I have submitted a new version (-26) of SIP Push. It contains editorial fixes provided by Jean.
> 
> Regards,
> 
> Christer
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore