[calsify] [Errata Rejected] RFC5545 (5082)
RFC Errata System <rfc-editor@rfc-editor.org> Tue, 16 January 2024 14:53 UTC
Return-Path: <wwwrun@rfcpa.amsl.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 06133C157927; Tue, 16 Jan 2024 06:53:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.659
X-Spam-Level:
X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no 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 zxsOMaJROlX8; Tue, 16 Jan 2024 06:53:49 -0800 (PST)
Received: from rfcpa.amsl.com (rfcpa.amsl.com [50.223.129.200]) (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 97FDFC057BA3; Tue, 16 Jan 2024 06:22:17 -0800 (PST)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 81B341BA3D9F; Tue, 16 Jan 2024 06:22:17 -0800 (PST)
To: georges@mhsoftware.com, bernard.desruisseaux@oracle.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: francesca.palombini@ericsson.com, iesg@ietf.org, calsify@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20240116142217.81B341BA3D9F@rfcpa.amsl.com>
Date: Tue, 16 Jan 2024 06:22:17 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/bxtO_XDU1whHG1bpD7QgN4gAA-k>
Subject: [calsify] [Errata Rejected] RFC5545 (5082)
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: Tue, 16 Jan 2024 14:53:53 -0000
The following errata report has been rejected for RFC5545, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5082 -------------------------------------- Status: Rejected Type: Technical Reported by: George Sexton <georges@mhsoftware.com> Date Reported: 2017-08-10 Rejected by: Francesca Palombini (IESG) Section: 3.8.7.3 Original Text ------------- N/A Corrected Text -------------- The value must not be in the future. Notes ----- If future values are allowed for LAST-MODIFIED, it makes it very difficult for software to perform change management for a VEVENT. Say for example, an event is imported from a source and the VEVENT has a future date. For example, December 20 2017 12:00:00Z That event is then edited and assigned the actual correct date and time. Say August 9 2017 13:45:44Z. Software that examines the VEVENT's LAST-MODIFIED to determine if the VEVENT record has been modified will not see the VEVENT is updated. In order for different systems to perform change management, the value for LAST-MODIFIED should NEVER be a future date. --VERIFIER NOTES-- The description of the property already implies that it is not in the future. And any handling of clock skew is an iTIP/CalDAV protocol issue, NOT a data format issue. See https://mailarchive.ietf.org/arch/msg/calsify/x82GopunVcEh8y5UGSIsEIC3s6M/ -------------------------------------- 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
- [calsify] [Errata Rejected] RFC5545 (5082) RFC Errata System