From nobody Tue Nov 1 11:48:07 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 04B56129875 for ; Tue, 1 Nov 2016 11:48:04 -0700 (PDT) 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, SPF_HELO_PASS=-0.001] autolearn=unavailable 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 1D3LQPW6c0ks for ; Tue, 1 Nov 2016 11:48:02 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [192.0.33.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 1E4BE1297D0 for ; Tue, 1 Nov 2016 11:38:28 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pechora1.lax.icann.org (Postfix) with ESMTPS id 665991E0161 for ; Tue, 1 Nov 2016 18:38:27 +0000 (UTC) Received: from [IPv6:::1] ([193.197.143.162]) by mrelayeu.kundenserver.de (mreue102) with ESMTPSA (Nemesis) id 0MLPHO-1c2CAz0o0w-000aZP; Tue, 01 Nov 2016 19:38:03 +0100 Content-Type: multipart/signed; boundary="Apple-Mail=_105EAF03-BF9C-4947-8F99-C1CC0777C229"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Paul Libbrecht In-Reply-To: Date: Tue, 1 Nov 2016 19:37:39 +0100 Message-Id: <9B2DA410-7AB2-44C6-857B-01C77647B553@hoplahup.net> References: To: Cullen Jennings X-Mailer: Apple Mail (2.3124) X-Provags-ID: V03:K0:yRd2xxqVooYiyzYBXpcPlcTivc08u5i9+kxnzE5xVHOVbJ3T3GB fO8jMeK2AW7m07ShMuVbpMhApTsBwtZ+E4UC3N9ZpmcTXqjZA0Fq4zauVIuMENvo0x0zMRT NWcHlShs7tC47Te3yG+Xnzjs9qBnYdNqHMuI52vLQ0yXO/4DCk/ExKeyaZm9jyBLJ9m1V3f 9MUhzad/0RB9NuYTEKqSw== X-UI-Out-Filterresults: notjunk:1;V01:K0:VF7u5pr/iYI=:VHagCWHfMmukRIuMYgPuPC qCbQC9qojI9Yk5v0RZszhpIXRLfyGgVXpacTmvMSJVqNo6w/9dzg2X/ErihO5f9s/csxrYKEn YensNdwsExTZ7TeRiLuxr3woMUB+ExXjeNaSMP4+h1NymbeA8qWwO2az89suWc9cCNNDceYHX CzhfNmYFscJMlwxuYVViQO2jY9feXMdahWVOnjt4ktyLrCISjeoLFo3baU1vaJS77WjokPqEx Mj6lwQ9kSujvcZ5JQpTp2DRLYwKNRZNBjI2s0ADRrky4Tg3vx14EgwTy28VoCvN2HO+mK0qAr waup5d/Zhl/nOEPf+HUv4ZX9C6++LHXnnc+D+fjSmw6OSyjI5JV6gbFzy93QhfxzEHkcUG3pW CM2LSKsloY39+gTyjw4EQlWCIowgASyXcfmMFtghmTULUN/Ee9EOLdPq8imQSsqgDLqFzn6W1 sowQzomQ+hy36NQO1mJz5W/KrufNCFCthZdlaxgc2Czyz+kHvl0lGHAhTsbJ6aJ8SopqBjAfx 6ooosUeZnWgNTgw/DyhkJoLLdNqFIHR4t/rhX7F0zTh7IJN9Fw43bjTheo8zL9xDuk+miepAh fHGcJzzm/fmhkocKj5DZtODvfuSfRX5tQWoKlFon929n7M0rwd2XT9wKS8YLmkQqwqa+SOVVl b1dMMcyEHno5592CkcFswmo6lcUwOvcaq/9SX162/d9Faxt3ja7DKZmGVI99Z02b8JHw= Archived-At: Cc: media-types@iana.org Subject: Re: [media-types] Request even more review for application/senml+xml and application/sensml+xml 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: Tue, 01 Nov 2016 18:48:04 -0000 --Apple-Mail=_105EAF03-BF9C-4947-8F99-C1CC0777C229 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Cullen, it seems to me that all the content-types you have been describing about = senML are candidate content types to be exchanged over the clipboard of = a normal mobile or desk computer; e.g. from a reading app to another, = =E2=80=A6 Do you agree on this? If yes, then I=E2=80=99d like to recommend to add: - MacOS Uniform Type Identiers - Windows Clipboard Name for each of the content-types. If there is earlier experience in this realm, probably this should be = taken, otherwise, I can probably suggest some clipboard names. Standardising such at the Media-Type declaration level allows to set a = reference frame so that other implementations can follow, just as the = content-type name. For examples of including this in the media-type registration, see that = of SVG or MathML. thanks in advance. Paul > On 31 Oct 2016, at 22:07, Cullen Jennings wrote: >=20 >=20 > In the registration below, RFC-AAAA would point at an RFC based on = draft-ietf-core-senml-04 >=20 >=20 > Type name: application >=20 > Subtype name: senml+xml and sensml+xml >=20 > Required parameters: none >=20 > Optional parameters: none >=20 > Encoding considerations: Must be encoded as using > [W3C.REC-xml-20081126]. See RFC-AAAA for details. >=20 > Security considerations: Sensor data can contain a wide range of > information ranging from information that is very public, such the > outside temperature in a given city, to very private information that > requires integrity and confidentiality protection, such as patient > health information. This format does not provide any security and > instead relies on the transport protocol that carries it to provide > security. Given applications need to look at the overall context of > how this media type will be used to decide if the security is > adequate. >=20 > Interoperability considerations: Applications should ignore any tags > or attributes that they do not understand. This allows backwards > compatibility extensions to this specification. The "bver" attribute > in the senml tag can be used to ensure the receiver supports a > minimal level of functionality needed by the creator of the XML. >=20 > Published specification: RFC-AAAA >=20 > Applications that use this media type: The type is used by systems > that report e.g., electrical power usage and environmental > information such as temperature and humidity. It can be used for a > wide range of sensor reporting systems. >=20 > Additional information: >=20 > Magic number(s): none >=20 > File extension(s): senmlx and sensmlx >=20 > Macintosh file type code(s): none >=20 > Person & email address to contact for further information: Cullen > Jennings >=20 > Intended usage: COMMON >=20 > Restrictions on usage: None >=20 > Author: Cullen Jennings >=20 > Change controller: IESG >=20 > [W3C.REC-xml-20081126] > Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and > F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth > Edition)", World Wide Web Consortium Recommendation REC- > xml-20081126, November 2008, > . >=20 > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types --Apple-Mail=_105EAF03-BF9C-4947-8F99-C1CC0777C229 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 iQEcBAEBCgAGBQJYGOD0AAoJEJQjh+Shy2exjbQIALYNfzZoqnrCOL0iKCjJ/Sh7 zuxGUHmtqavHeaIbZkIO/QBumvqmXhMYCiOqucAV6UOsOB1tI9tGY66Wwer7IjE7 NwC3VHLr9wcIxva+/pK6KKPKYg+6JEf/t6qy41ZWM+qYWphy9nJdyxu10q+BTTGf 0au3xxl802r23XchmAnQeYEyDjXaBVTnDyiXv++qCcmD9hs33zBsGD2NPtIG+22l OJprfocoNpCAv7G1LA8Ple2yTvn8wiSt23efGf74CnSfLmnKBZ+p7Vi86WT2oinE QiA3w3AuLApUjzSMI4w27CiCQnOTdioZLQGRP04OYdPVIkzD5dlIjf1QWLIH4U0= =uYTb -----END PGP SIGNATURE----- --Apple-Mail=_105EAF03-BF9C-4947-8F99-C1CC0777C229-- From nobody Sun Nov 13 21:35:15 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 98520129626 for ; Sun, 13 Nov 2016 21:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=teamtelstra.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 sScWrCtj4RYG for ; Sun, 13 Nov 2016 21:35:11 -0800 (PST) Received: from pechora1.lax.icann.org (pechora1.icann.org [192.0.33.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 9351E129622 for ; Sun, 13 Nov 2016 21:35:02 -0800 (PST) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) (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 A218B1E0C44 for ; Mon, 14 Nov 2016 05:35:01 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.31,488,1473084000"; d="scan'208,217";a="118158180" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 14 Nov 2016 16:34:37 +1100 X-IronPort-AV: E=McAfee;i="5700,7163,8348"; a="331483318" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcavi.tcif.telstra.com.au with ESMTP; 14 Nov 2016 16:34:36 +1100 Received: from wsapp5862.srv.dir.telstra.com (10.75.3.94) by wsmsg3704.srv.dir.telstra.com (172.49.40.197) with Microsoft SMTP Server (TLS) id 8.3.485.1; Mon, 14 Nov 2016 16:34:37 +1100 Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsapp5862.srv.dir.telstra.com (10.75.3.94) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 14 Nov 2016 16:34:35 +1100 Received: from AUS01-ME1-obe.outbound.protection.outlook.com (10.172.229.125) by wsapp5584.srv.dir.telstra.com (10.75.131.20) with Microsoft SMTP Server (TLS) id 15.0.1178.4 via Frontend Transport; Sun, 13 Nov 2016 21:34:35 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teamtelstra.onmicrosoft.com; s=selector1-team-telstra-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IfhCKKezg5coi6CHPsvvkVDjypvDVCEse4tF5qff+VA=; b=WVyVgUyZrMjkuIG1Smo/hoQ+ZtVqhuGtUBbB7u2CQ/lazhTNlvFuQrG1Q/gRPZ1ZGAtqaQ0DoXywN4S3MTR5+9MG/QKcC4nWxZuB3QFunodHCNkJXXTP7tSjvu7bp4GoCbB2UpAEwWYzGb4snaCopNyAd/YUPuERJ5c1zJG/AqA= Received: from SY3PR01MB1610.ausprd01.prod.outlook.com (10.171.3.138) by SY3PR01MB1611.ausprd01.prod.outlook.com (10.171.3.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Mon, 14 Nov 2016 05:34:21 +0000 Received: from SY3PR01MB1610.ausprd01.prod.outlook.com ([10.171.3.138]) by SY3PR01MB1610.ausprd01.prod.outlook.com ([10.171.3.138]) with mapi id 15.01.0721.015; Mon, 14 Nov 2016 05:34:21 +0000 From: "Manger, James" To: "media-types@iana.org" Thread-Topic: application/openid-connect-porting Thread-Index: AdI+BbkpzevVJPniSPCXh1fm40HvTg== Date: Mon, 14 Nov 2016 05:34:21 +0000 Message-ID: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com; x-originating-ip: [203.41.142.254] x-microsoft-exchange-diagnostics: 1; SY3PR01MB1611; 7:YCVZ5CEm6X/Qv+ajhuVzu5ViDpHTxy5GGT67+VpIaAf123U7kgCTYAB38kAKEERNzVCyVbpU3C7xMkChV+oiSu+BZWuRTqD5GtpOLJgtNVkoTxtqEct1OZNBQ0svpufWWjtbwGTY7NYsDI8tFWCXAyMky28KJTOj2dehGOrnSoYrkp8V8WD+8Cfa856d+pLXbvetqb6mEgPtnLQy4JvMbyMIf60bK0aP65FUNVq7YDG61TcXGDrx7YI38D0TYsmXFGS7YB9BBFxi8q/9TGKfrT5QuSUEyl06w9+BGoZPy4tBP+7Iw8b6NQYH2efS9+rg2FaueUn4j+DZeh4leRJdSuGyy+KOdaJRF/IlSzNJI3I= x-ms-office365-filtering-correlation-id: 9a63c4aa-4d47-40c2-f793-08d40c4fe2e0 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SY3PR01MB1611; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(272811157607776)(21748063052155)(21532816269658)(67441168502697); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060320)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6061315); SRVR:SY3PR01MB1611; BCL:0; PCL:0; RULEID:; SRVR:SY3PR01MB1611; x-forefront-prvs: 0126A32F74 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(336003)(199003)(189002)(586003)(9686002)(68736007)(87936001)(8676002)(3846002)(102836003)(6116002)(790700001)(2906002)(2351001)(76576001)(7736002)(5660300001)(7846002)(54356999)(74316002)(7906003)(50986999)(450100001)(3660700001)(3280700002)(101416001)(105586002)(33656002)(8936002)(6916009)(86362001)(42882006)(2501003)(7696004)(110136003)(230783001)(189998001)(66066001)(81156014)(81166006)(92566002)(107886002)(106356001)(77096005)(2900100001)(97736004)(5630700001)(15395725005)(5640700001)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:SY3PR01MB1611; H:SY3PR01MB1610.ausprd01.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: team.telstra.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SY3PR01MB16109C88F0BD3B965402803CE5BC0SY3PR01MB1610ausp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2016 05:34:21.2244 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY3PR01MB1611 X-OriginatorOrg: team.telstra.com Archived-At: Subject: [media-types] application/openid-connect-porting 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: Mon, 14 Nov 2016 05:35:13 -0000 --_000_SY3PR01MB16109C88F0BD3B965402803CE5BC0SY3PR01MB1610ausp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi media-type team, I would like to register application/openid-connect-porting to unambiguousl= y identify the semantics of a message involved when a user changes identity= providers. It is being specified in the OpenID Connect Account Porting specificati= on being developed in the OpenID Foundation (MODRNA working group). The media type will be used for messages in the JSON= Web Encryption (JWE) compact serialization format [RFC7516 JWE]. The media type goes in the "typ" member of the = JSON header part of a message [see =A74.1.11 "typ (Type) Header Parameter o= f RFC7516, which refers to =A74.1.9 of RFC7515 JWS]. >From the draft spec: This document registers the "application/openid-connect-porting" media type= in the IANA "Media Types" registry [IANA.MEDIA]. It identifies a JSON Web = Encryption (JWE) compact serialization that is the encryption of a port tok= en. Type name: application Subtype name: openid-connect-porting Required parameters: N/A Optional parameters: N/A Encoding considerations: 7bit Security considerations: see [RFC7516] Interoperability considerations: N/A Published specification: Section 4.1 of [[ this specification ]] Applications that use this media type: OpenID Connect Fragment identifier considerations: N/A Additional information: N/A Intended usage: COMMON Restrictions on usage: N/A Change controller: OpenID Foundation I assume it is better not to list an individual as the contact when the def= inition/registration comes from a spec from a standards body, but in case a= n individual's details are required I have included mine below. Contact name: James Manger Contact email address: james.h.manger@team.telstra.com I hope the OpenID Foundation is a "recognised standards-related organizatio= n" for media type registrations. Can anyone confirm? After responding to any feedback triggered by this email, I will submit med= ia type via the IANA web form. -- James Manger --_000_SY3PR01MB16109C88F0BD3B965402803CE5BC0SY3PR01MB1610ausp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi media-type team,

 

I would like to register application/openid-connect-= porting to unambiguously identify the semantics of a message involved when = a user changes identity providers. It is being specified in the OpenID Connect Account Porting specification being developed in the OpenID Foundation (MODRNA working = group). The media type will be used for messages in the JSON Web Encryp= tion (JWE) compact serialization format [RFC7516 JWE]. The media type goes in the "typ" member of the JSON header part of a= message [see =A74.1.11 “typ (Type) Header Parameter of RFC7516, whic= h refers to =A74.1.9 of R= FC7515 JWS].

 

From the draft spec:

 

This document registers the "application/openid= -connect-porting" media type in the IANA "Media Types" regis= try [IANA.MEDIA]. It identifies a JSON Web Encryption (JWE) compact seriali= zation that is the encryption of a port token.

 

Type name: application

Subtype name: openid-connect-porting

Required parameters: N/A

Optional parameters: N/A

Encoding considerations: 7bit

Security considerations: see [RFC7516]

Interoperability considerations: N/A

Published specification: Section 4.1 of [[ this specification ]]

Applications that use this media type: OpenID Connec= t

Fragment identifier considerations: N/A

Additional information: N/A

Intended usage: COMMON

Restrictions on usage: N/A

Change controller: OpenID Foundation

 

I assume it is better not to list an individual as t= he contact when the definition/registration comes from a spec from a standa= rds body, but in case an individual’s details are required I have inc= luded mine below.

 

Contact name: James Manger

Contact email address: james.h.manger@team.telstra.c= om

 

 

I hope the OpenID Foundation is a “recognised = standards-related organization” for media type registrations. Can any= one confirm?

 

After responding to any feedback triggered by this e= mail, I will submit media type via the IANA web form.

 

--

James Man= ger

 

--_000_SY3PR01MB16109C88F0BD3B965402803CE5BC0SY3PR01MB1610ausp_-- From nobody Thu Nov 17 02:21:21 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 6F04A1294BC for ; Thu, 17 Nov 2016 02:21:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 6jKfUmS-xFoo for ; Thu, 17 Nov 2016 02:21:17 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 BC19E12947A for ; Thu, 17 Nov 2016 02:21:17 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id n21so212195909qka.3 for ; Thu, 17 Nov 2016 02:21:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=4rExwqFP0M783Au7GSollWFLTZXL4WbDWHNcjV+R+28=; b=c9aAFF7AOTUMxxL3FkNjmcXIyKgMjZhFOTfbFnNbewITAZ4Vz4ob8uODUnDUS1c5yO vfxMKsJjU66FaD6ZYRbUI6F+3RJeBSeGKs+RduTSdvsvsvdaOrn45hBUNyuGMAGhGNGm MbhDljxDbsmVg48aVgjKAK3ldmmLvtHhLU3Whpo/KBJNdEpNqdpX1lCbEfJOUGN0Ikaz jIuHWCpQZKuwGtW5abhganwKZLtDZaqpxV7J+IJye4V5TYYjGKZ+5+3jNM2TyBUqyxlh C+exmUg2MuQsW5Yb+sDFQrNG24W8O9RlHerESRtIAl5egBRhi2/H15tADOqDATnLPcYx u2KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4rExwqFP0M783Au7GSollWFLTZXL4WbDWHNcjV+R+28=; b=TuSBQNoPJpr/6jmJ4K9Av0hjx7zXP23vMFPAn/TXfdy6ZWCt2l1VjGarrqP9qNyUjI 5Z4xbMyFn+Atj6DSAUYV8sFni/61M9TO5AAJs8Jl1yLCWzMO/EJz8qZSaPeKCUH57iwd unWA/FqLtU3tCt36QSOnwDXZiKHacxx3qJu4wEl5LW8DmAF5pQAiWb/o/OExYqVKJqFz s68hYj14lP3NmgPuFyzMn+W6/UqnyVTT1AgpdVDQuWzupWRN6Z9UTNYd6xiWswYwXWUb fxC2D77mHUrDjRLAffEj2reiu546ArSM5u5dMU/sL/aGwRSASeLIIjJpdmE6hB38OJJO +4NA== X-Gm-Message-State: AKaTC02m72K5eUSETEc475HezWUngxlJHmLISnXUbmlL4U+IiXSZhEkGOYOgXBJ0FbEqxpts7GKrNSLJ/+K3/A== X-Received: by 10.55.77.137 with SMTP id a131mr2260740qkb.249.1479378076664; Thu, 17 Nov 2016 02:21:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.176.6 with HTTP; Thu, 17 Nov 2016 02:21:16 -0800 (PST) From: Nik Tomkinson Date: Thu, 17 Nov 2016 10:21:16 +0000 Message-ID: To: media-types@ietf.org Content-Type: multipart/alternative; boundary=001a11488614bfa47205417c8c17 Archived-At: Subject: [media-types] Registration for multipart/multilingual type 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, 17 Nov 2016 10:21:19 -0000 --001a11488614bfa47205417c8c17 Content-Type: text/plain; charset=UTF-8 Hello all, I am going to be registering a new multipart (multipart/multilingual) with IANA and want to run the registration template past this group for final suggestions: Media Type name: multipart Media subtype name: multilingual Required parameters: boundary (defined in RFC2046) Optional parameters: N/A Encoding considerations: There are no encoding considerations for this multipart other than that of the embedded body parts. The embedded body parts (typically one text/plain plus one or more message/*) may contain ASCII or binary. Security considerations: See the Security Considerations section in this document Interoperability considerations: Existing systems that do not treat unknown multipart subtypes as multipart/mixed might not correctly render a multipart/multilingual type. Published specification: This document Applications that use this media type: Mail Transfer Agents, Mail User Agents, spam detection, virus detection modules and message authentication modules. Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): N/A Macintosh file type code(s): N/A Person & email address to contact for further information: Nik Tomkinson rfc.nik.tomkinson@gmail.com Nathaniel Borenstein nsb@mimecast.com Intended usage: Common -- This relates to the following Internet Draft: Multiple Language Content Type Internet Draft: https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ The Internet Draft currently shows the template with the major difference: Encoding considerations: only "7bit", "8bit", or "binary" are permitted Thanks in advance for your suggestions, Nik Tomkinson. --001a11488614bfa47205417c8c17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all,

I am going to be registering= a new multipart (multipart/multilingual) with IANA and want to run the reg= istration template past this group for final suggestions:

=C2=A0 =C2=A0Media Type name: multipart

=C2=A0 =C2=A0Media subtype name: multilingual

= =C2=A0 =C2=A0Required parameters: boundary (defined in RFC2046)
<= br>
=C2=A0 =C2=A0Optional parameters: N/A

=C2=A0 =C2=A0Encoding considerations: There are no encoding consideration= s for
=C2=A0 =C2=A0 =C2=A0 =C2=A0this multipart other than that o= f the embedded body parts.=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0The e= mbedded body parts (typically one text/plain plus one or
=C2=A0 = =C2=A0 =C2=A0 =C2=A0more message/*) may contain ASCII or binary.
=
=C2=A0 =C2=A0Security considerations: See the Security Consi= derations section
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in this document
=

=C2=A0 =C2=A0Interoperability considerations:
=C2=A0 =C2=A0 =C2=A0 =C2=A0Existing systems that do not treat unknown mult= ipart subtypes
=C2=A0 =C2=A0 =C2=A0 =C2=A0as multipart/mixed migh= t not correctly render a
=C2=A0 =C2=A0 =C2=A0 =C2=A0multipart/mul= tilingual type.

=C2=A0 =C2=A0Published specificati= on: This document

=C2=A0 =C2=A0Applications that u= se this media type:
=C2=A0 =C2=A0 =C2=A0 =C2=A0Mail Transfer Agen= ts, Mail User Agents, spam detection,
=C2=A0 =C2=A0 =C2=A0 =C2=A0= virus detection modules and message authentication modules.

<= /div>
=C2=A0 =C2=A0Additional information:
=C2=A0 =C2=A0 =C2= =A0 =C2=A0Deprecated alias names for this type: N/A
=C2=A0 =C2=A0= =C2=A0 =C2=A0Magic number(s): N/A
=C2=A0 =C2=A0 =C2=A0 =C2=A0Fil= e extension(s): N/A
=C2=A0 =C2=A0 =C2=A0 =C2=A0Macintosh file typ= e code(s): N/A

=C2=A0 =C2=A0Person & email add= ress to contact for further information:
=C2=A0 =C2=A0 =C2=A0 =C2= =A0Nik Tomkinson
=C2=A0 =C2=A0 =C2=A0 =C2=A0rfc.nik.tomkinson@gmail.com

=C2=A0 =C2=A0 =C2=A0 =C2=A0Nathaniel Borenstein
=C2=A0 = =C2=A0 =C2=A0 =C2=A0nsb@mimecast.com

--=C2=A0
This relates to the following Internet Draft:
The Internet Draft currently shows the templat= e with the major difference:

=C2=A0 =C2=A0Enc= oding considerations: only "7bit", "8bit", or "bin= ary" are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 permitted
=
Thanks in advance for your suggestions,

Nik Tomkinson.
--001a11488614bfa47205417c8c17-- From nobody Thu Nov 17 02:24:58 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 85BD91296B4 for ; Thu, 17 Nov 2016 02:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 etXyTzFdp1hR for ; Thu, 17 Nov 2016 02:24:56 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 BC4F9129641 for ; Thu, 17 Nov 2016 02:24:55 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id w33so126647333qtc.3 for ; Thu, 17 Nov 2016 02:24:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=R3erQuAr9KQ+8kHUfY5e17kHTh00eqSkB84GLOvNw+8=; b=X16qU6M8ucO6/fayhPLqWhjkA//YlBTh7rFUC96MndBBBiWME8OkaMGbx2ZCDRw0R4 0L+2CQOJfx/Bys1W+5U1ghiiZ+LQm+5b0K0ffJz4m0Iev5Yi+3SnyNPcEUhDnGaozNSJ HyYo5W6d6S0VK9dRNgVFvMr4+jxc2SAHH1CoB97k+Glpz1Y7+cTP2VmQs6szJc3xYhEf Q6cBJCf2eVhHb8rj6wTK/MKXpywWz5XK6dQyRNu2u3acZHvc5Cf8Uh+NiiFmHtr1su29 wzMtB93N0Se5QtOEsad5jB6MO802OGWPDneD6AvUdTQCysLzbX+uFuNYvYopnYSAs490 R8CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=R3erQuAr9KQ+8kHUfY5e17kHTh00eqSkB84GLOvNw+8=; b=hEBLM1kSOPvkuvnos49ibGYADsGqj4I5sjHY5SbMULFlXbLk0nXPjaDKWFy1v1CyyN Ha/TZdeF4Yksl3k7HvuzjydmR8MHlp41zSBvIOt+LHwAwFWAWs7M0xkygob7Fpagmxq1 wW9hielYDEThPVTFXq4A1lmh1XBs7Ddl4sL5/pzkZ66wUS9nSPwrGMLH/Jwpy3SISSFt Fa05C2jHWU8gQH+Plk/lEsIIPgKhO1vU3+uokRMAQqFWx4D3V4CcN/vLGTKLaTGxqlpm oST6F8bnGqDgI/l/OWDrUrcb9VJlgXHKZU8sVN/tLv+Q49Jf6yxaEKUuMVj8Mv/Uenns +XhA== X-Gm-Message-State: AKaTC00wuai/Zgyh8PnziLTdSWSLh4Te1vPL3lJiJpjB41LKjI1dMkCCEcwbWzmfnqU9mJS0f2AIesYL69DHjA== X-Received: by 10.200.36.98 with SMTP id d31mr1271633qtd.268.1479378294817; Thu, 17 Nov 2016 02:24:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.176.6 with HTTP; Thu, 17 Nov 2016 02:24:54 -0800 (PST) In-Reply-To: References: From: Nik Tomkinson Date: Thu, 17 Nov 2016 10:24:54 +0000 Message-ID: To: media-types@ietf.org Content-Type: multipart/alternative; boundary=001a113f0c8cc046df05417c9955 Archived-At: Subject: Re: [media-types] Registration for multipart/multilingual type 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, 17 Nov 2016 10:24:57 -0000 --001a113f0c8cc046df05417c9955 Content-Type: text/plain; charset=UTF-8 The location of the latest/correct Internet Draft is this: https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent Nik. On 17 November 2016 at 10:21, Nik Tomkinson wrote: > Hello all, > > I am going to be registering a new multipart (multipart/multilingual) with > IANA and want to run the registration template past this group for final > suggestions: > > Media Type name: multipart > > Media subtype name: multilingual > > Required parameters: boundary (defined in RFC2046) > > Optional parameters: N/A > > Encoding considerations: There are no encoding considerations for > this multipart other than that of the embedded body parts. > The embedded body parts (typically one text/plain plus one or > more message/*) may contain ASCII or binary. > > Security considerations: See the Security Considerations section > in this document > > Interoperability considerations: > Existing systems that do not treat unknown multipart subtypes > as multipart/mixed might not correctly render a > multipart/multilingual type. > > Published specification: This document > > Applications that use this media type: > Mail Transfer Agents, Mail User Agents, spam detection, > virus detection modules and message authentication modules. > > Additional information: > Deprecated alias names for this type: N/A > Magic number(s): N/A > File extension(s): N/A > Macintosh file type code(s): N/A > > Person & email address to contact for further information: > Nik Tomkinson > rfc.nik.tomkinson@gmail.com > > Nathaniel Borenstein > nsb@mimecast.com > > Intended usage: Common > > -- > This relates to the following Internet Draft: > > Multiple Language Content Type Internet Draft: > > > https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ > > > The Internet Draft currently shows the template with the major difference: > > Encoding considerations: only "7bit", "8bit", or "binary" are > permitted > > Thanks in advance for your suggestions, > > Nik Tomkinson. > -- ----------------------------------------------------------------- Multiple Language Content Type Internet Draft: https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ ----------------------------------------------------------------- --001a113f0c8cc046df05417c9955 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The location of the latest/correct Internet Draft is this:= =C2=A0h= ttps://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent=

<= /span>
Nik.

On 17 November 2016 at 10:21, Nik Tomkinson = <rfc.ni= k.tomkinson@gmail.com> wrote:
Hello all,

I am going to be register= ing a new multipart (multipart/multilingual) with IANA and want to run the = registration template past this group for final suggestions:

=
=C2=A0 =C2=A0Media Type name: multipart

=C2=A0 =C2=A0Media subtype name: multilingual

=C2=A0 =C2=A0Required parameters: boundary (defined in RFC2046)

=C2=A0 =C2=A0Optional parameters: N/A

<= div>=C2=A0 =C2=A0Encoding considerations: There are no encoding considerati= ons for
=C2=A0 =C2=A0 =C2=A0 =C2=A0this multipart other than that= of the embedded body parts.=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0The= embedded body parts (typically one text/plain plus one or
=C2=A0= =C2=A0 =C2=A0 =C2=A0more message/*) may contain ASCII or binary.

=C2=A0 =C2=A0Security considerations: See the Security Cons= iderations section
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in this document
=

=C2=A0 =C2=A0Interoperability considerations:
=C2=A0 =C2=A0 =C2=A0 =C2=A0Existing systems that do not treat unknown mult= ipart subtypes
=C2=A0 =C2=A0 =C2=A0 =C2=A0as multipart/mixed migh= t not correctly render a
=C2=A0 =C2=A0 =C2=A0 =C2=A0multipart/mul= tilingual type.

=C2=A0 =C2=A0Published specificati= on: This document

=C2=A0 =C2=A0Applications that u= se this media type:
=C2=A0 =C2=A0 =C2=A0 =C2=A0Mail Transfer Agen= ts, Mail User Agents, spam detection,
=C2=A0 =C2=A0 =C2=A0 =C2=A0= virus detection modules and message authentication modules.

<= /div>
=C2=A0 =C2=A0Additional information:
=C2=A0 =C2=A0 =C2= =A0 =C2=A0Deprecated alias names for this type: N/A
=C2=A0 =C2=A0= =C2=A0 =C2=A0Magic number(s): N/A
=C2=A0 =C2=A0 =C2=A0 =C2=A0Fil= e extension(s): N/A
=C2=A0 =C2=A0 =C2=A0 =C2=A0Macintosh file typ= e code(s): N/A

=C2=A0 =C2=A0Person & email add= ress to contact for further information:
=C2=A0 =C2=A0 =C2=A0 =C2= =A0Nik Tomkinson
=C2=A0 =C2=A0 =C2=A0 =C2=A0rfc.nik.tomkinson@gmail.com=

=C2=A0 =C2=A0 =C2=A0 =C2=A0Nathaniel Borenstein
=C2=A0 =C2=A0 =C2=A0 =C2=A0nsb@mimecast.com

=C2=A0 =C2=A0I= ntended usage: Common

--=C2=A0
This relates t= o the following Internet Draft:
<= div>
Multiple Language Content Type Internet Draft:
https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/

The Internet Draft currently shows the template with th= e major difference:

=C2=A0 =C2=A0Encoding con= siderations: only "7bit", "8bit", or "binary"= are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 permitted

=
Thanks in advance for your suggestions,

Nik Tomkinson.
<= /div>



-- 
-------------------------------=
----------------------------------
Multiple Language Content Type Intern=
et Draft:
https://datatracker.= ietf.org/doc/draft-ietf-slim-multilangcontent/
-----------------------------------------=
------------------------
--001a113f0c8cc046df05417c9955-- From nobody Thu Nov 17 17:15:32 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 30EDA129842 for ; Thu, 17 Nov 2016 17:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 F6JLzqHZ_Zqd for ; Thu, 17 Nov 2016 17:15:30 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 28697129865 for ; Thu, 17 Nov 2016 17:15:05 -0800 (PST) Received: from dhcp-898b.meeting.ietf.org (unknown [31.133.137.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3AD9522E1FA; Thu, 17 Nov 2016 20:14:57 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_096BCE71-7A01-48C7-A6E8-A13AFD982A5E" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: Date: Fri, 18 Nov 2016 10:14:55 +0900 Message-Id: <897D25BE-CE7F-46B0-9FD4-6BB6BC32C578@seantek.com> References: To: Nik Tomkinson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: media-types@ietf.org Subject: Re: [media-types] Registration for multipart/multilingual type 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, 18 Nov 2016 01:15:32 -0000 --Apple-Mail=_096BCE71-7A01-48C7-A6E8-A13AFD982A5E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Looks good to me. Carry on. Sean > On Nov 17, 2016, at 7:24 PM, Nik Tomkinson = wrote: >=20 > The location of the latest/correct Internet Draft is this: = https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent = >=20 > Nik. >=20 > On 17 November 2016 at 10:21, Nik Tomkinson = > = wrote: > Hello all, >=20 > I am going to be registering a new multipart (multipart/multilingual) = with IANA and want to run the registration template past this group for = final suggestions: >=20 > Media Type name: multipart >=20 > Media subtype name: multilingual >=20 > Required parameters: boundary (defined in RFC2046) >=20 > Optional parameters: N/A >=20 > Encoding considerations: There are no encoding considerations for > this multipart other than that of the embedded body parts.=20 > The embedded body parts (typically one text/plain plus one or > more message/*) may contain ASCII or binary. >=20 > Security considerations: See the Security Considerations section > in this document >=20 > Interoperability considerations: > Existing systems that do not treat unknown multipart subtypes > as multipart/mixed might not correctly render a > multipart/multilingual type. >=20 > Published specification: This document >=20 > Applications that use this media type: > Mail Transfer Agents, Mail User Agents, spam detection, > virus detection modules and message authentication modules. >=20 > Additional information: > Deprecated alias names for this type: N/A > Magic number(s): N/A > File extension(s): N/A > Macintosh file type code(s): N/A >=20 > Person & email address to contact for further information: > Nik Tomkinson > rfc.nik.tomkinson@gmail.com = >=20 > Nathaniel Borenstein > nsb@mimecast.com >=20 > Intended usage: Common >=20 > --=20 > This relates to the following Internet Draft: > Multiple Language Content Type Internet Draft: > = https:/= /datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ = >=20 > The Internet Draft currently shows the template with the major = difference: >=20 > Encoding considerations: only "7bit", "8bit", or "binary" are > permitted >=20 > Thanks in advance for your suggestions, >=20 > Nik Tomkinson. >=20 >=20 >=20 > --=20 > ----------------------------------------------------------------- > Multiple Language Content Type Internet Draft: > = https:/= /datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ = > ----------------------------------------------------------------- > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types --Apple-Mail=_096BCE71-7A01-48C7-A6E8-A13AFD982A5E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Looks good to me. Carry on.

Sean

On = Nov 17, 2016, at 7:24 PM, Nik Tomkinson <rfc.nik.tomkinson@gmail.com> wrote:

The location of the latest/correct Internet Draft is = this: https://datatracker.ietf.org/doc/draft-ietf-slim-multilangconte= nt
Nik.

On 17 November 2016 at 10:21, Nik = Tomkinson <rfc.nik.tomkinson@gmail.com> wrote:
Hello all,

I am going to be registering a new multipart = (multipart/multilingual) with IANA and want to run the registration = template past this group for final suggestions:

   Media Type = name: multipart

   Media subtype name: multilingual

   Required = parameters: boundary (defined in RFC2046)

   Optional parameters: = N/A

  =  Encoding considerations: There are no encoding considerations = for
       this multipart other = than that of the embedded body parts. 
  =      The embedded body parts (typically one text/plain = plus one or
       more = message/*) may contain ASCII or binary.

   Security considerations: = See the Security Considerations section
  =                     =       in this document

   Interoperability = considerations:
       Existing = systems that do not treat unknown multipart subtypes
       as multipart/mixed might not = correctly render a
      =  multipart/multilingual type.

   Published specification: = This document

   Applications that use this media type:
       Mail Transfer Agents, Mail User = Agents, spam detection,
      =  virus detection modules and message authentication = modules.

  =  Additional information:
      =  Deprecated alias names for this type: N/A
       Magic number(s): N/A
       File extension(s): N/A
       Macintosh file type code(s): = N/A

  =  Person & email address to contact for further = information:
       Nik = Tomkinson
       rfc.nik.tomkinson@gmail.com

       Nathaniel = Borenstein
       nsb@mimecast.com

   Intended usage: = Common

-- 
This relates to the following Internet Draft:
Multiple Language Content Type Internet =
Draft:
https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/

The Internet Draft currently shows the = template with the major difference:

   Encoding = considerations: only "7bit", "8bit", or "binary" are
                =             permitted

Thanks in = advance for your suggestions,

Nik = Tomkinson.



-- 
---------------------------------------------------------------=
--
Multiple Language Content Type Internet =
Draft:
https://datatracker.ietf.org/doc/draft-ietf-slim-multilangconte= nt/
---------------------------------------------------------------=
--
_______________________________________________
media-types = mailing list
media-types@ietf.org
https://www.ietf.org/mailman/listinfo/media-types

= --Apple-Mail=_096BCE71-7A01-48C7-A6E8-A13AFD982A5E-- From nobody Thu Nov 17 22:54:46 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 A3BD112959C for ; Thu, 17 Nov 2016 22:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Oknwd94C_xMY for ; Thu, 17 Nov 2016 22:54:42 -0800 (PST) Received: from bin-vsp-out-02.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (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 58ECC129457 for ; Thu, 17 Nov 2016 22:54:42 -0800 (PST) X-Halon-ID: dee017a5-ad5b-11e6-8413-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from unknown (unknown [83.209.159.45]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id dee017a5-ad5b-11e6-8413-005056917f90; Fri, 18 Nov 2016 07:54:37 +0100 (CET) To: media-types@ietf.org References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Fri, 18 Nov 2016 07:54:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A0B750E28D4D8A074821082B" Archived-At: Subject: Re: [media-types] Registration for multipart/multilingual type 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, 18 Nov 2016 06:54:45 -0000 This is a multi-part message in MIME format. --------------A0B750E28D4D8A074821082B Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Nik, In the "Encoding Considerations", you mention ASCII. Why? Reading RFC 6838 section 4.8, where the encoding considerations field is defined, only 7-bit, 8-bit, binary and framed are mentioned as possible values. It seems that you just want to expess total freedom for encoding, so therefore I suggest that you replace "may contain ASCII or binary." with "may contain 7-bit, 8-bit or binary encodings". (or mention all four if also "framed" is possible. ) Regards Gunnar Den 2016-11-17 kl. 11:24, skrev Nik Tomkinson: > The location of the latest/correct Internet Draft is this: > https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent > On 17 November 2016 at 10:21, Nik Tomkinson > > wrote: > > Hello all, > > I am going to be registering a new multipart > (multipart/multilingual) with IANA and want to run the > registration template past this group for final suggestions: > > Media Type name: multipart > > Media subtype name: multilingual > > Required parameters: boundary (defined in RFC2046) > > Optional parameters: N/A > > Encoding considerations: There are no encoding considerations for > this multipart other than that of the embedded body parts. > The embedded body parts (typically one text/plain plus one or > more message/*) may contain ASCII or binary. > > Security considerations: See the Security Considerations section > in this document > > Interoperability considerations: > Existing systems that do not treat unknown multipart subtypes > as multipart/mixed might not correctly render a > multipart/multilingual type. > > Published specification: This document > > Applications that use this media type: > Mail Transfer Agents, Mail User Agents, spam detection, > virus detection modules and message authentication modules. > > Additional information: > Deprecated alias names for this type: N/A > Magic number(s): N/A > File extension(s): N/A > Macintosh file type code(s): N/A > > Person & email address to contact for further information: > Nik Tomkinson > rfc.nik.tomkinson@gmail.com > > Nathaniel Borenstein > nsb@mimecast.com > > Intended usage: Common > > -- > This relates to the following Internet Draft: > > Multiple Language Content Type Internet Draft: > > https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ > > > The Internet Draft currently shows the template with the major > difference: > > Encoding considerations: only "7bit", "8bit", or "binary" are > permitted > > Thanks in advance for your suggestions, > > Nik Tomkinson. > > > > > -- > ----------------------------------------------------------------- > Multiple Language Content Type Internet Draft: > https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ > > ----------------------------------------------------------------- > > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------A0B750E28D4D8A074821082B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Nik,

In the "Encoding Considerations", you mention ASCII. Why?

Reading RFC 6838 section 4.8, where the encoding considerations field is defined, only 7-bit, 8-bit, binary and framed are mentioned as possible values.

It seems that you just want to expess total freedom for encoding, so therefore I suggest that you replace "may contain ASCII or binary." with "may contain 7-bit, 8-bit or binary encodings".

(or mention all four if also "framed" is possible.  )

Regards

Gunnar


Den 2016-11-17 kl. 11:24, skrev Nik Tomkinson:
The location of the latest/correct Internet Draft is this: https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent
On 17 November 2016 at 10:21, Nik Tomkinson <rfc.nik.tomkinson@gmail.com> wrote:
Hello all,

I am going to be registering a new multipart (multipart/multilingual) with IANA and want to run the registration template past this group for final suggestions:

   Media Type name: multipart

   Media subtype name: multilingual

   Required parameters: boundary (defined in RFC2046)

   Optional parameters: N/A

   Encoding considerations: There are no encoding considerations for
       this multipart other than that of the embedded body parts. 
       The embedded body parts (typically one text/plain plus one or
       more message/*) may contain ASCII or binary.

   Security considerations: See the Security Considerations section
                            in this document

   Interoperability considerations:
       Existing systems that do not treat unknown multipart subtypes
       as multipart/mixed might not correctly render a
       multipart/multilingual type.

   Published specification: This document

   Applications that use this media type:
       Mail Transfer Agents, Mail User Agents, spam detection,
       virus detection modules and message authentication modules.

   Additional information:
       Deprecated alias names for this type: N/A
       Magic number(s): N/A
       File extension(s): N/A
       Macintosh file type code(s): N/A

   Person & email address to contact for further information:
       Nik Tomkinson

       Nathaniel Borenstein
       nsb@mimecast.com

   Intended usage: Common

-- 
This relates to the following Internet Draft:
Multiple Language Content Type Internet Draft:
https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/

The Internet Draft currently shows the template with the major difference:

   Encoding considerations: only "7bit", "8bit", or "binary" are
                            permitted

Thanks in advance for your suggestions,

Nik Tomkinson.



-- 
-----------------------------------------------------------------
Multiple Language Content Type Internet Draft:
https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/
-----------------------------------------------------------------



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


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------A0B750E28D4D8A074821082B-- From nobody Fri Nov 18 03:50:59 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 731F91294D4 for ; Fri, 18 Nov 2016 03:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 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, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-1.497, 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 Sv5I1EKgRwUq for ; Fri, 18 Nov 2016 03:50:55 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8C6129615 for ; Fri, 18 Nov 2016 03:50:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1479469853; d=isode.com; s=june2016; i=@isode.com; bh=TkAS/vTAjcluIKcatfXDH0fjrPWCPFzFnsqAJYZypoo=; 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=m8yH70yRTUb2s7WjJSz1wh396pG3WYPa5Wp2NBVATrPWHzb0vkd7ZuuDHoW/9dqwbm6/dZ m5/IOAecKHDupOTtt5E1JWDk8YZ3b9ViEPyMBrhFGjA6tEQSKuO5OxIHMGSOK1WHR7JjE4 7sUW/6nu2UdJNP+MmdFZoTB2b8U+Yr8=; Received: from [192.168.219.121] ((unknown) [106.255.97.69]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 18 Nov 2016 11:50:52 +0000 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Fri, 18 Nov 2016 20:56:52 +0900 Message-Id: References: To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-2CA0A6BC-0C90-4F28-9F64-240CAA4D29AD Content-Transfer-Encoding: 7bit Archived-At: Cc: media-types@ietf.org Subject: Re: [media-types] Registration for multipart/multilingual type 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, 18 Nov 2016 11:50:57 -0000 --Apple-Mail-2CA0A6BC-0C90-4F28-9F64-240CAA4D29AD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 18 Nov 2016, at 15:54, Gunnar Hellstr=C3=B6m wrote: >=20 > Nik, >=20 > In the "Encoding Considerations", you mention ASCII. Why?=20 > Reading RFC 6838 section 4.8, where the encoding considerations field is d= efined, only 7-bit, 8-bit, binary and framed are mentioned as possible value= s. >=20 > It seems that you just want to expess total freedom for encoding, so there= fore I suggest that you replace "may contain ASCII or binary." with "may con= tain 7-bit, 8-bit or binary encodings". >=20 +1. > (or mention all four if also "framed" is possible. ) >=20 This doesn't apply, I think. > Regards >=20 > Gunnar >=20 >> Den 2016-11-17 kl. 11:24, skrev Nik Tomkinson: >> The location of the latest/correct Internet Draft is this: https://datatr= acker.ietf.org/doc/draft-ietf-slim-multilangcontent >>> On 17 November 2016 at 10:21, Nik Tomkinson wrote: >>> Hello all, >>>=20 >>> I am going to be registering a new multipart (multipart/multilingual) wi= th IANA and want to run the registration template past this group for final s= uggestions: >>>=20 >>> Media Type name: multipart >>>=20 >>> Media subtype name: multilingual >>>=20 >>> Required parameters: boundary (defined in RFC2046) >>>=20 >>> Optional parameters: N/A >>>=20 >>> Encoding considerations: There are no encoding considerations for >>> this multipart other than that of the embedded body parts.=20 >>> The embedded body parts (typically one text/plain plus one or >>> more message/*) may contain ASCII or binary. >>>=20 >>> Security considerations: See the Security Considerations section >>> in this document >>>=20 >>> Interoperability considerations: >>> Existing systems that do not treat unknown multipart subtypes >>> as multipart/mixed might not correctly render a= >>> multipart/multilingual type. >>>=20 >>> Published specification: This document >>>=20 >>> Applications that use this media type: >>> Mail Transfer Agents, Mail User Agents, spam detection, >>> virus detection modules and message authentication modules. >>>=20 >>> Additional information: >>> Deprecated alias names for this type: N/A >>> Magic number(s): N/A >>> File extension(s): N/A >>> Macintosh file type code(s): N/A >>>=20 >>> Person & email address to contact for further information: >>> Nik Tomkinson >>> rfc.nik.tomkinson@gmail.com >>>=20 >>> Nathaniel Borenstein >>> nsb@mimecast.com >>>=20 >>> Intended usage: Common >>>=20 >>> --=20 >>> This relates to the following Internet Draft: >>> Multiple Language Content Type Internet Draft: >>> https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ >>>=20 >>> The Internet Draft currently shows the template with the major differenc= e: >>>=20 >>> Encoding considerations: only "7bit", "8bit", or "binary" are >>> permitted >>>=20 >>> Thanks in advance for your suggestions, >>>=20 >>> Nik Tomkinson. >>=20 >>=20 >>=20 >> --=20 >> ----------------------------------------------------------------- >> Multiple Language Content Type Internet Draft: >> https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ >> ----------------------------------------------------------------- >>=20 >>=20 >> _______________________________________________ >> media-types mailing list >> media-types@ietf.org >> https://www.ietf.org/mailman/listinfo/media-types >=20 > --=20 > ----------------------------------------- > Gunnar Hellstr=C3=B6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types --Apple-Mail-2CA0A6BC-0C90-4F28-9F64-240CAA4D29AD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 18 Nov 2016, at 15:5= 4, Gunnar Hellstr=C3=B6m <= gunnar.hellstrom@omnitor.se> wrote:

=20 =20 =20

Nik,

In the "Encoding Considerations", you mention ASCII. Why?

Reading RFC 6838 section 4.8, where the encoding considerations field is defined, only 7-bit, 8-bit, binary and framed are mentioned as possible values.

It seems that you just want to expess total freedom for encoding, so therefore I suggest that you replace "may contain ASCII or binary." with "may contain 7-bit, 8-bit or binary encodings".


+1.

(or mention all four if also "framed" is possible.  )

<= /blockquote>

This doesn't apply, I think.

Regards

Gunnar


Den 2016-11-17 kl. 11:24, skrev Nik Tomkinson:
The location of the latest/correct Internet Draft is this: https://datatracker.ietf.org/doc/draft-= ietf-slim-multilangcontent
On 17 November 2016 at 10:21, Nik Tomkinson <rfc.nik.tomkinson@gma= il.com> wrote:
Hello all,

I am going to be registering a new multipart (multipart/multilingual) with IANA and want to run the registration template past this group for final suggestions:

   Media Type name: multipart

   Media subtype name: multilingual

   Required parameters: boundary (defined in RFC2046)

   Optional parameters: N/A

   Encoding considerations: There are no enco= ding considerations for
       this multipart other than th= at of the embedded body parts. 
       The embedded body parts (typ= ically one text/plain plus one or
       more message/*) may contain A= SCII or binary.

   Security considerations: See the Security Considerations section
               =             in this document

   Interoperability considerations:
       Existing systems that do not= treat unknown multipart subtypes
       as multipart/mixed might not= correctly render a
       multipart/multilingual type.=

   Published specification: This document

   Applications that use this media type:
       Mail Transfer Agents, Mail U= ser Agents, spam detection,
       virus detection modules and m= essage authentication modules.

   Additional information:
       Deprecated alias names for t= his type: N/A
       Magic number(s): N/A
       File extension(s): N/A
=
       Macintosh file type code(s):= N/A

   Person & email address to contact for further information:
       Nik Tomkinson

       Nathaniel Borenstein
       nsb@mimecast.com
=

   Intended usage: Common

-- 
This relates to the following Internet Draft:
Multiple Language Content Type Internet Draft:=
https://datatracker.ietf.org/= doc/draft-ietf-slim-multilangcontent/

The Internet Draft currently shows the template with the major difference:

   Encoding considerations: onl= y "7bit", "8bit", or "binary" are
           =                 permitted

Thanks in advance for your suggestions,

Nik Tomkinson.



-- 
-----------------------------------------------------------------
Multiple Language Content Type Internet Draft:
https://datatracker.ietf.org/doc/draft-ietf-slim= -multilangcontent/
-----------------------------------------------------------------



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


--=20
-----------------------------------------
Gunnar Hellstr=C3=B6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
=20
____________________= ___________________________
media-types mailing list<= br>media-types@ietf.org
= https://www.ietf.org/mailman/listinfo/media-types
= --Apple-Mail-2CA0A6BC-0C90-4F28-9F64-240CAA4D29AD-- From nobody Fri Nov 18 11:45: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 AD98A1294D6 for ; Fri, 18 Nov 2016 11:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 KslRURwbyFCp for ; Fri, 18 Nov 2016 11:45:25 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 6B58E12943E for ; Fri, 18 Nov 2016 11:45:25 -0800 (PST) Received: from [10.35.141.224] (unknown [58.123.138.206]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 07EE150A84; Fri, 18 Nov 2016 14:45:22 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_8D257B26-205D-4751-8403-569AFB151D61" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: Date: Sat, 19 Nov 2016 04:45:20 +0900 Message-Id: <100E34A5-8AB0-412B-9113-D38B13D1A199@seantek.com> References: To: Alexey Melnikov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: media-types@ietf.org, =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= Subject: Re: [media-types] Registration for multipart/multilingual type 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, 18 Nov 2016 19:45:27 -0000 --Apple-Mail=_8D257B26-205D-4751-8403-569AFB151D61 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 18, 2016, at 8:56 PM, Alexey Melnikov = wrote: >=20 >=20 > On 18 Nov 2016, at 15:54, Gunnar Hellstr=C3=B6m = > = wrote: >=20 >> Nik, >>=20 >> In the "Encoding Considerations", you mention ASCII. Why?=20 >> Reading RFC 6838 section 4.8, where the encoding considerations field = is defined, only 7-bit, 8-bit, binary and framed are mentioned as = possible values. >>=20 >> It seems that you just want to expess total freedom for encoding, so = therefore I suggest that you replace "may contain ASCII or binary." with = "may contain 7-bit, 8-bit or binary encodings". >>=20 >=20 > +1. >> (or mention all four if also "framed" is possible. ) >>=20 >=20 > This doesn't apply, I think. Overall I agree with Gunnar Hellstr=C3=B6m, in that his proposed text is = in keeping with prior registration in the multipart media type, and = other registrations. (I checked several of the multipart registrations.) = For example, the contents can be =E2=80=9C7bit=E2=80=9D without actually = being in ASCII: there are other charsets that can be expressed in 7-bit = (including the wide range that are encoded as base64 or = quoted-printable). Regards, Sean >> Regards >>=20 >> Gunnar >>=20 >> Den 2016-11-17 kl. 11:24, skrev Nik Tomkinson: >>> The location of the latest/correct Internet Draft is this: = https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent = >>> On 17 November 2016 at 10:21, Nik Tomkinson = > = wrote: >>> Hello all, >>>=20 >>> I am going to be registering a new multipart = (multipart/multilingual) with IANA and want to run the registration = template past this group for final suggestions: >>>=20 >>> Media Type name: multipart >>>=20 >>> Media subtype name: multilingual >>>=20 >>> Required parameters: boundary (defined in RFC2046) >>>=20 >>> Optional parameters: N/A >>>=20 >>> Encoding considerations: There are no encoding considerations for >>> this multipart other than that of the embedded body parts.=20 >>> The embedded body parts (typically one text/plain plus one or >>> more message/*) may contain ASCII or binary. >>>=20 >>> Security considerations: See the Security Considerations section >>> in this document >>>=20 >>> Interoperability considerations: >>> Existing systems that do not treat unknown multipart subtypes >>> as multipart/mixed might not correctly render a >>> multipart/multilingual type. >>>=20 >>> Published specification: This document >>>=20 >>> Applications that use this media type: >>> Mail Transfer Agents, Mail User Agents, spam detection, >>> virus detection modules and message authentication modules. >>>=20 >>> Additional information: >>> Deprecated alias names for this type: N/A >>> Magic number(s): N/A >>> File extension(s): N/A >>> Macintosh file type code(s): N/A >>>=20 >>> Person & email address to contact for further information: >>> Nik Tomkinson >>> rfc.nik.tomkinson@gmail.com = >>>=20 >>> Nathaniel Borenstein >>> nsb@mimecast.com >>>=20 >>> Intended usage: Common >>>=20 >>> --=20 >>> This relates to the following Internet Draft: >>> Multiple Language Content Type Internet Draft: >>> = https:/= /datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ = >>>=20 >>> The Internet Draft currently shows the template with the major = difference: >>>=20 >>> Encoding considerations: only "7bit", "8bit", or "binary" are >>> permitted >>>=20 >>> Thanks in advance for your suggestions, >>>=20 >>> Nik Tomkinson. >>>=20 >>>=20 >>>=20 >>> --=20 >>> ----------------------------------------------------------------- >>> Multiple Language Content Type Internet Draft: >>> = https:/= /datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ = >>> ----------------------------------------------------------------- >>>=20 >>>=20 >>> _______________________________________________ >>> media-types mailing list >>> media-types@ietf.org >>> https://www.ietf.org/mailman/listinfo/media-types = >>=20 >> --=20 >> ----------------------------------------- >> Gunnar Hellstr=C3=B6m >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46 708 204 288 >> _______________________________________________ >> media-types mailing list >> media-types@ietf.org >> https://www.ietf.org/mailman/listinfo/media-types = > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types --Apple-Mail=_8D257B26-205D-4751-8403-569AFB151D61 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 18, 2016, at 8:56 PM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:


On 18 Nov 2016, at 15:54, Gunnar = Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> wrote:

=20

Nik,

In the "Encoding Considerations", you mention ASCII. Why?

Reading RFC 6838 section 4.8, where the encoding = considerations field is defined, only 7-bit, 8-bit, binary and framed are mentioned as possible values.

It seems that you = just want to expess total freedom for encoding, so therefore I suggest that you replace "may contain ASCII or binary." with "may contain 7-bit, 8-bit or binary = encodings".


+1.

(or mention all four if also = "framed" is possible.  )


This doesn't apply, I think.

Overall= I agree with Gunnar Hellstr=C3=B6m, in that his proposed text is in = keeping with prior registration in the multipart media type, and other = registrations. (I checked several of the multipart registrations.) For = example, the contents can be =E2=80=9C7bit=E2=80=9D without actually = being in ASCII: there are other charsets that can be expressed in 7-bit = (including the wide range that are encoded as base64 or = quoted-printable).

Regards,

Sean


Regards

Gunnar


Den 2016-11-17 kl. 11:24, skrev Nik Tomkinson:
The location of the latest/correct = Internet Draft is this: https://datatracker.ietf.org/doc/draft-ietf-slim-multilangconte= nt
On 17 November 2016 at 10:21, Nik Tomkinson <rfc.nik.tomkinson@gmail.com> wrote:
Hello all,

I am going to be registering a new = multipart (multipart/multilingual) with IANA and want to run the registration template past this group for final suggestions:

   Media Type name: = multipart

   Media subtype name: = multilingual

   Required parameters: = boundary (defined in RFC2046)

   Optional parameters: = N/A

   Encoding considerations: = There are no encoding considerations for
       this = multipart other than that of the embedded body parts. 
       The embedded = body parts (typically one text/plain plus one or
       more = message/*) may contain ASCII or binary.

   Security considerations: = See the Security Considerations section
          =                   in this = document

   Interoperability = considerations:
       Existing = systems that do not treat unknown multipart subtypes
       as = multipart/mixed might not correctly render a
      =  multipart/multilingual type.

   Published specification: = This document

   Applications that use this = media type:
       Mail Transfer = Agents, Mail User Agents, spam detection,
       virus = detection modules and message authentication modules.

   Additional = information:
       Deprecated = alias names for this type: N/A
       Magic = number(s): N/A
       File = extension(s): N/A
       Macintosh = file type code(s): N/A

   Person & email address = to contact for further information:
       Nik = Tomkinson
       rfc.nik.tomkinson@gmail.com

       Nathaniel = Borenstein
       nsb@mimecast.com

   Intended usage: = Common

-- 
This relates to the following Internet = Draft:
Multiple Language Content Type Internet Draft:
https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/

The Internet Draft currently = shows the template with the major difference:

   Encoding = considerations: only "7bit", "8bit", or "binary" are
      =                     =   permitted

Thanks in = advance for your suggestions,

Nik Tomkinson.



--
= 
---------------------------------------------------------------=
--
Multiple Language Content Type Internet Draft:
https://datatracker.ietf.org/doc/draft-ietf-slim-multilangconte= nt/
---------------------------------------------------------------=
--



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


--=20
-----------------------------------------
Gunnar Hellstr=C3=B6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
=20
_______________________________________________
media-types mailing list
media-types@ietf.org
https://www.ietf.org/mailman/listinfo/media-types
______________________________________= _________
media-types mailing list
media-types@ietf.org
https://www.ietf.org/mailman/listinfo/media-types

= --Apple-Mail=_8D257B26-205D-4751-8403-569AFB151D61--