OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Incoming/6151
Full headers

From: michael@stroeder.com
Subject: Update cosine.schema to RFC 4524
Compose comment
Download message
State:
0 replies:
14 followups: 1 2 3 4 5 6 7 8 9 10 11 12 13 14

Major security issue: yes  no

Notes:

Notification:


Date: Thu, 28 May 2009 15:21:11 +0000
From: michael@stroeder.com
To: openldap-its@OpenLDAP.org
Subject: Update cosine.schema to RFC 4524
Full_Name: Michael Str.der
Version: HEAD
OS: 
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (84.163.80.206)


cosine.schema is still based on obsoleted RFC 1274. It should be updated to RFC
4524.

Followup 1

Download message
Date: Mon, 01 Jun 2009 13:29:28 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
To: openldap-its@openldap.org
Subject: Re: (ITS#6151) Update cosine.schema to RFC 4524
This is a multi-part message in MIME format.
--------------080004030402080700020504
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Updated schema file cosine-update.schema attached. Note that some schema
descriptions were copied from old cosine.schema to preserve backward
compability since RFC 4524 does not contain all schema descriptions e.g.
needed for 'pilotPerson'. Note that 'pilotPerson' is used as superior
class for 'OpenLDAPperson'. Also some aliases were added to NAME of
attribute type descriptions.

IPR notice:
This patch file is derived from OpenLDAP Software and RFC 4524 and RFC
1274. All of the modifications to OpenLDAP Software represented in the
attached file were developed by Michael Str.der <michael@stroeder.com>.
I have not assigned rights and/or interest in this work to any party.

--------------080004030402080700020504
Content-Type: text/plain;
 name="cosine-update.schema"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="cosine-update.schema"

# RFC 4524: COSINE LDAP/X.500 Schema
# $OpenLDAP: pkg/ldap/servers/slapd/schema/cosine.schema,v 1.26 2009/01/21
23:40:40 kurt Exp $
## This work is part of OpenLDAP Software <http://www.openldap.org/>.
##
## Copyright 1998-2009 The OpenLDAP Foundation.
## All rights reserved.
##
## Redistribution and use in source and binary forms, with or without
## modification, are permitted only as authorized by the OpenLDAP
## Public License.
##
## A copy of this license is available in the file LICENSE in the
## top-level directory of the distribution or, alternatively, at
## <http://www.OpenLDAP.org/license.html>.
#
# RFC 4524: COSINE LDAP/X.500 Schema
# This file is mainly based on the schema descriptions found in RFC 4524.
# To preserve backwards compability with 'pilotPerson' schema some attribute
# types and object classes not declared in RFC 4524 were copied from
# (obsoleted) RFC 1274 and some attribute type descriptions were extended
# with aliases for NAME.
#
# Depends on core.schema

# --------------------------------------------------------------------------
# 2.  COSINE Attribute Types
# --------------------------------------------------------------------------
#
#    This section details COSINE attribute types for use in LDAP.
# 

# --------------------------------------------------------------------------
# 2.1.  associatedDomain
# 
#    The 'associatedDomain' attribute specifies DNS [RFC1034][RFC2181]
#    host names [RFC1123] that are associated with an object.   That is,
#    values of this attribute should conform to the following ABNF:
# 
#     domain = root / label *( DOT label )
#     root   = SPACE
#     label  = LETDIG [ *61( LETDIG / HYPHEN ) LETDIG ]
#     LETDIG = %x30-39 / %x41-5A / %x61-7A ; "0" - "9" / "A"-"Z" / "a"-"z"
#     SPACE  = %x20                        ; space (" ")
#     HYPHEN = %x2D                        ; hyphen ("-")
#     DOT    = %x2E                        ; period (".")
# 
#    For example, the entry in the DIT with a DN <DC=example,DC=com> might
#    have an associated domain of "example.com".
# 
# (OpenLDAP-specific: Declared in core.schema)
# attributetype ( 0.9.2342.19200300.100.1.37
#     NAME 'associatedDomain'
#     EQUALITY caseIgnoreIA5Match
#     SUBSTR caseIgnoreIA5SubstringsMatch
#     SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
# 
#    The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the
#    'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are
#    described in [RFC4517].
# 
#    Note that the directory will not ensure that values of this attribute
#    conform to the <domain> production provided above.  It is the
#    application's responsibility to ensure that domains it stores in this
#    attribute are appropriately represented.
# 
#    Also note that applications supporting Internationalized Domain Names
#    SHALL use the ToASCII method [RFC3490] to produce <label> components
#    of the <domain> production.

# --------------------------------------------------------------------------
# 2.2.  associatedName
# 
#    The 'associatedName' attribute specifies names of entries in the
#    organizational DIT associated with a DNS domain [RFC1034][RFC2181].
# 

attributetype ( 0.9.2342.19200300.100.1.38
    NAME 'associatedName'
    EQUALITY distinguishedNameMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

# 
#    The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
#    'distinguishedNameMatch' rule are described in [RFC4517].
# 

# --------------------------------------------------------------------------
# 2.3.  buildingName
# 
#    The 'buildingName' attribute specifies names of the buildings where
#    an organization or organizational unit is based, for example, "The
#    White House".
# 

attributetype ( 0.9.2342.19200300.100.1.48
    NAME 'buildingName'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

Message of length 43072 truncated


Followup 2

Download message
Cc: Gavin Henry <openldap-its@OpenLDAP.org>
From: Kurt Zeilenga <Kurt@OpenLDAP.org>
To: michael@stroeder.com
Subject: Re: (ITS#6151) Update cosine.schema to RFC 4524
Date: Mon, 1 Jun 2009 06:02:24 -0700
On Jun 1, 2009, at 4:30 AM, michael@stroeder.com wrote:

> This is a multi-part message in MIME format.
> --------------080004030402080700020504
> Content-Type: text/plain; charset=3DISO-8859-1
> Content-Transfer-Encoding: 8bit
>
> Updated schema file cosine-update.schema attached.

I note that differs are generally preferred, even where the file is =20
mostly changed.  This helps ensure changes that others might make to =20
the file you started with are not lost.

> Note that some schema
> descriptions were copied from old cosine.schema to preserve backward
> compability since RFC 4524 does not contain all schema descriptions =20=

> e.g.
> needed for 'pilotPerson'. Note that 'pilotPerson' is used as superior
> class for 'OpenLDAPperson'. Also some aliases were added to NAME of
> attribute type descriptions.
>
> IPR notice:
> This patch file is derived from OpenLDAP Software and RFC 4524 and RFC
> 1274. All of the modifications to OpenLDAP Software represented in the
> attached file were developed by Michael Str=F6der =20
> <michael@stroeder.com>.
> I have not assigned rights and/or interest in this work to any party.

While this notice of origin is fine, you did not include a rights =20
statement.

>
>
> --------------080004030402080700020504
> Content-Type: text/plain;
> name=3D"cosine-update.schema"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
> filename=3D"cosine-update.schema"
>
> # RFC 4524: COSINE LDAP/X.500 Schema
> # $OpenLDAP: pkg/ldap/servers/slapd/schema/cosine.schema,v 1.26 =20
> 2009/01/21 23:40:40 kurt Exp $
> ## This work is part of OpenLDAP Software <http://www.openldap.org/>.
> ##
> ## Copyright 1998-2009 The OpenLDAP Foundation.
> ## All rights reserved.
> ##
> ## Redistribution and use in source and binary forms, with or without
> ## modification, are permitted only as authorized by the OpenLDAP
> ## Public License.
> ##
> ## A copy of this license is available in the file LICENSE in the
> ## top-level directory of the distribution or, alternatively, at
> ## <http://www.OpenLDAP.org/license.html>.
> #
> # RFC 4524: COSINE LDAP/X.500 Schema
> # This file is mainly based on the schema descriptions found in RFC =20=

> 4524.
> # To preserve backwards compability with 'pilotPerson' schema some =20
> attribute
> # types and object classes not declared in RFC 4524 were copied from
> # (obsoleted) RFC 1274 and some attribute type descriptions were =20
> extended
> # with aliases for NAME.
> #
> # Depends on core.schema
>
> # =20
> =
--------------------------------------------------------------------------=

> # 2.  COSINE Attribute Types
> # =20
> =
--------------------------------------------------------------------------=

> #
> #    This section details COSINE attribute types for use in LDAP.
> #
>
> # =20
> =
--------------------------------------------------------------------------=

> # 2.1.  associatedDomain
> #
> #    The 'associatedDomain' attribute specifies DNS [RFC1034][RFC2181]
> #    host names [RFC1123] that are associated with an object.   That =20=

> is,
> #    values of this attribute should conform to the following ABNF:
> #
> #     domain =3D root / label *( DOT label )
> #     root   =3D SPACE
> #     label  =3D LETDIG [ *61( LETDIG / HYPHEN ) LETDIG ]
> #     LETDIG =3D %x30-39 / %x41-5A / %x61-7A ; "0" - "9" / "A"-"Z" / =20=

> "a"-"z"
> #     SPACE  =3D %x20                        ; space (" ")
> #     HYPHEN =3D %x2D                        ; hyphen ("-")
> #     DOT    =3D %x2E                        ; period (".")
> #
> #    For example, the entry in the DIT with a DN
<DC=3Dexample,DC=3Dcom>=
 =20
> might
> #    have an associated domain of "example.com".
> #
> # (OpenLDAP-specific: Declared in core.schema)
> # attributetype ( 0.9.2342.19200300.100.1.37
> #     NAME 'associatedDomain'
> #     EQUALITY caseIgnoreIA5Match
> #     SUBSTR caseIgnoreIA5SubstringsMatch
> #     SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
> #
> #    The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the
> #    'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are
> #    described in [RFC4517].
> #
> #    Note that the directory will not ensure that values of this =20
> attribute
> #    conform to the <domain> production provided above.  It is the
> #    application's responsibility to ensure that domains it stores =20
> in this
> #    attribute are appropriately represented.
> #
> #    Also note that applications supporting Internationalized Domain =20=

> Names
> #    SHALL use the ToASCII method [RFC3490] to produce <label> =20
> components
> #    of the <domain> production.
>
> # 

Message of length 51337 truncated


Followup 3

Download message
Date: Mon, 08 Jun 2009 20:18:50 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
To: Kurt Zeilenga <Kurt@OpenLDAP.org>
CC: openldap-its@OpenLDAP.org
Subject: Re: (ITS#6151) Update cosine.schema to RFC 4524
Kurt Zeilenga wrote:
> 
> On Jun 1, 2009, at 4:30 AM, michael@stroeder.com wrote:
>> Updated schema file cosine-update.schema attached.
> 
> I note that differs are generally preferred, even where the file is
> mostly changed.  This helps ensure changes that others might make to the
> file you started with are not lost.

I thought about sending a diff but the file in this form is more
readable for easy review. Could someone please look at it whether that's ok?

Another approach would be to have two schema files, one which only
contains the schema descriptions from RFC 4524 and one with the missing
schema descriptions from RFC 1274 with the latter obviously being
dependent on the former.

>> IPR notice:
>> This patch file is derived from OpenLDAP Software and RFC 4524 and RFC
>> 1274. All of the modifications to OpenLDAP Software represented in the
>> attached file were developed by Michael Str.der
<michael@stroeder.com>.
>> I have not assigned rights and/or interest in this work to any party.
> 
> While this notice of origin is fine, you did not include a rights
> statement.

I, Michael Str.der, hereby place the modified schema file cosine.schema
attached to ITS#6151 (and only these modifications) into the public
domain. Hence, these modifications may be freely used and/or
redistributed for any purpose with or without attribution and/or other
notice.

Ciao, Michael.



Followup 4

Download message
Date: Thu, 22 Apr 2010 03:03:34 +0200 (CEST)
Subject: Re: (ITS#6151) Update cosine.schema to RFC 4524
From: masarati@aero.polimi.it
To: michael@stroeder.com, kurt@openldap.org
Cc: openldap-its@openldap.org
> Kurt Zeilenga wrote:
>>
>> On Jun 1, 2009, at 4:30 AM, michael@stroeder.com wrote:
>>> Updated schema file cosine-update.schema attached.
>>
>> I note that differs are generally preferred, even where the file is
>> mostly changed.  This helps ensure changes that others might make to
the
>> file you started with are not lost.
>
> I thought about sending a diff but the file in this form is more
> readable for easy review. Could someone please look at it whether that's
> ok?

> Another approach would be to have two schema files, one which only
> contains the schema descriptions from RFC 4524 and one with the missing
> schema descriptions from RFC 1274 with the latter obviously being
> dependent on the former.

I have one preliminary question for Kurt: since rfc4524 obsoletes rfc1274,
should those schema items that were not brought forward be marked as
OBSOLETE?  If yes, then all schema could fit in one file.  I'd like a
clear way to separate valid from obsolete schema.  The obsolete items
should be available for backwards compatibility.  As an alternative, I'd
like to have a "slim" (without obsolete) and a complete version of the
file.  Could you please upload the file?  Through the ITS attachments
don't work too well.

>>> IPR notice:
>>> This patch file is derived from OpenLDAP Software and RFC 4524 and
RFC
>>> 1274. All of the modifications to OpenLDAP Software represented in
the
>>> attached file were developed by Michael Str.der
<michael@stroeder.com>.
>>> I have not assigned rights and/or interest in this work to any
party.
>>
>> While this notice of origin is fine, you did not include a rights
>> statement.
>
> I, Michael Str.der, hereby place the modified schema file cosine.schema
> attached to ITS#6151 (and only these modifications) into the public
> domain. Hence, these modifications may be freely used and/or
> redistributed for any purpose with or without attribution and/or other
> notice.

Am I right in assuming this IPR is fine?  Thanks, p.



Followup 5

Download message
Subject: Re: (ITS#6151) Update cosine.schema to RFC 4524
From: Kurt Zeilenga <kurt@OpenLDAP.org>
Date: Wed, 21 Apr 2010 21:18:36 -0700
Cc: michael@stroeder.com, openldap-its@openldap.org
To: masarati@aero.polimi.it
On Apr 21, 2010, at 6:03 PM, masarati@aero.polimi.it wrote:

>> Kurt Zeilenga wrote:
>>>=20
>>> On Jun 1, 2009, at 4:30 AM, michael@stroeder.com wrote:
>>>> Updated schema file cosine-update.schema attached.
>>>=20
>>> I note that differs are generally preferred, even where the file is
>>> mostly changed.  This helps ensure changes that others might make
to =
the
>>> file you started with are not lost.
>>=20
>> I thought about sending a diff but the file in this form is more
>> readable for easy review. Could someone please look at it whether =
that's
>> ok?
>=20
>> Another approach would be to have two schema files, one which only
>> contains the schema descriptions from RFC 4524 and one with the =
missing
>> schema descriptions from RFC 1274 with the latter obviously being
>> dependent on the former.
>=20
> I have one preliminary question for Kurt: since rfc4524 obsoletes =
rfc1274,
> should those schema items that were not brought forward be marked as
> OBSOLETE?

obsoletes !=3D OBSOLETE, so no.   That is, the meaning of the term =
'obsolete' is quite different in these two contexts.

The latter context the term is defined as follows:
    The OBSOLETE field, if present, indicates the element is not active.

For user application attribute types, whether the type is active or not =
is, I think, best left to the schema administrator.  (Update operations =
upon an inactive element is limited to removal of the element.)

> If yes, then all schema could fit in one file.  I'd like a
> clear way to separate valid from obsolete schema.  The obsolete items
> should be available for backwards compatibility.  As an alternative, =
I'd
> like to have a "slim" (without obsolete) and a complete version of the
> file.

I rather no element be specified in multiple files.

> Could you please upload the file?  Through the ITS attachments
> don't work too well.
>=20
>>>> IPR notice:
>>>> This patch file is derived from OpenLDAP Software and RFC 4524
and =
RFC
>>>> 1274. All of the modifications to OpenLDAP Software represented
in =
the
>>>> attached file were developed by Michael Str=F6der =
<michael@stroeder.com>.
>>>> I have not assigned rights and/or interest in this work to any
=
party.
>>>=20
>>> While this notice of origin is fine, you did not include a rights
>>> statement.
>>=20
>> I, Michael Str=F6der, hereby place the modified schema file =
cosine.schema
>> attached to ITS#6151 (and only these modifications) into the public
>> domain. Hence, these modifications may be freely used and/or
>> redistributed for any purpose with or without attribution and/or =
other
>> notice.
>=20
> Am I right in assuming this IPR is fine?  Thanks, p.

Yes.  - Kurt



Followup 6

Download message
Date: Thu, 22 Apr 2010 10:33:37 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
To: Kurt Zeilenga <kurt@OpenLDAP.org>
CC: masarati@aero.polimi.it, openldap-its@OpenLDAP.org
Subject: Re: (ITS#6151) Update cosine.schema to RFC 4524
Kurt Zeilenga wrote:
> obsoletes != OBSOLETE, so no.   That is, the meaning of the term
> 'obsolete' is quite different in these two contexts.
> 
> The latter context the term is defined as follows: The OBSOLETE field, if
> present, indicates the element is not active.

I agree that OBSOLETE should not be set in this case.

> For user application attribute types, whether the type is active or not is,
> I think, best left to the schema administrator.

Who is the schema administrator? I'm nitpicking here because on the OpenLDAP
lists we all keep telling OpenLDAP admins not to mess with the standard schema
at all. IMO this includes setting OBSOLETE.

Ciao, Michael.



Followup 7

Download message
Date: Thu, 22 Apr 2010 15:26:28 +0200 (CEST)
Subject: Re: (ITS#6151) Update cosine.schema to RFC 4524
From: masarati@aero.polimi.it
To: Michael =?iso-8859-15?Q?Str=F6der?= <michael@stroeder.com>
Cc: "Kurt Zeilenga" <kurt@openldap.org>, openldap-its@openldap.org
> Kurt Zeilenga wrote:
>> obsoletes != OBSOLETE, so no.   That is, the meaning of the term
>> 'obsolete' is quite different in these two contexts.
>>
>> The latter context the term is defined as follows: The OBSOLETE field,
>> if
>> present, indicates the element is not active.
>
> I agree that OBSOLETE should not be set in this case.
>
>> For user application attribute types, whether the type is active or not
>> is,
>> I think, best left to the schema administrator.
>
> Who is the schema administrator? I'm nitpicking here because on the
> OpenLDAP
> lists we all keep telling OpenLDAP admins not to mess with the standard
> schema
> at all. IMO this includes setting OBSOLETE.

I Think there's a misunderstanding.  My understanding (and intention) is

1) You said you pulled in revisited cosine.schema also elements that were
dropped in RFC4524.

2) I was asking whether the fact they were dropped implied they were
OBSOLETE (i.e. had to be marked as OBSOLETE in their schema definition)

3) Kurt replied that they MUST NOT be marked as OBSOLETE.  Whether they
are loaded or not in a DSA's schema is at the DSA schema administrator's
choice

4) This, IMHO, implies that we need to provide two separate files, to
allow DSA admins to either load strict RFC4524 schema (no obsolete items)
or loose RFC4524 (entire RFC1274 schema).

Now, we have different options to arrange the resulting schema files
(names used below are only an example, the final name can be discussed
when there's consensus on the approach):

a) cosine.schema (== RFC1274)
   cosine4524.schema (== RFC4524)
   mutually exclusive (Kurt does not like this)

b) cosine4524.schema (== RFC4524)
   cosine.schema (== RFC1274 - RFC4524)
   the latter includes the former

c) cosine4524.schema (== RFC4524)
   cosine1274.schema (== RFC1274 - RFC4524)

(there might be more)

Cases (a) and (b) have advantages: loading cosine.schema loads all RFC1274
schema, thus existing configurations surely do not break.  I concur case
(a) would cause a lot of complaints from people loading all available
schema files and having conflicts.  Case (c) needs to modify
configuration, but avoids file nesting, if that's a problem at all.

p.




Followup 8

Download message
Subject: Re: (ITS#6151) Update cosine.schema to RFC 4524
From: Kurt Zeilenga <Kurt@OpenLDAP.org>
Date: Thu, 22 Apr 2010 06:55:38 -0700
Cc: openldap-its@OpenLDAP.org
To: michael@stroeder.com
On Apr 22, 2010, at 1:34 AM, michael@stroeder.com wrote:

> Kurt Zeilenga wrote:
>> obsoletes !=3D OBSOLETE, so no.   That is, the meaning of the term
>> 'obsolete' is quite different in these two contexts.
>>=20
>> The latter context the term is defined as follows: The OBSOLETE =
field, if
>> present, indicates the element is not active.
>=20
> I agree that OBSOLETE should not be set in this case.
>=20
>> For user application attribute types, whether the type is active or =
not is,
>> I think, best left to the schema administrator.
>=20
> Who is the schema administrator?

Generally speaking, the OpenLDAP admin administrates which schema =
elements to load into the schema and whether each such element is active =
and inactive.

While in some cases a schema admin might design schema elements, I =
consider schema admin and schema element designer to be two separate =
roles.

> I'm nitpicking here because on the OpenLDAP
> lists we all keep telling OpenLDAP admins not to mess with the =
standard schema
> at all.

We often advise admins to load various schema elements into their =
schemas.  We generally assume admins run have only active elements in =
the their schema as the need for inactive elements can generally be =
avoided.

When at I say "don't mess with standard schema elements", what I mean is =
don't change aspects of schema specifications which are consider per the =
technical specifications to be immutable on published in a technical =
specification (or otherwise broadly published).  There certainly are =
other changes one can make to standard schema elements without violating =
the technical specifications (e.g., changing the DESC value), and if =
such case were to arise more generally, I might be more precise in my =
general advice.  That is, I rather only raise exceptions in advice when =
it's actually applicable to the situation raised by the admin.

-- Kurt=



Followup 9

Download message
Date: Thu, 22 Apr 2010 06:55:04 -0700
From: Howard Chu <hyc@symas.com>
To: masarati@aero.polimi.it
CC: openldap-its@openldap.org
Subject: Re: (ITS#6151) Update cosine.schema to RFC 4524
masarati@aero.polimi.it wrote:
> 4) This, IMHO, implies that we need to provide two separate files, to
> allow DSA admins to either load strict RFC4524 schema (no obsolete items)
> or loose RFC4524 (entire RFC1274 schema).
>
> Now, we have different options to arrange the resulting schema files
> (names used below are only an example, the final name can be discussed
> when there's consensus on the approach):
>
> a) cosine.schema (== RFC1274)
>     cosine4524.schema (== RFC4524)
>     mutually exclusive (Kurt does not like this)
>
> b) cosine4524.schema (== RFC4524)
>     cosine.schema (== RFC1274 - RFC4524)
>     the latter includes the former
>
> c) cosine4524.schema (== RFC4524)
>     cosine1274.schema (== RFC1274 - RFC4524)
>
> (there might be more)

Yes, cosine.schema wrapping cosine4524.schema and cosine1274.schema might be
best.

> Cases (a) and (b) have advantages: loading cosine.schema loads all RFC1274
> schema, thus existing configurations surely do not break.  I concur case
> (a) would cause a lot of complaints from people loading all available
> schema files and having conflicts.  Case (c) needs to modify
> configuration, but avoids file nesting, if that's a problem at all.

File nesting has some implications in cn=config, which is why I made the above 
suggestion.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 10

Download message
Date: Thu, 22 Apr 2010 18:58:38 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
To: Kurt Zeilenga <Kurt@OpenLDAP.org>
CC: openldap-its@OpenLDAP.org
Subject: Re: (ITS#6151) Update cosine.schema to RFC 4524
Kurt Zeilenga wrote:
> 
> On Apr 22, 2010, at 1:34 AM, michael@stroeder.com wrote:
> 
>> Kurt Zeilenga wrote:
>>> obsoletes != OBSOLETE, so no.   That is, the meaning of the term
>>> 'obsolete' is quite different in these two contexts.
>>>
>>> The latter context the term is defined as follows: The OBSOLETE
field, if
>>> present, indicates the element is not active.
>>
>> I agree that OBSOLETE should not be set in this case.
>>
>>> For user application attribute types, whether the type is active or
not is,
>>> I think, best left to the schema administrator.
>>
>> Who is the schema administrator?
> 
> Generally speaking, the OpenLDAP admin administrates which schema elements
> to load into the schema and whether each such element is active and
> inactive.

What does "active and inactive" mean exactly? Does that include changing the
OBSOLETE keyword in schema files? I hope not...

> While in some cases a schema admin might design schema elements, I consider
> schema admin and schema element designer to be two separate roles.

Agreed.

>> I'm nitpicking here because on the OpenLDAP
>> lists we all keep telling OpenLDAP admins not to mess with the standard
schema
>> at all.
> 
> We often advise admins to load various schema elements into their schemas.

The role for loading the shipped schema files is not the question here.

> When at I say "don't mess with standard schema elements", what I mean is
> don't change aspects of schema specifications which are consider per the
> technical specifications to be immutable on published in a technical
> specification (or otherwise broadly published).

Does "immutable" include OBSOLETE? I hope so...

Ciao, Michael.



Followup 11

Download message
Subject: Re: (ITS#6151) Update cosine.schema to RFC 4524
From: Kurt Zeilenga <Kurt@OpenLDAP.org>
Date: Thu, 22 Apr 2010 10:20:46 -0700
Cc: openldap-its@OpenLDAP.org
To: =?iso-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
On Apr 22, 2010, at 9:58 AM, Michael Str=F6der wrote:

> Kurt Zeilenga wrote:
>>=20
>> On Apr 22, 2010, at 1:34 AM, michael@stroeder.com wrote:
>>=20
>>> Kurt Zeilenga wrote:
>>>> obsoletes !=3D OBSOLETE, so no.   That is, the meaning of the
term
>>>> 'obsolete' is quite different in these two contexts.
>>>>=20
>>>> The latter context the term is defined as follows: The OBSOLETE
=
field, if
>>>> present, indicates the element is not active.
>>>=20
>>> I agree that OBSOLETE should not be set in this case.
>>>=20
>>>> For user application attribute types, whether the type is
active or =
not is,
>>>> I think, best left to the schema administrator.
>>>=20
>>> Who is the schema administrator?
>>=20
>> Generally speaking, the OpenLDAP admin administrates which schema =
elements
>> to load into the schema and whether each such element is active and
>> inactive.
>=20
> What does "active and inactive" mean exactly? Does that include =
changing the
> OBSOLETE keyword in schema files? I hope not...

The purpose of the OBSOLETE (inactive) flag is to support transition =
away from a particular schema element.  Basically, if one no longer =
wants to use the attribute type 'x' in their directory, they should 1) =
mark x as inactive in the subschema, 2) then remove all uses of x, 3) =
then remove x from the subschema.

The directory prevents all non-removal updates to inactive elements, =
allowing 2 to be well performed.

>=20
>> While in some cases a schema admin might design schema elements, I =
consider
>> schema admin and schema element designer to be two separate roles.
>=20
> Agreed.
>=20
>>> I'm nitpicking here because on the OpenLDAP
>>> lists we all keep telling OpenLDAP admins not to mess with the =
standard schema
>>> at all.
>>=20
>> We often advise admins to load various schema elements into their =
schemas.
>=20
> The role for loading the shipped schema files is not the question =
here.
>=20
>> When at I say "don't mess with standard schema elements", what I mean =
is
>> don't change aspects of schema specifications which are consider per =
the
>> technical specifications to be immutable on published in a technical
>> specification (or otherwise broadly published).
>=20
> Does "immutable" include OBSOLETE? I hope so...

OBSOLETE is one of the mutable properties of a schema element (because =
otherwise it couldn't support local movements away from arbitrary schema =
elements).

-- Kurt

>=20
> Ciao, Michael.



Followup 12

Download message
Subject: Re: (ITS#6151) Update cosine.schema to RFC 4524
From: Kurt Zeilenga <Kurt@OpenLDAP.org>
Date: Thu, 22 Apr 2010 11:45:12 -0700
Cc: openldap-its@OpenLDAP.org
To: =?iso-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
On Apr 22, 2010, at 10:20 AM, Kurt Zeilenga wrote:

> The purpose of the OBSOLETE (inactive) flag is to support transition =
away from a particular schema element.  Basically, if one no longer =
wants to use the attribute type 'x' in their directory, they should 1) =
mark x as inactive in the subschema, 2) then remove all uses of x, 3) =
then remove x from the subschema.

