From ldapext-bounces@ietf.org  Fri Apr  1 02:57:47 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23841
	for <ldapext-archive@lists.ietf.org>; Fri, 1 Apr 2005 02:57:47 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DHH1G-0000CT-8M; Fri, 01 Apr 2005 02:56:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DHH1E-0000BJ-CB
	for ldapext@megatron.ietf.org; Fri, 01 Apr 2005 02:56:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23753
	for <ldapext@ietf.org>; Fri, 1 Apr 2005 02:56:39 -0500 (EST)
Received: from lucius.provo.novell.com ([137.65.81.172])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHH8U-0006j3-Q6
	for ldapext@ietf.org; Fri, 01 Apr 2005 03:04:12 -0500
Received: from INET-PRV1-MTA by lucius.provo.novell.com
	with Novell_GroupWise; Fri, 01 Apr 2005 00:56:27 -0700
Message-Id: <s24c9c3b.049@lucius.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 6.5.4 Beta
Date: Fri, 01 Apr 2005 00:01:33 -0700
From: "Vithalprasad Gaitonde" <gvithalprasad@novell.com>
To: <ldapext@ietf.org>, <Kurt@OpenLDAP.org>
Mime-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Subject: [ldapext] RFC 3062 section 2.1 and section 3
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0363677641=="
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--===============0363677641==
Content-Type: multipart/alternative; boundary="=__Part4A6949DD.0__="

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part4A6949DD.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Kurt,
This section says:
A Password Modify request is an ExtendedRequest with the requestName
field containing passwdModifyOID OID and optionally provides a
requestValue field.
The rfc does not specify what is the expected server behaviour when the
extension contains only the passwdModifyOID and no value.
My guess is that this will cause the server to generate a password for
the identity which is currently bound on the connection on which the
request was recieved and hence the server is required to return the
generated password in the extended response.
 
Also in section 2, the rfc says:
   If oldPasswd is present and the provided value cannot be verified
or
   is incorrect, the server SHALL NOT change the user password. 
 
In this case, what is the LDAP error that the server should send bac to
the client.
 
Prasad

--=__Part4A6949DD.0__=
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"=
>
<META content=3D"MSHTML 6.00.2800.1491" name=3DGENERATOR></HEAD>
<BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<DIV>Kurt,<BR>This section says:<BR>A Password Modify request is an=20
ExtendedRequest with the requestName<BR>field containing passwdModifyOID =
OID and=20
<STRONG>optionally</STRONG> provides a<BR>requestValue field.<BR>The rfc =
does=20
not specify what is the expected server behaviour when the extension =
contains=20
only the passwdModifyOID and no value.</DIV>
<DIV>My guess is that this will cause the server to generate a password =
for the=20
identity which is currently bound on the connection on which the request =
was=20
recieved and hence the server is required to return the generated password =
in=20
the extended response.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Also in section 2, the rfc says:</DIV>
<DIV>&nbsp;&nbsp; If oldPasswd is present and the provided value cannot =
be=20
verified or<BR>&nbsp;&nbsp; is incorrect, the server SHALL NOT change the =
user=20
password. </DIV>
<DIV>&nbsp;</DIV>
<DIV>In this case, what is the LDAP error that the server should send bac =
to the=20
client.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Prasad</DIV></BODY></HTML>

--=__Part4A6949DD.0__=--


--===============0363677641==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext

--===============0363677641==--



From ldapext-bounces@ietf.org  Fri Apr  1 04:09:27 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04558
	for <ldapext-archive@lists.ietf.org>; Fri, 1 Apr 2005 04:09:26 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DHI83-00039y-W6; Fri, 01 Apr 2005 04:07:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DHI7z-00038D-Mz
	for ldapext@megatron.ietf.org; Fri, 01 Apr 2005 04:07:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04493
	for <ldapext@ietf.org>; Fri, 1 Apr 2005 04:07:41 -0500 (EST)
Received: from boole.openldap.org ([204.152.186.50] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHIFG-00015S-Is
	for ldapext@ietf.org; Fri, 01 Apr 2005 04:15:15 -0500
Received: from gyspy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net
	[24.205.218.53]) (authenticated bits=0)
	by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j3197bi2055669
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 1 Apr 2005 09:07:37 GMT (envelope-from Kurt@OpenLDAP.org)
Message-Id: <6.2.1.2.0.20050401005135.0346bbc0@mail.openldap.org>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Fri, 01 Apr 2005 01:07:15 -0800
To: "Vithalprasad Gaitonde" <gvithalprasad@novell.com>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: [ldapext] RFC 3062 section 2.1 and section 3
In-Reply-To: <s24c9c3b.049@lucius.provo.novell.com>
References: <s24c9c3b.049@lucius.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: ldapext@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org

At 11:01 PM 3/31/2005, Vithalprasad Gaitonde wrote:
>Kurt,
>This section says:
>A Password Modify request is an ExtendedRequest with the requestName
>field containing passwdModifyOID OID and optionally provides a
>requestValue field.
>The rfc does not specify what is the expected server behaviour when the extension contains only the passwdModifyOID and no value.

If no control value is present, then no PasswdModifyRequestValue
is present, and hence, none of its fields are present.

>My guess is that this will cause the server to generate a password for the identity which is currently bound on the connection on which the request was recieved and hence the server is required to return the generated password in the extended response.

Well, more precisely, the message requests the server generate
a password for the current user.  The server is not required to
do so, it return an error if its unwilling or unable to provide
the requested service.

>Also in section 2, the rfc says:
>   If oldPasswd is present and the provided value cannot be verified or
>   is incorrect, the server SHALL NOT change the user password. 
> 
>In this case, what is the LDAP error that the server should send bac to the client.

The specification prescribes an appropriate resultCode.
If the server is busy, then returning busy might be
appropriate.  But if the password is invalid,
then invalidCredentials would be appropriate.

> 
>Prasad
>_______________________________________________
>Ldapext mailing list
>Ldapext@ietf.org
>https://www1.ietf.org/mailman/listinfo/ldapext


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Tue Apr  5 23:19:14 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17196
	for <ldapext-archive@lists.ietf.org>; Tue, 5 Apr 2005 23:19:14 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJ13X-0007df-8x; Tue, 05 Apr 2005 23:18:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ13V-0007dV-AO
	for ldapext@megatron.ietf.org; Tue, 05 Apr 2005 23:18:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17097
	for <ldapext@ietf.org>; Tue, 5 Apr 2005 23:18:10 -0400 (EDT)
Received: from boole.openldap.org ([204.152.186.50] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ1Bk-0002LU-Cd
	for ldapext@ietf.org; Tue, 05 Apr 2005 23:26:45 -0400
Received: from gyspy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net
	[24.205.218.53]) (authenticated bits=0)
	by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j363I8Vt054475
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Apr 2005 03:18:09 GMT (envelope-from Kurt@OpenLDAP.org)
Message-Id: <6.2.1.2.0.20050405201247.054e2328@mail.openldap.org>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Tue, 05 Apr 2005 20:17:44 -0700
To: ldapext@ietf.org
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: ietf-ldapbis@OpenLDAP.org
Subject: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-cosine-00.txt
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org

This I-D is primarily an update of RFC 1274.  With
LDAPBIS's user-schema I-D, and a soon to be submitted
zeilenga-ldap-domains, replaces RFC 2247 as well.
(I'm thinking about 2377bis as well.)

My intent is to submit this for publication in conjunction
with the revised LDAP TS being produced by the LDAPBIS
WG.  Please review.  Technical comments to <ldapext@ietf.org>
and editorial comments to <kurt@openldap.org>.

Thanks, Kurt

>To: i-d-announce@ietf.org
>From: Internet-Drafts@ietf.org
>Date: Tue, 05 Apr 2005 15:29:59 -0400
>Subject: I-D ACTION:draft-zeilenga-ldap-cosine-00.txt
>Reply-To: internet-drafts@ietf.org
>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>        Title           : COSINE LDAP/X.500 Schema
>        Author(s)       : K. Zeilenga
>        Filename        : draft-zeilenga-ldap-cosine-00.txt
>        Pages           : 25
>        Date            : 2005-4-5
>        
>This document provides a collection of schema elements for use with
>  the Lightweight Directory Access Protocol (LDAP) from the COSINE and
>  Internet X.500 pilot projects.
>
>  This document obsoletes RFC 1274 and RFC 2247.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-cosine-00.txt
>
>To remove yourself from the I-D Announcement list, send a message to 
>i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
>to change your subscription settings.
>
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>        "get draft-zeilenga-ldap-cosine-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html 
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>        mailserv@ietf.org.
>In the body type:
>        "FILE /internet-drafts/draft-zeilenga-ldap-cosine-00.txt".
>        
>NOTE:   The mail server at ietf.org can return the document in
>        MIME-encoded form by using the "mpack" utility.  To use this
>        feature, insert the command "ENCODING mime" before the "FILE"
>        command.  To decode the response(s), you will need "munpack" or
>        a MIME-compliant mail reader.  Different MIME-compliant mail readers
>        exhibit different behavior, especially when dealing with
>        "multipart" MIME messages (i.e. documents which have been split
>        up into multiple messages), so check your local documentation on
>        how to manipulate these messages.
>                
>                
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>Content-Type: text/plain
>Content-ID: <2005-4-5160053.I-D@ietf.org>
>
>ENCODING mime
>FILE /internet-drafts/draft-zeilenga-ldap-cosine-00.txt
>
>
><ftp://ftp.ietf.org/internet-drafts/draft-zeilenga-ldap-cosine-00.txt>
>_______________________________________________
>I-D-Announce mailing list
>I-D-Announce@ietf.org
>https://www1.ietf.org/mailman/listinfo/i-d-announce


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Thu Apr 14 08:23:09 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06028
	for <ldapext-archive@lists.ietf.org>; Thu, 14 Apr 2005 08:23:09 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DM3HP-000552-G0; Thu, 14 Apr 2005 08:17:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DM3HN-00054a-Gb
	for ldapext@megatron.ietf.org; Thu, 14 Apr 2005 08:17:05 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05362
	for <ldapext@ietf.org>; Thu, 14 Apr 2005 08:16:56 -0400 (EDT)
Received: from lucius.provo.novell.com ([137.65.81.172])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM3RD-0004KE-NJ
	for ldapext@ietf.org; Thu, 14 Apr 2005 08:27:17 -0400
Received: from INET-PRV1-MTA by lucius.provo.novell.com
	with Novell_GroupWise; Thu, 14 Apr 2005 06:16:46 -0600
Message-Id: <s25e0ace.036@lucius.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 6.5.4 Beta
Date: Thu, 14 Apr 2005 06:16:14 -0600
From: "Vithalprasad Gaitonde" <gvithalprasad@novell.com>
To: <hyc@highlandsun.com>
Subject: Re: [ldapext] referencing one LDIF file from another
Mime-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1
Cc: ldapext@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1287454946=="
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--===============1287454946==
Content-Type: multipart/alternative; boundary="=__Part3516241E.1__="

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part3516241E.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Howard,
Following is the change we could do to section "Formal Syntax
Definition of LDIF"

included-ldif-file-content = "include:" FILL fileName
;where the contents of filename confirm to ldif-file of type
ldif-content

included-ldif-file-content = "include:" FILL fileName
;where the contents of filename confirm to ldif-file of type
ldif-changes

included-content-ldifs = 1*(1*SEP included-ldif-file-content)

included-changes-ldifs = 1*(1*SEP included-ldif-file-changes)

ldif-file = ldif-content / ldif-changes / included-content-ldifs /
included-changes-ldifs 

ldif-content = version-spec included-content-ldifs 1*(1*SEP
ldif-attrval-record)

ldif-changes = version-spec included-changes-ldifs 1*(1*SEP
ldif-change-record)

Let me know what you think.

Thanks,
Prasad

>>> Howard Chu <hyc@highlandsun.com> 11/23/2004 12:33:06 PM >>>
Vithalprasad Gaitonde wrote:
> RFC2849 doesnt seem to provide a way to include one ldif file into
> another ldif file though it does allow referencing an external file
for
> an attribute value.
> Has this been considered in the past ? 
> It seems like a useful thing to have when there are dependencies
across
> several ldif files.

I agree, I would definitely have a use for this. Haven't thought about

what the syntax should be yet.

-- 
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc 
Symas: Premier OpenSource Development and Support

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org 
https://www1.ietf.org/mailman/listinfo/ldapext 


--=__Part3516241E.1__=
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"=
>
<META content=3D"MSHTML 6.00.2800.1491" name=3DGENERATOR></HEAD>
<BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<DIV>Howard,<BR>Following is the change we could do to section "<STRONG>For=
mal=20
Syntax Definition of LDIF"<BR></STRONG><BR>included-ldif-file-content =
=3D=20
"include:" FILL fileName<BR>;where the contents of filename confirm to =
ldif-file=20
of type ldif-content<BR><BR>included-ldif-file-content =3D "include:" =
FILL=20
fileName<BR>;where the contents of filename confirm to ldif-file of =
type=20
ldif-changes<BR></DIV>
<DIV>included-content-ldifs =3D 1*(1*SEP=20
included-ldif-file-content)<BR><BR>included-changes-ldifs =3D 1*(1*SEP=20
included-ldif-file-changes)<BR><BR>ldif-file =3D ldif-content / ldif-change=
s /=20
included-content-ldifs / included-changes-ldifs <BR><BR>ldif-content =
=3D=20
version-spec included-content-ldifs 1*(1*SEP=20
ldif-attrval-record)<BR><BR>ldif-changes =3D version-spec included-changes-=
ldifs=20
1*(1*SEP ldif-change-record)<BR></DIV>
<DIV>Let me know what you think.</DIV>
<DIV><BR>Thanks,</DIV>
<DIV>Prasad<BR><BR>&gt;&gt;&gt; Howard Chu &lt;hyc@highlandsun.com&gt;=20
11/23/2004 12:33:06 PM &gt;&gt;&gt;<BR>Vithalprasad Gaitonde wrote:<BR>&gt;=
=20
RFC2849 doesnt seem to provide a way to include one ldif file into<BR>&gt;=
=20
another ldif file though it does allow referencing an external file =
for<BR>&gt;=20
an attribute value.<BR>&gt; Has this been considered in the past ? =
<BR>&gt; It=20
seems like a useful thing to have when there are dependencies across<BR>&gt=
;=20
several ldif files.<BR><BR>I agree, I would definitely have a use for =
this.=20
Haven't thought about <BR>what the syntax should be yet.<BR><BR>-- <BR>-- =
Howard=20
Chu<BR>Chief Architect, Symas Corp. Director, Highland Sun<BR><U><A=20
href=3D"http://www.symas.com">http://www.symas.com</A></U> <U><A=20
href=3D"http://highlandsun.com/hyc">http://highlandsun.com/hyc</A></U> =
<BR>Symas:=20
Premier OpenSource Development and=20
Support<BR><BR>_______________________________________________<BR>Ldapext=
=20
mailing list<BR><U><A href=3D"mailto:Ldapext@ietf.org">Ldapext@ietf.org</A>=
</U>=20
<BR><U><A=20
href=3D"https://www1.ietf.org/mailman/listinfo/ldapext">https://www1.ietf.o=
rg/mailman/listinfo/ldapext</A></U>=20
<BR></DIV></BODY></HTML>

--=__Part3516241E.1__=--


--===============1287454946==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext

--===============1287454946==--



From ldapext-bounces@ietf.org  Thu Apr 14 09:06:14 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09396
	for <ldapext-archive@lists.ietf.org>; Thu, 14 Apr 2005 09:06:14 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DM3va-0002l0-Kj; Thu, 14 Apr 2005 08:58:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DM3vY-0002jl-Mj
	for ldapext@megatron.ietf.org; Thu, 14 Apr 2005 08:58:36 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08780
	for <ldapext@ietf.org>; Thu, 14 Apr 2005 08:58:27 -0400 (EDT)
Received: from highlandsun.propagation.net ([66.221.212.168])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM45P-00064F-9z
	for ldapext@ietf.org; Thu, 14 Apr 2005 09:08:48 -0400
Received: from [127.0.0.1] (highlandsun.com [66.221.212.169])
	by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id
	j3ECwJYP031959; Thu, 14 Apr 2005 06:58:20 -0600
Message-ID: <425E68F6.4020702@highlandsun.com>
Date: Thu, 14 Apr 2005 05:58:30 -0700
From: Howard Chu <hyc@highlandsun.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.8b2) Gecko/20050401
MIME-Version: 1.0
To: Vithalprasad Gaitonde <gvithalprasad@novell.com>
Subject: Re: [ldapext] referencing one LDIF file from another
References: <s25e0ace.035@lucius.provo.novell.com>
In-Reply-To: <s25e0ace.035@lucius.provo.novell.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: 7bit
Cc: ldapext@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
Content-Transfer-Encoding: 7bit

What do you think about using a URL here instead of a simple filename? 
For the common case it would usually be a FILE URL but I think we gain 
some future-proofing by making it fully hyperlinked. It may not be 
useful for utilities that just expect to process static data, but I have 
in mind to use LDAP URLs here as well.

