Compare the output of iddiff with the output from rfcdiff for almost any pair of files, and it will be seen that iddiff does not ignore changes in line wrap, which is a serious regression relative to rfcdiff.
For example, if a few words are added or removed in the middle of a para, for the rest of the para there will be blocks of text highlighted around the starts and ends of every subsequent line. Also, sometimes this causes iddiff to give up and just highlight everything from the first line-break after the actual change until the end of the para.
Example: compare the diffs between the most recently published RFC (9329) and the last draft before it was approved (note, however, that almost any pair of files will demonstrate the problem):
idiff:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-ipsecme-rfc8229bis-09&url2=rfc9329&difftype=--html
rfcdiff:
https://bobbriscoe.net/tmp/rfc932-from-draft-ietf-ipsecme-rfc8229bis-0.diff.html
I suggest you skip over all the boilerplate to Section 1.
Bob
Compare the output of iddiff with the output from rfcdiff for almost any pair of files, and it will be seen that iddiff does not ignore changes in line wrap, which is a serious regression relative to rfcdiff.
For example, if a few words are added or removed in the middle of a para, for the rest of the para there will be blocks of text highlighted around the starts and ends of every subsequent line. Also, sometimes this causes iddiff to give up and just highlight everything from the first line-break after the actual change until the end of the para.
Example: compare the diffs between the most recently published RFC (9329) and the last draft before it was approved (note, however, that almost any pair of files will demonstrate the problem):
idiff:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-ipsecme-rfc8229bis-09&url2=rfc9329&difftype=--html
rfcdiff:
https://bobbriscoe.net/tmp/rfc932-from-draft-ietf-ipsecme-rfc8229bis-0.diff.html
I suggest you skip over all the boilerplate to Section 1.
Bob