prop340: Expand on why we don't allow DATA fragmentation

I was going to propose allowing DATA fragmentation, but I think I've
talked myself out of it. I think it'll be useful to have a record of
this line of thought for future reference.

1 files changed, 17 insertions, 2 deletions

diff --git a/proposals/340-packed-and-fragmented.md b/proposals/340-packed-and-fragmented.md
index 2407f99..8586349 100644
--- a/proposals/340-packed-and-fragmented.md
+++ b/proposals/340-packed-and-fragmented.md
@@ -269,8 +269,23 @@ conflux bundle.
 
 ### An exception for `DATA`.
 
-Data messages may not be fragmented.  (There is never a reason to do
-this.)
+Data messages may not be fragmented. When packing data into a cell containing
+other messages is desired, the application can instead construct a DATA message
+of an appropriate size to fit into the remaining space.
+
+While relaxing this could simplify the implementation of opportunistic packing
+somewhat (by allowing code that constructs `DATA` messages not to have to know
+about packing or fragmentation), doing so would have several downsides.
+
+First, on the receiver side a naive implementation that receives the first cell
+of a fragmented `DATA` message would not be able to pass the data in that
+fragment on to the application until the remaining cells of that message are
+received. An optimized implementation might choose to do so, but that
+complexity seems worse than the complexity we'd be avoiding by allowing `DATA`
+fragmentation in the first place.
+
+Second, as with any sort of flexibility permitted to implementations, allowing
+flexibility here adds opportunities for fingerprinting and covert channels.
 
 ### Extending message-length maxima