Possible errata for DETAILS file

gnupg-doc@gnupg.org gnupg-doc@gnupg.org
Mon, 3 Jul 2000 13:35:19 +0900


--- ../share/src/gnupg/gnupg-1.0.1h/doc/DETAILS	Tue Jun 27 19:09:26 2000
+++ DETAILS	Sun Jul  2 19:13:02 2000
@@ -119,7 +119,7 @@
 	The signature key has expired.	No arguments yet.
 
     KEYREVOKED
-	The used key has been revoked by his owner.  No arguments yet.
+	The used key has been revoked by its owner.  No arguments yet.
 
     BADARMOR
 	The ASCII armor is corrupted.  No arguments yet.
@@ -198,7 +198,7 @@
     BEGIN_DECRYPTION
     END_DECRYPTION
 	Mark the start and end of the actual decryption process.  These
-	are also emmited when in --list-only mode.
+	are also emitted when in --list-only mode.
 
     BEGIN_ENCRYPTION
     END_ENCRYPTION
@@ -214,7 +214,7 @@
 	"char" is the character displayed with no --status-fd enabled, with
 	the linefeed replaced by an 'X'.  "cur" is the current amount
 	done and "total" is amount to be done; a "total" of 0 indicates that
-	the toatal amount is not known. 100/100 may be used to detect the
+	the total amount is not known.  100/100 may be used to detect the
 	end of operation.
 
     SIG_CREATED <type> <pubkey algo> <hash algo> <class> <timestamp> <key fpr>
@@ -263,31 +263,31 @@
 There is an experimental feature which allows for unattended
 generation of keys controlled by a parameter file.
 This feature is not very well tested and does only make sense for some
-very special applications.  Please don't complain if we decide to chnage
+very special applications.  Please don't complain if we decide to change
 the behaviour of this command.
 
 To use this feature, you use --gen-key together with --batch and feed the
-parameters either form stdin or from a file given on the commandline.
+parameters either from stdin or from a file given on the commandline.
 The format of this file is as follows:
   o Text only, line length is limited to about 1000 chars.
-  o You must use UTF-8 encoding to specifiy non-ascii characters.
-  o Empty lines are ignored
-  o Leading and trailing spaces are ignored
-  o A hash sign as the first non white space character indicates a comment line
+  o You must use UTF-8 encoding to specify non-ascii characters.
+  o Empty lines are ignored.
+  o Leading and trailing spaces are ignored.
+  o A hash sign as the first non white space character indicates a comment line.
   o Control statements are indicated by a leading percent sign, the
     arguments are separated by white space from the keyword.
   o Parameters are specified by a keyword, followed by a colon.  Arguments
-    are speparated by white space.
+    are separated by white space.
   o The first parameter must be "Key-Type", control statements
     may be placed anywhere.
   o Key generation takes place when either the end of the parameter file
     is reached, the next "Key-Type" parameter is encountered or at the
     controlstatement "%commit"
-  o Control staements:
+  o Control statements:
     %echo <text>
-	Print <text>
+	Print <text>.
     %dry-run
-	Suppress actual key generation (useful for syntax checking)
+	Suppress actual key generation (useful for syntax checking).
     %commit
 	Perform the key generation.  An implicit commit is done
 	at the next "Key-Type" parameter.
@@ -302,8 +302,8 @@
 	this file is created (and overwrites an existing one).
 	Both control statements must be given.
    o The order of the parameters does not matter except for "Key-Type"
-     which must be the first parameter.  The paramtyers are only for the
-     generated keyblock and paramters from previous key generations are not
+     which must be the first parameter.  The parameters are only for the
+     generated keyblock and parameters from previous key generations are not
      used. Some syntactically checks may be performed.
      The currently defined parameters are:
      Key-Type: <algo-number>|<algo-string>
@@ -311,7 +311,7 @@
 	primary key. The algorithm must be capable of signing.
 	This is a required parameter.
      Key-Length: <length-in-bits>
-	Length of the key in bits.  Default is 1024
+	Length of the key in bits.  Default is 1024.
      Subkey-Type: <algo-number>|<algo-string>
 	This generates a secondary key.  Currently only one subkey
 	can be handled.
@@ -476,16 +476,16 @@
      1 u32    next   next sigrec of this uid or 0 to indicate the
 		     last sigrec.
      6 times
-	1 u32  Local_id of signators dir or shadow dir record
+	1 u32  Local_id of signatures dir or shadow dir record
 	1 byte Flag: Bit 0 = checked: Bit 1 is valid (we have a real
 			     directory record for this)
-			 1 = valid is set (but my be revoked)
+			 1 = valid is set (but may be revoked)
 
 
 
   Record type 8: (shadow directory record)
   --------------
-    This record is used to reserved a LID for a public key.  We
+    This record is used to reserve a LID for a public key.  We
     need this to create the sig records of other keys, even if we
     do not yet have the public key of the signature.
     This record (the record number to be more precise) will be reused
@@ -614,7 +614,7 @@
 +  future extensions. These length markers must be inserted into the data
 +  stream just before writing the data out.
 +
-+  This 2 byte filed is large enough, because the application must buffer
++  This 2 byte field is large enough, because the application must buffer
 +  this amount of data to prepend the length marker before writing it out.
 +  Data block sizes larger than about 32k doesn't make any sense. Note
 +  that this may also be used for compressed data streams, but we must use
@@ -633,8 +633,8 @@
 
 Usage of gdbm files for keyrings
 ================================
-    The key to store the keyblock is it's fingerprint, other records
-    are used for secondary keys.  fingerprints are always 20 bytes
+    The key to store the keyblock is its fingerprint, other records
+    are used for secondary keys.  Fingerprints are always 20 bytes
     where 16 bit fingerprints are appended with zero.
     The first byte of the key gives some information on the type of the
     key.
@@ -742,11 +742,11 @@
 keys.
 
 
-A better way to to this would be a request like:
+A better way to do this would be a request like:
 
    /pks/lookup/<gnupg_formatierte_user_id>?op=<operation>
 
-this can be implemented using Hurd's translator mechanism.
+This can be implemented using Hurd's translator mechanism.
 However, I think the whole key server stuff has to be re-thought;
 I have some ideas and probably create a white paper.
 

--
  iida