Fix some formatting, phrasing, typos

diff --git a/doc/man/man5/slapo-dds.5 b/doc/man/man5/slapo-dds.5
index 435f368d8f274d892d47c04a5b4e2baaee85e334..a637aa306a14164f107add90c7ed357de2331a64 100644 (file)
--- a/doc/man/man5/slapo-dds.5
+++ b/doc/man/man5/slapo-dds.5
@@ -3,7 +3,7 @@
 .\" Copying restrictions apply.  See the COPYRIGHT file.
 .\" $OpenLDAP$
 .SH NAME
-slapo-dds \- dds overlay
+slapo-dds \- Dynamic Directory Services overlay
 .SH SYNOPSIS
 ETCDIR/slapd.conf
 .SH DESCRIPTION
@@ -15,12 +15,13 @@ implements dynamic objects as per RFC 2589.
 The name 
 .B dds
 stands for
-Dynamic Dyrectory Services.
+Dynamic Directory Services.
 It allows to define dynamic objects, characterized by the
 .B dynamicObject
 objectClass.
-Dynamic objects have a limited life, determined by a time-to-live (TTL)
-that can be refreshed by means of a specific 
+
+Dynamic objects have a limited lifetime, determined by a time-to-live
+(TTL) that can be refreshed by means of a specific
 .B refresh
 extended operation.
 This operation allows to set the Client Refresh Period (CRP),
@@ -28,16 +29,18 @@ namely the period between refreshes that is required to preserve the
 dynamic object from expiration.
 The expiration time is computed by adding the requested TTL to the 
 current time.
-When dynamic objects reach the end of their life without being
-further refreshed, they are automatically deleted; there is no guarantee
-of immediate deletion, but clients should not count over it.
-Dynamic objects can have subordinates, provided they also are dynamic
+When dynamic objects reach the end of their lifetime without being
+further refreshed, they are automatically deleted.
+There is no guarantee of immediate deletion, so clients should not count
+on it.
+
+Dynamic objects can have subordinates, provided these also are dynamic
 objects.
-RFC 2589 does not specify what should the behavior of a dynamic 
-directory service be when a dynamic object with (dynamic) subordinates
+RFC 2589 does not specify what the behavior of a dynamic directory
+service should be when a dynamic object with (dynamic) subordinates
 expires.
-In this implementation, the life of dynamic objects with subordinates
-is prolonged until all the dynamic subordinates expired.
+In this implementation, the lifetime of dynamic objects with subordinates
+is prolonged until all the dynamic subordinates expire.
 
 
 This 
@@ -61,7 +64,7 @@ and
 operations.
 Since its use may result in many internal entry lookups, adds
 and deletes, it should be best used in conjunction with backends
-that have resonably good write performances.
+that have reasonably good write performances.
 
 .LP 
 The config directives that are specific to the
@@ -73,19 +76,20 @@ database or to other stacked overlays.
 
 .TP
 .B dds\-max\-ttl <ttl>
-Specifies the max TTL value; this is the default TTL newly created
+Specifies the max TTL value.
+This is also the default TTL newly created
 dynamic objects receive, unless
 .B dds\-default\-ttl
 is set.
-When the client with a refresh exop requests a TTL higher than it,
-sizeLimitExceeded is returned.
+When the client with a refresh extended operation requests a TTL higher
+than it, sizeLimitExceeded is returned.
 This value must be between 86400 (1 day, the default) and 31557600
 (1 year plus 6 hours, as per RFC 2589).
 
 .TP
 .B dds\-min\-ttl <ttl>
 Specifies the min TTL value; clients requesting a lower TTL by means
-of the refresh exop actually obtain this value as CRP.
+of the refresh extended operation actually obtain this value as CRP.
 If set to 0 (the default), no lower limit is set.
 
 .TP
@@ -103,11 +107,12 @@ Specifies the interval between expiration checks; defaults to 1 hour.
 .B dds\-tolerance <ttl>
 Specifies an extra time that is added to the timer that actually wakes up
 the thread that will delete an expired dynamic object.
-So the nominal life of the entry is that specified in the
+So the nominal lifetime of the entry is that specified in the
 .B entryTtl
-attribute, but its life will actually be
-.BR " entryTtl + tolerance " .
-Note that there is no guarantee that the life of a dynamic object will be
+attribute, but its lifetime will actually be
+.BR "entryTtl + tolerance" .
+Note that there is no guarantee that the lifetime of a dynamic object
+will be
 .I exactly
 the requested TTL; due to implementation details, it may be longer, which 
 is allowed by RFC 2589.
@@ -117,8 +122,8 @@ By default, tolerance is 0.
 .B dds\-max\-dynamicObjects <num>
 Specifies the maximum number of dynamic objects that can simultaneously exist
 within a naming context.
-This allows to limit the amount of resources (mostly in terms of runqueue size)
-that are used by dynamic objects.
+This allows to limit the amount of resources (mostly in terms of
+run-queue size) that are used by dynamic objects.
 By default, no limit is set.
 
 .TP
@@ -146,8 +151,8 @@ is an operational, NO-USER-MODIFICATION attribute, no direct write access
 to it is possible.
 So the 
 .B dds
-overlay turns refresh exops into an internal modification to the value 
-of the
+overlay turns refresh extended operation into an internal modification to
+the value of the
 .B entryTtl
 attribute with the
 .B manageDIT