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

[Bjoern Hoehrmann <[e-mail]>]

* Vincent Roca wrote:
>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.

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

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

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

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

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

This is typically rendered `Toni Paila <[e-mail]>`. 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:[e-mail] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: [phone] · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/