Re: text/markdown effort in IETF (invite)

[John MacFarlane]

This seems a reasonable proposal to me.  Like Michel Fortin, though,
I suspect the "flavors" part will be more trouble than it's worth.
Is there going to be a distinct flavor for every version of pandoc,
for example?  What about people who use pandoc but disable one or
two of the pandoc extensions (which you can do with a command line
flag)?  Your document mentions "github flavored markdown," but there
are actually two distinct github flavors, one for displaying long-form
documents like READMEs (here hard line breaks are treated as spaces,
as in original markdown), and one of issues and comments (here hard
line breaks are rendered as hard breaks).  It sounds like a LOT of
work to keep the registry of flavors up to date, unless the flavors
are going to be very coarse-grained.

John

+++ Sean Leonard [Jul 09 14 08:49 ]:

Hi markdown-discuss Folks:

I am working on a Markdown effort in the Internet Engineering Task 
Force, to standardize on "text/markdown" as the Internet media type 
for all variations of Markdown content. You can read my draft here: .


The proposal is already getting traction. Is there anyone on this list 
that is interested in participating or helping this effort? In 
particular we need to better understand and document what versions of 
Markdown exist, so that either Markdown as a family of informal 
syntaxes will start to converge, or if not, that Markdown variations 
have an easy way to be distinguished from one another. (See the 
"flavor" parameter discussed in the draft.)


The draft is currently being discussed on apps-disc...@ietf.org.

Kind regards,

Sean Leonard
Author of Markdown IETF Draft
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: text/markdown effort in IETF (invite)

[John MacFarlane]

+++ Michel Fortin [Jul 09 14 18:07 ]:


Fun fact: PHP Markdown is mostly encoding agnostic. It understands UTF-8 
sequences but any byte that is not a valid UTF-8 sequence is treated as a 
character in itself. It's only relevant when converting tabs into spaces 
however, and only if you have non-ASCII characters before the tab.


Small amendment: There are at least two places where the difference
between utf-8 and latin1 matters:  tab expansion (as you note) and
reference links, since these are stipulated to be case insensitive.
(Case conversion is sensitive to the encoding.)

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: text/markdown effort in IETF (invite)

[Sean Leonard]

On 7/9/2014 8:06 PM, Aristotle Pagaltzis wrote:

* Sean Leonard  [2014-07-09 22:10]:

Markdown has no way to communicate the character set in the document
(other than the Unicode Byte Order Marks, which is a generalized
property about text streams, not specific to Markdown)--and it would
be counterproductive to invent one. So that is a perfect example of
relevant metadata. And the second one, is how to turn it into
something else that the author wants. If it's not communicated, it's
going to be implied. Implied means "guessing" and likely "guessing
wrong".

Yet guessing wrong is largely without consequence.

There are really no syntax features that affect the document’s rendering
non-locally. If part of a document is written with unsupported syntax,
only that part will render incorrectly, but the other parts will come
out fine.

There are two use cases that I am particularly interested in:
#1 You put .md files in a project (readme.md, etc.). These .md files are 
then passed around among project users, which may include developers, 
copy-writers, copy-editors, etc. They need to be sure that the readme.md 
is treated in the same way, which ought to be communicated with the 
data. If one person edits the document in UTF-8 and commits and another 
person edits the document in ISO-8859-1, you're going to have problems.


#2 You have some app (let's say some web forum for example, but it 
literally could be anything, an electronic health record, some national 
criminal records, whatever) and you export data from the app. Say to 
some structured data format like XML or a sqlite database. Part of data 
liberation or backup or whatever. You want to get whatever your users 
actually input into the fields--not the HTMLized versions. So you need 
to annotate the blobs of data as Markdown, since users like to upload 
various kinds of data (Word docs, JPEG images, MP4 videos, bits of text 
like names of individuals, whatever).


In both cases, rendering matters "non-locally".



And there are no large overlapping surfaces among the syntaxes of the
various extensions (esp. those for very different document features),
which makes unsupported syntax unlikely to appear to have been intended
to be rendered as some completely dissimilar feature.


As someone new to Markdown development, I really want to see some 
comprehensive references (since "authority" in Markdown-land is notably 
absent). Besides, since Markdown is such a free-for-all, someone could 
easily write a Markdown processor that turns (!) into 
alert('hello!');.




So you will get a document that differs from the author’s intent in some
way. But it will be clear *where* the differences are and you will still
get all of the data in *some* form, quite possibly fully intelligible if
not pretty.
For what we might call "sensible flavors" of Markdown, yes. But the 
author's intent may be poorly represented when processed through a tool 
that injects lolcat pictures every third word. Or, the author's intent 
may be very well-represented.


The point is...we don't know what the author's intent is, /unless the 
author tells us/. And I think we need some more metadata to make the 
author's intent clear.




And because of the primary goal of Markdown to be human-readable in its
source form, there is always an easy and cheap last resort: view source.


This is a goal. Agreed.


Therefore the flavour parameter ought to be considered nothing more than
loosely informative, and the processor should just render the document
to the best of its ability regardless of the flavour specified. It MAY
use the parameter value to adapt to the document, in RFC 2119 lingo, but
ought not be bound by it.

I would reword this:

The flavor parameter informs recipients of the author's intent. The processor 
should just render the document to the best of its ability regardless of the 
flavor specified. It SHOULD
use the parameter value to adapt to the document.



I don't know what should happen if the flavor is absent. I am trying to 
understand. Let me put it this way: if you come across un-annotated 
Markdown in the wild (as in, not attached to any processing scripts, 
instructions, directions, whatever), what do you do? "Guess?"



Furthermore, an absent flavour parameter ought to mean that the flavour
is unspecified, not that it is any particular default flavour; i.e. the
choice of flavour in that case ought to be up to the processor.


The choice of how to act on the Markdown is /always/ up to the 
processor...so...probably. It just may not represent the author's intent.


Between this and the Gruber discussion, I need to get used to this idea 
that "guessing" is a normative part of Markdown culture. :)




