Re: [apps-discuss] New I-D: text/markdown Media Type - draft-seantek-text-markdown-media-type-00

[Sean Leonard <[e-mail]>]

I agree with most of what Ned said, which is what led me to write the 
draft in the first place.

On 7/10/2014 9:15 AM, Ned Freed wrote:
>
> There's huge benefit. By requiring separate registrations, you'll effectively
> guarantee that nobody is going to bother registering many if not most of the
> variants. Or worse, they'll send around variants incorrectly tagged with one
> of the registered names. The process, even the far more lightweight one
> associated with vendor tree registrations, is simply too onerous for most
> people to bother with.
>
> There's tons of "running code" to back up my assessment here.

Yes. In the real world, most people use text/x-WHATEVER and call it a 
day, for years. It makes it into products, then it makes it into 
exchange formats, then it's all over the place.

> [...] We're being asked to publish a
> registration of a name and set of parameters for something that already exists.
> Nothing more.
>
> Now, maybe doing this is inappropriate. Maybe this type belongs in the  vendor
> tree, [...]
>
> My personal opinion is that defining this type, more or less as-is, in the
> standards tree is fine as long as the security considerations are beefed up
> substantially. I would actually prefer the approach of making this a format
> value for text/plain, but I think the security issues make that a bad idea.

The security issues alone warrant making Markdown content with its own, 
separate type (or series of types). Fundamentally Markdown is much 
closer to text/html than text/plain: it is one step away from being 
converted to HTML (or some other document type that can include active 
content, such as application/pdf), and can contain "islands" of markup. 
It may be a "lightweight" markup language, but it's still a markup language.

As for the vendor tree, I ruled that out early on in the drafting. 
Section 3.2 of RFC 6838 states:

    The vendor tree is used for media types associated with publicly
    available products.  "Vendor" and "producer" are construed very
    broadly in this context and are considered equivalent.  Note that
    industry consortia as well as non-commercial entities that do not
    qualify as recognized standards-related organizations can quite
    appropriately register media types in the vendor tree.

    A registration may be placed in the vendor tree by anyone who needs
    to interchange files associated with some product or set of products.
    However, the registration properly belongs to the vendor or
    organization producing the software that employs the type being
    registered, [...]


In this case, Markdown has become a techno-cultural phenomenon (like 
"mashups" and "emoji")--a force that is no longer owned by any one 
vendor or producer. Comparable lightweight markup languages are 
controlled by known entities or specific (if loose) industry consortia, 
such as:
BBCode  = bulletin board software vendors (UBB, vBulletin, etc.)
reStructuredText = Python
Javadoc = Java / Oracle
MediaWiki syntax = MediaWiki

One reason why Markdown has gotten such wide uptake has been because of 
its laissez-faire management approach: One guy did some stuff and then 
other guys did other stuff in other languages and then it became part of 
common web toolkits and then people extended it some more in their toolkits.

Thus: standards tree may not be the ideal fit, but it seems to me to be 
the best fit of all of the options. A lot of value will be generated 
simply by reflecting what Markdown is (as a technology and as a 
community), rather than shoehorning it into a process that neither the 
technology nor the community are likely to follow.

Whatever it is, I think it is important to make any registration 
procedure as simple and axiomatic as possible.

Sean