Vithalprasad Gaitonde wrote:
> Howard,
> Following is the change we could do to section "*Formal Syntax 
> Definition of LDIF"
> *
> included-ldif-file-content = "include:" FILL fileName
> ;where the contents of filename confirm to ldif-file of type ldif-content
> 
> included-ldif-file-content = "include:" FILL fileName
> ;where the contents of filename confirm to ldif-file of type ldif-changes
> included-content-ldifs = 1*(1*SEP included-ldif-file-content)
> 
> included-changes-ldifs = 1*(1*SEP included-ldif-file-changes)
> 
> ldif-file = ldif-content / ldif-changes / included-content-ldifs / 
> included-changes-ldifs
> 
> ldif-content = version-spec included-content-ldifs 1*(1*SEP 
> ldif-attrval-record)
> 
> ldif-changes = version-spec included-changes-ldifs 1*(1*SEP 
> ldif-change-record)
> Let me know what you think.
> 
> Thanks,
> Prasad
> 
>  >>> Howard Chu <hyc@highlandsun.com> 11/23/2004 12:33:06 PM >>>
> Vithalprasad Gaitonde wrote:
>  > RFC2849 doesnt seem to provide a way to include one ldif file into
>  > another ldif file though it does allow referencing an external file for
>  > an attribute value.
>  > Has this been considered in the past ?
>  > It seems like a useful thing to have when there are dependencies across
>  > several ldif files.
> 
> I agree, I would definitely have a use for this. Haven't thought about
> what the syntax should be yet.

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.       Director, Highland Sun
   http://www.symas.com               http://highlandsun.com/hyc
   Symas: Premier OpenSource Development and Support

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Thu Apr 14 09:45:25 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12380
	for <ldapext-archive@lists.ietf.org>; Thu, 14 Apr 2005 09:45:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DM4dn-0002S1-QF; Thu, 14 Apr 2005 09:44:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DM4dl-0002R5-Hb
	for ldapext@megatron.ietf.org; Thu, 14 Apr 2005 09:44:19 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12248
	for <ldapext@ietf.org>; Thu, 14 Apr 2005 09:44:07 -0400 (EDT)
Received: from lucius.provo.novell.com ([137.65.81.172])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM4nd-0007uz-3t
	for ldapext@ietf.org; Thu, 14 Apr 2005 09:54:29 -0400
Received: from INET-PRV1-MTA by lucius.provo.novell.com
	with Novell_GroupWise; Thu, 14 Apr 2005 07:43:59 -0600
Message-Id: <s25e1f3f.039@lucius.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 6.5.4 Beta
Date: Thu, 14 Apr 2005 07:43:35 -0600
From: "Vithalprasad Gaitonde" <gvithalprasad@novell.com>
To: <hyc@highlandsun.com>
Subject: Re: [ldapext] referencing one LDIF file from another
Mime-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407
Cc: ldapext@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0836115179=="
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--===============0836115179==
Content-Type: multipart/alternative; boundary="=__Part90B38197.1__="

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part90B38197.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Good point, Howard.
Here's another try: Does this work for you ?

included-ldif-file-content = "include:" FILL url
;where the url points to a file which confirms to ldif-file of type
ldif-content

included-ldif-file-content = "include:" FILL url
;where the url points to a file which confirms to ldif-file of type
ldif-changes

ldif-file = ldif-content / ldif-changes / included-content-ldifs

included-content-ldifs = 1*(1*SEP included-ldif-file-content)

included-changes-ldifs = 1*(1*SEP included-ldif-file-changes)

ldif-content = version-spec included-content-ldifs 1*(1*SEP
ldif-attrval-record)

ldif-changes = version-spec included-changes-ldifs 1*(1*SEP
ldif-change-record)

Prasad

>>> Howard Chu <hyc@highlandsun.com> 04/14/05 6:28 PM >>>
What do you think about using a URL here instead of a simple filename?

For the common case it would usually be a FILE URL but I think we gain

some future-proofing by making it fully hyperlinked. It may not be 
useful for utilities that just expect to process static data, but I
have 
in mind to use LDAP URLs here as well.

Vithalprasad Gaitonde wrote:
> Howard,
> Following is the change we could do to section "*Formal Syntax 
> Definition of LDIF"
> *
> included-ldif-file-content = "include:" FILL fileName
> ;where the contents of filename confirm to ldif-file of type
ldif-content
> 
> included-ldif-file-content = "include:" FILL fileName
> ;where the contents of filename confirm to ldif-file of type
ldif-changes
> included-content-ldifs = 1*(1*SEP included-ldif-file-content)
> 
> included-changes-ldifs = 1*(1*SEP included-ldif-file-changes)
> 
> ldif-file = ldif-content / ldif-changes / included-content-ldifs / 
> included-changes-ldifs
> 
> ldif-content = version-spec included-content-ldifs 1*(1*SEP 
> ldif-attrval-record)
> 
> ldif-changes = version-spec included-changes-ldifs 1*(1*SEP 
> ldif-change-record)
> Let me know what you think.
> 
> Thanks,
> Prasad
> 
> >>> Howard Chu < hyc@highlandsun.com > 11/23/2004 12:33:06 PM >>>
> Vithalprasad Gaitonde wrote:
> > RFC2849 doesnt seem to provide a way to include one ldif file into
> > another ldif file though it does allow referencing an external file
for
> > an attribute value.
> > Has this been considered in the past ?
> > It seems like a useful thing to have when there are dependencies
across
> > several ldif files.
> 
> I agree, I would definitely have a use for this. Haven't thought
about
> what the syntax should be yet.

-- 
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc 
Symas: Premier OpenSource Development and Support

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org 
https://www1.ietf.org/mailman/listinfo/ldapext 

--=__Part90B38197.1__=
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"=
>
<META content=3D"MSHTML 6.00.2900.2604" name=3DGENERATOR></HEAD>
<BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">Good point, =
Howard.<BR>Here's another try: Does this work for you ?<BR><BR>included-ldi=
f-file-content =3D "include:" FILL url<BR>;<STRONG>where the url points to =
a file which confirms to ldif-file of type ldif-content<BR></STRONG><BR>inc=
luded-ldif-file-content =3D "include:" FILL url<BR>;<STRONG>where the url =
points to a file which confirms to ldif-file of type ldif-changes<BR></STRO=
NG><BR>ldif-file =3D ldif-content / ldif-changes / included-content-ldifs<B=
R><BR>included-content-ldifs =3D 1*(1*SEP included-ldif-file-content)<BR><B=
R>included-changes-ldifs =3D 1*(1*SEP included-ldif-file-changes)<BR><BR>ld=
if-content =3D version-spec included-content-ldifs 1*(1*SEP ldif-attrval-re=
cord)<BR><BR>ldif-changes =3D version-spec included-changes-ldifs 1*(1*SEP =
ldif-change-record)<BR><BR>Prasad<BR><BR>&gt;&gt;&gt; Howard Chu &lt;hyc@hi=
ghlandsun.com&gt; 04/14/05 6:28 PM &gt;&gt;&gt;<BR>What do you think about =
using a URL here instead of a simple filename? <BR>For the common case it =
would usually be a FILE URL but I think we gain <BR>some future-proofing =
by making it fully hyperlinked. It may not be <BR>useful for utilities =
that just expect to process static data, but I have <BR>in mind to use =
LDAP URLs here as well.<BR><BR>Vithalprasad Gaitonde wrote:<BR>&gt; =
Howard,<BR>&gt; Following is the change we could do to section "*Formal =
Syntax <BR>&gt; Definition of LDIF"<BR>&gt; *<BR>&gt; included-ldif-file-co=
ntent =3D "include:" FILL fileName<BR>&gt; ;where the contents of filename =
confirm to ldif-file of type ldif-content<BR>&gt; <BR>&gt; included-ldif-fi=
le-content =3D "include:" FILL fileName<BR>&gt; ;where the contents of =
filename confirm to ldif-file of type ldif-changes<BR>&gt; included-content=
-ldifs =3D 1*(1*SEP included-ldif-file-content)<BR>&gt; <BR>&gt; included-c=
hanges-ldifs =3D 1*(1*SEP included-ldif-file-changes)<BR>&gt; <BR>&gt; =
ldif-file =3D ldif-content / ldif-changes / included-content-ldifs / =
<BR>&gt; included-changes-ldifs<BR>&gt; <BR>&gt; ldif-content =3D =
version-spec included-content-ldifs 1*(1*SEP <BR>&gt; ldif-attrval-record)<=
BR>&gt; <BR>&gt; ldif-changes =3D version-spec included-changes-ldifs =
1*(1*SEP <BR>&gt; ldif-change-record)<BR>&gt; Let me know what you =
think.<BR>&gt; <BR>&gt; Thanks,<BR>&gt; Prasad<BR>&gt; <BR>&gt; &gt;&gt;&gt=
; Howard Chu &lt;<U> <A href=3D"mailto:hyc@highlandsun.com">hyc@highlandsun=
.com</A></U> &gt; 11/23/2004 12:33:06 PM &gt;&gt;&gt;<BR>&gt; Vithalprasad =
Gaitonde wrote:<BR>&gt; &gt; RFC2849 doesnt seem to provide a way to =
include one ldif file into<BR>&gt; &gt; another ldif file though it does =
allow referencing an external file for<BR>&gt; &gt; an attribute value.<BR>=
&gt; &gt; Has this been considered in the past ?<BR>&gt; &gt; It seems =
like a useful thing to have when there are dependencies across<BR>&gt; =
&gt; several ldif files.<BR>&gt; <BR>&gt; I agree, I would definitely have =
a use for this. Haven't thought about<BR>&gt; what the syntax should be =
yet.<BR><BR>-- <BR>-- Howard Chu<BR>Chief Architect, Symas Corp. Director, =
Highland Sun<BR><U><A href=3D"http://www.symas.com/">http://www.symas.com</=
A></U> <U><A href=3D"http://highlandsun.com/hyc">http://highlandsun.com/hyc=
</A></U> <BR>Symas: Premier OpenSource Development and Support<BR><BR>_____=
__________________________________________<BR>Ldapext mailing list<BR><U><A=
 href=3D"mailto:Ldapext@ietf.org">Ldapext@ietf.org</A></U> <BR><U><A =
href=3D"https://www1.ietf.org/mailman/listinfo/ldapext">https://www1.ietf.o=
rg/mailman/listinfo/ldapext</A></U> <BR></BODY></HTML>

--=__Part90B38197.1__=--


--===============0836115179==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext

--===============0836115179==--



From ldapext-bounces@ietf.org  Fri Apr 15 14:12:02 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27806
	for <ldapext-archive@lists.ietf.org>; Fri, 15 Apr 2005 14:12:02 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMUw3-00083T-Rn; Fri, 15 Apr 2005 13:48:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMUw2-000835-3q
	for ldapext@megatron.ietf.org; Fri, 15 Apr 2005 13:48:54 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26280
	for <ldapext@ietf.org>; Fri, 15 Apr 2005 13:48:53 -0400 (EDT)
Received: from pat.uio.no ([129.240.130.16] ident=7411)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMV6G-00030A-OA
	for ldapext@ietf.org; Fri, 15 Apr 2005 13:59:29 -0400
Received: from mail-mx1.uio.no ([129.240.10.29])
	by pat.uio.no with esmtp (Exim 4.43)
	id 1DMUvv-0003C9-7M; Fri, 15 Apr 2005 19:48:47 +0200
Received: from bombur.uio.no ([129.240.186.42])
	by mail-mx1.uio.no with esmtp (Exim 4.43)
	id 1DMUvo-0006Uf-Jp; Fri, 15 Apr 2005 19:48:40 +0200
Received: from hbf by bombur.uio.no with local (Exim 4.44)
	id 1DMUvo-0006e3-Ij; Fri, 15 Apr 2005 19:48:40 +0200
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <hbf.20050415pl5t@bombur.uio.no>
Date: Fri, 15 Apr 2005 19:48:40 +0200
To: "Vithalprasad Gaitonde" <gvithalprasad@novell.com>
Subject: Re: [ldapext] referencing one LDIF file from another
In-Reply-To: <s25e1f3f.039@lucius.provo.novell.com>
References: <s25e1f3f.039@lucius.provo.novell.com>
X-Mailer: VM 7.18 under Emacs 21.3.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-6.014, required 12,
	autolearn=disabled, ALL_TRUSTED -2.82, AWL 1.81,
	UIO_MAIL_IS_INTERNAL -5.00)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: 7bit
Cc: ldapext@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
Content-Transfer-Encoding: 7bit

Vithalprasad Gaitonde writes:
> Here's another try: Does this work for you ?

As far as I can tell, all LDIF files of your grammar must include
at least one more LDIF file.

It should be possible for a file to include any number of files before
the first change/attrval records, or to contain only include statements
and no change/content records.  So with an "include:" statement one can
no longer see from the grammar whether the file will apply ldif-content
or ldif-changes.

Instead the parser must choose that from the first non-"include:" record
it encounters, possibly in an included file, and the RFC should proably
specify that it is an error if there are both change and content
records.

If we do it that way, I think the grammar can simply be:

  ldif-file    = version-spec 1*(1*SEP ldif-chunk)
  ldif-chunk   = ldif-attrval-record / ldif-change-record / include-ldif
  include-ldif = "include:" FILL url SEP


If implementors want to determine if it is a content or changes file
from looking at the file itself, we could instead have two include
statements:

  include-ldif-content: "include-content:" FILL url SEP
  include-ldif-changes: "include-changes:" FILL url SEP

and the grammar mod would be

  ldif-file                = ldif-content / ldif-changes ; (as before)

  ldif-content             = version-spec 1*(1*SEP ldif-content-chunk)
  ldif-changes             = version-spec 1*(1*SEP ldif-change-chunk)

  ldif-content-chunk       = ldif-attrval-record / include-ldif-content
  ldif-change-chunk        = ldif-change-record  / include-ldif-changes

-- 
Hallvard

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Mon Apr 18 03:14:56 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21531
	for <ldapext-archive@ietf.org>; Mon, 18 Apr 2005 03:14:56 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DNQdx-0007aR-I0
	for ldapext-archive@ietf.org; Mon, 18 Apr 2005 03:26:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNQLs-0002SR-GK; Mon, 18 Apr 2005 03:07:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNQLp-0002SJ-OE
	for ldapext@megatron.ietf.org; Mon, 18 Apr 2005 03:07:22 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20953
	for <ldapext@ietf.org>; Mon, 18 Apr 2005 03:07:17 -0400 (EDT)
Received: from 213-102-90-65.cust.tele2.de ([213.102.90.65]
	helo=nb2.stroeder.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DNQWW-0007Kz-7W
	for ldapext@ietf.org; Mon, 18 Apr 2005 03:18:26 -0400
Received: from localhost (localhost [127.0.0.1])
	by nb2.stroeder.com (Postfix) with ESMTP id EA9494CD2
	for <ldapext@ietf.org>; Mon, 18 Apr 2005 08:23:45 +0200 (CEST)
Received: from nb2.stroeder.com ([127.0.0.1])
	by localhost (nb2 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
	id 21100-04 for <ldapext@ietf.org>;
	Mon, 18 Apr 2005 08:23:27 +0200 (CEST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by nb2.stroeder.com (Postfix) with ESMTP id 692F34CD4
	for <ldapext@ietf.org>; Mon, 18 Apr 2005 08:23:18 +0200 (CEST)
Message-ID: <42635255.2090900@stroeder.com>
Date: Mon, 18 Apr 2005 08:23:17 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050319
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: ldapext@ietf.org
References: <s25e0ace.035@lucius.provo.novell.com>
	<425E68F6.4020702@highlandsun.com>
In-Reply-To: <425E68F6.4020702@highlandsun.com>
X-Enigmail-Version: 0.90.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1
X-Virus-Scanned: by amavisd-new at stroeder.com
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: quoted-printable
Subject: [ldapext] HTTP and LDAP URLs as attr values in LDIF (was:
 referencing one LDIF file from another)
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: quoted-printable

Howard Chu wrote:
> What do you think about using a URL here instead of a simple filename?

While we're at it I'd like to cite from RFC2849:

      6) When a URL is specified in an attrval-spec, the following
          conventions apply:

         a) Implementations SHOULD support the file:// URL format.  The
            contents of the referenced file are to be included verbatim
            in the interpreted output of the LDIF file.
         b) Implementations MAY support other URL formats.  The
            semantics associated with each supported URL will be
            documented in an associated Applicability Statement.

Do such applicability statements exist for HTTP and LDAP URLs? If not a
new revision of RFC2849 should say more about this.

In my LDIF module I include content referenced by http:// just like that
of file:// URLs. The HTTP body of an HTTP response is included as a
single attribute value.

With LDAP URLs I'd propose that one should only retrieve content when
the LDAP URL references exactly one attribute of a single entry.
Multiple values of an attribute should all be included.

What do you think about it?

