> Also, I think it’s fair to say that, at this point, each and every one of you > owes me a beer :-))) > > Possibly more than one – this was a ton of work! > :-)
We should include Megan (and colleagues? I have no idea about how the RFC Editor team is set up) too, her / their work was nothing short of amazing! These lists of terms to capitalize, and of possible candidates for the <tt> style… a crazy amount of work to produce them! (let alone our many, many queries and suggestions). More seriously, perhaps we could indeed try to get together at one of the upcoming IETFs (I’ll probably not be in Bangkok, but perhaps Madrid) to jointly celebrate the end of this (yes, including RFC editor staff) ? Not only would it be a celebration, but we could also chat a little bit about what we could do in terms of deployment. I think the Transport Services effort is a little different from other standards in this regard. It’s easy to get a negative perception of it because in other cases, implementations tend to pop up long *before* the standard is finished (QUIC is the prime example here); with the (fantastic!) exception of Apple, that hasn’t happened for TAPS at all. However, since this is the API that’s exposed to applications, implementations at a significant scale are better off waiting until the standard is finished. Imagine rolling out a full Transport Services API at large scale, and then having to say “ah, sorry, all you application coders, we had to take feature X out and change how feature Y is represented because that was the IETF consensus”. Cheers, Michael
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