Lastly, the spec should mention (as informal guidance to implementors)
that applications containing Markdown processors which have any chance
of being exposed to source documents of unknown flavour should, if at
all possible, provide a means for the user to view the source Markdown
d

Re: Markdown as genericized

[Sean Leonard]

On 7/9/2014 6:32 PM, Fletcher T. Penney wrote:
And in fact, Gruber has clearly stated that he did not intend to give 
away the "Markdown" name:


http://blog.gmane.org/gmane.text.markdown.general/month=20080301/page=13



I don't want to wade into this "what is Markdown and who gets to approve 
it" thing. But to the extent that this is what we know of John Gruber, 
it was said:


>>>
Yuri Takhteyev: /If/ Gruber decides he "despies" our specification, we 
should simply call it something other than "Markdown".


John Gruber: Just to be clear: in that case, you *must* call it 
something other than "Markdown".

>>>

Means:
<<<
/If/ Gruber decides he "despises" our specification, /then in that 
case/, John Gruber says that you *must* call it something other than 
"Markdown".

<<<

All this is to say that Gruber does not say what will happen if he does 
not "despise" someone's specification. So unless he says that he 
"despises" your specification, we have nothing authoritative from him. 
And even if we did, I don't know if it matters.


The only other thing we have is that the original Markdown Perl script 
uses a 3-clause BSD-style license, which says:


 *

   Neither the name "Markdown" nor the names of its contributors may be
   used to endorse or promote products derived from this software
   without specific prior written permission.


To be clear: this is a copyright license, and it only attaches to the 
software Markdown.pl, Markdown Readme.text, and License.text in the 
distribution (reflexively). "Derived" means derived in the copyright law 
sense, as in, you prepared a derivative work. Taking the techniques of a 
software /or its documentation/ and implementing the same techniques (as 
in, doing what the Syntax document says Markdown is supposed to do) 
using your own expression, is neither a copyright law violation nor a 
trademark issue. Only patent law can prevent you from taking techniques 
and practicing them elsewhere.



I don't know if there is much to argue about. Perhaps nobody can rev 
Markdown.pl and release Markdown 2.0 and call it "Markdown 2.0" (but 
obviously, they can call it something else). Interestingly, the Syntax 
webpage at  has no 
license attached; all we know is that it is "Copyright © 2002--2014 The 
Daring Fireball Company LLC." Just because you invent words (or invent 
capitalizations to words) doesn't mean that you can now prevent others 
from using those words, unless of course you register them as 
trademarks, and enforce your rights.


The overall point being...ok, you can't call your specification 
Markdown, but you can call it "Markdown Syntax", since that isn't 
"Markdown".  And there is such as thing as Markdown syntax--it is the 
collection of techniques that one can use with inputs to Markdown.pl /or 
other tools/, and expect certain outputs.


I think this is easy enough to understand if you replace "Markdown" with 
"grep". "grep" is a tool. When you refer to "grep" as a noun, you're 
referring to the command-line utility. But there is such a thing as 
"grep syntax" and "grep syntax" is a collection of techniques that are 
implemented in the original grep by Ken Thompson, as well as 
replacements to grep.


Just as FTP pointed out, some Markdown tools (MultiMarkdown) have modes 
or switches (-c) that make the tool more compatible with the original 
Markdown, versus more "feature-some". Similarly some grep tools have 
similar switches to enable or disable particular behaviors of their 
implementations.



-Sean
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: text/markdown effort in IETF (invite)

[Karl Dubost]

Aristotle,

Le 10 juil. 2014 à 12:06, Aristotle Pagaltzis  a écrit :
> Lastly, the spec should mention (as informal guidance to implementors)
> that applications containing Markdown processors which have any chance
> of being exposed to source documents of unknown flavour should, if at
> all possible, provide a means for the user to view the source Markdown
> document in unformatted form.

Very good point. Added to
https://github.com/karlcow/markdown-testsuite/issues/59


-- 
Karl Dubost 🐄
http://www.la-grange.net/karl/

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: text/markdown effort in IETF (invite)

[Aristotle Pagaltzis]

* Sean Leonard  [2014-07-09 22:10]:
> Markdown has no way to communicate the character set in the document
> (other than the Unicode Byte Order Marks, which is a generalized
> property about text streams, not specific to Markdown)--and it would
> be counterproductive to invent one. So that is a perfect example of
> relevant metadata. And the second one, is how to turn it into
> something else that the author wants. If it's not communicated, it's
> going to be implied. Implied means "guessing" and likely "guessing
> wrong".

Yet guessing wrong is largely without consequence.

There are really no syntax features that affect the document’s rendering
non-locally. If part of a document is written with unsupported syntax,
only that part will render incorrectly, but the other parts will come
out fine.

And there are no large overlapping surfaces among the syntaxes of the
various extensions (esp. those for very different document features),
which makes unsupported syntax unlikely to appear to have been intended
to be rendered as some completely dissimilar feature.

So you will get a document that differs from the author’s intent in some
way. But it will be clear *where* the differences are and you will still
get all of the data in *some* form, quite possibly fully intelligible if
not pretty.

And because of the primary goal of Markdown to be human-readable in its
source form, there is always an easy and cheap last resort: view source.

Bottom line, misrendering a document due to wrong choice of flavour is
annoying but inconsequential, due to the very nature of Markdown.

Therefore the flavour parameter ought to be considered nothing more than
loosely informative, and the processor should just render the document
to the best of its ability regardless of the flavour specified. It MAY
use the parameter value to adapt to the document, in RFC 2119 lingo, but
ought not be bound by it.

Furthermore, an absent flavour parameter ought to mean that the flavour
is unspecified, not that it is any particular default flavour; i.e. the
choice of flavour in that case ought to be up to the processor.

Lastly, the spec should mention (as informal guidance to implementors)
that applications containing Markdown processors which have any chance
of being exposed to source documents of unknown flavour should, if at
all possible, provide a means for the user to view the source Markdown
document in unformatted form.

Regards,
-- 
Aristotle Pagaltzis // 
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: text/markdown effort in IETF (invite)

[Fletcher T. Penney]

