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