[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
- [apps-discuss] text/markdown: Simplifying the syn… Sean Leonard