* techdoc/protocol.txt: document that unless otherwise specified,

  everything in the Citadel system is UTF-8.

diff --git a/citadel/ChangeLog b/citadel/ChangeLog
index b4e938db75a820c0836c6f24534509b55c07e167..ad96acb71a579d591eb233fe28222d7fd6fe3024 100644 (file)
--- a/citadel/ChangeLog
+++ b/citadel/ChangeLog
@@ -1,4 +1,8 @@
 $Log$
+Revision 654.18  2005/08/21 19:40:50  ajc
+* techdoc/protocol.txt: document that unless otherwise specified,
+  everything in the Citadel system is UTF-8.
+
 Revision 654.17  2005/08/21 06:16:37  ajc
 * html.c: don't transform <32 or >126 characters to question marks.  We
   like foreign character sets now.
@@ -7052,3 +7056,4 @@ Sat Jul 11 00:20:48 EDT 1998 Nathan Bryant <bryant@cs.usm.maine.edu>
 
 Fri Jul 10 1998 Art Cancro <ajc@uncensored.citadel.org>
        * Initial CVS import
+

diff --git a/citadel/techdoc/protocol.txt b/citadel/techdoc/protocol.txt
index 18affe1e6eb080510ecf8c2e207aedaee9e85f89..85e6de4dc6479bc5856d8c3094891914e397a449 100644 (file)
--- a/citadel/techdoc/protocol.txt
+++ b/citadel/techdoc/protocol.txt
@@ -42,6 +42,17 @@ our application layer assumes a clean, reliable, sequenced connection, the use
 of UDP would render the server unstable and unusable, so we stick with TCP.
 
 
+ CHARACTER SETS
+ --------------
+ 
+ The native character set for the Citadel system is UTF-8.  Unless otherwise
+specified, all data elements are expected to be in the UTF-8 character set.
+Specifically, all non-MIME messages should be assumed to be in UTF-8.  MIME
+messages may be in whatever character set is specified by the MIME header, of
+course; however, some clients (such as WebCit) will automatically convert
+messages from other character sets before displaying them.
+ 
+ 
  GENERAL INFORMATION ABOUT THE SERVER
  ------------------------------------
 
@@ -2175,11 +2186,22 @@ asynchronous messages as they arrive, before doing anything else.
  SRCH   (SeaRCH the message base)
  
  This command's implementation is incomplete and will be documented when it
-is finished.
-
-
-
-
+is finished.  The current implementation accepts a search string as its sole
+argument, and will respond with LISTING_FOLLOWS followed by a list of
+messages (globally, not just in the current room) which contain ALL of the
+words in the search string.  If the client desires an "exact phrase" match,
+it must then slow-search the text of each returned message for the exact
+string.  The client should also compare the returned message numbers against
+those which actually exist in the room or rooms being searched.  In
+particular, clients should avoid telling the user about messages which exist
+only in rooms to which the user does not have access.
+ 
+ Again, keep in mind that this is a temporary implementation and is not
+guaranteed to continue to exist in this form.
+ 
+ 
+ 
+ 
  ASYNCHRONOUS MESSAGES
  ---------------------