You appear to be testing MultiMarkdown in standard mode, rather than 
compatibility mode (`-c`).  If you're going to test against standard Markdown 
syntax you should use compatibility mode as it disables the additional features 
that alter the output (e.g. smart typography, anchors on headers, etc.).

When doing this properly, it appears that MMD fails only one test, which I will 
work on.

FTP

-- 
Fletcher T. Penney
fletc...@fletcherpenney.net 

On Jul 9, 2014, at 9:18 PM, Karl Dubost  wrote:

> Hi,
> 
> Michel Fortin said:
>> Markdown is in the spot where HTML was before HTML5 with each implementation 
>> doing its own thing. I don't know if Markdown will get out of there anytime 
>> soon.
> 
> Yes basically. And it's why Ciro Santilli has done an amazing work upon the 
> [test suite][1] I have started. 
> 
> [1]: https://github.com/karlcow/markdown-testsuite
> 
> The "issue" with Markdown and its flavors is that it is mainly used: 
> 
> * asan input format for something else, aka in a converter scenario
> * more than an exchange format with multiple emitters/consumers needing 
> interoperability.
> 
> It starts to change with the rise of some clients and this ties to the 
> mime-type "issue":
> 
>> I'll point out however that HTML never got anything like a "flavor" 
>> parameter in its MIME type, and even if it did it'd not have helped clear 
>> the mess in any way.
> 
> Yup agreed. A [MIME type][2] is useful in the case of "exchange format" when 
> an emitter and a receiver needs to understand what they are exchanging. In 
> the case of the input format, there is no issue because the environment is 
> constrained. When you play with multiple clients, the interoperability story 
> becomes interesting.
> 
> [2]: http://tools.ietf.org/html/draft-seantek-text-markdown-media-type-00
> 
> -- 
> Karl Dubost 🐄
> http://www.la-grange.net/karl/
> 
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss



smime.p7s
Description: S/MIME cryptographic signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Markdown as genericized

[Fletcher T. Penney]

If this in response to my earlier comment, as stated, I refer to the behavior 
of honest people…  not the behavior of those who would refer only to the law 
without consideration of what is clearly right or wrong.  Markdown was created 
by John Gruber, and until he states otherwise, he "owns" the name.  To take it 
away on the basis of rules of intellectual property rules may or may not be 
legal, but that doesn't make it right.

And in fact, Gruber has clearly stated that he did not intend to give away the 
"Markdown" name:

http://blog.gmane.org/gmane.text.markdown.general/month=20080301/page=13


I am not aware of any subsequent recanting of this opinion -- please provide a 
reference if you believe otherwise.


I would not support any effort to coopt the "Markdown" name without Gruber's 
approval.  If this is anyone's intent, count me out.  Hopefully the developers 
of the other major "Sons of Markdown" will follow suit, but I can speak only 
for myself.



FTP

-- 
Fletcher T. Penney
fletc...@fletcherpenney.net 

On Jul 9, 2014, at 9:20 PM, Jeff McNeill  wrote:

> Markdown has become genericized (and was never registered or defended as 
> intellectual property). See http://en.wikipedia.org/wiki/Generic_trademark
> 
> The idea that Gruber has to (or even ever would) sign off on anything is 
> counter to his behavior and stated opinion on the matter. His historical 
> involvement and contemporary non-involvement should not become an impediment 
> or even an issue for markdown-related development.
> 
> Sincerely,
> --
> Jeff McNeill 
> 
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss



smime.p7s
Description: S/MIME cryptographic signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Markdown as genericized

[Shane McCarron]

I personally agree with this and I would be happy to continue working
within the W3C or elsewhere to get a baseline standard defined.


On Wed, Jul 9, 2014 at 8:20 PM, Jeff McNeill  wrote:

> Markdown has become genericized (and was never registered or defended as
> intellectual property). See http://en.wikipedia.org/wiki/Generic_trademark
>
> The idea that Gruber has to (or even ever would) sign off on anything is
> counter to his behavior and stated opinion on the matter. His historical
> involvement and contemporary non-involvement should not become an
> impediment or even an issue for markdown-related development.
>
> Sincerely,
> --
> Jeff McNeill
>
>
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Markdown as genericized

[Jeff McNeill]

Markdown has become genericized (and was never registered or defended as
intellectual property). See http://en.wikipedia.org/wiki/Generic_trademark

The idea that Gruber has to (or even ever would) sign off on anything is
counter to his behavior and stated opinion on the matter. His historical
involvement and contemporary non-involvement should not become an
impediment or even an issue for markdown-related development.

Sincerely,
--
Jeff McNeill
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: text/markdown effort in IETF (invite)

[Karl Dubost]

Hi,

Michel Fortin said:
> Markdown is in the spot where HTML was before HTML5 with each implementation 
> doing its own thing. I don't know if Markdown will get out of there anytime 
> soon.

Yes basically. And it's why Ciro Santilli has done an amazing work upon the 
[test suite][1] I have started. 

[1]: https://github.com/karlcow/markdown-testsuite

The "issue" with Markdown and its flavors is that it is mainly used: 

* asan input format for something else, aka in a converter scenario
* more than an exchange format with multiple emitters/consumers needing 
interoperability.

It starts to change with the rise of some clients and this ties to the 
mime-type "issue":

> I'll point out however that HTML never got anything like a "flavor" parameter 
> in its MIME type, and even if it did it'd not have helped clear the mess in 
> any way.

Yup agreed. A [MIME type][2] is useful in the case of "exchange format" when an 
emitter and a receiver needs to understand what they are exchanging. In the 
case of the input format, there is no issue because the environment is 
constrained. When you play with multiple clients, the interoperability story 
becomes interesting.

[2]: http://tools.ietf.org/html/draft-seantek-text-markdown-media-type-00

-- 
Karl Dubost 🐄
http://www.la-grange.net/karl/

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: text/markdown effort in IETF (invite)

[Jason Davies]

While I don't disagree with these points, I don't think they are 
necessarily *the* point.


