IETF Logo Mail Archive

Re: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-incr-00.txt

"David Boreham" <david_list@boreham.org> Thu, 21 October 2004 18:17 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01633 for <ldapext-archive@lists.ietf.org>; Thu, 21 Oct 2004 14:17:49 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhKc-0000XV-6a; Thu, 21 Oct 2004 14:06:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKh0Z-0006aY-8m for ldapext@megatron.ietf.org; Thu, 21 Oct 2004 13:45:51 -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 NAA28375 for <ldapext@ietf.org>; Thu, 21 Oct 2004 13:45:49 -0400 (EDT)
Received: from [69.145.82.195] (helo=mail.montana.boreham.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhDC-0001EY-F3 for ldapext@ietf.org; Thu, 21 Oct 2004 13:58:56 -0400
Received: from squirrel (unknown [69.145.82.218]) by mail.montana.boreham.org (Postfix) with SMTP id 0961A11037E for <ldapext@ietf.org>; Thu, 21 Oct 2004 10:45:15 -0700 (PDT)
Message-ID: <053601c4b795$b8b9f020$da529145@mtbrook.bozemanpass.com>
From: David Boreham <david_list@boreham.org>
To: ldapext@ietf.org
References: <6.1.2.0.0.20041020175617.033b0df8@127.0.0.1> <043201c4b780$7695c440$da529145@mtbrook.bozemanpass.com> <6.1.2.0.0.20041021090823.02d578b0@127.0.0.1> <04e301c4b78d$317ffe40$da529145@mtbrook.bozemanpass.com> <6.1.2.0.0.20041021101612.02d7f2d0@127.0.0.1>
Subject: Re: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-incr-00.txt
Date: Thu, 21 Oct 2004 10:45:14 -0700
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
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
Content-Transfer-Encoding: 7bit

> In LDAP, clients may presume server is acting in accordance
> with the X.500 data model.  If the server is unable or
> unwilling to do that, then it should not provide service.

I see, I think you've answered my question: this
feaure should not be implemented by servers that
are participating in a multimaster replication mechanism
with respect to the entry being modified (unless the
server does something unusual to deliver the
required consistency guarantees such as using 2-phase
commit).

It might be worth noting this in the draft, for those
who might ask this question in the future.



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

v2.23.0 | Report a Bug | By Email