<html><body><p>Hello all,<br><br>Hope everyone had a good weekend, and hope this email does not ruin your next.<br>We had a small internal discussion at IBM and here are some of the findings that I will present to the wider community.<br><br>1. The ":" separator that swift currently uses is not entirely safe since LDAP can be configured to allow special characters in user IDs. It essentially means no special characters are safe to use as separators. I am not sure how practical this is, but its something to consider.<br><br>2. Since names are not guaranteed to be immutable, we should store everything via IDs. Currently, for backward compatibility reasons, Swift continues to support names for for V2. Keep in mind that V2 does not guarantee that names are immutable either. Given this fact and what we know from #1, we can say that names are mutable for both V2 and V3, and that any separators we use are fallible. In other words, using a separator for names or ids will not work 100% of the time.<br><br>3. Keystone recently enabled URL safe naming of project and domains for their hierarchal work. As a by product of that, if the option is enabled, Swift can essentially use the reserved characters as separators. The list of reserved characters are listed below. The only question remaining, how does Keystone inform Swift that this option is enabled? or Swift can add an separator option that is a subset of the characters below and leave it to the deployer to configure it.<br><br><tt><font size="4">";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |"$" | ","</font></tt><br><br><a href="https://github.com/openstack/keystone/commit/60b52c1248ddd5e682838d9e8ba853789940c284">https://github.com/openstack/keystone/commit/60b52c1248ddd5e682838d9e8ba853789940c284</a><br><a href="http://www.ietf.org/rfc/rfc2396.txt">http://www.ietf.org/rfc/rfc2396.txt</a><br><br>3. As mentioned in the KeystoneAuthACL write up in Atlanta, JSON format is one of the option going forward. The article goes on to mention that we should store only user IDs (avoiding the mutable names issue). It outlined a process and reverse-process that would allow names to be use but mentioned an overhead cost to Keystone. I personally think is the right approach going forward since it negate the use of a separator altogether.<br><br>Whether we chose to store the user IDs or names as metadata is another issue. But on a side note, I have tested this the changing names in V2 and it has the same exact problem as V3. If we are allowing V2 to store names [{ project, name }], I do not see why we should not allow the same for V3 [{ domain, project, name }]. This would remove the overhead cost to Keystone. And of course, you still have the option to store things as IDs [{ domain, project, id }].<br><br><a href="https://wiki.openstack.org/wiki/Swift/ContainerACLWithKeystoneV3">https://wiki.openstack.org/wiki/Swift/ContainerACLWithKeystoneV3</a><br><br>My intention is to spark discussion around this topic with the goal of moving the Swift community toward accepting the JSON format. Whether we store it as names or ids can be a discussion for another time. If you made it this far, thanks for reading! Your thoughts will be much appreciated.<br><br>Thanks,<br>Thai (tqtran)<br><br><BR>
</body></html>