[glue-wg] No audio

Laurence Field Laurence.Field at cern.ch
Tue Sep 24 15:09:29 EDT 2013


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.
>
> On 2013-09-24 15:49, Laurence wrote:
>> 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
> 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


More information about the glue-wg mailing list