Re: [sipcore] AD Evaluation of draft-ietf-sipcore-sip-push-20 - Ben's technical comments

[Christer Holmberg <[e-mail]>]

Hi,

I saw that Paul replied on the “Expires” issue, so I will reply to his e-mail on that issue.

---

>>>-6th paragraph: "REGISTER request will create NAT bindings..."
>>>
>>>  If we talk about creating NAT bindings as one of the purposes of the push-triggered REGISTER, we may also need to 
>>>  think about the lifetime of those nat bindings, and how that interacts with the REGISTER expires value. I'm not sure we 
>>> want to go there; would it make sense to remove the mention?
>>
>> I am not sure that is needed in the context of PUSH, since the NAT bindings only need to be alive in time for the request that triggered the push notification to reach the UA. Next time there is an inbound SIP request, the REGISTER triggered by the push notification associated with the request will create a NAT binding (if the previous one has expired) for that request.
>
> A one line comment to that effect would be helpful.

I suggest adding the following:

“NOTE: The lifetime of any NAT binding created by the REGISTER request only needs to be long enough in order for the SIP request that triggered the push notification to reach the UA.” 

---

>>> - 7th paragraph:
>>> --  The first sentence seems to still assume the REGISTER has as single contact. Should it say to insert the tag into each 
>>> contact header field? (but see general §4.1 comment above.)
>>
>> What sentence are you referring to?
>
> Sorry, it’s the 8th paragraph: "If the UA is able to send binding refresh REGISTER requests using a
> non-push mechanism (e.g., using an internal timer that periodically wakes the UA), the UA MUST 
> insert a ’sip.pnsreg’ media feature tag [RFC3840] in the Contact header field URI of each REGISTER request"

I will fix as suggested (“insert a tag in each Contact header field”).

---

>>> Along those lines, what is the PUSH proxy expected to do with inbound SIP requests that do not contain the parameters 
>>> in the R-URI? Route them normally? Reject them?
>>
>> I think that is an implementation issue. If the proxy also handles non-PNS calls, it would forward the request using normal procedures.
>
> A brief mention of that would be helpful.

I suggest the following:

"NOTE: If the SIP request does not contain the pn- parameters, the proxy processing of the request is based on local policy, e.g., depending on whether the proxy servers requests towards UAs that do not use the SIP push mechanism, in which case the proxy will forward the request using normal SIP procedures. Otherwise the proxy might reject the request."
 
---

>>> §6: Is support for push-notifications on mid-dialog requests optional? If so, please state that up front.
>>
>> If one wants to support longlived SIP dialogs, one obviously will have to implement section 6. I am not sure we need to say something.
>
> I’m more concerned about whether an implementation can choose _not_ to support long-lived dialogs. I assume 
> so since there’s a separate negotiation. All I’m looking for is the word “optional” somewhere early in the section :-)

An implementation can choose not to support a feature no matter what the spec says :)

What about adding the following to the end of the first paragraph:

"The procedures in this section are optional to support, but MUST be supported by proxies that will deployed in SIP networks where the type SIP dialogs described above might occur."

---

>>>  §6.1.1: Does the UA indicate support on a per-dialog basis? That is, it can support the mechanism for some dialogs but not others?
>>
>> It could be per-dialog basis. The text says: "if the UA is willing to receive push notifications triggered by incoming mid-dialog requests”.
>
> I assume that if the UA indicates support in one dialog-initiating transaction but not another, that the proxy should not assume 
> that it supports mid-dialog push in both transactions. If that’s a correct assumption, it would be helpful to explicitly state it.

I suggest the following:

"NOTE: As the 'pn-purr' SIP URI parameter only applies to a give dialog, the UA needs to include a 'pn-purr' parameter in the 
  Contact header of the request or response for each dialog in which the UA is willing to receive push notifications triggered by incoming 
  mid-dialog requests."

(Related to that, I noted that the purr parameters are missing from the grammar, IANA section etc. I will fix that.)

---

>>>  §9, 1st paragraph: We are talking about a specification that defines the parameter usage for the given PNS, not the PNS in it's entirety, right?
>>
>> Yes. I suggest to say: "defines the usage of the associated PNS". Because, the parameter itself only identifies the PNS.
>
> You said “Yes”, which I take to agree that we don’t require a spec for the PNS itself, but then you said “defines the usage of the 
> associated PNS”, which does sound like a requirement for a spec of the PNS itself. So I’m confused :-)

You do need a spec that defines how to use the PNS, but you don't need to details on how the PNS is implemented etc.

Regards,

Christer