Whenever someone has a "experience" while reading an e-mail message or viewing a web page, one has to wonder what sort of drugs they are on ... It is the LSD that provides the "experience", not whether you are viewing an e-mail message or a web-page-over-SMTP ...
Please experience the wonders of the top-quote. See your local psychedelic distributor if you are somehow not "experiencing" anything ... --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Owen DeLong >Sent: Monday, 14 January, 2019 15:22 >To: Valdis Kletnieks >Cc: nanog@nanog.org >Subject: Re: (Netflix/GlobalConnect a/s) Scheduled Open Connect >Appliance upgrade is starting > > > >> On Jan 13, 2019, at 12:11 PM, valdis.kletni...@vt.edu wrote: >> >> On Sun, 13 Jan 2019 20:55:54 +0100, Christoffer Hansen said: >> >>> (*it is frustrating when content parity between HTML and PLAINTEXT >>> sections is e-mails is inconsistent. :/ ) >> >> Back when we were designing MIME, somebody (Vernon Schryver?) >stated >> that multipart/alternative with text/plain and text/html was >*always* incorrect. >> >> If the two parts are semantically equal, then one is superfluous >and doesn't >> need to be sent. (Remember bandwidth costs in 1992...) >> >> If the two parts aren't semantically equal, then one part is >deficient at best >> and actively misleading at worst, and should not be sent. > >This involves a number of erroneous assumptions, IMHO… > >1. All recipients have the ability to consume either form. >2. HTML cannot offer a better experience to some recipients while >remaining semantically > equivalent to the plain text content. >3. The improved recipient experience afforded by HTML has no value >beyond what can be > done in plain text. >4. The cost of bandwidth will remain fixed at 1992 levels. > >While I’m not a huge fan of the various forms of rich text for most >emails, I do acknowledge that they do sometimes have merit and that >in those cases, having a plain-text alternative included in the >message for backwards compatibility with less capable or automated >email consumers is, IMHO, preferable to not having it and consumes >very little bandwidth by today’s standards. > >Owen
