Revising Structured Fields: scope

Discussion so far seems to indicate folks have a preference for defining a new Date type in a revision of the Structured Fields specification, rather than in a separate document or as part of the Retrofit draft.

If we're going to 'open up' the Structured Fields specification, we should have a defined scope of work, to help assure we don't unintentionally take on a bigger task than we're willing to. 

I'm proposing that the scope be limited to:

- Adding a Date type (using the current text in the Retrofit draft[1] as a starting point)
- Removing ABNF from the specification (as discussed, it's confusing and current editorial style is NOT to use it[2])
- Addressing technical issues that are or could qualify as errata (e.g., minor algorithm clarifications)
- Minor and purely editorial work (e.g., improving wording, explanations, correcting typos if found)

If we limit it in this way, I'm reasonably confident we can ship the spec to the IESG in a reasonable timeframe -- conceivably before the end of the year.


1. <>
2. <>

Mark Nottingham

Received on Wednesday, 12 October 2022 22:56:53 UTC