RFC 2646

RFC 2646

[Per Abrahamsen]

After pGnus is released, I think RFC 2646 support would be a good
thing to work on.  It solves some of the worst shortcommings of
text/plain in a backward compatible way.

We might even invent a new format value for our _fancy_ markup.

Re: RFC 2646

[Steinar Bang]

>>>>> Per Abrahamsen <abraham@dina.kvl.dk>:

> After pGnus is released, I think RFC 2646 support would be a good
> thing to work on.  It solves some of the worst shortcommings of
> text/plain in a backward compatible way.

        http://www.ietf.org/rfc/rfc2646.txt

Title: The Text/Plain Format Parameter

Re: RFC 2646

[Steinar Bang]

>>>>> Steinar Bang <sb@metis.no>:

>>>>> Per Abrahamsen <abraham@dina.kvl.dk>:
>> After pGnus is released, I think RFC 2646 support would be a good
>> thing to work on.  It solves some of the worst shortcommings of
>> text/plain in a backward compatible way.

>         http://www.ietf.org/rfc/rfc2646.txt

> Title: The Text/Plain Format Parameter

Of course one problem with this solution is that offenders like eg. MS 
Outlook and OE will never implement it, because it would break with
the MS policy of creating subtle and some not so subtle annoyances in
other programs that tries to interoperate with them.

Not to speak of the legacy MUAs which will just keep on sending broken 
messages.

Re: RFC 2646

[Toby Speight]

Per> Per Abrahamsen <URL:mailto:abraham@dina.kvl.dk>

0> In article <rjhfk0qlkf.fsf@feller.dina.kvl.dk>, Per wrote:

Per> After pGnus is released, I think RFC 2646 support would be a good
Per> thing to work on.  It solves some of the worst shortcommings of
Per> text/plain in a backward compatible way.

That's text/plain;format="flowed", isn't it?  I've thought about this a
little since I saw it appear.  I agree that it would be nice to use the
hint to render such messages; I'm not sure it would be as useful when
generating.  To do it right, you need to set quite a few variables to
ensure that quoting is done exactly as RFC2646 wants (matching ">+ *",
IIRC), and being careful with hard and soft newlines so that some source
code yanked into the message doesn't get wrapped[1].


[1] WIBNI Emacs had a buffer-local variable to say whether newlines were
    hard or soft by defualt in buffers that have use-hard-newlines unset,
    so that killed text can be yanked into buffers with use-hard-newlines
    turned on and the Right Thing would happen.  So C mode would have
    default-newline-property be 'hard, and text mode would have it be
    'soft.

Re: RFC 2646

[Per Abrahamsen]

Steinar Bang <sb@metis.no> writes:

> Of course one problem with this solution is that offenders like eg. MS 
> Outlook and OE will never implement it, because it would break with
> the MS policy of creating subtle and some not so subtle annoyances in
> other programs that tries to interoperate with them.

Maybe not, but Gnus should at least play nice to those who *does*
implement it.  I guess someone will implement it for Mozilla at
least.  And obviously Turnpike will have it.

Re: RFC 2646

[Per Abrahamsen]

Toby Speight <Toby.Speight@streapadair.freeserve.co.uk> writes:

> I agree that it would be nice to use the hint to render such
> messages;

That would be the obvious first step.

> I'm not sure it would be as useful when generating.

It would be useful, but much harder.

Re: RFC 2646

[Steinar Bang]

>>>>> Per Abrahamsen <abraham@dina.kvl.dk>:

> Steinar Bang <sb@metis.no> writes:
>> Of course one problem with this solution is that offenders like
>> eg. MS Outlook and OE will never implement it, because it would
>> break with the MS policy of creating subtle and some not so subtle
>> annoyances in other programs that tries to interoperate with them.

> Maybe not, but Gnus should at least play nice to those who *does*
> implement it.  

I agree completely.

Re: RFC 2646

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> After pGnus is released, I think RFC 2646 support would be a good
> thing to work on.  It solves some of the worst shortcommings of
> text/plain in a backward compatible way.

(Executive summary: One encodes whether line break are "hard" or not
by using trailing whitespace.)

Yes, I think Gnus should support this if it becomes supported by any
other significant news/mail reader.

I don't think it will be, though.  It addresses one (annoying) aspect
of variable-width composition, and that's all it does, so I doubt that 
it's sexy enough to garner much enthusiasm.

> We might even invent a new format value for our _fancy_ markup.

Cursory reading of the rfc seems to say that the only valid values for
the FORMAT parameter are "fixed" and "flowed".  Adding more (sub)types
will require "fixed-and-fancy", "flowed-and-fancy", "fixed", "flowed",
and when people add more of these subformats, it'll expand
exponentially.  Which is one thing I don't like about this RFC; it
seems so... fixed.  No possibilty for future feepurism.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: RFC 2646

[Per Abrahamsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Yes, I think Gnus should support this if it becomes supported by any
> other significant news/mail reader.

I presume Eudora will support it, as it was written by a Qualcomm
employee.  Maybe we should promise to support it, if they will fix
that annoying references-"copy-but-do-not-update"-misfeature. ;-)

Re: RFC 2646

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> I presume Eudora will support it, as it was written by a Qualcomm
> employee.  Maybe we should promise to support it, if they will fix
> that annoying references-"copy-but-do-not-update"-misfeature. ;-)

Definitely.  :-)  Promise away!

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen