RE: [xliff] RE: Change Track Module

From
Schurig, Joachim <>
Date
2013-03-05T16:45:47+00:00
ID
Thread
RE: [xliff] RE: Change Track Module
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:  [mailto:]
On Behalf Of Ryan King

Sent: Freitag, 1. März 2013 19:10

To: Yves Savourel; 'Shirley Coady'; 

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:  [mailto:]
On Behalf Of Yves Savourel

Sent: Thursday, February 28, 2013 3:07 PM

To: Ryan King; 'Shirley Coady'; 

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:
 [mailto:]
On Behalf Of Ryan King

Sent: Thursday, February 28, 2013 3:48 PM

To: Ryan King; Shirley Coady ();


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:
 [mailto:]
On Behalf Of Ryan King

Sent: Wednesday, January 30, 2013 11:28 AM

To: Shirley Coady ();


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:
 [mailto:]
On Behalf Of Ryan King

Sent: Friday, January 18, 2013 2:50 PM

To: Shirley Coady ();


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