[stir] Second proposal for update of erratum #6519

Marc Petit-Huguenin <marc@petit-huguenin.org> Tue, 20 April 2021 21:38 UTC

Return-Path: <marc@petit-huguenin.org>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372893A1D4C for <stir@ietfa.amsl.com>; Tue, 20 Apr 2021 14:38:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XN3X_WiB9Iyc for <stir@ietfa.amsl.com>; Tue, 20 Apr 2021 14:38:19 -0700 (PDT)
Received: from implementers.org (implementers.org [92.243.22.217]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91AF13A1D4A for <stir@ietf.org>; Tue, 20 Apr 2021 14:38:19 -0700 (PDT)
Received: from [IPv6:2601:648:8400:8e7d:d250:99ff:fedf:93cd] (unknown [IPv6:2601:648:8400:8e7d:d250:99ff:fedf:93cd]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) client-signature RSA-PSS (2048 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id E36DBAE255 for <stir@ietf.org>; Tue, 20 Apr 2021 23:38:17 +0200 (CEST)
From: Marc Petit-Huguenin <marc@petit-huguenin.org>
To: "stir@ietf.org Mail List" <stir@ietf.org>
Message-ID: <86592ac3-85d1-bdfa-687e-828dc239322b@petit-huguenin.org>
Date: Tue, 20 Apr 2021 14:38:16 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/JZjfgUB5SF7hODO_vjIqhVpXYlo>
Subject: [stir] Second proposal for update of erratum #6519
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Apr 2021 21:38:24 -0000

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: marc@petit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug