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

From: Christer Holmberg <[email-masked]>
Date: Fri, 12 Oct 2018 09:55:31 +0000

Hi,

Based on Paul’s WGLC comments I have submitted a new version (-19) of draft-sip-push.

The following changes were done:

  *   ABNF
  *   UA text regarding binding expiration (in case of multiple bindings) and usage of PRIDs associated with other UAs

The following pull request was merged for the new version:

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

A big Thank You to Paul for his review!

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Oct 2018 11:37:45 -0400

That resolves my comments.

	Thanks,
	Paul

On 10/12/18 5:55 AM, Christer Holmberg wrote:
>   * UA text regarding binding expiration (in case of multiple bindings)
>     and usage of PRIDs associated with other UAs
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 16 Oct 2018 12:53:51 -0500

I've reviewed -19, and still have a few comments and questions.

I'm ok if dealing with these is deferred to IETF LC, but having an 
answer before then will likely improve the quality of any LC reviews the 
document receives.

1) This document is putting tokens representing the _current_ apple and 
google push services into a registry. What happens if one of those 
companies changes the way their push service works significantly? The 
point of carrying around the pns-provider is to let the consumer of it 
know what not-specified-here thing to do with the pn-prid and pn-param 
(if it's not, the document needs more clarity). If that 
not-specified-here thing changes for a given value, the consumer is 
going to behave incorrectly. Should these names we're putting in for the 
apple and google services be versioned in some fashion?

2) The privacy treatment of 556 is still incomplete. At a minimum, the 
security considerations section needs to point back to the "Note" in 
5.3.2 that says the "proxy operator needs to determine whether it could 
have privacy implications". I'm personally not convinced that we need a 
specific "Push Notification Failed" response. What would something _do_ 
with it differently than they would do with the 480 alternative already 
in the draft? My recommendation is to just remove 556 from the draft 
completely and always send the 480. If we leave 556 in, a thorough 
description of "could have privacy implications" needs to be added.

3) For future-proofing - right now the identifiers we put in pn-prid 
just happen to be minted by the push services we know in a way that fits 
the ABNF for a pn-prid value. What happens if one of those service 
providers changes, or a new service provider shows up with a prid value 
that syntactically won't fit in that parameter. Should we consider 
base64 encoding/decoding or something like it to protect against that?

Nits:

"upstream" and "downstream" in section 5.3.1 are undefined and a likely 
source of confusion. I recommend saying "a proxy between this proxy and 
the UA" when you say "upstream", and "a proxy that is not between the 
push proxy and the UA" when you say downstream.

Consider pointing to the 'reg' event package for one way a proxy would 
be "able to retrieve" registration information in the first paragraph of 
section 5.2.

Why is the sentence "A UA MUST NOT create bindings for other UAS (using 
a different PRID)." in the document? It feels like a "don't do this 
obviously stupid thing the protocol doesn't tell you to do." 
requirement, and those attract trouble. I don't see anything in the 
document that would mislead a UA into acting that way. Adding this might 
have rough edges in the future if a way to delegate the creation of 
bindings is found that makes sense. I recommend removing the sentence.

Micro-Nits:

At the end of section 6, "is wake" -> "is awake"

On 10/12/18 4:55 AM, Christer Holmberg wrote:
>   * UA text regarding binding expiration (in case of multiple
>     bindings) and usage of PRIDs associated with other UAs
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Oct 2018 14:11:10 -0400

> base64 encoding/decoding or something like it to protect against that?

ISTM it would make more sense to require each push service to provide an 
ID that syntactically fits here. If they want to use base64 to do that 
is up to them.

	Thanks,
	Paul

---

From: Robert Sparks <[email-masked]>
Date: Tue, 16 Oct 2018 13:33:38 -0500

On 10/16/18 1:11 PM, Paul Kyzivat wrote:
>> just happen to be minted by the push services we know in a way that 
>> fits the ABNF for a pn-prid value. What happens if one of those 
>> service providers changes, or a new service provider shows up with a 
>> prid value that syntactically won't fit in that parameter. Should we 
>> consider base64 encoding/decoding or something like it to protect 
>> against that?
>
> ISTM it would make more sense to require each push service to provide 
> an ID that syntactically fits here. If they want to use base64 to do 
> that is up to them.
You think Apple's team working on their push service is paying attention 
to our desire to carry the tokens they create around in SIP?

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Oct 2018 14:39:58 -0400

> to our desire to carry the tokens they create around in SIP?

Let me put it differently:

*Somebody* needs to specify the ID to be used for each service, and it 
needs to be something that fits syntactically. It doesn't need to be 
Apple, just somebody making the registration on behalf of Apple. The 
most likely way seems to be by publishing a document and referencing it 
in the registration. For the first few it could be included in this 
document. This document can then make reference to whatever proprietary 
things it needs.

	Thanks,
	Paul

---

From: Robert Sparks <[email-masked]>
Date: Tue, 16 Oct 2018 13:48:49 -0500

On 10/16/18 1:39 PM, Paul Kyzivat wrote:
>>>> 3) For future-proofing - right now the identifiers we put in 
>>>> pn-prid just happen to be minted by the push services we know in a 
>>>> way that fits the ABNF for a pn-prid value. What happens if one of 
>>>> those service providers changes, or a new service provider shows up 
>>>> with a prid value that syntactically won't fit in that parameter. 
>>>> Should we consider base64 encoding/decoding or something like it to 
>>>> protect against that?
>>>
>>> ISTM it would make more sense to require each push service to 
>>> provide an ID that syntactically fits here. If they want to use 
>>> base64 to do that is up to them.
>> You think Apple's team working on their push service is paying 
>> attention to our desire to carry the tokens they create around in SIP?
>
> most likely way seems to be by publishing a document and referencing 
> it in the registration. For the first few it could be included in this 
> document. This document can then make reference to whatever 
> proprietary things it needs.
Wait - I think you're looking at the wrong thing.
I had a different item about the identifier that you _register_. I'm not 
that concerned about whether those fit syntactically in our messages.
That is not the concern in 3 above.

I'm talking now about the pn-prid - the bits that you get when you _USE_ 
the service that you hand back to say "wake that thing up".

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 17 Oct 2018 10:31:37 +0000

Hi,

The draft says:

"Parameter value characters that are not part of pvalue needs to be escaped, as defined in RFC 3261."

So, I think the current syntax is ok.

Regards,

Christer

On 16/10/2018, 21.49, "sipcore on behalf of Robert Sparks" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Oct 2018 11:52:26 -0400

> the service that you hand back to say "wake that thing up".

Yes, I understand that.

What I'm saying is that each service has *something* that needs to be 
identified and mapped to this particular sip syntax. Each service will 
have its own nomenclature. (Most won't have something that they call a 
pn-prid.) So there needs to be something that specifies what is to be 
mapped to pn-prid, and how. It needn't be a direct byte-for-byte 
mapping. The mapping simply needs to be well defined and invertable.

In some cases it may be possible for the id to be direct mapped 
byte-by-byte. If not, sip escape codes are one possibility. Hex or 
radix64 are other possibilities. But this need not be consistent across 
services.

	Thanks,
	Paul