Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-sip-push-11 - Other issues

From: Christer Holmberg <[email-masked]>
Date: Wed, 8 Aug 2018 10:27:46 +0000

Hi Ben,

In this reply I address your other issues.

Other Substantive Comments:

---

>§1
>-  Does this draft claim compatibility with APNS and FCM? Can you offer citations for those?

I am not exactly sure what you mean. Sections 8 and 9 describe how the mechanism can be used with APNS and FCM.

>- " When the proxy receives (or, if the proxy is the SIP registrar[RFC3261], initiates) a SIP request for a new dialog”
>I don’t understand the intent here; registrars do not normally initiate SIP requests for new dialogs.

This is related to your major issue #2. It is the "home proxy of the UA", not the registrar. And, it does not initiate requests, it forwards them.

>“Different PNSs exist today.  Some are based on the standardized mechanism defined in [ RFC8030 ], while others are 
>proprietary (e.g., the Apple Push Notification service).”
>
>Is there an assumption that they are all similar enough that this mechanism can work with all of them? If so, please say that explicitly. 

I could modify the following sentence:

"Figure 1 shows the generic push notification architecture supported by the mechanism in this document. The mechanism in this document can be used with any push notification mechanism that is based on that architecture, and where the SIP UA is able to provide the information needed for the SIP proxy to request push notifications towards the UA."

---

>§2: Please use the new boilerplate from RFC 8174.

Ok.

---

>§4.1: 
>- Please cite RFC 6809 on the first mention of feature-caps. 

Ok.

>- Please elaborate on the practical effect of supporting VAPID.

I am not sure how much information this document should contain. There is already a reference, and the Security Considerations contains the following paragraph:

   "[RFC8292] defines a mechanism which allows a proxy to create a
   identity itself to a PNS, by signing a JWT sent to the PNS using a
   key pair.  The public key serves as an identifier of the proxy, and
   can be used by devices to restrict push notifications to the proxy
   associated with the key."

(Later you have a comment on this paragraph, but it is editorial)

>- " If the REGISTER response does not contain a a ’sip.pnsreg’ feature- capability indicator, the UA SHOULD only send a 
>re-registration REGISTER request when it receives a push notification (even if the UA is able to use a non-push mechanism for 
>sending re-registration REGISTER requests).”
>
>Why? That’s normal SIP behavior for UAs that do not support this mechanism, so the registrar must be able to handle it. 
>(If there’s a good reason, please explain it in the draft.)

The registrar will for sure be able to handle it, but if the proxy is anyway going to trigger REGISTER requests using push notifications, I see no reason for the UA to trigger REGISTER requests "on its own".

---

>- “ NOTE: If the SIP UA application wants to use push notifications for
>   other purposes than to trigger re-registration requests, it needs to
>   be able to distinguish between the different purposes when receiving
>   push notifications.  Mechanisms for doing that are outside the scope
>   of this specification."
>
> I can see keeping how you distinguish between SIP related notifications and other kinds of notifications. But what if the UA uses 
> more than one SIP services that supports push notifications?

Each UA application will have a separate push notification subscription, use separate registrations etc.

(Now, if a single UA handles multiple SIP services I see no reason from a non-push scenario: when the UA receives a request it needs to figure out to which service the request is "dispatched".)

---

>§5.2: “ It is RECOMMENDED that the proxy requests the push notification at least 120 seconds before the registration 
>expires.” - We usually recommend refreshing bindings at when half of the expiration time has passed. Is there a reason 
>to do this differently? If so, why 120 seconds in particular; has there been analysis of push notification latency?

I believe 120 seconds was suggested by Dale. We haven't done any further analysis within the WG.

Regarding sending when half of the expiration time as passed, in deployments the registration expiration timers are normally pretty long, so I am not sure there is a need to send at "half time".

---

>§5.3.1:
>-  “ If the proxy considers the requested registration expiration interval
>   [RFC3261] to be too short, the proxy MUST either send a 423 (Interval
>   Too Brief) response to the REGISTER request, or skip the rest of the
>   procedures in this section and process the REGISTER request using
>   normal SIP procedures. "
>
> That _is_ normal SIP procedure. What do you mean to be different?

Nothing :)

I can remove the text, or simply re-write it as an informative "As defined in RFC 3261, if the proxy..." statement.

>- " if the proxy received a ’sip.pnsreg’ media feature tag in theREGISTER request, the proxy SHOULD include a ’sip.pnsreg’ 
>feature-capability indicator with an indicator value bigger than 120 inthe response, unless the proxy always want to request 
>push notifications to trigger the UA to send a REGISTER request.”
>
>It’s not clear to me why the proxy should be able to override the UAs choice.

