[Doc-SIG] Email Reader (was Re: reST block quotes)

[Benja Fallenstein]

Beni Cherniavsky wrote:

>On 2002-12-19, Benja Fallenstein wrote:
>  
>
>>Beni Cherniavsky wrote:
>>
>>>3. Once mail is sent, it generally can't be edited (since it's already
>>>archived and people already hav it in their mailboxes).  I'm not sure
>>>if anything can be done about it but it's a pecularity of email that
>>>should be remembered.
>>>
>>>      
>>>
>>What's the issue here?
>>
>>    
>>
>Just that if after a broken rST is emitted, it's generally too late to
>tidy it :-).
>

Ah, ok, I see your point now.

>  Thinking of it again, I see your validate-when-sending point
>of view.  I agree - I would usually want to validate to avoid
>inconveninece for readers.
>

Cool, sounds like we are in agreement here :-) :-)

>>(BTW, email is quite often edited when being quoted :) )
>>
>>    
>>
>But you can't fix the master which get's quoted afresh in new braches of
>the thread...
>

Right.

>>>*Breakage ahead*: your list is broken by line folding.Unexpected line
>>>folding in the places where you least want it is all too popular with
>>>email tool writers ;-(.Good rST that you write will end up broken for
>>>some readers sooner or later.The "lazy indentation" ideas from the to-do
>>>list could help here a bit.
>>>
>>>      
>>>
>>Yes, but so is 'text/plain; format=flowed' [RFC2646]. It gets around the
>>problem by requiring (IIRC) that compliant user agents shall not fold
>>lines, but reflow instead-- ReST mail could do that too. (Mozilla
>>supports it. It seems to work in most cases, and the remaining ones can
>>be glossed over.)
>>
>>    
>>
>Wouldn't it break every single literal block containg Python code, too?
>

Hmmm. I guess the 'right' way to handle this would be not to reflow 
literal blocks, and not to line-break them either (since the mail reader 
would know about ReST, it would be able to take care of this correctly). 
I think that the SMTP infrastructure generally doesn't add additional 
linebreaks, so this should work-- if some server breaks the lines, of 
course, that would destroy the ReST formatting, but I think they don't. 
Again, the point is that the mail reader must handle ReST correctly...

The RFCs allow lines of up to 1000 characters, but recomment lines up to 
80 characters because many mail readers show these better. I guess that 
literal blocks with >80 chars/line (or literal blocks inside quoted text 
etc.) are good cases for using >80 chars.

>>>I'm not sure I like text/vnd.python.rst.I don't want another text/html.
>>>Most mail readers will probably complain that they don't know how to read
>>>it.
>>>
>>>      
>>>
>>Hmm. I wouldn't suspect this, but I haven't tried. (The reason I would
>>suspect it should work is that the RFCs say very clearly that you have
>>to treat it as text/plain, and that's not so hard to implement. But of
>>course we know how good standards compliance is in most systems... Does
>>anybody have experience in how mail readers treat unknown text/* formats?)
>>
>>    
>>
>OK, you've obviously read more RFCs than I.  Glad to know it should work.
>

Ok :-)

So far, our discussion suggests that we'd need:
- a ReST Tidy
- an extension of the ReST specification, for "> " quoting
- a specification of ReST email: MIME type, how to handle reflowing when 
replying, possibly other issues if they come up
- an email reader implementing the above

ReST Tidy would obviously also have applications outside this context. I 
think I may like to use ">" when quoting emails in ReST.

- Benja