Subject: [sipcore] RFC 8599 (SIP PN): Feedback & Nitpicking

From: Liviu Chircu <[email-masked]>
Date: Thu, 7 May 2020 14:49:12 +0300

Hi!

Following an apparently functional implementation of RFC 8599 within 
some open-source SIP proxy, I would first like to thank everyone who 
worked on the document for all of their careful considerations and 
restless reviewing.  The instructions were clear at all times and any 
lingering questions would eventually get answered on a 2nd, 3rd or 4th 
walk-through of the text. Cheers!

Here are all the issues which I could still spot in the published 
version of the text:

1. [Question/Nitpick] given that "+sip.pnspurr" is a unique Feature-Caps 
indicator and that there can only be a maximum of 1 Feature-Caps header 
fields per unique PNS (e.g. "fcm") in a SIP REGISTER, it then logically 
follows that a PN SIP REGISTER can only hold max 1 x Contact header 
field values pointing to a given PNS (using the ";pn-provider=fcm" URI 
parameter).

So the question is: should the text mention this extra SIP-level, 
logical restriction?  Because, coming into this RFC, there were no 
restrictions on the number of contacts that a single SIP REGISTER 
request may advertise.

2. [Typo] throughout § 4.1.4, there are three (!!!) incorrect mentions 
of the "sip.pnsreq" feature-capability indicator (notice it ends with a 
"q", not a "g"!).  It was confusing at first, until I realized it's a 
typo.  Fixing it would definitely be a time saver for everyone 
implementing the RFC.

3. [Typo] § 6.2.1: "even if 'pn-*'parameters"

     notice a missing space " " before "parameters"

4. [Typo] § 4.1.5:

         "... if the UA inserted a 'pn-provider' SIP URI parameter 
[value!!] ..."

         "If the UA did not insert a 'pn-provider' parameter [value!!] ..."

Both of these statements are correct with "parameter value", not 
"parameter".  If we take a look at the paragraph above, it actually 
talks about inserting a "parameter value".  Given that "pn-provider" is 
syntactically correct with or without a value, it is quite important to 
be non-ambiguous here.

5. [Typo] § 5.4: "A proxy MUST use a separate Feature-Cap[s!!] header field"

     missing "s"

6. [Typo] § 7: "make sure that the initial request for dialog[s??]"

extra "s"

7. [Typo] § 13: "Unless the PNS authenticates and authorizes the [PNS??]"

Most likely, the authors meant "proxy"

Thank you,
Liviu

---

From: Brian Rosen <[email-masked]>
Date: Thu, 7 May 2020 10:11:20 -0400

We should get the meaningful errors (2,4, 7) captured in an errata if authors agree with Liviu.

> On May 7, 2020, at 7:49 AM, Liviu Chircu <[email-masked]> wrote:
> 
> Hi!
> 
> Following an apparently functional implementation of RFC 8599 within some open-source SIP proxy, I would first like to thank everyone who worked on the document for all of their careful considerations and restless reviewing.  The instructions were clear at all times and any lingering questions would eventually get answered on a 2nd, 3rd or 4th walk-through of the text. Cheers!
> 
> Here are all the issues which I could still spot in the published version of the text:
> 
> 1. [Question/Nitpick] given that "+sip.pnspurr" is a unique Feature-Caps indicator and that there can only be a maximum of 1 Feature-Caps header fields per unique PNS (e.g. "fcm") in a SIP REGISTER, it then logically follows that a PN SIP REGISTER can only hold max 1 x Contact header field values pointing to a given PNS (using the ";pn-provider=fcm" URI parameter).
> 
> So the question is: should the text mention this extra SIP-level, logical restriction?  Because, coming into this RFC, there were no restrictions on the number of contacts that a single SIP REGISTER request may advertise.
> 
> 2. [Typo] throughout § 4.1.4, there are three (!!!) incorrect mentions of the "sip.pnsreq" feature-capability indicator (notice it ends with a "q", not a "g"!).  It was confusing at first, until I realized it's a typo.  Fixing it would definitely be a time saver for everyone implementing the RFC.
> 
>         "... if the UA inserted a 'pn-provider' SIP URI parameter [value!!] ..."
> 
> Both of these statements are correct with "parameter value", not "parameter".  If we take a look at the paragraph above, it actually talks about inserting a "parameter value".  Given that "pn-provider" is syntactically correct with or without a value, it is quite important to be non-ambiguous here.
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 May 2020 14:14:33 +0000

Hi Liviu,

Thank You for the comments! Please see inline.
    
>    restrictions on the number of contacts that a single SIP REGISTER 
  
I am not sure I understand the use-case.  

---

>    typo.  Fixing it would definitely be a time saver for everyone 
  
Correct. 

We always try to avoid these kind of typos to happen, but unfortunately they do occur from time to time.

---

>         notice a missing space " " before "parameters"
 
Correct. 

---
   
>    syntactically correct with or without a value, it is quite important to 

Correct. "parameter value" would have been correct.

---
  
>    5. [Typo] § 5.4: "A proxy MUST use a separate Feature-Cap[s!!] header field"
  
Correct.

---
  
>    6. [Typo] § 7: "make sure that the initial request for dialog[s??]"

I guess it should be "for a dialog".

---
    
>    Most likely, the authors meant "proxy"

Yes.

---

Thank You for the comments! Unfortunately we are not able to fix them in the actual document (we would have to start working on a new version of the specification). 

But, it IS possible to create an errata, where the error and suggested fix are described.

Not sure if we would open an errata just for fixing 3, 5 and 6. But, but 2, 4 and 7 would probably be worth fixing. I still need to understand 1 better :)

Regards,

Christer

---

From: Liviu Chircu <[email-masked]>
Date: Thu, 7 May 2020 17:40:56 +0300

> I am not sure I understand the use-case.

The only use-case that I see here would be a device which registers both 
an UDP and a TLS Contact by including them into the same REGISTER.  If 
each of these contacts is parameterized using "pn-provider=fcm", for 
example, the PN proxy has no way of returning 2 x "+sip.pnspurr" 
Feature-Caps values for each newly created binding, since RFC 8599 seems 
to restrict it in a way that a maximum of 1 PURR per PNS can be returned 
at a time inside a Feature-Caps.  Please correct me if I'm wrong here!

I have no idea how realistic the above is, nor do I care, frankly (I am 
quite OK with the restriction).  My opinion is coming from the 
implementation standpoint, where I aim to capture all the edge-cases and 
implement the spec with maximal acceptance for the input SIP format.

Thank you,
Liviu