I've heard people objecting to clear *improvements* in a protocol on the basis that their less capable variant is already deployed in the field, and it's too much work to update. Sometimes that's just a fact; at other times, it elicits the "rubberstamp" argument. Den 06. aug. 2016 21:29, skrev ned+ietf@xxxxxxxxxxxxxxxxx: > >>> On Aug 3, 2016, at 4:15 AM, Randy Bush <randy@xxxxxxx> wrote: >>> >>> if you write a draft and have running example code, you are accused to >>> be just coming to the ietf for a rubber stamp (cf. sidr). > >> The Postfix code for DANE in SMTP was developed in parallel with the early >> drafts of RFC767[12]. I don't recall any "rubber stamp" objections. Perhaps >> that was an exception, but at least that objection is not universal. > >> Work on the Postfix code began in Mar/2013 and on the new drafts in May/2013. >> Stable code in Postfix 2.11 was released in Jan/2014, and the RFCs were finally >> published in Oct/2015. > > Going way back, there were at least three implementations, two by two of the > specification coauthors, developed in parallel with the MIME specification. > > Since then I've always tried to code in parallel with the specifications I'm > involved with. > > None of this was in any way secret - in fact I've often stated that my position > on such-and-such was the result of implementation experience - and I don't > recall ever getting any flak for it. > > Hopefully this experience isn't unique to email protocols. > > Ned >