Re: [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))

[Martin J. Dürst <[e-mail]>]

On 2015/07/13 08:20, John C Klensin wrote:

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

Agreed. "Character set" as used in RFC 2046 is not a term we want to use 
in 2015.


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

For line breaks, I'd argue that they are very easy to enter on pretty 
much any keyboard, because pretty much any keyboard has an Enter key 
(and because pretty much every modern language has line- or paragraph 
breaks).

For page breaks and other control characters, I'd argue that they are 
difficult to enter with the average keyboard, in any language.

So just remove "line breaks", and the problem should be fixed.


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

I'd agree that this isn't how SGML or LaTeX would describe it, but it's 
not actually in any way wrong. In XML, depending on context, '>' means 
itself or "close tag" (or any of a few more obscure meanings). We are 
still in the introduction, after all.


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

I know what the sentence tries to refer to. It refers to the fact that, 
as long as the syntax you are looking at only uses 7-bit bytes values 
with ASCII semantics (including the usual control characters and space), 
a processor will work for a wide range of character encodings.

The problem is that this applies to some encodings, but not to others. 
The criterion is a certain kind of strong ASCII-compatibility, namely 
that characters in the ASCII range (including C0) are always represented 
directly as 7-bit bytes, and that these 7-bit bytes always represent the 
corresponding characters and nothing else.

Encodings that qualify are of course US-ASCII itself, straightforward 
8-bit encodings starting with iso-8859-1 and including vendor encodings 
(Windows, Mac,...), some multibyte encodings such as GB2312 and EUC-JP, 
and UTF-8 (but beware of the BOM). However, it does not include some 
other encodings, in particular not iso-2022-jp, Shift_JIS, GBK, or 
GB18030, and of course not UTF-(16|32)(LE|BE).

So the text should definitely be more careful here.


Regards,   Martin.