Markdown is -- sometime-- used as Markdown, by which I mean I read it 
raw and send it to people raw. But the vast majority of the time, it's a 
lightweight mark-up language and - most importantly - a transitional 
mode. It becomes something else (html, TeX, opml etc).


Its virtues are simplicity and adaptability. So, for instance, in 
Mailmate I can write in markdown and it will be interpreted into html 
rich text. But for that very reason, it doesn't implement numbered lists 
(the developer explained to me that this became problematic when you 
convert *back*, in a reply, which Mailmate has a good stab at.)


In other words, there are going to be reasons why someone might 
implement in differently for valid reasons (which you may or may not 
agree with). So you could say it's not true Markdown (well, it's not if 
you use Gruber's syntax). But its simplicity and growing popularity 
means that it's too tempting to use it: otherwise he would have to 
invent a parallel beta-code with a different syntax which is as 
frustrating as the way that different wikis use different mark-up  
(drives me nuts...I can never remember the different dialects).


So if you created a 'standard markdown', as HTML 5 did, you would also 
have a bunch of people who wouldn't implement it fully. HTML 5 was made 
mission critical by two things, it seems to me: 1) Microsoft's 
deliberate attempts to break HTML's universal rendering forced the 
community to unite and sort it out 2) the fact that massive commercial 
and social implications arose from websites not working properly. If IE 
had not been such a pain to code for, and the consequences of the minor 
variations were not great, you'd never have had HTML 5 -- there would 
not have been the will.


Markdown does not currently have that scenario. Its greatest asset is 
its relatively low-level specification and elegance. So, for instance, 
if you want to convert it to LaTeX or OPML, you can through 
multimarkdown. If your website, written in markdown, doesn't work 
properly, you just fix it because you have a standard to fix it against 
(thanks to 5).


So, without a strong impetus to enforce co-operation, If you created a 
new standard, you would *still* end up with one 'true' markdown and 
several variants which people would implement to suit their purposes -- 
which is precisely what you have now. There is a near-perfect 
specification, and there are variants.




There is not the urgency in this case: enforcement is therefore going to 
be a voluntary adherence to a single spec (or not). In other words, we 
are already wherever we are going to end up, with a few details changed.



. On 9 Jul 2014, at 20:06, Sean Leonard wrote:


Some realities are apparent, at least to me:
1. Markdown is a real thing. It's not plain text and it's not 
HTML--it's something different. (Heck, this list could be Markdown!)
2. People are using Markdown for real things of economic and social 
value.
3. Markdown is different from other _lightweight markup languages_. 
I.e., it's not reStructuredText, BBCode, javadocs, or Creole (wiki 
markup). But unlike the aforementioned examples, there is no authority 
that guides its development. (reStructuredText is a Python thing, for 
example, so the Python people are in charge of it.)
4. Things that are called Markdown (MultiMarkdown, GitHub Flavored 
Markdown, etc.) share more in common with each other than those in 
#3--therefore these things are related.
5. People are storing and exchanging Markdown-as-Markdown between 
systems. Not Markdown-as-plain-text, and not Markdown-as-HTML. Thus, 
there is a need for standardized interchange.
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: text/markdown effort in IETF (invite)

[Michel Fortin]

Le 9-juil.-2014 à 16:08, Sean Leonard  a écrit :

> The operating question is: What metadata (companion data) is /necessary/ to 
> reflect the creator's intent with respect to the data?
> 
> With Markdown, I think the answer is: you need the character set, and you 
> need to know how to turn the text into HTML (or XHTML, PDF, RTF, MS 
> Word/Office Open XML, or whatever).

Indeed.


> Markdown has no way to communicate the character set in the document (other 
> than the Unicode Byte Order Marks, which is a generalized property about text 
> streams, not specific to Markdown)--and it would be counterproductive to 
> invent one. So that is a perfect example of relevant metadata.

Fun fact: PHP Markdown is mostly encoding agnostic. It understands UTF-8 
sequences but any byte that is not a valid UTF-8 sequence is treated as a 
character in itself. It's only relevant when converting tabs into spaces 
however, and only if you have non-ASCII characters before the tab.

So whatever the input encoding is becomes the output's encoding (this works for 
HTML). Naturally, it's good to know the input's encoding if you want to know 
the output's. So obviously it's a good idea to specify the text encoding even 
though the parser itself doesn't need it, so you know the resulting document's 
encoding.

That's not really relevant though.


> And the second one, is how to turn it into something else that the author 
> wants. If it's not communicated, it's going to be implied. Implied means 
> "guessing" and likely "guessing wrong".

Ideally you'd use the exact same version of the same parser the author used to 
interpret the document in the first place.

Or you could be loose and use another version of the same parser.
Or you could be loose and use another parser claiming to be of the same flavor.
Or you could be loose and use another parser claiming to be of a superset of 
the given flavor.
Or you could be loose and use another Markdown parser.

It's a spectrum. Each step down will increase the likeliness of something going 
wrong.


> Hopefully this makes sense. I want to be more educated about this.

This makes perfect sense, but I fear there's no good answer to your second 
question. Since you want to know more, here's some insight.

It's important to understand that there is no notion of invalid Markdown input. 
As an implementer every time you fix what looks like a parsing bug to you or 
add a feature you're also breaking some valid input that was producing 
something else before. The implementer will usually only choose to break valid 
input that was deemed very unlikely to ever have been used before, but there's 
no way to know for sure (and no reliable way to measure impact either). So if 
you really really want to be sure things are parsed in the intended way, you 
should use the closest version possible of the same parser as the creator of 
the document was using.

Also, subtle changes can make things technically incompatible. For instance, 
Markdown Extra is mostly a superset of the original Markdown feature-wise, 
except for one small incompatible change: underscore emphasis within a word is 
disallowed. This was a deliberate change to fix some problems users were having 
with words that contained underscore. So even though most people would consider 
Markdown Extra as a superset of Markdown, it technically isn't. Other 
implementers might do the same thing but consider it as a bug fix instead and 
tell their users implementation implements the original syntax.

Babelmark 2 will tell you that implementations are pretty much evenly split on 
this:
http://johnmacfarlane.net/babelmark2/?normalize=1&text=word_with_emphasis

You'll even see that Pandoc implements both behaviour depending on whether 
you're in strict mode or not.

Something stranger happens with the shortcut reference syntax:
http://johnmacfarlane.net/babelmark2/?normalize=1&text=%5Blink%3F%5D%0A%0A%5Blink%3F%5D%3A+http%3A%2F%2Flink.x%2F

It's pretty much universally supported. It comes from a Markdown.pl beta that 
was never formally released but which is widely in use. If you were to go to 
the Markdown website and use the download link, you won't get the beta and it 
won't work. And while the second one is feature-wise a superset of the first, 
technically it could in some rare situations break documents, turning square 
bracketed text into links where it shouldn't:

Someone on [street Ivanhoe Carol][sIC] told me this:

> This is bad [sic].

[sIC]: http://sic.sickdomain

I sure wish things would be simpler. But as things are now, I have a hard time 
identifying what "flavor" could mean. Should "Markdown.pl-1.0.1" be a flavor on 
its own?


-- 
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

RE: text/markdown effort in IETF (invite)

[Waylan Limberg]

I think this comment [1] by Gruber on the mailing list in the past can shed
some light on what the spec is (is it markdown.pl, the syntax rules on
daringfireball.net, some mashup of various implementations, or something
else?). According to Gruber, it is the syntax rules and that's it. If that
is not "good enough" to get a mime-type, then I don’t think there is
anything else we can do.

[1]:
http://six.pairlist.net/pipermail/markdown-discuss/2008-February/001001.html

-Original Message-
From: Markdown-Discuss [mailto:markdown-discuss-boun...@six.pairlist.net] On
Behalf Of Sean Leonard
Sent: Wednesday, July 09, 2014 4:00 PM
To: markdown-discuss@six.pairlist.net
Subject: Re: text/markdown effort in IETF (invite)

On 7/9/2014 12:06 PM, Michel Fortin wrote:
> Le 9-juil.-2014 à 11:49, Sean Leonard  a écrit :
>
>> Hi markdown-discuss Folks:
>>
>> I am working on a Markdown effort in the Internet Engineering Task Force,
to standardize on "text/markdown" as the Internet media type for all
variations of Markdown content. You can read my draft here:
.
>>
>> The proposal is already getting traction. Is there anyone on this 
>> list that is interested in participating or helping this effort? In 
>> particular we need to better understand and document what versions of 
>> Markdown exist, so that either Markdown as a family of informal 
>> syntaxes will start to converge, or if not, that Markdown variations 
>> have an easy way to be distinguished from one another. (See the 
>> "flavor" parameter discussed in the draft.)
> The "flavor" parameter is a good idea in theory. I'm not sure it'll be
very useful in general though. Nobody is going to annotate their file with
the right flavor unless there's a tangible benefit, and I don't see what the
benefit could be. Software that could do something useful with
markdown-identified content will likely ignore the flavor part when parsing
because no one wants to see "incompatible flavor" errors, especially when
commonly used parts of the syntax are compatible anyway.
>
> Markdown is in the spot where HTML was before HTML5 with each
implementation doing its own thing. I don't know if Markdown will get out of
there anytime soon. I'll point out however that HTML never got anything like
a "flavor" parameter in its MIME type, and even if it did it'd not have
helped clear the mess in any way.

Ok so here is where I really want to focus and learn some stuff from the
Markdown community. I am a fairly heavy Markdown user, but not a Markdown
developer or maintainer [yet].

 From what I have gathered of Markdown history as an observer, getting this
into one standardized syntax is like herding cats. Someone complains about
how _ and * interact, or how to do tables such-and-such a way, and then they
go off and write a different tool that does it differently. Ultimately it's
as much about style (which is very
personal) as functionality. To make matters worse, Gruber isn't providing
leadership, so anyone can write "Son of Markdown" and before you know it
we'll have 50 different standards. 

If someone else manages to write a formal specification, I am happy to refer
to that normatively in the (proposed) IETF work. If the community manages to
coalesce around that spec, I am also happy to refer to that spec as the
exclusive normative reference. But...you may as well boil the ocean. So I'm
not going to attempt that. I just want to call the ocean for what it is, and
it's not text/plain. :)

Sean

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: text/markdown effort in IETF (invite)

[Sean Leonard]

On 7/9/2014 12:06 PM, Michel Fortin wrote:

Le 9-juil.-2014 à 11:49, Sean Leonard  a écrit :
The "flavor" parameter is a good idea in theory. [...] Nobody is going to 
annotate their file with the right flavor unless there's a tangible benefit[...]

[...] HTML never got anything like a "flavor" parameter in its MIME type, and 
even if it did it'd not have helped clear the mess in any way.


About this "flavors" thing. I know there are several lists floating out 
there of different Markdown implementations and variants (or if you 
don't like them being called Markdown, you can call them Illegitimate 
Sons of Markdown™). Which list is the most complete? Can someone show me 
(or make for the community) a really comprehensive list, and agree to 
update it?


When I wrote the -00 draft, I tried to follow the Media Type 
Registration Procedures. One requirement is to list required and 
optional parameters. Parameters are defined in RFC 6838 as "companion 
data". See RFC 6838 and in particular, Sections 1, 4.2.1, and 4.3.


All text/ types have at least one parameter: the charset. That is 
because all text data has to be interpreted according to a code (i.e., 
character set) that converts the bits of data into useful information. 
Nowadays we take Unicode (specifically UTF-8) for granted, but it's just 
not the case in reality. You can't just open a text file and hope for 
the best--you have to have /metadata/, express or implied, that tells 
you how to handle the blob of bits. The very fact that it is textual 
data has to be inferred from other things, such as the filename 
extension (when the data is in a file). A filename is just another piece 
of metadata.


