RE: Operations crossing replication contexts

Sounds good. Please revise and publish the URP spec based
on all comments but those relevant to this thread and we'll
consider this WG Last Call of URP over officially - it was
a while ago actually, but discussions kept going several days
past the actual deadline...

However, until we know specifically what the impact
could be on the URP document, I don't plan to recommend
that the Apps ADs review it for IESG consideration until
after the subsequent postings relevant to this thread.

And then, we may have to do another revision of the URP
document with a subsequent WG Last Call based on any changes
that the WG feels need be made to it.

If after discussing the additional postings that you
plan to make the WG indicates that no additional changes
need to be made to URP, John and I could make a recommendation
to the Apps ADs at that time to review the document without
further changes or another WG Last Call.

Chris Apple
Program Manager - Integration Services
United Messaging Inc.
<http://www.unitedmessaging.com>
<mailto:[email protected]> 
(V) +1 610 425 2860


-----Original Message-----
From: Steven Legg [mailto:[email protected]]
Sent: Monday, October 08, 2001 12:48 AM
To: 'Christopher Apple'
Cc: [email protected]
Subject: RE: Operations crossing replication contexts




Chris,

Christopher Apple wrote:
> Strongly agree also. I can't see any real benefit to the folks
> who actually have to use LDUP implementations to have to cope
> with two ways of handling LDAPv3 replication depending on
> how many contexts per server they need.
> 
> Steven: when could you have a revised I-D posted to the list
> plus some bullets indicating changes implied for other documents?

I can submit a revised URP draft with the changes already agreed
during the last call period within a week or so, but for the changes
required to properly support partial replication, I think the best
approach is for me to write up the architectural details of what
I've been working on and post that to the list. I can do that in
parts over the next month. Once everyone has had a chance to think
about it we can decide what amendments need to be made to which
documents, including further changes to URP.

Regards,
Steven

> 
> Chris Apple
> Program Manager - Integration Services
> United Messaging Inc.
> <http://www.unitedmessaging.com>
> <mailto:[email protected]> 
> (V) +1 610 425 2860
> 
> 
> -----Original Message-----
> From: Mark Smith [mailto:[email protected]]
> Sent: Wednesday, October 03, 2001 9:14 AM
> To: Timothy Hahn
> Cc: [email protected]
> Subject: Re: Operations crossing replication contexts
> 
> 
> 
> Timothy Hahn wrote:
> > 
> > Steven,
> > 
> > I really feel that LDUP should address the issues involved 
> in a single
> > server handling multiple replication contexts.  If we don't 
> I think we
> > would be miss the mark by providing a replication model 
> that would not
> > meet the needs of LDAP directory deployments.
> > 
> > I agree that providing this implies changes to all the replication
> > drafts - with exception, perhaps, of the requirements.  And 
> since this
> > probably has implications on the LDUP update protocol as well as the
> > information model, it seems to me we should take the time 
> to build it
> > right now rather than have to build a whole new "version" to support
> > mulitple replication contexts in a single server.
> 
> I strongly agree.  A directory server that supports only one 
> replication
> context, presumably for one contiguous subtree for the DIT, 
> will not be
> usable in many situations.
> 
> -- 
> Mark Smith
> Netscape
>

BEGIN:VCARD
VERSION:2.1
N:Apple;Christopher
FN:Christopher Apple (E-mail)
ORG:UMI
TITLE:Program Manager
TEL;WORK;VOICE:(610) 425-2860
TEL;HOME;VOICE:(215) 873-0850
TEL;CELL;VOICE:(610) 585-4241
TEL;WORK;FAX:(610) 425-6501
ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of America
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:1161 McDermott Drive=0D=0AWest Chester, Pa. 19380=0D=0AUnited States of Amer=
ica
EMAIL;PREF;INTERNET:[email protected]
REV:20010925T181636Z
END:VCARD