Jon Duckworth

Judging from [this migration](https://github.com/stac-utils/pgstac/blame/cb03727ebbcc49fa6a1f4775772d0deeb16552da/pypgstac/pypgstac/migrations/pgstac.0.2.4-0.2.7.sql#L26) it looks like it supports both.

> I'm OK with splitting create-replace-delete into separate conformance classes however the **OPTIONS** method might also be considered since it offers more fine-grained control over the methods supported particular endpoints....

An archive extension would be useful for the work we're doing on Radiant MLHub, as well. We are generating gzipped tar archives all assets associated with our collections to make...

@m-mohr Just to clarify, the `archive:href` and `archive:type` properties would be optional, yes? When referring to the archive itself as an asset it seems like neither of those would be...

It would probably be useful for us to have something like an `archive:size` property that gives the total byte size of the archive. This might only be relevant on the...

> > It would probably be useful for us to have something like an `archive:size` property that gives the total byte size of the archive. > > We have recently...

> > I know we could use `application/gzip` to indicate the compression, but I don't think there's anything to indicate something like a tar archive. > > Yeah, that it's...

> @duckontheweb Honestly, I don't understand your second comment ([#956 (comment)](https://github.com/radiantearth/stac-spec/issues/956#issuecomment-772955132)) . I don't understand the difference between my proposal for "two-level" archives?! We won't be able to change the...

Summaries of asset properties (and possible link properties) would be useful for us in the Radiant MLHub API. We have heard from a few users that it would be nice...

This seems like it has the potential to overlap with the scope of the Scientific Extension, at least at the Collection level... > This extension adds the ability to indicate...