[Debian-sf-devel] Assigned LDAP OID for Sourceforge

[Roland Mas]

  Hi,

Well, after some time spent debugging other stuff, I'm back on the
LDAP part of Sourceforge.

Russell Coker (2001-10-25 15:20:21 +0200) :

> # Under the Debian LDAP number let's assign number 100 onwards to Debian 
> related# projects.
> # 100 is for scalemail which makes scalemail LDAP be 1.3.6.1.4.1.9586.2.100
> # 101 is for sourceforge which makes sourceforge LDAP be 
> 1.3.6.1.4.1.9586.2.101
>
> The above is from my latest OSI draft.  Please start using
> 1.3.6.1.4.1.9586.2.101 as you see fit.

  I did.

> However please note the usual limitations on how to do these things,
> use a part of your number range for experiments and renumber objects
> from experimental range to real numbers after they are finalised.

  Okay.

> Firstly it is recommended that each project that has it's own
> attributes and objectClasses use it's own name prefix to avoid
> naming clashes.  I don't think that "x-" is destined to be unique
> and I think that many of your attributes are things that other
> projects may allocate.  I suggest "sfgCvsShell" for this one and
> prefixing all attributes with "sfg".

  I took the liberty of reinterpreting that as "debSf".  I have no
control over the upstream Sourceforge maintainers, and even though
they are not very responsive (not very responsive at all, even),
there's no need to trample on their feet.  A lot of work has been done
on this package, and the difference with upstream justifies the
distinction in names anyway.

> I think it would be good to have some of these in the standard
> Debian schema so that anyone who needs such features can get them
> without including the sourceforge schema.  I am thinking of
> "debForwardEmail" and "debListPostAddress".  Of course this doesn't
> stop you from having "sclForwardEmail" etc, but I think it would be
> handy to not double up.

  Well, until there is a debian.schema in some ldap-common package,
I'll keep these in my sourceforge.schema.  I'll be glad to switch over
to yours when they are available, of course.

> Generally for any attribute that isn't available in any standard
> schema and which has obvious practical uses you can send me the
> details and I'll make it a Debian standard attribute.

  See attached file, take your pick, and tell me what you take and
what I can keep.

> I am much more hesitant about adding Object Classes because it's
> much harder to get them right in a global sense.  Also for someone
> who is creating a schema for their own project or for private use
> it's much easier to create an object class

  Err, parse error on the last bit.  Could you rephrase and/or
explain?  What's wrong with creating an objectClass, and how can I
avoid it?

> Also why have these be single-value?  Forwarding email to multiple
> destinations is often desirable and having a mailing list with
> multiple addresses is quite common.  Even if Sourceforge doesn't
> currently support such things it might be a good idea to allow it in
> the schema (once the schema is set you would have to use a different
> attribute if you later need multiple values).

  You're right.  I removed all the SINGLE-VALUE bits from
attributetypes, except for debSfCvsShell, for which I can't see any
use.

  I attach the current state of the schema I plan to use.  If you have
any comments, please send them to me, so that I can fix what is wrong
and move what is right into the "stable" series (changing the OID).

sourceforge.schema
Description: LDAP schema used for Debian Sourceforge

  Thanks for your time,

Roland.
-- 
Roland Mas

[...] Des fois, y'a des trous. -- (Ptiluc)
  -- Signatures à collectionner, série n°2, partie 3/3.