Changes in Unidiff format with line numbers omitted. Differences due only
to formatting and administrivia have been removed.

--- draft20.pre-2.txt
+++ draft20.pre-3.txt
@@@@
    situation.
 
-   An NNTP client MUST NOT rely on any cached results from this command,
-   either earlier in this session or in a previous session, remaining
-   correct. While some extensions are likely to be always available or
-   never available, others will "appear" and "disappear" depending on
-   other changes. See Section 11.6 for further discussion of this topic.
+   An NNTP client may cache the results of this command, but MUST NOT
+   rely on any cached results, either from earlier in this session or
+   from a previous session, remaining correct. While some extensions are
+   likely to be always available or never available, others will
+   "appear" and "disappear" depending on other changes. Furthermore, a
+   server SHOULD NOT use cached results in relation to security,
+   privacy, and authentication extensions. See Section 11.6 for further
+   discussion of this topic.
 
    The list of extensions is returned as a multi-line response following
@@@@
    the former case it MUST NOT use any argument.
 
+   The HDR command may take information from a database rather than
+   directly from the articles. If so, the same issues of consistency and
+   inconsistency apply as with the OVER extension (Section 8.5) and the
+   LIST HEADERS command SHOULD take the same approach as the LIST
+   OVERVIEW.FMT command in resolving them.
+
 8.6.1 HDR
 
@@@@
    results such as a successful empty response.
 
+   If HDR uses a separate database and it is inconsistent for the
+   requested header or metadata item, the server MAY return what results
+   it can or it MAY respond with the generic 503 response; in the latter
+   case, the field MUST NOT appear in the output from LIST HEADERS.
+
 8.6.1.3 Examples
 
@@@@
    providing the extension).
 
-   If the list of available fields is not the same for all articles (for
-   example, because the HDR command uses the same database as the OVER
-   command and the set of fields being stored has recently changed),
-   then the response should indicate the situation for a newly-arrived
-   article.
-
-   OUTSTANDING ISSUE
-
-      Is this the best approach, or should the rules be the same as for
-      LIST OVERVIEW.FMT? If the latter, make it clear that HDR might
-      return success for some articles in this situation, or else define
-      a new error for HDR.
-
    An implementation that also supports the OVER extension SHOULD at
    least permit all the headers and metadata items listed in the output
@@@@
    In particular, NNTP clients and servers SHOULD rely on their name
    resolver for confirmation of an IP number/DNS name association,
-   rather than cacheing the result of previous host name lookups. Many
+   rather than caching the result of previous host name lookups. Many
    platforms already can cache host name lookups locally when
    appropriate, and they SHOULD be configured to do so. It is proper for
@@@@
    connection if it is no longer possible to parse it sensibly.
 
-11.6 Cacheing of LIST EXTENSIONS results
+11.6 Caching of LIST EXTENSIONS results
 
    The LIST EXTENSIONS command provides information about the extensions
@@@@
    to change accordingly.
 
-   In most situations the results from this command will not change from
-   session to session; a given extension will be installed permanently
-   on a server. Therefore it is reasonable for a client to cache
-   extension status between sessions, rather than using the LIST
-   EXTENSIONS command in every session, and use this cached information
-   when deciding whether or not to use a particular extension. However,
-   such implementations MUST cope gracefully with the cached status
-   being out of date, and SHOULD provide a way to force the cached
-   information to be refreshed.
+   In most situations the results from this command in a given server
+   state will not change from session to session; a given extension will
+   be installed permanently on a server. Therefore, once it has
+   established a working state - for example, by using MODE READER or
+   setting up an encrypted connection to the server - it is reasonable
+   for a client to cache extension status between sessions and use this
+   cached information when deciding whether or not to use a particular
+   extension, rather than using the LIST EXTENSIONS command in every
+   session. However, such implementations MUST NOT rely on any cached
+   results from this command remaining correct, MUST cope gracefully
+   with the cached status being out of date, and SHOULD provide a way to
+   force the cached information to be refreshed.
 
-   However, there are risks in cacheing information about extensions
+   However, there are risks in caching information about extensions
    related to security and privacy.
 
@@@@
 
    Therefore a client sending private information, such as a cleartext
-   password, to a server is advised always to check the security state
-   of the link and the identity of the server immediately beforehand.
-   How this is done will, of course, depend on the particular facilities
-   available on the server.
+   password, to a server SHOULD check the security state of the link and
+   the identity of the server immediately beforehand and SHOULD NOT rely
+   on the (cached) results of any previous check. How such a check is
+   done will, of course, depend on the particular facilities available
+   from the server.
 
    An even better approach, though, is to use authentication mechanisms