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

[Carsten Bormann <[e-mail]>]

On 2023-04-13, at 15:04, Robert Wilton via Datatracker <[e-mail]> wrote:
> 
> 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:
> ----------------------------------------------------------------------

I may be easier to understand this charter in the context of what is actually in the draft:

https://ietf-wg-sedate.github.io/draft-ietf-sedate-datetime-extended/draft-ietf-sedate-datetime-extended.html#name-updating-rfc-3339

> Am, I right that the proposal is:
> - Remove support for "-00:00"

More like: acknowledge that this isn’t widely implemented, and cannot be, as it is prohibited by ISO 8601.
(Section 2 ends in “the present specification however does not formally deprecate this syntax”; I personally would have gone further.)

> - Redefine what "Z" means in a timezone so that it now means something
> different from what it has meant for the last 20 years?

More like: Acknowledge that Z has had that meaning in a wide variety of implementations.
(We cannot fix the fact that there are exceptions that actually implement RFC 3339 by mapping +00:00 to Z.  But this has been questionable in practice already.
Note that we are discussing only the “timezone hint” aspect expressed via a timezone offset; the meaning of the timestamp itself does not change.
The new specification also provides ways to express better timezone hints in the future.)

> 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?

They can be reasonably sure that the implementation already will be using the “new”  convention, which is now documented.

Note that RFC 3339 is different from email dates (RFC 2822/5322), which show (limited, but active) usage for the -00:00 convention.

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

I don’t think we have a good way with dealing with situations where competing (and contradicting) standards led implementations to do something different from what we originally prescribed.

Or, succinctly, the outcome of this cannot be good.  I can only be less bad.

Grüße, Carsten