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

["Murray S. Kucherawy" <[e-mail]>]

On Wed, Sep 24, 2014 at 12:29 AM, Sean Leonard <[e-mail]> wrote:

>
>
>  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.
>

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?
>
>
> See RFC 6657 (whole thing) and RFC 6838 Section 4.2.1.
>

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
> 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>
> <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.
>

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
> "Markdown".
>

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.


>
>  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.
>
>
> I think the security risk is significantly mitigated (perhaps even
> eliminated) by registration. Will write in separate e-mail.
>

Replied separately as well.


>
>
>  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?
>
>
> 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.
>

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.


> 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.
>

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?


>
>  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.
>

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.


>
>
>  12) The requirement to register tools that implement given flavors is
> 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!
>

This is covered separately as well.

>
>  15) RFC1738 is obsoleted by RFCs 4248 and 4266.
>
>
> 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