Comments on draft-gellens-format-bis-00.txt

I'm revising my rfc2646 implementation based on this draft, and 
I'd like to see some things clarified in the document.
It is currently problematic to generate a conforming format=flowed 
message when replying to (i.e., quoting) a non-flowed message.  Is 
this scenario supported at all?  I'm actually not sure whether 
2646 allows this or not.  If it isn't allowed, making that 
explicit would be good.  On the other hand, I think it is possible 
to generate useful format=flowed messages when replying to 
non-flowed messages if some changes are made to the specification.
Section 5.1 "Generating Format=Flowed" currently says "lines 
SHOULD be shorter than 80 characters".  It discusses how to 
achieve this by wrapping, and references to section 5.5 "Quoting" 
on how to handle quoted text.  However, section 5.5 is only 
applicaple if the message that is being replied to is 
format=flowed -- the entire section starts with "In Format=Flowed, 
the canonical quote indicator (or quote mark) is one or more close 
angle bracket (">") characters ..." and this assumption is used 
throughout the section.  The assumption does not hold for 
non-format=flowed text, so a implementation has two choices:
1) Apply the quoting algorithm to fixed messages too.  This works 
   for well formed messages, but can generate horible output.
2) Leave the original message as is, and potentially break the 
   SHOULD about lines being shorter than 80 characters.
I think it would be useful to add a new section "Generating 
Format=Flowed Quoting Format=Fixed Messages" that blesses the 
second choice.  It should say that if the incoming message is not 
format=flowed, the client MUST NOT make any attempt at filling the 
line to fit under 80 characters.  Some examples to illustrate that 
this cannot be done reliably (which I belive is the case) would be 
useful.  The section should go on to say that performing wrapping 
of any lines produced by the local, format=flowed aware, client 
SHOULD be done.
What do you think?  I have not finished implemented this, so there 
may be some hidden things that invalidates my idea.