[apps-discuss] Objection to processing draft-ietf-appsawg-text-markdown-* documents as WG drafts (was: Re: Benoit Claise's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS and COMMENT))

[John C Klensin <[e-mail]>]

Hi.  

With "normal" IETF WGs, we assume a very high level of internal
WG review and resulting WG consensus (even if rough) before a
draft goes into IETF Last Call.  It is that assumption that
justifies a two-week Last Call and maybe being relaxed about
questions about whether or not a significant fraction of the
community actually cares, etc.   I don't have much experience
with other area WGs, but there seems to be a tacit assumption in
AppsAWG that, if a piece of work is worthwhile (in this case,
getting Markdown well documents in an obvious place and reviewed
through the IETF process) it is safe to assume that others who
_really_ care will do the heavy lifting or, indeed, all of the
lifting

At least in retrospect, that didn't happen with this pair of
documents.  The kinds of problematic text (and a few actual
errors) that are being found during and subsequent to IETF Last
Call suggests strongly that the WG process failed to do an
adequate review from several perspectives.  It occurs to me that
an IESG decision to initiate a Last Call is a decision that
should be subject to appeal.  I'm not going to do that in this
case because I'm satisfied that diligent efforts by the IESG are
turning up the issues that should have been caught and fixed
earlier.  However, I encourage the IESG (and document shepherds)
to very carefully review the criteria that are being used to
initiate IETF Last Calls on documents supposedly processed
through (and carefully reviewed by) Area or other broad-focus
WGs.  

This might even be worth some discussion during the AppsAWG
meeting on 20 July.

More specifically, the issues raised by Beniot and Sean's
response forced me into a quick read-through of these two
documents for issues I care about and with which I'm familiar
(e.g., Media Type definitions and character set and i18n issues
and terminology).  That reading strongly suggests that either no
effective review occurred in AppsAWG or that it was inadequate
enough to suggest that assigning these documents to that WG was
inappropriate.   I am not only concerned about the examples
above and below; I am concerned that, if these issues have
fallen through the cracks, there may be others in the two
documents.

For example, the first paragraph of Section 1.1 of
draft-ietf-appsawg-text-markdown includes "a linear sequence of
characters in some character set (code)".  That just isn't
acceptable terminology.  Not only does it not conform to the
recommendations of RFC 6365, but, in a slightly different
environment, it would probably be read as meaning something
entirely different from what was probably intended.  That
paragraph goes on to say "Because they are non-printing, these
characters" (referring to "line breaks, page breaks, or other
control characters) "are also hard to enter with standard
keyboards."   At least for European writing systems, that is
plain silly unless one has a keyboard that lacks an "Enter" or
"Return" function or is using a _very_ strange input method
editor (IME).   The next paragraph goes on to make a suggestion
about "overload certain characters with additional meanings". At
least for SGML (and its descendents), that is not the way what
happens is described.  I'd suggest it is even less true of
LaTex, but YMMD.  What might be intended is something like
"certain characters or character sequences are treated as
reserved delimiters, with the strings they delimit acting as
processing, identification, or formatting directions".


Continuing with this theme, the "charset" portion of Section 2
of draft-ietf-appsawg-text-markdown-06 says:

	"...will get along just fine by operating on character
	codes that lie in printable US-ASCII, blissfully
	oblivious to coded values outside of that range."

I don't know what that means in spite of being regularly
mistaken for an expert in the area.  Given that you want to be
CCS-independent (see RFC6365), I think the first part probably
refers to "graphic characters in the ASCII repertoire", but I
don't know what "blissfully oblivious..." is trying to tell me.
Is it that each Markdown processor has, or assumes, a CCS and
encoding and, if anything is encountered outside that range or
is a non-graphic character in that range, it will be ignored?
Noting that set of exclusions would ignore the character known
as SP, I suggest that any such Markdown processor would be
seriously broken.  It is more likely that the sentence is wrong.

In addition, the handwaving in the first paragraph of Security
Considerations in Section 2 of
draft-ietf-appsawg-text-markdown-06 is sufficient that an
"Internationalization Considerations" section should be required
in this document (see RFC 2277).

As a final example, Content Disposition headers are orthogonal
to Media Type.  If draft-ietf-appsawg-text-markdown is about
registration of a media  type, as the title very strongly
suggests and the abstract says explicitly, then Section 4 has no
place in it.  If it is intended as a general discussion of
Markdown as it might be transmitted through systems that might
use Content-Disposition headers, then the title and abstract
need fixing and some language should be added to the
Introduction that explains the scope of the document before it
starts explaining the use and history of Markup/Down.  It would
be appropriate --and normal practice in the IETF and
editorially-- for that actual introduction to also discuss the
relationship between this document and
draft-ietf-appsawg-text-markdown-use-cases.


The comments below are about one specific set of examples of the
above that follow up an exchange that has already occurred.
These problems can be fixed, but they need, IMO, to be
understood and taken seriously, not just responded to with a
reference to something that might be relevant.  I also suggest
that this example demonstrates that the separation into two
documents either was not wise or was not executed carefully
enough.

--On Saturday, July 11, 2015 14:09 -0700 Sean Leonard
<[e-mail]> wrote:

> On Jul 10, 2015, at 9:18 PM, John C Klensin
> <[e-mail]> wrote:
>...
>> If you have a character set problem, or, as usually turns out
>> to be the case when people start talking about "character set
>> interoperability", an i18n problem, you really need to say
>> something specific (and probably provide references), not say
>> something that sounds like "it is a problem that others have
>> spent time on and therefore we can ignore".
> 
> Okay, okay…
>...
> Therefore, proposed changes are:
> {{
> There are communities that are using Markdown for
> scholarly writing [OCCASION], for screenplays [FOUNTAIN], and
> even for mathematical formulae [MATHDOWN].

Not in my area of competence (at least without careful study),
but I assume ok.
>...
> {{
> [RFC6657] provides guidance on character set parameter
> handling. }}

This is more handwaving and is not helpful.  I strongly suspect
it doesn't belong here because it is either unnecssary or
represents information without which
draft-ietf-appsawg-text-markdown (aka [MDMTREG]) is not complete
enough to conform to the letter and spirit of RFC 6838 (BCP 13).
The information in draft-ietf-appsawg-text-markdown is, IMO,
written in a confusing way and needs a detail or two, but it
appears to be to be present.

So, asking everyone's indulgence for commenting on both of these
intertwined documents in the same note, a constructive
suggestion in the spirit of "send text":

(1) Drop the above sentence (and the reference) from
draft-ietf-appsawg-text-markdown-use-cases.  If you must say
something in the "use cases" document, point back to MDMTREG and
indicate that issues associated with charset parameters are
discussed there.   And say "charset" (in quotes if you think
that is needed) and not "character set" because they do not mean
the same thing and you are talking about the former (see
elsewhere in this note).

(2) In Section 2 of draft-ietf-appsawg-text-markdown, paragraph
about "charset", add, probably after "no default value",
"consistent with the requirements of RFC 6657 [RFC6657]".  That
should put the issue to rest.

best,
    john