When dealing with HTML, the charset could determined at least six ways:
1. as express external metadata, when the Content-Type has a charset 
parameter in the HTTP header.
2. as implied external metadata, when the HTTP header is absent but the 
client infers it from "other things" (e.g., the server, the IP address, 
or by looking at the ccTLD).
3. as express internal "metadata", with  or 
; or in the case of XHTML, encoding="iso-2022-jp"?>.
4. as express internal *data*, that is, the first bytes are 0xFF 0xFE 
(likely UTF-16LE), 0xFE 0xFF (likely UTF-16BE), or 0xEF 0xBB 0xBF 
(likely UTF-8).
5. as implied internal *data*, that is, "take the first 256 bytes and 
try to see if it decodes to something approximating HTML soup using some 
common character sets; if it fits, you quit".
6. as express user preference, that is, "I'm Japanese in Japan on a 
Windows machine, therefore on my browser, just assume everything is 
Shift-JIS".



See...there are all these crazy options...because nobody standardized on 
the character set when HTTP/HTML was developed; people assumed it was 
US-ASCII and then shoehorned lots of zany ways to make it something else.


At least with Markdown, we can probably safely eliminate #3 since 
Markdown is not intended to generate the  part of (X)HTML.


The operating question is: What metadata (companion data) is /necessary/ 
to reflect the creator's intent with respect to the data?


With Markdown, I think the answer is: you need the character set, and 
you need to know how to turn the text into HTML (or XHTML, PDF, RTF, MS 
Word/Office Open XML, or whatever).


Markdown has no way to communicate the character set in the document 
(other than the Unicode Byte Order Marks, which is a generalized 
property about text streams, not specific to Markdown)--and it would be 
counterproductive to invent one. So that is a perfect example of 
relevant metadata. And the second one, is how to turn it into something 
else that the author wants. If it's not communicated, it's going to be 
implied. Implied means "guessing" and likely "guessing wrong".


Hopefully this makes sense. I want to be more educated about this. Thanks!

Sean

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: text/markdown effort in IETF (invite)

[Sean Leonard]

On 7/9/2014 12:06 PM, Michel Fortin wrote:

Le 9-juil.-2014 à 11:49, Sean Leonard  a écrit :


Hi markdown-discuss Folks:

I am working on a Markdown effort in the Internet Engineering Task Force, to standardize on 
"text/markdown" as the Internet media type for all variations of Markdown content. 
You can read my draft here: 
.

The proposal is already getting traction. Is there anyone on this list that is interested 
in participating or helping this effort? In particular we need to better understand and 
document what versions of Markdown exist, so that either Markdown as a family of informal 
syntaxes will start to converge, or if not, that Markdown variations have an easy way to 
be distinguished from one another. (See the "flavor" parameter discussed in the 
draft.)

The "flavor" parameter is a good idea in theory. I'm not sure it'll be very useful in 
general though. Nobody is going to annotate their file with the right flavor unless there's a 
tangible benefit, and I don't see what the benefit could be. Software that could do something 
useful with markdown-identified content will likely ignore the flavor part when parsing because no 
one wants to see "incompatible flavor" errors, especially when commonly used parts of the 
syntax are compatible anyway.

Markdown is in the spot where HTML was before HTML5 with each implementation doing its 
own thing. I don't know if Markdown will get out of there anytime soon. I'll point out 
however that HTML never got anything like a "flavor" parameter in its MIME 
type, and even if it did it'd not have helped clear the mess in any way.


Ok so here is where I really want to focus and learn some stuff from the 
Markdown community. I am a fairly heavy Markdown user, but not a 
Markdown developer or maintainer [yet].


From what I have gathered of Markdown history as an observer, getting 
this into one standardized syntax is like herding cats. Someone 
complains about how _ and * interact, or how to do tables such-and-such 
a way, and then they go off and write a different tool that does it 
differently. Ultimately it's as much about style (which is very 
personal) as functionality. To make matters worse, Gruber isn't 
providing leadership, so anyone can write "Son of Markdown" and before 
you know it we'll have 50 different standards. 


If someone else manages to write a formal specification, I am happy to 
refer to that normatively in the (proposed) IETF work. If the community 
manages to coalesce around that spec, I am also happy to refer to that 
spec as the exclusive normative reference. But...you may as well boil 
the ocean. So I'm not going to attempt that. I just want to call the 
ocean for what it is, and it's not text/plain. :)


Sean

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

RE: text/markdown effort in IETF (invite)

[Dennis E. Hamilton]

"Flavor" was handled in HTML with the DTD, FWIW.

-Original Message-
From: Markdown-Discuss [mailto:markdown-discuss-boun...@six.pairlist.net] On 
Behalf Of Michel Fortin
Sent: Wednesday, July 9, 2014 12:06
To: Discussion related to Markdown.
Subject: Re: text/markdown effort in IETF (invite)

[ ... ]
Markdown is in the spot where HTML was before HTML5 with each implementation 
doing its own thing. I don't know if Markdown will get out of there anytime 
soon. I'll point out however that HTML never got anything like a "flavor" 
parameter in its MIME type, and even if it did it'd not have helped clear the 
mess in any way.

-- 
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: text/markdown effort in IETF (invite)

[Fletcher T. Penney]

I disagree with the section quoted below.

To my knowledge, Gruber has not officially trademarked "Markdown".

Markdown was a word before Gruber used it, but for different contexts.

I am not a lawyer.

However, in the world of honest people, the word "Markdown" as applied 
to lightweight text formats belongs to Gruber.  Others may play off of 
it (PHP Markdown Extra, my own MultiMarkdown, etc.), but I can't create 
an entirely new syntax and call it Markdown.


FTP


On 7/9/14, 3:06 PM, Sean Leonard wrote:


I am of the same view. Anyone can call anything "Markdown"--no one is
stopping them. Just as anyone can call anything "ASCII art" or "mashups"
(i.e., there might be an ASCII standard but what people do with it is
totally different--it has become a cultural phenomenon). In the draft, I
restricted the eligible formats to "things based on John Gruber's
original Markdown tool and syntax from 2004".


--
Fletcher T. Penney
fletc...@fletcherpenney.net
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: text/markdown effort in IETF (invite)

[Michel Fortin]

