Re: [calsify] [External] : [Technical Errata Reported] RFC5545 (7332)

Tobias Subklewe <tobias@lyckligtax.com> Sat, 04 February 2023 18:38 UTC

Return-Path: <tobias@lyckligtax.com>
X-Original-To: calsify@ietfa.amsl.com
Delivered-To: calsify@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAF1C151555 for <calsify@ietfa.amsl.com>; Sat, 4 Feb 2023 10:38:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.892
X-Spam-Level:
X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u07GwgpRlfog for <calsify@ietfa.amsl.com>; Sat, 4 Feb 2023 10:38:21 -0800 (PST)
Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [IPv6:2001:67c:2050:0:465::101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20E53C14F74F for <calsify@ietf.org>; Sat, 4 Feb 2023 10:38:02 -0800 (PST)
Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4P8Lqn1KYNz9sZk; Sat, 4 Feb 2023 19:37:57 +0100 (CET)
Content-Type: multipart/alternative; boundary="------------FJDt0gZB0msp39nlm1w0zwjU"
Message-ID: <87a7bf5b-73cc-7220-8785-cc61c8d59cb4@lyckligtax.com>
Date: Sat, 04 Feb 2023 19:37:55 +0100
MIME-Version: 1.0
Content-Language: en-US
To: Bernard Desruisseaux <bernard.desruisseaux@oracle.com>, RFC Errata System <rfc-editor@rfc-editor.org>
Cc: "superuser@gmail.com" <superuser@gmail.com>, "francesca.palombini@ericsson.com" <francesca.palombini@ericsson.com>, Eliot Lear <lear@cisco.com>, "calsify@ietf.org" <calsify@ietf.org>
References: <20230204085817.C10D0AE86@rfcpa.amsl.com> <69669729-4E2C-4832-8456-5EDF3ECC636B@oracle.com>
From: Tobias Subklewe <tobias@lyckligtax.com>
In-Reply-To: <69669729-4E2C-4832-8456-5EDF3ECC636B@oracle.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/H7QnNXsD4z47AVYEWNLJVZ4V1Xw>
X-Mailman-Approved-At: Sun, 05 Feb 2023 18:14:54 -0800
Subject: Re: [calsify] [External] : [Technical Errata Reported] RFC5545 (7332)
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Calendaring and Scheduling Standards Simplification <calsify.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/calsify>, <mailto:calsify-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/calsify/>
List-Post: <mailto:calsify@ietf.org>
List-Help: <mailto:calsify-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/calsify>, <mailto:calsify-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Feb 2023 18:39:25 -0000

Yeah,

this will work. Though I think it would be nice to have two differing 
datetime examples. I'm fine either way.

The grammar issue is a nice catch. Did not see that.

On 04.02.23 14:29, Bernard Desruisseaux wrote:
> Thanks Tobias!
>
> The issue was also present in RFC2445.
>
>   * https://www.rfc-editor.org/rfc/rfc2445#section-4.3.9
>
>
> I would add UTC in the text rather than removing the 'Z' in the 
> example, and fix the grammar as well!
>
> Correct Text:
>
>       The period _starting_ at 18:00:00 _UTC_, on January 1, 1997 and 
> lasting 5
>       hours and 30 minutes would be:
>
>        19970101T180000Z/PT5H30M
>
> Thanks,
> Bernard
>
>
>> On Feb 4, 2023, at 3:58 AM, RFC Errata System 
>> <rfc-editor@rfc-editor.org> wrote:
>>
>> The following errata report has been submitted for RFC5545,
>> "Internet Calendaring and Scheduling Core Object Specification 
>> (iCalendar)".
>>
>> --------------------------------------
>> You may review the report below and at:
>> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7332__;!!ACWV5N9M2RV99hQ!L6gFuabr9gpjhMKQIgFVEpkCMd_6GmT6dQmUysMz_X0IVDYneZSkBxF3n65B4iGFzRN22CWpYpeC40Zki3siplsZ4-X-UuIc$ 
>>
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Tobias Subklewe <tobias@lyckligtax.com>
>>
>> Section: 3.3.9
>>
>> Original Text
>> -------------
>> The period start at 18:00:00 on January 1, 1997 and lasting 5
>> hours and 30 minutes would be:
>>
>> 19970101T180000Z/PT5H30M
>>
>> Corrected Text
>> --------------
>> The period start at 18:00:00 on January 1, 1997 and lasting 5
>> hours and 30 minutes would be:
>>
>> 19970101T180000/PT5H30M
>>
>> Notes
>> -----
>> I do not know if this is an editorial or technical issue.
>>
>> If I understand the datetime value (Section 3.3.5) correct the last 
>> character should only be "Z" if the value is in UTC.
>>
>> In the first example in section 3.3.9 UTC is explicitely mentioned 
>> but not in the second example.
>>
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> can log in to change the status and edit the report, if necessary.
>>
>> --------------------------------------
>> RFC5545 (draft-ietf-calsify-rfc2445bis-10)
>> --------------------------------------
>> Title               : Internet Calendaring and Scheduling Core Object 
>> Specification (iCalendar)
>> Publication Date    : September 2009
>> Author(s)           : B. Desruisseaux, Ed.
>> Category            : PROPOSED STANDARD
>> Source              : Calendaring and Scheduling Standards Simplification
>> Area                : Applications
>> Stream              : IETF
>> Verifying Party     : IESG
>