Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-02.txt

From: [email-masked]
Date: Mon, 22 Sep 2014 15:42:17 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Applications Area Working Group Working Group of the IETF.

        Title           : The text/markdown Media Type
        Author          : Sean Leonard
	Filename        : draft-ietf-appsawg-text-markdown-02.txt
	Pages           : 25
	Date            : 2014-09-22

Abstract:
   This document registers the text/markdown media type for use with
   Markdown, a family of plain text formatting syntaxes that optionally
   can be converted to formal markup languages such as HTML.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-text-markdown-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Sean Leonard <[email-masked]>
Date: Mon, 22 Sep 2014 16:54:54 -0700

Colleagues,

draft-02 incorporates a lot of public and private comments that were 
received over the last few weeks. Rather than reiterate all of the 
changes, I provided a change log in Appendix A.

Best regards,

Sean

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 23 Sep 2014 23:22:13 -0700

>    can be converted to formal markup languages such as HTML.

This is my first time through the document, so I may lack some context.
I'm still learning the history and politics; hopefully some of this review
has not yet been tainted by them.

1) You can drop ".txt" from the filename.

2) The section numbering goes backwards after 1.4 somehow.  Is there
anything funny in the XML forcing this?  Or are you editing these by hand?

3) There's an awful lot of context and history being established throughout
Section 1.  It's not clear to me that a document that's supposed to be just
a media type registration needs all this stuff (material SM would call
"marketing").  Based on a cursory review, it looks like Section 1.4,
paragraphs 1, 3, and 4, would be an adequate and complete Section 1.  If
you're keen to have all this context published, you could move the rest to
an appendix.

4) What is now Section 2 should go after what is now Section 4.

