@mweise, yes, your procedure describes the process correctly to my understanding.
I compressed your points into three points to use the non-standard character encoding in the second step immediately, as alternative alphabets is a known process:
- add two zero bytes at the beginning of the UUID
- convert using standard Base64 conversion, using the character encoding
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz_$ - strip the first two characters (should be
00always) from the 24 character result to get a 22 character string
Would you be be comfortable with this wording @mweise?
I would recommend that the bullet points should be added after this existing sentence on that IFC GUID page, and also for the sentence to be slightly modified (I have bolded my edits):
Given that each IFC object instance required a unique identifier containing a 128-bit number, a custom compression algorithm using the RFC4648 base 64 standard with an IFC-specific character encoding was devised as shown below:
- bullet points go here
The word “custom” and “IFC-specific” highlights the two areas where IFC deviates from the norm, which is why I have added them in. For completeness I also mentioned the RFC standard.
@jwouellette, after we confirm the revised wording with @mweise, would that be sufficient for you to make a modification?
Once that edit is made, the only step left is to confirm what the desired UUID generation algorithm should be, and then document that too, since it is currently unmentioned. 