[Sedate] Proposed recharter

Bron Gondwana <brong@fastmailteam.com> Wed, 09 November 2022 18:10 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 C17ACC14CE40 for <sedate@ietfa.amsl.com>; Wed, 9 Nov 2022 10:10:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.805
X-Spam-Level:
X-Spam-Status: No, score=-2.805 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_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=RuMUHC4A; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Awn/sgtO
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 yn54qqbBBDKl for <sedate@ietfa.amsl.com>; Wed, 9 Nov 2022 10:10:18 -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 59D1AC14CE47 for <sedate@ietf.org>; Wed, 9 Nov 2022 10:10:18 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 0DAB85C019D for <sedate@ietf.org>; Wed, 9 Nov 2022 13:10:17 -0500 (EST)
Received: from imap43 ([10.202.2.93]) by compute4.internal (MEProxy); Wed, 09 Nov 2022 13:10:17 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm2; t=1668017417; x=1668103817; bh=etuyPf7CcQ 8Me9kNlA8YpUj7vu4S9BqC+V4hIKDqAq0=; b=RuMUHC4ArnOyn2uFtqlauCjV6j jDeNNTreDpL/kFHaDKfdf2V1v7YaMgWRFhD4euc+5P4jvWBtXy6AuIEousxPxv9G yFmihsid0uR+afKsu4q3mrPkMpTVgqzES0qwbYNRtNNR+EIQ6lW7Pj/QeK7BYlvy w5jBd76+oTch3FIviW3x/xpVlfSBcYnteI2iyJ0ecJuimA98EKtKb2UrcQmf9CAp yvo9GuNX+pe9Xa5ZLNbPjM1pkpFS1dzKTORwYlTzJl6tPr25BoJcPmjFUMVWr22+ 7hBcmGQ7EUnbuQcYDML2HebPehALi7uIi/p2aR9nIC5S3jH87kcSkUjnTbPg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=1668017417; x= 1668103817; bh=etuyPf7CcQ8Me9kNlA8YpUj7vu4S9BqC+V4hIKDqAq0=; b=A wn/sgtOQyAK9tDhpVqNAratMa53OJMT5W/fIG/80OAKOkGhBz7KiwgIMiLOE3LoG BANFg48fk1YQ5Q+OgCR8l7a/pUkJjNUZoAM0AUqERQ/7bAmKr3Mmeau1gM0kE6HJ IdOtX4R6IMr2WD7858kKa6los6fDzs/0j9TaFehalGPog9ZrHwfJhx+z1pDZGtC9 3kdCrORVQxF4Kd68Li7jlBiZsRxUMGgkB0NjGUHgOEez829eiqthvpIkU4GGzZPv GudoFiCIQgRIcTp+Gk/KIjXGU10y0gj1HkEydEBI1KoUvjXJDnr9x21OPIUHoyo9 N54qyOJTLGEqM2yhfRAGQ==
X-ME-Sender: <xms:CO1rYwHW-6yeYreRNp3S4t87RkkxFuX12E33P3P_R5HIGCr56iuZ6A> <xme:CO1rY5UgYVj_gjnaCRcECfQYQWV-qLPorexLq6BIW-33NWNxMqZsXvY6FCNYVsqlf -22uULxIpo>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrfedvgddutdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpefhjeehkeejkeehve eutdejteeihffffeduiedttdejhfelteevueehudeltdeuffenucffohhmrghinhepihgv thhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm
X-ME-Proxy: <xmx:CO1rY6IVXRtUl969IL9XK5HqKXEZhMPbhv9Y3PABeVngdE1gvjDehA> <xmx:CO1rYyEuTfo3zaw3GcjgM5t8fR-DxCJb1Wbfjh1_zT-MmyaIRAq9GQ> <xmx:CO1rY2UO_ko2v-WzdywHNJwHDg7_eN0M_dFo0d9s77RBb1tqADeKEg> <xmx:Ce1rY-if1s9JCaLpxhhAsSWUV-oMx6V3qp03-BfGL6kkfune4zkGMQ>
Feedback-ID: i2d7042ce:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id C65D92D4007D; Wed, 9 Nov 2022 13:10:16 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-1115-g8b801eadce-fm-20221102.001-g8b801ead
Mime-Version: 1.0
Message-Id: <ac7bc31c-e442-4b3f-b1f4-cf9b2ee28a02@app.fastmail.com>
Date: Wed, 09 Nov 2022 18:09:56 +0000
From: Bron Gondwana <brong@fastmailteam.com>
To: sedate@ietf.org
Content-Type: multipart/alternative; boundary="2aded1e24d89434c833471886f7e2ebf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sedate/sHH5agXWVW82QIsYBZLr8dsYRjg>
Subject: [Sedate] Proposed 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: Wed, 09 Nov 2022 18:10:22 -0000

Hi All,

Here's some proposed text.  Feel free to edit directly at:

https://notes.ietf.org/bZEMq1JgTtiO6F0XWLD4MA?both

*Charter**
*

RFC3339 defines a 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.

The work for draft-ietf-sedate-datetime-extended 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.

Further, in real world usage, the "Z" (Zulu) offset is often taken to mean "offset isn't relevant", and only "+00:00" to mean an explicit offset.

This is not an issue with ISO8601 which makes no claims about the meaning of the offset, it's only an issue with how the IETF has chosen to interpret different representations of the zero offset.

This working group is narrowly chartered to update RFC3339 in a fully backwards compatible way, to say that "-00:00" MUST NOT be generated but SHOULD be accepted, and allow for the meaning of "Z" to match real world usage.

Other changes to RFC3339 are explicitly outside the charter for this working group. Stability of the RFC3339 timestamp format is important to existing IETF protocols and the Internet generally.

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

Milestones:

  Feb 2023 - issue a document that updates RFC3339 to disallow new timestamps with "-00:00" offsets.

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