Again, I believe this is based on Dale's comment that we should make sure that REGISTER requests (no matter what triggers them) are sent at least 120 seconds before expiration.

---

>§5.3.2: 
>-"When the proxy receives (or, in case the proxy is the registrar, creates) a SIP request for a new dialog…”
>Why would a registrar create a SIP request for a new dialog?

It doesn't. Will be fixed.

>- “ If the contact of the most recent REGISTER
>   2xx response and Request-URI do not match, the proxy MUST reject the
>   SIP request with a 404 (Not Found) response.  This can happen if the
>   UA sends a re-registration REGISTER request with a new contact at the
>   same time the registrar forwards a SIP request towards a UA using the
>   previously registered contact in the Request-URI.”
>
> Why doesn’t the proxy forward using normal SIP procedures? It’s entirely possible that an UAS address changes during an inbound transaction 
> in normal SIP. Why is that different with push notifications? (this section seems to replace normal SIP request routing. That shouldn’t happen 
> without a really good reason. If normal SIP procedures are inadequate, please explain why.

In order for the proxy to forward the SIP request, it needs to be able to match the R-URI of the request with the contact in the REGISTER request/response. 

Now, the proxy could of course not wait for the REGISTER response, and simply forward the request when it receives a REGISTER request with a contact that matches the R-URI. But, if the registrar for whatever reason no longer accepts the registered contact, the proxy have forwarded the request before the REGISTER response informs it about the not-accepted contact. 

But, as you say, that could happen with any proxy, so we could say that the proxy forwards the request as soon as it receives a REGISTER request with a matching contact. That would also be better from the non-invite-transaction-timeout perspective, as the proxy does not need to wait for the REGISTER response before it forwards the request.

---

>§6.2: Why does the UAC need to know the failure was due to push notification? What would it do differently than for other kinds of 
>failures? (This seems like a privacy leak; does the recipient want the sender to know he or she is on a mobile 
>device?)

I am not sure whether the information is very useful for the UAC, but the "home proxy" may perhaps trigger different actions depending on what response it receives.

Push can also be used on non-mobile devices, e.g., on tablets where one wants to save battery.

---

>§11: “ If the push notification related information carried in SIP could be
>   used by a malicious middleman to trigger push notifications towards a
>   device, operators MUST ensure that the SIP signalling is properly
>   secured from malicious middlemen, e.g., using encryption.”
>
> This could use some elaboration. I think the sense of this is backwards. That is, the signaling MUST be secured unless 
> there are factors that make it impossible for an active attacker to use the informaiton.

Isn't that what the text says? :)

---

>§12.5: The template contains a “document” field, but the registration policy is “expert review”. Should this be “specification required”?

"Document" (or "Reference") is used also for "expert review", isn't it?

===

Editorial Comments:

>- General: 
>— The draft has some readability issues. In particular, it pervasively uses long, convoluted sentences, lots of imbedded parenthetical 
>phrases, improper comma placement, etc.
>— The draft pervasively mixes registration procedures with the handling of inbound SIP requests. Please consider separating those into 
>different sections. I realize there are interdependencies, but it’s hard to follow as is.

I will look into it, but when it comes to comma placements etc it would be very useful with input from an English speaker on how to fix it.

>- Abstract: s/awake/wake ; (or awaken)  (“awake” is not a verb. This repeats elsewhere in the draft. .)

Someone told me to use "awake". But, I can change it.

---

§1,
>- first paragraph: 
>-- Saying push notification is the only way to solve these issues seems overstated. It’s one way; there might be others.

Not necessarily. But, I will change the text.

>-- when you talk about “each operating” system, you are talking about popular mobile operating system vendors, right? 
>The assertion seems less true for operating systems in general.

You could e.g., have a tablet running a non-mobile operating system that want to use the mechanism in order to save battery.

>- 4th paragraph: The usual term for re-registration is “binding refresh”.

"re-register" is a common word, used also in other specifications.

>-4th paragraph: “battery life etc”? What else?

I will remove "etc".

>- figure 1: The page break is unfortunate; can the ladder diagram be kept all on the same page?

I will fix that.

---

§5.1, heading: Should “PNS Identifier” be “PNS Provider” (since that is what the section talks about.)

Will fix.

---

>§5.2: 
>- “...the SIP proxy MUST have information” - the MUST seems like a statement of fact, not a normative requirements.

I suggest to say "the SIP proxy needs to have information".

>- “ If the proxy receives information that a registration has expired,…” - Bindings expire, not registrations. (Much of the draft uses the 
>word “registration” when the common term is “binding"

I can try to fix that, but that will probably require other re-writings too.

---

>§5.3, heading: s/Request/Requests

Will fix.

---

>§5.3.1: “ If the proxy sends a SIP 555 (Push Notification Service Not Supported) response”
>It would be helpful to describe 555 before this.

Are you suggesting to move section 6 (Grammar) up?

---

>§5.3.2: “ The proxy MUST NOT include the SIP request as payload in the
>   requested push message.”
>Wasn’t there already text forbidding payloads in general?

There is a note in the UA section saying that the spec doesn't define any usage of push notification payloads, and that the UA can discard it if present.

---

>§6.7: "  Parameter value chapters that are not part of pvalue needs to be escaped, as defined in RFC 3261.”
>
>What is a parameter value chapter? Should “chapters” be “characters”?

Correct :) Will fix.

---

>§7: This information belongs in the IANA considerations section.

Ok. I can move it there.

---

>§11: “ [RFC8292] defines a mechanism which allows a proxy to create a
>   identity itself to a PNS, by signing a JWT sent to the PNS using a
>   key pair."
>I can’t parse the first clause. Are there missing words?

I suggest to remove "create a".

---

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Tue, 21 Aug 2018 17:06:49 -0500

Hi, apologies for the delay in responding. My last couple of weeks have been crazy busy.  Please see inline; I’ve removed sections that do not seem to need further discussion. I’ve read the list discussion and version 13 of the draft, and am responding from that context (but forgive me if I missed a change that addresses any of them.)

> On Aug 8, 2018, at 5:27 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Ben,
> 

Right. I guess I was reviewing linearly :-)