Ciao, Michael.

--=20
Michael Str=F6der
E-Mail: michael@stroeder.com
http://www.stroeder.com

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Fri Apr 22 07:54:07 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09393
	for <ldapext-archive@ietf.org>; Fri, 22 Apr 2005 07:54:07 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DOwvB-0000Kz-58
	for ldapext-archive@ietf.org; Fri, 22 Apr 2005 08:06:09 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOwfS-0008RU-2k; Fri, 22 Apr 2005 07:49:54 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOwfM-0008RM-Oo
	for ldapext@megatron.ietf.org; Fri, 22 Apr 2005 07:49:52 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09011
	for <ldapext@ietf.org>; Fri, 22 Apr 2005 07:49:47 -0400 (EDT)
Received: from smtp1.su.se ([130.237.162.112])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOwqx-0000Do-2y
	for ldapext@ietf.org; Fri, 22 Apr 2005 08:01:49 -0400
Received: from localhost (smtp1.su.se [127.0.0.1])
	by smtp1.su.se (Postfix) with ESMTP id C73DA38077;
	Fri, 22 Apr 2005 13:49:29 +0200 (CEST)
Received: from smtp1.su.se ([127.0.0.1])
	by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new,
	port 10024) with LMTP
	id 01122-02-11; Fri, 22 Apr 2005 13:49:29 +0200 (CEST)
Received: from [10.145.62.64] (unknown [217.213.138.15])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp1.su.se (Postfix) with ESMTP id D96A838056;
	Fri, 22 Apr 2005 13:49:19 +0200 (CEST)
Message-ID: <4268E4AF.1080303@it.su.se>
Date: Fri, 22 Apr 2005 13:49:03 +0200
From: Leif Johansson <leifj@it.su.se>
User-Agent: Mozilla Thunderbird 0.9 (X11/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "'ldapext@ietf.org'" <ldapext@ietf.org>, xeddev@adacel.com,
        =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        Roland Hedberg <roland@it.su.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at smtp.su.se
X-Spam-Status: No, hits=0 tagged_above=-99 required=7 tests=
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Content-Transfer-Encoding: 7bit
Subject: [ldapext] URN namespace for ldap/X.509 schema elements?
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: 7bit


Does anyone know if such a beast exists? What I would
like is a URN namespace (other than the oid namespace)
containing all (names of) ldap schema elements, possibly
limited to those published in RFCs.

My application is Roland Hedbergs meta-directory framework
which uses RDF as the intermediary data format.

The urn:ietf:param namespace doesn't seem to fit the bill
since schemas don't live in IANA registries.

	Cheers Leif

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Fri Apr 22 13:37:47 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06911
	for <ldapext-archive@ietf.org>; Fri, 22 Apr 2005 13:37:47 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DP2Ho-000094-3I
	for ldapext-archive@ietf.org; Fri, 22 Apr 2005 13:49:54 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DP256-0003QH-Ll; Fri, 22 Apr 2005 13:36:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DP0VY-0005mM-Ko
	for ldapext@megatron.ietf.org; Fri, 22 Apr 2005 11:55:56 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29410
	for <ldapext@ietf.org>; Fri, 22 Apr 2005 11:55:54 -0400 (EDT)
Received: from mxout7.cac.washington.edu ([140.142.32.178])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DP0hD-00066s-4z
	for ldapext@ietf.org; Fri, 22 Apr 2005 12:07:59 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout7.cac.washington.edu (8.13.4+UW05.03/8.13.4+UW05.04) with ESMTP
	id j3MFtpai013887; Fri, 22 Apr 2005 08:55:52 -0700
Received: from [192.168.101.207] (w002.z065106067.sjc-ca.dsl.cnc.net
	[65.106.67.2]) (authenticated bits=0)
	by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.04) with ESMTP id
	j3MFtnCM013067
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); 
	Fri, 22 Apr 2005 08:55:50 -0700
Date: Fri, 22 Apr 2005 08:55:48 -0700 (PDT)
From: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
X-X-Sender: rlmorgan@perp.cac.washington.edu
To: Leif Johansson <leifj@it.su.se>
Subject: Re: [ldapext] URN namespace for ldap/X.509 schema elements?
In-Reply-To: <4268E4AF.1080303@it.su.se>
Message-ID: <Pine.LNX.4.62.0504220845350.10365@perp.cac.washington.edu>
References: <4268E4AF.1080303@it.su.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
X-Mailman-Approved-At: Fri, 22 Apr 2005 13:36:42 -0400
Cc: xeddev@adacel.com, Roland Hedberg <roland@it.su.se>,
        =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        "'ldapext@ietf.org'" <ldapext@ietf.org>
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb


We confronted this question when considering a convention for 
representation of X.500/LDAP attributes as SAML Attributes, and decided on 
using the OID URN namespace.  See section 8.2 of the SAML 2.0 Profiles 
spec,

   http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf

Choosing to base URNs on anything other than OIDs seems to me to 
inevitable lead to having to maintain a registry of such names, in 
parallel with OID registries.  I can't see anyone wanting to do that.  Is 
there some problem with using urn:oid: ?

  - RL "Bob"

On Fri, 22 Apr 2005, Leif Johansson wrote:

>
> Does anyone know if such a beast exists? What I would
> like is a URN namespace (other than the oid namespace)
> containing all (names of) ldap schema elements, possibly
> limited to those published in RFCs.
>
> My application is Roland Hedbergs meta-directory framework
> which uses RDF as the intermediary data format.
>
> The urn:ietf:param namespace doesn't seem to fit the bill
> since schemas don't live in IANA registries.
>
> 	Cheers Leif
>
> _______________________________________________
> Ldapext mailing list
> Ldapext@ietf.org
> https://www1.ietf.org/mailman/listinfo/ldapext
>

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Fri Apr 22 15:46:45 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16817
	for <ldapext-archive@ietf.org>; Fri, 22 Apr 2005 15:46:45 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DP4Ic-0003Bs-Tr
	for ldapext-archive@ietf.org; Fri, 22 Apr 2005 15:58:52 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DP44W-0000ZI-0Q; Fri, 22 Apr 2005 15:44:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DP44U-0000Z8-OP
	for ldapext@megatron.ietf.org; Fri, 22 Apr 2005 15:44:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16370
	for <ldapext@ietf.org>; Fri, 22 Apr 2005 15:44:13 -0400 (EDT)
Received: from smtp1.su.se ([130.237.162.112])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DP4GA-00032N-Dj
	for ldapext@ietf.org; Fri, 22 Apr 2005 15:56:19 -0400
Received: from localhost (smtp1.su.se [127.0.0.1])
	by smtp1.su.se (Postfix) with ESMTP id 3D76638032;
	Fri, 22 Apr 2005 21:44:05 +0200 (CEST)
Received: from smtp1.su.se ([127.0.0.1])
	by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new,
	port 10024) with LMTP
	id 01957-01-22; Fri, 22 Apr 2005 21:44:04 +0200 (CEST)
Received: from [10.145.41.220] (unknown [217.213.138.178])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp1.su.se (Postfix) with ESMTP id DC7C438012;
	Fri, 22 Apr 2005 21:44:02 +0200 (CEST)
Message-ID: <426953F0.7070409@it.su.se>
Date: Fri, 22 Apr 2005 21:43:44 +0200
From: Leif Johansson <leifj@it.su.se>
User-Agent: Mozilla Thunderbird 0.9 (X11/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
Subject: Re: [ldapext] URN namespace for ldap/X.509 schema elements?
References: <4268E4AF.1080303@it.su.se>
	<Pine.LNX.4.62.0504220845350.10365@perp.cac.washington.edu>
In-Reply-To: <Pine.LNX.4.62.0504220845350.10365@perp.cac.washington.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at smtp.su.se
X-Spam-Status: No, hits=0 tagged_above=-99 required=7 tests=
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Content-Transfer-Encoding: 7bit
Cc: xeddev@adacel.com, Roland Hedberg <roland@it.su.se>,
        =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        "'ldapext@ietf.org'" <ldapext@ietf.org>
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Content-Transfer-Encoding: 7bit

RL 'Bob' Morgan wrote:
> 
> We confronted this question when considering a convention for 
> representation of X.500/LDAP attributes as SAML Attributes, and decided 
> on using the OID URN namespace.  See section 8.2 of the SAML 2.0 
> Profiles spec,
> 
>   http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
> 

Good reference, thanks.

> Choosing to base URNs on anything other than OIDs seems to me to 
> inevitable lead to having to maintain a registry of such names, in 
> parallel with OID registries.  I can't see anyone wanting to do that.  
> Is there some problem with using urn:oid: ?

I guess readability suffers a bit ;-) But seriously I don't understand
the need for a separate registry if only schema elements published in
RFC:s are handled...

Using urn:oid forces clients to be schema-aware which has good and bad
side-effects.

	MVH leifj

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Fri Apr 22 16:17:42 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25505
	for <ldapext-archive@ietf.org>; Fri, 22 Apr 2005 16:17:41 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DP4ma-0006Ex-E2
	for ldapext-archive@ietf.org; Fri, 22 Apr 2005 16:29:48 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DP4Zu-00046F-1z; Fri, 22 Apr 2005 16:16:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DP4Zs-00044j-HD
	for ldapext@megatron.ietf.org; Fri, 22 Apr 2005 16:16:40 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25160
	for <ldapext@ietf.org>; Fri, 22 Apr 2005 16:16:38 -0400 (EDT)
Received: from smtp3.su.se ([130.237.93.228])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DP4lY-000679-F6
	for ldapext@ietf.org; Fri, 22 Apr 2005 16:28:45 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
	by smtp3.su.se (Postfix) with ESMTP id 2CB9A37E75;
	Fri, 22 Apr 2005 22:16:37 +0200 (CEST)
Received: from smtp3.su.se ([127.0.0.1])
	by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new,
	port 10024) with LMTP
	id 27761-04-3; Fri, 22 Apr 2005 22:16:36 +0200 (CEST)
Received: from [10.145.44.61] (host-248-225.mobileonline.telia.com
	[217.213.248.225])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp3.su.se (Postfix) with ESMTP id 4966337E51;
	Fri, 22 Apr 2005 22:16:15 +0200 (CEST)
Message-ID: <42695B6B.7040908@it.su.se>
Date: Fri, 22 Apr 2005 22:15:39 +0200
From: Leif Johansson <leifj@it.su.se>
User-Agent: Mozilla Thunderbird 0.9 (X11/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: [ldapext] URN namespace for ldap/X.509 schema elements?
References: <4268E4AF.1080303@it.su.se>
	<6.2.1.2.0.20050422125843.07db26e8@mail.openldap.org>
In-Reply-To: <6.2.1.2.0.20050422125843.07db26e8@mail.openldap.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at smtp.su.se
X-Spam-Status: No, hits=0 tagged_above=-99 required=7 tests=
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: 7bit
Cc: xeddev@adacel.com, Roland Hedberg <roland@it.su.se>,
        =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        "'ldapext@ietf.org'" <ldapext@ietf.org>
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: 7bit

Kurt D. Zeilenga wrote:
> At 04:49 AM 4/22/2005, Leif Johansson wrote:
> 
>>Does anyone know if such a beast exists? What I would
>>like is a URN namespace (other than the oid namespace)
>>containing all (names of) ldap schema elements, possibly
>>limited to those published in RFCs.
>>
>>My application is Roland Hedbergs meta-directory framework
>>which uses RDF as the intermediary data format.
>>
>>The urn:ietf:param namespace doesn't seem to fit the bill
>>since schemas don't live in IANA registries.
> 
> 
> But the object identifier descriptors (short names) are registered.
> See <http://www.iana.org/assignments/ldap-parameters>.
> 

Thanks Kurt! I guess that means that

urn:ietf:params:ldap-parameters:object-identifier-descriptors:A:mail

(or something along those lines) could exists but the specification
for the ldap-parameters registry URN would have to be written up as
and RFC as per 3553?

	MVH leifj

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Fri Apr 22 16:22:03 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27594
	for <ldapext-archive@ietf.org>; Fri, 22 Apr 2005 16:22:03 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DP4qo-0006yv-Ey
	for ldapext-archive@ietf.org; Fri, 22 Apr 2005 16:34:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DP4KC-0005Ic-60; Fri, 22 Apr 2005 16:00:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DP4KA-0005Hw-Q0
	for ldapext@megatron.ietf.org; Fri, 22 Apr 2005 16:00:27 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20042
	for <ldapext@ietf.org>; Fri, 22 Apr 2005 16:00:23 -0400 (EDT)
Received: from boole.openldap.org ([204.152.186.50] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DP4Vp-0004Jg-AZ
	for ldapext@ietf.org; Fri, 22 Apr 2005 16:12:30 -0400
Received: from gyspy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net
	[24.205.218.53]) (authenticated bits=0)
	by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j3MK0KA4060256
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 22 Apr 2005 20:00:20 GMT (envelope-from Kurt@OpenLDAP.org)
Message-Id: <6.2.1.2.0.20050422125843.07db26e8@mail.openldap.org>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Fri, 22 Apr 2005 12:59:53 -0700
To: Leif Johansson <leifj@it.su.se>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: [ldapext] URN namespace for ldap/X.509 schema elements?
In-Reply-To: <4268E4AF.1080303@it.su.se>
References: <4268E4AF.1080303@it.su.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: xeddev@adacel.com, Roland Hedberg <roland@it.su.se>,
        Patrik Fältström <paf@cisco.com>,
        "'ldapext@ietf.org'" <ldapext@ietf.org>
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8

At 04:49 AM 4/22/2005, Leif Johansson wrote:
>Does anyone know if such a beast exists? What I would
>like is a URN namespace (other than the oid namespace)
>containing all (names of) ldap schema elements, possibly
>limited to those published in RFCs.
>
>My application is Roland Hedbergs meta-directory framework
>which uses RDF as the intermediary data format.
>
>The urn:ietf:param namespace doesn't seem to fit the bill
>since schemas don't live in IANA registries.

But the object identifier descriptors (short names) are registered.
See <http://www.iana.org/assignments/ldap-parameters>.


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Fri Apr 22 16:33:22 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00150
	for <ldapext-archive@ietf.org>; Fri, 22 Apr 2005 16:33:22 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DP51k-0007t4-SL
	for ldapext-archive@ietf.org; Fri, 22 Apr 2005 16:45:30 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DP4pr-0004eo-Gn; Fri, 22 Apr 2005 16:33:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DP4pq-0004dZ-8J
	for ldapext@megatron.ietf.org; Fri, 22 Apr 2005 16:33:10 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00107
	for <ldapext@ietf.org>; Fri, 22 Apr 2005 16:33:08 -0400 (EDT)
Received: from boole.openldap.org ([204.152.186.50] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DP51X-0007rT-K1
	for ldapext@ietf.org; Fri, 22 Apr 2005 16:45:15 -0400
Received: from gyspy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net
	[24.205.218.53]) (authenticated bits=0)
	by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j3MKX7Js065626
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 22 Apr 2005 20:33:07 GMT (envelope-from Kurt@OpenLDAP.org)
Message-Id: <6.2.1.2.0.20050422133122.065cba38@mail.openldap.org>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Fri, 22 Apr 2005 13:32:41 -0700
To: Leif Johansson <leifj@it.su.se>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: [ldapext] URN namespace for ldap/X.509 schema elements?
In-Reply-To: <42695B6B.7040908@it.su.se>
References: <4268E4AF.1080303@it.su.se>
	<6.2.1.2.0.20050422125843.07db26e8@mail.openldap.org>
	<42695B6B.7040908@it.su.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: Patrik Fältström <paf@cisco.com>, Roland Hedberg <roland@it.su.se>,
        xeddev@adacel.com, "'ldapext@ietf.org'" <ldapext@ietf.org>
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5

At 01:15 PM 4/22/2005, Leif Johansson wrote:
>Kurt D. Zeilenga wrote:
>>At 04:49 AM 4/22/2005, Leif Johansson wrote:
>>
>>>Does anyone know if such a beast exists? What I would
>>>like is a URN namespace (other than the oid namespace)
>>>containing all (names of) ldap schema elements, possibly
>>>limited to those published in RFCs.
>>>
>>>My application is Roland Hedbergs meta-directory framework
>>>which uses RDF as the intermediary data format.
>>>
>>>The urn:ietf:param namespace doesn't seem to fit the bill
>>>since schemas don't live in IANA registries.
>>
>>But the object identifier descriptors (short names) are registered.
>>See <http://www.iana.org/assignments/ldap-parameters>.
>
>Thanks Kurt! I guess that means that
>
>urn:ietf:params:ldap-parameters:object-identifier-descriptors:A:mail
>
>(or something along those lines) could exists but the specification
>for the ldap-parameters registry URN would have to be written up as
>and RFC as per 3553?

Might make a good appendix for BCP64bis.  You might
take this up with LDAPBIS.

Kurt 


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Fri Apr 22 17:18:01 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03269
	for <ldapext-archive@ietf.org>; Fri, 22 Apr 2005 17:18:01 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DP5iy-0000Vy-F3
	for ldapext-archive@ietf.org; Fri, 22 Apr 2005 17:30:09 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DP5V0-0005fj-42; Fri, 22 Apr 2005 17:15:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DP5Ux-0005fT-Eg
	for ldapext@megatron.ietf.org; Fri, 22 Apr 2005 17:15:40 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03127
	for <ldapext@ietf.org>; Fri, 22 Apr 2005 17:15:36 -0400 (EDT)
Received: from smtp3.su.se ([130.237.93.228])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DP5gd-0000Ss-DC
	for ldapext@ietf.org; Fri, 22 Apr 2005 17:27:44 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
	by smtp3.su.se (Postfix) with ESMTP id 3D85C37EC7;
	Fri, 22 Apr 2005 23:15:29 +0200 (CEST)
Received: from smtp3.su.se ([127.0.0.1])
	by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new,
	port 10024) with LMTP
	id 28788-05-13; Fri, 22 Apr 2005 23:15:29 +0200 (CEST)
