[Sedate] Recharter

Bron Gondwana <brong@fastmailteam.com> Fri, 10 March 2023 01:29 UTC

Return-Path: <brong@fastmailteam.com>
X-Original-To: sedate@ietfa.amsl.com
Delivered-To: sedate@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EBAC1522C2 for <sedate@ietfa.amsl.com>; Thu, 9 Mar 2023 17:29:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b="rSN+b0O6"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="TMeBhwcL"
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 UW8vHMR3aC-E for <sedate@ietfa.amsl.com>; Thu, 9 Mar 2023 17:29:43 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 54934C15270E for <sedate@ietf.org>; Thu, 9 Mar 2023 17:29:43 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 30B735C01A0 for <sedate@ietf.org>; Thu, 9 Mar 2023 20:29:42 -0500 (EST)
Received: from imap43 ([10.202.2.93]) by compute3.internal (MEProxy); Thu, 09 Mar 2023 20:29:42 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-type:content-type:date:date:from :from:in-reply-to:message-id:mime-version:reply-to:sender :subject:subject:to:to; s=fm2; t=1678411782; x=1678498182; bh=lo H3JJ9m6jyzXIEjznCW2I47yTG9mJro6OZmv7ZRxwQ=; b=rSN+b0O63vF5MGZv0q R6v3SZr+Oq4ptV9qMJSk4SrfvUkvfGZqSFTi5RYOI8YijQrxr6Wh+IFDAx/ScMnh dN70s9Mw0zHKHFD4rFSB+8JgLeG7VhQDcgo0TkvYEYPJTqU/oVOvwok9Nzaxz60x ADr7gBeVegIJWGhwugUq0WVPyIKOjB1anx0+Pz3waxnCd9rCgAZUZMdo+ADiTdxm trQ9zxjuXhLyOzsPvQHw9rFl7Ul8uQrI3pkPALvIMQjUahqeHuoOR7H+yo6pc9om G88dl68byWrEzkARE3JP0nsk4KBYEf1HFbZsl6aKPtvwg1bDlfnRhxsfxNCY5Xbz NGIw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1678411782; x=1678498182; bh=loH3JJ9m6jyzXIEjznCW2I47yTG9mJro6OZ mv7ZRxwQ=; b=TMeBhwcL4EZb71HOzB/RCCdiDvhbjWeJAlPDBCcqhCMIuw24+cL Oc3A32uJmYC14gVijxoE+9KCt6zERREgBZCwMveYoDWZxXZyHHyzX2bITuRc7T5Q dfKOq6fleVQKm+o1ybYK+bsDFMe3lqE+5VzC65+6JO2DacZPB9RCkyOA8UTpYK5E +imZbl+FVqFVtkgrUdqk1rUSGOc3ynWistFYmwJxxFW8HIMLjT5Zc9nwOUhaKsIT vF6vNEssjtt4lPcXedH9XWol8mXSkfWMveY1ylxxUqBZj+fU2KIqQSwfeHcXbwKd h+7d/YBrTt8tylB0Ckvk0dZqQVXcI8uEusg==
X-ME-Sender: <xms:BYgKZOxWNlVjq6988Gptqb0n1d-BlKQ3dah3EIaqA3t6vIPm-IkBpw> <xme:BYgKZKQmwSs7wfbMOoUA2PS81pofe0ippPFYf2Q533IsfBmQoz22L6eE1-cFb2pgh OdrYHfiZDw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvddujedgfeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeejlefhffeutdeije ehtdfgffeiffefueevffefieetleeklefgueehvdduledugfenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilh htvggrmhdrtghomh
X-ME-Proxy: <xmx:BogKZAUkhfgdWoGrVftVqAq9akcU_mX4zALEGlRbWmfKJqGF3KMI4g> <xmx:BogKZEhAjD7RBQqh3B1tl-240J0STEPdctRMOdntofMbv0eN92Q_9Q> <xmx:BogKZADTG5Kng4SobuqC7dkuiVGFLDeuPWSUo08IS5iowP_2cOrcwQ> <xmx:BogKZDMzamygi1gKsOQjXxAcfsyvCMVd1AMqOD4LX4GkTtALt3TfQw>
Feedback-ID: i2d7042ce:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id ED3A12D40074; Thu, 9 Mar 2023 20:29:41 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.9.0-alpha0-221-gec32977366-fm-20230306.001-gec329773
Mime-Version: 1.0
Message-Id: <8c3d08e6-f388-43de-9e38-f306f0abe80e@app.fastmail.com>
Date: Thu, 09 Mar 2023 20:29:22 -0500
From: Bron Gondwana <brong@fastmailteam.com>
To: sedate@ietf.org
Content-Type: multipart/alternative; boundary="451043ea7cce4ee88cdaff66c6e4184d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sedate/6Xn7QNpZRkqm1wbU29E6TBO6ZgI>
Subject: [Sedate] Recharter
X-BeenThere: sedate@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Serialising Extended Data About Times and Events <sedate.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sedate>, <mailto:sedate-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sedate/>
List-Post: <mailto:sedate@ietf.org>
List-Help: <mailto:sedate-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sedate>, <mailto:sedate-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Mar 2023 01:29:48 -0000

Hi all,

We've been discussing a changed charter for a bit, with the "update to RFC3339" as called out in our existing charter having been detected as needed.  My apology for the delay in the work on this, the chairs have been workshopping it with Francesca, our AD.

Here's the proposed new charter text.  Please let us know pretty quickly if you have any suggestions for changes to this - Francesca will be proposing it shortly.

Thanks,

Bron and Mark, your SEDATE chairs.

Recharter March 2023

RFC 3339 defines a text format as a profile of ISO 8601 that can reliably express an instant in time, either in UTC or in a local time along with the offset against UTC. However, datetime data often has additional context, such as the timezone or calendar system that was in use when that instant was recorded.

Particularly when using times for interval, recurrence, or offset calculations, it is necessary to know the context in which the timepoint exists. It would be valuable to have a standard text serialisation format for this contextual data. This working group will develop and publish a format meeting that requirement, subject to the additional constraints described below.

 • This format must be able to round-trip through intermediate systems which do not understand the full context.

 • Systems which don’t understand all the contextual fields must still be able to reliably extract the instant in time.



This format will be a companion to RFC 3339 rather than a replacement, embedding unaltered RFC 3339 data in a way that makes it easy to parse just the datetime data independently of the context.

The work on this format discovered an issue with RFC3339. When ISO8601 was revised in 2000, the “-00:00” offset which RFC3339 had invented for “offset isn’t relevant” was made invalid. This means that RFC3339 is not a strict subset of the current version of ISO8601.


To fix this issue, the working group will additionally update RFC3339 by removing the definition of “-00:00” and updating the definition of “Z” (Zulu) to mean that the offset to local time is not known, leaving “+00:00” to mean that UTC is the preferred reference point for local time.

Any other changes to RFC 3339 are explicitly outside the charter for this working group. If a need for any other changes to RFC3339 emerge, this group must recharter before performing that work. In this case, the changes to RFC 3339 will need to be clearly motivated, evaluated and precisely scoped during the rechartering process, and will need to make only changes that keep the timestamp specification a profile of current versions of ISO 8601. Stability of the RFC 3339 timestamp format is important to existing IETF protocols and the Internet generally, and any rechartering process should frown on anything that would invalidate the existing timestamp format.

The working group will coordinate with ECMA International TC39 and ISO/TC 154 to ensure that this work remains a strict extension of ISO 8601 and its various parts rather than becoming a conflicting standard.

Milestones:

 • Apr 2023 Submit extended date and time draft to the IESG for publication

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com