Re: Revising Structured Fields: scope

I think that this is an excellent scope to set.

I will note that the RFC currently has no errata; I'm also not aware of any need to do editorial work, minor or otherwise. Work to address those should be very cheap.

The end of the year seems aggressive, but if the assigned editors are quick, we can discuss a revision at IETF 115 and run WGLC shortly after.

On Thu, Oct 13, 2022, at 09:56, Mark Nottingham wrote:
> 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. <>
> --
> Mark Nottingham

Received on Wednesday, 12 October 2022 23:22:31 UTC