RE: RE: Architecure Draft [Dont Use Copy]

["Slone, Skip" <skip.slone@xxxxxxxx>]

Pardon the intrusion, but since I was heavily involved in the development of
X.500 concepts such as DontUseCopy, I might be able to clear up the
confusion by clarifying the intent of the DontUseCopy service control.  The
semantics are actually quite simple. Specifically...

1) A server holding entries is required to know for each entry it holds
whether that entry is the original or a copy.  How it represents this
internally is a local matter -- what matters is that it KNOW. (It would be
perfectly reasonable for the server to store this knowledge on a
per-replication-unit basis.)

2) A client is allowed to request access to the original. (This request is
on a per-operation basis.)

3) A server processing such a query is obliged to honor that request.

Assuming a server holds a copy (not the original) of a certain entry, what
this means is the following:

a) if it receives a request for that entry and DontUseCopy is NOT set, it is
free to return the copy.

b) if it receives a request for that entry and DontUseCopy IS set, it must
either chain the request or return a referal.  In the absence of chaining
(e.g., in an LDAP world), this leaves a referal as the ONLY VALID REPONSE to
the query. 

It would be absolutely incorrect for a server to respond, in effect, by
saying "I don't care whether you want the original, here's what I know about
the entry. Now YOU go figure out whether what I just gave you was the
original."  In other words, when the original is requested, a server holding
a copy simply DOES NOT HOLD the requested information and MUST NOT return a
substitute. 

Note that there's nothing to prevent a client from optimizing its
performance by learning where the originals are stored, and the subentry
publication could provide a nice optimization mechanism. However, forcing
the client to do some out-of-band operation in order to simply access the
original provides for highly inconsistent distributed behavior.

I hope this helps!

 -- Skip Slone
    Lockheed Martin Corporation



> -----Original Message-----
> From:	Sukanta Ganguly [SMTP:SGANGULY@xxxxxxxxxx]
> Sent:	Friday, August 21, 1998 12:22 PM
> To:	merrells@xxxxxxxxxxxx; ED#032#REED@xxxxxxxxxx;
> Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx; Lloyd@xxxxxxxxxxxxxxxxxxxx
> Cc:	ietf-ldup@xxxxxxx
> Subject:	Re: RE: Architecure Draft [Dont Use Copy]
> 
> Hi,
>    Does that mean the LDAP Server needs to store the information about the
> copy/replica as some attribute value. First of all why would this be an
> issue at all. If it pertains to replication then the replication unit
> decides what needs to be replicated and the source and target of the
> replication. Why would one need to store information specific to
> particular attributes breaking down the concept of replication unit per
> se. I don't see this being a problem even in the transaction operation.
> 
> Sukanta Ganguly
> 
> >>> "Ed Reed" <ED#032#REED@xxxxxxxxxx> 08/21 9:10 AM >>>
> Alan - you are, of course, correct.  A Resolve Name operation which 
> does this is certainly indicated as another possible extended operation
> for LDAP, which I hope we will get to as we add "full" distributed
> behavior to LDAP services and clients.
> 
> Ed
> 
> -------------------
> Ed Reed, Technologist
> Novell, Inc.
> +1 801 861 3320
> 
> >>> Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx> 08/20/1998 19:14:12 >>>
> John - this means more human configuration and more code for the client
> software... than X.500 systems
> regards alan
> 
> > -----Original Message-----
> > From:	John Merrells [SMTP:merrells@xxxxxxxxxxxx] 
> > Sent:	Monday, 10 August 1998 9:09
> > To:	Alan Lloyd
> > Cc:	'LDUP '
> > Subject:	Re: Architecure Draft [Dont Use Copy]
> > 
> > 
> > 
> > Alan Lloyd wrote:
> > 
> > > In x.500 entries can be selected as a copy/replica through the use
> > of
> > > Dont Use Copy in DAP and this is carried in DSP. This means that
> > entries
> > > in the DIT need a notion of master or copy indicators.
> > 
> > Our current thinking is that this bahaviour is up to clients to
> > implement.
> > Information about the LDAP servers hosting the Naming Context is
> > published in sub-entries below the Naming Context. A client that
> > demands high consistency would discover the access point for the
> > Primary Replica and apply all its operations there.
> > 
> > John
>