(Future changes): Entered all future changes into Bugzilla. Refer to

	Bugzilla.  (Bug 131).

doc/Protocol-A.texi

@@ -9167,26 +9167,30 @@ will still be able to use the old requests.
 @item
 Cryptography!  LysKOM is sometimes used for sensitive information.  It
 is unacceptable that everything is sent in the clear.  Should we use
-TLS?  This area needs further study.
+TLS?  This area needs further study.  (This is
+@uref{http://bugzilla.lysator.liu.se/show_bug.cgi?id=133, bug 133}.)
 
 @item
 The information contained in the @type{Misc-Info} array should be
 integrated into the @type{Text-Stat}.  There should be one array of
 recipients, one of texts that comments this text, and so on.  This
-would make the @type{Misc-Info} type obsolete.
+would make the @type{Misc-Info} type obsolete.  (This is
+@uref{http://bugzilla.lysator.liu.se/show_bug.cgi?id=134, bug 134}.)
 
 @item
 The aux-items can be very large.  It was a mistake to include them in
 the @type{Text-Stat}.  They should probably be separated from the
 @type{Text-Stat}; retrieving the @type{Text-Stat} should only indicate
-which aux-items that exists.
+which aux-items that exists.  (This is
+@uref{http://bugzilla.lysator.liu.se/show_bug.cgi?id=135, bug 135}.)
 
 @item
 There is too few asynchronous messages.  There are many situations
 where something can change without a client noticing it.
 
 There is more than one way to fix this, and it is not known which way
-is the best.
+is the best.  (This is
+@uref{http://bugzilla.lysator.liu.se/show_bug.cgi?id=93, bug 93}.)
 
 @item
 The super conference is used for two purposes: to indicate where
@@ -9198,10 +9202,13 @@ conference and unauthorized original articles to another conference.
 One way to fix this is to remove the @conftype{original} bit and
 introduce a @field{followups-to} field in the @type{Conference}.
 Doing this in a backwards-compatible way requires some thought@dots{}
+(This is
+@uref{http://bugzilla.lysator.liu.se/show_bug.cgi?id=136, bug 136}.)
 
 @item
 The security system is too complex, yet unable to do many useful
-things, and should be rethought.
+things, and should be rethought.  (This is
+@uref{http://bugzilla.lysator.liu.se/show_bug.cgi?id=137, bug 137}.)
 
 @item
 The @field{last-text-read} and @field{read-texts} fields of a
@@ -9210,7 +9217,8 @@ is read.  Consider the case where somebody has read everything up to
 text 100, and text 102-2002.  Using the current protocol specification
 more than 2000 numbers must be transmitted to convey that information.
 A much more attractive solution would be to send a list of ranges of
-read texts.
+read texts.  (This is
+@uref{http://bugzilla.lysator.liu.se/show_bug.cgi?id=52, bug 52}.)
 
 @item
 The @reqlink{mark-as-read} call is a reasonably good way to mark a
@@ -9234,10 +9242,14 @@ handle such reordering.
 In the future, a new call might be added, so that a client can give
 the server explicit permission to reorder the replies.  The client
 would then have to rely on the @field{ref-no} to match each reply to
-the corresponding call.
+the corresponding call.  (This is
+@uref{http://bugzilla.lysator.liu.se/show_bug.cgi?id=138, bug 138}.)
 
 @end itemize
 
+For more information about potential future changes, see
+@uref{http://bugzilla.lysator.liu.se/, Bugzilla @ Lysator}.
+
 @node Protocol Version History
 @appendix Protocol Version History (informative)