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

[Gilles Chehade <[e-mail]>]

On Wed, Jan 09, 2019 at 01:25:43PM +0530, Viruthagiri Thirumavalavan wrote:
> >
> > After reading your proposal, I don't quite understand what it is about and
> > what is expected from SMTP implementations.
> 
> 
> I wanted to introduce the keyword "MARKDOWN" in the list of EHLO response.
> So the client can understand and transfer the messages directly with
> content type "text/markdown"
> 

but what is preventing the client from doing so today ?

why does the server need to tell the client that it can send in text/markdown,
when the client can already do so and the server doesn't actually care for the
content type since it's part of the DATA and not the transport ?


> The content type is part of the message, not part of the protocol
> 
> 
> I'm using the content type in the message right?
> 

yes, which is why I don't understand why it also needs to be part of protocol.

put it differently, what do you expect the SMTP implementation to do when this
MARKDOWN extension is used that it doesn't do when it isn't used ?


> also your rationale seems to equate one SMTP session to one message but a
> > single session may transport multiple messages with different messages with
> > different content types.
> 
> 
> Ok what am I missing here? When a server says that "I recognize markdown
> format", then the client gonna send markdown messages as it is. I
> understand a session can transport multiple messages. But why do you think
> it won't work?
> 

well, as someone writing a server implementation:

      When a server says that "I recognize markdown format"

that sentence doesn't make sense to me because the server does not recognize a
format or another, it's in charge of the transport, not of rendering or making
any sense out of the DATA part. it feels like a violation of layer, DATA spill
over transport.

Now as to why it wouldn't work, well, assuming the transport protocol actually
had to know what's inside DATA, if you use the MARKDOWN extension then how can
the same session transport another message that's not a markdown message ? The
session is "tainted" as MARKDOWN session when you use that extension... so why
would I bother implementing it if DATA already contains the content-type ?

How comes MARKDOWN is needed and HTML wasn't given that they are basically the
same use-case with a different encoding format ?

Not to mention that many implementations establish SMTP sessions based on what
is on the envelope (FROM/TO) and not what's in DATA, so sessions would require
that implementations look at DATA to determine what it contains before setting
up the SMTP session.

-- 
Gilles Chehade						       @poolpOrg

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