Re: [ietf-smtp] [Proposal] 250-MARKDOWN

Gilles Chehade <gilles@poolp.org> Wed, 09 January 2019 08:58 UTC

Return-Path: <gilles@poolp.org>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE30A128766 for <ietf-smtp@ietfa.amsl.com>; Wed, 9 Jan 2019 00:58:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=poolp.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id in9M4kx6zTc4 for <ietf-smtp@ietfa.amsl.com>; Wed, 9 Jan 2019 00:58:14 -0800 (PST)
Received: from out.mailbrix.mx (out.mailbrix.mx [212.83.129.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20ADD1274D0 for <ietf-smtp@ietf.org>; Wed, 9 Jan 2019 00:58:13 -0800 (PST)
Received: from poolp.org (localhost [127.0.0.1]) by poolp.org (OpenSMTPD) with ESMTP id 15a710fe; Wed, 9 Jan 2019 09:58:12 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=poolp.org; h=date:from:to :cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=opensmtpd; bh=3V9LdGEImN8chiE9RygqfalFQF4=; b=Ce J7KVKJupuQft881l6XW4WXlYy+fvkRFzTiK3yv18qoGpP66Oii8+hcmZjrIS7xZS ViQ70Q86AwcmP5a8UuqHeaej9+344upYgof/auUAg1iLCzagS8DsLM5v1ddcUKYE Kklv6fZ46RYU0XJx7db2B4XG201k6VOFKlp1ycNdU=
Received: from localhost (poolp.org [local]) by poolp.org (OpenSMTPD) with ESMTPA id 00796831; Wed, 9 Jan 2019 09:58:11 +0100 (CET)
Date: Wed, 09 Jan 2019 09:58:11 +0100
From: Gilles Chehade <gilles@poolp.org>
To: Viruthagiri Thirumavalavan <giri@dombox.org>
Cc: ietf-smtp@ietf.org
Message-ID: <20190109085811.GA99829@ams-1.poolp.org>
References: <CAOEezJRwe9iSbGyBfyHNPn8=2avo6bAoFY56++HLY5+FZHhWgw@mail.gmail.com> <4647.1547019229@turing-police.cc.vt.edu> <CAOEezJSs11cRRd8xYu4TwO1Viayy8CB3-MdAicEKaJRgyn0tdg@mail.gmail.com> <20190109083807.GA41707@ams-1.poolp.org> <CAOEezJSoY23O=x-yvN4cbqwGYJBg2Xt0wd_-sajeYe5dy2swVA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAOEezJSoY23O=x-yvN4cbqwGYJBg2Xt0wd_-sajeYe5dy2swVA@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/JtTLRGVGt9oIM0pz6iY1ppzYiks>
Subject: Re: [ietf-smtp] [Proposal] 250-MARKDOWN
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2019 08:58:18 -0000

On Wed, Jan 09, 2019 at 02:12:39PM +0530, Viruthagiri Thirumavalavan wrote:
> Please take a look here.
> https://gist.github.com/mistergiri/603766f5295802d44cc1a5752ebfa21f#steps-need-to-be-taken
> 
> But it is a flawed proposal.
> 

I read it, but the following doesn't make sense to me:

	Sender should transfer the mail in "text/markdown" if the receiver support that format (250-MARKDOWN).
	Else they can go for multipart/alternative with "text/plain" and "text/html" format as usual.

What's the original content type for the mail here ?

There are multiple ways to understand this depending on what is the type
of the mail to start with. In one case, it might imply that servers need
to convert text/* to text/markdown based on a peer extension, in another
it implies that a text/markdown content should be converted to plain and
html parts, etc...

In cases were no transforms are required in either way, then I don't see
how a session with or without MARKDOWN would differ.

That being said, and as mentioned in another mail, SMTP is for transport
and I think having content-related informations spill in the protocol is
a violation of layers.


> On Wed, Jan 9, 2019 at 2:08 PM Gilles Chehade <gilles@poolp.org> wrote:
> 
> > On Wed, Jan 09, 2019 at 01:10:34PM +0530, Viruthagiri Thirumavalavan wrote:
> > > >
> > > > What happens if my mail server doesn't support markdown?
> > >
> > >
> > > That's why I'm proposing the MARKDOWN extension. MARKDOWN command should
> > be
> > > presented in the EHLO response only if your server supports markdown.
> > >
> > > If your server supports markdown, the mail will be transferred as
> > > text/markdown. Else mail will be transferred as "text/plain" and
> > > "text/html" as usual.
> > >
> > > I hope I understood you correctly.
> > >
> >
> > still unsure I understand how it works, sorry
> >
> > my understanding now is that the server translates DATA between markdown
> > and other content types based on MARKDOWN extension at peer.
> >
> > did i understand correctly ?
> >
> >
> > > On Wed, Jan 9, 2019 at 1:03 PM <valdis.kletnieks@vt.edu> wrote:
> > >
> > > > On Wed, 09 Jan 2019 12:29:43 +0530, Viruthagiri Thirumavalavan said:
> > > >
> > > > > I wanna bring Markdown support to SMTP.  So instead of transferring
> > both
> > > > > "text/plain" and "text/html" versions, future mails can use only
> > > > > "text/markdown".
> > > >
> > > > Well, right off the top, there's the end to end problem.
> > > >
> > > > Say you support text/markdown, and your mail server accepts it to
> > deliver.
> > > > What
> > > > happens if my mail server doesn't support markdown?  Do you send a
> > > > text/markdown
> > > > and hope my MUA can deal with it? If you do that, why bother with an
> > SMTP
> > > > intervention?
> > > >
> > > > Also, see RFC1341, and text/richtext. Ask yourself why you never see
> > > > e-mails with it.
> > > >
> > >
> > >
> > > --
> > > Best Regards,
> > >
> > > Viruthagiri Thirumavalavan
> > > Dombox, Inc.
> >
> > > _______________________________________________
> > > ietf-smtp mailing list
> > > ietf-smtp@ietf.org
> > > https://www.ietf.org/mailman/listinfo/ietf-smtp
> >
> >
> > --
> > Gilles Chehade                                                 @poolpOrg
> >
> > https://www.poolp.org                 tip me: https://paypal.me/poolpOrg
> >
> 
> 
> -- 
> Best Regards,
> 
> Viruthagiri Thirumavalavan
> Dombox, Inc.

-- 
Gilles Chehade						       @poolpOrg

https://www.poolp.org                 tip me: https://paypal.me/poolpOrg