Registration of media type FO and ZFO

[Jakub Hytka]

Martin Duerst napsal(a):
> 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.
>   
This has indeed worked, thanks for the suggestion. The specific 
registration in Opera helped, however the default behaviour is as 
described by me.

We still feel that as we're applying for registration in the vendor tree 
we'd like to keep the subtypes a bit broader, now i'm more inclined to 
the suffixes form+xml (for FO) and form+xml+zip (for ZFO, another option 
would be form+zip only of course). But we think leaving the 'form' 
keyword in the suffix is better for describing the media subtype in the 
vendor tree.

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