Expand on note regarding header-field representation.
authorChris Hanson <org/chris-hanson/cph>
Tue, 20 Jun 2000 19:43:06 +0000 (19:43 +0000)
committerChris Hanson <org/chris-hanson/cph>
Tue, 20 Jun 2000 19:43:06 +0000 (19:43 +0000)
v7/src/imail/todo.txt

index 8e5836769a6d4f88ff8ac54225027dc76ed33247..6c00fc74841a1886fbb11acdfff514b564a5e4f3 100644 (file)
@@ -1,11 +1,15 @@
 IMAIL To-Do List
-$Id: todo.txt,v 1.89 2000/06/19 22:15:25 cph Exp $
+$Id: todo.txt,v 1.90 2000/06/20 19:43:06 cph Exp $
 
 Bug fixes
 ---------
 
 * Change file URL completion to complete to any file name.
 
+* Preserve internal-date when copying to rmail folder from any other
+  type of folder, by writing a distinguished header field into the
+  rmail file.
+
 * Must be able to handle malformed headers in incoming mail.
   Generating a low-level error in this situation is unacceptable.
 
@@ -96,6 +100,12 @@ Design changes
   Strictly speaking, this isn't correct, but I don't know of any
   situation in which it would cause problems.
 
+  More generally, the internal representation of a header field should
+  permit arbitrary value strings.  The conversion to RFC 822 form
+  should be done during I/O rather than being a required feature of
+  the representation.  This is safe to do for many headers, which are
+  defined to have arbitrary whitespace.
+
 * Move pathname-completion code into the runtime system.
 
 * Repackage the code so that each file now in the core is in a