> This is related to your major issue #2. It is the "home proxy of the UA", not the registrar. And, it does not initiate requests, it forwards them.

Okay

> "Figure 1 shows the generic push notification architecture supported by the mechanism in this document. The mechanism in this document can be used with any push notification mechanism that is based on that architecture, and where the SIP UA is able to provide the information needed for the SIP proxy to request push notifications towards the UA.”
> 

WFM

[...]

> (Later you have a comment on this paragraph, but it is editorial)

I was asking about the impact on the SIP behavior. Do we expect the SIP client to do something with the capability indicator value? Maybe record the value pass it to the “push" client? Only send a new register when the right VAPID related things happens in the push protocol?

> The registrar will for sure be able to handle it, but if the proxy is anyway going to trigger REGISTER requests using push notifications, I see no reason for the UA to trigger REGISTER requests "on its own”.

So the concern is additional unnecessary REGISTER requests?

What happens if a binding is about to expire, but the client hasn’t gotten a push notification? What if the clients network configuration changes in a way that forces adding or removing contacts; should it wait for a push notification to send a new REGISTER request? Can it terminate a binding proactively, or does it need to wait for that, too?

> (Now, if a single UA handles multiple SIP services I see no reason from a non-push scenario: when the UA receives a request it needs to figure out to which service the request is "dispatched”.)

I was thinking in terms of a single UA application. Let’s say it has successfully registered with service FOO and service BAR. They both support push. If it gets a push notification, how does it know which binding to refresh? Should it refresh both?

> Regarding sending when half of the expiration time as passed, in deployments the registration expiration timers are normally pretty long, so I am not sure there is a need to send at "half time”.

Okay

> I can remove the text, or simply re-write it as an informative "As defined in RFC 3261, if the proxy..." statement.

Okay

> Again, I believe this is based on Dale's comment that we should make sure that REGISTER requests (no matter what triggers them) are sent at least 120 seconds before expiration.

Nevermind, I misread the text :-)

[...]

> But, as you say, that could happen with any proxy, so we could say that the proxy forwards the request as soon as it receives a REGISTER request with a matching contact. That would also be better f…

I see there’s been some discussion of this, but for the record, my question was not about waiting for the response, it was about requiring the R-URI to match the contact from that particular REGISTER.

For normal SIP, there’s always the chance a client may change it’s contact between the time the home proxy retargets the request and it arrives (or fails to arrive) at the client. Is that problem worse with push? (Maybe it is, if we assume that push clients do not proactively send new REGISTER requests when their contacts change)

> Push can also be used on non-mobile devices, e.g., on tablets where one wants to save battery.

Regardless, it tells the sender something about the client’s device that it did not already know. I think we need better justification than just saying the home proxy might need it; are there expected scenarios where it _will_ need it?

> Isn't that what the text says? :)

It changes the burden of proof. The original text suggests that they only need to secure the signaling if they think they the information could be used maliciously. My suggestion is to say they need to secure the signaling unless they are sure it cannot be used maliciously. These are not the same thing.

> "Document" (or "Reference") is used also for "expert review", isn't it?

“Expert Review” does not necessarily require a document. “Specification required” does.

> Someone told me to use "awake". But, I can change it.

Maybe they meant “awaken”?

[...]

> Are you suggesting to move section 6 (Grammar) up?

Not necessarily; just a brief mention that it’s defined in this document. Or just a forward reference.

[...]

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Aug 2018 08:16:14 +0000

Hi,

...

>> I am not sure how much information this document should contain. There
>>is already a reference, and the Security Considerations contains the
>>following paragraph:
>> 
>I was asking about the impact on the SIP behavior. Do we expect the SIP
>client to do something with the capability indicator value? Maybe record
>the value pass it to the ³push" client? Only send a new register when the
>right VAPID related things happens in the push protocol?

VAPID is used to restrict the push notifications the SIP UA will receive
in the first place. But, once it does receive a push notification, there
is no special behaviour. It will send a REGISTER etc, using the normal
procedures.

---

>> 
>>> - " If the REGISTER response does not contain a a ¹sip.pnsreg¹
>>>feature- capability indicator, the UA SHOULD only send a
>>> re-registration REGISTER request when it receives a push notification
>>>(even if the UA is able to use a non-push mechanism for
>>> sending re-registration REGISTER requests).²
>>> 
>>> Why? That¹s normal SIP behavior for UAs that do not support this
>>>mechanism, so the registrar must be able to handle it.
>>> (If there¹s a good reason, please explain it in the draft.)
>> 
>> The registrar will for sure be able to handle it, but if the proxy is
>>anyway going to trigger REGISTER requests using push notifications, I
>>see no reason for the UA to trigger REGISTER requests "on its own².
>
>What happens if a binding is about to expire, but the client hasn¹t
>gotten a push notification? What if the clients network configuration
>changes in a way that forces adding or removing contacts; should it wait
>for a push notification to send a new REGISTER request? Can it terminate
>a binding proactively, or does it need to wait for that, too?

If the SIP UA has a good reason to send a non-push triggered REGISTER, it
can do so. That¹s why it is a SHOULD :)

As you indicate, the only reason for not sending non-push triggered
REGISTER requests is to avoid unnecessary requests, but nothing will break
if they are sent.

---

>> 
>>> - ³ NOTE: If the SIP UA application wants to use push notifications for
>>> I can see keeping how you distinguish between SIP related
>>>notifications and other kinds of notifications. But what if the UA uses
>> Each UA application will have a separate push notification
>>subscription, use separate registrations etc.
>> 
>> (Now, if a single UA handles multiple SIP services I see no reason from
>>a non-push scenario: when the UA receives a request it needs to figure
>>out to which service the request is "dispatched².)
>
>I was thinking in terms of a single UA application. Let¹s say it has
>successfully registered with service FOO and service BAR. They both
>support push. If it gets a push notification, how does it know which
>binding to refresh? Should it refresh both?

Yes. If you have multiple contacts (no matter whether they are for
different services, different IP versions, or something else) associated
with a single push notification subscription, a push notification will
request them all to refresh.

---

>>> - ³ If the contact of the most recent REGISTER
>>>  previously registered contact in the Request-URI.²
>>> 
>>> Why doesn¹t the proxy forward using normal SIP procedures? It¹s
>>>entirely possible that an UAS address changes during an inbound
>>>transaction
>>> in normal SIP. Why is that different with push notifications? (this
>>>section seems to replace normal SIP request routing. That shouldn¹t
>>>happen
>> In order for the proxy to forward the SIP request, it needs to be able
>>to match the R-URI of the request with the contact in the REGISTER
>>request/response.
>> 
>> Now, the proxy could of course not wait for the REGISTER response, and
>>simply forward the request when it receives a REGISTER request with a
>>contact that matches the R-URI. But, if the registrar for whatever
>>reason no longer accepts the registered contact, the proxy have
>>forwarded the request before the REGISTER response informs it about the
>>not-accepted contact.
>> 
>> But, as you say, that could happen with any proxy, so we could say that
>>the proxy forwards the request as soon as it receives a REGISTER request
>>with a matching contact. That would also be better from the
>>non-invite-transaction-timeout perspective, as the proxy does not need
>>to wait for the REGISTER response before it forwards the request.
>
>I see there¹s been some discussion of this, but for the record, my
>question was not about waiting for the response, it was about requiring
>the R-URI to match the contact from that particular REGISTER.
>
>For normal SIP, there¹s always the chance a client may change it¹s
>contact between the time the home proxy retargets the request and it
>arrives (or fails to arrive) at the client. Is that problem worse with
>push? (Maybe it is, if we assume that push clients do not proactively
>send new REGISTER requests when their contacts change)

It is not a problem with push. The proxy will forward the request using
the old contact, but that could happen also in non-push scenarios.

In a previous version of the draft, the proxy actually did check that the
contacts match, but Robert commented that we can remove it: the proxy will
forward the SIP request using normal proxy procedures.

---

>> 
>>> §6.2: Why does the UAC need to know the failure was due to push
>>>notification? What would it do differently than for other kinds of
>> I am not sure whether the information is very useful for the UAC, but
>>the "home proxy" may perhaps trigger different actions depending on what
>>response it receives.
>> 
>Regardless, it tells the sender something about the client¹s device that
>it did not already know. I think we need better justification than just
>saying the home proxy might need it; are there expected scenarios where
>it _will_ need it?

Ok, I will look into this.

---

>>>§11: ³ If the push notification related information carried in SIP
>>>could be
>>>  secured from malicious middlemen, e.g., using encryption.²
>>> 
>>> This could use some elaboration. I think the sense of this is
>>>backwards. That is, the signaling MUST be secured unless
>It changes the burden of proof. The original text suggests that they only
>need to secure the signaling if they think they the information could be
>used maliciously. My suggestion is to say they need to secure the
>signaling unless they are sure it cannot be used maliciously. These are
>not the same thing.

What about:

³Operators MUST ensure that the SIP signalling is properly secured, e.g.,
using encryption, from malicious middlemen, unless they are sure that the
signalling cannot be accessed and used maliciously (e.g., to trigger push
notifications towards a deice) by a middleman.²

---

>> 
>>> §12.5: The template contains a ³document² field, but the registration
>>>policy is ³expert review². Should this be ³specification required²?
>> 
>³Expert Review² does not necessarily require a document. ³Specification
>required² does.

There has to be some documentation for implementers. That could be a
document or a webpage.

So, perhaps we should then change to ³Specification required² - assuming
that also covers webpages.

---

>> 
>> Editorial Comments:
>> 
>>> - General:
>>> ‹ The draft has some readability issues. In particular, it pervasively
>>>uses long, convoluted sentences, lots of imbedded parenthetical
>>> ‹ The draft pervasively mixes registration procedures with the
>>>handling of inbound SIP requests. Please consider separating those into
>>> different sections. I realize there are interdependencies, but it¹s
>>>hard to follow as is.
>> 
>> I will look into it, but when it comes to comma placements etc it would
>>be very useful with input from an English speaker on how to fix it.
>> 
>>> - Abstract: s/awake/wake ; (or awaken)  (³awake² is not a verb. This
>>>repeats elsewhere in the draft. .)
>> 
>Maybe they meant ³awaken²?

Perhaps.

So, ³awaken² is fine, but any instance of ³awake² should be ³wake²?

---

>> 
>>> §5.3.1: ³ If the proxy sends a SIP 555 (Push Notification Service Not
>>>Supported) response²
>Not necessarily; just a brief mention that it¹s defined in this document.
>Or just a forward reference.

Ok. IF we decide to keep the 555 response code (you have a separate issue
on whether we need the push-specific response codes) I will fix it.

Thanks!

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Wed, 22 Aug 2018 16:39:02 -0500

> On Aug 22, 2018, at 3:16 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> ...
> 

So the client doesn’t need to do anything with the value it gets in the capability indicator in SIP?

> REGISTER requests is to avoid unnecessary requests, but nothing will break

SHOULD is still pretty strong. If there are non-exceptional circumstances where we expect a normal client to send non-triggered REGISTERs, then SHOULD is not appropriate. To push on one of my examples: If the client learns that its network configuration has changed in a way that invalidates an existing binding, would it be good or bad behavior to wait for a push notification?

> request them all to refresh.

Unless I missed text that said that, it would be good to say that :-)

I can imagine a somewhat cleaner solution that sends something in a push body to identify which service (or binding) to refresh, but that could be a later extension.

> forward the SIP request using normal proxy procedures.

Hmm. Version 13 has been updated to talk about matching “one of the contacts” and to check for expiration, but I don’t see where the requirement to match the contact has been removed.

WFM

> that also covers webpages.

The main thing that “specification required” requires is some form of spec that is publicly available and reasonably expected to be available well into the future. If those are not requirements, then “expert review” could still be appropriate.

> So, ³awaken² is fine, but any instance of ³awake² should be ³wake²?

Pretty much. “wake” and “awaken” are verbs. “awake” is an adjective.

>> Not necessarily; just a brief mention that it¹s defined in this document

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 Aug 2018 10:06:24 +0000

Hi,

>>>> I am not sure how much information this document should contain. 
>>>> There is already a reference, and the Security Considerations 
>>>> contains the following paragraph:
>>>> 
>>> I was asking about the impact on the SIP behavior. Do we expect the 
>>> SIP client to do something with the capability indicator value? Maybe 
>>> record the value pass it to the ³push" client? Only send a new 
>>> register when the right VAPID related things happens in the push protocol?
>> 
>> VAPID is used to restrict the push notifications the SIP UA will 
>> receive in the first place. But, once it does receive a push 
>> notification, there is no special behaviour. It will send a REGISTER 
>> etc, using the normal procedures.
>> 
>

The client includes vapid information when it registers with the push notification service, but the subscribe details are outside the scope of the document.

---

>>>>> re-registration REGISTER request when it receives a push 
>>>>> notification (even if the UA is able to use a non-push mechanism 
>>>>> for sending re-registration REGISTER requests).²
>>>>> 
>>>> The registrar will for sure be able to handle it, but if the proxy 
>>>> is anyway going to trigger REGISTER requests using push 
>>>> notifications, I see no reason for the UA to trigger REGISTER requests "on its own².
>>> 
>>> changes in a way that forces adding or removing contacts; should it 
>>> wait for a push notification to send a new REGISTER request? Can it 
>>> terminate a binding proactively, or does it need to wait for that, too?
>> 
>> If the SIP UA has a good reason to send a non-push triggered REGISTER, 
>> it can do so. That¹s why it is a SHOULD :)
>> 
>> REGISTER requests is to avoid unnecessary requests, but nothing will 
>> break if they are sent.
>
> SHOULD is still pretty strong. If there are non-exceptional circumstances where we expect a normal client to send 
> non-triggered REGISTERs, then SHOULD is not appropriate. To push on one of my examples: If the client learns that 
> its network configuration has changed in a way that invalidates an existing binding, would it be good or bad behavior 
> to wait for a push notification?

