Registration of media type FO and ZFO

[Jakub Hytka]

Bjoern Hoehrmann napsal(a):
> * Jakub Hytka wrote:
>   
>> Thanks for the suggestions Frank. I added some information under 
>> published specification to describe both media types.
>> We still want to keep the vnd.software602.filler.xml+form and 
>> vnd.software602.filler.xml+zip+form subtypes, because they are highly 
>> descriptive in our opinion. Is this a important issue to be considered?
>>
>> Here follows the updated registration proposal:
>>
>> ------------------------------------------------------
>> ---FO---
>>
>> Type name: application
>>
>> Subtype name: Vendor Tree - vnd.software602.filler.xml+form
>>
>> Required parameters: None
>>
>> Optional parameters: None
>>
>> Encoding considerations: UTF-8
>>
>> Security considerations: FO is a XML-based plain text format, secured 
>> by signing the file itself through the means of the XML Signature standard.
>>     
>
> See RFC 4288 on the possible values for the Encoding considerations. I
> am not sure what kind of format you have. Could application/xml also be
> used instead of vnd.software602.filler.xml+form, i.e., are these simply
> XML documents with a special type, or is there some special encoding
> that makes them non-XML without additional decoding? If they are XML,
> then I would advise to reference RFC 3023 for encoding considerations,
> and add the optional 'charset' parameter, and consider calling the type
> e.g. vnd.software602.filler.form+xml.
>   
We want to avoid application/xml, as this is a specific XML file, which 
is only intended for usage in the 602XML applications, as only these 
applications know how to parse the document properly and display it 
properly. Therefore the selection of the subtype. We also wanted to 
avoid putting form+xml, because some web browsers (like Opera) don't 
follow the MIME type settings and use their internal processing for 
files whose MIME subtype contains +xml as the suffix...

Thanks for pointing our the charset parameter, I'll add that to the 
specification.
> By the way, your first message in this thread sounded like this is not
> the first time you send the proposal, if that is so, please note that I
> could not find a previous message from you in the archive.
>   
I don't think my first message got anywhere, that's why there was a 
slight confusion on my side... However now everything seems working, as 
we're already discussing!
>   
>> Additional information:
>>
>>   Magic number(s): NONE
>>   File extension(s): FO
>>   Macintosh file type code(s): -
>>     
>
> I would advise against using this extension, I believe it is in common
> use for XSL FO already.
>
>   
This is probably our requirement for compatibility issues, because we're 
using that extension for a long time already. However, 'our' FO is only 
just an extension of the standard XSL-FO files - it contains a XSL-FO 
layout flow, but on top of that some further XML constructs concerning 
the electronic forms. Do you think this can be a big problem?
>> Type name: application
>> Subtype name: Vendor Tree - vnd.software602.filler.xml+zip+form
>> Required parameters: None
>> Optional parameters: None
>> Encoding considerations: UTF-8
>>     
>
> Please see above for the encoding considerations. Perhaps you should re-
> fer to the application/zip registration here.
>   
Again, as in the FO section, we want to avoiud application/zip, for the 
same reasons. Do you suggest some simplification in the subtype suffix, 
like putting only form+zip for example?
>   
>> Additional information:
>>
>>   Magic number(s): NONE
>>   File extension(s): FO
>>   Macintosh file type code(s): -
>>     
>
> Same as above.
>   
This is just a mistype, the File extension here should be ZFO, which 
will be corrected, thanks for pointing that out for me.

Jakub