[glue-wg] LDAP rendering document: new version as an outcome of Lund review

[stephen.burke at stfc.ac.uk]

glue-wg-bounces at ogf.org [mailto:glue-wg-bounces at ogf.org] On
> Behalf Of Balazs Konya said:
> I've just uploaded a new version of the "GLUE v. 2.0 – Reference
> Realization to LDAP Schema" ldap rendering draft to the glue2 gridforge
> area. The uploaded new version contains comments and tracks all the
> changes we made in the document.

I haven't yet read the new document in detail, but as the author of the previous version I have a few general comments. Firstly, I don't think it's accurate to describe this as a revision of the existing document; it seems to be substantially a new document describing a significantly different rendering. I would personally prefer to separate textual and minor technical comments on the existing text from substantive changes to the structure.

  Secondly, the history of this is that the LDAP rendering was discussed in this mailing list and in open meetings in mid-2009, the resulting LDAP schema was then implemented and we've spent nearly three years deploying it in production in EGEE and EGI. Given the practicalities of deployment I think it's essentially impossible to make any backward-incompatible changes at this stage, and even backward-compatible changes would probably take several years to propagate across the whole Grid, so regardless of how the document changes the major existing implementation is basically fixed.

  The previous document was intended to correspond to what was actually implemented but may not do so in every respect - for example it seems that we failed to change string types from IA5String to DirectoryString in the deployed schema. I think that's unfortunate but we will in practice have to live with it as a restriction (as we did for GLUE 1) - in that case we could change the schema since it would be backward-compatible, but it would be a long time before non-ASCII characters could be used reliably.

  It is of course possible to have variant implementations, and to some extent variants can be covered by a single document, e.g. it was explicitly intended to allow the DIT to be flexible. However, at some point if it's really desired to have renderings which differ in major ways I think it would be better to have separate documents.

Stephen