If we add the "non-exceptional circumstances" to the SHOULD?

Something like:

"If the REGISTER response does not contain a a ¹sip.pnsreg¹
feature-capability indicator, the UA SHOULD only send a 
re-registration REGISTER request when it receives a push 
notification (even if the UA is able to use a non-push mechanism 
for sending re-registration REGISTER requests), or when there are
circumstances (e.g., if the UA is assigned new contact parameters
due to a network configuration change) that require an immediate 
REGISTER request to be sent."

---
  
>>>>> - "NOTE: If the SIP UA application wants to use push notifications 
>>>>> for other purposes than to trigger re-registration requests, it 
>>>>> needs to be able to distinguish between the different purposes when 
>>>>> receiving push notifications.  Mechanisms for doing that are 
>>>>> outside the scope of this specification."
>>>>> 
>>>>> notifications and other kinds of notifications. But what if the UA 
>>>>> uses more than one SIP services that supports push notifications?
>>>> 
>>>> (Now, if a single UA handles multiple SIP services I see no reason 
>>>> from a non-push scenario: when the UA receives a request it needs to 
>>>> figure out to which service the request is "dispatched².)
>>> 
>> different services, different IP versions, or something else) 
>> associated with a single push notification subscription, a push 
>> notification will request them all to refresh.
>

I will add text.

> I can imagine a somewhat cleaner solution that sends something in a push body to identify which service (or binding) to refresh, but that could be a later extension.

There have been discussions about sending such "metadata" associated with the SIP request as push notification payload, but we decided to leave that outside the document. It could be a candidate for future work, though.

---
 
