[dev] Fwd: Re: Patch I submitted

[Eric Rostetter]

Quoting Conor Kerr <conor at dev.ceon.net>:

> I don't claim to know any of the reasoning behind the decision to make
> the RFC as such but from a purely practical point of view what's the
> difference in this case?

Following the sender's instructions versus ignoring the sender's instructions.

> What is the distinction between displaying an
> image marked as "inline" inline in IMP and an image marked as
> "attachment" inline in IMP *given that* IMP will only display images if
> browsers have the necessary software registered?

Following the sender's instructions versus ignoring the sender's instructions.

The inline/attachment distinction is there so the sender can specify how
to treat the image.
 
> > Why should we break the RFC?
> 
> Because doing so won't affect anyone in any way except that of making
> their lives simpler? :)

You are wrong here.  The sender may actually have a good reason to
send an image as an attachment which should not be viewed inline.
To ignore the sender's wishes could potentially cause problems for the
receiver.  That means making the receiver's life more difficult, not
simpler.  And if the receiver is a typical person, then he will blame
that on the sender (who did the right thing) rather than on the broken
mail client he is using (which is doing the wrong thing).
 
> The majority of email software attaches images as base64 encoded
> attachments of content-disposition "attachment".  The ideals that RFCs
> express are well and good but sometimes their absolute and unfoundering
> implentation isn't useful.

If they were implemented in a more absolute and unfoundering way, then
you wouldn't be getting all those base64 encoded attachment disposition
images.  Your argument is flawed.

> Of course if I am wrong in this matter someone please enlighten me.

Yes, you are wrong.
 
> I look forward to hearing feedback on this.  All the best...

Reasons I might send an image as an attachment instead of inline:

* It is off-color, and I want the user to be able to decide (via a text
disclaimer) if they should open it or not rather than force them to see
it.

* It is too large for less powerful machines to render or render in a 
reasonable time.

* The resolution is too great to display on screen.

* It is not meant to be viewed (I'm sending it to a print shop for
printing, and they don't want to see it, just print it).

* I'm sending a bunch of images to someone for them to save (say, on a
web site) and not view, and rendering them all (since there are so many)
would take too long and serve no value.

* Hundreds of more reasons I can come up with.

People sometimes email images for reasons other than viewing them!
I do this often (to print shops for printing for example).  If you don't
that is fine, but don't break my RFC or mail client for your needs when
it works for my needs.

> Conor

-- 
Eric Rostetter
The Department of Physics
The University of Texas at Austin

Why get even? Get odd!