headers
Vincent Roca | 22 May 2012 16:14
Picon
Picon
Favicon

Registration of media type application/fdt+xml

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.
(Continue reading)

Permalink | Reply |
headers
Bjoern Hoehrmann | 23 May 2012 03:14
Picon

Re: Registration of media type application/fdt+xml

* 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
(Continue reading)

Permalink | Reply |
headers
Vincent Roca | 23 May 2012 16:19
Picon
Picon
Favicon

Re: Registration of media type application/fdt+xml

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.)
(Continue reading)

Permalink | Reply |

Gmane