Subject: [ietf-types] Registration of media type application/fdt+xml

From: Vincent Roca <[email-masked]>
Date: Tue, 22 May 2012 16:14:02 +0200

Hello,

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.

Thanks!
Cheers,

   Vincent

---

   Type name: application

   Subtype name: fdt+xml

   Required parameters: none

   Optional parameters: none

   Encoding considerations: The fdt+xml type consists of UTF-8 ASCII
   characters [RFC3629] and must be well-formed XML.

   Additional content and transfer encodings may be used with fdt+xml
   files, with the appropriate encoding for any specific file being
   entirely dependent upon the deployed application.

   Restrictions on usage: Only for usage with FDT Instances which are
   valid according to the XML schema of section 3.4.2.

   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: 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.

   Additional information:

       Magic number(s): none
       File extension(s): An FDT Instance may use the extension ".fdt"
                          but this is not required.
       Macintosh File Type Code(s): none

   Person and email address to contact for further information: Toni
   Paila (toni.paila (at) nokia.com)

   Intended usage: Common

   Author/Change controller: IETF

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 23 May 2012 03:14:56 +0200

>   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.

>   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.)

>   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.

>   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.

>                          but this is not required.

I would make that simply ".fdt", but don't mind the extra text.

>   Paila (toni.paila (at) nokia.com)

This is typically rendered `Toni Paila <[email-masked]>`. 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.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Vincent Roca <[email-masked]>
Date: Wed, 23 May 2012 16:19:13 +0200

Hello Bjoern,

Thanks a lot for your highly valuable comments! My answers and proposal
are below.

> differently, depending on whether they assume it would have a charset

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?

> 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.

> similar registrations do not tend to have such text.

Removed.

> type of application where this is used.

Done.

> I would make that simply ".fdt", but don't mind the extra text.

I have simplified.

> all it takes is one of them getting it right since address lists are

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

   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

   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 ([email-masked])

   Intended usage: Common

Cheers,

   Vincent