>>>>> - "If the contact of the most recent REGISTER 2xx response and 
>>>>> Request-URI do not match, the proxy MUST reject the SIP request 
>>>>> with a 404 (Not Found) response.  This can happen if the UA sends a 
>>>>> re-registration REGISTER request with a new contact at the same 
>>>>> time the registrar forwards a SIP request towards a UA using the 
>>>>> transaction in normal SIP. Why is that different with push 
>>>>> notifications? (this section seems to replace normal SIP request 
>>>>> routing. That shouldn¹t happen without a really good reason. If 
>>>>> normal SIP procedures are inadequate, please explain why.
>>>> 
>>>> In order for the proxy to forward the SIP request, it needs to be 
>>>> able to match the R-URI of the request with the contact in the 
>>>> REGISTER request/response.
>>>> 
>>>> Now, the proxy could of course not wait for the REGISTER response, 
>>>> and simply forward the request when it receives a REGISTER request 
>>>> with a contact that matches the R-URI. But, if the registrar for 
>>>> whatever reason no longer accepts the registered contact, the proxy 
>>>> have forwarded the request before the REGISTER response informs it 
>>>> about the not-accepted contact.
>>>> 
>>>> But, as you say, that could happen with any proxy, so we could say 
>>>> that the proxy forwards the request as soon as it receives a 
>>>> REGISTER request with a matching contact. That would also be better 
>>>> from the non-invite-transaction-timeout perspective, as the proxy 
>>>> does not need to wait for the REGISTER response before it forwards the request.
>>> 
>>> question was not about waiting for the response, it was about 
>>> requiring the R-URI to match the contact from that particular REGISTER.
>>> 
>>> arrives (or fails to arrive) at the client. Is that problem worse 
>>> with push? (Maybe it is, if we assume that push clients do not 
>>> proactively send new REGISTER requests when their contacts change)
>> 
>> It is not a problem with push. The proxy will forward the request 
>> using the old contact, but that could happen also in non-push scenarios.
>> 
>> In a previous version of the draft, the proxy actually did check that 
>> the contacts match, but Robert commented that we can remove it: the 
>> proxy will forward the SIP request using normal proxy procedures.
>
> Hmm. Version 13 has been updated to talk about matching “one of the contacts” and to check for expiration, but I 
> don’t see where the requirement to match the contact has been removed.

Sorry, my reply was misleading. The R-URI still has to match one of the contacts of the REGISTER, but what has been removed is the requirement that the proxy has to wait for the REGISTER response before forwarding the SIP request, if the proxy is able to authenticate the sender of the REGISTER request.

...

>>>>> §12.5: The template contains a "document" field, but the 
>>>>> registration policy is "expert review". Should this be "specification required"?
>>>> 
>>> "Expert Review" does not necessarily require a document. 
>>> "Specification required" does.
>> 
>> So, perhaps we should then change to "Specification required" - 
>> assuming that also covers webpages.
>
> The main thing that “specification required” requires is some form of spec that is publicly available and reasonably expected to 
> be available well into the future. If those are not requirements, then “expert review” could still be appropriate.

I think having a reference is good.

For example, the document defines some pn-provider values, and I think it would be good if the registry indicates that they are defined in the document.

...

>>>>> §5.3.1: "If the proxy sends a SIP 555 (Push Notification Service 
>>>>> Not Supported) response"

I talked with the product people about the push-specific response codes. Currently they are used only for trouble shooting, and don't trigger any response code-specific behaviour.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Thu, 23 Aug 2018 15:15:17 -0500

> On Aug 23, 2018, at 5:06 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

The document should say that :-)

> REGISTER request to be sent.”

That WFM.

> There have been discussions about sending such "metadata" associated with the SIP request as push notification payload, but we decided to leave that outside the document. It could be a candidate fo…

Okay.

> Sorry, my reply was misleading. The R-URI still has to match one of the contacts of the REGISTER, but what has been removed is the requirement that the proxy has to wait for the REGISTER response b…

The REGISTER or the REGISTER _response_? (See my response about multiple clients in the “major issue” thread--I think these are related)

> For example, the document defines some pn-provider values, and I think it would be good if the registry indicates that they are defined in the document.

WFM.

> I talked with the product people about the push-specific response codes. Currently they are used only for trouble shooting, and don't trigger any response code-specific behaviour.

Is that a response to the quoted text about 555, or the discussion about 556?

If the latter: I guess that comes down to a question about whether trouble-shooting is a sufficient reason for the new response code, and whether the potential to tell the caller things about the callee’s device constitutes a privacy issue. Please don’t take my opinion there as an AD mandate--I’m curious if anyone else following this thread has thoughts?

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Aug 2018 11:36:46 +0000

Hi,

>>>>>> key pair.  The public key serves as an identifier of the proxy, 
>>>>>> and can be used by devices to restrict push notifications to the 
>>>>>> proxy associated with the key."
>>>>>> 
>>>>> SIP client to do something with the capability indicator value? 
>>>>> Maybe record the value pass it to the "push" client? Only send a 
>>>>> new register when the right VAPID related things happens in the push protocol?
>>>>> 
>> The client includes vapid information when it registers with the push 
>> notification service, but the subscribe details are outside the scope of the document.
>