One additional note, I generally would advise that a schema-aware client =
not alter it's update behavior of elements based upon whether said =
elements are active or inactive (OBSOLETE) in the schema.  Instead, they =
should just try the update and, if it fails, report it as they normally =
would.  Handling the inactive condition locally hides the error from the =
directory administrator, who is likely relying on directory server logs =
to find applications which using inactive schema.  He may well not have =
access to all the clients' logs.

-- Kurt=



Followup 13

Download message
Date: Thu, 22 Apr 2010 23:58:23 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
To: Kurt Zeilenga <Kurt@OpenLDAP.org>
CC: openldap-its@OpenLDAP.org
Subject: Re: (ITS#6151) Update cosine.schema to RFC 4524
Kurt Zeilenga wrote:
> One additional note, I generally would advise that a schema-aware client
> not alter it's update behavior of elements based upon whether said elements
> are active or inactive (OBSOLETE) in the schema. 

I disagree especially for cases when new data is added.

> Instead, they should just
> try the update and, if it fails, report it as they normally would.

Modifying existing data I first have to think about...

> Handling the inactive condition locally hides the error from the directory 
> administrator, who is likely relying on directory server logs to find 
> applications which using inactive schema.

Hmm, that's not the case with a schema-aware client anyway which guides the
user *not* to use OBSOLETE schema elements. You're likely talking about
detecting pre-configured applications with hard-coded use of OBSOLETE object
classes and attribute types. Most times these are not schema-aware at all.

Ciao, Michael.



Followup 14

Download message
Subject: Re: (ITS#6151) Update cosine.schema to RFC 4524
From: Kurt Zeilenga <Kurt@OpenLDAP.org>
Date: Thu, 22 Apr 2010 15:27:06 -0700
Cc: openldap-its@OpenLDAP.org
To: =?iso-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
On Apr 22, 2010, at 2:58 PM, Michael Str=F6der wrote:

> Kurt Zeilenga wrote:
>> One additional note, I generally would advise that a schema-aware =
client
>> not alter it's update behavior of elements based upon whether said =
elements
>> are active or inactive (OBSOLETE) in the schema.=20
>=20
> I disagree especially for cases when new data is added.

I think you're trying to make the client far smarter than it really =
ought to be.

If the clients configured to place say place element of data in =
attribute x, it shouldn't try to put it elsewhere.  It should fail.

While certainly one could design a client such as it could be configured =
with fallbacks for attributes, and fallback for fallbacks, etc., this is =
an unnecessarily complication IMO.

Also, note that were a client to attempt the above, it could still fail =
due to an element being marked inactive between the time it read the =
schema and the time it tried the DIT update.   Of course, one could =
complicate the client further by trying to handle this as well.

>=20
>> Instead, they should just
>> try the update and, if it fails, report it as they normally would.
>=20
> Modifying existing data I first have to think about...
>=20
>> Handling the inactive condition locally hides the error from the =
directory=20
>> administrator, who is likely relying on directory server logs to
find=20=

>> applications which using inactive schema.
>=20
> Hmm, that's not the case with a schema-aware client anyway which =
guides the
> user *not* to use OBSOLETE schema elements.

I generally assume the user is not selecting which attribute to store =
some piece of information into.  I assume the client been programmed to =
collect a piece of information and configured (or programmed) where to =
store it.

The client you refer to is what I would call an application-neutral LDAP =
directory administration tool.  For such a tool, it might be reasonable =
to warn the user (whose generally an "administrator" of some sort as =
opposed to a "normal" user).
=20
> You're likely talking about
> detecting pre-configured applications with hard-coded use of OBSOLETE =
object
> classes and attribute types.
> Most times these are not schema-aware at all.

Well, pre-configured applications may be schema-aware but maybe not as =
fully as an LDAP directory administration tool might be.  They might =
check that the element they were configured to use is appropriate for =
that use by examining its specification in the subschema.

-- Kurt=


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org