Subject: Re: [sipcore] Minor comments on draft-ietf-sipcore-sip-push-06 - The pull request

From: Christer Holmberg <[email-masked]>
Date: Tue, 27 Feb 2018 08:59:47 +0000

Hi,

Based on Yehoshua¹s comments, I have created a pull request.

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

The pull request also contains some minor editorial fixes.

In addition, in the description for FCM, it was noted that I was using the
Sender ID, even though it shall be the Project ID, so I fixed that too.

Regards,

Christer

On 26/02/18 18:57, "sipcore on behalf of Christer Holmberg"
<[email-masked] on behalf of [email-masked]>
wrote:

>Hi,
>
>
>From: Yehoshua Gev [mailto:[email-masked]]
>Sent: 26 February 2018 17:10
>To: Christer Holmberg <[email-masked]>
>Cc: sipcore <[email-masked]>
>Subject: Re: [sipcore] Minor comments on draft-ietf-sipcore-sip-push-06
>
>See Inline.
>
>Thanks.
>
>
>Hi Yehoshua,
>
>>>> 1. First paragraph of section 4:
>>>>    SIP URI parameter in the SIP Contact
>>>>  Should be:
>>>>    SIP URI parameters in the SIP Contact
>>>
>>>Are you sure? Note that there is an ³A² in front of each parameter.
>>
>> I'm not sure :-), IIRC the plural is omitted only if hyphens are used,
>>like "a pn-prid- and pn-param-SIP-URI-parameter".
>> Maybe the sentence can be rephrased to:
>> "The UA MUST include the following SIP URI parameters in the SIP
>>Contact header field URI of the REGISTER request:
>> pn-provider, pn-prid and pn-param (if required for the specific PNS)."
>
>If people think that's better I have no problem to change it.
>
>>>> 2. 4th paragraph of section 5.3.1:
>>>>  I believe the 'sip.pns' should indicate the PNS of the pn-provider.
>>>
>>> The purpose is only to indicate to other proxies that the proxy will
>>>trigger push notifications.
>>
>> I understand, but the proposed ABNF for sip.pns requires a value.
> 
>Aaah... true. I guess it doesn't hurt if the proxy indicates the PNS.
> 
>>>>3. 4th paragraph of section 5.3.2:
>>>>  I think a timeout should be defined for the case the re-registration
>>>>doesn't occur.
>>>
>>> Not sure I understood your comment (are you sure you used the correct
>>>paragraph/section?), but
>>>if the re-registration doesn¹t occur then the registration will
>>>eventually expire.
>>
>> I meant that that paragraph handles the case of a re-registration that
>>fails with non-2xx response, but
>> doesn't handle a case that the re-registration never begins (or at
>>least the proxy doesn't receive it).
>> For handling this case, I suggest adding a timeout (maybe with
>>implementation-specific time), and if it expires reject the request with
>>404.
>
>Aaah... I get it. There is a request to forward, but the re-registration
>REGISTER request never arrives. I will add text about that.
>
>Regards,
>
>Christer
>
>
>
>_______________________________________________
>sipcore mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sipcore