Ok, I will try to add a few words somewhere.

...

>>> The main thing that “specification required” requires is some form of 
>>> spec that is publicly available and reasonably expected to be available well into the future. >>> If those are not requirements, then “expert review” could still be appropriate.
>> 
>> For example, the document defines some pn-provider values, and I think it would be good >> if the registry indicates that they are defined in the document.
>
> WFM.

So, what do I do?

...

>> I talked with the product people about the push-specific response codes. 
>> Currently they are used only for trouble shooting, and don't trigger any 
>> response code-specific behaviour.
>
> If the latter: I guess that comes down to a question about whether trouble-shooting 
> is a sufficient reason for the new response code, and whether the potential to tell the 
> caller things about the callee’s device constitutes a privacy issue. Please don’t take my 
> opinion there as an AD mandate--I’m curious if anyone else following this thread has 
> thoughts?

The response was regarding both 555 and 556.

However, while 556 could be replaced with something else (e.g., 480) I was told that 555 is useful to have. But, again, currently it is only used for trouble-shooting.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Fri, 24 Aug 2018 14:21:00 -0500

> On Aug 24, 2018, at 6:36 AM, Christer Holmberg <[email-masked]> wrote:
> 

[...]

>>> For example, the document defines some pn-provider values, and I think it would be good >> if the registry indicates that they are defined in the document.

Sorry, I thought you were arguing for “specification required”.  But to be clear, I’m okay either way as long as the policy fits the intent. If a reference to a stable document is _required_, then “specification required” seems to fit better than “expert review”. If the doc is optional, the “expert review” makes sense. But it’s up to you whether the document is required.

> However, while 556 could be replaced with something else (e.g., 480) I was told that 555 is useful to have. But, again, currently it is only used for trouble-shooting.

I have no objection to 555 (modulo a different comment below.) My concern was about 556 (assuming I have these straight--556 was the response to a third party UAC sending a request towards to push client, right?)

On reflection, and after talking to a few people, I’m okay with 556 as an optional response, along with a sentence or two pointing out that it can have privacy implications. (I was reminded by those people that this is a tiny leak on top of all the legacy privacy leaks that SIP has.)

However, it also came up in discussion that perhaps at least 556 should be a 400 class error. Thoughts?

Thanks!

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Aug 2018 21:02:20 +0000

Hi,

>>>>>> There has to be some documentation for implementers. That could be 
>>>>>> a document or a webpage.
>>>>>> 
>>>>> The main thing that “specification required” requires is some form 
>>>>> of spec that is publicly available and reasonably expected to be available well into the future. 
>>>>> If those are not requirements, then “expert review” could still be appropriate.
>>>> 
> Sorry, I thought you were arguing for “specification required”.  But to be clear, I’m okay either way as long as the policy fits the intent. 
> If a reference to a stable document is _required_, then “specification required” seems to fit better than “expert review”. If the doc is optional, 
> the “expert review” makes sense. But it’s up to you whether the document is required.

Just to clarify: if the document is optional, what is the expert reviewer going to read?

>>>>>>>>> §5.3.1: "If the proxy sends a SIP 555 (Push Notification 
>>>>>>>>> Service Not Supported) response"
>>>> Currently they are used only for trouble shooting, and don't trigger 
>>>> any response code-specific behaviour.
>>> 
>>> If the latter: I guess that comes down to a question about whether 
>>> trouble-shooting is a sufficient reason for the new response code, 
>>> and whether the potential to tell the caller things about the 
>>> callee’s device constitutes a privacy issue. Please don’t take my 
>>> opinion there as an AD mandate--I’m curious if anyone else following this thread has thoughts?
>> 
>> However, while 556 could be replaced with something else (e.g., 480) I was told that 555 is useful to have. 
>> But, again, currently it is only used for trouble-shooting.
>
> I have no objection to 555 (modulo a different comment below.) 

Ok, so I will keep it.

> My concern was about 556 (assuming I have these  straight--556 was the response to a third party UAC sending a request towards to push client, right?)

Correct.

> On reflection, and after talking to a few people, I’m okay with 556 as an optional response, along with a sentence or two pointing out that it can have 
> privacy implications. (I was reminded by those people that this is a tiny leak on top of all the legacy privacy leaks that SIP has.)
>

The reason we chose a 5xx code was because it is sent due to a push notification error - not a SIP level error.

But, I don't have any strong feelings. I guess 480 would fit too.

Regards,

Christer