[ietf-822] Re: Fwd: [Ietf-dkim] Fwd: WG Action: Formed Mail Maintenance (mailmaint)

[Bron Gondwana <[e-mail]>]

On Tue, May 14, 2024, at 18:41, Keith Moore wrote:
> On 5/10/24 17:36, Dave Crocker wrote:
> 
> >
> > -------- Forwarded Message --------
> >
> > On 5/10/2024 10:54 AM, Murray S. Kucherawy wrote:
> >> * Prior to accepting any Standards Track document for development, 
> >> there must
> >> be a commitment to implement the resulting proposed standard from at 
> >> least
> >> two independent parties, as recorded on a related IETF mailing list.
> >>
> >> * When deciding to send any Standards Track work to the IESG, there must
> >> first be produced a report documenting at least two (preferably more)
> >> independent implementations with at least partial interoperation 
> >> based on the
> >> developed specification.
> >
> >
> > This imposes two, formal requirements for Standards Track that are 
> > dramatically higher barriers than is typical for IETF Standards Track 
> > specification.
> 
> I had a similar impression.
> 
> Offhand, I think it's unreasonable to expect parties to commit to 
> implement a standard before they've even seen a near-complete draft of 
> it, so I'd like to see this provision go away.

I'd like to see it become more widely distributed.  You discover a LOT more when actually implementing something than when a bunch of smart people sit down and think really hard without actually real-worlding it.  I have so many cases I've designed something that seemed really nice only to see it fall over under real world conditions, and I consider myself at least medium-smart.

> Also, historically we have not expected multiple independent 
> implementations to appear before sending work to IESG, though sometimes 
> this has happened.   While I don't inherently question the desirability 
> of encouraging early implementation of a standard-to-be, I wonder 
> whether this will cause the WG to "stall" awaiting such implementations 
> to appear.   I suspect that's not a desirable outcome.

If there aren't at least two implementers able to put together proof of concepts and have them interoperate with each other, then you don't have anything shown workable yet.  It can be as simple as a perl^Wpython script that spits out the wire format and a parser that consumes it.  Have two people write those, send each other messages, parse them. Viola,  you have yourself a spec.

> Traditionally we expected implementations to follow publication as 
> Proposed Standard and required them before advancing to later stages.   
> Of course, this didn't always work well.   Sometimes the work languished 
> and never reached a desirable level of maturity, and sometimes the 
> protocol was widely implemented without advancing and the motivation to 
> maintain the specifications had to come from somewhere else (if it ever 
> did).
> 
> I welcome more exploration of how to maintain core IETF protocol 
> specifications over long periods of time, as I see this as an emerging 
> problem for IETF.  I'm not sure how well the traditional WG structure 
> adapts to this need.  Of course, nothing stops this group from being 
> rechartered, or the work from being moved to a different structure, in 
> the future, so I don't see this aspect of the current mailmaint charter 
> to be a serious concern.

If we find that things are blocked up after a couple of years, I'd be happy to re-visit this, but I'm strongly in favour of requiring more implementations of stuff before standardising them.

At the moment within Fastmail we're running both a pre-JMAP JSON version of our contacts and calendars, plus a snapshot of the JMAP formats from a few years ago (ask me over a beer some time... I can't wait to throw out all that pre-JMAP code, it's a horror) - but we have implementations and test cases for the version that's going to become the standard as well - and update them each version with the spec - even if they're not running in production.

If we had the separate implementation requirement we'd also be pushing harder to get someone else to implement first, and maybe catch even more issue before publishing but at least we have complete implementations.  And the JSON data formats themselves have multiple separate implementations by different vendors already, and the interop testing of the converters to the VCARD and VCALENDAR formats raised many issues that would have made it through to publishing if we hadn't been so strongly pushing for implementations before publishing.

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [e-mail]