Re: Revising Structured Fields: scope

Am 13.10.2022 um 00:56 schrieb Mark Nottingham:
> 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.
> Thoughts?
> 1. <>
> 2. <>

+1 on all points, except for the one about ABNF. The referenced
statement is about how to define Structured Fields in other specs; it
doesn't really say anything about why the use of ABNF *inside* the SF
spec would be a bad idea.

FWIW, as implementer of the spec the ABNF made things easier for me; I
understand that people who do not use ABNF a lot might feel different.
But if it ain't broke, don't fix it.

Best regards, Julian

Received on Thursday, 13 October 2022 05:42:24 UTC