Subject: [sipcore] Draft new version: draft-sip-push-01

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 Oct 2017 06:53:22 +0000

Hi,

I’ve submitted a new version (-01) of draft-holmberg-sipcore-sip-push.

The new version contain more text, including the creation of an IANA registry for pn-type values. The draft also adds two values to the new registry: “apns” (Apple Push Notification service) and “fcm” (Firebase Cloud Messaging).

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Oct 2017 12:05:37 -0400

On 10/27/17 2:53 AM, Christer Holmberg wrote:
> The new version contain more text, including the creation of an IANA 
> registry for pn-type values. The draft also adds two values to the new 
> registry: “apns” (Apple Push Notification service) and “fcm” (Firebase 
> Cloud Messaging).

Thanks for adding the registry.

I have a few other concerns:

The parameters pn-enckey and pn-enccode appear in the syntax but have no 
semantics defined. That needs to be added. And then the use (or non-use) 
and form for each of pn-prid, pn-enckey, and pn-enccode for a particular 
pn-type ought to be specified in the pn-type registry, or in the 
document referenced from there.

Why is it that there are four related parameters that are used in 
concert to provide pieces of the required information, and then pn-type 
has a two-part value? ISTM it would make more sense to either:

1) make the two parts of pn-type be separate parameters,

      uri-parameter   =/ pn-type / pn-param /pn-prid
                       / pn-enccode / pn-enckey
      pn-type         = "pn-type" EQUAL pns-provider
      pn-param        = "pn-param" EQUAL pns-param
      pn-prid         = "pn-prid" EQUAL pvalue
      pn-enccode      = "pn-enccode" EQUAL pvalue
      pn-enckey       = "pn-enckey" EQUAL pvalue

      pns-provider    = 1*alphanum
      pns-param       = pvalue

2) OR else combine all of pns-param, pn-enckey value and pn-enccode 
value into a single parameter with detailed syntax defined on a 
per-pn-type basis,

      uri-parameter   =/ pn-type / pn-value
      pn-type         = "pn-type" EQUAL pns-provider
      pns-provider    = 1*alphanum
      pn-value        = "pn-value" EQUAL pvalue

3) OR it could even be made into a single parameter.

      uri-parameter   =/ pn-param
      pn-param        = "pn" EQUAL pns-provider COLON pn-value
      pns-provider    = 1*alphanum
      pn-value        = pvalue

Of all those I prefer (3), but this is a matter of taste.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 Oct 2017 17:15:40 +0000

Hi,

>> I've submitted a new version (-01) of draft-holmberg-sipcore-sip-push.
>> 
>> registry: "apns" (Apple Push Notification service) and "fcm" (Firebase 
>> Cloud Messaging).
>
> The parameters pn-enckey and pn-enccode appear in the syntax but have no semantics defined. That needs to be added.

pn-enckey and pn-enccode are not needed by the push notification service mechanism as such, and are therefore independent of the pn-type. 

Section 4 says:

"The pn-enckey URI parameter contains the public key, and the pn-encsec URI parameter contains the authentication secret [I-D.ietf-webpush-encryption]."

But, they may not be feasible in all cases, if e.g., the payload contains information that needs to be accessible by the push notification server, so it would be good to mention that.

> And then the use (or non-use) and form for each of pn-prid, pn-enckey, and pn-enccode for a particular pn-type ought
> to be specified in the pn-type registry, or in the document referenced from there.

Sections 8 and 9 do define the use and form for pn-prid and pn-type for "apns" and "fcm". 

But, I realize there is no text saying it has to be done, so it needs to be added. The idea is that it has to be specified in the referenced document.

>Why is it that there are four related parameters that are used in concert to provide pieces of the required information, and 
>then pn-type has a two-part value? ISTM it would make more sense to either:
>
> 2) OR else combine all of pns-param, pn-enckey value and pn-enccode value into a single parameter with detailed syntax defined on a per-pn-type basis,
>

Isn't 3) more or less identical to the current syntax? The only difference is that the encoded value of the parameter name is "pn" instead of "pn-type".

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Oct 2017 15:34:45 -0400

> But, I realize there is no text saying it has to be done, so it needs to be added. The idea is that it has to be specified in the referenced document.

Just a few words about what the document must include should do the trick.

> Isn't 3) more or less identical to the current syntax? The only difference is that the encoded value of the parameter name is "pn" instead of "pn-type".

No, because it is assuming that pn-value includes all the information 
that the other syntaxes include in all the other parameters. The form 
for packing whatever it is into the value would be specified by the 
document for the provider.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 28 Oct 2017 08:30:51 +0000

Hi,

...

>>> concert to provide pieces of the required information, and then pn-type has a two-part value? ISTM it would make more sense to either:
>>>
> No, because it is assuming that pn-value includes all the information that the other syntaxes include in all the
> other parameters. The form for packing whatever it is into the value would be specified by the document for the provider.

I am still not following :)

You suggest:

The draft says:

pn-type            = "pn-type" EQUAL pns-provider COLON pns-param
pns-param       = pvalue

...so, if I replace pns-param wih pvalue it becomes:

pn-type            = "pn-type" EQUAL pns-provider COLON pvalue

How is that different from your suggestion? :)

(You don't comment on pn-prid, so I assume that parameter would stay unchanged?)

Regards,

Christer

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 28 Oct 2017 12:02:13 -0400

> (You don't comment on pn-prid, so I assume that parameter would stay unchanged?)

No. In (3) there is no prid or enckey or enccode in the syntax. Instead, 
if those are needed for this push service then they are embedded within 
pn-value. It would be up to the definition of the particular pn type to 
specify what goes into the value.

So while the names are similar to parts of the current syntax the usage 
is different.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 29 Oct 2017 10:12:06 +0000

Hi,

...
 
>>> that the other syntaxes include in all the other parameters. The form for packing whatever it is into the value would be specified by the document for the provider.
>> 
> No. In (3) there is no prid or enckey or enccode in the syntax. Instead, if those are needed for this push 
> service then they are embedded within pn-value.

Aaah... ok, now I get it.

The reason I have kept pn-prid separate is because the value could be a URL, which means it could include the same character as is used as separator. If such character occurs within the URI it would have to be escaped, and I would like to avoid that.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 29 Oct 2017 12:56:21 -0400

> The reason I have kept pn-prid separate is because the value could be a URL, which means it could include the same character as is used as separator. If such character occurs within the URI it woul…

If (3) were being used then I expect that the provider that needs a URI 
could find a way to make that work in the value syntax.

But choosing an approach is at least partly an aesthetic decision. As 
long as whatever way you choose is well defined I won't object (much).

	Thanks,
	Paul

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 29 Oct 2017 17:07:33 +0000

(I noted my previous reply to this was sent to Paul only)
 
Hi,

...

>>> No. In (3) there is no prid or enckey or enccode in the syntax. 
>>> Instead, if those are needed for this push service then they are embedded within pn-value.
>> 
>> The reason I have kept pn-prid separate is because the value could be a URL, which means it 
>> could include the same character as is used as separator. If such character occurs within the URI 
>> it would have to be escaped, and I would like to avoid that.
>
> If (3) were being used then I expect that the provider that needs a URI could find a way to make that work in the value syntax.

The client will get the PRID from the provider, and the idea is that it will copy/paste it into the SIP pn-prid parameter without modifications (escaping etc).

> But choosing an approach is at least partly an aesthetic decision. As long as whatever way you choose is well defined I won't object (much).

I will keep the syntax as it is for now, but I will add/modify text based on your other comments. I will try to do it before the Singapore submission window closes.

Regards,

Christer