[apps-discuss] text/markdown: Simplifying the syntax parameter and the draft

Sean Leonard <dev+ietf@seantek.com> Fri, 07 November 2014 06:29 UTC

Return-Path: <dev+ietf@seantek.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5701ACEF5 for <apps-discuss@ietfa.amsl.com>; Thu, 6 Nov 2014 22:29:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFXad3LdQzUc for <apps-discuss@ietfa.amsl.com>; Thu, 6 Nov 2014 22:29:00 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02E4F1A1A52 for <apps-discuss@ietf.org>; Thu, 6 Nov 2014 22:28:59 -0800 (PST)
Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D335E509B5 for <apps-discuss@ietf.org>; Fri, 7 Nov 2014 01:28:58 -0500 (EST)
Message-ID: <545C6644.8070707@seantek.com>
Date: Thu, 06 Nov 2014 22:27:16 -0800
From: Sean Leonard <dev+ietf@seantek.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms030009050609050105030405"
Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/kaSgQOOolkXUdmYKeh78npLAlXQ
Subject: [apps-discuss] text/markdown: Simplifying the syntax parameter and the draft
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Nov 2014 06:29:01 -0000

I have worked with several parties privately to try to see how we can 
keep the text/markdown draft moving.

Looking at all the feedback, the public comments are clearly going in 
the direction of making the text/markdown registration simpler. (Yes, I 
got the memo…) Most of the complexity stems from unifying all 
Markdown-derivative syntaxes into one media type (text/markdown) with 
specific parameters.

PROPOSAL
Change the registration template in draft-03 as follows:
***
Optional Parameters:
variant: An optional identifier that serves as a “hint” to the recipient 
of the specific Markdown variant that the author intended. When omitted, 
there is no hint; the interpretation is entirely up to the receiver and 
context. This identifier is plain US-ASCII and case-insensitive. People 
who want interop can optionally register them using a simple webform 
(IANA registry), which just asks for the Identifier, a Description, and 
Contact Information. If a receiver does not recognize the variant 
identifier, the receiver MAY present the identifier to a user to inform 
him or her of it.
Other parameters MAY be included with the media type. The semantics of 
such parameters MAY be defined by the variant; they are not defined 
here. As an alternative, the variant MAY be registered under another 
media type; this text/markdown registration does not preclude other 
registrations.
***

With the text above in the registration template, pretty much all of 
Section 3 (draft-03) would be eliminated. Additionally, Section 6 (IANA 
Considerations) would be cut down to about 1/3 of its current size.

Definition:
"Variant" means a lightweight markup language that differs in some 
respect from other Markdown-derived languages. The purpose of a variant 
is to distinguish a given variation from other Markdown variations, as 
well as from Gruber's original syntax specification and implementation, 
where two parties wish to interoperate by implementing the common variation.

The IANA Registry shall be called "Markdown Variants". The intent of 
this name is to broaden the uses of variant identifiers, so protocols 
that do not rely on Internet media types can still tag Markdown content 
with a variant name. For example, a file can be named 
"file.pandoc.markdown", which could have the equivalent meaning as 
"Content-Type: text/markdown; variant=pandoc". (Credit goes to Michel 
Fortin for suggesting that the classification of variants have broader 
value than just the media type registration; for example, in content 
management systems that do not use media types to classify formats.)

-Sean