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.
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...