Hi Florido, On 09/24/2013 05:46 PM, Florido Paganelli wrote:
Hi Laurence, all,
Some thoughts about Laurence claims that should help us sort out the issue.
Hi Florido,
The question is basically flat vs nested, similar to the XML, JSON discussions. As I mentioned in the previous mail, the decision at the time was to go with flat, i.e. not to make any assumption about the DIT. But then I really don't understand why you put a picture of the DIT in
On 2013-09-24 15:49, Laurence wrote: the rendering document, in the version before the one me and Balazs reviewed. If you wanted to go flat you shouldn't have suggested any DIT. I don't know who put it in or the reasoning behind it, but agree it should not be in the document as it is confusing rather than helpful.
The truth is that no LDAP implementation can be really flat. Here's the reasons:
Even if we move the whole DIT to external documents, the draft will leave these question open both for producers and consumers of information:
1) shall we mandate a tree root or not (i.e. a DN suffix)? (the already discussed o=glue thing) [I think this is good choice] The DN suffix discussion is part of the access protocol. The o=glue suffix is used to "access" GLUE 2.0 information. It is perfectly reasonable to query using HTTP (access protocol) and return LDIF (data model). The standarization of the access protocol has not started. 2) shall we suggest a use of GLUE2GroupID entries? I recall these are NOT part of the GFD147, it's an invention that came with LDAP rendering. [I already motivated why I like structures. no need to add here]
In spite of the above, I'd like to stress that we *CANNOT* suggest a complete FLAT tree structure, because if so, we shoudln't use groupings. Introducing a group introduces a dn structure and therefore a DIT. Be careful. We do not say that it MUST be flat, we say that you should not assume any specific DIT structure. The grouping entries are there for pragmatic reasons if for whatever reason someone would like to group objects, but we do not care how people do this as the structure should be ignored.
By defining 1) we are already mandating a minimal tree structure. All GLUE2 LDAP entries MUST be child of o=glue entry, like <glue></glue> in XML. No. We are defining part of an access protocol, which is out-of-scope for an information model discussion.
2) needs to be defined somewhat as it doesn't exist in the model, or removed forever. So the question is why is the grouping entry defined if we state that you should not assume any specific DIT structure?
Laurence