From nobody Sun Oct 4 17:38:51 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192921B3BA4 for ; Sun, 4 Oct 2015 17:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 vR3_2BDiFzR9 for ; Sun, 4 Oct 2015 17:38:48 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 451F11B2D02 for ; Sun, 4 Oct 2015 17:38:48 -0700 (PDT) Received: from [192.168.123.109] (unknown [75.83.2.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id EE272509BD; Sun, 4 Oct 2015 20:38:45 -0400 (EDT) From: Sean Leonard Content-Type: multipart/signed; boundary="Apple-Mail=_BF00B613-7BD1-42CF-880F-90743405DD7A"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <51DD9858-4E44-4296-A00D-A1B75D99864F@seantek.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Sun, 4 Oct 2015 17:37:36 -0700 References: <20151005002952.4782.41782.idtracker@ietfa.amsl.com> To: IETF Apps Discuss , media-types@iana.org X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: ietf-charsets@iana.org Subject: [apps-discuss] New Version Notification for draft-seantek-text-nfo-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 00:38:51 -0000 --Apple-Mail=_BF00B613-7BD1-42CF-880F-90743405DD7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A new version of the Independent Submission for the media type text/nfo = is posted; comments welcome. Per IETF policies, the media type registration template is provided = below for the sake of media-types@ ; the charset registration template = is provided below for the sake of ietf-charsets@ . (Note that the last time that I submitted the template to ietf-charsets@ = on September 5, 2015, I got a bounce back. Not good.) Sean Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-seantek-text-nfo-02.txt > Date: October 4, 2015 at 5:29:52 PM PDT >=20 A new version of I-D, draft-seantek-text-nfo-02.txt has been successfully submitted by Sean Leonard and posted to the IETF repository. Name: draft-seantek-text-nfo Revision: 02 Title: The text/nfo Media Type Document date: 2015-10-04 Group: Individual Submission Pages: 13 URL: = https://www.ietf.org/internet-drafts/draft-seantek-text-nfo-02.txt Status: https://datatracker.ietf.org/doc/draft-seantek-text-nfo/ Htmlized: https://tools.ietf.org/html/draft-seantek-text-nfo-02 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-seantek-text-nfo-02 Abstract: This document registers the text/nfo media type for use with release iNFOrmation. While mostly compatible with text/plain, ".NFO" files and content have unique encoding and rendering characteristics that make them distinguishable from typical plain text. ***** 2. Release iNFOrmation Media Type Registration Application Type name: text Subtype name: nfo Required parameters: charset: Per Section 4.2.1 of [RFC6838], charset is REQUIRED. Unlike most other text types, the default value is the character set of the original IBM PC and MS-DOS, called OEM Code Page 437, and named "oem437". Implementations MUST support OEM Code Page 437. Unfortunately, the simple application of the IANA registered character set "IBM437" (aka "cp437") [RFC1345] will miss some important characters, so conformant implementations MUST support OEM Code Page 437 as specified in Section 3. NFOs authored for more modern computing environments are known to use ISO-8859-1, ISO- 8859-15 (including support for the Euro sign), or UTF-8; however, for maximum interoperability, these or any other character sets MUST be declared by the sender. When absent, a receiver MAY guess, but SHOULD heavily bias the outcome towards OEM Code Page 437 unless UTF-8 encoding is patently obvious. A RECOMMENDED detection algorithm is provided in Appendix A. Optional parameters: baud: A natural number (integer greater than 0) indicating the gross bit rate at which the NFO is supposed to be rendered to screen. This optional parameter provides a nostalgic effect from the days of modems and fixed-speed serial lines. It also controls the animation rate, to the extent that the NFO employs optional escape sequences. Encoding considerations: Text with 8-bit code points; all 8-bit combinations (including NUL) are possible. Accordingly, text SHOULD be quoted-printable or base64 encoded when transmitted over a channel that is not 8-bit clean. Security considerations:=20 It's just text; this format provides no facilities for confidentiality or integrity. The ANSI escape sequence "CSI 5 m" could, however, blink you to death. As only a subset of ANSI escape sequences MUST be interpreted; interpreting a greater range than the subset prescribed in this registration may introduce other security issues, such as transmitting operating system commands. Some code points in oem437 have been used ambiguously in practice, so implementations SHOULD NOT assume that the mapping between this charset and Unicode is bijective. When displayed, codes 00, 20, and FF MAY appear to be similar, i.e., as a blank space. Interoperability considerations: NFOs are plain text but look best when read in a terminal view or with a dedicated NFO viewer that can emulate terminal features. As a result, they SHOULD be treated differently than text/plain files. The reference implementation that all NFO viewers SHOULD target is an IBM PC-compatible machine running MS-DOS 6.22 with the ANSI.SYS MS-DOS device driver loaded, where the NFO is displayed as if it were output to the terminal using the "TYPE" command. Published specification: [[Note to RFC Editor: Insert number here.]] Applications that use this media type: NFO viewers; text editors; terminals. Fragment identifier considerations: Same as text/plain [RFC5147]. Note that escape sequences do not contribute to the character count [[NB: do they?]], and line breaks are treated as one character, regardless of whether CRLF or some other code(s) are used. Additional information: Deprecated alias names for this type: text/x-nfo File extension(s): .nfo Macintosh file type code(s): TEXT. A uniform type identifier (UTI) of "public.nfo", which conforms to "public.plain-text", is RECOMMENDED. 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 ***** To: ietf-charsets@iana.org Subject: Registration of new charset oem437 Charset name: oem437 Charset aliases: None. Suitability for use in MIME text: Suitable. Published specification(s): This specification; [OEMCP437]. ISO 10646 equivalency table: This table is taken from the IBM437 registration in [RFC1345], with modifications based on actual implementations of [OEMCP437], as discussed in this document. Character mnemonic symbols generally map to the Unicode code points listed in Section 3 of [RFC1345], with the following exceptions. The symbol suffix $ (for example, HT$) means that the Unicode code point mapping is essentially correct, but an implementation might need to perform additional or special processing as discussed in this document, depending on the output environment. The symbol $$ means that this code point has special considerations as discussed in this document, so no single, definitive Unicode code point mapping can be given. Finally, three characters have no corresponding mnemonic symbols in Section 3 of [RFC1345], so symbols are defined here: $> 25ba BLACK RIGHT-POINTING POINTER $< 25c4 BLACK LEFT-POINTING POINTER $B 21a8 UP DOWN ARROW WITH BASE NU$ 0u 0U cH- cD- cC cS BL$ BS$ HT$ LF$ Ml Fm CR$ M2 SU $> $< UD !*2 PI SE SR $B -! -v $$ EC$ -L <> UT Dt SP ! " Nb DO % & ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < =3D > ? At A B C D E F G H I J K L M N O P Q R S T U V W X Y Z <( // )> '> _ '! a b c d e f g h i j k l m n o p q r s t u v w x y z (! !! !) '? Eh C, u: e' a> a: a! aa c, e> e: e! i: i> i! A: AA E' ae AE o> o: o! u> u! y: O: U: Ct Pd Ye Pt Fl a' i' o' u' n? N? -a -o ?I NI NO 12 14 !I << >> .S :S ?S vv vl vL Vl Dl dL VL VV LD UL Ul uL dl ur uh dh vr hh vh vR Vr UR DR UH DH VR HH VH uH Uh dH Dh Ur uR dR Dr Vh vH ul dr FB LB lB RB TB a* $$ G* $$ $$ s* $$ t* F* H* $$ $$ 00 $$ $$ (U =3D3 +- >=3D =3D< Iu Il -: ?2 Ob .M Sb RT nS 2S fS NS$ Additional information: See this document for details on how to handle particular codes that correspond both to graphemes in the IBM PC ROM, and to control characters. Person & email address to contact for further information: Sean Leonard Intended usage: COMMON *END* --Apple-Mail=_BF00B613-7BD1-42CF-880F-90743405DD7A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUxMDA1MDAzODI3WjAjBgkqhkiG9w0BCQQxFgQUMlT8yqUbDeCNDyCfN+qnWSswiyUwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBAHYEOoPja1ho5ovcoAoQlimI120gj2PUMjWQ61hgXJuMqGt4Gt5rmqiclYTF8OEDeBFx zsZMRk9P8kJE85ThltamMXuqZKSsHmZrwaZnOBD98jTW6E/YKA9ubB4H566fnrHClf0vOj/m67V5 va3KNCSur8YDWjfTwy094vK+M8a3Y+Orgwq71Abxx+LqjMlbOC1kgSR1EPPCQSP5q6yHUg9Q6SeQ 6CM4oht26yQ7+jey3AjVbnaTpx6GhAOYGxTjzV0z7WQCOS2eJyDUOuHfkNqOgesSp98eRcV664ox Xa6B32jJD/CLyebnygj7p6v5SBdhgN4497aVr70cXKm58dwAAAAAAAA= --Apple-Mail=_BF00B613-7BD1-42CF-880F-90743405DD7A-- From nobody Sun Oct 4 17:53:19 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8741B3C27 for ; Sun, 4 Oct 2015 17:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, 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 UK3C-ly20w6f for ; Sun, 4 Oct 2015 17:53:16 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 0AE191B3C26 for ; Sun, 4 Oct 2015 17:53:15 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8A8EF509BD; Sun, 4 Oct 2015 20:53:14 -0400 (EDT) To: "t.petch" , apps-discuss@ietf.org References: <560A2D96.7080605@seantek.com> <002d01d0faaa$315235c0$4001a8c0@gateway.2wire.net> From: Sean Leonard Message-ID: <5611C9DA.3050302@seantek.com> Date: Sun, 4 Oct 2015 17:52:42 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <002d01d0faaa$315235c0$4001a8c0@gateway.2wire.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010606010301030205010808" Archived-At: Cc: "media-types@iana.org" Subject: [apps-discuss] text/nfo draft-01 to -02 feedback, was Re: Volunteer needed for media type ISE review X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 00:53:17 -0000 This is a cryptographically signed message in MIME format. --------------ms010606010301030205010808 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello Tom et. al.: Thank you for the comments. I incorporated most of this feedback without = issue, except for the final two points (and a clarification about=20 security considerations): On 9/29/2015 4:29 AM, t.petch wrote: > Sean > > I think that you will need more Security Considerations to make this > acceptable. Looking at that section for other Media Types, they mostly= > say something about the lack of confidentiality, integrity and so on, > while this I-D explicitly mentions the ambiguity of some code points > which to me says 'easy phishing'. On this--I added more stuff. The only thing I might add in a future=20 draft is that if you go with the modern Microsoft code page mapping at=20 , then the mapping is in=20 fact bijective with Unicode. > s.3.7 this template corresponds to RFC2978 but I note that IANA has a > few extra fields. Doubtless the Expert Reviewer will ask for them if= > needed. I looked through the IANA registries (note that there are two: the=20 "charsets" registry and the "character sets" registry), and I did not=20 see the extra fields. Can you point them out? > 3.5 Better to be explicit that it is the 'Media Types' registry that is= > the intended destination. I did not modify the IANA Considerations text, not so much because I=20 disagree, but because I have at least two other Internet-Drafts: draft-seantek-windows-image draft-ietf-appsawg-text-markdown in which the same boilerplate directives are stated, without saying=20 "...in the Standards tree of the Media Types registry [CITE NEEDED?]=20 using the application provided...". If I change this draft, it is only=20 fair that I change the other drafts. Note that the text-markdown draft=20 is allllmoooosssttt ttthhheerrreee to AUTH48. So this is a general referendum on the topic. In a published document is = it necessary to state: 1. "of the Media Types registry" 2. "[CITE]" to the Media Types registry 3. "in the [Standards] tree" (let's face it, it's almost always going to = be in the Standards tree, otherwise why bother; it's also implicit in=20 the registration template) in the IANA Considerations? My view is that this statement is sufficient: IANA is asked to register the media type X/Y using the application=20 provided in Section Z of this document. Less is more. Sean --------------ms010606010301030205010808 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEw MDUwMDUyNDJaMC8GCSqGSIb3DQEJBDEiBCB5J7RUrb7PgeZjQWm6Dk5q+80GALudzTbauaCQ Sc3RRDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQCKr9npUBybL2m0xN7i mdLH1ku35m4DrmkIl9+uJHaxIPe83l9Q1PCqBcll8Z3i34SIrP0eN7ii8H82WVUu9yb5ngBP J4nb1eTfccz/L33l9OF0uPwTCTihgjeArUHqtWlZGY52MBEemot4sOuAp/Qd+79b50FQ6IOW PjWEeOv/CXMqKfBHs3aNNBaYWE9plJdrbietNMZDEGkWnlQf3XWik9X7HHukFRfrfluA2ubJ B8+g1BUNr9dYDSqmDSamqLf3kJJU0FVrhxrGBj393Yoi7ztaPHsg9fJWk0fOo7DymD4C57Gp fbEl17BV8cbElqqJvBvp/C2z3Ilr2Sjfvh1/AAAAAAAA --------------ms010606010301030205010808-- From nobody Mon Oct 5 00:19:33 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9ADC1B4B98 for ; Mon, 5 Oct 2015 00:19:31 -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 wUKg4JZkzFee for ; Mon, 5 Oct 2015 00:19:30 -0700 (PDT) Received: from relay12.mail.ox.ac.uk (relay12.mail.ox.ac.uk [129.67.1.163]) by ietfa.amsl.com (Postfix) with ESMTP id C71571B4B97 for ; Mon, 5 Oct 2015 00:19:29 -0700 (PDT) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay12.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Zj03U-0006PZ-dH; Mon, 05 Oct 2015 08:19:28 +0100 Received: from gklyne38.plus.com ([81.174.129.24] helo=conina.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Zj03U-0004El-D6; Mon, 05 Oct 2015 08:19:28 +0100 Message-ID: <5612247F.9000806@ninebynine.org> Date: Mon, 05 Oct 2015 08:19:27 +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 , apps-discuss@ietf.org References: <560A2D96.7080605@seantek.com> <002d01d0faaa$315235c0$4001a8c0@gateway.2wire.net> <5611C9DA.3050302@seantek.com> In-Reply-To: <5611C9DA.3050302@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Subject: Re: [apps-discuss] [media-types] text/nfo draft-01 to -02 feedback, was Re: Volunteer needed for media type ISE review X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 07:19:32 -0000 On 05/10/2015 01:52, Sean Leonard wrote: > So this is a general referendum on the topic. In a published document is it > necessary to state: > 1. "of the Media Types registry" > 2. "[CITE]" to the Media Types registry > 3. "in the [Standards] tree" (let's face it, it's almost always going to be in > the Standards tree, otherwise why bother; it's also implicit in the registration > template) > > in the IANA Considerations? > > My view is that this statement is sufficient: > IANA is asked to register the media type X/Y using the application provided in > Section Z of this document. > > Less is more. FWIW, based on my experience of reviewing non-media-type registration requests, I would say: 1. & 3. Not if the intent is clear from the template. 2. I think the relevant registration procedure document should be cited (normatively) somewhere that is close to the registration request. (e.g. add the citation [xxx] to a statement of the form you suggest above. #g -- From nobody Mon Oct 5 02:10:27 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4031B4E8E for ; Mon, 5 Oct 2015 02:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, 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 CvpaDI7OB86V for ; Mon, 5 Oct 2015 02:10:21 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-pu1apc01on0102.outbound.protection.outlook.com [104.47.126.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 881651B4E8C for ; Mon, 5 Oct 2015 02:10:20 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OS1PR01MB0136.jpnprd01.prod.outlook.com (10.161.229.13) with Microsoft SMTP Server (TLS) id 15.1.286.20; Mon, 5 Oct 2015 09:10:16 +0000 To: Sean Leonard , t.petch , References: <560A2D96.7080605@seantek.com> <002d01d0faaa$315235c0$4001a8c0@gateway.2wire.net> <5611C9DA.3050302@seantek.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <56123E72.3050602@it.aoyama.ac.jp> Date: Mon, 5 Oct 2015 18:10:10 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5611C9DA.3050302@seantek.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR06CA0007.apcprd06.prod.outlook.com (25.164.91.17) To OS1PR01MB0136.jpnprd01.prod.outlook.com (25.161.229.13) X-Microsoft-Exchange-Diagnostics: 1; OS1PR01MB0136; 2:Ya+9PMVCsp83uDjwa8YhQSISBtn+zkom3VvsOLhBnNyfEstLeclzQZKH82pRJorpo/hWzdU5g9SYWOr+xnnfVR03HmwmQLF5c7GjlE0kzkmTWRTt7ThOjnJJgWgc7RjVYvbMAtHMqqbBzAD2STXxb2nNEr2+N1/l4kyNWm2AGmk=; 3:53hiH7Wh0hEolXbtK7Tx+E0temUj7ENvZd3qpjwuwgQfWdU5ACqpJVxAJDMq+gdNrWgfcRC4S2y/Nlr2ltAQkT1Ok51tgvHk4r2v9Navm4/6xy3UeOe0pMoZTR68rDLd2/fWtyIw2uah2o2enl1RxQ==; 25:ohuMs7U7hYnm0e1lMFkABE749psLpWdDnFo5ArtqMo/B/jXoTPHfrQm+3fT1CS/l2S31YxU+PpPMTE0BbhWUXIX2An7Mc7X9BcjUyASanId+TX36S41JGSZy1WCxWP3iCJKUoQpOfX629glj0/oZz4V1WC6BEFoaEF3HBglHqndtd9I2fAG7ABDUqkOQWvQrTIY/AsfsIlGMX/GHzpApbsuPPRy0opkP8oplsUADYH0fgPFMjDfxHOnF8Q79WVCDUF1Z9qc71SIRypuJuZmuFA==; 4:pIg16+HcVkG1rsq99xH3pikJ51I4MIYW9KhjK/uUTAUq2A17LhBqmV7UtO0LEJksKoOg1SXNpRXb3RdFQnroZmvOBmBogUWdzQj+L85llrE/uzjk2uHVefyv8uCbCau/1IlOeo6I+bz7rQWcsSk/pVX9klfTpY/308R+CM4QzghtQa5rsgVY+f2dU7nKB0iBIIg+yPGfUgEkkpH4WVnyht8JeOOjznlw+gCLl0i5uVt12Yz8MhFqRcNui6UXTxvZhXXql4zvD3R9U28fKRqLCACUeD4B2S34SyNXQk9RlL4Z7VCLnf/Jnoe2uwwh9bdlqmEFtcbV+NGK/yH55eSLFQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS1PR01MB0136; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:OS1PR01MB0136; BCL:0; PCL:0; RULEID:; SRVR:OS1PR01MB0136; X-Forefront-PRVS: 07200C0526 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(199003)(189002)(24454002)(479174004)(122386002)(106356001)(40100003)(5001960100002)(65816999)(64126003)(99136001)(50466002)(65956001)(105586002)(23676002)(5008740100001)(86362001)(65806001)(64706001)(66066001)(47776003)(77096005)(50986999)(59896002)(2950100001)(189998001)(33656002)(101416001)(5004730100002)(5007970100001)(80316001)(46102003)(74482002)(81156007)(5001770100001)(77156002)(87976001)(97736004)(4001350100001)(62966003)(5001860100001)(4001540100001)(5001830100001)(83506001)(92566002)(42186005)(87266999)(68736005)(54356999)(76176999)(7059030)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS1PR01MB0136; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzFQUjAxTUIwMTM2OzIzOk04OGZ6TVB5NUU4S2h4ekptMHJSK1FmMlB6?= =?utf-8?B?cUJNQzhnR0x2cGdJRGJFRGd2bXFvNXNQTGJEb1FQT1dGZkkyUWRkTkZkUVBH?= =?utf-8?B?RlZzemV0dHlwb1N4RnJlTWZzby9pendpN1BHMWQ4NjFKMVZleGE2QWZzRC8w?= =?utf-8?B?N29JaUsvU1h1dXJteTNwTFdXaHVxa2pEamNScVFDOHBCSjdPc1NyZ0JaRnBz?= =?utf-8?B?Wk50dHBTazcvOE1DNFovaDhuYmR0UjVIekJFdGRrWUNkVUpINVZIcFlJUFF4?= =?utf-8?B?ZmtWTXBoWkRrdHRJMDJlWTFqRWx1ODZXYnJ3bm1iVzdTc1pVMTZEVzRWQ3N1?= =?utf-8?B?VU1qNC9qZGVXWldOczZXcmQrQ3JocHNRVjYxc09oNVYza3loKzk3dytQZTJK?= =?utf-8?B?L3JQS3JaUEw3bi9HcEsvaHArckV2RWVMQU9zMndPeWdkeE9aVTNEY1JzaXVa?= =?utf-8?B?dE80NTBKVFBITXF1cUxwT3FLNWZ1WmIzeVhQQ2JwZm1wTTFUbFA1RXVIV0lF?= =?utf-8?B?aFcvNlBRLytZanNvOElzT1VlZHRMcHV1eTZJcDJJcXVQNC9OMXV3M3c5OWR4?= =?utf-8?B?eUsxamRKYjlsM2xOMTh0aTFYOUM0a0xLQkhvSUJZZ1o0L01weUFKODJaclBP?= =?utf-8?B?WnFLeVZkU1JkVnVrRURCNG42M2k3YUpCeVRORXk5eWFUQ1VNM2F4K3F3ODRt?= =?utf-8?B?TWF6VFdxcWkvMXI2bTAvY1pnUTRLZnNKUHBPVE8vNjlSV2VXcUo4dTBCTS9k?= =?utf-8?B?aWRiK2ZYRGdvb2tuZVNkSDVnbGVOaFJtSXJlbzFGOW4rV0JUUWdpZnFDN3Zs?= =?utf-8?B?TlJLNWo4TGJaL2xlVlFDRGdtTWZxa0ZLZ291eTV6cSt2eC9nSFA3eDhudk9F?= =?utf-8?B?a0Q0cEgzZ200RjBGYXB2MHZZQkVSM3crOTR6cjFMQWNzYmxLWURleVZIRm5L?= =?utf-8?B?Rkdmd0ZianZOSUlEODRzQ3lCN1lGOXhTVkVnTXJBbjg0NnNjSkF4bHRjcHBE?= =?utf-8?B?NkZOZnBweG15L1ZjWXpjVFAwM2lCK2R1bnBESUJ3bERkMUdtajVyNlJicjJu?= =?utf-8?B?UmFhTVVaTENreW9INzBoMjhIYW0zRlR6WlRGMEc0WVcxS0d0ZkM0QnBESkJB?= =?utf-8?B?K0x4WmRMaDkyZ3NIM2VpUmlCNjFEQzZCY0RsMjY5OFAwaERJVFl2UGVlV2di?= =?utf-8?B?aElFN2JNN2EzTEt5SnZZVnJRSnhFeVJDcGxkSVd4YTh0Y0VsclBzNXJ2amRz?= =?utf-8?B?WFFPKzkxNjJOanRlbnlpY1pHdXM2TEliVnV5M0d2cEtuVTdhdUJZUEwyVkN1?= =?utf-8?B?R0c5YTVpZGlCbHI1cmxmVlNqekt1L1pkbmU3UDV1NnVwdnRvcVoyVHFiL3Vw?= =?utf-8?B?c20zMklSVUhGSC96VU5OQ1gzVWt2QXJBNkJKeGhmNFpKcFFLTEdEQk5sUmtp?= =?utf-8?B?UlA1cFpHY3R2dnJaSzE5R3h4cTEzOUFhMmdma0NQMC8vSEF1bmorZEpPRXNC?= =?utf-8?B?UEJxdkVBTENEU3ZkeEMzY2c3OWNzK0JlQkNUYjNzQ29zdld4eDFZcytKVVZa?= =?utf-8?B?RlN4bjgyeEZCcHdscVZ4WjNpRDJyOFRKZnRzbUdRWmhvYjQreHpOSjUrUU5I?= =?utf-8?B?WitjczIwVElQeW9yTVlMbTBPNzF5VlNKTENLN1NNdjlibVdYVFBZenpvaEMx?= =?utf-8?B?ZXhmM1YxeVRhT2t6bVd0S2RGOEttcVprTVFhOXdRdTNHTUs1U1dybGxycnZq?= =?utf-8?B?S2twRUZkR2JSckZiN3Rpa3JwVDQwb0cvMG9qRUxlYUtxZHZkVzlSRlR4K3VK?= =?utf-8?B?R2RHQkd5SVhoZnVseXovSVQ0ek5mNnRSdGc1Z0U5djhhYzdhcXBtaEYrSUVN?= =?utf-8?B?VnRQZmRIWUZjT09RVkw4T2tneVJTbFRjdk9rV3hBQVJJSUs0OGRiYVl1QXJC?= =?utf-8?B?MUZ0cEVWQzlRPT0=?= X-Microsoft-Exchange-Diagnostics: 1; OS1PR01MB0136; 5:HOg3bLIZ588tPxB9xnFajv8YQhebSQE6sxN8MQVAhTC/XV+TH3ZE4okpCBliTNSqgHr1+/yy1ezyMz7CYaQ4VAfsaTR6i7KGbxwIkKNLvxsP+mZNcgZGZONtZJSGPj4W8qt8WAxM8TISptdJYB3zww==; 24:17vRW+m8+Kg3+OYHiA5/YHh4YCvFBgiOvbjvLv7yxngXlXm0hnQ5eg/WhPPeq6bf6RSREYIzFGMGLIpkLqiEwKlUOF4kHRfvQAxcMmK0U2g=; 20:nheCAUfifxBd52IvBN7nqY6nQ4XxCXWy6m7OMfKJMEEy0vXNPlI4fHvctbTptDRYTbldDxPWL6pHYC30ts4yTA== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2015 09:10:16.2712 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS1PR01MB0136 Archived-At: Cc: "media-types@iana.org" Subject: Re: [apps-discuss] text/nfo draft-01 to -02 feedback, was Re: Volunteer needed for media type ISE review X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 09:10:25 -0000 On 2015/10/05 09:52, Sean Leonard wrote: > Hello Tom et. al.: >> s.3.7 this template corresponds to RFC2978 but I note that IANA has a >> few extra fields. Doubtless the Expert Reviewer will ask for them if >> needed. > > I looked through the IANA registries (note that there are two: the > "charsets" registry and the "character sets" registry), Can you say what you are referring to here? As far as I know, there is only one such registry. And as an expert reviewer for that registry, I guess I should know :-(. >> 3.5 Better to be explicit that it is the 'Media Types' registry that is >> the intended destination. > > I did not modify the IANA Considerations text, not so much because I > disagree, but because I have at least two other Internet-Drafts: > draft-seantek-windows-image > draft-ietf-appsawg-text-markdown > > in which the same boilerplate directives are stated, without saying > "...in the Standards tree of the Media Types registry [CITE NEEDED?] > using the application provided...". If I change this draft, it is only > fair that I change the other drafts. Note that the text-markdown draft > is allllmoooosssttt ttthhheerrreee to AUTH48. > > So this is a general referendum on the topic. In a published document is > it necessary to state: > 1. "of the Media Types registry" > 2. "[CITE]" to the Media Types registry > 3. "in the [Standards] tree" (let's face it, it's almost always going to > be in the Standards tree, otherwise why bother; it's also implicit in > the registration template) > > in the IANA Considerations? In the published document, the "please register" phrase will be replaced by something saying that IANA registered it, or so I think. > My view is that this statement is sufficient: > IANA is asked to register the media type X/Y using the application > provided in Section Z of this document. If it turns out to not be sufficient, IANA will tell you when they review the document. If a document is close to AUTH48, then it most probably already has passed that review. Regards, Martin. From nobody Mon Oct 5 06:01:35 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688031ACD37 for ; Mon, 5 Oct 2015 06:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 UP0-riOsbiTK for ; Mon, 5 Oct 2015 06:01:31 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 0841A1ACD32 for ; Mon, 5 Oct 2015 06:01:30 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B990E509C2; Mon, 5 Oct 2015 09:01:26 -0400 (EDT) To: =?UTF-8?Q?Martin_J._D=c3=bcrst?= , "t.petch" , apps-discuss@ietf.org References: <560A2D96.7080605@seantek.com> <002d01d0faaa$315235c0$4001a8c0@gateway.2wire.net> <5611C9DA.3050302@seantek.com> <56123E72.3050602@it.aoyama.ac.jp> From: Sean Leonard Message-ID: <56127486.1030305@seantek.com> Date: Mon, 5 Oct 2015 06:00:54 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <56123E72.3050602@it.aoyama.ac.jp> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060402050009080104010702" Archived-At: Cc: "media-types@iana.org" Subject: Re: [apps-discuss] text/nfo draft-01 to -02 feedback, was Re: Volunteer needed for media type ISE review X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 13:01:33 -0000 This is a cryptographically signed message in MIME format. --------------ms060402050009080104010702 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 10/5/2015 2:10 AM, Martin J. D=C3=BCrst wrote: > > > On 2015/10/05 09:52, Sean Leonard wrote: >> Hello Tom et. al.: > >>> s.3.7 this template corresponds to RFC2978 but I note that IANA has = a >>> few extra fields. Doubtless the Expert Reviewer will ask for them = if >>> needed. >> >> I looked through the IANA registries (note that there are two: the >> "charsets" registry and the "character sets" registry), > > Can you say what you are referring to here? As far as I know, there is = > only one such registry. And as an expert reviewer for that registry, I = > guess I should know :-(. http://www.iana.org/assignments/character-sets/character-sets.xml http://www.iana.org/assignments/charset-reg/charset-reg.xhtml See: http://www.iana.org/protocols#index_C Sean --------------ms060402050009080104010702 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEw MDUxMzAwNTRaMC8GCSqGSIb3DQEJBDEiBCDLSEYxj3C+CAy9lY96vE3yy8Ldq12wkFSXFsb1 Cof/aDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQCENI/vFNi6eGlcF0Cy OXn51WNbWOWA9E6sJKhMzoPW+JBHFgiHQxlTwl5AeVxY7sec/BEPmkkjoogtt6+DwqMujSgk aMOZCnb5JzGXYWk1R2txBA885jks1zTp7plE8yHQxXc0iY3KTATa7ibQvx28HxOOFbckuPir sy0JcQAtWoKFxt4st3CHXvTqAOcNCwQ+0Vugm4QNnTNA8n4cGv4oO38rlLHyQ1hL+qaIIMKr HDhDnUlSuEeOfINQ4ji9y21iistPtepZvzlrklznuashHapq8vwmiqEZLbBfj7bsHHrJPlLn RwGPT4Ah4m957zaOJ9p2ieHTg5W5Lo9NuvH6AAAAAAAA --------------ms060402050009080104010702-- From nobody Mon Oct 5 08:41:35 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5941B3191 for ; Mon, 5 Oct 2015 08:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, SPF_HELO_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 Je9f1iv33DFe for ; Mon, 5 Oct 2015 08:41:30 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0749.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::749]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6EAF1B3193 for ; Mon, 5 Oct 2015 08:41:20 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (31.54.179.163) by DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) with Microsoft SMTP Server (TLS) id 15.1.286.20; Mon, 5 Oct 2015 15:40:59 +0000 Message-ID: <009901d0ff84$3104aba0$4001a8c0@gateway.2wire.net> From: t.petch To: Sean Leonard , , =?UTF-8?Q?Martin_J._D=C3=BCrst?= References: <560A2D96.7080605@seantek.com> <002d01d0faaa$315235c0$4001a8c0@gateway.2wire.net> <5611C9DA.3050302@seantek.com> <56123E72.3050602@it.aoyama.ac.jp> Date: Mon, 5 Oct 2015 16:40:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [31.54.179.163] X-ClientProxiedBy: DB4PR05CA0022.eurprd05.prod.outlook.com (25.160.40.32) To DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB059; 2:VEb0RRNtIZ9VLxz4yht9esGDwy5Hdm6vfggvGXvAN26fOv0T4X4ZDqh+w2PiB/1NMDqnBI1KCXbEY99HrOnQqECR4p9iKOTcdAsjvFkKLe6wbE8s9qU+WZL/xG6EFvH/vqRo8Snb7tblOW6K7L+YDmohPDyirzB0QSYque04OxM=; 3:qnlvfMfvYcgAzJ/JepDuTVpUoGeDf58BLzNVFwtetW2lgAcOGQt9EqIrjlSWLZ3UUkvUYHqrHAsxKvDr6ceEEVSk31wqlrXIg0fu4YV2lHIvnCDraiMER06z6FJwIobXBO4XxUvo5UzBdBKIG1VfpA==; 25:pghLjAHs2tM26vvLp8x8NO3CCfYPEX0Qcog50xTPf1zIpiDkwvV3E52PYRGwW621NDNnv433cRFMN5bVgf6amkFc/Ek6l+0oRVWAkRopo5+HpDvtuAy7I5PlxOgcGYLuPpnZwIffB4Ysq/Iz0hjElHbhp2wjijpafkVuMaeyN155Vhiy77QPkXRKap0MnR7+Ye45ImbbbR0Bm/IR70BU7quP3qNcu4whhlQeeGWaku8rUBMJpT6QFglIOUq0KulO; 4:GrJpAlP4jsUdtcplqESNDRm5/m6svlmKo6IxfyRJE3bcPeyxP/+bmqfcF+Lnamw2C5wVMohEuzK9gq066lE14zAvCTgolGySJ1XNlwqTGGHx1gVU4OAUvQKSPVcQNnX8M3GqPkYIDUqkAtcnxTJEZhhkGmsghxtT1lhrpbHhyYwnvFmzuUPoCnfO0lebdLu9cCNvWt8zCtpr+dY1TK1CIua5qHmrJ8ZvVs+fgTd5ZWledQuVHRZVG84JvT6mye44DawWi/WJyTLjdsgNB06q0KEu6Hq4ZSj+xrCqLDnzcVT8QHHj+cam/nu6wt+NmrXqtNk5BeGcEfiSjhGOFzUjY+0fD46koT13ql13S9J3Jy0= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB059; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:DB3PR07MB059; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB059; X-Forefront-PRVS: 07200C0526 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(377454003)(13464003)(24454002)(189002)(479174004)(106356001)(66066001)(50986999)(40100003)(5820100001)(76176999)(81686999)(86362001)(97736004)(87976001)(1556002)(77156002)(5001770100001)(81816999)(81156007)(23676002)(50466002)(46102003)(62966003)(5001830100001)(5001860100001)(64706001)(42186005)(4001540100001)(47776003)(84392001)(5004730100002)(116806002)(122386002)(61296003)(101416001)(105586002)(5008740100001)(77096005)(93886004)(189998001)(5001960100002)(5007970100001)(19580395003)(44736004)(92566002)(62236002)(1456003)(14496001)(68736005)(44716002)(19580405001)(50226001)(33646002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB059; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjNQUjA3TUIwNTk7MjM6Ujk4ZlJvTXoxQkdqbHJZeXNtOUVRb3FVUkow?= =?utf-8?B?dFc3MkJEQ3NKRmZYYWJDOHQyOEt2SnhmTTVPb2VQNmlQRmZQLy9SWnJiZlJJ?= =?utf-8?B?WmFQdWVoMkRNSm9zZ2tHUnZSVVV3NmNsczhKUDJycmxjQ3JwVGEwdzF2eEpt?= =?utf-8?B?a3R5MmZ2a2drZmp6YXJSWlBDZFNaeVhicktrL0IyQlJUcXFxc05MVm8rdHIr?= =?utf-8?B?WkdyTVYvQWZBSUErVHh5QmZWU2E2aWF4RzcwR0RscFJwb3ZVUjRnSHdVaHBS?= =?utf-8?B?L3o4dVQ3ZUZlL0VwSGRucmxLRXNERnk3Rzk1UWhUL212WGdva3hlU0RrM09y?= =?utf-8?B?Y21Ma3NidFlIRTNpQkUxallaVThYanpxcmM4alJpRy96bUptT2gzK1g1dnJr?= =?utf-8?B?blBIaUg4Rmo4TjhuMFZrQ3FKL29USitEdklKM1ZUMXoyTmNLVGhMaGpkOFRH?= =?utf-8?B?Y2NUNmdsUjBNU1pQSE5JejVzeTZla3p6MmNwTEh6S2JoalpueFVzS00zdnh0?= =?utf-8?B?TmdSSjJSTE9aQlNSVGx5NlZLZTc3WTA5Vm1SUVF6RjNPV1RtUm5XZzBGbUZD?= =?utf-8?B?SXJUMWlYT0hwVG95VWx4Q2J3K2dlS2J3M2JSQUw4NThCMitmbk9EdDFCWUJs?= =?utf-8?B?eTgxcU9WMi95eWJ6ZEIvcDZlWVdwVW5uakkyVUIrWEdrNUM5Yno3bWVGMk1X?= =?utf-8?B?MUdKbzJWb0pwNDA2ajdWMy94K1dvTjdZS2tyRWtaeGtGT0c1RXlmYTdIcUcy?= =?utf-8?B?UnN2MGJGdENMVm5Zc3dYMnRXdjBsc1ExeFFhd2VSMGNENUlXU0FwYXZOV0tr?= =?utf-8?B?YitJUS81Zm5hRTZLSEc3dVV6V0lDY2NQaDJNaURHU01SbjV3MWorNktnTU9U?= =?utf-8?B?bk5sa0s5dDBoSXMyY28vOUxDL3BFbTNEQ3A5ODNTMjYyeHdGeEZSRm1KdUY0?= =?utf-8?B?UDMyKzk2RllPaUc0cVNzeHdyUm00TW1iYU9aVUI2R3NabFRYdW9TT2RJdUQw?= =?utf-8?B?VFpwOCtXYjdEc1hKSytqV2k2NWYvZ2ZBR0F0YlEzb1NZb0xtSENmdWoyNGtx?= =?utf-8?B?ZktQRjZuMTZLbjJMYk13cUs1Q3NqdkdGMzZzMW9KUlFEN1hIamIxQzB6MkJn?= =?utf-8?B?V1JiK3RJV201amdmMy9kZERvcVlKUVB5d0FwZlZoMUJScFM4KzFJeExjak1U?= =?utf-8?B?c2dlUFRqRlBzVkptSGRpSFRMVHhGVmt5ZGRuY0FlRXg2TGt6R0c2Ujl4Umtl?= =?utf-8?B?TlZRQy96eCtMbkw2NGJ5OS9wM0JYelM4enNjU1grRmNoZDdkOTlQTTFkUHBm?= =?utf-8?B?K3QyU2FqenZveXU2NnhnK05Tbm0vSzlvMnZuekp6RkhNVjFjR29Ub1RDV0RM?= =?utf-8?B?dUxsSmhZTXBBYW81U05PSzlrSEZsQ2FYMlFDbElQL1NBSHY2dk43QmxKdTJv?= =?utf-8?B?ZHQ4c21Fb0hGd1Y0VVdGRzRaUEYweUI4emdNQVRwa0tIYm1lclNnVHgvNkow?= =?utf-8?B?a2NsUGZQc25Rd082UkVJSy9JdC9oNkdoVTZ5OERXbmpWYVpPNFR0dVB2WHlV?= =?utf-8?B?ejhXR0owRWxOQjRPdE0wVEVZZTUvdmhKblpveko0ODBST3AwVC9tUXpiSXk2?= =?utf-8?B?dDVnc1pabmgrZTk4YkpBTU15UWNKanBtaEhwa3lXQnQxSlF0U0lOT285Q1hU?= =?utf-8?B?SnU2ajE2ZGpSdCswcEkxL0EyMVR0cnhpNGYvUVJlODE1OFBxYzYyelAyR0ls?= =?utf-8?B?eGI3NzhTb1FGbFJTVllOTDF1RHhCR3laZEJ1dmFVMEhuNHdqN3RrcTFPTk5G?= =?utf-8?B?S1NYcUM5R2hWQUNTZ0NCMnByOGdGVndQQmJYZVpnZmtab2JabW1VdW9oOVZQ?= =?utf-8?B?QUVwQmpZK1VpaTBpRnAvZkk1WnlqbEY0eUJrak9qSVNwenlTcFMyeWxjVzFX?= =?utf-8?B?WW9QNzhMcDNka3JWc01GWmtRZ3dWZS8vbEpjd05sdytoOHpzaWMvQmZubHFp?= =?utf-8?B?NTQzZG9HdmdPMDN5SGJ1MDB1WStlQzY0a0k1ZkJBUkVlSmJjNnFRYnNVblc3?= =?utf-8?Q?HAA=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB059; 5:brM760QUltW0ZqzChe72jsDKcnGZGhtR5tUFrrMO8ucJZ3I4CnFg2M3EbLL/yZ+7r7p+WgAlziFBLUs7bIFV8eOs6ZnHH8fGa0bPJ7fkhmIJxR8DKibQ7xkhlqw5qXE/KEm16UBbQHvNY1a2HiW6Tw==; 24:gDOk24pCTevU7LVxb3wEeP/Kq7XE2HUQ9kgYsLrGbr2NrgiB810LSPbolUhlEBWU+NEpVlEVslS/oLgFII6zqXIgFkrx1KulI4IugOMMy2o=; 20:s/8fKqqiXi33vYb8NZsU6bgm5bhTPY3eEKFjF0VDN5XAJBP76n4Ll69vOzYkkTDjIWn1ehLE73AcoEU5vX4xTg== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2015 15:40:59.9346 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB059 Archived-At: Cc: media-types@iana.org Subject: Re: [apps-discuss] text/nfo draft-01 to -02 feedback, was Re: Volunteer needed for media type ISE review X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 15:41:33 -0000 ----- Original Message ----- From: "Martin J. Dürst" To: "Sean Leonard" ; "t.petch" ; Cc: Sent: Monday, October 05, 2015 10:10 AM > > On 2015/10/05 09:52, Sean Leonard wrote: > > Hello Tom et. al.: > > >> s.3.7 this template corresponds to RFC2978 but I note that IANA has a > >> few extra fields. Doubtless the Expert Reviewer will ask for them if > >> needed. > > > > I looked through the IANA registries (note that there are two: the > > "charsets" registry and the "character sets" registry), > > Can you say what you are referring to here? As far as I know, there is > only one such registry. And as an expert reviewer for that registry, I > guess I should know :-(. charsets is for those not defined in RFC and so not applicable here My other comment related to the MIBenum - I see now that these are assigned by IANA. Tom Petch > > > >> 3.5 Better to be explicit that it is the 'Media Types' registry that is > >> the intended destination. > > > > I did not modify the IANA Considerations text, not so much because I > > disagree, but because I have at least two other Internet-Drafts: > > draft-seantek-windows-image > > draft-ietf-appsawg-text-markdown > > > > in which the same boilerplate directives are stated, without saying > > "...in the Standards tree of the Media Types registry [CITE NEEDED?] > > using the application provided...". If I change this draft, it is only > > fair that I change the other drafts. Note that the text-markdown draft > > is allllmoooosssttt ttthhheerrreee to AUTH48. > > > > So this is a general referendum on the topic. In a published document is > > it necessary to state: > > 1. "of the Media Types registry" > > 2. "[CITE]" to the Media Types registry > > 3. "in the [Standards] tree" (let's face it, it's almost always going to > > be in the Standards tree, otherwise why bother; it's also implicit in > > the registration template) > > > > in the IANA Considerations? > > In the published document, the "please register" phrase will be replaced > by something saying that IANA registered it, or so I think. > > > My view is that this statement is sufficient: > > IANA is asked to register the media type X/Y using the application > > provided in Section Z of this document. > > If it turns out to not be sufficient, IANA will tell you when they > review the document. If a document is close to AUTH48, then it most > probably already has passed that review. > > Regards, Martin. From nobody Mon Oct 5 23:33:57 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF261A8A7B for ; Mon, 5 Oct 2015 23:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, 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 AgX_XKjpzdvo for ; Mon, 5 Oct 2015 23:33:52 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0130.outbound.protection.outlook.com [104.47.124.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0CC11A8A78 for ; Mon, 5 Oct 2015 23:33:51 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by KAWPR01MB0130.jpnprd01.prod.outlook.com (10.161.27.11) with Microsoft SMTP Server (TLS) id 15.1.286.20; Tue, 6 Oct 2015 06:33:44 +0000 To: t.petch , Sean Leonard , References: <560A2D96.7080605@seantek.com> <002d01d0faaa$315235c0$4001a8c0@gateway.2wire.net> <5611C9DA.3050302@seantek.com> <56123E72.3050602@it.aoyama.ac.jp> <009901d0ff84$3104aba0$4001a8c0@gateway.2wire.net> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <56136B41.2070304@it.aoyama.ac.jp> Date: Tue, 6 Oct 2015 15:33:37 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <009901d0ff84$3104aba0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR01CA0011.jpnprd01.prod.outlook.com (25.161.131.149) To KAWPR01MB0130.jpnprd01.prod.outlook.com (25.161.27.11) X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0130; 2:iEmr0rmF6lxRJ961A/zg7HVW/uW/R3mSIxlNdnKPGCyuZPqCGryJSCXgRSnm8cekypgyt7END3yvbVLtvGaSy84A73jPQ8gLsKeKGI+yy436NJLV5fiEciCooovelINTxEKE+a5Rftbip9+mmTYikpuPAGxC6AzCQJUMA59/BG0=; 3:TclzwdW0IhjdNI9MEluk6X/j7DPO6Vs5Zrs06kmxKcgV/3NM8z6R5xe6TbazynRfJ8yPJIkpkDJIIVu9/Ysf8L3ptMw9YJPv3c9rXLlOA8PxORq8i+lULWD+Fpvb1kDwmhpZe5kV1ea6mAqNzwp0lA==; 25:AQxYu3XkYUaSy23gDoN66mXJIHOcttj8Xt4XtpUWfPYzzuPHqKEurESitTo7Py1agFO6cnCLcmYq6BwwbRw/cQEyfFtZfZ6VgvZyLBtircFW3IL/ABPdYEqTDSiIMQuB6wRZIOAxB+vMgJO9fnBMR2hhw/XNoiACCISa0vXbkMqh7axTQdGMTdda6d1Jw7ZD5eWdDmn031Cb+Rh4hCqdwy/9zlmymctHaypAPkfVaVVUwHjTqCn7VtAgFP0pDw3z1T4HnggxtO00Z6Qj1LtGpQ==; 4:q+HxG2TtJn6X4FvIxfws1GB9WvRDHbRxKd4N1Sm+1Ld6PDWgO+MoERqULPhg75Kvoj5ZbMik1rVrNcsH2gbWkbsrby6sXgJE1FJx1lCci1FmPutrzkVv5h4T3nftP80q5XLD1J2Q27UhHnhSxnVoqBXUhbGnJ7VhVojjTSic5Iaz2BcN7kS+we/9COpXKvT8ks+y8oKmOBtTzIVaY6doAJt93UwpnX+uFktzX289zXW96kwXKaaMzoZ96CigjX40K3Kz8+po7Ebr6VQzA2Bc5h8VsrhKvHWw18xMr0iRk3PMNynCjr6nhP9JvFqONY3feMLjjDx3kJMe8ciTL3jDiw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:KAWPR01MB0130; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(8121501046)(520078)(5005006)(3002001); SRVR:KAWPR01MB0130; BCL:0; PCL:0; RULEID:; SRVR:KAWPR01MB0130; X-Forefront-PRVS: 07215D0470 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(199003)(377454003)(13464003)(24454002)(189002)(479174004)(65816999)(47776003)(50466002)(4001350100001)(50986999)(101416001)(23676002)(46102003)(83506001)(76176999)(87266999)(40100003)(87976001)(97736004)(99136001)(5008740100001)(5001770100001)(65806001)(59896002)(122386002)(74482002)(33656002)(5004730100002)(66066001)(54356999)(105586002)(86362001)(64706001)(77096005)(5007970100001)(81156007)(80316001)(2950100001)(15975445007)(64126003)(106356001)(5001960100002)(65956001)(93886004)(19580395003)(189998001)(92566002)(19580405001)(42186005)(7059030)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:KAWPR01MB0130; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtLQVdQUjAxTUIwMTMwOzIzOjlvcnNVY3VSWG5KU05sRlc3R3Q5R3FtY215?= =?utf-8?B?M3gwQzk2ZEZzRnRxc2tDb1UxRDBIeG1IVmkrSXRSQ25Eb0R4UWx1T0hxUC9I?= =?utf-8?B?QkczbUZtcWhRdDlFNXhmVEl5eXQyRDFLVjVMQzh2a2N6OC9XOTVHVEtVT093?= =?utf-8?B?VEtJbUZjMFJMY1BZTWt0MXJXRlNWMVBJQm9vaTVUekZTSGN4d09iays3eDBS?= =?utf-8?B?a1NvQ3Z1SzNMamNvS1pKTFF0VVZBOTR6WXVSL3JjbE5IVkRuNWFzeTJtYkt5?= =?utf-8?B?R1hTcjNmcGczTmRGaWg4ZURHc012bks2YjdMQms2RXloQWZ5cjd3WGYwR0wr?= =?utf-8?B?bUs0V0k1bERod3hNNjJ5OWVBR0lUL2xzaDh1amdDK1Y0M3hEZS9qbGkzK2lO?= =?utf-8?B?dlVobTdpeGVvK1lHRHZvMHNVUjB3TTFtcXg2WnJPK3BoRHlTenVMRDQ0VlRY?= =?utf-8?B?cXNsUUpqNDlSWHhBa1p0T1dOM1JzNEl0NzJ2OTYrcmtrUWtvSWw3OXFKcEFI?= =?utf-8?B?akdCMG0xdzVWRmxJcVBpTXJoV2hOY1I4MGZ0aUE0dXR4OC9iMGw1dmlxSUw2?= =?utf-8?B?N0N6SEFBZS94Rk5GVWhxSGpnRkNpSUJudDJFQURHSzI1d3FnVTcwdkdldlBM?= =?utf-8?B?a2RtTmtQVkwwSXhEK2FrRnlJSGpmNnRxUHgrNVpVMXNOdnVnYjZ2aWtrbkVU?= =?utf-8?B?cW9BT09xenBRVjdCKzAzWlhHVFJXWWMzWTdCMW1selNvTnlsKzkzNUU2aXJS?= =?utf-8?B?TnVULzFvbTlNNWJNbFE5ZE1semZuTTZEdEVZQmlZdGVLcW5mSmdJb2Y0ZlFw?= =?utf-8?B?RTJqeDhyOHM3S0dIcDV0N0xFdW5mNnpNYStGQkZ6ZjZCY2ZWT0YzUlNsMEJQ?= =?utf-8?B?ZFIwaVk1RVZlYjZUeUVabUxwMDlBeTdGbHMvcW1vZ29GeS9kOEs1N3F3SXVl?= =?utf-8?B?djhieDhhQy9KbExheldZK3pSK1p1QjlGQURsSHBwK2ZHeVhzc1Fsa05FWjR5?= =?utf-8?B?K0tjUXBPSXdJQTVIUVRQbEJZTkcwenJ2VXhjdGlzUThvc3RudmNYdFFSQUJZ?= =?utf-8?B?Z1Bua0JSMHJsdDdYVyswTUJtUmIweE5JdUFiZmNORDVvQ0MwKy9CRldISHJK?= =?utf-8?B?MFBNWHQzUUR0MUdJUW9qcWRpMFhzb2lJdzNBWnNFMXhIK3ZMcWlGd1Vya1lx?= =?utf-8?B?bzY3eDFKZFFjU1dHY3djbXJZeEVlZ1l1dktKdHZ4SWw3b25kendEOEx2UENG?= =?utf-8?B?anQ1NDB4WXI2TWdKMW1Oa2l4YXZlWWdKRWZHdm9ZOU83U3dRUXBhSEdNNlN0?= =?utf-8?B?M3BueW1BZ1V1MVZQSTZVMnpIb3NSQXB3dXNLLzFLaHdvRVk2Y3N2QkQ2bktl?= =?utf-8?B?amZzSlhQRkRQeHE3YTFPMytwUVNWc0NQbXE3S1NGSjd1ZHdpUDZsc0l5V2p5?= =?utf-8?B?QnQ4a1Q5VEx1bnoydC9qbFluQnlFTmVuc1N5bm5nUkhINHI3OW9yZzZMNU9F?= =?utf-8?B?U2ZzWXgxcDBTRklzTUpLSFg5aktWZmgwZFpCZkIvVFJQVTdQeG1Rcm00V3Uz?= =?utf-8?B?UWo0SU1lUnFoaTNOZWtjUTdjM01UcFJHV3dlY0N0bm1VOEt2YWo4LzFOYmFQ?= =?utf-8?B?QWtucEhVWHdld29NQXluWnJiYkY2dUtUKzFVSXBZTnBkNzZwWVVHUm9SblYy?= =?utf-8?B?ZDNPa0tYNFZFUW9hSUdERENTbUduWU11RGRqdFNkaEJjSXo1VGg2SlBON0lT?= =?utf-8?B?VUdMc3FGSWJtVnZGZUhHTDNzUkJramJKOG5iU2FsYjMrU2NpcFJ4VWpmMWZO?= =?utf-8?B?Y3ZneHoyK0pUaWIzYXhFRVBleEtsUGpiNldSdzhNSWt5QzJuV3o0Q2lMQkFR?= =?utf-8?Q?GZ8L/RWAs2Dd1yZiC0WxU+SO2QvA4z7X?= X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0130; 5:ouTdOVPn2Y4SCMwUKUwzIxwskPeH/aACt3W3ITVYvYZxxCP9rn8PBnXq4+ZK0/HxwklCGqRuDTdGKDpft3ef8X7ySA0TbcWOLy6Us6UxlO2H5DrPweVuU2BvAiGf71CH56LwQlv04c/cO6TMm1U5NQ==; 24:FHt5JRakkzu//e7PNThL87N33bzpnKElJoXu8pyIAoG1xUeiaAPeXqlTwcojUbrQnppvP+dzm8tWaYPpkqZwLT4e1qlZPQajbvsZzMLZKKQ=; 20:FhJBiyJacoV7zIabDoso/dKh1cBrlY7HZiuUV8xvJgYAkEH57p7J6N+T7DMY+zuaActMKsn+EU8Iwg5GuSKSiQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2015 06:33:44.6449 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: KAWPR01MB0130 Archived-At: Cc: media-types@iana.org Subject: Re: [apps-discuss] text/nfo draft-01 to -02 feedback, was Re: Volunteer needed for media type ISE review X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 06:33:56 -0000 On 2015/10/06 00:40, t.petch wrote: > ----- Original Message ----- > From: "Martin J. Dürst" > To: "Sean Leonard" ; "t.petch" > ; > Cc: > Sent: Monday, October 05, 2015 10:10 AM >> >> On 2015/10/05 09:52, Sean Leonard wrote: >>> Hello Tom et. al.: >> >>>> s.3.7 this template corresponds to RFC2978 but I note that IANA > has a >>>> few extra fields. Doubtless the Expert Reviewer will ask for > them if >>>> needed. >>> >>> I looked through the IANA registries (note that there are two: the >>> "charsets" registry and the "character sets" registry), >> >> Can you say what you are referring to here? As far as I know, there is >> only one such registry. And as an expert reviewer for that registry, I >> guess I should know :-(. > > > charsets is for those not defined in RFC and so not applicable here Yes indeed. The registry is at http://www.iana.org/assignments/character-sets/character-sets.xml. The page at http://www.iana.org/assignments/charset-reg/charset-reg.xhtml isn't a registry, just a list of pointers to registration documents. The text on the page explains this. In both cases, the page heading uses the term "Character Set", not "Charset" (I wish it were otherwise, but that's a separate issue.) > My other comment related to the MIBenum - I see now that these are > assigned by IANA. They can be proposed by the submitter, but indeed they are assigned by IANA. Regards, Martin. From nobody Tue Oct 6 01:41:27 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B4A1B3CFE for ; Tue, 6 Oct 2015 01:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 Mv2ma0IP9Sbr for ; Tue, 6 Oct 2015 01:41:24 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 8431B1B3CFD for ; Tue, 6 Oct 2015 01:41:24 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2FD2D509BE; Tue, 6 Oct 2015 04:41:19 -0400 (EDT) To: =?UTF-8?Q?Martin_J._D=c3=bcrst?= , "t.petch" , apps-discuss@ietf.org References: <560A2D96.7080605@seantek.com> <002d01d0faaa$315235c0$4001a8c0@gateway.2wire.net> <5611C9DA.3050302@seantek.com> <56123E72.3050602@it.aoyama.ac.jp> <009901d0ff84$3104aba0$4001a8c0@gateway.2wire.net> <56136B41.2070304@it.aoyama.ac.jp> From: Sean Leonard Message-ID: <5613890F.9020107@seantek.com> Date: Tue, 6 Oct 2015 01:40:47 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <56136B41.2070304@it.aoyama.ac.jp> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000106060600050704070704" Archived-At: Cc: media-types@iana.org Subject: Re: [apps-discuss] text/nfo draft-01 to -02 feedback, was Re: Volunteer needed for media type ISE review X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 08:41:26 -0000 This is a cryptographically signed message in MIME format. --------------ms000106060600050704070704 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 10/5/2015 11:33 PM, Martin J. D=C3=BCrst wrote: > > > On 2015/10/06 00:40, t.petch wrote: >> ----- Original Message ----- >> From: "Martin J. D=C3=BCrst" >> To: "Sean Leonard" ; "t.petch" >> ; >> Cc: >> Sent: Monday, October 05, 2015 10:10 AM >>> >>> On 2015/10/05 09:52, Sean Leonard wrote: >>>> Hello Tom et. al.: >>> >>>>> s.3.7 this template corresponds to RFC2978 but I note that IANA >> has a >>>>> few extra fields. Doubtless the Expert Reviewer will ask for >> them if >>>>> needed. >>>> >>>> I looked through the IANA registries (note that there are two: the >>>> "charsets" registry and the "character sets" registry), >>> >>> Can you say what you are referring to here? As far as I know, there i= s >>> only one such registry. And as an expert reviewer for that registry, = I >>> guess I should know :-(. >> >> >> charsets is for those not defined in RFC and so not applicable here > > Yes indeed. The registry is at=20 > http://www.iana.org/assignments/character-sets/character-sets.xml. The = > page at http://www.iana.org/assignments/charset-reg/charset-reg.xhtml=20 > isn't a registry, just a list of pointers to registration documents.=20 > The text on the page explains this. In both cases, the page heading=20 > uses the term "Character Set", not "Charset" (I wish it were=20 > otherwise, but that's a separate issue.) Uh, if the text on the page explains this, it is awfully elliptical: True, =20 notes that "The following is the ***list*** of Character Set=20 Registrations not defined in RFCs:" But: =E2=80=A2 It also says "Registration Procedure(s)". =E2=80=A2 The title is "Character Set Registrations". =E2=80=A2 The URL is=20 ,=20 three keywords that would imply a registry. =E2=80=A2 The stylesheet of the page is "=20 type=3D"text/css" /> -- implying a registry. =E2=80=A2 Both pages are listed with equal weight in=20 , which is titled "Protocol Registries".=20 There is no indication on that page that some documents are not actually = registries. Regards, Sean --------------ms000106060600050704070704 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEw MDYwODQwNDdaMC8GCSqGSIb3DQEJBDEiBCCT53lVv2Ma9J3tV1rDtMyLNkvv5MITmeJv3ZW8 dKf6aDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQBgYs/8/1vXB6j/5Lkk cwD2fpeSR+6MTzokco/mzTMvV5nh4vtng2RdZxfcnG5LpH4fE2rPI3r5MRlkVZORqDkNE+t2 CIQnSNrgZoxoueiEranNOEbg9+JzzfaNctTz+7rjz8tKwtQbwgYxiOWc5PZEhNxh/T2a8yHs /uFgnWXvY6En3nT4jFBzVscQ9OIxYiRoZD2NAKLTLxl5HKmNXekp/yK0vztf8shSnjHpGH2+ L9z2Ok7BjyOzMTrUOF01LQUItJOjYUeu5zXGiqjUdQxmRxq04Gfj2b4l0oq1ViWTXXh4UI6a GIHTn14BeN3pNi9k7Rz35P09HXPwvEvIBdPGAAAAAAAA --------------ms000106060600050704070704-- From nobody Wed Oct 7 04:00:44 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031EB1B2DE1 for ; Wed, 7 Oct 2015 04:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 ICDjmnDxe3Q9 for ; Wed, 7 Oct 2015 04:00:40 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C81281B2DDE for ; Wed, 7 Oct 2015 04:00:40 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZjmSd-000CrA-Bt; Wed, 07 Oct 2015 07:00:39 -0400 Date: Wed, 07 Oct 2015 07:00:34 -0400 From: John C Klensin To: apps-discuss@ietf.org Message-ID: <951C96BCC1201DA86241CD4B@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: "A. Rothman" Subject: [apps-discuss] FWD: RFC 2152 - UTF-7 clarification X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 11:00:43 -0000 Hi. As many others presumably noticed, the message below recently appeared on the IETF list. It prompts me to wonder whether, given increasing use of UTF-8, the "EAI" mail extensions for non-ASCII addresses and headers (which require UTF-8), and the observation that UTF-7 has never been a recommended form, it may be time to formally deprecate the thing. That could be done either by moving it to historic or by writing a super-short Applicability Statement that would reclassify it to "Not Recommended". Especially if Amichai is correct and there is an ambiguity in the spec, but even in the interest of reducing the number of forms that appear to be recommended, it seems to me that the right recommendation for email today is: (1) Use UTF-8 (2) If the transport environment is not suitable for 8-bit characters, use Base64 I think experience suggests that Quoted-Printable should probably not be recommended further unless the character repertoire is entirely Latin Script and has a very high ratio of Basic Latin (i.e., ASCII) characters to decorated/ectended ones. Anyone interesting in working on this to the extent needed to push something through? best, john ---------- Forwarded Message ---------- Date: Wednesday, October 07, 2015 11:21 +0300 From: "A. Rothman" To: ietf@ietf.org Subject: RFC 2152 - UTF-7 clarification Hi, I hope this is the right place to discuss RFC 2152 - I couldn't find a conclusive answer as to where and how one should comment on a specific Request For Comments (which is a bit unsettling :-) ) I'd like to raise an issue with the UTF-7 decoding process as described in the RFC with respect to trailing padding bits: "Next, the octet stream is encoded by applying the Base64 content transfer encoding algorithm as defined in RFC 2045, modified to omit the "=" pad character. Instead, when encoding, zero bits are added to pad to a Base64 character boundary. When decoding, any bits at the end of the Modified Base64 sequence that do not constitute a complete 16-bit Unicode character are discarded. If such discarded bits are non-zero the sequence is ill-formed." The way I understand this is that after decoding the modified-base64 data and grouping the resulting octets into 16-bit Unicode characters, any remaining zero bits at the end (up to 15 bits, theoretically) should simply be ignored. I'm not sure why an encoder would want to add extra zero bits at the end beyond the minimum necessary, but it is arguably allowed to pad 'to *a* Base64 character boundary', not specifically *the next* boundary. Perhaps an encoder would use some version of a standard Base64 routine and then replace the padding '=' characters with 'A' characters (which are then decoded to all zero bits). Such encoding would obviously be less space-efficient since it adds unnecessary octets to the encoding - but it seems like there are valid reasons to do so. The issue is with the decoding though, and the reason it came up is that I've checked various existing UTF-7 decoder implementations and resources (e.g. iconv, uconv, icu, jutf7, jcharset, Wikipedia, etc.) and they seem to disagree about this issue. Some generate an error after a maximum number of trailing zero bits (the maximum changes between implementations), and some agree with my interpretation above where any leftover partial group of zero bits is discarded and it's always valid. So, since there is such discrepancy in practice in how this is being interpreted, I submit that the description is not clear enough to make this unambiguous. Could someone please clarify what is officially valid/invalid according to the RFC regarding trailing zero bits? Can we add errata that clarifies it in either case? Finally, if it helps, here are some concrete test cases to consider: +A- +AA- +AAA- +AAAA- +AAAAA- +AAAAAA- +AAAAAAA- Which of these are valid inputs? Which are invalid? How many 0x0000 16-bit characters should each one be decoded into? Thanks! Amichai ---------- End Forwarded Message ---------- From nobody Wed Oct 7 04:08:07 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66BE1B2E00 for ; Wed, 7 Oct 2015 04:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 RgKOZrDTD4gT for ; Wed, 7 Oct 2015 04:08:05 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F50B1B2DF7 for ; Wed, 7 Oct 2015 04:08:05 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:48912) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1ZjmZm-0004zm-py (Exim 4.86_36-e07b163) (return-path ); Wed, 07 Oct 2015 12:08:02 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1ZjmZm-0004l1-24 (Exim 4.72) (return-path ); Wed, 07 Oct 2015 12:08:02 +0100 Date: Wed, 7 Oct 2015 12:08:02 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: John C Klensin In-Reply-To: <951C96BCC1201DA86241CD4B@JcK-HP8200.jck.com> Message-ID: References: <951C96BCC1201DA86241CD4B@JcK-HP8200.jck.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: Cc: "A. Rothman" , apps-discuss@ietf.org Subject: Re: [apps-discuss] FWD: RFC 2152 - UTF-7 clarification X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 11:08:06 -0000 John C Klensin wrote: > > As many others presumably noticed, the message below recently appeared > on the IETF list. It prompts me to wonder whether, given increasing use > of UTF-8, the "EAI" mail extensions for non-ASCII addresses and headers > (which require UTF-8), and the observation that UTF-7 has never been a > recommended form, it may be time to formally deprecate the thing. That > could be done either by moving it to historic or by writing a > super-short Applicability Statement that would reclassify it to "Not > Recommended". UTF-7 is used in modified form for IMAP mailbox names, and RFC 2152 is a normative reference from RFC 3501. So while it probably makes sense to deprecate it for message bodies, it needs to remain as part of IMAP. Tony. -- f.anthony.n.finch http://dotat.at/ Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or moderate, but rough in southwest Viking. Showers later. Good, occasionally poor later. From nobody Wed Oct 7 04:11:11 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F8A1B2E03 for ; Wed, 7 Oct 2015 04:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 lkSR-QrsLvxZ for ; Wed, 7 Oct 2015 04:11:08 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [217.34.220.150]) by ietfa.amsl.com (Postfix) with ESMTP id B6FD81B2DF7 for ; Wed, 7 Oct 2015 04:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1444216266; d=isode.com; s=selector; i=@isode.com; bh=QhYWY123SYfomEve4PJeqAyoI481/jcvuXONnj8qX+w=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Zqld2igNXP/Ahsk0BDLQniWvuN6tX/5p6kAhjW/Iwn7e2rP1a/u1OnJv8C/3FQWbEp/AUG 9XYhodoNw7vb5svplKXApxedWy1x9rT6haVgV4otjhXHu+GqgTKdt5B+pYSzUxBpBRvaWt au/D4POkQkWlI2VudRpnOdtgiERNdQ4=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 7 Oct 2015 12:11:05 +0100 Message-ID: <5614FDB7.5060603@isode.com> Date: Wed, 07 Oct 2015 12:10:47 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 To: Tony Finch , John C Klensin References: <951C96BCC1201DA86241CD4B@JcK-HP8200.jck.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "A. Rothman" , apps-discuss@ietf.org Subject: Re: [apps-discuss] FWD: RFC 2152 - UTF-7 clarification X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 11:11:09 -0000 On 07/10/2015 12:08, Tony Finch wrote: > John C Klensin wrote: >> As many others presumably noticed, the message below recently appeared >> on the IETF list. It prompts me to wonder whether, given increasing use >> of UTF-8, the "EAI" mail extensions for non-ASCII addresses and headers >> (which require UTF-8), and the observation that UTF-7 has never been a >> recommended form, it may be time to formally deprecate the thing. That >> could be done either by moving it to historic or by writing a >> super-short Applicability Statement that would reclassify it to "Not >> Recommended". > UTF-7 is used in modified form for IMAP mailbox names, and RFC 2152 is a > normative reference from RFC 3501. So while it probably makes sense to > deprecate it for message bodies, it needs to remain as part of IMAP. Yes, it needs to remain as part of IMAP in short term, but I can take care of this, as I am revising RFC 3501. From nobody Wed Oct 7 05:07:53 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7990E1B2E88 for ; Wed, 7 Oct 2015 05:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 rdBIe3lPcBoA for ; Wed, 7 Oct 2015 05:07:51 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23A8E1B2E82 for ; Wed, 7 Oct 2015 05:07:51 -0700 (PDT) Received: from [192.71.80.133] (135.217-78-194.adsl-static.isp.belgacom.be [194.78.217.135]) by mail.frobbit.se (Postfix) with ESMTPSA id 4C46F2144F; Wed, 7 Oct 2015 14:07:49 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "John C Klensin" Date: Wed, 07 Oct 2015 14:07:48 +0200 Message-ID: In-Reply-To: <951C96BCC1201DA86241CD4B@JcK-HP8200.jck.com> References: <951C96BCC1201DA86241CD4B@JcK-HP8200.jck.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_822C77CA-C869-43D4-8875-A5E3620BD6BA_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (1.9.2r5141) Archived-At: Cc: "A. Rothman" , apps-discuss@ietf.org Subject: Re: [apps-discuss] RFC 2152 - UTF-7 clarification X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 12:07:52 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_822C77CA-C869-43D4-8875-A5E3620BD6BA_= Content-Type: text/plain On 7 Oct 2015, at 13:00, John C Klensin wrote: > it seems to me > that the right recommendation for email today is: > > (1) Use UTF-8 > (2) If the transport environment is not suitable for 8-bit > characters, use Base64 Yes > I think experience suggests that Quoted-Printable should > probably not be recommended further unless the character > repertoire is entirely Latin Script and has a very high ratio of > Basic Latin (i.e., ASCII) characters to decorated/ectended ones. No reason to really use it then either. Anyone know of software that can do Quoted-Printable and not Base64? Anyone know of people reading (easily) UTF8 encoded with Quoted-Printable? > Anyone interesting in working on this to the extent needed to > push something through? Interested, yes. Time, no. But happy to help pushing. Patrik --=_MailMate_822C77CA-C869-43D4-8875-A5E3620BD6BA_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlYVCxQACgkQrMabGguI181/jwCfXG7eWIrXKf5UGRJHH2HSYodQ 2KMAn2vtvEVhfrRziNdHMAWRvBU5rFq+ =fmCc -----END PGP SIGNATURE----- --=_MailMate_822C77CA-C869-43D4-8875-A5E3620BD6BA_=-- From nobody Wed Oct 7 06:07:38 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B05F1A1A42 for ; Wed, 7 Oct 2015 06:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 Hlq_eYoukJXJ for ; Wed, 7 Oct 2015 06:07:21 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDE931A1A32 for ; Wed, 7 Oct 2015 06:07:21 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZjoR5-000D4A-EB; Wed, 07 Oct 2015 09:07:11 -0400 Date: Wed, 07 Oct 2015 09:07:06 -0400 From: John C Klensin To: Alexey Melnikov , Tony Finch Message-ID: In-Reply-To: <5614FDB7.5060603@isode.com> References: <951C96BCC1201DA86241CD4B@JcK-HP8200.jck.com> <5614FDB7.5060603@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: "A. Rothman" , apps-discuss@ietf.org Subject: Re: [apps-discuss] FWD: RFC 2152 - UTF-7 clarification X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 13:07:23 -0000 --On Wednesday, October 07, 2015 12:10 +0100 Alexey Melnikov wrote: > On 07/10/2015 12:08, Tony Finch wrote: >... >> UTF-7 is used in modified form for IMAP mailbox names, and >> RFC 2152 is a normative reference from RFC 3501. So while it >> probably makes sense to deprecate it for message bodies, it >> needs to remain as part of IMAP. > Yes, it needs to remain as part of IMAP in short term, but I > can take care of this, as I am revising RFC 3501. I had forgotten the IMAP case but, given the mess created by any approach to message header downgrading that the EAI WG was able to come up with (RFCs 6857 and 6858 are "least bad" approaches), it seems to me that we should be pushing IMAP (and POP3) very strongly in the direction of 6855 and 6856 respectively. We should be doing that independent of the implications to UTF-7, but, if it eliminates the need for UTF-7, so much the better. Following the precedent set in 5321 and 5322 and their predecessors, would it make sense to incorporate the core elements of 6855 into 3501bis and then describe the UTF-7 mailbox form as "SHOULD ACCEPT" for servers and "SHOULD NOT SEND" for clients? john From nobody Wed Oct 7 11:55:53 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B95B1AC445 for ; Wed, 7 Oct 2015 11:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 Ehpt_s4LWsUp for ; Wed, 7 Oct 2015 11:55:50 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A521A8A83 for ; Wed, 7 Oct 2015 11:55:50 -0700 (PDT) Received: (qmail 2532 invoked from network); 7 Oct 2015 18:55:49 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 7 Oct 2015 18:55:49 -0000 Date: 7 Oct 2015 18:55:26 -0000 Message-ID: <20151007185526.31392.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [apps-discuss] RFC 2152 - UTF-7 clarification X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 18:55:51 -0000 >Anyone know of people reading (easily) UTF8 encoded with Quoted-Printable? When the UTF-8 is mostly ASCII with the occasional accented latin character or soft space, yes. When the UTF-8 is Chinese, no. R's, John From nobody Thu Oct 8 09:03:06 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134BD1A90CD for ; Thu, 8 Oct 2015 09:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 V4k7HBuj2C4a for ; Thu, 8 Oct 2015 09:03:03 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE77F1A90D1 for ; Thu, 8 Oct 2015 09:03:01 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZkDel-000Fuy-PV; Thu, 08 Oct 2015 12:02:59 -0400 Date: Thu, 08 Oct 2015 12:02:54 -0400 From: John C Klensin To: apps-discuss@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: Marius Georgescu , nalini.elkins@insidethestack.com Subject: [apps-discuss] Replacing the Apps Area meeting X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 16:03:05 -0000 Hi. (copying Naline and Marius because this note was triggered by a discussion about mentoring) Historically the late Apps Area held a Monday morning meeting at IETF that served several purposes in addition to sharing a slot with Apps AWG once that activity got started. One of those purposes was to provide something of a readmap of what was happening during the week, giving people some guidance about how to match their interests to whatever WG and BOF sessions were going on. That particular function may be even more important with the larger and more diverse ART area, especially for relative newcomers who are trying to identify relevant WGs. I note that there does not appear to be any similar session on the preliminary IETF 94 agenda. DISPATCH, scheduled for Wednesday afternoon, presumably serves some of the function of the former area meeting, but does not address others and is too late in the week to be helpful for the role described above. I assume the ADs concluded that time was better spent in other ways than a Monday morning area meeting and am not questioning that decision. However, it seems to me that it would be worthwhile to identify "tracks" or clusters of WGs within the area and/or to get one-paragraph summaries of what each WGs is about and what is expected to be important for the WG at the meeting. That information is not easily extracted, especially by relative newcomers, from either an alphabetical list of WGs and charters (such as the one at http://datatracker.ietf.org/wg/ or from the agenda links that eventually appear on the IETF Agenda page(s) -- a different sort of summary is needed. It seems to me that WG Chairs should be able to produce those summaries -- more or less the same information the former Apps ones were expected to present during the area meeting-- rather easily and that they would have the incentive of broadening participation for doing so. best, john From nobody Thu Oct 15 22:37:04 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E581B2EFB for ; Thu, 15 Oct 2015 22:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_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 KdA1gEDqX2a1 for ; Thu, 15 Oct 2015 22:37:01 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (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 BDDBC1B2EF9 for ; Thu, 15 Oct 2015 22:37:00 -0700 (PDT) Received: by qgeo38 with SMTP id o38so47038667qge.0 for ; Thu, 15 Oct 2015 22:37:00 -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=xE+Sr7Tc1X9jfsIkuCYl7OOfX7PElJtXJKKVgy9g2iA=; b=SCvwDhfc5LhtejrZkme420WwZBheL3y9R3r0pew2Sb4WZyjDcJ8aHgU/D/EkiYFuE3 3/bVLBvy4mPIG14XjqbiXJodvAod/77YS8VNUhttAlA5yAjSbDdfezvFadbI0lNH9CX/ ZqQlhj7FO7BKuese5SPGWUfC+PgGdqioXAaBIIUOzwaAWFT27sV6rV772qgJSVBYvaGw AV/QDvb24r/ajA/Rmh3cg+YBdNKFQ623lSUya/sKGwol4eLjQMM8ZoRiW/s+F30YFwH3 Ismhcf/Tt6PuqLG8xPo5porqx7eTwQY9AV/jsaIjH6C2rDi1c1x15YgY9qKqjU3FdBO2 O+8A== MIME-Version: 1.0 X-Received: by 10.140.202.204 with SMTP id x195mr16724943qha.7.1444973819836; Thu, 15 Oct 2015 22:36:59 -0700 (PDT) Received: by 10.55.207.148 with HTTP; Thu, 15 Oct 2015 22:36:59 -0700 (PDT) Date: Thu, 15 Oct 2015 22:36:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a1140dd0a3dbeff0522322fc9 Archived-At: Subject: [apps-discuss] Proposed APPSAWG/DISPATCH charter revision X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 05:37:03 -0000 --001a1140dd0a3dbeff0522322fc9 Content-Type: text/plain; charset=UTF-8 Colleagues, As we've been discussing over the last several months, the RAI and APP areas have merged into a single area known as ART. We have also been discussing a merger between APPSAWG, the general APP working group, and DISPATCH, which does a similar function for the RAI work. The main difference between the two is that APPSAWG is currently chartered to take up work items that are thought to be too small to warrant a dedicated working group yet don't merit AD sponsorship, while DISPATCH merely evaluates proposed work and routes it toward the path best suited to its development. As has also been discussed, the current APPSAWG model isn't providing what we had hoped. This has been in no small part because it has been challenging to secure enough dedicated experts to review documents such that our work product is of consistently high quality. Below is a proposed charter for a merger between DISPATCH and APPSAWG. The intent is to call the merged working group DISPATCH. Generally speaking it will follow the largely successful DISPATCH model, with the stipulation that it can take on documents for direct handling only when approved by an AD, and this will normally be limited to housekeeping items such as simple IANA actions or document state changes. It will not do any direct technical development work of any kind. We welcome comments on the proposed charter on this list or the DISPATCH list. Note that APPSAWG will not meet at IETF 94 next month. We are aware that people like our usual Monday morning slot and especially find the BoF and New WG overviews valuable, and currently expect that will resume at IETF 95. We are considering having two DISPATCH sessions at future meetings, one during that slot that provides those overviews, and serves as the ART general meeting, while the other would cover the actual DISPATCH work. -MSK, APPSAWG (and soon to be DISPATCH) co-chair # Draft Charter for Dispatch Working Group The Dispatch working group is chartered to consider proposals for new work in the ART area and identify, or help create, an appropriate venue for the work. Guiding principles for the proposed new work include: 1. Providing a clear problem statement, motivation and deliverables for the proposed new work. 2. Ensuring there has been adequate mailing list discussion reflecting sufficient interest, individuals have expressed a willingness to contribute and there is WG consensus before new work is dispatched. 3. Looking for and identifying commonalities and overlap amongst published or ongoing protocol work. Such commonalities may indicate the possibility of reusing existing protocols or elements thereof published by other WGs, or expanding and/or refactoring the scope of deliverables in an active WG. 4. Protecting the architectural integrity of IETF protocols and ensuring that new work has general applicability. 5. Ensuring the new work considers the impact on security and privacy of both the network and the user. Options for handling new work include: - Directing the work to an existing WG. - Developing a proposal for a BOF. - Developing a charter for a new WG. - Making recommendations that documents be AD-sponsored (which ADs may or may not choose to follow). - By agreement with ART ADs, processing simple documents. - Deferring the decision for the new work. - Rejecting the new work. If the group decides that a particular topic needs to be addressed by a new WG, the normal IETF chartering process will be followed, including, for instance, IETF-wide review of the proposed charter. Proposals for large work efforts SHOULD lead to a BOF where the topic can be discussed in front of the entire IETF community. The DISPATCH WG will not do any protocol work. Specifically, DISPATCH will always opt to find a location for technical work; the only work that DISPATCH is not required to delegate (or defer, or reject) is administrative work such as IANA actions. Documents progressed as AD-sponsored would typically include those that do not have general applicability to IETF protocols, but rather are only applicable to specific use cases and network deployments, for which the scope must be clearly specified. Proposed new work may be deferred in cases where the WG does not have enough information for the chairs to determine consensus. New work may be rejected in cases where there is not sufficient WG interest or the proposal has been considered and rejected in the past, unless a substantially revised proposal is put forth, including compelling new reasons for accepting the work. A major objective of the DISPATCH WG is to provide timely, clear dispositions of new efforts. Thus, where there is consensus to take on new work, the WG will strive to quickly find a home for it. --001a1140dd0a3dbeff0522322fc9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

As = we've been discussing over the last several months, the RAI and APP are= as have merged into a single area known as ART.

We have also been di= scussing a merger between APPSAWG, the general APP working group, and DISPA= TCH, which does a similar function for the RAI work.=C2=A0 The main differe= nce between the two is that APPSAWG is currently chartered to take up work = items that are thought to be too small to warrant a dedicated working group= yet don't merit AD sponsorship, while DISPATCH merely evaluates propos= ed work and routes it toward the path best suited to its development.
As has also been discussed, the current APPSAWG model isn't pro= viding what we had hoped.=C2=A0 This has been in no small part because it h= as been challenging to secure enough dedicated experts to review documents = such that our work product is of consistently high quality.

Be= low is a proposed charter for a merger between DISPATCH and APPSAWG.=C2=A0 = The intent is to call the merged working group DISPATCH.=C2=A0 Generally sp= eaking it will follow the largely successful DISPATCH model, with the stipu= lation that it can take on documents for direct handling only when approved= by an AD, and this will normally be limited to housekeeping items such as = simple IANA actions or document state changes.=C2=A0 It will not do any dir= ect technical development work of any kind.

We welcome comment= s on the proposed charter on this list or the DISPATCH list.

N= ote that APPSAWG will not meet at IETF 94 next month.=C2=A0 We are aware th= at people like our usual Monday morning slot and especially find the BoF an= d New WG overviews valuable, and currently expect that will resume at IETF = 95.=C2=A0 We are considering having two DISPATCH sessions at future meeting= s, one during that slot that provides those overviews, and serves as the AR= T general meeting, while the other would cover the actual DISPATCH work.
-MSK, APPSAWG (and soon to be DISPATCH) co-chair

# Draft Charter for Dispatch Working Group

The Dispatch working group is chartered to consider proposals for new
work in the ART area and identify, or help create, an appropriate venue
for the work.

Guiding principles for the proposed new work include:

1. Providing a clear problem statement, motivation and deliverables for
   the proposed new work.

2. Ensuring there has been adequate mailing list discussion reflecting
   sufficient interest, individuals have expressed a willingness to
   contribute and there is WG consensus before new work is dispatched.

3. Looking for and identifying commonalities and overlap amongst
   published or ongoing protocol work. Such commonalities may indicate
   the possibility of reusing existing protocols or elements thereof
   published by other WGs, or expanding and/or refactoring the scope of
   deliverables in an active WG.

4. Protecting the architectural integrity of IETF protocols and ensuring
   that new work has general applicability.

5. Ensuring the new work considers the impact on security and privacy of
   both the network and the user.

Options for handling new work include:

- Directing the work to an existing WG.
- Developing a proposal for a BOF.
- Developing a charter for a new WG.
- Making recommendations that documents be AD-sponsored
  (which ADs may or may not choose to follow).
- By agreement with ART ADs, processing simple documents.
- Deferring the decision for the new work.
- Rejecting the new work.

If the group decides that a particular topic needs to be addressed by a
new WG, the normal IETF chartering process will be followed, including,
for instance, IETF-wide review of the proposed charter. Proposals for
large work efforts SHOULD lead to a BOF where the topic can be discussed
in front of the entire IETF community. The DISPATCH WG will not do any
protocol work. Specifically, DISPATCH will always opt to find a location
for technical work; the only work that DISPATCH is not required to
delegate (or defer, or reject) is administrative work such as IANA
actions. Documents progressed as AD-sponsored would typically include
those that do not have general applicability to IETF protocols, but
rather are only applicable to specific use cases and network
deployments, for which the scope must be clearly specified.

Proposed new work may be deferred in cases where the WG does not have
enough information for the chairs to determine consensus. New work may
be rejected in cases where there is not sufficient WG interest or the
proposal has been considered and rejected in the past, unless a
substantially revised proposal is put forth, including compelling new
reasons for accepting the work.

A major objective of the DISPATCH WG is to provide timely, clear
dispositions of new efforts. Thus, where there is consensus to take on
new work, the WG will strive to quickly find a home for it.


--001a1140dd0a3dbeff0522322fc9-- From nobody Sat Oct 17 21:31:08 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEAE1A90D7; Sat, 17 Oct 2015 21:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 fLqY1w1GSuIQ; Sat, 17 Oct 2015 21:31:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E46C1AC3EE; Sat, 17 Oct 2015 21:31:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151018043103.24530.29980.idtracker@ietfa.amsl.com> Date: Sat, 17 Oct 2015 21:31:03 -0700 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-12.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 04:31:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ART Area General Applications Working Group Working Group of the IETF. Title : The text/markdown Media Type Author : Sean Leonard Filename : draft-ietf-appsawg-text-markdown-12.txt Pages : 15 Date : 2015-10-17 Abstract: This document registers the text/markdown media type for use with Markdown, a family of plain text formatting syntaxes that optionally can be converted to formal markup languages such as HTML. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-text-markdown-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 19 04:36:22 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14021A8AC9 for ; Mon, 19 Oct 2015 04:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 2-d7PA95CpKA for ; Mon, 19 Oct 2015 04:36:19 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7E10C1A8AC8 for ; Mon, 19 Oct 2015 04:36:19 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3A41618020A; Mon, 19 Oct 2015 04:35:51 -0700 (PDT) To: andreas@sbin.se, nilsson@opera.com, barryleiba@computer.org, superuser@gmail.com, alexey.melnikov@isode.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20151019113551.3A41618020A@rfc-editor.org> Date: Mon, 19 Oct 2015 04:35:51 -0700 (PDT) Archived-At: Cc: luke.blaney@ft.com, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] [Editorial Errata Reported] RFC7239 (4506) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 11:36:20 -0000 The following errata report has been submitted for RFC7239, "Forwarded HTTP Extension". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7239&eid=4506 -------------------------------------- Type: Editorial Reported by: Luke Blaney Section: 3 Original Text ------------- Section 7 of [RFC7230] Corrected Text -------------- Section 7 of [RFC7230] Notes ----- The link for Section 7 in the html and pdf versions of the RFC is an internal link for the same page, so ends up at section 7 of RFC7239. It should link to section 7 of RFC7230. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7239 (draft-ietf-appsawg-http-forwarded-10) -------------------------------------- Title : Forwarded HTTP Extension Publication Date : June 2014 Author(s) : A. Petersson, M. Nilsson Category : PROPOSED STANDARD Source : Applications Area Working Group APP Area : Applications Stream : IETF Verifying Party : IESG From nobody Mon Oct 19 09:31:10 2015 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5741A8909; Mon, 19 Oct 2015 09:31:04 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019163104.24717.28275.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 09:31:04 -0700 Archived-At: Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown@ietf.org, The IESG , barryleiba@gmail.com, rfc-editor@rfc-editor.org Subject: [apps-discuss] Document Action: 'The text/markdown Media Type' to Informational RFC (draft-ietf-appsawg-text-markdown-12.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 16:31:05 -0000 The IESG has approved the following document: - 'The text/markdown Media Type' (draft-ietf-appsawg-text-markdown-12.txt) as Informational RFC This document is the product of the ART Area General Applications Working Group. The IESG contact persons are Ben Campbell, Barry Leiba and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ Technical Summary This document registers the text/markdown media type for use with Markdown, a family of plain text formatting syntaxes that optionally can be converted to formal markup languages such as HTML. The working group has selected Informational status since the markdown syntax was specified outside of the IETF, and RFC6838 does not require Standards Track status for a document from the IETF stream registering a media type. Review and Consensus The document had fairly active review within APPSAWG at first, but suffered from some attrition along the way. Feedback ranged from "Why does the IETF need to do this?" to whether the entire work (this plus the use-cases document) should appear in a single document or in separate documents. For the latter question, the split was done; for the former, there are still one or two participants who are unclear whether this media type or the registries created here will ever be used by someone other than the author. The author and chairs were implored to be sensitive to the markdown community, which is external to the IETF. The document shepherd is satisfied that this was done as much as practical. The author asserts that he and others have already begun to use the media type in prototype form within open source and commercial products. Personnel Murray Kucherawy is the document shepherd. Barry Leiba is the responsible Area Director. From nobody Mon Oct 19 09:57:07 2015 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 155301A8AB9; Mon, 19 Oct 2015 09:57:07 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019165707.31607.87171.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 09:57:07 -0700 Archived-At: Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown-use-cases@ietf.org, The IESG , barryleiba@gmail.com, rfc-editor@rfc-editor.org Subject: [apps-discuss] Document Action: 'Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations' to Informational RFC (draft-ietf-appsawg-text-markdown-use-cases-07.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 16:57:07 -0000 The IESG has approved the following document: - 'Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations' (draft-ietf-appsawg-text-markdown-use-cases-07.txt) as Informational RFC This document is the product of the ART Area General Applications Working Group. The IESG contact persons are Ben Campbell, Barry Leiba and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown-use-cases/ Technical Summary This document elaborates upon the text/markdown media type for use with Markdown, a family of plain text formatting syntaxes that optionally can be converted to formal markup languages such as HTML. Background information, local storage strategies, and additional syntax registrations are supplied. The WG is requesting Informational status for this document. The main work of specifying Markdown syntax variants is done outside of the IETF. This document, which was split off from draft-ietf-appsawg-text-markdown, consists mainly of brief descriptions and references for several Markdown variants, and presents IANA registrations for them. Review and Consensus This document was spun off from the above-named draft to try to keep the other one shorter. They each received the same amount of attention and criticism. The author asserts that he and others have already begun to use the media type in prototype form within open source and commercial products. Personnel Murray Kucherawy is the document shepherd. Barry Leiba is the responsible Area Director. From nobody Mon Oct 19 12:38:03 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6821ACEA2 for ; Mon, 19 Oct 2015 12:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 QQDpJ4yk315w for ; Mon, 19 Oct 2015 12:37:44 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE001ACE91 for ; Mon, 19 Oct 2015 12:37:40 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1689E18046F; Mon, 19 Oct 2015 12:37:12 -0700 (PDT) To: andreas@sbin.se X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20151019193712.1689E18046F@rfc-editor.org> Date: Mon, 19 Oct 2015 12:37:12 -0700 (PDT) Archived-At: Cc: luke.blaney@ft.com, apps-discuss@ietf.org, nilsson@opera.com, Barry Leiba , RFC Editor Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC7239 (4506) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 19:37:46 -0000 FYI, this report has been removed. As noted on https://www.rfc-editor.org/errata.php, the errata system is for the documents available from rfc-editor.org. Thank you. RFC Editor/ar On Oct 19, 2015, at 4:35 AM, RFC Errata System wrote: The following errata report has been submitted for RFC7239, "Forwarded HTTP Extension". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7239&eid=4506 -------------------------------------- Type: Editorial Reported by: Luke Blaney Section: 3 Original Text ------------- Section 7 of [RFC7230] Corrected Text -------------- Section 7 of [RFC7230] Notes ----- The link for Section 7 in the html and pdf versions of the RFC is an internal link for the same page, so ends up at section 7 of RFC7239. It should link to section 7 of RFC7230. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7239 (draft-ietf-appsawg-http-forwarded-10) -------------------------------------- Title : Forwarded HTTP Extension Publication Date : June 2014 Author(s) : A. Petersson, M. Nilsson Category : PROPOSED STANDARD Source : Applications Area Working Group APP Area : Applications Stream : IETF Verifying Party : IESG From nobody Wed Oct 21 10:42:29 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424181AC3C6; Wed, 21 Oct 2015 10:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 bJex0SiMa0HJ; Wed, 21 Oct 2015 10:42:25 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6501C1A9138; Wed, 21 Oct 2015 10:42:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14249; q=dns/txt; s=iport; t=1445449346; x=1446658946; h=from:subject:to:message-id:date:mime-version; bh=t/4/qnStXkXHaQ4XWVjDgnn7S7inFXae+14OvsBRfA0=; b=IZjlPKZ3aXfAkCg3Zpwg66THk7r7s2T7y7hp+N5KhbyMJ1oSYGHAXqNq kElJFjd0uGozBD+Z7Vjw+2sBDGgLRUiyK7uIj/IT7LP04V9OmZKGmVB8T Rr+/6pg16BctR3dpwnuBf5wyGycfa1JQFHHUm+9bIlfyJhvCthpeXoSPg A=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CpBAA5zidW/xbLJq1dhApvv3gjhXqCBBEBAQEBAQEBgQqEMAQkVQYoAg0WCwILAwIBAgE3FAEMCAEBF4gNCA0DsUWSdwEBAQcBAQEBARUJkCpHgwGBRQWSW4NMgk6BYWqIBYFYSIN3gwGPGoNwNyyCDHgBgQA8NYR6gUgBAQE X-IronPort-AV: E=Sophos;i="5.20,178,1444694400"; d="asc'?scan'208,217";a="630430122" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 21 Oct 2015 17:42:23 +0000 Received: from [10.61.223.45] ([10.61.223.45]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t9LHgLis032379; Wed, 21 Oct 2015 17:42:21 GMT From: Eliot Lear X-Enigmail-Draft-Status: N1110 To: draft-ietf-tsvwg-circuit-breaker.all@ietf.org, "apps-discuss@ietf.org" , tsvwg , "'IESG'" Message-ID: <5627CE7C.7080102@cisco.com> Date: Wed, 21 Oct 2015 19:42:20 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Q0BRio3DeD9u5r8W35GJ9SD08LE514u3t" Archived-At: Subject: [apps-discuss] apps directorate review of draft-ietf-tsvwg-circuit-breaker-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 17:42:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Q0BRio3DeD9u5r8W35GJ9SD08LE514u3t Content-Type: multipart/alternative; boundary="------------000401000800080007040906" This is a multi-part message in MIME format. --------------000401000800080007040906 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Greetings Gory! I have been selected (by me) as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see =E2=80=8B http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate= ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your WG chairman(s) before posting a new version of the draft. Document: draft-ietf-tsvwg-circuit-breaker-07 Title: Network Transport Circuit Breakers Reviewer: Eliot Lear Review Date: 21 October 2015 IETF Last Call Date: not yet IESG Telechat Date: not yet Summary: Nice draft. Needs a little bit of work still. Comments: This draft provides very useful guidance about how circuit breakers should behave. There are some aspects that can be expanded, and the draft highlights a gap in the Internet architecture (see Major Issues), which perhaps should be noted. While this review is somewhat long, I want to stress that most of the issues can be addressed with relatively small changes. Major Issues: High level issue: the document should make clearer just how anomalous these events are expected to be. At one point the author states that this should be treated as an abnormal network event, and elsewhere that operator intervention will normally be needed to reset a breaker, but then automated processes are discussed. Perhaps my confusion could be solved with some additional text in section 1 near this text: These measurements need to be taken over a reasonably long period of time.=20 Is it worth mentioning what "reasonably long" means at this point?=20 Above you talk about RTTs. There's not a direct comparison in the introduction, which would be useful. Another way to put this question: when a circuit breaker trips, does it indicate that there a network configuration error? The document makes clear that circuit ingress routers SHOULD log when the circuit breaker is tripped. Unfortunately this may not be sufficient to avoid the principle of least astonishment with regard to application owners and users. This can occur in two different ways: applications are using excessive amounts of bandwidth either because they are misbehaving or there is more used than planned, or because the circuit breaker is broken. In either case, the application may perform poorly once the circuit breaker is tripped. The support path between a slow trip or managed circuit breaker and the application can be quite long. It is even conceivable for a fast trip circuit breaker to not be implemented within an application but outside by the O/S. One or more signaling methods to the application would be ideal in these circumstances, but they have to be trusted. I do not think this draft needs to specify a solution here, but it should state the problem. There is what I would call a very high level discussion about length of time a circuit breaker is tripped. Additional detail would be helpful.=20 The length of time a circuit breaker is active will have some bearing.=20 A very short lived circuit breaker would be very hard for a network administrator or system administrator to detect. A long lived circuit breaker might live well after its usefulness. And so there is a tradeoff involving excessive policing and the principle of least astonishment, and an elaboration about this would be useful. As a security consideration, is it possible for some circuit breakers to be triggered intentionally by attackers, thus harming certain traffic? Section 3.1: It seems to me that there is additional text needed in Step 5 relating to the trigger function as to when to terminate the circuit breaker, even if it's manual. Minor Issues: Question about the following text in Section 1: > The goal is usually to limit the > maximum transmission rate to a rate that reflects the available > capacity across a network path. Does fairness come into play here? The idea of the "gentleman's agreement" is that circuit breakers not be needed when people are backing off in a way that is generally agreed to be fair. > This includes traffic sent using a network tunnel. > Designers of other protocols and tunnel encapsulations also ought to= > consider the use of these techniques to provide last resort to > protect traffic that shares the network path being used. This sentence isn't terribly clear, and doesn't seem grammatically correct. A last resort to protect against what? And what precisely is being protected? I ask because some confusion sets in around this point. Are we protecting the rest of the network from non-congestion-controlled traffic? Are we protecting that the non-congestion-controlled traffic itself? I think it's the former, but this makes it sound like the latter. Nits: Section 3.1: > 6. A reaction that is applied that the Ingress when the Circuit > Breaker is triggered.=20 s/applied that/applied at/ Eliot --------------000401000800080007040906 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Greetings Gory!

I have been selected (by me) as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see =E2=80=8Bhttp://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAr= eaDirectorate ).

Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your WG chairman(s) before posting a new version of the draft.

Document: draft-ietf-tsvwg-circuit-breaker-07
Title: Network Transport Circuit Breakers
Reviewer: Eliot Lear
Review Date: 21 October 2015
IETF Last Call Date: not yet
IESG Telechat Date: not yet

Summary: Nice draft. Needs a little bit of work still.

Comments:

This draft provides very useful guidance about how circuit breakers should behave.=C2=A0 There are some aspects that can be expanded, and the draft highlights a gap in the Internet architecture (see Major Issues), which perhaps should be noted.=C2=A0= While this review is somewhat long, I want to stress that most of the issues can be addressed with relatively small changes.

Major Issues:

High level issue: the document should make clearer just how anomalous these events are expected to be.=C2=A0 At one point the author states that this should be treated as an abnormal network event, and elsewhere that operator intervention will normally be needed to reset a breaker, but then automated processes are discussed.=C2=A0 Perhaps my confusion could be solved with some additional text in section 1 near this text:

   These measurements
   need to be taken over a reasonably long period of time.

Is it worth mentioning what "reasonably long" means at this point?=C2= =A0 Above you talk about RTTs.=C2=A0 There's not a direct comparison in t= he introduction, which would be useful.

Another way to put this question: when a circuit breaker trips, does it indicate that there a network configuration error?

The document makes clear that circuit ingress routers SHOULD log when the circuit breaker is tripped.=C2=A0 Unfortunately this may n= ot be sufficient to avoid the principle of least astonishment with regard to application owners and users.=C2=A0 This can occur in two= different ways: applications are using excessive amounts of bandwidth either because they are misbehaving or there is more used than planned, or because the circuit breaker is broken.=C2=A0 = In either case, the application may perform poorly once the circuit breaker is tripped.=C2=A0 The support path between a slow trip or managed circuit breaker and the application can be quite long.=C2=A0= It is even conceivable for a fast trip circuit breaker to not be implemented within an application but outside by the O/S.=C2=A0 One= or more signaling methods to the application would be ideal in these circumstances, but they have to be trusted.=C2=A0 I do not think th= is draft needs to specify a solution here, but it should state the problem.

There is what I would call a very high level discussion about length of time a circuit breaker is tripped.=C2=A0 Additional detail would b= e helpful.=C2=A0 The length of time a circuit breaker is active will ha= ve some bearing.=C2=A0 A very short lived circuit breaker would be very = hard for a network administrator or system administrator to detect.=C2=A0 = A long lived circuit breaker might live well after its usefulness.=C2=A0= And so there is a tradeoff involving excessive policing and the principle of least astonishment, and an elaboration about this would be useful.

As a security consideration, is it possible for some circuit breakers to be triggered intentionally by attackers, thus harming certain traffic?

Section 3.1:

It seems to me that there is additional text needed in Step 5 relating to the trigger function as to when to terminate the circuit breaker, even if it's manual.

Minor Issues:

Question about the following text in Section 1:

   The goal is usually to limit the
   maximum transmission rate to a rate that reflects the available
   capacity across a network path.

Does fairness come into play here?=C2=A0 The idea of the "gentleman= 's agreement" is that circuit breakers not be needed when people are backing off in a way that is generally agreed to be fair.


   This includes traffic sent using a netw=
ork tunnel.
   Designers of other protocols and tunnel encapsulations also ought to
   consider the use of these techniques to provide last resort to
   protect traffic that shares the network path being used.

This sentence isn't terribly clear, and doesn't seem grammatically correct.=C2=A0 A last resort to protect against what?= =C2=A0 And what precisely is being protected?=C2=A0 I ask because some confusion sets in around this point.=C2=A0 Are we protecting the re= st of the network from non-congestion-controlled traffic?=C2=A0 Are we= protecting that the non-congestion-controlled traffic itself?=C2=A0= I think it's the former, but this makes it sound like the latter.
=

Nits:

Section 3.1:

   6.  A reaction that is applied that the=
 Ingress when the Circuit
       Breaker is triggered.=20
s/applied that/applied at/

Eliot

--------------000401000800080007040906-- --Q0BRio3DeD9u5r8W35GJ9SD08LE514u3t 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 iQEcBAEBCAAGBQJWJ858AAoJEIe2a0bZ0nozj0QH/30EjLwt+YuVOSe3yX0yL4XI qBaADJkrGoj0DXB2nWsF+h/IYBIh92h8rm+eKfz3mUlK5NyLe+R8RbBh6raee3PA Jkpr1ApDWWsYOneMJRlJhYmRz0kOWag7ldBKOZvHVtTcqHMx9hPAxi7W0zWftZ82 +aeviHyIJGhvH/ApwxkziP/N7M42xV/hufKqDaceYF/R3slqLQY0eRCdla9Xd1jD QRGN1BUFkajtPHayeFu+rx3LGM3OOsJS15oGqIeGhmbW6XcBmKG04XXTWySNXVFQ cvFtlVa4B2BLR3RhqQdKqc0JQaHenCrJH/yglpTIT5j8HYiUyPMh22kh6bS/urk= =pVVX -----END PGP SIGNATURE----- --Q0BRio3DeD9u5r8W35GJ9SD08LE514u3t--