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

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

On Mon, Sep 22, 2014 at 3:42 PM, <[e-mail]> wrote:

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

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