Vendor-specific MIME type for review

[Ned Freed]

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