Received: from [10.145.44.61] (host-248-225.mobileonline.telia.com
	[217.213.248.225])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp3.su.se (Postfix) with ESMTP id A90B037E51;
	Fri, 22 Apr 2005 23:15:26 +0200 (CEST)
Message-ID: <4269695C.5080208@it.su.se>
Date: Fri, 22 Apr 2005 23:15:08 +0200
From: Leif Johansson <leifj@it.su.se>
User-Agent: Mozilla Thunderbird 0.9 (X11/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Liben, Michael (IDS GNS)" <michael_liben@ml.com>
Subject: Re: [ldapext] URN namespace for ldap/X.509 schema elements?
References: <36D738A911A2814EA3DC134DAA5091A815120004@mlnyb707mb.amrs.win.ml.com>
In-Reply-To: <36D738A911A2814EA3DC134DAA5091A815120004@mlnyb707mb.amrs.win.ml.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at smtp.su.se
X-Spam-Status: No, hits=0 tagged_above=-99 required=7 tests=
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Content-Transfer-Encoding: 7bit
Cc: xeddev@adacel.com, Roland Hedberg <roland@it.su.se>,
        =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>, ldapext@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: 7bit

Liben, Michael (IDS GNS) wrote:
> Even though the short names may be registered, they may map to different attribute IDs on the back end. Not sure if that's a factor here or not.
> 
> For example, the co attribute has O.I.D. 1.2.840.113556.1.2.131 in Microsoft's Active Directory and is defined as single-valued. In RFC1274, it is assigned O.I.D. 0.9.2342.19200300.100.1.43 and is intended to contain multiple values.
> 
> Mike
> 

Isn't that just a bug?

	MVH leifj

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Fri Apr 22 17:18:41 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03402
	for <ldapext-archive@ietf.org>; Fri, 22 Apr 2005 17:18:40 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DP5jb-0000YG-VJ
	for ldapext-archive@ietf.org; Fri, 22 Apr 2005 17:30:49 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DP5Vd-0005jK-Bo; Fri, 22 Apr 2005 17:16:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DP5Vb-0005jF-3E
	for ldapext@megatron.ietf.org; Fri, 22 Apr 2005 17:16:19 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03151
	for <ldapext@ietf.org>; Fri, 22 Apr 2005 17:16:16 -0400 (EDT)
Received: from smtp3.su.se ([130.237.93.228])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DP5hE-0000TY-ST
	for ldapext@ietf.org; Fri, 22 Apr 2005 17:28:22 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
	by smtp3.su.se (Postfix) with ESMTP id 8611B37E6C;
	Fri, 22 Apr 2005 23:16:11 +0200 (CEST)
Received: from smtp3.su.se ([127.0.0.1])
	by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new,
	port 10024) with LMTP
	id 28788-05-15; Fri, 22 Apr 2005 23:16:11 +0200 (CEST)
Received: from [10.145.44.61] (host-248-225.mobileonline.telia.com
	[217.213.248.225])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp3.su.se (Postfix) with ESMTP id 9777C37E51;
	Fri, 22 Apr 2005 23:16:09 +0200 (CEST)
Message-ID: <42696989.8090101@it.su.se>
Date: Fri, 22 Apr 2005 23:15:53 +0200
From: Leif Johansson <leifj@it.su.se>
User-Agent: Mozilla Thunderbird 0.9 (X11/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: [ldapext] URN namespace for ldap/X.509 schema elements?
References: <4268E4AF.1080303@it.su.se>
	<6.2.1.2.0.20050422125843.07db26e8@mail.openldap.org>
	<42695B6B.7040908@it.su.se>
	<6.2.1.2.0.20050422133122.065cba38@mail.openldap.org>
In-Reply-To: <6.2.1.2.0.20050422133122.065cba38@mail.openldap.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at smtp.su.se
X-Spam-Status: No, hits=0 tagged_above=-99 required=7 tests=
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: 7bit
Cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        Roland Hedberg <roland@it.su.se>, xeddev@adacel.com,
        "'ldapext@ietf.org'" <ldapext@ietf.org>
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Content-Transfer-Encoding: 7bit

Kurt D. Zeilenga wrote:
> At 01:15 PM 4/22/2005, Leif Johansson wrote:
> 
>>Kurt D. Zeilenga wrote:
>>
>>>At 04:49 AM 4/22/2005, Leif Johansson wrote:
>>>
>>>
>>>>Does anyone know if such a beast exists? What I would
>>>>like is a URN namespace (other than the oid namespace)
>>>>containing all (names of) ldap schema elements, possibly
>>>>limited to those published in RFCs.
>>>>
>>>>My application is Roland Hedbergs meta-directory framework
>>>>which uses RDF as the intermediary data format.
>>>>
>>>>The urn:ietf:param namespace doesn't seem to fit the bill
>>>>since schemas don't live in IANA registries.
>>>
>>>But the object identifier descriptors (short names) are registered.
>>>See <http://www.iana.org/assignments/ldap-parameters>.
>>
>>Thanks Kurt! I guess that means that
>>
>>urn:ietf:params:ldap-parameters:object-identifier-descriptors:A:mail
>>
>>(or something along those lines) could exists but the specification
>>for the ldap-parameters registry URN would have to be written up as
>>and RFC as per 3553?
> 
> 
> Might make a good appendix for BCP64bis.  You might
> take this up with LDAPBIS.
> 

Good idea. I will.

	MVH leifj


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Fri Apr 22 18:57:30 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12106
	for <ldapext-archive@ietf.org>; Fri, 22 Apr 2005 18:57:30 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DP7HH-0003AA-K2
	for ldapext-archive@ietf.org; Fri, 22 Apr 2005 19:09:39 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DP74f-0000xf-Ix; Fri, 22 Apr 2005 18:56:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DP74d-0000xP-P4
	for ldapext@megatron.ietf.org; Fri, 22 Apr 2005 18:56:36 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11998
	for <ldapext@ietf.org>; Fri, 22 Apr 2005 18:56:28 -0400 (EDT)
Received: from mxout1.cac.washington.edu ([140.142.32.134])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DP7GH-00037H-NG
	for ldapext@ietf.org; Fri, 22 Apr 2005 19:08:38 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout1.cac.washington.edu (8.13.4+UW05.03/8.13.4+UW05.04) with ESMTP
	id j3MMuRGh011573; Fri, 22 Apr 2005 15:56:28 -0700
Received: from D-140-142-21-235.dhcp4.washington.edu
	(D-140-142-21-235.dhcp4.washington.edu [140.142.21.235])
	(authenticated bits=0)
	by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.04) with ESMTP id
	j3MMuQso026464
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); 
	Fri, 22 Apr 2005 15:56:26 -0700
Date: Fri, 22 Apr 2005 15:56:25 -0700 (PDT)
From: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
X-X-Sender: rlmorgan@perp.cac.washington.edu
To: Leif Johansson <leifj@it.su.se>
Subject: Re: [ldapext] URN namespace for ldap/X.509 schema elements?
In-Reply-To: <426953F0.7070409@it.su.se>
Message-ID: <Pine.LNX.4.62.0504221532580.11189@perp.cac.washington.edu>
References: <4268E4AF.1080303@it.su.se>
	<Pine.LNX.4.62.0504220845350.10365@perp.cac.washington.edu>
	<426953F0.7070409@it.su.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: xeddev@adacel.com, Roland Hedberg <roland@it.su.se>,
        =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        "'ldapext@ietf.org'" <ldapext@ietf.org>
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8


>> Choosing to base URNs on anything other than OIDs seems to me to 
>> inevitable lead to having to maintain a registry of such names, in 
>> parallel with OID registries.  I can't see anyone wanting to do that. 
>> Is there some problem with using urn:oid: ?
>
> I guess readability suffers a bit ;-) But seriously I don't understand
> the need for a separate registry if only schema elements published in
> RFC:s are handled...

The existence of the descriptor registry only proves my point, that using 
a namespace other than urn:oid requires a registry.  But this registry, 
rather than being completely delegated and distributed, is centralized, 
and requires "expert review" for new entries to be created.  These are 
among the reasons why the flat descriptor space is just a bad idea, as has 
been discussed very often on ldap lists.  The fact that we are stuck with 
descriptors in LDAP doesn't mean we should adopt them for URN-based 
attribute names, in fact it means we should learn from the experience and 
stay far away from them.

Also, how could it possibly be useful to put into practice a URN space for 
X.500/LDAP attribute types that excludes large numbers of already-defined 
types (ie, those whose descriptors aren't registered with IANA)?  If I 
wanted to use my organizationally-assigned attribute types, I couldn't 
until I registered them with IANA?  In fact what people would do (and 
we've seen this already with a one-off Internet2 URN space we made up for 
this purpose) is use URNs of urn:ietf:param:ldap-parameters:foo without 
registering the descriptor, resulting in collisions etc.

Another serious problem, the inverse of the one brought up by Michael 
Liben, is (from RFC 3383):

    Multiple names may be assigned to a given OID.

eg CN and commonName.  If I'm sending this attribute, which 
descriptor-based URN would I use?  Do you really think it would be a "best 
common practice" to promote the use of a URN space that defines multiple 
names for the same thing?

> Using urn:oid forces clients to be schema-aware which has good and bad
> side-effects.

Choosing URNs based on the assumption that it's useful for clients simply 
to splat those URNs in front of users (which I assume is what you would 
mean by "not schema-aware") also seems like less than best practice.  If 
clients are simply using them as opaque identifiers and comparing against 
values in tables etc, then it doesn't matter what they look like.

Perhaps I have made my position clear ...

  - RL "Bob"


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Sat Apr 23 05:39:24 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11276
	for <ldapext-archive@ietf.org>; Sat, 23 Apr 2005 05:39:24 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DPHIY-00009V-Kx
	for ldapext-archive@ietf.org; Sat, 23 Apr 2005 05:51:38 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DPH4X-0007YZ-FG; Sat, 23 Apr 2005 05:37:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DPH4O-0007Ua-6F
	for ldapext@megatron.ietf.org; Sat, 23 Apr 2005 05:37:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11169
	for <ldapext@ietf.org>; Sat, 23 Apr 2005 05:36:57 -0400 (EDT)
Received: from smtp1.su.se ([130.237.162.112])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPHG9-00006N-HI
	for ldapext@ietf.org; Sat, 23 Apr 2005 05:49:12 -0400
Received: from localhost (smtp1.su.se [127.0.0.1])
	by smtp1.su.se (Postfix) with ESMTP id B9FAD3804D;
	Sat, 23 Apr 2005 11:36:42 +0200 (CEST)
Received: from smtp1.su.se ([127.0.0.1])
	by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new,
	port 10024) with LMTP
	id 14350-01; Sat, 23 Apr 2005 11:36:41 +0200 (CEST)
Received: from [10.145.54.215] (unknown [217.213.130.167])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp1.su.se (Postfix) with ESMTP id 76E3C3800F;
	Sat, 23 Apr 2005 11:36:39 +0200 (CEST)
Message-ID: <426A1714.7000007@it.su.se>
Date: Sat, 23 Apr 2005 11:36:20 +0200
From: Leif Johansson <leifj@it.su.se>
User-Agent: Mozilla Thunderbird 0.9 (X11/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
Subject: Re: [ldapext] URN namespace for ldap/X.509 schema elements?
References: <4268E4AF.1080303@it.su.se>
	<Pine.LNX.4.62.0504220845350.10365@perp.cac.washington.edu>
	<426953F0.7070409@it.su.se>
	<Pine.LNX.4.62.0504221532580.11189@perp.cac.washington.edu>
In-Reply-To: <Pine.LNX.4.62.0504221532580.11189@perp.cac.washington.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at smtp.su.se
X-Spam-Status: No, hits=0 tagged_above=-99 required=7 tests=
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Content-Transfer-Encoding: 7bit
Cc: xeddev@adacel.com, Roland Hedberg <roland@it.su.se>,
        =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        "'ldapext@ietf.org'" <ldapext@ietf.org>
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Content-Transfer-Encoding: 7bit

RL 'Bob' Morgan wrote:
> 
>>> Choosing to base URNs on anything other than OIDs seems to me to 
>>> inevitable lead to having to maintain a registry of such names, in 
>>> parallel with OID registries.  I can't see anyone wanting to do that. 
>>> Is there some problem with using urn:oid: ?
>>
>>
>> I guess readability suffers a bit ;-) But seriously I don't understand
>> the need for a separate registry if only schema elements published in
>> RFC:s are handled...
> 
> 
> The existence of the descriptor registry only proves my point, that 
> using a namespace other than urn:oid requires a registry.  But this 
> registry, rather than being completely delegated and distributed, is 
> centralized, and requires "expert review" for new entries to be 
> created.  These are among the reasons why the flat descriptor space is 
> just a bad idea, as has been discussed very often on ldap lists.  The 
> fact that we are stuck with descriptors in LDAP doesn't mean we should 
> adopt them for URN-based attribute names, in fact it means we should 
> learn from the experience and stay far away from them.

I both agree and disagree. I agree that LDAP would have benefited from
using OIDs on the wire. Had that been the case I would not have
initiated this thread. However that is not the world we live in.
Short-names on the wire are a fact of life.

> 
> Also, how could it possibly be useful to put into practice a URN space 
> for X.500/LDAP attribute types that excludes large numbers of 
> already-defined types (ie, those whose descriptors aren't registered 

That is a valid point but imo only representing a subset of the schema
elements in a given urn "arc" does not invalidate the idea itself. Those
groups who define schema not registered with IANA can just as easily
define and use private URN (or god forbid URI) namespaces for those
schema. Put another way: local use of schema implies local use of urn:s.

> with IANA)?  If I wanted to use my organizationally-assigned attribute 
> types, I couldn't until I registered them with IANA?  In fact what 
> people would do (and we've seen this already with a one-off Internet2 
> URN space we made up for this purpose) is use URNs of 
> urn:ietf:param:ldap-parameters:foo without registering the descriptor, 
> resulting in collisions etc.
> 
> Another serious problem, the inverse of the one brought up by Michael 
> Liben, is (from RFC 3383):
> 
>    Multiple names may be assigned to a given OID.
> 
> eg CN and commonName.  If I'm sending this attribute, which 
> descriptor-based URN would I use?  Do you really think it would be a 
> "best common practice" to promote the use of a URN space that defines 
> multiple names for the same thing?

Another valid point but equaliy valid for LDAP itself and we are able
to use LDAP anyway. In practice one of the aliases will be used, the
other less so.

> 
>> Using urn:oid forces clients to be schema-aware which has good and bad
>> side-effects.
> 
> 
> Choosing URNs based on the assumption that it's useful for clients 
> simply to splat those URNs in front of users (which I assume is what you 

Absolutely not! My application does not involve users directly in any
way. Introducing oids is quite possible but requires a separate mapping
(i.e the schema) to be maintained.

> would mean by "not schema-aware") also seems like less than best 
> practice.  If clients are simply using them as opaque identifiers and 
> comparing against values in tables etc, then it doesn't matter what they 
> look like.
> 
> Perhaps I have made my position clear ...

You have some very good arguments. I would agree with you fully if it
weren't for the existence of the ldap-parameters IANA registry. Imo that
makes it useful (and 'cost efficient') to have these urn:s around.

> 
>  - RL "Bob"
> 

	MVH leifj

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Sun Apr 24 02:46:14 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18196
	for <ldapext-archive@ietf.org>; Sun, 24 Apr 2005 02:46:14 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DPb4g-0004Hf-3r
	for ldapext-archive@ietf.org; Sun, 24 Apr 2005 02:58:39 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DPapv-0006Jg-I8; Sun, 24 Apr 2005 02:43:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DPapo-0006JY-HH
	for ldapext@megatron.ietf.org; Sun, 24 Apr 2005 02:43:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18109
	for <ldapext@ietf.org>; Sun, 24 Apr 2005 02:43:14 -0400 (EDT)
