Vendor-specific MIME type for review
ned.freed at mrochek.com
Thu Jul 15 19:10:56 CEST 2010
> On Wed, Apr 14, 2010 at 21:47, Ned Freed <ned.freed at 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
> 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.
More information about the Ietf-types