Le 9-juil.-2014 à 11:49, Sean Leonard  a écrit :

> Hi markdown-discuss Folks:
> 
> I am working on a Markdown effort in the Internet Engineering Task Force, to 
> standardize on "text/markdown" as the Internet media type for all variations 
> of Markdown content. You can read my draft here: 
> .
> 
> The proposal is already getting traction. Is there anyone on this list that 
> is interested in participating or helping this effort? In particular we need 
> to better understand and document what versions of Markdown exist, so that 
> either Markdown as a family of informal syntaxes will start to converge, or 
> if not, that Markdown variations have an easy way to be distinguished from 
> one another. (See the "flavor" parameter discussed in the draft.)

The "flavor" parameter is a good idea in theory. I'm not sure it'll be very 
useful in general though. Nobody is going to annotate their file with the right 
flavor unless there's a tangible benefit, and I don't see what the benefit 
could be. Software that could do something useful with markdown-identified 
content will likely ignore the flavor part when parsing because no one wants to 
see "incompatible flavor" errors, especially when commonly used parts of the 
syntax are compatible anyway.

Markdown is in the spot where HTML was before HTML5 with each implementation 
doing its own thing. I don't know if Markdown will get out of there anytime 
soon. I'll point out however that HTML never got anything like a "flavor" 
parameter in its MIME type, and even if it did it'd not have helped clear the 
mess in any way.

-- 
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: text/markdown effort in IETF (invite)

[Sean Leonard]

Hello everyone,

On 7/9/2014 9:58 AM, Dennis E. Hamilton wrote:

I think the Internet draft is very clear.  It is not a Standards Track project. 
 It is a MIME-type registration proposal and the procedure for determination of 
flavors should satisfy whatever concerns there are.


That is correct. My purpose in creating this first draft is not to make 
a Markdown standard; it is to identify Markdown content in a 
standardized way, namely, with text/markdown.



In general, a MIME-type registration has to point to some place where there is 
a description of the format.  These are not particularly definitive or 
authoritative in some cases, and this registration could fail for lack of 
something definitive.  That is best dealt with on the IETF discussion list.


Yes, this is a sticking point. Experienced IETFers will raise (and have 
raised) concerns about the authoritative-ness of the format. But IETFers 
have less experience with Markdown compared to you all, which is why I'm 
bringing it up here (and elsewhere).




I have nothing to offer concerning "official" Markdown.  It would appear that 
the term has already been appropriated as a common noun and there is no means to protect 
against that being otherwise.


I am of the same view. Anyone can call anything "Markdown"--no one is 
stopping them. Just as anyone can call anything "ASCII art" or "mashups" 
(i.e., there might be an ASCII standard but what people do with it is 
totally different--it has become a cultural phenomenon). In the draft, I 
restricted the eligible formats to "things based on John Gruber's 
original Markdown tool and syntax from 2004".


Some realities are apparent, at least to me:
1. Markdown is a real thing. It's not plain text and it's not HTML--it's 
something different. (Heck, this list could be Markdown!)

2. People are using Markdown for real things of economic and social value.
3. Markdown is different from other _lightweight markup languages_. 
I.e., it's not reStructuredText, BBCode, javadocs, or Creole (wiki 
markup). But unlike the aforementioned examples, there is no authority 
that guides its development. (reStructuredText is a Python thing, for 
example, so the Python people are in charge of it.)
4. Things that are called Markdown (MultiMarkdown, GitHub Flavored 
Markdown, etc.) share more in common with each other than those in 
#3--therefore these things are related.
5. People are storing and exchanging Markdown-as-Markdown between 
systems. Not Markdown-as-plain-text, and not Markdown-as-HTML. Thus, 
there is a need for standardized interchange.


-Sean

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: text/markdown effort in IETF (invite)

[Jason Davies]

On 9 Jul 2014, at 17:07, Fletcher T. Penney wrote:

Unless it were to receive Gruber's blessing, it would have to be named 
something other than Markdown.


Really good summary Fletcher. I think unless someone steps up to create 
Son of Markdown as a project, we should all live with your third option 
(and I am just an inexpert user, would not be able to contribute any 
code/coding logic, so I'm not volunteering).


We could go classical for the name: the latin would be 'subscribe' which 
is not very helpful. (Very bad literal classical) Greek for Son of 
Markdown would be something like 'Hypographides', retaining the allusion 
to Mark-down without actually using Gruber's name.


The elusive acronym 'HGP' appeal to anyone?;)

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

RE: text/markdown effort in IETF (invite)

[Dennis E. Hamilton]

I think the Internet draft is very clear.  It is not a Standards Track project. 
 It is a MIME-type registration proposal and the procedure for determination of 
flavors should satisfy whatever concerns there are.  In general, a MIME-type 
registration has to point to some place where there is a description of the 
format.  These are not particularly definitive or authoritative in some cases, 
and this registration could fail for lack of something definitive.  That is 
best dealt with on the IETF discussion list.

I have nothing to offer concerning "official" Markdown.  It would appear that 
the term has already been appropriated as a common noun and there is no means 
to protect against that being otherwise.  


 -- Dennis E. Hamilton
dennis.hamil...@acm.org+1-206-779-9430
https://keybase.io/orcmid  PGP F96E 89FF D456 628A



-Original Message-
From: Markdown-Discuss [mailto:markdown-discuss-boun...@six.pairlist.net] On 
Behalf Of Fletcher T. Penney
Sent: Wednesday, July 9, 2014 09:08
To: Discussion related to Markdown.
Subject: Re: text/markdown effort in IETF (invite)

I would strongly recommend thinking through some of the "political" 
decisions before getting too far into this.

1) "Markdown" officially refers to the implementation and syntax created 
by John Gruber.

2) "Markdown" the perl implementation has not seen a bug fix in nearly 
10 years.

3) Gruber's voice has been noticeably absent from the list for a long 
time, except for a comment that I recall as basically saying that 
Markdown was essentially feature complete as far as he was concerned.