Received: from mxout1.cac.washington.edu ([140.142.32.134])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPb1m-0004F6-MU
	for ldapext@ietf.org; Sun, 24 Apr 2005 02:55:40 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
	by mxout1.cac.washington.edu (8.13.4+UW05.03/8.13.4+UW05.04) with ESMTP
	id j3O6h87W028967; Sat, 23 Apr 2005 23:43:09 -0700
Received: from [192.168.1.103] (c-67-170-101-104.hsd1.wa.comcast.net
	[67.170.101.104]) (authenticated bits=0)
	by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.04) with ESMTP id
	j3O6h4YC030196
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); 
	Sat, 23 Apr 2005 23:43:08 -0700
Date: Sat, 23 Apr 2005 23:43:02 -0700 (PDT)
From: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
X-X-Sender: rlmorgan@perp.cac.washington.edu
To: Leif Johansson <leifj@it.su.se>
Subject: Re: [ldapext] URN namespace for ldap/X.509 schema elements?
In-Reply-To: <426A1714.7000007@it.su.se>
Message-ID: <Pine.LNX.4.62.0504232330290.11977@perp.cac.washington.edu>
References: <4268E4AF.1080303@it.su.se>
	<Pine.LNX.4.62.0504220845350.10365@perp.cac.washington.edu>
	<426953F0.7070409@it.su.se>
	<Pine.LNX.4.62.0504221532580.11189@perp.cac.washington.edu>
	<426A1714.7000007@it.su.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: xeddev@adacel.com, Roland Hedberg <roland@it.su.se>,
        =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        "'ldapext@ietf.org'" <ldapext@ietf.org>
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9


>> descriptor-based URN would I use?  Do you really think it would be a "best 
>> common practice" to promote the use of a URN space that defines multiple 
>> names for the same thing?
>
> Another valid point but equaliy valid for LDAP itself and we are able
> to use LDAP anyway. In practice one of the aliases will be used, the
> other less so.

The fact that with we live with this problem in LDAP certainly doesn't 
mean we would choose to recreate the problem in a new space.  In fact it 
means that we learn from our mistake and choose not to recreate the 
problem in the new space.

>>> Using urn:oid forces clients to be schema-aware which has good and bad
>>> side-effects.
>> 
>> Choosing URNs based on the assumption that it's useful for clients simply 
>> to splat those URNs in front of users (which I assume is what you 
>
> Absolutely not! My application does not involve users directly in any
> way. Introducing oids is quite possible but requires a separate mapping
> (i.e the schema) to be maintained.

Then I really don't understand what you mean by this point.  If there are 
no users involved then what could be the difference between

   urn:oid:2.5.6.2

and

   urn:ietf:param:ldap-parameters:objectidentifierdescriptors:country

as they're both just strings that identify an attribute type?  Why does 
one require some sort of mapping and the other not?

  - RL "Bob"


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Sun Apr 24 07:46:00 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09425
	for <ldapext-archive@ietf.org>; Sun, 24 Apr 2005 07:45:59 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DPfkp-0005pp-Cx
	for ldapext-archive@ietf.org; Sun, 24 Apr 2005 07:58:27 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DPfXm-0002Nt-Ab; Sun, 24 Apr 2005 07:44:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DPfXk-0002No-AS
	for ldapext@megatron.ietf.org; Sun, 24 Apr 2005 07:44:56 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09387
	for <ldapext@ietf.org>; Sun, 24 Apr 2005 07:44:55 -0400 (EDT)
Received: from boole.openldap.org ([204.152.186.50] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPfjl-0005jR-9s
	for ldapext@ietf.org; Sun, 24 Apr 2005 07:57:22 -0400
Received: from gyspy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net
	[24.205.218.53]) (authenticated bits=0)
	by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j3OBhm60051996
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 24 Apr 2005 11:43:48 GMT (envelope-from Kurt@OpenLDAP.org)
Message-Id: <6.2.1.2.0.20050424043629.0964f4b0@mail.openldap.org>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Sun, 24 Apr 2005 04:43:17 -0700
To: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: [ldapext] URN namespace for ldap/X.509 schema elements?
In-Reply-To: <Pine.LNX.4.62.0504232330290.11977@perp.cac.washington.edu>
References: <4268E4AF.1080303@it.su.se>
	<Pine.LNX.4.62.0504220845350.10365@perp.cac.washington.edu>
	<426953F0.7070409@it.su.se>
	<Pine.LNX.4.62.0504221532580.11189@perp.cac.washington.edu>
	<426A1714.7000007@it.su.se>
	<Pine.LNX.4.62.0504232330290.11977@perp.cac.washington.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: Patrik Fältström <paf@cisco.com>, Roland Hedberg <roland@it.su.se>,
        Leif Johansson <leifj@it.su.se>, xeddev@adacel.com,
        "'ldapext@ietf.org'" <ldapext@ietf.org>
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581

At 11:43 PM 4/23/2005, RL 'Bob' Morgan wrote:
>Then I really don't understand what you mean by this point.  If there are no users involved then what could be the difference between
>
>  urn:oid:2.5.6.2
>
>and
>
>  urn:ietf:param:ldap-parameters:objectidentifierdescriptors:country
>
>as they're both just strings that identify an attribute type?

Because some implementations are too stupid to map
'2.5.6.2' to 'country' (or vice versa).

Kurt 


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Sun Apr 24 08:22:11 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11791
	for <ldapext-archive@ietf.org>; Sun, 24 Apr 2005 08:22:11 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DPgJr-0007eU-40
	for ldapext-archive@ietf.org; Sun, 24 Apr 2005 08:34:39 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DPg5t-0005s3-VW; Sun, 24 Apr 2005 08:20:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DPg5r-0005ry-Qy
	for ldapext@megatron.ietf.org; Sun, 24 Apr 2005 08:20:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11721
	for <ldapext@ietf.org>; Sun, 24 Apr 2005 08:20:10 -0400 (EDT)
Received: from mlnyb901er.ml.com ([199.43.54.99])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPgHu-0007Xb-6m
	for ldapext@ietf.org; Sun, 24 Apr 2005 08:32:38 -0400
Received: from MLNYA354BH.amrs.win.ml.com (unknown [146.125.98.4])
	by mlnyb901er.ml.com (Postfix) with ESMTP
	id 9C13E1000027B; Sun, 24 Apr 2005 08:19:48 -0400 (EDT)
Received: from mlnya301bh.amrs.win.ml.com ([146.125.109.51]) by
	MLNYA354BH.amrs.win.ml.com with Microsoft
	SMTPSVC(5.0.2195.6713); Sun, 24 Apr 2005 08:19:48 -0400
Received: from mlnyb707mb.amrs.win.ml.com ([146.125.92.7]) by
	mlnya301bh.amrs.win.ml.com with Microsoft
	SMTPSVC(5.0.2195.6713); Sun, 24 Apr 2005 08:19:48 -0400
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Content-Class: urn:content-classes:message
Subject: RE: [ldapext] URN namespace for ldap/X.509 schema elements?
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 24 Apr 2005 08:19:47 -0400
Message-ID: <36D738A911A2814EA3DC134DAA5091A81566F375@mlnyb707mb.amrs.win.ml.com>
Thread-Topic: [ldapext] URN namespace for ldap/X.509 schema elements?
thread-index: AcVIwyHP9KgftplbTYiFBbtARgB8sQABG97g
Importance: normal
Priority: normal
From: "Liben, Michael (IDS GNS)" <michael_liben@ml.com>
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>,
        "RL 'Bob' Morgan" <rlmorgan@washington.edu>
X-OriginalArrivalTime: 24 Apr 2005 12:19:48.0382 (UTC)
	FILETIME=[E859D3E0:01C548C7]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Content-Transfer-Encoding: quoted-printable
Cc: xeddev@adacel.com, Roland Hedberg <roland@it.su.se>,
        Leif Johansson <leifj@it.su.se>,
        =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        ldapext@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Content-Transfer-Encoding: quoted-printable

I posted this earlier but it appears to have been bounced because of new =
corporate email address standards at my end. I had to re-register with =
the new email address. Here's a repost:

------------
Even though the short names may be registered, they may map to different =
attribute IDs on the back end. Not sure if that's a factor here or not.

For example, the co attribute has O.I.D. 1.2.840.113556.1.2.131 in =
Microsoft's Active Directory and is defined as single-valued. In =
RFC1274, it is assigned O.I.D. 0.9.2342.19200300.100.1.43 and is =
intended to contain multiple values.

Mike Liben


-----Original Message-----
From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org] On =
Behalf Of Kurt D. Zeilenga
Sent: Sunday, April 24, 2005 7:43 AM
To: RL 'Bob' Morgan
Cc: Patrik F=E4ltstr=F6m; Roland Hedberg; Leif Johansson; =
xeddev@adacel.com; 'ldapext@ietf.org'
Subject: Re: [ldapext] URN namespace for ldap/X.509 schema elements?

At 11:43 PM 4/23/2005, RL 'Bob' Morgan wrote:
>Then I really don't understand what you mean by this point.  If there =
are no users involved then what could be the difference between
>
>  urn:oid:2.5.6.2
>
>and
>
>  urn:ietf:param:ldap-parameters:objectidentifierdescriptors:country
>
>as they're both just strings that identify an attribute type?

Because some implementations are too stupid to map
'2.5.6.2' to 'country' (or vice versa).

Kurt=20


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext
--------------------------------------------------------

If you are not an intended recipient of this e-mail, please notify the =
sender, delete it and do not read, act upon, print, disclose, copy, =
retain or redistribute it. Click here for important additional terms =
relating to this e-mail.     http://www.ml.com/email_terms/
--------------------------------------------------------

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Mon Apr 25 01:31:07 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22131
	for <ldapext-archive@ietf.org>; Mon, 25 Apr 2005 01:31:07 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DPwNj-0004XD-Bw
	for ldapext-archive@ietf.org; Mon, 25 Apr 2005 01:43:44 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DPw9h-0006RD-KB; Mon, 25 Apr 2005 01:29:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DPw9f-0006R1-0M
	for ldapext@megatron.ietf.org; Mon, 25 Apr 2005 01:29:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22031
	for <ldapext@ietf.org>; Mon, 25 Apr 2005 01:29:09 -0400 (EDT)
Received: from mxout1.cac.washington.edu ([140.142.32.134])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPwLo-0004PY-VB
	for ldapext@ietf.org; Mon, 25 Apr 2005 01:41:46 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
	by mxout1.cac.washington.edu (8.13.4+UW05.03/8.13.4+UW05.04) with ESMTP
	id j3P5Rkt4016054; Sun, 24 Apr 2005 22:27:46 -0700
Received: from [192.168.1.103] (c-67-170-101-104.hsd1.wa.comcast.net
	[67.170.101.104]) (authenticated bits=0)
	by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.04) with ESMTP id
	j3P5RjWR018516
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); 
	Sun, 24 Apr 2005 22:27:45 -0700
Date: Sun, 24 Apr 2005 22:27:42 -0700 (PDT)
From: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
X-X-Sender: rlmorgan@perp.cac.washington.edu
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: [ldapext] URN namespace for ldap/X.509 schema elements?
In-Reply-To: <6.2.1.2.0.20050424043629.0964f4b0@mail.openldap.org>
Message-ID: <Pine.LNX.4.62.0504242214040.11977@perp.cac.washington.edu>
References: <4268E4AF.1080303@it.su.se>
	<Pine.LNX.4.62.0504220845350.10365@perp.cac.washington.edu>
	<426953F0.7070409@it.su.se>
	<Pine.LNX.4.62.0504221532580.11189@perp.cac.washington.edu>
	<426A1714.7000007@it.su.se>
	<Pine.LNX.4.62.0504232330290.11977@perp.cac.washington.edu>
	<6.2.1.2.0.20050424043629.0964f4b0@mail.openldap.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: =?utf-8?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        Roland Hedberg <roland@it.su.se>, Leif Johansson <leifj@it.su.se>,
        xeddev@adacel.com, "'ldapext@ietf.org'" <ldapext@ietf.org>
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126


On Sun, 24 Apr 2005, Kurt D. Zeilenga wrote:

> Because some implementations are too stupid to map '2.5.6.2' to 
> 'country' (or vice versa).

But *why* does an implementation have to map 2.5.6.2 to anything at all, 
if there are (as Leif said) no end-users who might want to see the string 
"country" (or the appropriate string in their preferred language)?  Y'all 
seem to be assuming that the native representation of attribute type names 
in implementations is the descriptors.

  - RL "Bob"


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Mon Apr 25 01:37:20 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22598
	for <ldapext-archive@ietf.org>; Mon, 25 Apr 2005 01:37:20 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DPwTl-0004o6-EZ
	for ldapext-archive@ietf.org; Mon, 25 Apr 2005 01:49:57 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DPwGi-00071i-DK; Mon, 25 Apr 2005 01:36:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DPwGg-00071a-Gw
	for ldapext@megatron.ietf.org; Mon, 25 Apr 2005 01:36:26 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22525
	for <ldapext@ietf.org>; Mon, 25 Apr 2005 01:36:25 -0400 (EDT)
Received: from boole.openldap.org ([204.152.186.50] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPwSr-0004ms-2V
	for ldapext@ietf.org; Mon, 25 Apr 2005 01:49:02 -0400
Received: from gyspy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net
	[24.205.218.53]) (authenticated bits=0)
	by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j3P5ZLJh075323
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Apr 2005 05:35:21 GMT (envelope-from Kurt@OpenLDAP.org)
Message-Id: <6.2.1.2.0.20050424223215.0b313b68@mail.openldap.org>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Sun, 24 Apr 2005 22:34:49 -0700
To: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: [ldapext] URN namespace for ldap/X.509 schema elements?
In-Reply-To: <Pine.LNX.4.62.0504242214040.11977@perp.cac.washington.edu>
References: <4268E4AF.1080303@it.su.se>
	<Pine.LNX.4.62.0504220845350.10365@perp.cac.washington.edu>
	<426953F0.7070409@it.su.se>
	<Pine.LNX.4.62.0504221532580.11189@perp.cac.washington.edu>
	<426A1714.7000007@it.su.se>
	<Pine.LNX.4.62.0504232330290.11977@perp.cac.washington.edu>
	<6.2.1.2.0.20050424043629.0964f4b0@mail.openldap.org>
	<Pine.LNX.4.62.0504242214040.11977@perp.cac.washington.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: xeddev@adacel.com, Roland Hedberg <roland@it.su.se>,
        Leif Johansson <leifj@it.su.se>, Patrik Fältström <paf@cisco.com>,
        "'ldapext@ietf.org'" <ldapext@ietf.org>
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8

At 10:27 PM 4/24/2005, RL 'Bob' Morgan wrote:
>On Sun, 24 Apr 2005, Kurt D. Zeilenga wrote:
>>Because some implementations are too stupid to map '2.5.6.2' to 'country' (or vice versa).
>
>But *why* does an implementation have to map 2.5.6.2 to anything at all, if there are (as Leif said) no end-users who might want to see the string "country" (or the appropriate string in their preferred language)?  Y'all seem to be assuming that the native representation of attribute type names in implementations is the descriptors.

Because in some implementations, this is the case.  Hence,
in other implementations, if they don't map, they don't get
what they expect.  That is, asking for return of '2.5.6.2'
may not cause values of the 'country' attribute to be
returned because the server might not regard 2.5.6.2 and
'country' as being equivalent.

Kurt 


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Mon Apr 25 03:42:22 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21453
	for <ldapext-archive@ietf.org>; Mon, 25 Apr 2005 03:42:22 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DPyQn-00027D-JI
	for ldapext-archive@ietf.org; Mon, 25 Apr 2005 03:55:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DPyDF-0000m0-BV; Mon, 25 Apr 2005 03:41:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DPyD8-0000lG-Iw
	for ldapext@megatron.ietf.org; Mon, 25 Apr 2005 03:40:59 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21408
	for <ldapext@ietf.org>; Mon, 25 Apr 2005 03:40:52 -0400 (EDT)
Received: from smtp3.su.se ([130.237.93.228])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPyPK-00020U-64
	for ldapext@ietf.org; Mon, 25 Apr 2005 03:53:31 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
	by smtp3.su.se (Postfix) with ESMTP id 631CB37E66;
	Mon, 25 Apr 2005 09:40:44 +0200 (CEST)
Received: from smtp3.su.se ([127.0.0.1])
	by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new,
	port 10024) with LMTP
	id 03738-01-31; Mon, 25 Apr 2005 09:40:44 +0200 (CEST)
Received: from [130.237.168.243] (dhcp-wavelan-v-243.publik.su.se
	[130.237.168.243])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp3.su.se (Postfix) with ESMTP id C4E0737E76;
	Mon, 25 Apr 2005 09:40:39 +0200 (CEST)
