[Sedate] Robert Wilton's Block on charter-ietf-sedate-01-00: (with BLOCK)

Robert Wilton via Datatracker <noreply@ietf.org> Thu, 13 April 2023 13:04 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: sedate@ietf.org
Delivered-To: sedate@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4B4C151538; Thu, 13 Apr 2023 06:04:55 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: sedate-chairs@ietf.org, sedate@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 10.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Wilton <rwilton@cisco.com>
Message-ID: <168139109514.46960.10088188298946909806@ietfa.amsl.com>
Date: Thu, 13 Apr 2023 06:04:55 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sedate/y9YkDgZvYEfukbo9R8ojIolxDBQ>
Subject: [Sedate] Robert Wilton's Block on charter-ietf-sedate-01-00: (with BLOCK)
X-BeenThere: sedate@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 13 Apr 2023 13:04:55 -0000

Robert Wilton has entered the following ballot position for
charter-ietf-sedate-01-00: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-sedate/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

Am, I right that the proposal is:
 - Remove support for "-00:00"
 - Redefine what "Z" means in a timezone so that it now means something
 different from what it has meant for the last 20 years?

If so, given that I presume that these timezones are very widely used/deployed
then when a device returns a timezone using the Z notation, how will the
recipient know whether there are using the existing RFC 3339 convention, or the
new convention?

I feel like I must be missing something here ...

Regards,
Rob