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

[Ned Freed <[e-mail]>]

> On 7/9/2014 1:55 PM, Ned Freed wrote:
> >> The way this thread has progressed suggests to me that the spec is
> >> > better as a single, specific media type, with no variant option.
> > My understanding is that there are already multiple variants in play, so
> > you'd need multiple media types right off as well as an effort to get
> > them all registered.
> >
> >> > When a next form of markdown gets traction, give it its own media type
> >> > entry.
> > I'm really not a fan of this approach, but then again, my position as
> > reviewer may bias me somewhat here.

> As others have noted, these 'variants' are incompatible.

> They might have overlap, but they aren't proper subsets.  Consequently
> I'm not hearing benefit in having them share namespace, distinguished by
> an associated parameter.

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.

More generally, having now read a bunch of material on this family of formats,
it seems there's a markedly different engineering aesthetic in play here. It's
one where things are intentionally not locked down, where random people are
encouraged to experiment and create incompatible variants, where heuristic
processing is an intrinsic part of the process, and where things not working
quite right is tolerated. This is all about ease of use, not correctness.

This is emphatically not the approach the IETF takes to engineering, where the
primary goal is interoperability. And so, predictably, there have been multiple
efforts to in effect force this work into the IETF mold. I've seen calls for
someone (who?) to perform an analysis of what's in play here (which even if
possible ignores the fact that what's in play may be very different a year from
now). There have been calls for separate registrions (see above). There have
been calls for what is effectively a capability list. There have been calls for
what amounts to a subregistry. There have even been calls for making this into
a media suffix, which would effectively require a full formal specification of
the format.

All of these suggestions are no doubt well intentioned, but IMO, at least
counterproductive if not wrongminded in this case.

It would be one thing if we were being asked to publish the format as a
standards-track RFC. That would absolutely call for doing a bunch of these
things.

But we're not being asked to do that. 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, where I note that there's not going to be a problem registering this
type. Or maybe the registration should be run through a different standards
org like the W3C that also has access to the standards 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.

				Ned