Message-ID: <426C9EF6.1080904@it.su.se>
Date: Mon, 25 Apr 2005 09:40:38 +0200
From: Leif Johansson <leifj@it.su.se>
User-Agent: Mozilla Thunderbird 0.9 (X11/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
Subject: Re: [ldapext] URN namespace for ldap/X.509 schema elements?
References: <4268E4AF.1080303@it.su.se>
	<Pine.LNX.4.62.0504220845350.10365@perp.cac.washington.edu>
	<426953F0.7070409@it.su.se>
	<Pine.LNX.4.62.0504221532580.11189@perp.cac.washington.edu>
	<426A1714.7000007@it.su.se>
	<Pine.LNX.4.62.0504232330290.11977@perp.cac.washington.edu>
In-Reply-To: <Pine.LNX.4.62.0504232330290.11977@perp.cac.washington.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at smtp.su.se
X-Spam-Status: No, hits=-0.1 tagged_above=-99 required=7 tests=ALL_TRUSTED,
	MANGLED_DOSE
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: 7bit
Cc: xeddev@adacel.com, Roland Hedberg <roland@it.su.se>,
        =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        "'ldapext@ietf.org'" <ldapext@ietf.org>
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: 7bit


> Then I really don't understand what you mean by this point.  If there 
> are no users involved then what could be the difference between
> 
>   urn:oid:2.5.6.2
> 
> and
> 
>   urn:ietf:param:ldap-parameters:objectidentifierdescriptors:country
> 
> as they're both just strings that identify an attribute type?  Why does 
> one require some sort of mapping and the other not?


I can do $e->get_value((split /':'/,$urn)[5])

	MVH leifj

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Mon Apr 25 03:44:02 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21534
	for <ldapext-archive@ietf.org>; Mon, 25 Apr 2005 03:44:02 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DPySO-00029A-OD
	for ldapext-archive@ietf.org; Mon, 25 Apr 2005 03:56:41 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DPyF0-0000rr-NJ; Mon, 25 Apr 2005 03:42:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DPyEx-0000rm-7L
	for ldapext@megatron.ietf.org; Mon, 25 Apr 2005 03:42:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21475
	for <ldapext@ietf.org>; Mon, 25 Apr 2005 03:42:45 -0400 (EDT)
Received: from smtp1.su.se ([130.237.162.112])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPyR8-00027Z-R8
	for ldapext@ietf.org; Mon, 25 Apr 2005 03:55:24 -0400
Received: from localhost (smtp1.su.se [127.0.0.1])
	by smtp1.su.se (Postfix) with ESMTP id 6080A38063;
	Mon, 25 Apr 2005 09:42:44 +0200 (CEST)
Received: from smtp1.su.se ([127.0.0.1])
	by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new,
	port 10024) with LMTP
	id 08227-01-47; Mon, 25 Apr 2005 09:42:43 +0200 (CEST)
Received: from [130.237.168.243] (dhcp-wavelan-v-243.publik.su.se
	[130.237.168.243])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp1.su.se (Postfix) with ESMTP id 14C553804D;
	Mon, 25 Apr 2005 09:42:42 +0200 (CEST)
