Hello,
the main reason I would propose to use a CRC over a cryptographic hash when you would want to check for corruption only is that a CRC can be computed
a lot faster, and typically needs a lot less storage space. Of course the collision risk is higher (by design) than with a cryptographic hash, but we do not intend to use the checksum as a unique ID. And because we do not take any other provisions to guarantee
integrity (by using certificates and signatures) there is not much necessity to make it difficult or impossible to break integrity.
Regards,
Joachim
From:
xliff@lists.oasis-open.org [mailto:
xliff@lists.oasis-open.org]
On Behalf Of Ryan King
Sent: Freitag, 1. März 2013 19:10
To: Yves Savourel; 'Shirley Coady';
xliff@lists.oasis-open.org Cc: Kevin O'Donnell; Uwe Stahlschmidt; Alan Michael
Subject: RE: [xliff] RE: Change Track Module
Thanks Yves, I’ll let Fredrik or Joachim answer this one as this was a request from their side. They may have more details as to why they chose
CRC32 in particular.
Ryan
From:
xliff@lists.oasis-open.org [mailto:
xliff@lists.oasis-open.org]
On Behalf Of Yves Savourel
Sent: Thursday, February 28, 2013 3:07 PM
To: Ryan King; 'Shirley Coady';
xliff@lists.oasis-open.org Cc: Kevin O'Donnell; Uwe Stahlschmidt; Alan Michael
Subject: RE: [xliff] RE: Change Track Module
Hi Ryan,
One note: Any reason to use the CRC32 value for checksum?
Wouldn’t MD5 or SHA-1 or other more reliable algorithm be better? I’ve read that CRC32 is ok for error checking but not necessarily perfect for checking
integrity. or we think CRC32 is good enough?
cheers,
-yves
From:
xliff@lists.oasis-open.org [ mailto:
xliff@lists.oasis-open.org ]
On Behalf Of Ryan King
Sent: Thursday, February 28, 2013 3:48 PM
To: Ryan King; Shirley Coady (
scoady@multicorpora.com );
xliff@lists.oasis-open.org Cc: Kevin O'Donnell; Uwe Stahlschmidt; Alan Michael
Subject: [xliff] RE: Change Track Module
Here is the latest draft of the Change Track module that takes feedback into account from Fredrik and Joachim to incorporate checksum handling
and being able to roll-back a revision made outside of an XLIFF-aware tool. Fredrik was kind enough to share implementation details with me so I could understand the use case better. I will be creating docBook files and adding this version to the spec in the
next couple of days.
Thanks,
Ryan
From:
xliff@lists.oasis-open.org [ mailto:
xliff@lists.oasis-open.org ]
On Behalf Of Ryan King
Sent: Wednesday, January 30, 2013 11:28 AM
To: Shirley Coady (
scoady@multicorpora.com );
xliff@lists.oasis-open.org Subject: [xliff] RE: Change Track Module
Hi All, I haven’t seen any feedback on the draft for Change Track Module. Please send them to the list so that I can incorporate any changes before working on the
DocBook files and publishing it to the spec.
Thanks,
Ryan
From:
xliff@lists.oasis-open.org [ mailto:
xliff@lists.oasis-open.org ]
On Behalf Of Ryan King
Sent: Friday, January 18, 2013 2:50 PM
To: Shirley Coady (
scoady@multicorpora.com );
xliff@lists.oasis-open.org Subject: [xliff] Change Track Module
Hi Shirley and ALL,
In the TC call on 11/21 it was decided that the following items
Change Tracking / Version Control (Shirley)
Change track module (Ryan)
Would be merged into 1. Please take a look at the attached Change Track Module proposal and provide comments.
Thanks,
Ryan