4) Gruber has specifically said in the past that new projects could not 
coopt the "Markdown" name and would have to be clearly disambiguated. 
For example, I would assume that anyone other than Gruber could not 
create "Markdown 2.0" to be the Markdown to rule them all...

5) I don't have numbers to back this up, but would strongly suspect that 
at this point very few people who think they use "Markdown" actually 
are.  Most are using various derivatives that have made wide-ranging 
decisions on how to handle edge cases, etc.  For most users, whose needs 
are very basic, the distinction is probably academic.  But I would 
suggest that these distinctions are very important when it comes to 
official standards.


I would propose that if there is to be an official standard based on 
"Markdown", it would first require defining what "Markdown" is.  To do 
that would (hopefully) require a more formalized description of the 
grammar.  If Gruber were to sign off on allowing this to use the 
"Markdown" name, fantastic.  But if not, a difficult decision would need 
to be made:

1) Build a standard based on Markdown.pl, bugs and all, and keep the 
"Markdown" name.

2) Develop a formalized version of the core syntax of Markdown, and base 
the standard on this.  Unless it were to receive Gruber's blessing, it 
would have to be named something other than Markdown.

3) Continue to use the term "Markdown" as a vague term that refers to a 
loosely related collection of tools, leaving users to wonder why a given 
document works with one tool, and not others.  At some point, a new 
common standard (e.g. "Son of Markdown" or whatever) may or may not 
arise that would require redefining all of this stuff.  Granted, efforts 
to organize such a standard have thus far failed despite multiple 
enthusiastic discussions over the years on this list.



My $.02


FTP



On 7/9/14, 11:49 AM, Sean Leonard wrote:
> Hi markdown-discuss Folks:
>
> I am working on a Markdown effort in the Internet Engineering Task
> Force, to standardize on "text/markdown" as the Internet media type for
> all variations of Markdown content. You can read my draft here:
> .
>
> The proposal is already getting traction. Is there anyone on this list
> that is interested in participating or helping this effort? In
> particular we need to better understand and document what versions of
> Markdown exist, so that either Markdown as a family of informal syntaxes
> will start to converge, or if not, that Markdown variations have an easy
> way to be distinguished from one another. (See the "flavor" parameter
> discussed in the draft.)
>
> The draft is currently being discussed on apps-disc...@ietf.org.
>
> Kind regards,
>
> Sean Leonard
> Author of Markdown IETF Draft
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss

-- 
Fletcher T. Penney
fletc...@fletcherpenney.net
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown

Re: text/markdown effort in IETF (invite)

[Fletcher T. Penney]

I would strongly recommend thinking through some of the "political" 
decisions before getting too far into this.


1) "Markdown" officially refers to the implementation and syntax created 
by John Gruber.


2) "Markdown" the perl implementation has not seen a bug fix in nearly 
10 years.


3) Gruber's voice has been noticeably absent from the list for a long 
time, except for a comment that I recall as basically saying that 
Markdown was essentially feature complete as far as he was concerned.


4) Gruber has specifically said in the past that new projects could not 
coopt the "Markdown" name and would have to be clearly disambiguated. 
For example, I would assume that anyone other than Gruber could not 
create "Markdown 2.0" to be the Markdown to rule them all...


5) I don't have numbers to back this up, but would strongly suspect that 
at this point very few people who think they use "Markdown" actually 
are.  Most are using various derivatives that have made wide-ranging 
decisions on how to handle edge cases, etc.  For most users, whose needs 
are very basic, the distinction is probably academic.  But I would 
suggest that these distinctions are very important when it comes to 
official standards.



I would propose that if there is to be an official standard based on 
"Markdown", it would first require defining what "Markdown" is.  To do 
that would (hopefully) require a more formalized description of the 
grammar.  If Gruber were to sign off on allowing this to use the 
"Markdown" name, fantastic.  But if not, a difficult decision would need 
to be made:


1) Build a standard based on Markdown.pl, bugs and all, and keep the 
"Markdown" name.


2) Develop a formalized version of the core syntax of Markdown, and base 
the standard on this.  Unless it were to receive Gruber's blessing, it 
would have to be named something other than Markdown.


3) Continue to use the term "Markdown" as a vague term that refers to a 
loosely related collection of tools, leaving users to wonder why a given 
document works with one tool, and not others.  At some point, a new 
common standard (e.g. "Son of Markdown" or whatever) may or may not 
arise that would require redefining all of this stuff.  Granted, efforts 
to organize such a standard have thus far failed despite multiple 
enthusiastic discussions over the years on this list.




My $.02


FTP



On 7/9/14, 11:49 AM, Sean Leonard wrote:

Hi markdown-discuss Folks:

I am working on a Markdown effort in the Internet Engineering Task
Force, to standardize on "text/markdown" as the Internet media type for
all variations of Markdown content. You can read my draft here:
.

The proposal is already getting traction. Is there anyone on this list
that is interested in participating or helping this effort? In
particular we need to better understand and document what versions of
Markdown exist, so that either Markdown as a family of informal syntaxes
will start to converge, or if not, that Markdown variations have an easy
way to be distinguished from one another. (See the "flavor" parameter
discussed in the draft.)

The draft is currently being discussed on apps-disc...@ietf.org.

Kind regards,

Sean Leonard
Author of Markdown IETF Draft
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss


--
Fletcher T. Penney
fletc...@fletcherpenney.net
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

text/markdown effort in IETF (invite)

[Sean Leonard]

Hi markdown-discuss Folks:

I am working on a Markdown effort in the Internet Engineering Task 
Force, to standardize on "text/markdown" as the Internet media type for 
all variations of Markdown content. You can read my draft here: 
.


The proposal is already getting traction. Is there anyone on this list 
that is interested in participating or helping this effort? In 
particular we need to better understand and document what versions of 
Markdown exist, so that either Markdown as a family of informal syntaxes 
will start to converge, or if not, that Markdown variations have an easy 
way to be distinguished from one another. (See the "flavor" parameter 
discussed in the draft.)


The draft is currently being discussed on apps-disc...@ietf.org.

Kind regards,

Sean Leonard
Author of Markdown IETF Draft
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss