On Wed, Apr 14, 2010 at 21:47, Ned Freed <ned.freed@mrochek.com> wrote:
Our content does meet the requirements of RFC 4288 section 4.1, just not in compliance with RFC 2046.
So looks like the application/vnd.adobe.composite-asset is still the appropriate place for this type. Would you agree?
Yes, I'm in agreement with this assessment.
One (late) question:
Is there no precedence for adding +zip for such composite formats?
No. The question would be: Is being able to perform generic processing of formats packaged using ZIP useful even when you cannot process the specific type? If the answer is yes, then +zip makes sense, if not, then it doesn't. In the absence of more explicit guidelines, which we have for XML-based types but nothing else, this is a call for the registrant to make.
Compared this to say +xml for various XML-derived mimetypes like application/rdf+xml and image/svg+xml.
The argument for +xml is that there's value in being able to process something as XML even when you don't support the type specifically. I can see that argument applying to +zip. I can also see it not applying.
Another example: application/vnd.oasis.opendocument.text is a structured ZIP-file, where META-INF/manifest.xml describes the mime-types of the content (and the uncompressed file mimetype shows the mimetype of the archive itself)
There are many types structured this way.
We're thinking of being strongly inspired by the ODF archive format to make a container for Taverna workflows (by utillising org.odftoolkit.odfdom.pkg.OdfPackage).
Currently I'm thinking to call this application/vnd.taverna.scufl2.research-object+zip - but if the precedence is to *not* include "+zip" we'll just drop the last bit.
Any views on this..?
Speaking in my capacity as a media type reviewer, according to RFC 4288: In accordance with the rules specified in [RFC3023], media subtypes that do not represent XML entities MUST NOT be given a name that ends with the "+xml" suffix. More generally, "+suffix" constructs should be used with care, given the possibility of conflicts with future suffix definitions. I read this as saying that I should push back on any subtype name ending in +zip where the type itself is _not_ enclosed in a ZIP archive or if there's clearly a reason why you wouldn't want generic treatement for the type to ever occur. But I see neither of those applying to your registration. We have in fact registered various types with +suffixes other than +xml, but this may be the first time someone wanted +zip specifically in their type name. Ned