Registration of media type FO and ZFO

[Martin Duerst]

At 16:32 08/06/10, Jakub Hytka wrote:
>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.

I think having a dedicated type is fine.

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

I think that's an error. It is a good idea to use that as a fallback,
but it shouldn't be used in general. Did you talk to them? Are there
any technical reasons why they do this? Does this happen if your
application/type is registered with Opera? (in Tools - Preferences -
Advanced - Downloads)

Regards,   Martin.


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


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst at it.aoyama.ac.jp