home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_a_c / draft-ietf-asid-ldap-repl-info-01.txt < prev    next >
Text File  |  1997-10-07  |  23KB  |  583 lines
  1.  
  2. IETF ASID Working Group                                      Sanjay Jain
  3. Internet Draft                                        Oracle Corporation
  4.                                                        Uppili Srinivasan
  5.                                                       Oracle Corporation
  6.                                                              Gordon Good
  7.                                      Netscape Communications Corporation
  8.                                                                July 1997
  9.  
  10.            
  11.                      Schema for Replication Information
  12.                    <draft-ietf-asid-ldap-repl-info-01.txt>
  13.  
  14.  
  15. I. Status of this Memo
  16.  
  17. This document is an Internet-Draft.  Internet-Drafts are working docume-
  18. nts of the Internet Engineering Task Force (IETF), its areas, and its 
  19. working groups.  Note that other groups may also distribute working doc-
  20. uments as Internet-Drafts.
  21.  
  22. Internet-Drafts are draft documents valid for a maximum of six months
  23. and may be updated, replaced, or obsoleted by other documents at any
  24. time.  It is inappropriate to use Internet- Drafts as reference material
  25. or to cite them other than as ``work in progress.''
  26.  
  27. To learn the current status of any Internet-Draft, please check the
  28. ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
  29. Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
  30. ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
  31.  
  32. Distribution of this memo is unlimited. Editorial comments should be
  33. sent to skjain@us.oracle.com. Technical discussion should take place on
  34. the IETF ASID mailing list (ietf-asid@umich.edu).
  35.  
  36. This Internet Draft expires February 1st, 1998.
  37.  
  38. II. Abstract
  39.  
  40. This document defines a new attribute syntax and an operational attribu-
  41. te type to store replication agreements within the directory.  In addit-
  42. ion it defines a framework to detect whether an entry is a master or 
  43. replica.
  44.  
  45. The replication agreement structure defined here includes a placeholder
  46. to specify the replication protocol associated with an agreement.  This
  47. document itself does not define any replication protocol.  Replication 
  48. protocols and replication agreements are seen as orthogonal issues.  
  49.  
  50. III. Definition Of Terms
  51.  
  52. Consumer          An LDAP server which receives replica updates.
  53.  
  54. Master            An LDAP server holding a master copy of an entry.
  55.  
  56.  
  57.  
  58.  
  59. jain,srinivasan,good       Schema for Replication Information     Page 1
  60. INTERNET-DRAFT     draft-ietf-asid-ldap-repl-info-00.txt     July 1997
  61.  
  62.  
  63. Master Entry      The copy of an entry where all direct LDAP 
  64.                   modifications are performed. In a multi-master 
  65.                   environment, there could exist multiple master copies
  66.                   for an entry.
  67.  
  68. Replication Agreement            
  69.                    An agreement between a supplier and a consumer
  70.                    regarding replication of a full/partial naming
  71.                    context. The main components of a replication
  72.                    agreement are: 
  73.                        . Reference to the supplier
  74.                        . Reference to the consumer
  75.                        . Specification of the directory information to
  76.                          be replicated.
  77.                        . Schedule for updating the replicas.
  78.  
  79. Replica            A copy of an entry where modifications are allowed
  80.                    only through replication updates. I.e. direct LDAP 
  81.                    modifications are not allowed on a replica of an
  82.                    entry. A replica will typically issue a referral to a
  83.                    supplier if a client attempts an update operation.
  84.  
  85. Supplier           An LDAP server which supplies replica updates.
  86.  
  87. IV. Introduction
  88.  
  89. The broadening of interest in LDAP directories beyond their use as front
  90. ends to X.500 and proliferation of stand alone LDAP implementations has
  91. created a need to define standards that would facilitate deployment of
  92. distributed and replicated directory involving multi-vendor implementat-
  93. ions. 
  94.  
  95. The "referrals" draft (Ref[4]) defines ways to create and use knowledge
  96. references.  It lays the foundation for distributed directories by defi-
  97. ning mechanisms that can be used to "glue" the parts of directory infor-
  98. mation tree (DIT) together.  The framework defined here is a step in the
  99. direction to standardize the directory replication process.  Together,
  100. these proposals establish the infrastructure to distribute and replicate
  101. the directory information. 
  102.  
  103. This document defines a new attribute syntax and an operational attribu-
  104. te type to store replication agreements within the directory.  The attr-
  105. ibute is a root DSE attribute.  
  106.  
  107. A replication agreement is established between a consumer and a 
  108. supplier.  Establishment of an agreement is expected to precede any rep-
  109. lication. An agreement specifies, among other things, the replication 
  110. area and the update frequency.  It also identifies the replication prot-
  111. ocol and the parameters that are specific to that protocol.
  112.  
  113.  
  114. While it is desirable for a single LDAP replication protocol to be defi-
  115. ned and standardized, this draft accommodates the possibility of variat-
  116.  
  117. jain,srinivasan,good       Schema for Replication Information     Page 2
  118. INTERNET-DRAFT     draft-ietf-asid-ldap-repl-info-00.txt     July 1997
  119.  
  120.  
  121. ions and versions to be specified in the agreement through a replication
  122. protocol identifier (oid) and associated parameters.  Some of the possi-
  123. ble variations include characteristics such as supplier initiated (push)
  124. , consumer initiated (pull) etc.  
  125.  
  126. Proprietary replication protocols already exist and LDAP directories
  127. will be rolled out into these environments.  Replication protocol oids
  128. can be registered for such protocols as well.  The intent is not to pro-
  129. mote proprietary protocols, but to facilitate painless roll-out of stan-
  130. dards based implementations within pre-existing directory environments.
  131. It is believed that this accommodation in the replication agreements 
  132. would ease adoption of the standards.
  133.  
  134. V. Replication Agreement Establishment and Usage Model
  135.  
  136. Creation of a replication agreement would either be initiated by a human 
  137. administrator or by a consumer.  Identical copies of an agreement would 
  138. exist on the supplier and the consumer.  A replication agreement has to 
  139. exist before replication can take place.  The servers will enforce  rep-
  140. lication exchanges per the terms of an agreement.
  141.  
  142. The replication agreements should be added, deleted or modified using
  143. LDAP "modify" operation on the root DSE. The server should check the 
  144. consistency and acceptability of an agreement  based on local administr-
  145. ative policies. An agreement is considered to be in effect when both the
  146. supplier and consumer have identical copies of the agreement in their
  147. root DSEs. Two agreements are deemed identical when they match according
  148. to the replBindingMatch matching rule defined in this document.
  149.  
  150. It is possible to achieve the effect of the above administrative actions
  151. (creation of replication agreements) through protocol exchanges between
  152. servers, equivalent of the X.500 DOP.  Such protocols may get standardi-
  153. zed in the future.  This draft does not define such a protocol.  It only
  154. defines a standard for the structure and semantics of resulting replica-
  155. tion agreement information.
  156.  
  157. A supplier can maintain different replication agreements with different
  158. consumer servers for a single naming context.  It is also possible for a
  159. consumer to have multiple agreements with one or more suppliers for same
  160. or different naming contexts.  
  161.  
  162.  
  163. VI. Attribute Definitions
  164.  
  165. A. replAgreement
  166.  
  167. ( < ora_onldap_replica_oid1> NAME 'replAgreement' DESC 'describes a rep-
  168. lication agreement between 2 servers' EQUALITY replBindingMatch SYNTAX
  169. 'replBinding' USAGE distributedOperation )
  170.  
  171. 'replAgreement' attribute stores the information about a replication
  172. agreement reached between two servers (consumer and supplier). It is a
  173. multi-valued attribute.  It is a root DSE attribute.
  174.  
  175. jain,srinivasan,good       Schema for Replication Information     Page 3
  176. INTERNET-DRAFT     draft-ietf-asid-ldap-repl-info-00.txt     July 1997
  177.  
  178.  
  179. A replication agreement specifies, among other details, the user entries
  180. and attributes to be replicated from the supplier LDAP server to the
  181. consumer LDAP server.  Normally, the administrative information (Schema,
  182. ACLs etc.), associated with the selected user entries, would also be re-
  183. plicated along with the user entries. 
  184.  
  185. B. supportedReplProtocols
  186.  
  187. ( < ora_onldap_replica_oid2> NAME 'supportedReplProtocols' DESC 'Stores
  188. the OIDS of the supported replication protocols" SYNTAX 'OID' USAGE dis-
  189. tributedOperation)
  190.  
  191. 'supportedReplProtocols' attribute stores the OIDS of the supported rep-
  192. lication protocols.  It is a multi-valued attribute.   It is a root DSE
  193. attribute.
  194.  
  195. C. myRef
  196.  
  197. ( < ora_onldap_replica_oid3> NAME 'myRef' DESC 'LDAP URI without any DN
  198. part. Reference to self.' EQUALITY caseExactIA5Match SYNTAX 'IA5String'
  199. SINGLE_VALUE USAGE dSAOperation ) 
  200.  
  201. 'myRef' is a root DSE attribute .  It is a single valued attribute.  It
  202. contains the LDAP reference (without the DN part) to the server itself.
  203.  
  204. D. masterRef
  205.  
  206. ( < ora_onldap_replica_oid4> NAME 'masterRef' DESC 'LDAP URI without any
  207. DN part' EQUALITY caseExactIA5Match SYNTAX 'IA5String' USAGE dSAOperati-
  208. on ) 
  209.  
  210. 'masterRef' is an operational attribute for every entry (except the DSE
  211. root entry) in the LDAP directory.  It is a multi-valued attribute.  The
  212. values of this attribute refer to the servers which master this entry.  
  213.  
  214. By comparing 'myRef' attribute value and the 'masterRef' attribute valu-
  215. es for an entry,  a server and a directory user can determine whether
  216. the particular copy is a master copy or a replica. When an LDAP client
  217. tries a modify operation on a replica then the server by looking at the
  218. 'masterRef' attribute can return a referral to the master LDAP server.
  219.  
  220. VII. replBinding Syntax
  221.  
  222. ( < ora_onldap_replica_oid5> DESC 'Replication Agreement Syntax' )
  223.  
  224. Attribute values with 'replBinding' syntax are written according to 
  225. following BNF:
  226.  
  227. <replBinding>     ::= "("
  228.                       "AGREEMENTID"            <NumericString>
  229.                       "NAMINGCONTEXT"          <DirectoryString>
  230.                       "SUPPLIER_REFERENCE"     <IA5STRING>
  231.  
  232.  
  233. jain,srinivasan,good       Schema for Replication Information     Page 4
  234. INTERNET-DRAFT     draft-ietf-asid-ldap-repl-info-00.txt     July 1997
  235.  
  236.  
  237.                       "CONSUMER_REFERENCE"     <IA5STRING>
  238.                       ["SUPPLIER_IDENTITY"     <DirectoryString>]
  239.                       ["CONSUMER_IDENTITY"     <DirectoryString>]
  240.                       ["BASEDN"                <DirectoryString>]
  241.                       ["FILTER"                <DirectoryString>]
  242.                       ["SCOPE"                 <0|1|2>]
  243.                       ["ATTRIBUTE_SELECTION    <AttributeSelectionList>]
  244.                       "UPDATE_SCHEDULE"        <UpdateSchedule>
  245.                       ["REPLICATION_PROTOCOL"  <ReplProtocol>]
  246.                       ")"
  247.  
  248. AGREEMENTID is local to the supplier. The server must verify that the 
  249. combination of AGREEMENTID and SUPPLIER_REFERENCE is unique.  Otherwise
  250. the LDAP "modify" operation to enter an agreement should fail with an 
  251. LDAP_CONSTRAINT_VIOLATION (0x13) LDAP error.
  252.  
  253. NAMINGCONTEXT is the DN of the root of the naming context with which the
  254. replication agreement is associated.
  255.  
  256. SUPPLIER_REFERENCE is an LDAP URI [6] (without the DN part) to the supp-
  257. lier.
  258.  
  259. CONSUMER_REFERENCE is an LDAP URI [6] (without the DN part) to the cons-
  260. umer.
  261.  
  262. SUPPLIER_IDENTITY is the identity which the supplier must use to authen-
  263. ticate itself to the consumer for replica update exchanges.  This param-
  264. eter would be most useful in the push model.
  265.  
  266. CONSUMER_IDENTITY is the identity which the consumer must use to authen-
  267. ticate itself to the supplier for replica update exchanges.  This param-
  268. eter would be most useful in the pull model.
  269.  
  270. Note: For security reasons, bind credentials MUST NOT be stored in the
  271. replication agreement attribute.  
  272.  
  273. SUPPLIER_IDENTITY, CONSUMER_IDENTITY and associated credentials may not
  274. actually exist in the directory.  When binding for sending/receiving 
  275. replication updates,  the target server would recognize the 
  276. SUPPLIER_IDENTITY /CONSUMER_IDENTITY and adjust its semantics appropria-
  277. tely.
  278.  
  279. SUPPLIER_IDENTITY and CONSUMER_IDENTITY are both optional parameters of
  280. a replication agreement.
  281.  
  282. BASEDN, FILTER and SCOPE have same semantics as in a LDAP search request
  283. . Default value for BASEDN is the root of the naming context. Default 
  284. value for SCOPE is 2 (whole subtree). 
  285.  
  286. Through ATTRIBUTE_SELECTION one can specify the list of attributes of a
  287. particular object class which should be included/excluded in the replic-
  288. ation.
  289.  
  290.  
  291. jain,srinivasan,good       Schema for Replication Information     Page 5
  292. INTERNET-DRAFT     draft-ietf-asid-ldap-repl-info-00.txt     July 1997
  293.  
  294.  
  295. AttributeSelectionList       ::=     <AttributeSelection> | 
  296.                                      '('<AttributeSelectionList>')'
  297.  
  298. AttributeSelectionList       ::=     <AttributeSelectionList> '$'                                     
  299.                                      <AttributeSelection> |
  300.                                      <AttributeSelection>
  301.  
  302. AttributeSelection           ::=     "(" [<ldapFilter>]
  303.                                          [<AttributeSelectionSpec>]
  304.                                      ")" 
  305.  
  306. <ldap-Filter>                ::=     An LDAP filter as described in [5]
  307.  
  308. If the filter is absent, then the attribute list selection applies to 
  309. all replicated entries.  
  310.  
  311. <AttributeSelectionSpec>     ::=      <IncludeList> | 
  312.                                       <ExcludeList>
  313.  
  314. <IncludeList>                ::=      "INCLUDE"  <AttributeList>
  315.  
  316. <ExcludeList>                ::=      "EXCLUDE"  <AttributeList>            
  317. <AttributeList>              ::=      <AttributeType> |
  318.                                       '(' <AttributeList> ')'
  319.     
  320.  <AttributeList>             ::=      <AttributeList> '$'
  321.                                       <AttributeType> | 
  322.                                       <AttributeType>
  323.  
  324. UPDATE_SCHEDULE specifies the schedule for updating the replica.
  325.  
  326. <UpdateSchedule>             ::=       <ScheduleList> 
  327.  
  328. <ScheduleList>               ::=       <ScheduleItem> | 
  329.                                        '('<ScheduleList>')'
  330.  
  331. <ScheduleList>               ::=       < ScheduleList> '$'                         
  332.                                        <ScheduleItem> |
  333.                                        <ScheduleItem>
  334.  
  335. <ScheduleItem>               ::=       <minute> <hour> <day_of_month> 
  336.                                        <month_of_year> <day_of_week>            
  337.  
  338. <ScheduleItem> has UNIX crontab style syntax and semantics.  The schedu-
  339. le is specified using five fields separated by spaces.  The fields are
  340. integer patterns that specify the following:
  341.  
  342.             minute (0-59)
  343.             hour (0-23)
  344.             day of the month (1-31)
  345.             month of the year (1-12)
  346.             day of the week (0-6 with 0=Sunday)
  347.  
  348.  
  349. jain,srinivasan,good       Schema for Replication Information     Page 6
  350. INTERNET-DRAFT     draft-ietf-asid-ldap-repl-info-00.txt     July 1997
  351.  
  352.  
  353. Each of these five patterns may be either an asterisk (meaning all legal
  354. values) or a list of elements separated by commas.  An element is either
  355. a number or two numbers separated by a minus sign (meaning an inclusive
  356. range).  Note that the specification of days may be made by two fields
  357. (day of the month and day of the week).  Both are adhered to if specifi-
  358. ed as a list of elements.  Times are always interpreted as Greenwich
  359. Mean Time.
  360.  
  361. Examples:
  362.  
  363. 1.Always keep replicas updated immediately:
  364.             UPDATE_SCHEDULE  * * * * *
  365.  
  366. 2. Update replicas at 1 am every day:
  367.             UPDATE_SCHEDULE  * 1 * * *
  368.  
  369. 3. Update replicas every hour between 8am and 5 pm on weekdays, and at 
  370. 1am on weekends:
  371.             UPDATE_SCHEDULE  (* 8-17 * * 1-5 $ * 1 * * 0, 6)
  372. 4. Update replicas every 30 minutes:
  373.             UPDATE_SCHEDULE  0,30 * * * *
  374.  
  375. 5. Update replicas on first and fifteenth of each month as well as on 
  376. every Monday (Example of using two fields for the specification of days)
  377.             UPDATE_SCHEDULE  * * 1,15 * 1
  378.                         
  379.  
  380. REPLICATION_PROTOCOL is the protocol to be used to exchange replica upd-
  381. ates. 
  382.  
  383. ReplProtocol       ::=        "("
  384.                                 "OID"                <oid>
  385.                                 ["PROTOCOL_SPECIFIC" <DirectoryString>]
  386.                               ")"
  387.  
  388.  
  389. VIII. replBindingMatch definition
  390.  
  391. ( < ora_onldap_shadow_oid6> NAME ' replBindingMatch' SYNTAX 'replBinding
  392. ' )
  393.  
  394. Two replication agreements are equal if and only if the AGREEMENTID and
  395. SUPPLIER_REFERENCE match for equality, as determined by the NumericStri-
  396. ngMatch and CaseExactIA5Match matching rules defined in X.520 (1993).
  397.  
  398. IX. Relationship To X.500 Shadowing Agreements
  399.  
  400. LDAP replication agreements are independent of X.500 shadowing agreemen-
  401. ts, although terminology has been borrowed from X.500 and, in general,
  402. the meaning of these terms is equivalent. 
  403.  
  404.  
  405.  
  406.  
  407. jain,srinivasan,good       Schema for Replication Information     Page 7
  408. INTERNET-DRAFT     draft-ietf-asid-ldap-repl-info-00.txt     July 1997
  409.  
  410.  
  411. It is anticipated that LDAP servers which front-end and X.500 server
  412. will advertise the fact that they support X.500 DISP by placing in the 
  413. 'supportedReplProtocols' attribute of the root DSE the OID which repres-
  414. ents X.500 DISP (this OID has not been defined at this time).
  415.  
  416. X. Examples
  417.  
  418. Following are examples of attribute values for replAgreement attribute:
  419.  
  420. 1.  This is an example of a replication agreement between two cooperati-
  421. ng organizations, "ABC Inc." and "XYZ AG".  ABC's LDAP server runs on 
  422. the host "ldap.abc.com" while XYZ's LDAP server runs on the host 
  423. "ldap.mch.xyz.de".  The objective is for both organizations to have a 
  424. copy of the subtree "ou=Sales, o=ABC, c=US". The server "ldap.mch.xyz.de
  425. ", then, is a consumer for the subtree "ou=Sales, o=ABC, c=US", which is
  426. part of the "c=US" naming context held by the supplier. The server "ldap
  427. .abc.com" is the supplier for that subtree. The replica is updated by
  428. the supplier (since only supplier identity isthere in the agreement)
  429. continuously, using the replication protocol identified by the OID '1.2.
  430. 3'.  When connecting to the consumer, the supplier will bind as "cn=rep-
  431. lAdmin,dc=replTree,dc=ldap,dc=mch,dc=xyz,dc=de".  The following replAgr-
  432. eement attribute describes this agreement:
  433.  
  434.          (  AGREEMENTID 123456 NAMINGCONTEXT 'c=us' SUPPLIER_REFERENCE 
  435.             'ldap://ldap.abc.com' CONSUMER_REFERENCE  
  436.             'ldap://ldap.mch.xyz.de' SUPPLIER_IDENTITY 
  437.             'cn=replAdmin,dc=replTree,dc=ldap,dc=mch,dc=xyz,dc=de' 
  438.             BASEDN 'ou=Sales, o=ABC, c=US' SCOPE 2 UPDATE_SCHEDULE * * * 
  439.             * * REPLICATION_PROTOCOL 1.2.3 ) 
  440.  
  441. 2. This example is a refinement of the above agreement.  In addition to
  442. the parameters described above, entries are only replicated if they 
  443. match the filter "(objetclass=person)".  Furthermore, only the attribut-
  444. es cn, sn, telephoneNumber, and mail are replicated, and replication may
  445. only occur between 1 am and 2 am GMT.
  446.  
  447.          (  AGREEMENTID 123456 NAMINGCONTEXT 'c=us' SUPPLIER_REFERENCE 
  448.             'ldap://ldap.abc.com' CONSUMER_REFERENCE 
  449.             'ldap://ldap.mch.xyz.de' SUPPLIER_IDENTITY 
  450.             'cn=replAdmin,dc=replTree,dc=ldap,dc=mch,dc=xyz,dc=de' 
  451.             BASEDN 'ou=Sales, o=ABC, c=US' FILTER '(objectlass=person)' 
  452.             ATTRIBUTE_SELECTION '(objectclass=*) INCLUDE cn $ sn $ 
  453.             telephoneNumber $ mail)' SCOPE 2 UPDATE_SCHEDULE * 1-2 * * * 
  454.             REPLICATION_PROTOCOL 1.2.3 ) 
  455.  
  456. XI. Security Considerations
  457.  
  458. This document defines a mechanism that can be used to describe the repl-
  459. ication agreements between suppliers and consumers.  The replication pr-
  460. ocess would rely on this information to schedule and control the replica
  461. updates.  Hence the replication agreement attribute should be protected
  462. from unauthorized access.  If the identity of consumers and/or the natu-
  463. re of their subscription to directory information is not public informa-
  464.  
  465. jain,srinivasan,good       Schema for Replication Information     Page 8
  466. INTERNET-DRAFT     draft-ietf-asid-ldap-repl-info-00.txt     July 1997
  467.  
  468.  
  469. tion, the relevant directory information should be protected from unaut-
  470. horized access as well.
  471.  
  472. Servers will generally need to persistently store authentication creden-
  473. tials used to bind to consumer or supplier servers when performing repl-
  474. ica updates.  These credentials MUST be adequately protected from unaut-
  475. horized access.
  476.  
  477. XII. References
  478.  
  479. [1]  Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Spe-
  480. cification", INTERNET-DRAFT draft-ietf-asid-ldif-01.txt, Netscape Commu-
  481. nications Corp., 
  482. <URL:ftp://ietf.org/internet-drafts/draft-ietf-asid-ldif-01.txt>
  483.  
  484. [2]  Good, G., "Definition of an Object Class to Hold LDAP Change Recor-
  485. ds", INTERNET-DRAFT draft-ietf-asid-changelog-01.txt, Netscape Communic-
  486. ations Corp., 
  487. <URL:ftp://ietf.org/internet-drafts/draft-ietf-asid-changelog-01.txt>
  488.  
  489. [3]  C. Weider, J. Strassner, "LDAP Multi-master Replication Protocol",
  490. INTERNET-DRAFT draft-ietf-asid-ldap-mult-mast-rep-00.txt, Microsoft Cor-
  491. poration, Cisco Systems Corporation, 
  492. <URL:ftp://ietf.org/internet-drafts/draft-ietf-asid-ldap-mult-mast-rep-
  493. 00.txt>
  494.  
  495. [4]  T. Howes, M. Wahl, "Referrals and Knowledge References in LDAP Dir-
  496. ectories", INTERNET-DRAFT draft-ietf-asid-ldapv3-referral-00.txt, 
  497. Netscape Communications Corp., Critical-Angle, Inc., <URL:ftp://ietf.org
  498. /internet-drafts/draft-ietf-asid-ldapv3-referral-00.txt>
  499.  
  500. [5]  T. Howes, "The String Representation of LDAP Search Filters", 
  501. INTERNET-DRAFT draft-ietf-asid-ldapv3-filter-02.txt, Netscape Communica-
  502. tions Corp.,
  503. <URL:ftp://ietf.org/internet-drafts/draft-ietf-asid-ldapv3-filter-02.
  504. txt>
  505.  
  506. [6] T. Howes, M. Smith, "The LDAP URL Format", INTERNET-DRAFT 
  507. draft-ietf-asid-ldapv3-url-03.txt, Netscape Communications Corp.,
  508. <URL:ftp://ietf.org/internet-drafts/draft-ietf-asid-ldapv3-url-03.txt>
  509.  
  510. XIII. Authors' Addresses
  511.  
  512. Sanjay Jain
  513. Oracle Corporation
  514. 200 Oracle Parkway
  515. Box 659210
  516. Redwood Shores, CA 94065
  517. USA
  518. Phone: +1 415-506-9325
  519. E-mail: skjain@us.oracle.com
  520.  
  521.  
  522.  
  523. jain,srinivasan,good       Schema for Replication Information     Page 9
  524. INTERNET-DRAFT     draft-ietf-asid-ldap-repl-info-00.txt     July 1997
  525.  
  526.  
  527. Uppili Srinivasan
  528. Oracle Corporation
  529. 200 Oracle Parkway
  530. Box 659210
  531. Redwood Shores, CA 94065
  532. USA
  533. Phone: +1 415-506-3039
  534. E-mail: usriniva@us.oracle.com
  535.  
  536. Gordon Good
  537. Netscape Communications Corporation
  538. 501 E. Middlefield Rd.
  539. Mail Stop MV068
  540. Mountain View, CA 94043
  541. USA
  542. Phone: +1 415 937 3825
  543. E-mail: ggood@netscape.com
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.  
  568.  
  569.  
  570.  
  571.  
  572.  
  573.  
  574.  
  575.  
  576.  
  577.  
  578.  
  579.  
  580.  
  581. jain,srinivasan,good      Schema for Replication Information     Page 10
  582.  
  583.