Use valid IANA or proper unregistered media type for Item Spec type attribute

[philvarner]

The "dev" version of the Item Spec has as valid entries for the type attribute these two entries:

| image/geotiff | Georeferenced TIFF. We would like to register image/geotiff as a mime type with IANA. |
| image/geotiff+cog | Cloud Optimized GeoTIFF |

I believe we should replace these either or both of (1) a valid IANA type and/or (2) a properly-defined unregistered type, until a point at which the IANA has actually accepted the recommended one above.

I believe the best option is allow both, as:

| image/tiff or image/x.geotiff | GeoTIFF TIFF file with standardized georeferencing metadata|
| image/tiff or image/x.geotiff-cloud-optimized | Cloud Optimized GeoTIFF

image/tiff is the mime type that file returns for a GeoTIFF. Placing x. in front of the type is the correct way to define an unregistered type. +cog looks nice, but +cog is not a valid subtype like +json is, and even if a subtype were registered, the full name would be inverted, e.g., image/cog+tiff, as the less-narrow type is tiff.

The image/tiff spec has an application parameter which was originally intended to help fax machines render images, which could possibly be repurposed. However, the valid values for this parameter are also part of a standard, so putting an arbitrary value like geotiff or cog in it would be a violation of that spec.

[m-mohr]

Has been merged.

[mojodna]

[puts pedant hat on]

https://serialseb.com/blog/2011/02/01/minting-new-internet-media-type-identifiers/ has some opinions on not using the x. prefix in favor of using a vendor prefix (would "STAC" be the vendor?)

From a consumer point of view, I want (need) to be able to distinguish between GeoTIFFs (which might be COGs?) and GeoTIFFs that are explicitly stated to be COGs. However, my pedantic side wants to use the same media type for both with some alternative way to distinguish between them (cog+ or with a parameter like cloud-optimized=true).

With those in mind, my updated proposal is:

1. image/vnd.stac.geotiff for generic GeoTIFFs
2. image/vnd.stac.geotiff; cloud-optimized=true for COGs

By using a stac vendor prefix, we can legitimately play faster and looser without introducing conflicts with other users of similar prefixes. It's also clear that distinctions exist for STAC purposes.

#308 is related, as it means that I can look for a "primary" image/vnd.stac.geotiff; cloud-optimized=true.

[m-mohr]

The problem again is that we don't have anything registered for geotiff or cogs.

Your linked article is a bit confusing in this regard. It says:

The x- or x. prefixes are only to be used for “unregistered, experimental, and for use only with the active agreement of the parties exchanging them”

The conclusion in the article:

In other words, don’t ever use x- or x

Why? There is no real explanation.

GeoTiff and COGs are no registered standard and the media types are not registered either. Isn't vnd. a prefix at IANA, too? Do we need to register the image/vnd.stac.geotiff to be officially in the vnd tree? I think our "invented" media types follow the quote above. The media types by @philvarner are indeed "unregistered, experimental, and for use only with the active agreement of the parties exchanging them". So to me the x. seems appropriate.

[mojodna]

The problem again is that we don't have anything registered for geotiff or cogs.

Exactly.

Why? There is no real explanation.

My read is that the post's point is that x isn't explicit enough about why it's experimental. And, given that there are 2 other places in the tree to put custom types without registration, it's the least specific.

Do we need to register the image/vnd.stac.geotiff to be officially in the vnd tree?

No, <type>/vnd.* can be arbitrarily used by vendors for documented purposes without IANA registration.

I think my deeper hesitation about @philvarner's media types is that we'd essentially be squatting on types intended for more general-purpose use without opening that discussion up wider.

[m-mohr]

Okay, I get your point.

We actually got in contact with OGC and @rouault a month ago on the STAC Gitter and asked about their plans regarding registering a media type for GeoTiff. The answer basically was that OGCs efforts to standardize GeoTiff and register a media type started years ago and are only moving forward slowly. Afterwards, I opened an issue opengeospatial/geotiff#34, but never got a response. So it seems there is no guideline for us and we need to go our own way.

[m-mohr]

Has been implemented in 0.6, so changing the milestone and closing.