#11 Force UUID version number to comply with standard

open
nobody
None
5
2010-05-20
2010-05-20
Tim Harris
No

This change is possibly a little controversial.

The UUID returned by the Windows system call is just a stream of random numbers. In order to comply with the UUID standard, the version number and reserved value need to be set. To be strictly correct (according to the RFC), the version number should be 4, but apparently this is not allowed in the ISO standard, so I have forced the version number to 1, but the UUID is actually still generated as a version 4 one should be. This might confuse a parser that was relying on this fact, but I really hope no-one is trying the use the UUIDs in an MXF file that way...

Discussion

  • Matt Beard

    Matt Beard - 2010-11-24

    Thank you for your effort with this, I have a couple of problems with this fix:

    First, the bytes you are setting are the 7th and 8th bytes (Buffer[6] and Buffer[7]) however from RFC4122 and ISO/IEC 11578 the "version" field in the the top 4 bits of the 8th byte (Buffer[7]) and the variant in the top bits of the 9th byte (Buffer[8]).

    Secondly, according to http://msdn.microsoft.com/en-us/library/ms688568.aspx and http://msdn.microsoft.com/en-us/library/aa379205.aspx Windows does generate proper type-4 UUID, and all the versions of Windows I have tested do set the correct values into the version and variant fields.

     
  • Tim Harris

    Tim Harris - 2010-11-24

    OK, cool. Thanks for looking at this in more detail, I thought it might not be quite right. I was endeavouring to clear a warning being given by the IRT's MXF Analyser Light.

    If I get the chance, I will try and look at this again.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks