From nobody Tue Apr 14 12:26:32 2015 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D941AD068 for ; Tue, 14 Apr 2015 12:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.367 X-Spam-Level: * X-Spam-Status: No, score=1.367 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 sHHCgiXaf0-0 for ; Tue, 14 Apr 2015 12:26:29 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [IPv6:2620:0:2d0:201::1:71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A41F1B2EB0 for ; Tue, 14 Apr 2015 12:26:02 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t3EJPf6G009123 for ; Tue, 14 Apr 2015 19:26:01 GMT Received: by widdi4 with SMTP id di4so126647631wid.0 for ; Tue, 14 Apr 2015 12:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=GSYXw8sCd7ipxy9oEojOgI/q6nJnEMcoH6UyQyhvDag=; b=LkYjh03to11JvoyZ4x9rvGp5BPV+SUNWR4Vg+yOuJOvZ2VgblTtw3fk2cP2T6yShx0 opuxS+gn9HeFGUNTHcRa6azIhrvIVgpaN820NxmBSV+ZZP7eH5cgJIEl+/+q+ILHagQm 0YlGgHyYYELNktfLg6Jb6dzK0CN6cmSEOQH9YcsC1uLNN29MPnWsm4C8TP/RpzH65cRk b9PjaYDT8+aLXcXmUDnbZHK2ekeLUvQTIDlXMnU47VLiw8/AefYkzQQGKmS0vuBtVfrY osaHJtIDwKciFsXDNfioL5lwO0lJb+qfiL/ylror1+Em2UGx8vTSSpCdiyaXoD9uzyjl TvBA== MIME-Version: 1.0 X-Received: by 10.194.179.194 with SMTP id di2mr41837560wjc.4.1429039541061; Tue, 14 Apr 2015 12:25:41 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Tue, 14 Apr 2015 12:25:41 -0700 (PDT) Date: Tue, 14 Apr 2015 12:25:41 -0700 Message-ID: From: "Murray S. Kucherawy" To: "media-types@iana.org" Content-Type: multipart/alternative; boundary=089e01419d1c370fb80513b43259 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [IPv6:2620:0:2d0:201::1:71]); Tue, 14 Apr 2015 19:26:01 +0000 (UTC) Archived-At: Subject: [media-types] Early review request: draft-ietf-appsawg-text-markdown X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 19:26:30 -0000 --089e01419d1c370fb80513b43259 Content-Type: text/plain; charset=UTF-8 Hi there, Could we get an early review of this document? It contains a media type registration. The document is approaching Working Group Last Call in APPSAWG and I wanted to see if there's anything he should fix before the formal request comes through. https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ It's a good opportunity for me to train on filtering new requests too. Thanks, -MSK --089e01419d1c370fb80513b43259 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi there,

Could we get an earl= y review of this document?=C2=A0 It contains a media type registration.=C2= =A0 The document is approaching Working Group Last Call in APPSAWG and I wa= nted to see if there's anything he should fix before the formal request= comes through.

https://datatracker.ietf.org/doc/draft-ietf-apps= awg-text-markdown/

It's a good opportunity for me= to train on filtering new requests too.

Thanks,
-MSK=
--089e01419d1c370fb80513b43259-- From nobody Tue Apr 14 13:14:39 2015 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD0A1AD0AB for ; Tue, 14 Apr 2015 13:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 m1vOfYisUSgw for ; Tue, 14 Apr 2015 13:14:37 -0700 (PDT) Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DF601AD0A6 for ; Tue, 14 Apr 2015 13:14:36 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id t3EKEF56020718 for ; Tue, 14 Apr 2015 20:14:35 GMT Received: from cim06-h01-31-32-14-119.dsl.sta.abo.bbox.fr ([31.32.14.119] helo=M6700) by raoul.w3.org with esmtpsa (TLS1.1:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Yi7Dp-000F6F-DT; Tue, 14 Apr 2015 20:14:13 +0000 Date: Tue, 14 Apr 2015 22:14:11 +0200 From: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <1519282150.20150414221411@w3.org> To: "Murray S. Kucherawy" , "media-types@iana.org" In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora7.dc.icann.org [IPv6:2620:0:2830:201::1:73]); Tue, 14 Apr 2015 20:14:35 +0000 (UTC) Archived-At: Subject: Re: [media-types] Early review request: draft-ietf-appsawg-text-markdown X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 20:14:39 -0000 Hello Murray, Tuesday, April 14, 2015, 9:25:41 PM, you wrote: > Hi there, > Could we get an early review of this document?=C2=A0 It contains a media > type registration.=C2=A0 The document is approaching Working Group Last > Call in APPSAWG and I wanted to see if there's anything he should > fix before the formal request comes through. > https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ Putting Markdown in the text tree seems reasonable; it is probably more easily readable in source form than text/html. "Many Markdown processors 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." That seems to imply that encodings where US-ASCII does not encode as itself (such as UTF-16) should be avoided. "Encoding considerations: Text." That doesn't really say anything. " Fragment identifier considerations: See Section 4." Fragment Identifiers is actually section 3. --=20 Best regards, Chris Lilley Technical Director, W3C Interaction Domain From nobody Wed Apr 15 12:20:52 2015 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC2A1A88D5 for ; Wed, 15 Apr 2015 12:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 1ER6XtOMeHBu for ; Wed, 15 Apr 2015 12:20:49 -0700 (PDT) Received: from pechora8.dc.icann.org (pechora8.icann.org [IPv6:2620:0:2830:201::1:74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 282151A88C7 for ; Wed, 15 Apr 2015 12:20:49 -0700 (PDT) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id t3FJKSIN025064 for ; Wed, 15 Apr 2015 19:20:48 GMT Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id A3F172FD7A9 for ; Wed, 15 Apr 2015 15:05:31 -0400 (EDT) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BBA1E22E1F4; Wed, 15 Apr 2015 15:04:49 -0400 (EDT) Message-ID: <552EB64C.7080807@seantek.com> Date: Wed, 15 Apr 2015 12:04:44 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Chris Lilley , "Murray S. Kucherawy" , "media-types@iana.org" References: <1519282150.20150414221411@w3.org> In-Reply-To: <1519282150.20150414221411@w3.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000400080709010407050206" X-Greylist: Delayed for 00:14:56 by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Wed, 15 Apr 2015 19:20:48 +0000 (UTC) Archived-At: Subject: Re: [media-types] Early review request: draft-ietf-appsawg-text-markdown X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 19:20:51 -0000 This is a cryptographically signed message in MIME format. --------------ms000400080709010407050206 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Thanks for the feedback! My responses are below. On 4/14/2015 1:14 PM, Chris Lilley wrote: > Hello Murray, > > Tuesday, April 14, 2015, 9:25:41 PM, you wrote: > >> Hi there, >> Could we get an early review of this document? It contains a media >> type registration. The document is approaching Working Group Last >> Call in APPSAWG and I wanted to see if there's anything he should >> fix before the formal request comes through. >> https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ > Putting Markdown in the text tree seems reasonable; it is probably > more easily readable in source form than text/html. > > "Many Markdown processors 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." > > That seems to imply that encodings where US-ASCII does not encode as > itself (such as UTF-16) should be avoided. Not exactly. Many programming ecosystems have a text-oriented stream or processing=20 pipeline that abstracts the (usually octet based input) into a sequence=20 of non-negative integers. I am referring in vague terms to C/C++=20 stdlibs, PHP, Perl, POSIX, Python, etc. Someone can write a Markdown processor using these programming=20 libraries, in such a way that the code operates on the abstract=20 non-negative integers, and sequences out another set of abstract=20 non-negative integers, which get converted into octets in accordance=20 with the codepage or other settings in the environment or programming=20 library. (This is in fact how several Markdown processors are written,=20 such as Markdown.pl.) Therefore if the programming library recognizes UTF-16 input (with or=20 without BOM, and with or without external metadata) and turns them into=20 abstract non-negative integers for the program to consume, there is no=20 reason to avoid (or promote) UTF-16 encoding over other forms. The=20 program itself just looks for things like "<" which maps to the=20 non-negative integer 0x3C (decimal 60). It is of course possible that=20 EBCDIC is used, but I am not aware of popular Markdown processors that=20 work specifically on EBCDIC values at the application level (obviously,=20 such an application can consume and produce EBCDIC content if the=20 programming library does the mapping from and to underneath), hence why=20 the text says "will get along just fine by operating on character codes=20 that lie in printable US-ASCII". > > "Encoding considerations: Text." > > That doesn't really say anything. Well it is supposed to imply all of the stuff above. Nevertheless I did a search and lo-and-behold, I haven't found other=20 registrations that say "Text" for this section. So, how about: ***** Encoding considerations: Markdown content is plain text content; any octet sequence is valid as=20 long as it conforms to the character codes of the charset parameter. See = [RFC2046]. Markup characters in Original Markdown [MDSYNTAX] are limited = to printable US-ASCII; however other variants can define markup=20 characters outside this range (including control characters such as NUL=20 and characters encoded in multiple bytes). ***** > > " Fragment identifier considerations: > > See Section 4." > > Fragment Identifiers is actually section 3. Thanks. I will change that reference to Section 3 in the next draft. Looking at the text, it appears that the Original variant is not=20 actually registered, even though it is used in the example. I will draft = a registration in the text-markdown-07 document. Sean --------------ms000400080709010407050206 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCC BK8wggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNV BAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJu YWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcN MTQxMjIyMDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAibEN2npTGU5wUh28VqYGJre4SeCW51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2 IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JDFnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9 KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUIkzqcKlOjENs9IGE8VQOO2U52JQIhKfqj fHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7AzaS1D6/rWpfGXd2dRjNnuJ+u8pQc4 doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZAP8vk4p+iIQIDAQABo4IBFzCC ARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYDVR0OBBYEFJJha4LhoqCq T+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0w OzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJv b3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRy dXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOc Uvi7BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc0 6HvgARClnMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLK hjQHuSzK5hxK2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6 H3kU9koQGib6fIr7mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcN AQELBQAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAyMDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRl ditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n2 0qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKPvku7E+utnLhcaNahAWr2oZgeCK9uhEqi jaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cUvZqY7YwzCG6jSfs4gwNh+29MS6fa Y6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/MwNAabNhDgxU2Tw1fl5w1Vt+6x RTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/syYhS1Ko4MSiJmR3ugKPk xEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQABo4IB8jCCAe4wHwYD VR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y8PBT6NqnIVbf NK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEE AbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2 Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEE gYMwgYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1 NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGG GGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVr LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC 8IXwUmNxL7L5uE3tGlNJVoTKZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63r MlFPFrjqQCEA6rDgo9DlFO9/81P7ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3 gUs5xJT0koGVvli2wR18zecG3ib3ml+GnDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamq r3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEpqpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMC tqlHvF3YY2z55jGCBDEwggQtAgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9u IGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecwCQYFKw4DAhoFAKCCAlUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwNDE1MTkwNDQ0 WjAjBgkqhkiG9w0BCQQxFgQUVq6TgR8BGks0y1lvogLc1RltkykwbAYJKoZIhvcNAQkPMV8w XTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBwQYJKwYBBAGCNxAE MYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4 Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBpCSs8n+cQbczyWKtueyecwgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtue yecwDQYJKoZIhvcNAQEBBQAEggEAySjw6p/ecVnAk8OMlyqzpFyAYAFjRzvscILuhopDXzxR IuXkZd+9FC+lcCvhnFViwGyLnVjA+2jyHYFu5ieAYg9uJf0F08NgH4iHR/FqtJ1CVKo2RMDC cDwmFh4J+Zt/kYC7eqcUIMs1q4v1ldkBYdnctlAckGe4FHbLZzgJJFn4CG1gZ6D7NiomdBmz lWI1a+avhBIeFOfpuTA1jiEvFnucCNadjHtOFM4dlbocNYwxuImH1TIgJYv0b61H/GuwLSZP R/WR+a8Us8KuFfcAdbcIwNDbLybkszY6yiml4776wz6JMEmy7gdOD7K/CU89oYD6e9+WSy1I euI1OXQ+2wAAAAAAAA== --------------ms000400080709010407050206-- From nobody Wed Apr 15 22:39:23 2015 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5652B1A1ACA for ; Wed, 15 Apr 2015 22:39:23 -0700 (PDT) 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 24IDSs7Cw0sP for ; Wed, 15 Apr 2015 22:39:21 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5274D1A1A70 for ; Wed, 15 Apr 2015 22:39:21 -0700 (PDT) Received: from [192.168.123.110] (unknown [23.241.1.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8F74922E265; Thu, 16 Apr 2015 01:39:17 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <552EB64C.7080807@seantek.com> Date: Wed, 15 Apr 2015 22:39:15 -0700 Content-Transfer-Encoding: 7bit Message-Id: <38888327-8B9A-4034-911D-9AD5C8F0C419@seantek.com> References: <1519282150.20150414221411@w3.org> <552EB64C.7080807@seantek.com> To: media-types@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Murray Kucherawy Subject: Re: [media-types] Early review request: draft-ietf-appsawg-text-markdown X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 05:39:23 -0000 On 4/15/2015 12:04 PM, Sean Leonard wrote: > [THINGS] draft-07 has been posted. http://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-07 The registration template follows below. ************** This section provides the media type registration application for the text/markdown media type (see [RFC6838], Section 5.6). Type name: text Subtype name: markdown Required parameters: charset: Per Section 4.2.1 of [RFC6838], charset is REQUIRED. There is no default value. [MDSYNTAX] clearly describes Markdown as a writing format; its syntax rules operate on characters (specifically, on punctuation) rather than code points. Neither [MDSYNTAX] nor many popular implementations at the time of this registration actually require or assume any particular character set. Many Markdown processors 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. 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. To promote interoperability, identifiers MAY be registered in the registry defined in Section 6. 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 variant SHOULD define the semantics of such parameters. Additionally, the variant MAY be registered under another media type; this text/markdown registration does not preclude other registrations. Encoding considerations: Markdown content is plain text content; any octet sequence is valid as long as it conforms to the character codes of the charset parameter. See [RFC2046]. Markup characters in [MDSYNTAX] are limited to printable US-ASCII; however, other variants can define markup characters outside this range (including control characters such as NUL and characters encoded in multiple bytes). Security considerations: Markdown interpreted as plain text is relatively harmless. A text editor need only display the text. The editor SHOULD take care to handle control characters appropriately, and to limit the effect of the Markdown to the text editing area itself; malicious Unicode- based Markdown could, for example, surreptitiously change the directionality of the text. An editor for normal text would already take these control characters into consideration, however. Markdown interpreted as a precursor to other formats, such as HTML, carries all of the security considerations as the target formats. For example, HTML can contain instructions to execute scripts, redirect the user to other webpages, download remote content, and upload personally identifiable information. Markdown also can contain islands of formal markup, such as HTML. These islands of formal markup may be passed as-is, transformed, or ignored (perhaps because the islands are conditional or incompatible) when the Markdown is processed. Since Markdown may have different interpretations depending on the tool and the environment, a better approach is to analyze (and sanitize or block) the output markup, rather than attempting to analyze the Markdown. Interoperability considerations: Markdown variations (some might say "innovations") are designed to be broadly compatible with humans ("humane"), but not necessarily with each other. Therefore, syntax in one Markdown derivative may be ignored or treated differently in another derivative. The overall effect is a general degradation of the output, proportional to the quantity of variant-specific Markdown used in the text. When it is desirable to reflect the author's intent in the output, stick with the variant identified in the variant parameter. Published specification: This specification; [MDSYNTAX]. Applications that use this media type: Markdown conversion tools, Markdown WYSIWYG editors, and plain text editors and viewers; markup processor targets indirectly use Markdown (e.g., web browsers for Markdown converted to HTML). Fragment identifier considerations: See Section 3. Additional information: Magic number(s): None File extension(s): .md, .markdown Macintosh file type code(s): TEXT. A uniform type identifier (UTI) of "net.daringfireball.markdown", which conforms to "public.plain- text", is RECOMMENDED [MDUTI]. See [MDMTUSES] for other considerations. Person & email address to contact for further information: Sean Leonard Restrictions on usage: None. Author/Change controller: Sean Leonard Intended usage: COMMON Provisional registration? No Implementations SHOULD record the value of the variant parameter (and other parameters if defined by the variant) along with the Markdown content when the content leaves the domain of Internet media type- capable formats. Strategies for doing so are discussed in [MDMTUSES]. The Content-Disposition header (particulalry the preview-type parameter) can be used with Markdown content. See Section 4. *END* From nobody Fri Apr 17 09:59:44 2015 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977121A882C for ; Fri, 17 Apr 2015 09:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 RlAdTrJa4x0N for ; Fri, 17 Apr 2015 09:59:41 -0700 (PDT) Received: from relay11.mail.ox.ac.uk (relay11.mail.ox.ac.uk [129.67.1.162]) by ietfa.amsl.com (Postfix) with ESMTP id 793E81A8847 for ; Fri, 17 Apr 2015 09:59:40 -0700 (PDT) Received: from smtp5.mail.ox.ac.uk ([163.1.2.207]) by relay11.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Yj9cA-0001eK-bb; Fri, 17 Apr 2015 17:59:38 +0100 Received: from 94.197.120.7.threembb.co.uk ([94.197.120.7] helo=[192.168.43.120]) by smtp5.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Yj9c9-00032l-JG; Fri, 17 Apr 2015 17:59:38 +0100 Message-ID: <55313BED.1090808@ninebynine.org> Date: Fri, 17 Apr 2015 17:59:25 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sean Leonard , media-types@ietf.org References: <1519282150.20150414221411@w3.org> <552EB64C.7080807@seantek.com> <38888327-8B9A-4034-911D-9AD5C8F0C419@seantek.com> In-Reply-To: <38888327-8B9A-4034-911D-9AD5C8F0C419@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: Murray Kucherawy Subject: Re: [media-types] Early review request: draft-ietf-appsawg-text-markdown X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 16:59:43 -0000 I think the template is generally OK, but I spot a couple of nits: [[ Interoperability considerations: Markdown variations (some might say "innovations") are designed to be broadly compatible with humans ("humane"), but not necessarily with each other. Therefore, syntax in one Markdown derivative may be ignored or treated differently in another derivative. The overall effect is a general degradation of the output, proportional to the quantity of variant-specific Markdown used in the text. When it is desirable to reflect the author's intent in the output, stick with the variant identified in the variant parameter. ]] The last sentence here caused me some confusion. I think you're trying to say something like: "When it is important to reflect the author's intent in the output, processors should only accept markdown variants that they explicitly know about, and Markdown generators should avoid use of variants that are now known to be understood by the intended recipient." In the penultimate sentence, the description "proportional to ..." seems a spurious description. Maybe "which increases with ..."? ... [[ The Content-Disposition header (particulalry the preview-type parameter) can be used with Markdown content. See Section 4. ]] Typo: "particulalry" #g -- On 16/04/2015 06:39, Sean Leonard wrote: > On 4/15/2015 12:04 PM, Sean Leonard wrote: >> [THINGS] > > draft-07 has been posted. > > http://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-07 > > The registration template follows below. > > ************** > > This section provides the media type registration application for the > text/markdown media type (see [RFC6838], Section 5.6). > > Type name: text > > Subtype name: markdown > > Required parameters: > > charset: Per Section 4.2.1 of [RFC6838], charset is REQUIRED. There > is no default value. [MDSYNTAX] clearly describes Markdown as a > writing format; its syntax rules operate on characters > (specifically, on punctuation) rather than code points. Neither > [MDSYNTAX] nor many popular implementations at the time of this > registration actually require or assume any particular character > set. Many Markdown processors 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. > > 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. To promote interoperability, > identifiers MAY be registered in the registry defined in Section > 6. 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 variant > SHOULD define the semantics of such parameters. Additionally, the > variant MAY be registered under another media type; this > text/markdown registration does not preclude other registrations. > > Encoding considerations: > > Markdown content is plain text content; any octet sequence is valid > as long as it conforms to the character codes of the charset > parameter. See [RFC2046]. Markup characters in [MDSYNTAX] are > limited to printable US-ASCII; however, other variants can define > markup characters outside this range (including control characters > such as NUL and characters encoded in multiple bytes). > > Security considerations: > > Markdown interpreted as plain text is relatively harmless. A text > editor need only display the text. The editor SHOULD take care to > handle control characters appropriately, and to limit the effect of > the Markdown to the text editing area itself; malicious Unicode- > based Markdown could, for example, surreptitiously change the > directionality of the text. An editor for normal text would already > take these control characters into consideration, however. > > Markdown interpreted as a precursor to other formats, such as HTML, > carries all of the security considerations as the target formats. > For example, HTML can contain instructions to execute scripts, > redirect the user to other webpages, download remote content, and > upload personally identifiable information. Markdown also can > contain islands of formal markup, such as HTML. These islands of > formal markup may be passed as-is, transformed, or ignored (perhaps > because the islands are conditional or incompatible) when the > Markdown is processed. Since Markdown may have different > interpretations depending on the tool and the environment, a better > approach is to analyze (and sanitize or block) the output markup, > rather than attempting to analyze the Markdown. > > Interoperability considerations: > > Markdown variations (some might say "innovations") are designed to > be broadly compatible with humans ("humane"), but not necessarily > with each other. Therefore, syntax in one Markdown derivative may > be ignored or treated differently in another derivative. The > overall effect is a general degradation of the output, proportional > to the quantity of variant-specific Markdown used in the text. When > it is desirable to reflect the author's intent in the output, stick > with the variant identified in the variant parameter. > > Published specification: This specification; [MDSYNTAX]. > > Applications that use this media type: > > Markdown conversion tools, Markdown WYSIWYG editors, and plain text > editors and viewers; markup processor targets indirectly use > Markdown (e.g., web browsers for Markdown converted to HTML). > > Fragment identifier considerations: > > See Section 3. > > Additional information: > > Magic number(s): None > File extension(s): .md, .markdown > Macintosh file type code(s): > TEXT. A uniform type identifier (UTI) of > "net.daringfireball.markdown", which conforms to "public.plain- > text", is RECOMMENDED [MDUTI]. See [MDMTUSES] for other > considerations. > > Person & email address to contact for further information: > > Sean Leonard > > > Restrictions on usage: None. > > Author/Change controller: Sean Leonard > > > Intended usage: COMMON > > Provisional registration? No > > Implementations SHOULD record the value of the variant parameter (and > other parameters if defined by the variant) along with the Markdown > content when the content leaves the domain of Internet media type- > capable formats. Strategies for doing so are discussed in [MDMTUSES]. > > The Content-Disposition header (particulalry the preview-type > parameter) can be used with Markdown content. See Section 4. > > > *END* > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types > From nobody Fri Apr 17 19:17:49 2015 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812B81A1BAC for ; Fri, 17 Apr 2015 19:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 YTRjHjNh7hjm for ; Fri, 17 Apr 2015 19:17:46 -0700 (PDT) Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A1EB1A1B8B for ; Fri, 17 Apr 2015 19:17:45 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id t3I2HO3A007710 for ; Sat, 18 Apr 2015 02:17:44 GMT Received: by lbcga7 with SMTP id ga7so95720808lbc.1 for ; Fri, 17 Apr 2015 19:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=FCKHCChRDAF8eaFek0PFJ29xdFMIdIWOzBtcDEAG1eQ=; b=tId3b4KTHfnotQIyXw1qqfeZabUDAy2TdwCBODBt4TAd2Z5cI/02DZOv/sB8weFMeo 8pCNDIIpcXVwcz8lX9WOBfYBvhfVgir/h9JpokG4eMz3bgCASXkH1tA7fn70AZmhmNIC maEX0U2+CF6ejRPm8yD4wX6E9xR3gmIW/rWdgpf1o0foeAt+rhBXMZNLRuMX21cpbpYD KETEJSPacEC8+hFr8o0RggzgOiP+3of1K+1+UZLEeqVmRZBpYZPizdjTZPu0gG8c4LZj 6nMqt0vEPTS4cj//d1iaqxsctVHCDNU4SGmH3Z4LOCSMP8YoS5XFiDf36K3YrqQeT2Rk lE7Q== MIME-Version: 1.0 X-Received: by 10.152.19.132 with SMTP id f4mr6644738lae.115.1429323443736; Fri, 17 Apr 2015 19:17:23 -0700 (PDT) Sender: ericw3c@gmail.com Received: by 10.152.131.202 with HTTP; Fri, 17 Apr 2015 19:17:23 -0700 (PDT) Received: by 10.152.131.202 with HTTP; Fri, 17 Apr 2015 19:17:23 -0700 (PDT) In-Reply-To: <552EB64C.7080807@seantek.com> References: <1519282150.20150414221411@w3.org> <552EB64C.7080807@seantek.com> Date: Fri, 17 Apr 2015 22:17:23 -0400 X-Google-Sender-Auth: B8Z-FH6-aja9HaHJE6c1lIpQjqI Message-ID: From: "Eric Prud'hommeaux" To: Sean Leonard Content-Type: multipart/alternative; boundary=089e0149418022147f0513f64c34 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora7.dc.icann.org [IPv6:2620:0:2830:201::1:73]); Sat, 18 Apr 2015 02:17:45 +0000 (UTC) Archived-At: Cc: Chris Lilley , "Murray S. Kucherawy" , "media-types@iana.org" Subject: Re: [media-types] Early review request: draft-ietf-appsawg-text-markdown X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2015 02:17:48 -0000 --089e0149418022147f0513f64c34 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Apr 15, 2015 9:21 PM, "Sean Leonard" wrote: > > Thanks for the feedback! My responses are below. > > > On 4/14/2015 1:14 PM, Chris Lilley wrote: >> >> Hello Murray, >> >> Tuesday, April 14, 2015, 9:25:41 PM, you wrote: >> >>> Hi there, >>> Could we get an early review of this document? It contains a media >>> type registration. The document is approaching Working Group Last >>> Call in APPSAWG and I wanted to see if there's anything he should >>> fix before the formal request comes through. >>> https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ >> >> Putting Markdown in the text tree seems reasonable; it is probably >> more easily readable in source form than text/html. >> >> "Many Markdown processors 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." >> >> That seems to imply that encodings where US-ASCII does not encode as >> itself (such as UTF-16) should be avoided. > > > Not exactly. > > Many programming ecosystems have a text-oriented stream or processing pipeline that abstracts the (usually octet based input) into a sequence of non-negative integers. I am referring in vague terms to C/C++ stdlibs, PHP, Perl, POSIX, Python, etc. > > Someone can write a Markdown processor using these programming libraries, in such a way that the code operates on the abstract non-negative integers, and sequences out another set of abstract non-negative integers, which get converted into octets in accordance with the codepage or other settings in the environment or programming library. (This is in fact how several Markdown processors are written, such as Markdown.pl.) > > Therefore if the programming library recognizes UTF-16 input (with or without BOM, and with or without external metadata) and turns them into abstract non-negative integers for the program to consume, there is no reason to avoid (or promote) UTF-16 encoding over other forms. The program itself just looks for things like "<" which maps to the non-negative integer 0x3C (decimal 60). It is of course possible that EBCDIC is used, but I am not aware of popular Markdown processors that work specifically on EBCDIC values at the application level (obviously, such an application can consume and produce EBCDIC content if the programming library does the mapping from and to underneath), hence why the text says "will get along just fine by operating on character codes that lie in printable US-ASCII". Is it possible for a generic markdown editor, be it a script-sensitive GUI tool or pico/notepad, to record words like "=E6=BC=A2=E5=AD=97" and "=D0=BA= =D0=B8=D1=80=D0=B8=D0=BB=D0=BB=D0=B8=D1=86=D0=B0" in a way that all markdown systems should recognize and render correctly (e.g. transcoding to match HTTP preferences)? >> "Encoding considerations: Text." >> >> That doesn't really say anything. > > Well it is supposed to imply all of the stuff above. > > Nevertheless I did a search and lo-and-behold, I haven't found other registrations that say "Text" for this section. > > So, how about: > > ***** > Encoding considerations: > Markdown content is plain text content; any octet sequence is valid as long as it conforms to the character codes of the charset parameter. See [RFC2046]. Markup characters in Original Markdown [MDSYNTAX] are limited to printable US-ASCII; however other variants can define markup characters outside this range (including control characters such as NUL and characters encoded in multiple bytes). > ***** > > > >> >> " Fragment identifier considerations: >> >> See Section 4." >> >> Fragment Identifiers is actually section 3. > > > Thanks. I will change that reference to Section 3 in the next draft. > > Looking at the text, it appears that the Original variant is not actually registered, even though it is used in the example. I will draft a registration in the text-markdown-07 document. > > Sean > > > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types > --089e0149418022147f0513f64c34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Apr 15, 2015 9:21 PM, "Sean Leonard" <dev+ietf@seantek.com> wrote:
>
> Thanks for the feedback! My responses are below.
>
>
> On 4/14/2015 1:14 PM, Chris Lilley wrote:
>>
>> Hello Murray,
>>
>> Tuesday, April 14, 2015, 9:25:41 PM, you wrote:
>>
>>> Hi there,
>>> Could we get an early review of this document?=C2=A0 It contai= ns a media
>>> type registration.=C2=A0 The document is approaching Working G= roup Last
>>> Call in APPSAWG and I wanted to see if there's anything he= should
>>> fix before the formal request comes through.
>>> https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-m= arkdown/
>>
>> Putting Markdown in the text tree seems reasonable; it is probably=
>> more easily readable in source form than text/html.
>>
>> "Many Markdown processors will get along just fine by operati= ng on
>> character codes that lie in printable US-ASCII, blissfully oblivio= us
>> to coded values outside of that range."
>>
>> That seems to imply that encodings where US-ASCII does not encode = as
>> itself (such as UTF-16) should be avoided.
>
>
> Not exactly.
>
> Many programming ecosystems have a text-oriented stream or processing = pipeline that abstracts the (usually octet based input) into a sequence of = non-negative integers. I am referring in vague terms to C/C++ stdlibs, PHP,= Perl, POSIX, Python, etc.
>
> Someone can write a Markdown processor using these programming librari= es, in such a way that the code operates on the abstract non-negative integ= ers, and sequences out another set of abstract non-negative integers, which= get converted into octets in accordance with the codepage or other setting= s in the environment or programming library. (This is in fact how several M= arkdown processors are written, such as Markdown.pl.)
>
> Therefore if the programming library recognizes UTF-16 input (with or = without BOM, and with or without external metadata) and turns them into abs= tract non-negative integers for the program to consume, there is no reason = to avoid (or promote) UTF-16 encoding over other forms. The program itself = just looks for things like "<" which maps to the non-negative = integer 0x3C (decimal 60). It is of course possible that EBCDIC is used, bu= t I am not aware of popular Markdown processors that work specifically on E= BCDIC values at the application level (obviously, such an application can c= onsume and produce EBCDIC content if the programming library does the mappi= ng from and to underneath), hence why the text says "will get along ju= st fine by operating on character codes that lie in printable US-ASCII"= ;.

Is it possible for a generic markdown editor, be it a script= -sensitive GUI tool or pico/notepad, to record words like "=E6=BC=A2= =E5=AD=97" and "=D0=BA=D0=B8=D1=80=D0=B8=D0=BB=D0=BB=D0=B8=D1=86= =D0=B0" in a way that all markdown systems should recognize and render= correctly (e.g. transcoding to match HTTP preferences)?

>> "Encoding considerations: Text."
>>
>> That doesn't really say anything.
>
> Well it is supposed to imply all of the stuff above.
>
> Nevertheless I did a search and lo-and-behold, I haven't found oth= er registrations that say "Text" for this section.
>
> So, how about:
>
> *****
> Encoding considerations:
> Markdown content is plain text content; any octet sequence is valid as= long as it conforms to the character codes of the charset parameter. See [= RFC2046]. Markup characters in Original Markdown [MDSYNTAX] are limited to = printable US-ASCII; however other variants can define markup characters out= side this range (including control characters such as NUL and characters en= coded in multiple bytes).
> *****
>
>
>
>>
>> " Fragment identifier considerations:
>>
>> =C2=A0 =C2=A0 =C2=A0 See Section 4."
>>
>> Fragment Identifiers is actually section 3.
>
>
> Thanks. I will change that reference to Section 3 in the next draft. >
> Looking at the text, it appears that the Original variant is not actua= lly registered, even though it is used in the example. I will draft a regis= tration in the text-markdown-07 document.
>
> Sean
>
>
>
> _______________________________________________
> media-types mailing list
> media-types@ietf.org
> https://= www.ietf.org/mailman/listinfo/media-types
>

--089e0149418022147f0513f64c34-- From nobody Sat Apr 18 11:22:12 2015 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D121A882A for ; Sat, 18 Apr 2015 11:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_48=0.6] autolearn=no 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 5apFJEc7J-FU for ; Sat, 18 Apr 2015 11:22:10 -0700 (PDT) Received: from pechora8.dc.icann.org (pechora8.icann.org [IPv6:2620:0:2830:201::1:74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C33451A8829 for ; Sat, 18 Apr 2015 11:22:09 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id t3IILmsA029300 for ; Sat, 18 Apr 2015 18:22:08 GMT Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 77EA522E260; Sat, 18 Apr 2015 14:21:47 -0400 (EDT) Message-ID: <5532A0B4.1040708@seantek.com> Date: Sat, 18 Apr 2015 11:21:40 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Eric Prud'hommeaux" References: <1519282150.20150414221411@w3.org> <552EB64C.7080807@seantek.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020309010409030804090501" X-Greylist: Delayed for 71:16:57 by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Sat, 18 Apr 2015 18:22:08 +0000 (UTC) Archived-At: Cc: Chris Lilley , "Murray S. Kucherawy" , "media-types@iana.org" Subject: Re: [media-types] Early review request: draft-ietf-appsawg-text-markdown X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2015 18:22:11 -0000 This is a cryptographically signed message in MIME format. --------------ms020309010409030804090501 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 4/17/2015 7:17 PM, Eric Prud'hommeaux wrote: > > > On Apr 15, 2015 9:21 PM, "Sean Leonard" > wrote: > > > > Thanks for the feedback! My responses are below. > > > > > > On 4/14/2015 1:14 PM, Chris Lilley wrote: > >> > >> Hello Murray, > >> > >> Tuesday, April 14, 2015, 9:25:41 PM, you wrote: > >> > >>> Hi there, > >>> Could we get an early review of this document? It contains a media= > >>> type registration. The document is approaching Working Group Last > >>> Call in APPSAWG and I wanted to see if there's anything he should > >>> fix before the formal request comes through. > >>> https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ > >> > >> Putting Markdown in the text tree seems reasonable; it is probably > >> more easily readable in source form than text/html. > >> > >> "Many Markdown processors 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." > >> > >> That seems to imply that encodings where US-ASCII does not encode as= > >> itself (such as UTF-16) should be avoided. > > > > > > Not exactly. > > > > Many programming ecosystems have a text-oriented stream or=20 > processing pipeline that abstracts the (usually octet based input)=20 > into a sequence of non-negative integers. I am referring in vague=20 > terms to C/C++ stdlibs, PHP, Perl, POSIX, Python, etc. > > > > Someone can write a Markdown processor using these programming=20 > libraries, in such a way that the code operates on the abstract=20 > non-negative integers, and sequences out another set of abstract=20 > non-negative integers, which get converted into octets in accordance=20 > with the codepage or other settings in the environment or programming=20 > library. (This is in fact how several Markdown processors are written, = > such as Markdown.pl.) > > > > Therefore if the programming library recognizes UTF-16 input (with=20 > or without BOM, and with or without external metadata) and turns them=20 > into abstract non-negative integers for the program to consume, there=20 > is no reason to avoid (or promote) UTF-16 encoding over other forms.=20 > The program itself just looks for things like "<" which maps to the=20 > non-negative integer 0x3C (decimal 60). It is of course possible that=20 > EBCDIC is used, but I am not aware of popular Markdown processors that = > work specifically on EBCDIC values at the application level=20 > (obviously, such an application can consume and produce EBCDIC content = > if the programming library does the mapping from and to underneath),=20 > hence why the text says "will get along just fine by operating on=20 > character codes that lie in printable US-ASCII". > > Is it possible for a generic markdown editor, be it a script-sensitive = > GUI tool or pico/notepad, to record words like "=E6=BC=A2=E5=AD=97" and= "=D0=BA=D0=B8=D1=80=D0=B8=D0=BB=D0=BB=D0=B8=D1=86=D0=B0"=20 > in a way that all markdown systems should recognize and render=20 > correctly (e.g. transcoding to match HTTP preferences)? > Yes. First, you can use whatever text encoding you prefer, such as UTF-8. The = generic markdown editor shouldn't disturb those characters, and a=20 generic markdown processor should just pass them through. (The generic=20 markdown editor, if not UTF-8 aware, would just show some other byte=20 values such as =C3=A5=C3=99 but wouldn't change the octets.) Second, you can use entity references such as 〷. Those will be=20 passed as-is to the output. Sean --------------ms020309010409030804090501 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCC BK8wggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNV BAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJu YWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcN MTQxMjIyMDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAibEN2npTGU5wUh28VqYGJre4SeCW51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2 IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JDFnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9 KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUIkzqcKlOjENs9IGE8VQOO2U52JQIhKfqj fHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7AzaS1D6/rWpfGXd2dRjNnuJ+u8pQc4 doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZAP8vk4p+iIQIDAQABo4IBFzCC ARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYDVR0OBBYEFJJha4LhoqCq T+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0w OzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJv b3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRy dXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOc Uvi7BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc0 6HvgARClnMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLK hjQHuSzK5hxK2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6 H3kU9koQGib6fIr7mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcN AQELBQAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAyMDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRl ditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n2 0qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKPvku7E+utnLhcaNahAWr2oZgeCK9uhEqi jaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cUvZqY7YwzCG6jSfs4gwNh+29MS6fa Y6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/MwNAabNhDgxU2Tw1fl5w1Vt+6x RTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/syYhS1Ko4MSiJmR3ugKPk xEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQABo4IB8jCCAe4wHwYD VR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y8PBT6NqnIVbf NK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEE AbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2 Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEE gYMwgYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1 NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGG GGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVr LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC 8IXwUmNxL7L5uE3tGlNJVoTKZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63r MlFPFrjqQCEA6rDgo9DlFO9/81P7ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3 gUs5xJT0koGVvli2wR18zecG3ib3ml+GnDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamq r3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEpqpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMC tqlHvF3YY2z55jGCBDEwggQtAgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9u IGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecwCQYFKw4DAhoFAKCCAlUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwNDE4MTgyMTQw WjAjBgkqhkiG9w0BCQQxFgQUNar/x+LOG6VmOSjXIZFdmx0DNQwwbAYJKoZIhvcNAQkPMV8w XTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBwQYJKwYBBAGCNxAE MYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4 Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBpCSs8n+cQbczyWKtueyecwgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtue yecwDQYJKoZIhvcNAQEBBQAEggEAa5cqnHPBX6/FYQ8MThtolnGjOoCYirYy+LlMfR19OntP QGErKaogB+mSU0ISwtZJKacMLSvW3pyvQvFH6+4p3L30L4W6f2gzGHgF91x42IbxEm0ST9pX R/hwvyuCPrgAPXN3aCeZCKUhV03WQZ+vXHLA1nH4n3lQXrmwcYXPCeDBvLT24rNr0GQJgboI NNAwZryclgWZySjky0/lS+XYff/XB+FA3Jfi5/WVR+ZeTMgk2hfuFzDIC4vkwKJ/ojoA/y5t evB2ZJsghfHqokGpqJYOCZuzaB3M0bJjdQhi+aaBe9NM8vnhNv/FtYvppybwavJXskBZKPf3 OIUOqau/qQAAAAAAAA== --------------ms020309010409030804090501-- From nobody Sat Apr 18 22:58:26 2015 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5886F1AD182 for ; Sat, 18 Apr 2015 22:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.765 X-Spam-Level: * X-Spam-Status: No, score=1.765 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, SPF_SOFTFAIL=0.665] autolearn=no 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 nZv1fAIX2k24 for ; Sat, 18 Apr 2015 22:58:25 -0700 (PDT) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 878801AD1A3 for ; Sat, 18 Apr 2015 22:58:24 -0700 (PDT) Received: from APAC01-SG1-obe.outbound.protection.outlook.com (mail-sg1on0141.outbound.protection.outlook.com [134.170.132.141]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id t3J5w2Dr005968 for ; Sun, 19 Apr 2015 05:58:23 GMT Authentication-Results: iana.org; dkim=none (message not signed) header.d=none; Received: from [192.168.1.2] (220.221.10.230) by OS2PR01MB0139.jpnprd01.prod.outlook.com (0.161.77.147) with Microsoft SMTP Server (TLS) id 15.1.136.25; Sun, 19 Apr 2015 05:25:21 +0000 Message-ID: <55333C3D.1070402@it.aoyama.ac.jp> Date: Sun, 19 Apr 2015 14:25:17 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Sean Leonard , "Eric Prud'hommeaux" References: <1519282150.20150414221411@w3.org> <552EB64C.7080807@seantek.com> <5532A0B4.1040708@seantek.com> In-Reply-To: <5532A0B4.1040708@seantek.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [220.221.10.230] X-ClientProxiedBy: TY1PR0201CA0003.apcprd02.prod.outlook.com (25.164.90.141) To OS2PR01MB0139.jpnprd01.prod.outlook.com (25.161.77.147) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS2PR01MB0139; X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(6049001)(24454002)(479174004)(93886004)(92566002)(86362001)(117156001)(66066001)(85182001)(99136001)(65956001)(83506001)(80316001)(230783001)(85202003)(87976001)(122386002)(42186005)(23676002)(65816999)(76176999)(50986999)(87266999)(77096005)(62966003)(77156002)(4001350100001)(54356999)(2950100001)(64126003)(50466002)(65806001)(74482002)(40100003)(47776003)(46102003)(33656002)(5001770100001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS2PR01MB0139; H:[192.168.1.2]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(5002010)(5005006); SRVR:OS2PR01MB0139; BCL:0; PCL:0; RULEID:; SRVR:OS2PR01MB0139; X-Forefront-PRVS: 05514B7026 X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Apr 2015 05:25:21.8426 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS2PR01MB0139 X-Greylist: Delayed for 00:32:37 by milter-greylist-4.0 (pechora4.lax.icann.org [192.0.33.74]); Sun, 19 Apr 2015 05:58:24 +0000 (UTC) Archived-At: Cc: Chris Lilley , "Murray S. Kucherawy" , "media-types@iana.org" Subject: Re: [media-types] Early review request: draft-ietf-appsawg-text-markdown X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 05:58:26 -0000 On 2015/04/19 03:21, Sean Leonard wrote: > First, you can use whatever text encoding you prefer, such as UTF-8. The > generic markdown editor shouldn't disturb those characters, and a > generic markdown processor should just pass them through. (The generic > markdown editor, if not UTF-8 aware, would just show some other byte > values such as åÙ but wouldn't change the octets.) Please be careful. Some encodings, in particular UTF-8, are carefully designed to avoid using any 7-bit byte values when encoding non-ASCII characters. But other encodings, e.g. ISO-2022-JP and Shift_JIS, do use 7-bit bytes, and for them the "just pass through" will not work. If possible, please reflect this in your draft (at least to the extent as to not imply that "pass through" will work with all encodings. Regards, Martin. From nobody Sun Apr 19 10:20:47 2015 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131751A0084 for ; Sun, 19 Apr 2015 10:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 3R-fmAW7q8D5 for ; Sun, 19 Apr 2015 10:20:44 -0700 (PDT) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A645A1A007F for ; Sun, 19 Apr 2015 10:20:44 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id t3JHKNXw006527 for ; Sun, 19 Apr 2015 17:20:43 GMT Received: from deRahm.local ([93.222.227.185]) by mrelayeu.kundenserver.de (mreue003) with ESMTPSA (Nemesis) id 0MF8bn-1YY33u1llb-00GLKK; Sun, 19 Apr 2015 19:20:21 +0200 Message-ID: <5533E3D0.5000402@hoplahup.net> Date: Sun, 19 Apr 2015 19:20:16 +0200 From: Paul Libbrecht User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , "media-types@iana.org" References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aHlKOV4roQ6Ih6VpdARK6nFilOsa2B4ht" X-Provags-ID: V03:K0:YWTND3xch+nExhFdGPXaSC2scJs0j/HaUGjeH9B4Vldr46ZtNLT txq9GKqvBcjvXv3cg+ztTWQ3sorUKS/CSSEe53w2aInRrR6Qa65OGsZwwAO5GNE/YqLq4wH SqaMVEi/1GH+p9akeSMVIbJZB8E0RDPB0gmMwxbyXRewnarhw278qdvpSESO8IebRadyo4S TLU2uDZVqxQ5Svd53PlEw== X-UI-Out-Filterresults: notjunk:1; X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [192.0.33.74]); Sun, 19 Apr 2015 17:20:44 +0000 (UTC) Archived-At: Subject: Re: [media-types] Early review request: draft-ietf-appsawg-text-markdown X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 17:20:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aHlKOV4roQ6Ih6VpdARK6nFilOsa2B4ht Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Murray, I see this draft includes a UTI declaration which is very good and allows interoperability on the OSX-related platforms. Could you include a windows flavour name for Windows? I suspect the simple word "Markdown" (without quotes) would be sufficient, unless you know of existing editors that use that. Unfortunately, the only markdown editors I know of, Folding Text on MacOSX and StackEdit in browsers, do not export a Markdown-specific flavours. So... no big experiment doable. Paul On 14/04/15 21:25, Murray S. Kucherawy wrote: > Hi there, > > Could we get an early review of this document? It contains a media > type registration. The document is approaching Working Group Last > Call in APPSAWG and I wanted to see if there's anything he should fix > before the formal request comes through. > > https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ > > It's a good opportunity for me to train on filtering new requests too. > > --aHlKOV4roQ6Ih6VpdARK6nFilOsa2B4ht Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVM+PTAAoJEJQjh+Shy2exBqwIAKNtMzA9c7dgEISCKQ8LraCz LoC9CB0Y81sa/swFHfVlX4KbRw6dONJwCgugWFj96hvhRr2neCSm5lDCuBivijEV HyfIs/1fRD2h5X439qDJhDXAfZ2Cl5//VDPJit9LhnBlCd8AMImQC3c/Z+9xpge/ iMRi1HI1iYnUrSt6g7gaXUEUY9yLfChImCMlrvZ+U0l2z44+ZFBZxasUu77NGUF9 Lcy2gEXVny6/aJwDyK4C4epcUYRCH8KH9I0ncY5Uuqxv1m22wvt5Ur69KUdYDLEY 97XWdn+B8eAOcvCRFqezRvpp+Y91yIfFgmptXlObIixMuqFculpOTWD5rcg8l+A= =1/oB -----END PGP SIGNATURE----- --aHlKOV4roQ6Ih6VpdARK6nFilOsa2B4ht-- From nobody Sun Apr 19 11:00:57 2015 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326BB1A0B00 for ; Sun, 19 Apr 2015 11:00:56 -0700 (PDT) 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 vdXV3MWd0xcY for ; Sun, 19 Apr 2015 11:00:54 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E981A19E4 for ; Sun, 19 Apr 2015 11:00:54 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CECF622E260; Sun, 19 Apr 2015 14:00:50 -0400 (EDT) Message-ID: <5533ED4B.2030006@seantek.com> Date: Sun, 19 Apr 2015 11:00:43 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: media-types@ietf.org References: <5533E3D0.5000402@hoplahup.net> In-Reply-To: <5533E3D0.5000402@hoplahup.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020205040409030105020703" Archived-At: Cc: Murray Kucherawy Subject: Re: [media-types] Early review request: draft-ietf-appsawg-text-markdown X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 18:00:56 -0000 This is a cryptographically signed message in MIME format. --------------ms020205040409030105020703 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Paul, What do you mean by "flavours"? In the latest draft, the term "flavor"=20 has been discontinued, in favor of "variant". I am not aware of the term = "flavour name" being used as a Windows software development term. Thanks, Sean On 4/19/2015 10:20 AM, Paul Libbrecht wrote: > Dear Murray, > > I see this draft includes a UTI declaration which is very good and > allows interoperability on the OSX-related platforms. > Could you include a windows flavour name for Windows? I suspect the > simple word "Markdown" (without quotes) would be sufficient, unless you= > know of existing editors that use that. > > Unfortunately, the only markdown editors I know of, Folding Text on > MacOSX and StackEdit in browsers, do not export a Markdown-specific > flavours. > So... no big experiment doable. > > Paul > > > > > On 14/04/15 21:25, Murray S. Kucherawy wrote: >> Hi there, >> >> Could we get an early review of this document? It contains a media >> type registration. The document is approaching Working Group Last >> Call in APPSAWG and I wanted to see if there's anything he should fix >> before the formal request comes through. >> >> https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ >> >> It's a good opportunity for me to train on filtering new requests too.= >> >> > > > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types --------------ms020205040409030105020703 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCC BK8wggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNV BAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJu YWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcN MTQxMjIyMDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAibEN2npTGU5wUh28VqYGJre4SeCW51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2 IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JDFnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9 KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUIkzqcKlOjENs9IGE8VQOO2U52JQIhKfqj fHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7AzaS1D6/rWpfGXd2dRjNnuJ+u8pQc4 doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZAP8vk4p+iIQIDAQABo4IBFzCC ARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYDVR0OBBYEFJJha4LhoqCq T+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0w OzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJv b3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRy dXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOc Uvi7BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc0 6HvgARClnMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLK hjQHuSzK5hxK2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6 H3kU9koQGib6fIr7mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcN AQELBQAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAyMDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRl ditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n2 0qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKPvku7E+utnLhcaNahAWr2oZgeCK9uhEqi jaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cUvZqY7YwzCG6jSfs4gwNh+29MS6fa Y6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/MwNAabNhDgxU2Tw1fl5w1Vt+6x RTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/syYhS1Ko4MSiJmR3ugKPk xEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQABo4IB8jCCAe4wHwYD VR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y8PBT6NqnIVbf NK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEE AbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2 Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEE gYMwgYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1 NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGG GGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVr LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC 8IXwUmNxL7L5uE3tGlNJVoTKZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63r MlFPFrjqQCEA6rDgo9DlFO9/81P7ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3 gUs5xJT0koGVvli2wR18zecG3ib3ml+GnDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamq r3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEpqpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMC tqlHvF3YY2z55jGCBDEwggQtAgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9u IGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecwCQYFKw4DAhoFAKCCAlUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwNDE5MTgwMDQz WjAjBgkqhkiG9w0BCQQxFgQU2GzvPwuFuDhroEUXr04DU+Vq+iIwbAYJKoZIhvcNAQkPMV8w XTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBwQYJKwYBBAGCNxAE MYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4 Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBpCSs8n+cQbczyWKtueyecwgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtue yecwDQYJKoZIhvcNAQEBBQAEggEACjE2kaAZtnNBSGsx0uBsqh0cFA5x+9+TqdRaFkcTpfp9 UqMmX9uA34y6HPWWDLvSQ/8HSEUhi2XoQxDXkjJwJB0M5nPCq8XLWsbuiMTq5Bg2ZjyRNZR7 xfPnsBJh9t+QdqAzsUe8kW9PouROiH+T/BpmRnSTlRTKBU62J8kEt/sSZX4nWa5mqoJIEM2r +hdI7x/ONoiNzTGsWk44JXlLwS04EAc5k8w7sDX4nmywPE4usFcrsT5n3lzA6k4t9L0nL1I/ bbY/VX/TX2nrLG1ig0GEXaERO/tnV9/KYUbPgZMoO/JZbTctEfOJ94r63mq2s8/kzLx3yrOK Dcd6L0228wAAAAAAAA== --------------ms020205040409030105020703-- From nobody Sun Apr 19 13:41:12 2015 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA59B1A1B16 for ; Sun, 19 Apr 2015 13:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 XS1XHIC4roT9 for ; Sun, 19 Apr 2015 13:41:10 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 424C31A1B17 for ; Sun, 19 Apr 2015 13:41:10 -0700 (PDT) Received: from deRahm.local ([93.222.227.185]) by mrelayeu.kundenserver.de (mreue001) with ESMTPSA (Nemesis) id 0LbDeU-1ZDGDy3IpW-00kx9S; Sun, 19 Apr 2015 22:41:04 +0200 Message-ID: <553412DC.4090007@hoplahup.net> Date: Sun, 19 Apr 2015 22:41:00 +0200 From: Paul Libbrecht User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Sean Leonard , media-types@ietf.org References: <5533E3D0.5000402@hoplahup.net> <5533ED4B.2030006@seantek.com> In-Reply-To: <5533ED4B.2030006@seantek.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XkcAdJttEilgv13EcoDAnKBpUg8UGJNi0" X-Provags-ID: V03:K0:4SwoJSuvNS1XRsHuD0mXp7+xoH2wU1Xe2zAQt2XJZLm6KFLA6Du ViKuVJDQBvpGmSw0Pb8XsKNvtHIawJekw9PmzkIz+tgWUOP4c7hSqF9DO9zvx4yCkcvrrEq yPk/cQ3JSZM/eJixc/sghStwauQFCzHhfBuq0xThOBMwMFt2bLpjgOB1cr5aRozwJRcVl4n UcewhxTyIDE2reBjcFhjg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: Murray Kucherawy Subject: Re: [media-types] Early review request: draft-ietf-appsawg-text-markdown X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 20:41:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XkcAdJttEilgv13EcoDAnKBpUg8UGJNi0 Content-Type: multipart/alternative; boundary="------------020107020004030607040809" This is a multi-part message in MIME format. --------------020107020004030607040809 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks Sean, I dug a bit and indeed the word flavor seems to be far from the MS world. It may well be something that is special to Java... Sorry for the wrong naming. DataFormat would be the closest. A list of predefined values is here: https://msdn.microsoft.com/en-us/library/system.windows.dataformats.a= spx paul On 19/04/15 20:00, Sean Leonard wrote: > Hi Paul, > > What do you mean by "flavours"? In the latest draft, the term "flavor" > has been discontinued, in favor of "variant". I am not aware of the > term "flavour name" being used as a Windows software development term. > > Thanks, > > Sean > > On 4/19/2015 10:20 AM, Paul Libbrecht wrote: >> Dear Murray, >> >> I see this draft includes a UTI declaration which is very good and >> allows interoperability on the OSX-related platforms. >> Could you include a windows flavour name for Windows? I suspect the >> simple word "Markdown" (without quotes) would be sufficient, unless yo= u >> know of existing editors that use that. >> >> Unfortunately, the only markdown editors I know of, Folding Text on >> MacOSX and StackEdit in browsers, do not export a Markdown-specific >> flavours. >> So... no big experiment doable. >> >> Paul >> >> >> >> >> On 14/04/15 21:25, Murray S. Kucherawy wrote: >>> Hi there, >>> >>> Could we get an early review of this document? It contains a media >>> type registration. The document is approaching Working Group Last >>> Call in APPSAWG and I wanted to see if there's anything he should fix= >>> before the formal request comes through. >>> >>> https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ >>> >>> It's a good opportunity for me to train on filtering new requests too= =2E >>> >>> >> >> >> >> _______________________________________________ >> media-types mailing list >> media-types@ietf.org >> https://www.ietf.org/mailman/listinfo/media-types > > > > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types --------------020107020004030607040809 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks Sean,

I dug a bit and indeed the word flavor seems to be far from the MS world. It may well be something that is special to Java... Sorry for the wrong naming.

DataFormat would be the closest.
A list of predefined values is here:
=A0=A0=A0 https://msdn.microsoft.co= m/en-us/library/system.windows.dataformats.aspx
paul


On 19/04/15 20:00, Sean Leonard wrote:=
H= i Paul,

What do you mean by "flavours"? In the latest draft, the term "flavor" has been discontinued, in favor of "variant". I am not aware of the term "flavour name" being used as a Windows software development term.

Thanks,

Sean

On 4/19/2015 10:20 AM, Paul Libbrecht wrote:
Dear Murray,

I see this draft includes a UTI declaration which is very good and
allows interoperability on the OSX-related platforms.
Could you include a windows flavour name for Windows? I suspect the
simple word "Markdown" (without quotes) would be sufficient, unless you
know of existing editors that use that.

Unfortunately, the only markdown editors I know of, Folding Text on
MacOSX and StackEdit in browsers, do not export a Markdown-specific
flavours.
So... no big experiment doable.

Paul




On 14/04/15 21:25, Murray S. Kucherawy wrote:
Hi there,

Could we get an early review of this document?=A0 It contains a= media
type registration.=A0 The document is approaching Working Group= Last
Call in APPSAWG and I wanted to see if there's anything he should fix
before the formal request comes through.

https://datatracker.ietf.org/doc/dr= aft-ietf-appsawg-text-markdown/

It's a good opportunity for me to train on filtering new requests too.





_______________________________________________
media-types mailing list
media-types@ietf.org
https://www.ietf.org/mailman/listinfo/media-= types 




_______________________________________________
media-types mailing list
media-types@ietf.org
https://www.ietf.org/mailman/listinfo/media-types

--------------020107020004030607040809-- --XkcAdJttEilgv13EcoDAnKBpUg8UGJNi0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVNBLfAAoJEJQjh+Shy2exOEgH/A5F3qxRHaJuz1/z6+nkH5sW CjJn6Xb24Z81Z9h9t5JsuII7nwmsm4MqucSfeF2pVB6U+dNAIznFSmNRsi1KTtN6 7UJKy+gSmaveFVTp7gbPeoOOJgBsjanpzul2MrtrIHw+j3DvQ7r+d+G8+828d/rO MO7RzZ/CnE/mkscr/c9Vy12OCYfK51W/6cn4zFrtOklqw8h3M6ax/aOVGgOR/E2d FnzV3s8hFtvLNSXPjnt3dVPklw+d1senT3aqxeyWeYMA3Y8F9vhV9yhlYytrRA4g iQC4ltYFuUZPlOVyg3ONQe117IZw6AXzsbm1Gx+fSFFUvlyXqDCajKmsN7uAI1A= =+Iqe -----END PGP SIGNATURE----- --XkcAdJttEilgv13EcoDAnKBpUg8UGJNi0-- From nobody Wed Apr 22 01:57:18 2015 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D017D1B3212 for ; Wed, 22 Apr 2015 01:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.321 X-Spam-Level: ** X-Spam-Status: No, score=2.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_26=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001] autolearn=no 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 F5SPdXdgGcXZ for ; Wed, 22 Apr 2015 01:57:14 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F195C1B31D2 for ; Wed, 22 Apr 2015 01:57:00 -0700 (PDT) Received: by oiko83 with SMTP id o83so173673385oik.1 for ; Wed, 22 Apr 2015 01:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mygrid.org.uk; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=cVfaGAYeSW31Axs1zI/Nzxf7LrTiomiYnWl8gXHjr/4=; b=e8JXYylbV32GNthwP8zq8EHjpjDLcQeScqutTUbOhWN8DaomNQyFZSUN2YmJVDCPzj +iipfVGgTvlZI3aXw3DnFs85DIPwqkWOhDYOM/sVnQm14skF6C6PAFJqCJEWgvAZlReM hbvzLTD7y6Q0VFlNa3KBBQon31xPS3Ce/85Xs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:content-type; bh=cVfaGAYeSW31Axs1zI/Nzxf7LrTiomiYnWl8gXHjr/4=; b=M8xAqvuXAYEJ+wZiHvBBa14TWEXYCCbTz9xbGjNFUtfZ4CIq2Sv0+V2uAV4BI+ACwr Ok/p2WO6n5q35ozBPTog7MOxfIc2wzfbhL0PSyex7+XFo5LKUyqqoD1nS6A7TrSb6MDj c/bctekfV7/qdEDFTb55Hg7jl+okRt+U/J6t6mnEviXivExCvlNZNk6VL8HNb5uBzpKT DGtPK2trllz8cAkkYAuGnda55tFw80GMnTB9LRodXzwZ9yUakqi65F/2qg7auKSj6DkX FVglJ18MZ9g9PBbnrI4Nfh1ZfBoZq8F84EET2gAhP3HZ2lGomq+jy/1WZlvzCdN+fFdq owTA== X-Gm-Message-State: ALoCoQmc+za5ZG5YfE/GwE5JZGD/KdlGLvhlSgbWpCgb7UI8+B3mX4k4HcqVD4Fml21RUmF4pKjs X-Received: by 10.202.176.134 with SMTP id z128mr21488811oie.102.1429693020096; Wed, 22 Apr 2015 01:57:00 -0700 (PDT) MIME-Version: 1.0 Sender: stian@mygrid.org.uk Received: by 10.76.37.170 with HTTP; Wed, 22 Apr 2015 01:56:39 -0700 (PDT) In-Reply-To: References: From: Stian Soiland-Reyes Date: Wed, 22 Apr 2015 09:56:39 +0100 X-Google-Sender-Auth: 0rjAzHXmzDb9zxGQPozh5dFA17s Message-ID: To: media-types@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [media-types] "Cool" Linked Data URIs for all IANA mediatypes? X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 08:57:17 -0000 I never heard anything about this question. I can try to help with creating the corresponding web resources - but need to know what is the setup at iana.org.. is it a regular Apache server? Is the HTML created from the XML as a manual step or dynamically? I see there is http://www.iana.org/assignments/media-types/media-types.xml now.. so it's one step forward to a structured media registry.. but I would have preferred regular Linked Data than a custom XML. Related discussion also for link relation types, which also need resolvable URIs: https://github.com/mnot/I-D/issues/39 On 14 October 2014 at 02:07, Stian Soiland-Reyes wrote: > tl;dr: Ensure every registered media type has a corresponding URI, > avoid 404 for http://www.iana.org/assignments/media-types/text/plain > > > In Linked Data [1][2] we need identifiers for common resources. These > identifiers are typically so-called "Cool URIs" [3]. > > Internet Media Types are commonly referred to when describing resource > metadata, particularly in the case of packaging or redistributing > resources. > > > Many newer mediatypes have individual pages at iana, like: > > http://www.iana.org/assignments/media-types/application/pdf > > Put many mediatypes do not have such a "cool URI", e.g. > > http://www.iana.org/assignments/media-types/text/plain > 404 Not Found > > > I therefore feel that as a third-party I am not at liberty to "invent" > such URIs by simply appending the registered (or unregistered!) type > to an URI template > > http://www.iana.org/assignments/media-types/{type}/{subtype} > > > > Additionally there is no RDF information available for media-types > using content-negotiation at iana.org - some of the URIs give HTML, > other plain text. > > > Some third-party efforts have been made to create alternative URIs to > identify media types: > > http://purl.org/NET/mediatypes/text/plain > > (sadly the above does not content-negotiate to RDF either) > > Those are achieved by screen scraping of iana,org, and is also > available as a (probably by now outdated) RDF dump [5]. > > > > Example of usage of these identifier beyond the Linked Data world, > from the COMBINE Archive [6], page 7: > >> The Internet Media type URI should be of the form >> http://purl.org/NET/mediatypes/ >> followed by >> the Media type name. Here are a few examples: >> >> for png (Portable Network Graphics) http://purl.org/NET/mediatypes/image/png >> for pdf (Portable Document Format) http://purl.org/NET/mediatypes/application/pdf > > (There the use of URIs allow one to mix and match official IANA media > types with other format identifiers) > > > > > > How to describe mediatypes in RDF is still a bit unclear, it is > however common to use Dublin Core's "format" property, although there > are two approaches: > > dc:format "text/html" > > No links to follow here.. and dc:format also allows any kind of format > literals like "VHS" and "Polaroid". Easy to use, though. > > > The dcterms:format property [7] is more suited as it goes to a > resource, but is a bit cumbersome to describe correctly as an IANA > type, see [4] > > > > > > I would want to propose for IANA to support this directly for all > registered types without needing the volunteer effort of > http://purl.org/NET/mediatypes/ > > > dcterms:format > . > > > Resolving http://www.iana.org/assignments/media-types/application/pdf > with content negotiation to Accept: text/turtle should give something like: > > @prefix rdf: . > @prefix rdfs: . > @prefix dcterms: . > @prefix dcam: . > > a > dcterms:FileFormat ; > owl:sameAs ; > dcam:memberOf dcterms:IMT ; > rdfs:label "application/pdf" ; > rdf:value "application/pdf" ; > rdfs:isDefinedBy ; > rdfs:seeAlso > > > Resolving for > Accept: text/turtle should give the concatenation (without repeated @prefix) > of all those. > > Support for other RDF formats like application/rdf and > application/ld+json should also be considered. > > > Is this something for IANA to consider? > > > > As a minimum what I am hoping for is a predictable URI pattern that we > can use for any registered IANA type - e.g. so that > http://www.iana.org/assignments/media-types/text/plain and friends > don't give a 404. > > > > > [1] http://www.w3.org/DesignIssues/LinkedData.html > [2] http://www.w3.org/standards/semanticweb/data > [3] http://www.w3.org/TR/cooluris/ > [4] https://gist.github.com/stain/4635250 > [5] http://mediatypes.appspot.com/ > [6] http://co.mbine.org/system/files/omex.version-1.pdf > [7] http://purl.org/dc/terms/format > > > > -- > Stian Soiland-Reyes, myGrid team > School of Computer Science > The University of Manchester > http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718 -- Stian Soiland-Reyes, eScience Lab School of Computer Science The University of Manchester http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718