Message-ID: <426C9F71.5040007@it.su.se>
Date: Mon, 25 Apr 2005 09:42:41 +0200
From: Leif Johansson <leifj@it.su.se>
User-Agent: Mozilla Thunderbird 0.9 (X11/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: [ldapext] URN namespace for ldap/X.509 schema elements?
References: <4268E4AF.1080303@it.su.se>
	<Pine.LNX.4.62.0504220845350.10365@perp.cac.washington.edu>
	<426953F0.7070409@it.su.se>
	<Pine.LNX.4.62.0504221532580.11189@perp.cac.washington.edu>
	<426A1714.7000007@it.su.se>
	<Pine.LNX.4.62.0504232330290.11977@perp.cac.washington.edu>
	<6.2.1.2.0.20050424043629.0964f4b0@mail.openldap.org>
	<Pine.LNX.4.62.0504242214040.11977@perp.cac.washington.edu>
	<6.2.1.2.0.20050424223215.0b313b68@mail.openldap.org>
In-Reply-To: <6.2.1.2.0.20050424223215.0b313b68@mail.openldap.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at smtp.su.se
X-Spam-Status: No, hits=-2.4 tagged_above=-99 required=7 tests=ALL_TRUSTED
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: 7bit
Cc: xeddev@adacel.com, Roland Hedberg <roland@it.su.se>,
        =?ISO-8859-1?Q?Patrik_F=E4?= =?ISO-8859-1?Q?ltstr=F6m?= <paf@cisco.com>,
        "'ldapext@ietf.org'" <ldapext@ietf.org>
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit

Kurt D. Zeilenga wrote:
> At 10:27 PM 4/24/2005, RL 'Bob' Morgan wrote:
> 
>>On Sun, 24 Apr 2005, Kurt D. Zeilenga wrote:
>>
>>>Because some implementations are too stupid to map '2.5.6.2' to 'country' (or vice versa).
>>
>>But *why* does an implementation have to map 2.5.6.2 to anything at all, if there are (as Leif said) no end-users who might want to see the string "country" (or the appropriate string in their preferred language)?  Y'all seem to be assuming that the native representation of attribute type names in implementations is the descriptors.
> 
> 
> Because in some implementations, this is the case.  Hence,
> in other implementations, if they don't map, they don't get
> what they expect.  That is, asking for return of '2.5.6.2'
> may not cause values of the 'country' attribute to be
> returned because the server might not regard 2.5.6.2 and
> 'country' as being equivalent.
> 
> Kurt 
> 

In fact I know of no ldap-libraries that does this... (or maybe I just
don't know my ldap libraries :-) )

	MVH leifj

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Tue Apr 26 10:42:06 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13719
	for <ldapext-archive@ietf.org>; Tue, 26 Apr 2005 10:42:06 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DQRSn-0005xT-94
	for ldapext-archive@ietf.org; Tue, 26 Apr 2005 10:55:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQRGB-0006EK-7V; Tue, 26 Apr 2005 10:41:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQRG9-0006EC-4M
	for ldapext@megatron.ietf.org; Tue, 26 Apr 2005 10:41:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13692
	for <ldapext@ietf.org>; Tue, 26 Apr 2005 10:41:55 -0400 (EDT)
Received: from highlandsun.propagation.net ([66.221.212.168])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQRSb-0005wl-1a
	for ldapext@ietf.org; Tue, 26 Apr 2005 10:54:50 -0400
Received: from [127.0.0.1] (highlandsun.com [66.221.212.169])
	by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id
	j3QEfkoc032446
	for <ldapext@ietf.org>; Tue, 26 Apr 2005 08:41:47 -0600
Message-ID: <426E532D.7070102@highlandsun.com>
Date: Tue, 26 Apr 2005 07:41:49 -0700
From: Howard Chu <hyc@highlandsun.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.8b2) Gecko/20050419
MIME-Version: 1.0
To: ldapext@ietf.org
Subject: Re: [ldapext] draft-behera-ldap-password-policy - operational attrs
References: <s21e2f9e.035@sinclair.provo.novell.com>
In-Reply-To: <s21e2f9e.035@sinclair.provo.novell.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: 7bit
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Content-Transfer-Encoding: 7bit

I kept meaning to raise this question, but it seems to have fallen thru 
the cracks. For the OpenLDAP implementation, I needed to change these 
operational attributes to NO-USER-MODIFICATION:
	pwdChangedTime, pwdGraceUseTime, and pwdHistory

We have a problem because of the way we process a password change - if a 
user is changing their own password, that Modify request is performed 
using the user's identity. To do bookkeeping on the above operational 
attributes, we internally append some modify operations to the user's 
Modify request, and then the augmented request is passed down to the 
usual Modify processing. One other factor in our implementation is that 
user-modifiable attributes are subject to ACL checks, non-modifiable 
attributes are not. So, userPassword is user-modifiable, and typically 
users are given permission to write their own password. But they 
shouldn't have permission to write the above three attributes, because 
then they can just bypass a lot of the policies that rely on those 
attributes.

So with the default definitions, we have a problem because the user may 
have permission to update the userPassword attr, but no permissions to 
the other attrs.

Alternatively we can break things up into two separate Modify 
operations, doing the user's original request and then using system 
privileges to handle the bookkeeping, but I'm not keen on that approach. 
It introduces some lag in a replication scenario, where the password 
change itself will get replicated separately from the bookkeeping update.

Fundamentally I believe NO-USER-MODIFICATION is appropriate for these 
attributes. Issues with our implementation can be worked around, but I'd 
rather clear this up regardless.

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.       Director, Highland Sun
   http://www.symas.com               http://highlandsun.com/hyc
   Symas: Premier OpenSource Development and Support

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Wed Apr 27 10:33:12 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20307
	for <ldapext-archive@ietf.org>; Wed, 27 Apr 2005 10:33:11 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DQnns-00062H-Kj
	for ldapext-archive@ietf.org; Wed, 27 Apr 2005 10:46:19 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQnaJ-00006A-8Y; Wed, 27 Apr 2005 10:32:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQnaG-0008Vn-Hu
	for ldapext@megatron.ietf.org; Wed, 27 Apr 2005 10:32:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20195
	for <ldapext@ietf.org>; Wed, 27 Apr 2005 10:32:10 -0400 (EDT)
Received: from sinclair.provo.novell.com ([137.65.81.169])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQnmr-00060D-Sc
	for ldapext@ietf.org; Wed, 27 Apr 2005 10:45:18 -0400
Received: from INET-PRV-MTA by sinclair.provo.novell.com
	with Novell_GroupWise; Wed, 27 Apr 2005 08:31:53 -0600
Message-Id: <s26f4df9.041@sinclair.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 6.5.4 
Date: Wed, 27 Apr 2005 08:31:29 -0600
From: "Jim Sermersheim" <jimse@novell.com>
To: <hyc@highlandsun.com>, <ldapext@ietf.org>
Subject: Re: [ldapext] draft-behera-ldap-password-policy - operational
	attrs
Mime-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
Cc: Duane Buss <DBuss@novell.com>, Tammy Green <TGREEN@novell.com>,
        Zhanna Tsitkova <ZTsitkova@novell.com>
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0474885509=="
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--===============0474885509==
Content-Type: multipart/alternative; boundary="=__PartB6959651.1__="

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartB6959651.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

While I worry a bit about your implementation (though it's not really my =
place to), I agree with your final assessment, we should change these to =
NO-USER-MODIFICATION.
=20
Anyone disagree?
=20
Jim

>>> Howard Chu <hyc@highlandsun.com> 4/26/05 8:41 AM >>>
I kept meaning to raise this question, but it seems to have fallen thru=20
the cracks. For the OpenLDAP implementation, I needed to change these=20
operational attributes to NO-USER-MODIFICATION:
pwdChangedTime, pwdGraceUseTime, and pwdHistory

We have a problem because of the way we process a password change - if =
a=20
user is changing their own password, that Modify request is performed=20
using the user's identity. To do bookkeeping on the above operational=20
attributes, we internally append some modify operations to the user's=20
Modify request, and then the augmented request is passed down to the=20
usual Modify processing. One other factor in our implementation is that=20
user-modifiable attributes are subject to ACL checks, non-modifiable=20
attributes are not. So, userPassword is user-modifiable, and typically=20
users are given permission to write their own password. But they=20
shouldn't have permission to write the above three attributes, because=20
then they can just bypass a lot of the policies that rely on those=20
attributes.

So with the default definitions, we have a problem because the user may=20
have permission to update the userPassword attr, but no permissions to=20
the other attrs.

Alternatively we can break things up into two separate Modify=20
operations, doing the user's original request and then using system=20
privileges to handle the bookkeeping, but I'm not keen on that approach.=20=

It introduces some lag in a replication scenario, where the password=20
change itself will get replicated separately from the bookkeeping update.

Fundamentally I believe NO-USER-MODIFICATION is appropriate for these=20
attributes. Issues with our implementation can be worked around, but =
I'd=20
rather clear this up regardless.

--=20
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc=20
Symas: Premier OpenSource Development and Support

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org=20
https://www1.ietf.org/mailman/listinfo/ldapext=20



--=__PartB6959651.1__=
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"=
>
<META content=3D"MSHTML 6.00.2900.2627" name=3DGENERATOR></HEAD>
<BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<DIV>While I worry a bit about your implementation (though it's not really =
my place to), I agree with your final assessment, we should change these =
to NO-USER-MODIFICATION.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Anyone disagree?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Jim<BR><BR>&gt;&gt;&gt; Howard Chu &lt;hyc@highlandsun.com&gt; =
4/26/05 8:41 AM &gt;&gt;&gt;<BR>I kept meaning to raise this question, but =
it seems to have fallen thru <BR>the cracks. For the OpenLDAP implementatio=
n, I needed to change these <BR>operational attributes to NO-USER-MODIFICAT=
ION:<BR>pwdChangedTime, pwdGraceUseTime, and pwdHistory<BR><BR>We have a =
problem because of the way we process a password change - if a <BR>user is =
changing their own password, that Modify request is performed <BR>using =
the user's identity. To do bookkeeping on the above operational <BR>attribu=
tes, we internally append some modify operations to the user's <BR>Modify =
request, and then the augmented request is passed down to the <BR>usual =
Modify processing. One other factor in our implementation is that =
<BR>user-modifiable attributes are subject to ACL checks, non-modifiable =
<BR>attributes are not. So, userPassword is user-modifiable, and typically =
<BR>users are given permission to write their own password. But they =
<BR>shouldn't have permission to write the above three attributes, because =
<BR>then they can just bypass a lot of the policies that rely on those =
<BR>attributes.<BR><BR>So with the default definitions, we have a problem =
because the user may <BR>have permission to update the userPassword attr, =
but no permissions to <BR>the other attrs.<BR><BR>Alternatively we can =
break things up into two separate Modify <BR>operations, doing the user's =
original request and then using system <BR>privileges to handle the =
bookkeeping, but I'm not keen on that approach. <BR>It introduces some lag =
in a replication scenario, where the password <BR>change itself will get =
replicated separately from the bookkeeping update.<BR><BR>Fundamentally I =
believe NO-USER-MODIFICATION is appropriate for these <BR>attributes. =
Issues with our implementation can be worked around, but I'd <BR>rather =
clear this up regardless.<BR><BR>-- <BR>-- Howard Chu<BR>Chief Architect, =
Symas Corp. Director, Highland Sun<BR><U><A href=3D"http://www.symas.com/">=
http://www.symas.com</A></U> <U><A href=3D"http://highlandsun.com/hyc">http=
://highlandsun.com/hyc</A></U> <BR>Symas: Premier OpenSource Development =
and Support<BR><BR>_______________________________________________<BR>Ldape=
xt mailing list<BR><U><A href=3D"mailto:Ldapext@ietf.org">Ldapext@ietf.org<=
/A></U> <BR><U><A href=3D"https://www1.ietf.org/mailman/listinfo/ldapext">h=
ttps://www1.ietf.org/mailman/listinfo/ldapext</A></U> <BR></DIV></BODY></HT=
ML>

--=__PartB6959651.1__=--


--===============0474885509==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext

--===============0474885509==--



From ldapext-bounces@ietf.org  Wed Apr 27 10:46:15 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21295
	for <ldapext-archive@ietf.org>; Wed, 27 Apr 2005 10:46:14 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DQo0W-0006KI-Lm
	for ldapext-archive@ietf.org; Wed, 27 Apr 2005 10:59:23 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQnmR-0002Nz-94; Wed, 27 Apr 2005 10:44:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQnmP-0002Nu-EP
	for ldapext@megatron.ietf.org; Wed, 27 Apr 2005 10:44:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21126
	for <ldapext@ietf.org>; Wed, 27 Apr 2005 10:44:43 -0400 (EDT)
Received: from imo-d01.mx.aol.com ([205.188.157.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQnz1-0006Hc-Vd
	for ldapext@ietf.org; Wed, 27 Apr 2005 10:57:51 -0400
Received: from richm@netscape.net
	by imo-d01.mx.aol.com (mail_out_v38_r1.7.) id t.c2.10264cd5 (22682);
	Wed, 27 Apr 2005 10:43:57 -0400 (EDT)
Received: from [192.168.1.35] (bgp01365849bgs.sandia01.nm.comcast.net
	[68.35.55.152]) by air-in04.mx.aol.com (vx) with ESMTP id
	MAILININ43-589a426fa52c1aa; Wed, 27 Apr 2005 10:43:57 -0400
Message-ID: <426FA52B.2090601@netscape.net>
Date: Wed, 27 Apr 2005 08:43:55 -0600
From: Rich Megginson <richm@netscape.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.7.2) Gecko/20040805 Netscape/7.2
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: jimse@novell.com
Subject: Re: [ldapext] draft-behera-ldap-password-policy - operational attrs
References: <s26f4df9.041@sinclair.provo.novell.com>
In-Reply-To: <s26f4df9.041@sinclair.provo.novell.com>
X-AOL-IP: 68.35.55.152
X-Mailer: Unknown (No Version)
X-AOL-Test: Testing
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576
Cc: Duane Buss <DBuss@novell.com>, ldapext@ietf.org,
        Zhanna Tsitkova <ZTsitkova@novell.com>,
        Tammy Green <TGREEN@novell.com>
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richm@stanfordalumni.org
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1532292881=="
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
X-Spam-Score: 0.6 (/)
X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e


--===============1532292881==
Content-Type: multipart/alternative;
	boundary="------------070709060102000909040503"


--------------070709060102000909040503
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

jimse@novell.com wrote:

> While I worry a bit about your implementation (though it's not really 
> my place to), I agree with your final assessment, we should change 
> these to NO-USER-MODIFICATION.
>  
> Anyone disagree?

No.  Our implementation does not have these attributes as 
NO-USER-MODIFICATION but it shouldn't be a problem to change them.

>  
> Jim
>
> >>> Howard Chu <hyc@highlandsun.com> 4/26/05 8:41 AM >>>
> I kept meaning to raise this question, but it seems to have fallen thru
> the cracks. For the OpenLDAP implementation, I needed to change these
> operational attributes to NO-USER-MODIFICATION:
> pwdChangedTime, pwdGraceUseTime, and pwdHistory
>
> We have a problem because of the way we process a password change - if a
> user is changing their own password, that Modify request is performed
> using the user's identity. To do bookkeeping on the above operational
> attributes, we internally append some modify operations to the user's
> Modify request, and then the augmented request is passed down to the
> usual Modify processing. One other factor in our implementation is that
> user-modifiable attributes are subject to ACL checks, non-modifiable
> attributes are not. So, userPassword is user-modifiable, and typically
> users are given permission to write their own password. But they
> shouldn't have permission to write the above three attributes, because
> then they can just bypass a lot of the policies that rely on those
> attributes.
>
> So with the default definitions, we have a problem because the user may
> have permission to update the userPassword attr, but no permissions to
> the other attrs.
>
> Alternatively we can break things up into two separate Modify
> operations, doing the user's original request and then using system
> privileges to handle the bookkeeping, but I'm not keen on that approach.
> It introduces some lag in a replication scenario, where the password
> change itself will get replicated separately from the bookkeeping update.
>
> Fundamentally I believe NO-USER-MODIFICATION is appropriate for these
> attributes. Issues with our implementation can be worked around, but I'd
> rather clear this up regardless.
>
> -- 
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> http://www.symas.com <http://www.symas.com/> http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support
>
> _______________________________________________
> Ldapext mailing list
> Ldapext@ietf.org <mailto:Ldapext@ietf.org>
> https://www1.ietf.org/mailman/listinfo/ldapext
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Ldapext mailing list
>Ldapext@ietf.org
>https://www1.ietf.org/mailman/listinfo/ldapext
>  
>

--------------070709060102000909040503
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<a class="moz-txt-link-abbreviated" href="mailto:jimse@novell.com">jimse@novell.com</a> wrote:
<blockquote cite="mids26f4df9.041@sinclair.provo.novell.com" type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta content="MSHTML 6.00.2900.2627" name="GENERATOR">
  <div>While I worry a bit about your implementation (though it's not
really my place to), I agree with your final assessment, we should
change these to NO-USER-MODIFICATION.</div>
  <div>&nbsp;</div>
  <div>Anyone disagree?</div>
</blockquote>
No.&nbsp; Our implementation does not have these attributes as
NO-USER-MODIFICATION but it shouldn't be a problem to change them.<br>
<blockquote cite="mids26f4df9.041@sinclair.provo.novell.com" type="cite">
  <div>&nbsp;</div>
  <div>Jim<br>
  <br>
&gt;&gt;&gt; Howard Chu <a class="moz-txt-link-rfc2396E" href="mailto:hyc@highlandsun.com">&lt;hyc@highlandsun.com&gt;</a> 4/26/05 8:41 AM
&gt;&gt;&gt;<br>
I kept meaning to raise this question, but it seems to have fallen thru
  <br>
the cracks. For the OpenLDAP implementation, I needed to change these <br>
operational attributes to NO-USER-MODIFICATION:<br>
pwdChangedTime, pwdGraceUseTime, and pwdHistory<br>
  <br>
We have a problem because of the way we process a password change - if
a <br>
user is changing their own password, that Modify request is performed <br>
using the user's identity. To do bookkeeping on the above operational <br>
attributes, we internally append some modify operations to the user's <br>
Modify request, and then the augmented request is passed down to the <br>
usual Modify processing. One other factor in our implementation is that
  <br>
user-modifiable attributes are subject to ACL checks, non-modifiable <br>
attributes are not. So, userPassword is user-modifiable, and typically <br>
users are given permission to write their own password. But they <br>
shouldn't have permission to write the above three attributes, because <br>
then they can just bypass a lot of the policies that rely on those <br>
attributes.<br>
  <br>
So with the default definitions, we have a problem because the user may
  <br>
have permission to update the userPassword attr, but no permissions to <br>
the other attrs.<br>
  <br>
Alternatively we can break things up into two separate Modify <br>
operations, doing the user's original request and then using system <br>
privileges to handle the bookkeeping, but I'm not keen on that
approach. <br>
It introduces some lag in a replication scenario, where the password <br>
change itself will get replicated separately from the bookkeeping
update.<br>
  <br>
Fundamentally I believe NO-USER-MODIFICATION is appropriate for these <br>
attributes. Issues with our implementation can be worked around, but
I'd <br>
rather clear this up regardless.<br>
  <br>
-- <br>
-- Howard Chu<br>
Chief Architect, Symas Corp. Director, Highland Sun<br>
  <u><a href="http://www.symas.com/">http://www.symas.com</a></u> <u><a  href="http://highlandsun.com/hyc">http://highlandsun.com/hyc</a></u> <br>
Symas: Premier OpenSource Development and Support<br>
  <br>
_______________________________________________<br>
Ldapext mailing list<br>
  <u><a href="mailto:Ldapext@ietf.org">Ldapext@ietf.org</a></u> <br>
  <u><a href="https://www1.ietf.org/mailman/listinfo/ldapext">https://www1.ietf.org/mailman/listinfo/ldapext</a></u>
  <br>
  </div>
  <pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Ldapext mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ldapext@ietf.org">Ldapext@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www1.ietf.org/mailman/listinfo/ldapext">https://www1.ietf.org/mailman/listinfo/ldapext</a>
  </pre>
</blockquote>
</body>
</html>

--------------070709060102000909040503--


--===============1532292881==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext

--===============1532292881==--



From ldapext-bounces@ietf.org  Wed Apr 27 18:14:34 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13852
	for <ldapext-archive@ietf.org>; Wed, 27 Apr 2005 18:14:34 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DQv0U-0004Fo-Ge
	for ldapext-archive@ietf.org; Wed, 27 Apr 2005 18:27:46 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQuml-0003PA-Sw; Wed, 27 Apr 2005 18:13:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQumj-0003Ot-US
	for ldapext@megatron.ietf.org; Wed, 27 Apr 2005 18:13:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13730
	for <ldapext@ietf.org>; Wed, 27 Apr 2005 18:13:31 -0400 (EDT)
Received: from cust3103.vic01.dataco.com.au ([202.63.62.31]
	helo=amos.eb2bcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DQuzT-0004Ce-Ax
	for ldapext@ietf.org; Wed, 27 Apr 2005 18:26:44 -0400
Received: from [192.168.1.159] (10.1.2.225) by amos.eb2bcom.com (7.1.016.1)
	(authenticated as andrew.sciberras)
	id 4236430A00003D25; Thu, 28 Apr 2005 08:22:53 +1000
Message-ID: <42700F0B.1060406@eB2Bcom.com>
Date: Thu, 28 Apr 2005 08:15:39 +1000
From: Andrew Sciberras <andrew.sciberras@eB2Bcom.com>
Organization: eB2Bcom
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jim Sermersheim <jimse@novell.com>
Subject: Re: [ldapext] draft-behera-ldap-password-policy - operational	attrs
References: <s26f4df9.041@sinclair.provo.novell.com>
In-Reply-To: <s26f4df9.041@sinclair.provo.novell.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Content-Transfer-Encoding: 7bit
Cc: Duane Buss <DBuss@novell.com>, ldapext@ietf.org,
        Zhanna Tsitkova <ZTsitkova@novell.com>,
        Tammy Green <TGREEN@novell.com>
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: andrew.sciberras@eB2Bcom.com
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Content-Transfer-Encoding: 7bit

Hi

Jim Sermersheim wrote:
> While I worry a bit about your implementation (though it's not really my 
> place to), I agree with your final assessment, we should change these to 
> NO-USER-MODIFICATION.
>  
> Anyone disagree?

This sounds alright to me.
Since we're actually making some the the state attributes 
NO-USER-MODIFICATION, perhaps we should look at the others as well.
I'm thinking that pwdAccountLockedTime, pwdFailureTime and 
pwdPolicySubentry should also be included in this list.

> Jim

Andrew.

> 
>  >>> Howard Chu <hyc@highlandsun.com> 4/26/05 8:41 AM >>>
> I kept meaning to raise this question, but it seems to have fallen thru
> the cracks. For the OpenLDAP implementation, I needed to change these
> operational attributes to NO-USER-MODIFICATION:
> pwdChangedTime, pwdGraceUseTime, and pwdHistory
> 
> We have a problem because of the way we process a password change - if a
> user is changing their own password, that Modify request is performed
> using the user's identity. To do bookkeeping on the above operational
> attributes, we internally append some modify operations to the user's
> Modify request, and then the augmented request is passed down to the
> usual Modify processing. One other factor in our implementation is that
> user-modifiable attributes are subject to ACL checks, non-modifiable
> attributes are not. So, userPassword is user-modifiable, and typically
> users are given permission to write their own password. But they
> shouldn't have permission to write the above three attributes, because
> then they can just bypass a lot of the policies that rely on those
> attributes.
> 
> So with the default definitions, we have a problem because the user may
> have permission to update the userPassword attr, but no permissions to
> the other attrs.
> 
> Alternatively we can break things up into two separate Modify
> operations, doing the user's original request and then using system
> privileges to handle the bookkeeping, but I'm not keen on that approach.
> It introduces some lag in a replication scenario, where the password
> change itself will get replicated separately from the bookkeeping update.
> 
> Fundamentally I believe NO-USER-MODIFICATION is appropriate for these
> attributes. Issues with our implementation can be worked around, but I'd
> rather clear this up regardless.
> 
> -- 
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> _http://www.symas.com <http://www.symas.com/>_ _http://highlandsun.com/hyc_
> Symas: Premier OpenSource Development and Support
> 
> _______________________________________________
> Ldapext mailing list
> _Ldapext@ietf.org <mailto:Ldapext@ietf.org>_
> _https://www1.ietf.org/mailman/listinfo/ldapext_
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ldapext mailing list
> Ldapext@ietf.org
> https://www1.ietf.org/mailman/listinfo/ldapext



_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Fri Apr 29 11:33:53 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06790
	for <ldapext-archive@ietf.org>; Fri, 29 Apr 2005 11:33:52 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DRXiA-0001AO-W9
	for ldapext-archive@ietf.org; Fri, 29 Apr 2005 11:47:27 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRXTS-0001WF-AQ; Fri, 29 Apr 2005 11:32:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRXTR-0001W6-CD
	for ldapext@megatron.ietf.org; Fri, 29 Apr 2005 11:32:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06563
	for <ldapext@ietf.org>; Fri, 29 Apr 2005 11:32:10 -0400 (EDT)
Received: from brmea-mail-4.sun.com ([192.18.98.36])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRXgW-000124-85
	for ldapext@ietf.org; Fri, 29 Apr 2005 11:45:45 -0400
Received: from phys-gadget-1 ([129.156.85.171])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j3TFW9i9011567
	for <ldapext@ietf.org>; Fri, 29 Apr 2005 09:32:10 -0600 (MDT)
Received: from conversion-daemon.gadget-mail1.uk.sun.com by
	gadget-mail1.uk.sun.com
	(iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
	id <0IFP00L01SCMPC@gadget-mail1.uk.sun.com>
	(original mail from Ludovic.Poitou@Sun.COM) for ldapext@ietf.org; Fri,
	29 Apr 2005 16:32:08 +0100 (BST)
Received: from [129.157.211.83]
	(dhcp-gnb07-211-83.France.Sun.COM [129.157.211.83]) by
	gadget-mail1.uk.sun.com
	(iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
	with ESMTPA id <0IFP00J8BSHKY8@gadget-mail1.uk.sun.com>; Fri,
	29 Apr 2005 16:32:08 +0100 (BST)
Date: Fri, 29 Apr 2005 17:32:14 +0200
From: Ludovic Poitou <Ludovic.Poitou@Sun.COM>
Subject: Re: [ldapext] draft-behera-ldap-password-policy - operational	attrs
In-reply-to: <42700F0B.1060406@eB2Bcom.com>
To: andrew.sciberras@eB2Bcom.com
Message-id: <4272537E.1000303@sun.com>
Organization: Sun Microsystems Inc.
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
References: <s26f4df9.041@sinclair.provo.novell.com>
	<42700F0B.1060406@eB2Bcom.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
Content-Transfer-Encoding: 7BIT
Cc: Duane Buss <DBuss@novell.com>, ldapext@ietf.org,
        Tammy Green <TGREEN@novell.com>,
        Zhanna Tsitkova <ZTsitkova@novell.com>,
        Jim Sermersheim <jimse@novell.com>
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813
Content-Transfer-Encoding: 7BIT

I also agree.

Ludovic.

Andrew Sciberras wrote:

> Hi
>
> Jim Sermersheim wrote:
>
>> While I worry a bit about your implementation (though it's not really 
>> my place to), I agree with your final assessment, we should change 
>> these to NO-USER-MODIFICATION.
>>  
>> Anyone disagree?
>
>
> This sounds alright to me.
> Since we're actually making some the the state attributes 
> NO-USER-MODIFICATION, perhaps we should look at the others as well.
> I'm thinking that pwdAccountLockedTime, pwdFailureTime and 
> pwdPolicySubentry should also be included in this list.
>
>> Jim
>
>
> Andrew.
>
>>
>>  >>> Howard Chu <hyc@highlandsun.com> 4/26/05 8:41 AM >>>
>> I kept meaning to raise this question, but it seems to have fallen thru
>> the cracks. For the OpenLDAP implementation, I needed to change these
>> operational attributes to NO-USER-MODIFICATION:
>> pwdChangedTime, pwdGraceUseTime, and pwdHistory
>>
>> We have a problem because of the way we process a password change - if a
>> user is changing their own password, that Modify request is performed
>> using the user's identity. To do bookkeeping on the above operational
>> attributes, we internally append some modify operations to the user's
>> Modify request, and then the augmented request is passed down to the
>> usual Modify processing. One other factor in our implementation is that
>> user-modifiable attributes are subject to ACL checks, non-modifiable
>> attributes are not. So, userPassword is user-modifiable, and typically
>> users are given permission to write their own password. But they
>> shouldn't have permission to write the above three attributes, because
>> then they can just bypass a lot of the policies that rely on those
>> attributes.
>>
>> So with the default definitions, we have a problem because the user may
>> have permission to update the userPassword attr, but no permissions to
>> the other attrs.
>>
>> Alternatively we can break things up into two separate Modify
>> operations, doing the user's original request and then using system
>> privileges to handle the bookkeeping, but I'm not keen on that approach.
>> It introduces some lag in a replication scenario, where the password
>> change itself will get replicated separately from the bookkeeping 
>> update.
>>
>> Fundamentally I believe NO-USER-MODIFICATION is appropriate for these
>> attributes. Issues with our implementation can be worked around, but I'd
>> rather clear this up regardless.
>>
>> -- 
>> -- Howard Chu
>> Chief Architect, Symas Corp. Director, Highland Sun
>> _http://www.symas.com <http://www.symas.com/>_ 
>> _http://highlandsun.com/hyc_
>> Symas: Premier OpenSource Development and Support
>>
>> _______________________________________________
>> Ldapext mailing list
>> _Ldapext@ietf.org <mailto:Ldapext@ietf.org>_
>> _https://www1.ietf.org/mailman/listinfo/ldapext_
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Ldapext mailing list
>> Ldapext@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ldapext
>
>
>
>
> _______________________________________________
> Ldapext mailing list
> Ldapext@ietf.org
> https://www1.ietf.org/mailman/listinfo/ldapext


-- 
Ludovic Poitou                                    Sun Microsystems Inc.
Software Architect                               Directory Server Group
http://blogs.sun.com/Ludo/                             Grenoble, France

Sun Microsystems requires the following notice:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Fri Apr 29 11:40:51 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07503
	for <ldapext-archive@ietf.org>; Fri, 29 Apr 2005 11:40:51 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DRXov-0001UY-IO
	for ldapext-archive@ietf.org; Fri, 29 Apr 2005 11:54:25 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRXaq-0003y8-Ja; Fri, 29 Apr 2005 11:39:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRXac-0003xh-3L
	for ldapext@megatron.ietf.org; Fri, 29 Apr 2005 11:39:38 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07388
	for <ldapext@ietf.org>; Fri, 29 Apr 2005 11:39:35 -0400 (EDT)
Received: from cust3103.vic01.dataco.com.au ([202.63.62.31]
	helo=amos.eb2bcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DRXng-0001SR-GF
	for ldapext@ietf.org; Fri, 29 Apr 2005 11:53:09 -0400
Received: from [192.168.1.10] (202.164.196.167) by amos.eb2bcom.com
	(7.1.016.1) (authenticated as andrew.sciberras)
	id 4236430A0000401C; Sat, 30 Apr 2005 01:48:52 +1000
Message-ID: <427255BA.1080800@eB2Bcom.com>
Date: Sat, 30 Apr 2005 01:41:46 +1000
From: Andrew Sciberras <andrew.sciberras@eB2Bcom.com>
Organization: eB2Bcom
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ludovic Poitou <Ludovic.Poitou@Sun.COM>
Subject: Re: [ldapext] draft-behera-ldap-password-policy - operational	attrs
References: <s26f4df9.041@sinclair.provo.novell.com>	<42700F0B.1060406@eB2Bcom.com>
	<4272537E.1000303@sun.com>
In-Reply-To: <4272537E.1000303@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Content-Transfer-Encoding: 7bit
Cc: Duane Buss <DBuss@novell.com>, ldapext@ietf.org,
        Tammy Green <TGREEN@novell.com>,
        Zhanna Tsitkova <ZTsitkova@novell.com>,
        Jim Sermersheim <jimse@novell.com>
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: andrew.sciberras@eB2Bcom.com
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e
Content-Transfer-Encoding: 7bit

I suppose I should note that I have intentionally omitted pwdReset from 
the attributes that require NO-USER-MODIFICATION.
This is due to the fact that I believe an administrator should be able 
to modify this value at their discretion to force a user to change their 
password.

Andrew Sciberras.

Ludovic Poitou wrote:
> I also agree.
> 
> Ludovic.
> 
> Andrew Sciberras wrote:
> 
>> Hi
>>
>> Jim Sermersheim wrote:
>>
>>> While I worry a bit about your implementation (though it's not really 
>>> my place to), I agree with your final assessment, we should change 
>>> these to NO-USER-MODIFICATION.
>>>  
>>> Anyone disagree?
>>
>>
>>
>> This sounds alright to me.
>> Since we're actually making some the the state attributes 
>> NO-USER-MODIFICATION, perhaps we should look at the others as well.
>> I'm thinking that pwdAccountLockedTime, pwdFailureTime and 
>> pwdPolicySubentry should also be included in this list.
>>
>>> Jim
>>
>>
>>
>> Andrew.
>>
>>>
>>>  >>> Howard Chu <hyc@highlandsun.com> 4/26/05 8:41 AM >>>
>>> I kept meaning to raise this question, but it seems to have fallen thru
>>> the cracks. For the OpenLDAP implementation, I needed to change these
>>> operational attributes to NO-USER-MODIFICATION:
>>> pwdChangedTime, pwdGraceUseTime, and pwdHistory
>>>
>>> We have a problem because of the way we process a password change - if a
>>> user is changing their own password, that Modify request is performed
>>> using the user's identity. To do bookkeeping on the above operational
>>> attributes, we internally append some modify operations to the user's
>>> Modify request, and then the augmented request is passed down to the
>>> usual Modify processing. One other factor in our implementation is that
>>> user-modifiable attributes are subject to ACL checks, non-modifiable
>>> attributes are not. So, userPassword is user-modifiable, and typically
>>> users are given permission to write their own password. But they
>>> shouldn't have permission to write the above three attributes, because
>>> then they can just bypass a lot of the policies that rely on those
>>> attributes.
>>>
>>> So with the default definitions, we have a problem because the user may
>>> have permission to update the userPassword attr, but no permissions to
>>> the other attrs.
>>>
>>> Alternatively we can break things up into two separate Modify
>>> operations, doing the user's original request and then using system
>>> privileges to handle the bookkeeping, but I'm not keen on that approach.
>>> It introduces some lag in a replication scenario, where the password
>>> change itself will get replicated separately from the bookkeeping 
>>> update.
>>>
>>> Fundamentally I believe NO-USER-MODIFICATION is appropriate for these
>>> attributes. Issues with our implementation can be worked around, but I'd
>>> rather clear this up regardless.
>>>
>>> -- 
>>> -- Howard Chu
>>> Chief Architect, Symas Corp. Director, Highland Sun
>>> _http://www.symas.com <http://www.symas.com/>_ 
>>> _http://highlandsun.com/hyc_
>>> Symas: Premier OpenSource Development and Support
>>>
>>> _______________________________________________
>>> Ldapext mailing list
>>> _Ldapext@ietf.org <mailto:Ldapext@ietf.org>_
>>> _https://www1.ietf.org/mailman/listinfo/ldapext_
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Ldapext mailing list
>>> Ldapext@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/ldapext
>>
>>
>>
>>
>>
>> _______________________________________________
>> Ldapext mailing list
>> Ldapext@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ldapext
> 
> 
> 

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Fri Apr 29 11:58:19 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09272
	for <ldapext-archive@ietf.org>; Fri, 29 Apr 2005 11:58:19 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DRY5p-0002Hp-Ja
	for ldapext-archive@ietf.org; Fri, 29 Apr 2005 12:11:53 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRXqt-0007G4-56; Fri, 29 Apr 2005 11:56:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRXqr-0007Fz-SU
	for ldapext@megatron.ietf.org; Fri, 29 Apr 2005 11:56:26 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09143
	for <ldapext@ietf.org>; Fri, 29 Apr 2005 11:56:23 -0400 (EDT)
Received: from highlandsun.propagation.net ([66.221.212.168])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRY3x-0002Au-Mc
	for ldapext@ietf.org; Fri, 29 Apr 2005 12:09:58 -0400
Received: from [127.0.0.1] (highlandsun.com [66.221.212.169])
	by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id
	j3TFuJpk016293; Fri, 29 Apr 2005 09:56:19 -0600
Message-ID: <42725926.8010109@highlandsun.com>
Date: Fri, 29 Apr 2005 08:56:22 -0700
From: Howard Chu <hyc@highlandsun.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.8b2) Gecko/20050419
MIME-Version: 1.0
To: andrew.sciberras@eB2Bcom.com
Subject: Re: [ldapext] draft-behera-ldap-password-policy - operational	attrs
References: <s26f4df9.041@sinclair.provo.novell.com>	<42700F0B.1060406@eB2Bcom.com>	<4272537E.1000303@sun.com>
	<427255BA.1080800@eB2Bcom.com>
In-Reply-To: <427255BA.1080800@eB2Bcom.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365
Content-Transfer-Encoding: 7bit
Cc: Duane Buss <DBuss@novell.com>, ldapext@ietf.org,
        Tammy Green <TGREEN@novell.com>,
        Ludovic Poitou <Ludovic.Poitou@Sun.COM>,
        Zhanna Tsitkova <ZTsitkova@novell.com>,
        Jim Sermersheim <jimse@novell.com>
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab
Content-Transfer-Encoding: 7bit

Andrew Sciberras wrote:
> I suppose I should note that I have intentionally omitted pwdReset from 
> the attributes that require NO-USER-MODIFICATION.
> This is due to the fact that I believe an administrator should be able 
> to modify this value at their discretion to force a user to change their 
> password.

Understood. I'm in agreement there too.

> Andrew Sciberras.
> 
> Ludovic Poitou wrote:
> 
>> I also agree.
>>
>> Ludovic.
>>
>> Andrew Sciberras wrote:
>>
>>> Hi
>>>
>>> Jim Sermersheim wrote:
>>>
>>>> While I worry a bit about your implementation (though it's not 
>>>> really my place to), I agree with your final assessment, we should 
>>>> change these to NO-USER-MODIFICATION.
>>>>  
>>>> Anyone disagree?
>>>
>>>
>>>
>>>
>>> This sounds alright to me.
>>> Since we're actually making some the the state attributes 
>>> NO-USER-MODIFICATION, perhaps we should look at the others as well.
>>> I'm thinking that pwdAccountLockedTime, pwdFailureTime and 
>>> pwdPolicySubentry should also be included in this list.
>>>
>>>> Jim
>>>
>>>
>>>
>>>
>>> Andrew.
>>>
>>>>
>>>>  >>> Howard Chu <hyc@highlandsun.com> 4/26/05 8:41 AM >>>
>>>> I kept meaning to raise this question, but it seems to have fallen thru
>>>> the cracks. For the OpenLDAP implementation, I needed to change these
>>>> operational attributes to NO-USER-MODIFICATION:
>>>> pwdChangedTime, pwdGraceUseTime, and pwdHistory
>>>>
>>>> We have a problem because of the way we process a password change - 
>>>> if a
>>>> user is changing their own password, that Modify request is performed
>>>> using the user's identity. To do bookkeeping on the above operational
>>>> attributes, we internally append some modify operations to the user's
>>>> Modify request, and then the augmented request is passed down to the
>>>> usual Modify processing. One other factor in our implementation is that
>>>> user-modifiable attributes are subject to ACL checks, non-modifiable
>>>> attributes are not. So, userPassword is user-modifiable, and typically
>>>> users are given permission to write their own password. But they
>>>> shouldn't have permission to write the above three attributes, because
>>>> then they can just bypass a lot of the policies that rely on those
>>>> attributes.
>>>>
>>>> So with the default definitions, we have a problem because the user may
>>>> have permission to update the userPassword attr, but no permissions to
>>>> the other attrs.
>>>>
>>>> Alternatively we can break things up into two separate Modify
>>>> operations, doing the user's original request and then using system
>>>> privileges to handle the bookkeeping, but I'm not keen on that 
>>>> approach.
>>>> It introduces some lag in a replication scenario, where the password
>>>> change itself will get replicated separately from the bookkeeping 
>>>> update.
>>>>
>>>> Fundamentally I believe NO-USER-MODIFICATION is appropriate for these
>>>> attributes. Issues with our implementation can be worked around, but 
>>>> I'd
>>>> rather clear this up regardless.
>>>>
>>>> -- 
>>>> -- Howard Chu
>>>> Chief Architect, Symas Corp. Director, Highland Sun
>>>> _http://www.symas.com <http://www.symas.com/>_ 
>>>> _http://highlandsun.com/hyc_
>>>> Symas: Premier OpenSource Development and Support
>>>>
>>>> _______________________________________________
>>>> Ldapext mailing list
>>>> _Ldapext@ietf.org <mailto:Ldapext@ietf.org>_
>>>> _https://www1.ietf.org/mailman/listinfo/ldapext_
>>>>
>>>>
>>>> ------------------------------------------------------------------------ 
>>>>
>>>>
>>>> _______________________________________________
>>>> Ldapext mailing list
>>>> Ldapext@ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/ldapext
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Ldapext mailing list
>>> Ldapext@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/ldapext
>>
>>
>>
>>
> 
> _______________________________________________
> Ldapext mailing list
> Ldapext@ietf.org
> https://www1.ietf.org/mailman/listinfo/ldapext
> 


-- 
   -- Howard Chu
   Chief Architect, Symas Corp.       Director, Highland Sun
   http://www.symas.com               http://highlandsun.com/hyc
   Symas: Premier OpenSource Development and Support

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-bounces@ietf.org  Thu May 12 12:26:46 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08899
	for <ldapext-archive@ietf.org>; Thu, 12 May 2005 12:26:46 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DWGmA-00066o-Gu
	for ldapext-archive@ietf.org; Thu, 12 May 2005 12:43:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DWGUe-00049G-6N; Thu, 12 May 2005 12:25:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DWGUc-00049B-KD
	for ldapext@megatron.ietf.org; Thu, 12 May 2005 12:24:59 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08817
	for <ldapext@ietf.org>; Thu, 12 May 2005 12:24:55 -0400 (EDT)
Received: from palrel11.hp.com ([156.153.255.246])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWGkM-00064h-6N
	for ldapext@ietf.org; Thu, 12 May 2005 12:41:15 -0400
Received: from cacexg13.americas.cpqcorp.net (cacexg13.americas.cpqcorp.net
	[16.92.1.76]) by palrel11.hp.com (Postfix) with ESMTP id 9CE70352F;
	Thu, 12 May 2005 09:24:38 -0700 (PDT)
Received: from cacexc10.americas.cpqcorp.net ([16.92.1.47]) by
	cacexg13.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 12 May 2005 09:24:36 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 12 May 2005 09:24:35 -0700
Message-ID: <632116003944094FB495E72A6EDB90B201269406@cacexc10.americas.cpqcorp.net>
Thread-Index: AcVXB5o4GOlQN+2wQt+Q6Lf4yAq9Ig==
From: "Neal-Joslin, Robert (HP-UX Lab R&D)" <bob.joslin@hp.com>
To: "Ludovic Poitou" <Ludovic.Poitou@Sun.COM>, <andrew.sciberras@eB2Bcom.com>
X-OriginalArrivalTime: 12 May 2005 16:24:36.0388 (UTC)
	FILETIME=[16852E40:01C5570F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c
Content-Transfer-Encoding: quoted-printable
Cc: Duane Buss <DBuss@novell.com>, ldapext@ietf.org,
        Tammy Green <TGREEN@novell.com>,
        Zhanna Tsitkova <ZTsitkova@novell.com>,
        Jim Sermersheim <jimse@novell.com>
Subject: [ldapext] (no subject)
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a
Content-Transfer-Encoding: quoted-printable


While I understand the reasoning for the suggestions, I thought I should
bring out one point for discussion:

Is not one purpose of standardizing password/account policy to allow
other agents (aside from the DUA itself) to interact with this policy?
If so, then changing some of these attributes to NO-USER-MODIFICATION
limits the ability of these agents to interact with the policy.  What if
the agent wants to use this schema to manage the policy itself?

Bob

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20

I also agree.

Ludovic.

Andrew Sciberras wrote:

> Hi
>
> Jim Sermersheim wrote:
>
>> While I worry a bit about your implementation (though it's not really
>> my place to), I agree with your final assessment, we should change
>> these to NO-USER-MODIFICATION.
>>=20
>> Anyone disagree?
>
>
> This sounds alright to me.
> Since we're actually making some the the state attributes
> NO-USER-MODIFICATION, perhaps we should look at the others as well.
> I'm thinking that pwdAccountLockedTime, pwdFailureTime and
> pwdPolicySubentry should also be included in this list.
>
>> Jim
>
>
> Andrew.
>
>>
>>  >>> Howard Chu <hyc@highlandsun.com> 4/26/05 8:41 AM >>>
>> I kept meaning to raise this question, but it seems to have fallen
thru
>> the cracks. For the OpenLDAP implementation, I needed to change these
>> operational attributes to NO-USER-MODIFICATION:
>> pwdChangedTime, pwdGraceUseTime, and pwdHistory
>>
>> We have a problem because of the way we process a password change -
if a
>> user is changing their own password, that Modify request is performed
>> using the user's identity. To do bookkeeping on the above operational
>> attributes, we internally append some modify operations to the user's
>> Modify request, and then the augmented request is passed down to the
>> usual Modify processing. One other factor in our implementation is
that
>> user-modifiable attributes are subject to ACL checks, non-modifiable
>> attributes are not. So, userPassword is user-modifiable, and
typically
>> users are given permission to write their own password. But they
>> shouldn't have permission to write the above three attributes,
because
>> then they can just bypass a lot of the policies that rely on those
>> attributes.
>>
>> So with the default definitions, we have a problem because the user
may
>> have permission to update the userPassword attr, but no permissions
to
>> the other attrs.
>>
>> Alternatively we can break things up into two separate Modify
>> operations, doing the user's original request and then using system
>> privileges to handle the bookkeeping, but I'm not keen on that
approach.
>> It introduces some lag in a replication scenario, where the password
>> change itself will get replicated separately from the bookkeeping
>> update.
>>
>> Fundamentally I believe NO-USER-MODIFICATION is appropriate for these
>> attributes. Issues with our implementation can be worked around, but
I'd
>> rather clear this up regardless.
>>
>> --
>> -- Howard Chu
>> Chief Architect, Symas Corp. Director, Highland Sun
>> _http://www.symas.com <http://www.symas.com/>
<http://www.symas.com/>_
>> _http://highlandsun.com/hyc_
>> Symas: Premier OpenSource Development and Support
>>
>> _______________________________________________
>> Ldapext mailing list
>> _Ldapext@ietf.org <mailto:Ldapext@ietf.org>_
>> _https://www1.ietf.org/mailman/listinfo/ldapext_
>>
>>
>>
------------------------------------------------------------------------
>>
>> _______________________________________________
>> Ldapext mailing list
>> Ldapext@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ldapext
>
>
>
>
> _______________________________________________
> Ldapext mailing list
> Ldapext@ietf.org
> https://www1.ietf.org/mailman/listinfo/ldapext


--
Ludovic Poitou                                    Sun Microsystems Inc.
Software Architect                               Directory Server Group
http://blogs.sun.com/Ludo/                             Grenoble, France

Sun Microsystems requires the following notice:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext



_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext