From nobody Thu Dec 8 09:35:12 2016 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF926129AA2 for ; Thu, 8 Dec 2016 09:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 AW-N_XkehnWe for ; Thu, 8 Dec 2016 09:35:08 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 158CD129A2E for ; Thu, 8 Dec 2016 09:35:07 -0800 (PST) Received: from 30-9-49.wireless.csail.mit.edu ([128.30.9.49]) by raoul.w3.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1cF2b4-0004d7-Ax for media-types@ietf.org; Thu, 08 Dec 2016 17:35:06 +0000 Content-Type: multipart/alternative; boundary="----=_NextPart_63547033.204529747099" MIME-Version: 1.0 Date: Thu, 08 Dec 2016 12:34:59 -0500 Message-ID: From: "Chris Lilley" To: "" User-Agent: Mailbird/2.3.36.0 X-Mailbird-ID: e25a4143-7999-4ed0-9947-776033636f15@getmailbird.com Archived-At: Subject: [media-types] Macintosh file type code X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 17:35:11 -0000 ------=_NextPart_63547033.204529747099 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable It is not clear to me what, in a Media Type registration, the "Macintosh fi= le type code" is for, or what the allowed range of tokens is, or whether an= yone checks this information or uses it in any way. It seems that this code is for use on Mac OS 9 or earlier, i.e. pre-OS X.= =C2=A0 Apple seems to have replaced this with "Uniform Type Identifiers". https://developer.apple.com/library/content/documentation/FileManagement/Co= nceptual/understanding_utis/understand_utis_intro/understand_utis_intro.html and says that there are various legacy sources of it=C2=A0 - the four character codes (Macintosh file type code) - filename extensions - "MIME types" (sic) and that Uniform Type Identifiers "replaces all these incompatible tagging = methods with the string ..." There seems to be a registry of System-Declared UTIs https://developer.apple.com/library/content/documentation/Miscellaneous/Ref= erence/UTIRef/Articles/System-DeclaredUniformTypeIdentifiers.html#//apple_r= ef/doc/uid/TP40009259-SW1 RFC6833, section 4.12 Additional Information has a reference to MacOSFileTy= pes [MacOSFileTypes] Apple Computer, Inc., "Mac OS: File Type and Creator Codes= , and File Formats", Apple Knowledge Base Article 55381, June 1993, . and the link has rotted. On to my actual questions: 1) Is there continuing value in providing this data in a Meda Type registra= tion, given that it does not seem to be used by current Apple products and = has been replaced, as far as Apple is concerned, by UTIs? I see some registrations say 'none' as the value. It seems better to me to = just remove this field from the template. 2) Is there value in adding the Apple UTI (which is at least documented, an= d in current use) to the registration templates?=C2=A0 My reason for asking is=C2=A0draft-ietf-justfont-toplevel https://datatracker.ietf.org/doc/draft-ietf-justfont-toplevel/ which will define a new top-level Media Type for fonts. I am very tempted t= o just remove the "Macintosh file type code" from the registration template= , and could go either way on replacing it with an "Apple Uniform Type Ident= ifier" field - opinions welcome. Raisng on this list since it affects all other registration templates as we= ll. -- Chris Lilley @svgeesus Technical Director @ W3C W3C Strategy Team, Core Web Design W3C Architecture & Technology Team, Core Web & Media ------=_NextPart_63547033.204529747099 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
It is not clear to me what, in a Media Type registratio= n, the "Macintosh file type code" is for, or what the allowed range of toke= ns is, or whether anyone checks this information or uses it in any way.
It seems that this code is for use on Mac OS 9 or earlier, = i.e. pre-OS X. 

Apple seems to have replaced = this with "Uniform Type Identifiers".
https://developer.apple.com= /library/content/documentation/FileManagement/Conceptual/understanding_utis= /understand_utis_intro/understand_utis_intro.html
and says that t= here are various legacy sources of it 
- the four character = codes (Macintosh file type code)
- filename extensions
= - "MIME types" (sic)
and that Uniform Type Identifiers "replaces = all these incompatible tagging methods with the string ..."

<= /div>
There seems to be a registry of System-Declared UTIs
ht= tps://developer.apple.com/library/content/documentation/Miscellaneous/Refer= ence/UTIRef/Articles/System-DeclaredUniformTypeIdentifiers.html#//apple_ref= /doc/uid/TP40009259-SW1

RFC6833, section 4.12 Additi= onal Information has a reference to MacOSFileTypes

   [MacOSFileTypes]  Apple Computer, Inc., "Mac OS: File Type and=
=0A                     Creator Codes, and File Formats", Apple Knowledge=
=0A                     Base Article 55381, June 1993,=0A                  =
   <http://www.info.a=
pple.com/kbnum/n55381>.

and the link = has rotted.

On to my actual questions:
<= br>
1) Is there continuing value in providing this data in a Meda= Type registration, given that it does not seem to be used by current Apple= products and has been replaced, as far as Apple is concerned, by UTIs?

I see some registrations say 'none' as the value. It = seems better to me to just remove this field from the template.
<= br>
2) Is there value in adding the Apple UTI (which is at least = documented, and in current use) to the registration templates? 
<= div>
My reason for asking is draft-ietf-justfont-toplevel
https:/= /datatracker.ietf.org/doc/draft-ietf-justfont-toplevel/

which will define a new top-level Media Type for fonts. I am very tem= pted to just remove the "Macintosh file type code" from the registration te= mplate, and could go either way on replacing it with an "Apple Uniform Type= Identifier" field - opinions welcome.

Raisng on t= his list since it affects all other registration templates as well.

--
Chris Lilley
@svgeesus
Technical Director @ W3C
W3C Strategy Team, Core Web Des= ign
W3C Architecture & Technology Team, Core Web & Media<= /div>
------=_NextPart_63547033.204529747099-- From nobody Thu Dec 8 10:06:18 2016 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44AAC12950D for ; Thu, 8 Dec 2016 10:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 QQY0WlV3GcZS for ; Thu, 8 Dec 2016 10:06:14 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 A846A129493 for ; Thu, 8 Dec 2016 10:06:14 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q88GLXXLG0018OD5@mauve.mrochek.com> for media-types@ietf.org; Thu, 8 Dec 2016 10:01:13 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q7RKQ1HV28011H9Q@mauve.mrochek.com>; Thu, 08 Dec 2016 10:01:06 -0800 (PST) Message-id: <01Q88GLSKJC4011H9Q@mauve.mrochek.com> Date: Thu, 08 Dec 2016 09:58:29 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 08 Dec 2016 12:34:59 -0500" References: To: Chris Lilley Archived-At: Cc: media-types@ietf.org Subject: Re: [media-types] Macintosh file type code X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 18:06:16 -0000 > It is not clear to me what, in a Media Type registration, the "Macintosh file > type code" is for, or what the allowed range of tokens is, or whether anyone > checks this information or uses it in any way. It's pretty much obsolete. We retained it on the last update mostly because old registrations had it. > It seems that this code is for use on Mac OS 9 or earlier, i.e. pre-OS X.  Exactly. > Apple seems to have replaced this with "Uniform Type Identifiers". > https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/understanding_utis/understand_utis_intro/understand_utis_intro.html > and says that there are various legacy sources of it  > - the four character codes (Macintosh file type code) > - filename extensions > - "MIME types" (sic) > and that Uniform Type Identifiers "replaces all these incompatible tagging methods with the string ..." > There seems to be a registry of System-Declared UTIs > https://developer.apple.com/library/content/documentation/Miscellaneous/Reference/UTIRef/Articles/System-DeclaredUniformTypeIdentifiers.html#//apple_ref/doc/uid/TP40009259-SW1 > RFC6833, section 4.12 Additional Information has a reference to MacOSFileTypes > [MacOSFileTypes] Apple Computer, Inc., "Mac OS: File Type and Creator Codes, and File Formats", Apple Knowledge Base Article 55381, June 1993, . > and the link has rotted. > On to my actual questions: > 1) Is there continuing value in providing this data in a Meda Type > registration, given that it does not seem to be used by current Apple products > and has been replaced, as far as Apple is concerned, by UTIs? Very little. > I see some registrations say 'none' as the value. It seems better to me to > just remove this field from the template. Or leave it blank. > 2) Is there value in adding the Apple UTI (which is at least documented, and > in current use) to the registration templates?  Not that I'm aware of, but more information can't hurt. > My reason for asking is draft-ietf-justfont-toplevel > https://datatracker.ietf.org/doc/draft-ietf-justfont-toplevel/ > which will define a new top-level Media Type for fonts. I am very tempted to > just remove the "Macintosh file type code" from the registration template, and > could go either way on replacing it with an "Apple Uniform Type Identifier" > field - opinions welcome. Either way works. Ned From nobody Thu Dec 8 14:21:42 2016 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A69129B93 for ; Thu, 8 Dec 2016 14:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=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 CHPDdwGWiCXt for ; Thu, 8 Dec 2016 14:21:35 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (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 1A8D5129BAA for ; Thu, 8 Dec 2016 14:18:03 -0800 (PST) Received: from jordan.fritz.box ([93.222.244.228]) by mrelayeu.kundenserver.de (mreue102 [212.227.15.183]) with ESMTPSA (Nemesis) id 0Lto5V-1cgA3Y1m8z-011EIS; Thu, 08 Dec 2016 23:17:53 +0100 Content-Type: multipart/signed; boundary="Apple-Mail=_595B46BF-2C2C-4A62-9F1D-BA31E8F63B66"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Paul Libbrecht In-Reply-To: <01Q88GLSKJC4011H9Q@mauve.mrochek.com> Date: Thu, 8 Dec 2016 23:17:44 +0100 Message-Id: <44F6AEF0-8A25-4981-8620-293FD5907483@hoplahup.net> References: <01Q88GLSKJC4011H9Q@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.3124) X-Provags-ID: V03:K0:XeLGVGUEmgFEsMZ2gTFqv0Nl0F2BCee/akmIWb/ELt+4rFGSdGM RamqDFYF8fS5uSF0ktEr+bq9S/mfLigGBlVFpAQUsLsqSHTUUEt+3FsRt7mXTZZY7/2SMFv ilUNKoo7RBnmUvWW8RhlzrYvIVtvPpb8hDcuspF1n/59KhHPCNL/rEeY1mO0DscHprgTgYu JsT4GLkV8BUtEBzD9EYVw== X-UI-Out-Filterresults: notjunk:1;V01:K0:8kTSEBjypEs=:yY2Qs0slQwr5roHPZuiThm JbGv9uFzyzI1t5dsskyEZHwhVtUtXWq4msSDoYikTPlY4NPrPyuYTdirM1A1LxkcLMjWY/sXe x8v8M121kZFE/VET5BGYHanttpS69Bi6G82YZQS2pS6Bf+vCC0xKSz+f5+f9/8UycUfDdU5Ft 6Icdj4lq64/fRg9mb9w222OtPkBPL8xQ09+xX6lfH2mlL5jfzTu6w13TC45ZoABT/hIrKC7fA 0u/r2PzYZoFa+A2USJcf4tS1qHxm8dcHfrA3JtI4MA9TkU9wuQjyHzG6OLjvjbj7iqHZI4C6P U3qurhGZt7CVkDewNcPx4BpGbeIhpUcPMVkw+C9rhQNJFQLCBOQudWqAjZlzyM2QeQPtCXwYH ixSo7/rqWEEyrvV0M+Mjh+kIFRNDZ9RmnxYLAtfm0r+O9ZRUC9M9aGD2+X69LUqPVrzKjsM2o Qh4UZFooilOjcy0F/h6tVdoB2f+US5cuDcCt009VRMG1Tc3BrxPgaiJWkaMYHF8T68xkqNAqZ xLZ/x8Obb7dg026uRioe7k+G+rOD4OP/QB4iMSrXywBhHbh7VfcCViGHVgpYpWuWQdXwsMNfd 7xHlZCQWJfjpSp+FNJALii4sj0UHE2uh3sQsK3sLeTfvV5wkG1kmh4tYX58uMxZ3gJVIqniT6 dXTr3oYmjcp+Jui2D8aCWFgRhd45YvRTf5hhTmlAg5RLkMZLrtXJlsLvRPvjASUW/O/E= Archived-At: Cc: media-types@ietf.org, Chris Lilley Subject: Re: [media-types] Macintosh file type code X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 22:21:40 -0000 --Apple-Mail=_595B46BF-2C2C-4A62-9F1D-BA31E8F63B66 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This goes along the proposal I had to add UTI and Windows clipboard = flavour names within the template. I remember having been too late "last = time". I haven=E2=80=99t heard of Apple using UTI outside clipboards though. Have you found such Chris? I believe that many media types can be sensibly exchanged over a = clipboard so that it makes sense to insert a section on = windows-clipboard-flavor and apple-UTI. Ned, how is the process to file such a change fo the template? thanks in advance. Paul >> 2) Is there value in adding the Apple UTI (which is at least = documented, and in current use) to the registration templates? >=20 > Not that I'm aware of, but more information can't hurt. >=20 >> My reason for asking is draft-ietf-justfont-toplevel >> https://datatracker.ietf.org/doc/draft-ietf-justfont-toplevel/ >=20 >> which will define a new top-level Media Type for fonts. I am very = tempted to just remove the "Macintosh file type code" from the = registration template, and could go either way on replacing it with an = "Apple Uniform Type Identifier" >> field - opinions welcome. >=20 > Either way works. --Apple-Mail=_595B46BF-2C2C-4A62-9F1D-BA31E8F63B66 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYSdwKAAoJEJQjh+Shy2exgksIALLYxFZvuFH9E/4W/aqaIfhF Y+uCdvyUf3UHCW+Epl3/ieR6OSmN9k7/SMbW5aI2WAUixii2L+Z/98/+SZfwbMVy z0vM2ORMfjaImVDFGWn4eORKgQUtZIY0vS36hOSu/mOkRyCofutDbvDtVOHdiSFa w5ZQKekt8whcxVVKb6379KnxRNWgXZ99DRliHhKoMQxRCOcnv/hdJkYJFms0Aoc5 r2xho3G7zr7X9/yuzbUTeD0Gdly1WPvc5Ka8YkTvfH/DQWgbj4br9oQuSovalwRD z6sTXE1KRs5HCcClXurb8CKRbNi4WvxrJYLKzR0cj2nTsd1WEEcocZJOQ09bL7o= =pWM6 -----END PGP SIGNATURE----- --Apple-Mail=_595B46BF-2C2C-4A62-9F1D-BA31E8F63B66-- From nobody Thu Dec 8 22:40:16 2016 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36E7129495 for ; Thu, 8 Dec 2016 22:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com 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 IZfxQ6Va9G1c for ; Thu, 8 Dec 2016 22:40:12 -0800 (PST) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0121.outbound.protection.outlook.com [104.47.93.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85CC512948A for ; Thu, 8 Dec 2016 22:40:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HMb7HhJlFZ93DAZDSKHHnxJ6rza98aNlKHCjtIXvZMY=; b=tao3+hu9/VJ6nMFWKc0A8AdnnYdZCbHkRB+9B0TS6W+Kl1P/WFtUrxPtVIbFm4w6HRL4cY8ehHs/qoN9+QU6x6CvR6DJemER30GgyrSj/OYJ6m7YS3EasRsf0/x5wVjISDzoZDDmTxIv9XEVsHYfn+OT/y2FIvEitP1kToJYlqo= 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 TY1PR0101MB0988.jpnprd01.prod.outlook.com (10.167.157.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.9; Fri, 9 Dec 2016 06:40:07 +0000 To: Chris Lilley , References: From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <5e3c8a55-ea40-9bd1-5f45-b426b29b794f@it.aoyama.ac.jp> Date: Fri, 9 Dec 2016 15:40:05 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OSXPR01CA0065.jpnprd01.prod.outlook.com (10.167.144.38) To TY1PR0101MB0988.jpnprd01.prod.outlook.com (10.167.157.151) X-MS-Office365-Filtering-Correlation-Id: bc3a961e-549d-44a9-6af0-08d41ffe375b X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:TY1PR0101MB0988; X-Microsoft-Exchange-Diagnostics: 1; TY1PR0101MB0988; 3:1KgPrvB0fXqM1NumenjnOmjxxUqst15v7igKNCxpPGRCyo8v2ZfpH1q2nC0X/nHh2R9Tag+APFrJORLJ04tZXKNhK4c7bUA3tfi+6YCE8bocIqWf3LUojtNEUPukqph6aNy9zY2L4aednIdI8HNc+2busxleBkklNceZLyk6S/WGrFXNOtFXjtyhoopk0SYWqu00RLi75eqqmjUF2ixvuDf4lT/XvLyS0Jot0tVDzx1jDrJQ/wRZU6UvdXoQTfoKVNqV3PBQz5ZV2KHW7386Jw==; 25:bUsFDkizbFuOjhym8rGLZOGQJDQznEaFSCYG1WLlYPzb34mq5sx+GTLrSN0XM8G9Jywvb71ngOk+C0ErS6SQuExv1XJRjJ2IVkyken0fuxddDDk1rnpe5x3wtaVUf+R3xIvuFTfB24oTYojlnbfSOqUyuI7y3e89fzshK0O6BWbGx1/WiDcdLGEIn7Nvd3zk+978qnCqqY6m3wPev3tFrutJaRJqJhy+vy0L2sbcTjUp6J6PuTkUD/m9QSmBDBuQBmjfPYL+EWAyFLolAN0Y4fHIlBHsVeJ+afkhb1Px7cQVxtvLIDhRSCQLauwwsoCc/kZIzKIu+P0TIaX7fT7mFO7RassK7hm4EpajJfsSSxitNQsJU3O4nxvLxxIVggX7VW7SF+2sRnwCvu1FnixgqIa2ud2SwdpmnsZIsLgylgn1JSgsf2vjdtp+7kfZIgPDPntBVaLjMSE52kRFmgBRrA== X-Microsoft-Exchange-Diagnostics: 1; TY1PR0101MB0988; 31:Umg08DjdrT34s1iNXQ+w2oJNLKmN+PSd/C1AJmkAWOEoTv1fGcVekn8ruuwxYiOE3/91ZmKP+qpEF5iEiiJjPnpIyllpUcXWRlo0KeYIf10OvsnZ+L7jPPQxXD+jgpruMcU8LVBULpxCuiOuWDIjgl3vZ5o2RvDe7bmRCCP1NwEYs5BT/SCv+TTWXDQXWSh2VyfQArccRBmj1aFDL5hl12gJrScVckpcxv5K+D/7vAVmVbOAbUAgtU59XsezVacZeW7g2nb+7btFXRJUZGbHWyFBq2jW0+ympll9OWUTjLo= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(166708455590820); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(2016111802025)(6043046)(6042181)(6072148); SRVR:TY1PR0101MB0988; BCL:0; PCL:0; RULEID:; SRVR:TY1PR0101MB0988; X-Microsoft-Exchange-Diagnostics: 1; TY1PR0101MB0988; 4:+WtusNCHqpBtvON6jWfaKpVvdtnmygcJn80UN2iWhSngEFpyLw9v8sF7B/sLwb2/raAYGyOxCvIavzrczH9egnXRe7WNv5YN3HiPQoX3LMee/O0EaioKIvrOllR8Lfe0+IaFmp8g83vTXvHgi5aDmIdp2pbIkhuXab3vSecNsYY2Xo7x97A04Yilm6FLo6wRDn78yEWsvb4qRULh1fYirNno6LcOvfJwe35wAKl8XdqEAeHdQkkm90rEL2RrQqQ/DN3bDUjV0vrKyDfnG7vHJPEnX7vipvKAL0zPti+r+476T+5qz5KaM8LgbRlBmClKbUa3ZyWJPLHsLXjCkl10ghhmb8hy2kisVocghh8OXdiMGniD67D7U3Y0E3XkLxewyqeB0xPDSe7b8BRLW73Insjo1tE0liEFXWYktsV/dRgboUrHHYd//+7Ay/9MwRCyaobh7ws+4zVI8/GVop8czUHavbPEh4rbY1rRwWLnE5pHK3gvI1clpqgD1w5wR7hJ54xsvff8rCtPrNin/TBrgOTwQGd1QqdBcSpt6+9aR6ifM5P3Epm7xhddg89EZgVNKpH0+3K9y80LVULnVvfk58kXKyz3KEP7RpQRCaVfkUAlYLEVCo3eZNbQ0Hhs5q9Uzb5jBuo7GBOjh+kkTKRX1a2P1o/ZHnZ0QnP+WVCFzwW+oFofgxuM3fuZz/St7fxCaSlN6/Xgq2iRNPgoZ35veA== X-Forefront-PRVS: 015114592F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(51444003)(24454002)(189002)(199003)(68736007)(86362001)(106356001)(2906002)(733004)(31686004)(6486002)(50466002)(64126003)(42186005)(23676002)(74482002)(105586002)(101416001)(66066001)(76176999)(54356999)(65956001)(65806001)(50986999)(31696002)(33646002)(90366009)(47776003)(38730400001)(65826007)(229853002)(305945005)(7736002)(81166006)(189998001)(81156014)(230700001)(8676002)(92566002)(42882006)(107886002)(5660300001)(5001770100001)(97736004)(3846002)(2950100002)(83506001)(4001350100001)(6116002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR0101MB0988; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; 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?MTtUWTFQUjAxMDFNQjA5ODg7MjM6VXpiTUZGOWRib0VGOFNlNDhlMW15NHF5?= =?utf-8?B?L2xHOUJDekp2SFJQekhiSW1oc1p0S3krQ1l4OEpPOW9vZ2NTNG9RRXh0THFq?= =?utf-8?B?YVkrUEVOOTF0SXhlOFpodWp6cXlwMTArY0JjTVdTdlcxNHdTME5BQmdzSXBy?= =?utf-8?B?aGV5ZFlEN3pUdHA4bjRzdFM4TU1WYVRwYldUeUp0THZvV3ZuUHptTmFFd3pi?= =?utf-8?B?cUJMVFBDYllaWTBzVS9MeDlGWnRKSndpNjRiN1Z0bjZIOFdkMktDVS9ObWhk?= =?utf-8?B?cytlR2ZUUjcxSjhZZE9OUW8zTW1JSHByRFdUTmEwRENPUHd3dm5lYmF0Qm5B?= =?utf-8?B?a0pvUGcrd3RwRVBEajlXcHpxcmVRVzNZMXJOS3FJVWRiTjB4UHZFUVE0dFpQ?= =?utf-8?B?dXNWZEg5NHV5dmNzN2tzR2ZGU0lPbWJEUGt1emtKMlEyT2xBckNicjJaVXdv?= =?utf-8?B?R2JIRk1CYTROYjBtY28rbkViVnIxVVhWbGErMWdPNCtkMDhDVmphUG93SGdC?= =?utf-8?B?aU1GS0x6c0ZQampHUmxkVHc4QlVCYnB1anI1eHEyeVQzQXY4V0RyUDZTcWQx?= =?utf-8?B?SFltOWswZjY5aU8vWjhPc2FEWWVPRzBGNHZjQ3c4Uis0a09sbzBrM1VSM0xu?= =?utf-8?B?aTc1YTZRM2JQcEtIYW9BMlkwQzg0OVRNTjA1Y1YwMVoxMWk2blQ5ZU1jbFla?= =?utf-8?B?ZENNRTdMeGZSc0k3d0VIR3NQNmZrbnk1RDN1WmxMbVV0TXV5WTlWUVRta0dr?= =?utf-8?B?WlhLb1NjckoxZmJPOEY0YnR6RDhTd3FXVW85d3NPYlE1ZncxQXBKb1htWjR4?= =?utf-8?B?cmsyU2NlUVhRblJXMkNsTnBvWG5lQ1F0TmdUemJMaytxSzRsR0dQaEF5YnZv?= =?utf-8?B?dnNKWHFPNTBEQ1BjMUwrMy9Ja0Y2Y0s3ZUJod291UFNndnpMalRmYW0rOVVr?= =?utf-8?B?NHdSU1VSckRSamh5RG4yRlJTL3JjaWJtQ0lnVTg3LzRlc2U0S2V4bGsyMTdQ?= =?utf-8?B?dUk4Wk5mWUQvdnhjR3dPay85dWlUV0pPQ0c5MnpDaUxJTjlnTXhJQ2ZZNFIv?= =?utf-8?B?aFUrNG45ZFprMGZlbFJPSFFIVWs5OHZoM21GV3dGY01oWEJiMnBrZXAvWHFz?= =?utf-8?B?d2hJcGVmR29mWS9adDloaTg1R0Y0OVhxTFliQkY0aFNEZmVIRkpLQ0RYNnUr?= =?utf-8?B?Unkwa0tTcUVOMnNuZHYrSkJRdy9wUTBldURQYjlqaGpubFdCL0RUQWRkZnFU?= =?utf-8?B?czhwYzV3Zm1iVkllRTBWS0VsSnRYakttY01oNXFNeEJuOUtrRmdvR3hPSGcz?= =?utf-8?B?SVJyN20wK0QxbTRaUmsvQ3kyQVNFY21CSmFENjEwRzNGcXI2Y0k1aXJ6clg1?= =?utf-8?B?Mll2cUc4YzlPLzQ1MWM0Ym8xRHNlcTJ4TUtXam5uZmZPUzJ3OWI0UUVZZy95?= =?utf-8?B?UklEMmFiZDFMcU9rcndKWWJ5UXhNWmgxa2I3NDl2RWZoNFVOcEt0V29OZjBv?= =?utf-8?B?a20xQmRsL0xjVW9KMnBQV1pZeWF5cU92U1oweFFSMXdTenlZblVwRTBGVDhD?= =?utf-8?B?cVVRSDN5SWJ4OEplbUozNGN2NEN0ckR1VlFLc0VjdGFDRE1ZN0p2SmFQMmZX?= =?utf-8?B?cFh1VkdUeVBkallWUHBWR0RJd2xLbVU1SGpSZ3VETlZ6OWdITGNycmtyVit1?= =?utf-8?B?LzdxWnplaG52N291NmJnSlo5TCtmTXZ4WDkwMktGVnBabTlGeDBMSXdwbXJr?= =?utf-8?Q?2IcCg6KK7FY3ep55kT9OuwG09MsWvL5pqmqFYKw=3D?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR0101MB0988; 6:O1Nq9kfWN5refRzSMlZVth18+TLmc60Kx13JfGqHbHoL+YsaCusMlQwwzvh8mZy/SGUThHiSJ4v18figWuq/Ie66YWmqy5Xc2ABMt52EkWQ84OxlrVrBVkbKuW7KWiSBe924xzGzqC4VEfS7w6/GTxvWg3GZu53wcepHW8wArM2047q2wispdLQSh5Rx6rAIVTjSumLyG67CxYE6t9uxW8eRdeqo3pqk5OrNryV2WxTTJMP/kKFS3sz0KnoP8vKCPgjHqr+KgxbQYjB2hTPQKNZSRk8RHXja6bWXJ0mLeWUfr0HdaFNcnGVSDcO5QxH/8ASifPXA3XqFElb9Cp1ZQ5PaZdHoESTEhe4OI2Tht+cpVXdwCNorfH3gfPo/s2UkjUOXrvi15YOFmOMXp3E2Rb7TiE8VlrTZMaFM/5s3pQQKqFePqT2F7lkQmrwXhqZB; 5:Ukhj9g5bjXi4S3M+3yPl19XBYsJ++OLMHVB8XALXbf84oJLbv4MSAUmTKSy0HQEot4O6EOWXVsEy87knUhpphX4TsFOaIZDSEyEGXJVOTvNHZKe91dRprbBW2BI/3RXqhkdDqBl2tSgS73BX2VGfOA==; 24:eaaZl5NAX96tGB2fOY7LvYLXVfh32HY8lBQJHUEvBjNv9YJiANCOFUxiQjxwsKGLxBe37/L9MfmWfejQVzlfw8RuVzcbOgCymjEcV2Gycyw= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; TY1PR0101MB0988; 7:EeVtq5QZt8t/7+tTGKoQQKgR23GH8WawR/qbmraWVshkPr4I+X90Mll6VPW9igXvZvsUvqjbljPkokgHPCbTe+ba2V0smNCpglQ0SAYTdpOC0wldnQMh7bq2MKWgFPF0ctNVNmoDjTQWXDnXYRxUjCkkAk9iCftrjtn0EjyqESgoqPTp1xYSw/uToZ/M9/3mPtKQHLN21uRnzx4wPhuy8YPYR2vEKmiavhCYEUGIU2lX2xwTJrM43+XMdjmvHKEuv9lb7IrSdvwAP3AdfgUqXohR59EHz/1lLt+qWcP09fhIIinVki8Vf0ZvnF8IyIG99jAcT9PnEr4/6M192u/gN2Zep4WrIrz7W2XMkrd9t5tPAlmi/4mGbQRApfW9OQilrX+Ld3fwhzB1T6V8ebr29+LQUpS4bYvWSJFZzOJNYDJZ1syhe4rqD5GN10xJjObExK35ydV/E5SEz9V/oVrP+A== X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Dec 2016 06:40:07.4983 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR0101MB0988 Archived-At: Subject: Re: [media-types] Macintosh file type code X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 06:40:15 -0000 Hello Chris, On 2016/12/09 02:34, Chris Lilley wrote: > It is not clear to me what, in a Media Type registration, the "Macintosh file type code" is for, or what the allowed range of tokens is, or whether anyone checks this information or uses it in any way. > 1) Is there continuing value in providing this data in a Meda Type registration, given that it does not seem to be used by current Apple products and has been replaced, as far as Apple is concerned, by UTIs? > > I see some registrations say 'none' as the value. It seems better to me to just remove this field from the template. Yes, this seems to be only of historic value. > 2) Is there value in adding the Apple UTI (which is at least documented, and in current use) to the registration templates? > > My reason for asking is draft-ietf-justfont-toplevel > https://datatracker.ietf.org/doc/draft-ietf-justfont-toplevel/ > > which will define a new top-level Media Type for fonts. I am very tempted to just remove the "Macintosh file type code" from the registration template, and could go either way on replacing it with an "Apple Uniform Type Identifier" field - opinions welcome. Do the individual subtypes that this draft is registering have UTIs, or should they have them? If yes, then having this field is definitely valuable. > Raisng on this list since it affects all other registration templates as well. I'd propose you also ask for advice on https://github.com/svgeesus/ietf-justfont/issues/24 and https://github.com/svgeesus/ietf-justfont/issues/23 here on this list, because I think that's where the chance of getting some valuable input is highest. Regards, Martin. From nobody Fri Dec 9 08:43:25 2016 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C63A1294D1 for ; Fri, 9 Dec 2016 08:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 S9vPbG3Vz_zp for ; Fri, 9 Dec 2016 08:43:21 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49A8D129480 for ; Fri, 9 Dec 2016 08:43:20 -0800 (PST) Received: from 30-9-49.wireless.csail.mit.edu ([128.30.9.49]) by raoul.w3.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1cFOGU-0004vP-MB; Fri, 09 Dec 2016 16:43:18 +0000 Content-Type: multipart/alternative; boundary="----=_NextPart_3397451.767614015569" MIME-Version: 1.0 Date: Fri, 09 Dec 2016 11:43:10 -0500 Message-ID: <0fcf531b-f63b-43ff-91fa-aa3234dde8cc@getmailbird.com> From: "Chris Lilley" To: =?utf-8?B?TWFydGluIEouIETDvHJzdA==?= , "" In-Reply-To: <5e3c8a55-ea40-9bd1-5f45-b426b29b794f@it.aoyama.ac.jp> References: <5e3c8a55-ea40-9bd1-5f45-b426b29b794f@it.aoyama.ac.jp> User-Agent: Mailbird/2.3.36.0 X-Mailbird-ID: 0fcf531b-f63b-43ff-91fa-aa3234dde8cc@getmailbird.com Archived-At: Subject: Re: [media-types] Macintosh file type code X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 16:43:24 -0000 ------=_NextPart_3397451.767614015569 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2016-12-09 01:40:41, Martin J. D=C3=BCrst wrote: > 2) Is there value in adding the Apple UTI (which is at least documented, = and in current use) to the registration templates? > > My reason for asking is draft-ietf-justfont-toplevel > https://datatracker.ietf.org/doc/draft-ietf-justfont-toplevel/ > > which will define a new top-level Media Type for fonts. I am very tempted= to just remove the "Macintosh file type code" from the registration templa= te, and could go either way on replacing it with an "Apple Uniform Type Ide= ntifier" field - opinions welcome. Do the individual subtypes that this draft is registering have UTIs, or should they have them? If yes, then having this field is definitely valuable. Chris Lilley:=C2=A0 Yes, they do, and I have added them to the current document yesterday. > Raising on this list since it affects all other registration templates as= well. I'd propose you also ask for advice on https://github.com/svgeesus/ietf-justfont/issues/24 and https://github.com/svgeesus/ietf-justfont/issues/23 here on this list, because I think that's where the chance of getting some valuable input is highest. Chris Lilley: Good idea, thanks Martin. The one about case insensitivity is settled, but = I will send a separate message about the spaces in parameters. However, the= current document now disallows spaces. -- Chris Lilley @svgeesus Technical Director @ W3C W3C Strategy Team, Core Web Design W3C Architecture & Technology Team, Core Web & Media ------=_NextPart_3397451.767614015569 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

=0A

On 2016-12-09 01:40:41, Martin J.= D=C3=BCrst <duerst@it.aoyama.ac.jp> wrote:

> 2) Is there value= in adding the Apple UTI (which is at least documented, and in current use)= to the registration templates?=0A
>=0A
> My reason for asking = is draft-ietf-justfont-toplevel=0A
> https://datatracker.ietf.org/doc= /draft-ietf-justfont-toplevel/=0A
>=0A
> which will define a ne= w top-level Media Type for fonts. I am very tempted to just remove the "Mac= intosh file type code" from the registration template, and could go either = way on replacing it with an "Apple Uniform Type Identifier" field - opinion= s welcome.=0A
=0A
Do the individual subtypes that this draft is regis= tering have UTIs, or =0A
should they have them? If yes, then having this= field is definitely =0A
valuable.=0A
Chris Lilley: 
Yes, they do, and I have added the= m to the current document yesterday.
=0A
= > Raising on this list since it affects all other registration templates= as well.=0A
=0A
I'd propose you also ask for advice on=0A
https:/= /github.com/svgeesus/ietf-justfont/issues/24 and=0A
https://github.com/s= vgeesus/ietf-justfont/issues/23=0A
here on this list, because I think th= at's where the chance of getting =0A
some valuable input is highest.=0A<= br>
Chris Lilley:

Good idea, thanks Martin. The one about case insensitivity is settled, but I= will send a separate message about the spaces in parameters. However, the = current document now disallows spaces.


--
Chris Lilley=
@svgeesus
Technical Director @ W3C
W3C Strategy Te= am, Core Web Design
W3C Architecture & Technology Team, Core = Web & Media
=0A = =0A
------=_NextPart_3397451.767614015569-- From nobody Fri Dec 9 08:47:29 2016 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70981294C7 for ; Fri, 9 Dec 2016 08:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 JhTQJp4VHyKJ for ; Fri, 9 Dec 2016 08:47:25 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64C251294B2 for ; Fri, 9 Dec 2016 08:47:25 -0800 (PST) Received: from 30-9-49.wireless.csail.mit.edu ([128.30.9.49]) by raoul.w3.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1cFOKS-0005Fs-EJ for media-types@ietf.org; Fri, 09 Dec 2016 16:47:24 +0000 Content-Type: multipart/alternative; boundary="----=_NextPart_1055536.613677040733" MIME-Version: 1.0 Date: Fri, 09 Dec 2016 11:47:16 -0500 Message-ID: <67961b58-3ec6-446a-b7e2-4662d341c2a5@getmailbird.com> From: "Chris Lilley" To: "" User-Agent: Mailbird/2.3.36.0 X-Mailbird-ID: 67961b58-3ec6-446a-b7e2-4662d341c2a5@getmailbird.com Archived-At: Subject: [media-types] Spaces in parameter values X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 16:47:28 -0000 ------=_NextPart_1055536.613677040733 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Dale R. Worley wrote (in review of the proposed font top-level type) I strongly recommend against allowing whitespace in parameter values. It seems to be allowed in principle (RFC 6838 section 4.3), but I expect many processors of media types to misbehave on parameter values containing whitespace. In response I have disallowed spaces in parameter values, in the current dr= aft. More generally however, I am interested to know more specific details about= processors misbehaving when parameter values contain spaces. If this is a significant problem, and those processors can't or won't chang= e, shouldn't an update to RFC 6838 be produced? -- Chris Lilley @svgeesus Technical Director @ W3C W3C Strategy Team, Core Web Design W3C Architecture & Technology Team, Core Web & Media ------=_NextPart_1055536.613677040733 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Dale R. Worley wrote (in review of the proposed font= top-level type)

=0A
=0A

I strongly recommend against allow= ing whitespace in parameter values.
=0AIt seems to be allowed in princip= le (RFC 6838 section 4.3), but I
=0Aexpect many processors of media type= s to misbehave on parameter values
=0Acontaining whitespace.

In response I have disallowed spaces in parameter values, in the = current draft.
<= br>
More = generally however, I am interested to know more specific details about proc= essors misbehaving when parameter values contain spaces.
<= span style=3D"font-size: 10pt;line-height: 1.5">
If this is a significant proble= m, and those processors can't or won't change, shouldn't an update to RFC 6= 838 be produced?

--
Ch= ris Lilley
@svgeesus
Technical Director @ W3C
W3C S= trategy Team, Core Web Design
W3C Architecture & Technology T= eam, Core Web & Media
------=_NextPart_1055536.613677040733-- From nobody Fri Dec 9 08:49:14 2016 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27741294C7 for ; Fri, 9 Dec 2016 08:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 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, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 PJfXvQqdmjeP for ; Fri, 9 Dec 2016 08:49:12 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 5542A1294D5 for ; Fri, 9 Dec 2016 08:49:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1481302151; d=isode.com; s=june2016; i=@isode.com; bh=EKYTRbzGWcKW+W3TuLNZxch4/SoOc9xkttLZirAQ6C0=; 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=QEqWU7ck7Xbr1hpxCItI7Gu8tJqTvoiUeG5b/7OUcfdBJ6/Lwaa+EnBdGkz2DPxSmY8qAq iKVvX+G/h01r3Ege5xP7RVbeQxZSsqLCY8VqpXMJAlWLTJOX7gB1Z/IyvKCElQtM9b6Jzq eLBckktpoYjaGO+dWKbCdl03Lm7MRQo=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 9 Dec 2016 16:49:11 +0000 To: Chris Lilley , media-types@ietf.org References: <67961b58-3ec6-446a-b7e2-4662d341c2a5@getmailbird.com> From: Alexey Melnikov Message-ID: <2878f4d0-9353-9d60-d34a-93e6ff4f9d66@isode.com> Date: Fri, 9 Dec 2016 16:48:46 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 In-Reply-To: <67961b58-3ec6-446a-b7e2-4662d341c2a5@getmailbird.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------8236BB29D1EDD8A764FD459A" Archived-At: Subject: Re: [media-types] Spaces in parameter values X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 16:49:13 -0000 This is a multi-part message in MIME format. --------------8236BB29D1EDD8A764FD459A Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 09/12/2016 16:47, Chris Lilley wrote: > Dale R. Worley wrote (in review of the proposed font top-level type) > > I strongly recommend against allowing whitespace in parameter values. > It seems to be allowed in principle (RFC 6838 section 4.3), but I > expect many processors of media types to misbehave on parameter values > containing whitespace. > > In response I have disallowed spaces in parameter values, in the > current draft. > > More generally however, I am interested to know more specific details > about processors misbehaving when parameter values contain spaces. > > If this is a significant problem, and those processors can't or won't > change, shouldn't an update to RFC 6838 be produced? IMHO, not a problem in email world. So not doing any change is sensible to me. --------------8236BB29D1EDD8A764FD459A Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

On 09/12/2016 16:47, Chris Lilley wrote:

Dale R. Worley wrote (in review of the proposed font top-level type)

I strongly recommend against allowing whitespace in parameter values.
It seems to be allowed in principle (RFC 6838 section 4.3), but I
expect many processors of media types to misbehave on parameter values
containing whitespace.

In response I have disallowed spaces in parameter values, in the current draft.

More generally however, I am interested to know more specific details about processors misbehaving when parameter values contain spaces.

If this is a significant problem, and those processors can't or won't change, shouldn't an update to RFC 6838 be produced?

IMHO, not a problem in email world. So not doing any change is sensible to me.


--------------8236BB29D1EDD8A764FD459A-- From nobody Fri Dec 9 09:28:56 2016 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E49712997C for ; Fri, 9 Dec 2016 09:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 VDOUaEX78OTE for ; Fri, 9 Dec 2016 09:28:54 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 284B112996A for ; Fri, 9 Dec 2016 09:28:54 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q89TL3AWW0003W41@mauve.mrochek.com> for media-types@ietf.org; Fri, 9 Dec 2016 09:23:57 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q7RKQ1HV28011H9Q@mauve.mrochek.com>; Fri, 09 Dec 2016 09:23:54 -0800 (PST) Message-id: <01Q89TL1PXE6011H9Q@mauve.mrochek.com> Date: Fri, 09 Dec 2016 09:17:48 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Fri, 09 Dec 2016 16:48:46 +0000" <2878f4d0-9353-9d60-d34a-93e6ff4f9d66@isode.com> References: <67961b58-3ec6-446a-b7e2-4662d341c2a5@getmailbird.com> <2878f4d0-9353-9d60-d34a-93e6ff4f9d66@isode.com> To: Alexey Melnikov Archived-At: Cc: media-types@ietf.org, Chris Lilley Subject: Re: [media-types] Spaces in parameter values X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 17:28:55 -0000 > IMHO, not a problem in email world. So not doing any change is sensible > to me. +1. Think "file names", which in addition to being placed in content-disposition filename parameters, routinely appear in content-type name parameters. And quite a few file names contain spaces. Many other parameters that contain spaces have been defined for various types. I've yet to see it be an issue. You are of course free not to use spaces in your parameter values if you think that's appropriate. But a general ban on spaces in parameter values at this point in time is an absolute and complete nonstarter. Ned From nobody Sun Dec 18 09:14:45 2016 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BACFD12954E for ; Sun, 18 Dec 2016 09:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 yw0Nnkcbo17d for ; Sun, 18 Dec 2016 09:14:43 -0800 (PST) Received: from pechora1.lax.icann.org (pechora1.icann.org [IPv6:2620:0:2d0:201::1:71]) (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 C4D55129546 for ; Sun, 18 Dec 2016 09:14:43 -0800 (PST) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pechora1.lax.icann.org (Postfix) with ESMTPS id A81A21E0654 for ; Sun, 18 Dec 2016 17:14:43 +0000 (UTC) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by adrilankha.hactrn.net (Postfix) with ESMTPS id B78B939837; Sun, 18 Dec 2016 17:14:22 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id CAF03446331C; Sun, 18 Dec 2016 12:13:31 -0500 (EST) Date: Sun, 18 Dec 2016 12:13:31 -0500 From: Rob Austein To: media-types@iana.org User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20161218171331.CAF03446331C@minas-ithil.hactrn.net> Archived-At: Subject: [media-types] Please review media type rpki-publication in draft-ietf-sidr-publication X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2016 17:14:45 -0000 draft-ietf-sidr-publication-09 has just gone to IETF last call on standards track, and our AD noticed that we had never requested formal review of the rpki-publication media type. Oops. Please review. Transport and encapsulation are essentially the same as in RFC 6492 (unsurprising, since part of the same family of protocols). The slightly odd encapsulation (HTTP transporting signed CMS wrapping XML) stems from a design requirement for the ability to archive signed transactions for signature audit long after any channel security mechanism has been torn down. The code which implements this protocol also has to implement RFC 6492, so using the same basic mechanisms simplifies code reuse. https://datatracker.ietf.org/doc/draft-ietf-sidr-publication/ Thanks! --Rob