5) I'm not sure that I agree the charset should be mandatory.  It seems to
go against what I'm reading in RFC2046 Section 4.1 to not have "us-ascii"
as a default since this is a subtype of the "text" media type.  Why should
this be different from how other text/* types do it?

6) The "flavor" tag itself seems to be a debatable point.  I don't have an
opinion on that yet (more discussion, please), but as defined the name is
case-sensitive.  Is that what we want?  And does it need to be able to
contain spaces or special characters such that it will need to be quoted?

7) The "processor" tag makes me very nervous indeed.  It seems to me
anything you might say as part of the processor argument should be inferred
from the value of the flavor argument, obviating the need for this.  I
would not expect security reviewers or consumers to tolerate the idea that
the author of a MIME header field can tell a consumer what command to run
and with what arguments.  If that were the case, we had better be prepared
to come up with a lot of text or ABNF that hardens this against command
injection attacks.

8) I'm unclear on what the "output-type" tag is for.  Isn't the output
format a function of the context in which the MIME part is being
processed?  For example, if I get this in a piece of email, wouldn't the
markdown processor output in HTML if I'm using an HTML-enabled MUA, or in
text otherwise?

9) Why is this a provisional registration?

10) In Section 4 you talk about private use or custom parameter values
needing to be prefixed with "!".  How is this different from the
now-deprecated practice of prefixing private use header fields with "X-"?
(See BCP 178.)

11) For the flavor parameter, I'm not clear on why it's a mandatory value
that has a default.

12) The requirement to register tools that implement given flavors is
unusual.  What's the impetus here?  I'm also not sure about having a
Designated Expert that to validate every such registration.  That seems
like it could be quite a lot to ask of a volunteer.  Is that necessary?

13) Security Considerations refers to the "template questions in Section
2", but Section 2 is an example section.  Are you using "xref" tags, or
setting section numbers manually?

14) Also in Security Considerations, I suggest at least having a summary of
the Section 4 issues here, if not actually moving them here.

15) RFC1738 is obsoleted by RFCs 4248 and 4266.

16) Appendix A should include a notation like "[RFC Editor: Please delete
this section prior to publication.]"

-MSK

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 24 Sep 2014 16:53:21 +1000

On 24 September 2014 16:22, Murray S. Kucherawy <[email-masked]> wrote:

> ​
Actually it's RFC 3986 that matters; from RFC 3986, Section 1:

| This document obsoletes [RFC2396], which merged "Uniform Resource
| Locators" [RFC1738] and "Relative Uniform Resource Locators"
| [RFC1808] in order to define a single, generic syntax for all URIs.

I really wish the status of RFC 1738 could be fixed up. I've spent two
years trying to work out how to resurrect the "file" scheme because RFC
1738 says it's obsoleted, even though the two RFCs that apparently
obsoleted it only obsoleted a small part, and the one that really replaced
the bulk only "updated" it, and some RFCs that usurped its schemes (looking
at you, RFC 2068/2616) didn't update it at all, and some parts are probably
meant to still be current (the schemes referenced from the IANA registry,
like "file").

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Sep 2014 00:14:31 -0700

> anything funny in the XML forcing this?  Or are you editing these by hand?

It's Markdown, didn't you know?

https://github.com/cabo/kramdown-rfc2629

Though that tool wouldn't do that.

---

From: Sean Leonard <[email-masked]>
Date: Wed, 24 Sep 2014 00:29:06 -0700

On 9/23/2014 11:22 PM, Murray S. Kucherawy wrote:
> On Mon, Sep 22, 2014 at 3:42 PM, <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
> This is my first time through the document,

Yay!

> so I may lack some context.  I'm still learning the history and 
> politics; hopefully some of this review has not yet been tainted by them.
>
No problem.

> anything funny in the XML forcing this?  Or are you editing these by hand?

Good 'ol nroff (NroffEdit, specifically). I think for folks from the 
security-area, nroff is the preferred tool. xml2rfc does not permit fine 
enough control over spacing.

>
> 3) There's an awful lot of context and history being established 
> throughout Section 1.  It's not clear to me that a document that's 
> supposed to be just a media type registration needs all this stuff 
> (material SM would call "marketing").  Based on a cursory review, it 
> looks like Section 1.4, paragraphs 1, 3, and 4, would be an adequate 
> and complete Section 1.  If you're keen to have all this context 
> published, you could move the rest to an appendix.

Noted.

> 4) What is now Section 2 should go after what is now Section 4.

Originally I put the example at the end, but for draft-02 I felt like it 
should be at the beginning. Especially given the lack of a *formal* 
specification, I wanted to be clear with an example up-front. It can go 
back, though.

>
> 5) I'm not sure that I agree the charset should be mandatory.  It 
> seems to go against what I'm reading in RFC2046 Section 4.1 to not 
> have "us-ascii" as a default since this is a subtype of the "text" 
> media type.  Why should this be different from how other text/* types 
> do it?

See RFC 6657 (whole thing) and RFC 6838 Section 4.2.1.

>
> 6) The "flavor" tag itself seems to be a debatable point.  I don't 
> have an opinion on that yet (more discussion, please), but as defined 
> the name is case-sensitive.  Is that what we want?  And does it need 
> to be able to contain spaces or special characters such that it will 
> need to be quoted?

There are a few reasons for the case-sensitivity of the name. First, the 
parameter value can be any Unicode string. The purpose was to enable 
flavors (variants) to be named things in languages other than English. 
See BCP 18 Section 2, "Where to do internationalization". Right now most 
examples of Markdown-related flavors are in English, but it is perfectly 
conceivable that someone can write some Markdown variant in some other 
script. Actually, Markdown itself is starting to be iconized as M↓ by 
the community.

Over the last couple of years, I have become very suspicious about 
case-insensitivity and its interactions with Unicode. It's one thing to 
map the US-ASCII characters U+0041-U+005A (uppercase) to U+0061-U+007A; 
it's another thing to require huge tables of mappings for all sorts of 
scripts out there. See 
<http://en.wikipedia.org/wiki/Letter_case#Unicode_case_folding_and_script_identification> 
for the case folding algorithm. Note that Unicode defines three cases: 
uppercase, lowercase, and title case. Too. Much. Detail.

BCP 18 frames the problem and states specifically that:
"Names are a problem, because people feel strongly about them, many of 
them are mostly for local usage, and all of them tend to leak out of the 
local context at times. RFC 1958 
<http://tools.ietf.org/html/rfc1958>recommends US-ASCII for all globally 
visible names. This document does not mandate a policy on name 
internationalization, but requires that all protocols describe whether 
names are internationalized or US-ASCII."

The compromise position I reached was that you can use Unicode, but you 
SHOULD use US-ASCII. And since I wanted to obviate the case-folding 
issue, I said case-sensitive.

As a bonus: John Gruber is extremely sensitive to capitalization of 
"Markdown".

> anything you might say as part of the processor argument should be 
> inferred from the value of the flavor argument, obviating the need for 
> this.  I would not expect security reviewers or consumers to tolerate 
> the idea that the author of a MIME header field can tell a consumer 
> what command to run and with what arguments.  If that were the case, 
> we had better be prepared to come up with a lot of text or ABNF that 
> hardens this against command injection attacks.

I think the security risk is significantly mitigated (perhaps even 
eliminated) by registration. Will write in separate e-mail.

> processed?  For example, if I get this in a piece of email, wouldn't 
> the markdown processor output in HTML if I'm using an HTML-enabled 
> MUA, or in text otherwise?

First, thanks for the open discussion of output-type. I think the text 
spells it out. text/html is what most people think of...but text/html is 
not the way that Markdown is going. Markdown is slowly encroaching upon 
every other format, because other formats are "too complicated".

The use case of an e-mail client showing the HTML output of Markdown 
inline, is not realistic. As someone else noted earlier, if you write an 
e-mail in Markdown and want the recipient to see formatted text, the 
expectation is that the sending mail client will do the formatting, so 
in an e-mail, the received data will be text/html.

Probably a better scenario (which is becoming a significant use case) is 
authors collaborating on a document. The authors on disparate machines 
*both* want to see the source, *and* the output, preferably at the same 
time. Maybe one collaborator is the author and the other is an editor or 
reviewer.

> 9) Why is this a provisional registration?

Oh, just because it's an Internet-Draft. I sent a registration request 
for a provisional registration back after draft-01 was published. I 
think it's being held up by an IANA question of whether I-Ds can do 
provisional registrations, or if it requires AD action.

Anyway, that field should be changed to "No".

> now-deprecated practice of prefixing private use header fields with 
> "X-"?  (See BCP 178.)

I was not aware of BCP 178 at the time. Also, several commenters asked 
for a way to use unregistered identifiers...I don't want to quote them 
directly but I recall that they expressed concerns that nobody would 
bother registering identifiers. Now that I am aware of BCP 178, I agree 
that the unregistered value mechanism should be removed. The right way 
to fix this is to make registration very simple. I am less sure about 
provisional registrations...that sounds more complicated (and moreover, 
it sounds like an invitation to do a provisional registration and then 
skip town).

>
> 11) For the flavor parameter, I'm not clear on why it's a mandatory 
> value that has a default.

It's optional.

The text does say "Generators MUST NOT emit empty flavor 
parameters"...but then it proceeds, "but parsers MUST treat empty flavor 
parameters the same as if omitted." The whole parameter is optional. The 
point is that there is a syntactic difference between:
  text/markdown; flavor=""
and
  text/markdown

but there is no semantic difference--they mean the same thing.

> unusual.  What's the impetus here?
Section 5.1.1.:
"The purpose of the tool requirement is to ensure that the flavor is 
actually used in practice."

Due to the proliferation of processors, there have been very many calls 
in the Markdown community to have "one true formalized syntax". So that 
means that now there is a proliferation of syntax 
specifications--several of which are not representative of any 
implementation at all!

>   I'm also not sure about having a Designated Expert that to validate 
> every such registration.  That seems like it could be quite a lot to 
> ask of a volunteer.  Is that necessary?

I tried to constrain the work that the DE would have to do. It's 
definitely worth discussing.

>
> 13) Security Considerations refers to the "template questions in 
> Section 2", but Section 2 is an example section.  Are you using "xref" 
> tags, or setting section numbers manually?
nroff.

Incidentally: Markdown has setext and atx header syntaxes, but Gruber's 
Markdown syntax does not allow headers to be numbered. Numbered headers 
(which would be very useful for IETF documents, wink wink) are an 
extension in some Markdown variants. For example:

|pandoc --number-sections|

<http://stackoverflow.com/questions/19999696/are-numbered-headings-in-markdown-rdiscount-possible>

> 14) Also in Security Considerations, I suggest at least having a 
> summary of the Section 4 issues here, if not actually moving them here.
Ok. Noted.

> 15) RFC1738 is obsoleted by RFCs 4248 and 4266.

RFC 1738 is the latest reference for file:/// URLs.

>
> 16) Appendix A should include a notation like "[RFC Editor: Please 
> delete this section prior to publication.]"
Ok. Noted. Thanks!

-Sean

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Sep 2014 00:55:26 -0700

> RFC 1738 is the latest reference for file:/// URLs.

I think that the reference you are looking for is RFC 3986.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Sep 2014 00:57:27 -0700

On 24 September 2014 00:29, Sean Leonard <[email-masked]> wrote:
> parameter value can be any Unicode string. The purpose was to enable flavors
> (variants) to be named things in languages other than English. See BCP 18
> Section 2, "Where to do internationalization". Right now most examples of
> Markdown-related flavors are in English, but it is perfectly conceivable
> that someone can write some Markdown variant in some other script. Actually,
> Markdown itself is starting to be iconized as M↓ by the community.
>
> case-insensitivity and its interactions with Unicode. It's one thing to map
> the US-ASCII characters U+0041-U+005A (uppercase) to U+0061-U+007A; it's
> another thing to require huge tables of mappings for all sorts of scripts
> out there. See
> "Names are a problem, because people feel strongly about them, many of them
> are mostly for local usage, and all of them tend to leak out of the local
> context at times. RFC 1958 recommends US-ASCII for all globally visible
> names. This document does not mandate a policy on name internationalization,
> but requires that all protocols describe whether names are internationalized
> or US-ASCII."
>
> SHOULD use US-ASCII. And since I wanted to obviate the case-folding issue, I
> said case-sensitive.
>

It's not a name, it's a label.

---

From: Sean Leonard <[email-masked]>
Date: Wed, 24 Sep 2014 01:23:23 -0700

> It's not a name, it's a label. 

What's the difference? (Citation please?)

-Sean

---

From: Sean Leonard <[email-masked]>
Date: Wed, 24 Sep 2014 01:25:05 -0700

> I think that the reference you are looking for is RFC 3986.
Uh, are you sure?

RFC 3986 talks about file:/// URIs but does not define them.

The IANA registry for URI schemes plainly points to RFC 1738 for file: 
see <http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml>.

-Sean

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Sep 2014 02:25:26 -0700

> What's the difference? (Citation please?)

My point was that the intent of the parameter is protocol
identification.  There is no value in permitting expressiveness
through character choice.  That's an purely for humans; computers
don't need that.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 24 Sep 2014 18:48:41 +0900

> What's the difference? (Citation please?)

There are usually three levels of stuff in protocols (in the wider 
sense), content, identifiers (or names as Martin Thomson calls them) and 
labels (or whatever you call them).

It is usually clear to everybody that in content (e.g. the text in an 
email, HTML document, Markdown document, and so on), it must be possible 
to use not only ASCII, but (almost) the full range of Unicode characters.

It's widely recognized these days that for identifiers/names (e.g. file 
names, domain names, email addresses, Web addresses), it is highly 
preferable to be able to use not only ASCII, but (almost) the full range 
of Unicode characters. For some background, see e.g. 
http://tools.ietf.org/html/rfc3987#section-1.1, in particular the second 
sentence of the second paragraph.

It's also widely recognized that for labels (e.g. HTTP verbs, SMTP 
commands, HTML element and attribute names, media types,...), the cost 
of offering full Unicode support (as opposed to only allowing ASCII) is 
not justified.

One core distinction between identifiers and labels is their number. The 
number of identifiers is huge; the number of labels in each category is 
very limited.

We can go into more details in this discussion, but I agree with others 
that there is no need to allow Unicode for flavors, which then avoids 
the casing issues and allows to define it as case-insensitive.

As for citations, what about the first paragraph of Section 2 of BCP 18 
(http://tools.ietf.org/html/bcp18#section-2)?

    Internationalization is for humans. This means that protocols are not
    subject to internationalization; text strings are. Where protocol
    elements look like text tokens, such as in many IETF application
    layer protocols, protocols MUST specify which parts are protocol and
    which are text.

What Martin Thomson calls labels is what this calls "protocol elements".

Regards,   Martin.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 24 Sep 2014 12:47:37 +0200

Nit:

>    [XML1.0-3] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
>               F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third
>               Edition)", World Wide Web Consortium Recommendation REC-
>               xml-20040204, February 2004,
>               <http://www.w3.org/TR/2004/REC-xml-20040204#dt-fatal>.

This reference is outdated; the latest would be:

"[REC-xml-20081126]	Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, 
E., and F. Yergeau, “Extensible Markup Language (XML) 1.0 (Fifth 
Edition)”, W3C Recommendation REC-xml-20081126, November 2008, 
<http://www.w3.org/TR/2008/REC-xml-20081126/>.
Latest version available at <http://www.w3.org/TR/xml>."

---

From: Sean Leonard <[email-masked]>
Date: Wed, 24 Sep 2014 07:47:31 -0700

[Note: this message was prerecorded last night.]

> hardens this against command injection attacks.
Actually I think that without a well-structured processor parameter (or 
some equivalent), the security issues become much worse.

Consider that in the current world of things, if an author wants someone 
else to get the same output, the author is going to tell that person to 
execute:
“pandoc -s -f markdown_strict+pandoc_title_block+tex_math_dollars -t 
markdown_strict+mmd_title_block+tex_math_double_backslash”,
or say:
“here: just use this Makefile”.

That command line is real, by the way: 
<https://pairlist6.pair.net/pipermail/markdown-discuss/2014-July/003064.html>. 
I didn’t invent the media type parameters for the sake of complexity—I 
was just reflecting what the Markdown community has already made.

Someone elsewhere recently posted that what they really want is a 
shebang #! on the first line of the Markdown, indicating the 
command-line to execute. (Dennis E. Hamilton, see 
<https://pairlist6.pair.net/pipermail/markdown-discuss/2014-September/003223.html>.)

Talk about a security nightmare! For trained users who “know what they 
are doing”, it’s no big deal. But Markdown is being used by users who 
don’t know what they’re doing…and asking some user to “run this 
Makefile” is just about as good from a security standpoint as giving 
them a loaded gun and saying “point at foot”. Think of the damage 
someone can do by running an arbitrary batch script that they receive 
from some random person or Internet site--particularly if they are being 
spear-phished. I doubt that half of the folks on this list who use 
Makefiles from other people go through the trouble to comb through every 
line and look for hidden, malicious commands. (And even if you know what 
a Makefile is, how do you know what all of the arbitrary command 
programs are on your system, and how they might be invoked for 
unpleasant purposes?)

Maybe processor should go away…it’s a debate worth having (and is 
actively being had), specifically to see if other parameters (namely the 
flavor parameter or its successor) can satisfy the need. But I think 
that kicking the security can down to some other part of the system will 
make the security issues worse, rather than better.

The purposes of having a controlled vocabulary for the processor 
parameter are:

 1. to promote interoperability, so that both the sender and receiver
    are going to get the same behavior; and
 2. to provide security, by ensuring that arbitrary commands /can't/ be
    executed--the behaviors are circumscribed by the processor registry,
    and moreover, by the receiver's software making judgments about
    which processors are actually worth invoking.

It is probably a failure of draft-02 that unregistered processor 
identifiers are allowed. That, at least, should be reined in. Then 
asking if the only processors are registered ones, (and flavors are 
registered ones), can the flavors do the same work without putting 
unrealistic burdens on the Markdown community. ("Unrealistic" of course 
depends on one's perspective.)

When I looked at the ways this could go down, I specifically looked at 
the text/troff registration. In that registration, the problem is kicked 
down the road because the process parameter is "human readable". So 
basically the process parameter in text/troff amounts a glorified 
comment. First: I doubt that much software is actually generating or 
consuming these glorified comments (there is a Comment header anyway, 
RFC 5322 Section 3.6.5). Second: these glorified comments aren't usable 
by non-technical people, except as a loaded gun.

-Sean

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Sep 2014 10:27:56 -0700

> “here: just use this Makefile”.

I don't believe using a registry to constrain possible processors and all
of their various parameter combinations is practical.  At a minimum it puts
a burden on the Designated Expert to validate all of them, and on consumers
to ensure they always have the latest dump of the registry.  Among other
things, the registration can't accommodate substitution parameters; what
if, for example, the filename is supposed to be passed as a command line
parameter?  And what about ordering of the parameters?  You could say order
doesn't matter, but note that at least for "-f" and "-t" above, they have
to at least be paired with their corresponding values.  What about
arguments that can repeat?  All of that needs to appear in the registry if
you really intend it to reflect a comprehensive list of what's allowed.  I
don't think we should have registry rules that amount to the man page for
getopt().

What if there are two different processors that handle a particular
markdown flavor identically, the message demands use of one of them, and I
have the other one installed?

What about the case where a critical security flaw is identified in a
processor mandating release of a new version, or an entry is found to be
seriously incorrect?  Isn't there now a scramble to update the registry in
some way?  What if the DE isn't available for some period?

To me, the complexity this introduces far outweighs the defenses you're
trying to erect.

I envision something more like Apache's handler construct, where there's a
table mapping filename extensions to the module that knows how to parse
them.  These are not maintained in a registry, but are rather enumerated
locally and map to the handlers available.  For text/markdown, you would
have something like a table mapping flavors and maybe some options over to
the locally-available processor and whatever options you want to use for
that flavor.  There's some default you use for flavors you've never heard
of.  As you find out about new flavors and their processors, you install
the processors and add them to the table accordingly.

> Maybe processor should go away…it’s a debate worth having (and is actively
> being had), specifically to see if other parameters (namely the flavor
> parameter or its successor) can satisfy the need. But I think that kicking
> the security can down to some other part of the system will make the
> security issues worse, rather than better.
>

I don't believe the idea is to punt on security.  I do believe the idea is
to avoid unnecessary complexity, which by itself can introduce all kinds of
security and interoperability problems.

>
>    1.
>
> When I looked at the ways this could go down, I specifically looked at the
> text/troff registration. In that registration, the problem is kicked down
> the road because the process parameter is "human readable". So basically
> the process parameter in text/troff amounts a glorified comment. First: I
> doubt that much software is actually generating or consuming these
> glorified comments (there is a Comment header anyway, RFC 5322 Section
> 3.6.5). Second: these glorified comments aren't usable by non-technical
> people, except as a loaded gun.
>

I think text/troff (RFC4263 for those that want to look) skates through by
saying the processor and version parameters are advisory text and not to be
executed, because in fact they could be prose.  Here, you're saying they
are "the" commands that have to be used to render the intended content.
The text/troff approach seems a lot more palatable to me.

I'd be curious to hear about anyone that's implemented text/troff and
encountered this.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Sep 2014 10:50:56 -0700

> specification, I wanted to be clear with an example up-front. It can go

It just seems strange to say "Here's what I'm trying to build, now here are
all the pieces", versus "Here are the pieces, and here's how you would use
them."  The latter is much more common, except maybe on a box of Lego.  :-)

>
>
>  5) I'm not sure that I agree the charset should be mandatory.  It seems
> to go against what I'm reading in RFC2046 Section 4.1 to not have
> "us-ascii" as a default since this is a subtype of the "text" media type.
> Why should this be different from how other text/* types do it?
>
>

Ah right, I'd forgotten about that work.  Disregard.

>
>
>  6) The "flavor" tag itself seems to be a debatable point.  I don't have
> an opinion on that yet (more discussion, please), but as defined the name
> is case-sensitive.  Is that what we want?  And does it need to be able to
> flavors (variants) to be named things in languages other than English. See
> BCP 18 Section 2, "Where to do internationalization". Right now most
> script. Actually, Markdown itself is starting to be iconized as M↓ by the
> community.
>
> local context at times. RFC 1958 <http://tools.ietf.org/html/rfc1958>
> recommends US-ASCII for all globally visible names. This document does not
> mandate a policy on name internationalization, but requires that all
> protocols describe whether names are internationalized or US-ASCII."
>
> SHOULD use US-ASCII. And since I wanted to obviate the case-folding issue,
> I said case-sensitive.
>

OK, you said "internationalization" and that makes me cringe and back
away.  I'll yield to consensus here until I'm more of an expert on that
topic.

On the other hand, you say that the handling is case-sensitive yet you
direct the Designated Expert not to allow new names that differ from
registered names only by case.  I'm left wondering if the latter really
matters.

> As a bonus: John Gruber is extremely sensitive to capitalization of

I could be convinced that this is fine in prose, but when we get to talking
about tokenizing a string for processing by a program, I'm less sure it
should matter.

> eliminated) by registration. Will write in separate e-mail.

Replied separately as well.

> expectation is that the sending mail client will do the formatting, so in
> an e-mail, the received data will be text/html.
>

Email clients are not the only common consumers of media types.  What about
a web browser?  Here, too, the output format is implicit from the
environment.

> time. Maybe one collaborator is the author and the other is an editor or

Why does the media type need to indicate to both authors what the output
format is when they presumably already know that?  Or wouldn't it be
implicit in whatever editing environment they're using?  Is it safe to
assume they're always the same?

> The text does say "Generators MUST NOT emit empty flavor parameters"...but
> then it proceeds, "but parsers MUST treat empty flavor parameters the same
> as if omitted." The whole parameter is optional. The point is that there is
> a syntactic difference between:
>  text/markdown; flavor=""
> and
>  text/markdown
>

OK.  However, the ABNF doesn't allow empty values in the first place, so I
don't think this needs to be said at all.  An empty flavor value is already
a syntax error.

> Due to the proliferation of processors, there have been very many calls in
> the Markdown community to have "one true formalized syntax". So that means
> that now there is a proliferation of syntax specifications--several of
> which are not representative of any implementation at all!
>

This is covered separately as well.

> RFC 1738 is the latest reference for file:/// URLs.

Actually you're right, it's listed as authoritative for "file" in the IANA
URI scheme registry, even though it shows it's obsoleted.  That should
probably get fixed (but not by this document, obviously).

-MSK

---

From: t.petch <[email-masked]>
Date: Thu, 25 Sep 2014 09:54:31 +0100

----- Original Message -----
From: "Matthew Kerwin" <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Cc: "IETF Apps Discuss" <[email-masked]>
Sent: Wednesday, September 24, 2014 7:53 AM
On 24 September 2014 16:22, Murray S. Kucherawy <[email-masked]>

<tp>

Matthew

Well, you write an I-D!  But you know that because you have done that
plenty of times already.  I do notice that since the last post I saw
from you on this, in 2013, you have asked people to discuss this on
github.  Following the link in the I-D, I get 'The page cannot be
displayed' but really, that is irrelevant for me, since if I am going to
discuss it, I want it to be here on the apps list, not on yet another
list (the uri list would be an alternative).

I do use file:/// most days of the week in the flavour used by IE and
would be happy to work to see it standardised; which then requires a WG
to show sufficient interest, or an AD to feel motivated to take it on
(which you also know:-).

Tom Petch

1738 says it's obsoleted, even though the two RFCs that apparently
obsoleted it only obsoleted a small part, and the one that really
replaced
the bulk only "updated" it, and some RFCs that usurped its schemes
(looking
at you, RFC 2068/2616) didn't update it at all, and some parts are
probably
meant to still be current (the schemes referenced from the IANA
registry,
like "file").

---

From: Sean Leonard <[email-masked]>
Date: Mon, 29 Sep 2014 12:32:35 -0700

Colleagues:

Having taken everyone's feedback into consideration, it is clear that 
the consensus is trending away from the processor parameter in 
draft-ietf-appsawg-text-markdown. Sufficient technical arguments have 
been advanced; thus I am going to do an about-face on the matter. It 
will be removed from draft-03. Thanks.

I have tried to gather the most salient feedback on draft-02 thus far, 
which I have put in the IETF appsawg wiki:
http://trac.tools.ietf.org/wg/appsawg/trac/wiki/TextMarkdown/Feedback-draft-02

If you feel that your comments were not taken into consideration, by all 
means post them to the wiki.
The feedback page isn't a promise that any particular thing will or will 
not happen, but at least it's a public comment board so that when 
draft-03 appears in a few weeks, we can all see that key points were at 
least noted.

Best regards,

Sean