Re: [ietf-types] Registration of media type application/fdt+xml
Vincent Roca <vincent.roca@inria.fr> Wed, 23 May 2012 14:36 UTC
Return-Path: <vincent.roca@inria.fr>
X-Original-To: ietf-types@ietfa.amsl.com
Delivered-To: ietf-types@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A4321F8741 for <ietf-types@ietfa.amsl.com>; Wed, 23 May 2012 07:36:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.539
X-Spam-Level:
X-Spam-Status: No, score=-109.539 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62rSeFpubuUq for <ietf-types@ietfa.amsl.com>; Wed, 23 May 2012 07:36:32 -0700 (PDT)
Received: from pechora3.lax.icann.org (unknown [IPv6:2620:0:2d0:201::1:73]) by ietfa.amsl.com (Postfix) with ESMTP id 5D48421F8721 for <ietf-types@ietf.org>; Wed, 23 May 2012 07:36:28 -0700 (PDT)
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id q4NEa2Zl000430 for <ietf-types@iana.org>; Wed, 23 May 2012 14:36:23 GMT
X-IronPort-AV: E=Sophos;i="4.75,645,1330902000"; d="scan'208";a="159565804"
Received: from geve.inrialpes.fr ([194.199.24.116]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 23 May 2012 16:19:13 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Vincent Roca <vincent.roca@inria.fr>
In-Reply-To: <j0eor7lmfkgkrhfpqptm52k9jgnd1cp38f@hive.bjoern.hoehrmann.de>
Date: Wed, 23 May 2012 16:19:13 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <10F4C7A9-BAB1-4E61-98D9-42ED1D1E218A@inria.fr>
References: <E1B907DE-95AD-4A43-9023-CDEF2D4BD064@inria.fr> <j0eor7lmfkgkrhfpqptm52k9jgnd1cp38f@hive.bjoern.hoehrmann.de>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
X-Mailer: Apple Mail (2.1084)
X-Greylist: Delayed for 00:16:47 by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Wed, 23 May 2012 14:36:23 +0000 (UTC)
Cc: rmt-chairs@tools.ietf.org, draft-ietf-rmt-flute-revised@tools.ietf.org, Vincent Roca <vincent.roca@inria.fr>, ietf-types@iana.org
Subject: Re: [ietf-types] Registration of media type application/fdt+xml
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-types>
List-Post: <mailto:ietf-types@ietf.org>
List-Help: <mailto:ietf-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 May 2012 14:36:33 -0000
Hello Bjoern, Thanks a lot for your highly valuable comments! My answers and proposal are below. >> The FLUTE-revised I-D (http://tools.ietf.org/html/ietf-rmt-flute-revised-14), >> currently under IESG review, defines in section 8.2 the application/fdt+xml >> Media-Type. Comments on this registration would be greatly appreciated. > >> Optional parameters: none > > There should be a rationale for omitting the 'charset' parameter while > also using the "+xml" convention. The idea of the convention is that you > can process all "+xml" "the same", but if some "+xml" types have a char- > set parameter while others do not, applications would handle, say, > > Content-Type: application/fdt+xml;charset=windows-1252 > > differently, depending on whether they assume it would have a charset > parameter. If I understand the various documents, this is where we need to say that we expect UTF-8. I've kept is as an optional parameter. Is that appropriate? >> Encoding considerations: The fdt+xml type consists of UTF-8 ASCII >> characters [RFC3629] and must be well-formed XML. > > This should use the text in RFC 3023 section 7.1 or specify one of the > values in RFC 4288 ('binary', '8bit', etc.) If I understand, here we can say that we expect any kind of encoding (i.e. binary), since FLUTE, as a communication protocol, does not make any restriction on the data it sends. >> Restrictions on usage: Only for usage with FDT Instances which are >> valid according to the XML schema of section 3.4.2. > > This seems to be redundant and possibly misleading, considering that > similar registrations do not tend to have such text. Removed. >> Applications which use this media type: Not restricted to any >> particular application. Any application, FLUTE included, that sends >> an object that consists of an FDT Instance can use this media type. > > This should say something like "spreadsheet applications", "3D modeling > programs", "bitmap image processors", or whatever, capturing the general > type of application where this is used. Done. >> Additional information: >> >> Magic number(s): none >> File extension(s): An FDT Instance may use the extension ".fdt" >> but this is not required. > > I would make that simply ".fdt", but don't mind the extra text. I have simplified. >> Person and email address to contact for further information: Toni >> Paila (toni.paila (at) nokia.com) > > This is typically rendered `Toni Paila <toni.paila@nokia.com>`. Note > that address harvesters handle obfuscations like this quite well, and > all it takes is one of them getting it right since address lists are > shared and cheap. You're right especially as the full email address is already in the document. To summarize, here is the new version: NEW: 8.3. Registration of the application/fdt+xml Media-Type IANA is asked to register a new namespace in the IETF XML Registry (http://www.iana.org/assignments/xml-registry/ns.html) [RFC3688], using the following registration template: Type name: application Subtype name: fdt+xml Required parameters: none Optional parameters: charset="utf-8" Encoding considerations: binary (the FLUTE file delivery procol does not impose any restriction on the objects it carries and in particular on the FDT Instance itself) Restrictions on usage: none Security considerations: fdt+xml data is passive, and does not generally represent a unique or new security threat. However, there is some risk in sharing any kind of data, in that unintentional information may be exposed, and that risk applies to fdt+xml data as well. Interoperability considerations: None Published specification: The present document including section 3.4.2. The specified FDT Instance functions as an actual media format of use to the general Internet community and thus media type registration under the Standards Tree is appropriate to maximize interoperability. Applications which use this media type: file and object delivery applications and protocols (e.g., FLUTE). Additional information: Magic number(s): none File extension(s): ".fdt" (e.g., if there is a need to store an FDT Instance as a file); Macintosh File Type Code(s): none Person and email address to contact for further information: Toni Paila (toni.paila@nokia.com) Intended usage: Common Author/Change controller: IETF Cheers, Vincent
- [ietf-types] Registration of media type applicati… Vincent Roca
- Re: [ietf-types] Registration of media type appli… Bjoern Hoehrmann
- Re: [ietf-types] Registration of media type appli… Vincent Roca