Subject: [apps-discuss] draft-ietf-appsawg-text-markdown-02 and the registry

From: Michel Fortin <[email-masked]>
Date: Wed, 24 Sep 2014 08:09:45 -0400

It's pretty hard for me to do a meaningful review a document when I disagree with so much of it.

Those who use Markdown generally don't need a MIME type. Markdown is rarely an interchange format, and it isn't meant to be one. There is a small subset of Markdown users who want a MIME type, but it's not entirely clear to me why. I'd guess some want it as a decorative replacement to text/plain (text/markdown fells better) and I'd guess some want it to try to bring some interoperability.

The later use case, interoperability, is still an open problem with Markdown. There are many reasons contributing to that: there's a low barrier of entry for writing a new parser, there's no formal specification and no single test suite, and most implementers want something that works for their own need (official spec be damned) and later acquire some more users. There is very little intensive for most implementers of Markdown parsers to make things interoperable because what we publish is not the document but the processed version of it. Add to that that most parsers are written in people's spare time, or at least that's my case.

There is a small subset of users who want a MIME type, but I'm going to bet most Markdown implementers do not care at all. I, author of PHP Markdown, personally don't really care much about this spec. (I'm in fact currently having second thoughts about accepting to be a reviewer given the complexity of the proposal makes things more bothersome than I expected.) John Gruber doesn't care much either. I bet it's the case of most implementers out there.

Hence, I think the requirement that parser implementers register anything is deeply flawed. If there is a registry to be maintained, it should be maintained by the subset of users who care about having a things registered in a central place, which for the most part does not include implementers of Markdown parsers.

 - - -

My suggestion is to find a way to make the type descriptive enough without prescribing any action on anyone's part.

So register text/markdown. If we want a flavor parameter, I'd suggest making it an informal list of comma-separated identifiers denoting possible flavor candidates to use in order of preference:

	text/markdown; flavor="Markdown Extra, MultiMarkdown, Maruku"

Somewhat like the font-family directive in CSS, I think it'd work best by not having a registry at all. If there is one, I'm pretty sure it's going to be ignored by most users anyway.

As for the "processor", "processor-arguments", and "output-type" parameters, I don't think they have their place in a MIME type.

-- 
Michel Fortin
[email-masked]
http://michelf.ca

---

From: "Fletcher T. Penney" <[email-masked]>
Date: Wed, 24 Sep 2014 08:21:55 -0400

On Sep 24, 2014, at 8:09 AM, Michel Fortin <[email-masked]> wrote:

<snipp'ed>

> There is a small subset of users who want a MIME type, but I'm going to bet most Markdown implementers do not care at all. I, author of PHP Markdown, personally don't really care much about this sp…

...

> As for the "processor", "processor-arguments", and "output-type" parameters, I don't think they have their place in a MIME type.

Agreed.

I understand that this flies in the face of the OCD tendencies of many of us to want something more precise, but I still believe this is an area where precision is going to be wasted.

FTP

> 
> -- 
> Michel Fortin
> [email-masked]
> http://michelf.ca
> 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

-- 
Fletcher T. Penney
[email-masked]

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 24 Sep 2014 15:23:00 +0200

I don't see why this has to include much text at all.

People do use MIME types, so registering one for such a widely used format 
makes sense. But why does it need to specify much?

"Markdown is a family of mostly compatible formats, called flavours. This 
document does not define a canonical markdown. The flavour argument can be 
used to name the particular flavour, including..." and then list the 
flavours for which there is a convenient stable reference. "The flavour 
argument is optional. Note that some flavours are incompatible in minor 
ways." Registered and done. 95% of the benefit for 20% of the text.

Arnt

---

From: Ned Freed <[email-masked]>
Date: Wed, 24 Sep 2014 07:57:29 -0700 (PDT)

> ways." Registered and done. 95% of the benefit for 20% of the text.

+1. Sometimes less is more.

				Ned

---

From: Dave Cridland <[email-masked]>
Date: Wed, 24 Sep 2014 16:08:14 +0100

> ways." Registered and done. 95% of the benefit for 20% of the text.

I'm in agreement, with the additional note that if anyone tries to include
arbitrary command line arguments in the parameters of a media type I may
have to just send them mail saying the processor is "rf -rf /".

Dave.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Sep 2014 09:28:10 -0700

> +1. Sometimes less is more.

In order to avoid an inherently contentious point, I suggest:

   mostly compatible  ->  related

"Mostly compatible" also means "incompatible".

(In the early days of Internet commercialization, vendors wishing to
continue to sell proprietary solutions -- since those have higher profit
margins -- would have data sheets that described their products as
"based on open standards".  "Based on" was a code phrase for
"non-interoperable". The product only worked with products from that
vendor...)

Rather than invoke any of the compatibility issue, the suggested word
change provides what's needed and not more.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net