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

[Florido Paganelli]

On 06/16/2012 06:15 PM, stephen.burke at stfc.ac.uk wrote:
> 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!

I'll try do present it this way in my presentation. I will clearly state 
what is to be discussed

> 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.

the document clearly says draft, and we had no other traceable way of 
sharing with the rest of the group, I don't know how to do this better!

>
> 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

So we have a recommendation draft that nobody actually followed and you 
want us to comment on that? I don't understand. We must make it usable 
for implementers, the previous version was not, I think the new one is 
clearer.

>- 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.
>

then we will come to a deal and a roadmap, I don't see any bad with that.

> 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 am already trying to fix that to fit in the bdii-top, at the moment 
I've been successful, I would't be so pessimist here. And again, you are 
contradicting yourself if you say there is no mandatory DIT but the 
actual infrastructure is based on a specific DIT!

We should then make the infrastructure independent on the DIT. But My 
idea is that is an overkill on LDAP.

> 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.
>

but you just said current clients rely on 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.
>

isn't enough to change the schema? UTF8 strings will be there anyway, 
it's just a matter of encoding, isn't it?

Cheers,
-- 
Florido Paganelli
Lund University - Particle Physics
ARC Middleware
EMI Project