[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 Florido Paganelli said:
> with all the respect, you should just read the document, and you'll
> notice that the spirit is really to sync it with the current
> implementations at the best, correcting deviations that might make the
> implementation not capable of using the unique features of the
> underlying technology, or improving (mostly human) readability.

I'm not clear how you expect to proceed from here. For me the correct way, and the way we've always done this in the past, is for you to prepare a list of proposed changes which we can discuss one by one and record decisions as we go. If we try to base a discussion on a completely re-written document I think the discussion will go nowhere useful, we will start debating it one word at a time! Also, in the meantime you have uploaded the new document over the top of the existing one so anyone looking for documentation on the LDAP rendering is likely to assume that is now the agreed specification, which it certainly isn't.

  For the specific question of the string type I think this needs wider discussion as it potentially affects all renderings. In any case it's a real problem and not simply a matter of changing the text; at the moment I don't find it obvious what the best solution will be (see below).

> I believe there is no real backward incompatible change that cannot be
> fixed in a simple minor update; the logic is there, we're speaking
> about renaming of groups, which is in line with the previous version of
> the documents. I clearly remember an exchange of email where you said
> the structure of the tree is not important. Did you change your mind?

I will try to say it more clearly. When I say that the tree isn't important I'm referring to queries made by clients; they should query using objectclass and attribute filters and ignore the DN. However, the deployed BDII infrastructure does of course build the DNs in a particular way, and that implementation is for the time being essentially fixed - there are BDIIs and information providers spread over hundreds of sites and thousands of services, and the typical time to propagate a change to all of them is of the order of 3 years. Hence any changes must be made in a gradual, backward-compatible way and can't be relied on for quite a long time.

  In terms of the document, my view is that it should specify something which is consistent with the current BDII implementation, but on the other hand should not constrain any implementation more than necessary - we may well want to evolve the existing infrastructure in the medium term, and of course other providers, e.g. Nordugrid, may want to produce their own implementation. I don't think there is any necessity to specify the DIT since clients should not need to rely on it. If you do regard it as necessary to specify aspects of the DIT I would like to see the specific use cases which you think require it.

> > 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.
> 
> But why is that? I didn't understand the problem there, I was not part
> of the process at that time, sorry

I'm not sure what you're asking, but the basic issue is that the schema doesn't specify what characters are allowed in strings. In GLUE 1 we typed strings using the IA5String type which is basically 7-bit ASCII; most of the time that's OK but every so often someone gets tripped up when they try to include other characters; the most recent case I helped to debug was only a few weeks ago. The initial definition of the GLUE 2 LDAP schema also used IA5String, but we then discussed this issue and agreed to switch to DirectoryString which allows UTF-8 strings. However it seems that the schema was never updated to reflect that decision. I'm a bit surprised that I never noticed that, but that's where we are. The simplest solution would be to make a global declaration, for all implementations in all technologies, that only ASCII characters are allowed, but that may not be the best way. We could make it implementation-defined, but then we should probably make some statement about interoperability.

Stephen