Subject: [Sedate] SEDATE Discussion topics for IETF 112

From: Carsten Bormann <[email-masked]>
Date: Wed, 3 Nov 2021 18:55:22 +0100

As you might have seen, an updated I-D [1] is available as input for
next week's sedate meeting.

Here is a list of topics that we might want to use to potentially structure a discussion, or maybe even to have a discussion on the list about them before the meeting.  Note that there also is a list of issues on the github repo [2], which is somewhat orthogonal to the discussion structure I'm proposing (but I'll reference most of them below).

I see five major topic areas:

## (1) overall format, idea of adding extensions to an RFC 3339 timestamp

We might discuss:

- the overall syntax (e.g., [#5])
- the meaning of receiving an extension one doesn't understand

The format probably needs a name (and that should be different from the WG name), [#9].

Do we simply add extensions to RFC 3339 or do we do surgery on that, too (e.g., [#7]) or have impact that changes the meaning (e.g., [#8])?

## (2) timezone extensions

I think this is relatively stable part of the specification, but:

What does it mean for a recipient that a timestamp has a timezone extension?
Is this purely informative, or does it change the meaning of the RFC 3339 part of the timestamp? [#3]

The TZDB is not static, not even in the timezone names it contains.  What does this mean with respect of the forward compatibility of extended timestamps? [#6]

## (3) naming the other extensions

The idea of delegating namespaces:
Weirdly, the registry in the draft doesn't register extensions, but namespaces, which are names for organizations that defined and keep registries for extensions.  Do we need this indirection?

X-Dash (RFC6648) considerations [#2], or more specifically: how does the naming of an extension evolve over its lifecycle (proposal, first implementations, formal acceptance, wider use)...

## (4) single-char namespace

Who exactly defines the u- extensions?
Just having a locale extension registered in BCP47 doesn't mean that the corresponding timestamp extension already has a well-defined meaning.

Will there be single-char namespaces beyond u-?  Why aren't we saying anything about them, then?

## (5) multi-char namespace

Section 3.3 [3] essentially defines requirements on an organization that then publishes IETF RFCs that they register in their own registries.  This sounds significantly more complicated than a simple RFC8126-style [4] registry with a designated expert (who could receive instructions that mirror the MUSTs currently in the section).  Discuss.

Grüße, Carsten

[1]: https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-01.html
[2]: https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/issues
[3]: https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-01.html#name-multi-character-namespaces
[4]: https://www.rfc-editor.org/rfc/rfc8126.html
[#2]: https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/issues/2
[#3]: https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/issues/3
[#4]: https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/issues/4
[#5]: https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/issues/5
[#6]: https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/issues/6
[#7]: https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/issues/7
[#8]: https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/issues/8
[#9]: https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/issues/9