Subject: [stir] Second proposal for update of erratum #6519

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 20 Apr 2021 14:38:16 -0700

This is a refreshed proposal for the update of erratum #6519, which I tried to collect all the parts where we have somehow consensus.  As before, "Original Text" and "Corrected Text" refer to the names of the erratum fields, not to the current content:

- Original Text:

Section 4 says:

  ident-type = "ppt" EQUAL token

- Corrected Text:

It should say:

  ident-type =  "ppt" EQUAL ( token / ( DQUOTE token DQUOTE ) )

Furthermore in the second paragraph of section 4, the following sentence should be inserted after 'defines the optional "ppt" parameter (PASSporT Type).':

  Implementations SHOULD use quotes around the token when sending and MUST accept the token with or without the quotes around it when receiving.

Similarly in the fourth bullet of the first list in section 4.1, the sentence '...a value equivalent to the quoted value of the "ppt" parameter...' is replaced by:

  ...a quoted value whose unquoted part is equivalent to the token in the "ppt" parameter, normalized to contain only lowercase characters...

Finally in the first paragraph of section 9, the sentence '...The "ppt" parameter value MUST consist of a token...' is replaced by:

  ...The "ppt" parameter value MUST consist of a token (between quotes)...

- Notes:

Based on discussions in the STIR WG, implementations should use the quoted form when sending, but should accept both forms when receiving.  Regardless of the presence of the quotes, the content is treated as a token, i.e. is case-insensitive as explained in RFC 3261 section 7.3.1.  Note also that the new syntax does not allow for spaces immediately before or immediately after the token when quoted.

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

---

From: Roman Shpount <[email-masked]>
Date: Tue, 20 Apr 2021 18:33:44 -0400

I think this covers all of my comments and addresses my initial errata.

Thank you,
_____________
Roman Shpount

On Tue, Apr 20, 2021 at 5:38 PM Marc Petit-Huguenin <[email-masked]>
wrote:

> This is a refreshed proposal for the update of erratum #6519, which I
> tried to collect all the parts where we have somehow consensus.  As before,
> "Original Text" and "Corrected Text" refer to the names of the erratum
> fields, not to the current content:
>
> - Original Text:
>
> Section 4 says:
>
> Furthermore in the second paragraph of section 4, the following sentence
> should be inserted after 'defines the optional "ppt" parameter (PASSporT
> Type).':
>
>   Implementations SHOULD use quotes around the token when sending and MUST
> accept the token with or without the quotes around it when receiving.
>
> Similarly in the fourth bullet of the first list in section 4.1, the
> sentence '...a value equivalent to the quoted value of the "ppt"
> parameter...' is replaced by:
>
>   ...a quoted value whose unquoted part is equivalent to the token in the
> "ppt" parameter, normalized to contain only lowercase characters...
>
> Finally in the first paragraph of section 9, the sentence '...The "ppt"
> parameter value MUST consist of a token...' is replaced by:
>
> Based on discussions in the STIR WG, implementations should use the quoted
> form when sending, but should accept both forms when receiving.  Regardless
> of the presence of the quotes, the content is treated as a token, i.e. is
> case-insensitive as explained in RFC 3261 section 7.3.1.  Note also that
> the new syntax does not allow for spaces immediately before or immediately
> after the token when quoted.
>
>
> --
> Marc Petit-Huguenin
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 23 Apr 2021 09:24:43 -0700

Any other comment from the WG on my second proposal?

---

From: Russ Housley <[email-masked]>
Date: Fri, 23 Apr 2021 13:04:03 -0400

Should the ABNF allow whitespace after the second DQUOTE?  At one point in this discussion, we had a proposal that did.

Russ

> On Apr 23, 2021, at 12:24 PM, Marc Petit-Huguenin <[email-masked]> wrote:
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 23 Apr 2021 10:12:46 -0700

> Should the ABNF allow whitespace after the second DQUOTE?  At one point in this discussion, we had a proposal that did.

I think that it is not necessary:

1. If there is an additional parameter after this one, then the SEMI rule already permits SWS before the ";".
2. As far as I can tell (that would require checking all SIP extensions) whitespaces are never allowed before the final CRLF.

---

From: Russ Housley <[email-masked]>
Date: Fri, 23 Apr 2021 13:31:45 -0400

Thanks.  I forgot about the SEMI in the rule set.

Russ

> On Apr 23, 2021, at 1:12 PM, Marc Petit-Huguenin <[email-masked]> wrote:
>