For example the TLS Working Group is polishing up a document telling people to cut it out with the TLS 1.0 after all these years and get to something at least vaguely modern like ten year old TLS 1.2 instead, (once upon a time named the diediedie draft, these days it has a more respectable name). Martin Rex offered the opinion that TLS 1.2 is _worse_ than TLS 1.0 and 1.1 because it doesn't smash SHA1 and MD5 together to produce a single hash. He reasons that if, somehow, SHA1 is broken enough to allow a preimage attack, TLS 1.0 is fine, whereas TLS 1.2 with SHA1 is now broken.
Of course people said Martin is barking up the wrong tree. But much more importantly they took another look at their document, it didn't actually _say_ you should implement SHA-256 when you upgrade to TLS 1.2, but they all agreed you should do that, so probably the document wants to spell that out...
I've read the SIP RFCs. That's not a hard rule unfortunately. (Unless it really was worse before, but I can't imagine that...)
https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=rfc326...
... is the changes from their last draft to the published RFC
Admittedly only very recent work with git-minded people in the WG has a full git history of revisions, earlier work like SIP just has the numbered drafts representing a few months work typically from one draft to the next, but you can go back and see this work and also the mailing lists that drove the changes.
I'm not a SIP expert, but looks to me like the brief extracts I read are improvements. For example that last draft requires people who want to add a new SIP method (like INVITE or CANCEL) to send IANA a copy of the RFC describing their method. Why? What possible purpose could there be when RFCs are public documents? Are they expected to... print it out and mail it? So, the final standard text just says to provide the RFC number.
I'm happy to see a newer standard that is at least simpler to understand and implement.
Sorry to be 'that guy'. I like Fastmail but maybe they could fix some of the irritating bugs we keep asking for resolutions on before embarking on fun protocol invention missions. Two killers:
(1) When forwarding an email there is no link between the forwarded email and the original thread (TOTAL TIME WASTER), when reported they "don't consider it a bug [because of SMTP ID handling in existing daemons]". Missing the point here so hard guys!
(2) When creating a new filter it doesn't have a checkbox to include matching emails. This means you have to manually go replicate the search again, for consistency, to get things where they should be.
Frustrated at lack of response from reporting these as a commercial user. Inventing new protocols should not be higher priority than fundamental annoyances that are wasting customer time NOW.
But you know, you could send them the feature requests - they actually implemented something I asked for on mobile, so at least one team is listening.
Did you interview all gmail users to ask them if they would miss those features if they weren’t there?
Really thrilled the FastMail team is working on this, and doing it in the way that changes to mail should be handled: Going through proper Internet standards bodies. It's in stark contrast to AMP4Email, which is being implemented by Google wholly without respect to Internet standards.