Registration of media type FO and ZFO

Jakub Hytka hytka at 602.cz
Tue Jun 10 09:35:15 CEST 2008


Martin Duerst napsal(a):
> At 03:01 08/06/10, Bjoern Hoehrmann wrote:
>   
>> * 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.
>>     
>
> Very much so indeed. The current subtype name is highly unclear,
> and if it's indeed XML, then +xml should be last.
> "because they are highly descriptive" is really a non-starter.
> The +xml suffix is highly descriptive, the +form 'suffix' is
> completely undefined.
>
> Regards,    Martin
>
>
>   
See the reply to Bjoern's message. The reason is to avoid the files 
being handled as simple XML files, but rather as XML forms, intended for 
usage in 602XML. That's also why we want to apply to the vendor's tree.
>> 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.
>>
>>     
>>> 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.
>>
>>     
>>> 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.
>>
>>     
>>> Additional information:
>>>
>>>   Magic number(s): NONE
>>>   File extension(s): FO
>>>   Macintosh file type code(s): -
>>>       
>> Same as above.
>> -- 
>> Bj��n H��rmann キ mailto:bjoern at hoehrmann.dehttp://bjoern.hoehrmann.de
>> Weinh. Str. 22 キ Telefon: +49(0)621/4309674 キ http://www.bjoernsworld.de
>> 68309 Mannheim キ PGP Pub. KeyID: 0xA4357E78 キ http://www.websitedev.de/ 
>>     
>
>
> #-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
> #-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst at it.aoyama.ac.jp     
>
>   
Jakub



More information about the Ietf-types mailing list