layer: clarify that layers are gzipped

[jonboulle]

Signed-off-by: Jonathan Boulle [email protected]

[vbatts]

Yes. I wonder if we worded in such a way that allows that to be optional? The mimetype having the +gzip suffix means it's an option. But will always at least a tar.
Does that make sense?

[jonboulle]

The mimetype having the +gzip suffix means it's an option.

does it? I sort of also had that intuition but can't seem to find a reference stipulating that.
https://en.wikipedia.org/wiki/Media_type#Suffix
https://tools.ietf.org/html/rfc6839

[wking]

On Fri, Sep 16, 2016 at 06:39:58AM -0700, Jonathan Boulle wrote:

The mimetype having the +gzip suffix means it's an option.

does it? I sort of also had that intuition but can't seem to find a
reference stipulating that.
https://en.wikipedia.org/wiki/Media_type#Suffix
https://tools.ietf.org/html/rfc6839

I don't think +gzip is defined anywhere, but I think we could define
+gzip and refernce RFC 6839 as the pattern we're following.

[vbatts]

does it? I sort of also had that intuition but can't seem to find a reference stipulating that.
https://en.wikipedia.org/wiki/Media_type#Suffix
https://tools.ietf.org/html/rfc6839

You're right. Perhaps we ought to describe a Structured Syntax Suffix
for +gzip, in likeness to rfc6839, but for this use-case

[wking]

On Tue, Sep 20, 2016 at 06:45:39AM -0700, Vincent Batts wrote:

does it? I sort of also had that intuition but can't seem to find a reference stipulating that.
https://en.wikipedia.org/wiki/Media_type#Suffix
https://tools.ietf.org/html/rfc6839

You're right. Perhaps we ought to describe a Structured Syntax Suffix
for +gzip, in likeness to rfc6839, but for this use-case

Already filed as #332 ;).

[stevvooe]

LGTM

In general, the suffixes aren't really optional (Apache HTTPD gets this very wrong, on occasion). In practice, it is much better to treat these as string constants. In Docker, we have them as .gzip to prevent this mucking. I changed this spec to use +gzip to keep it consistent with other media types, thinking that we had the discipline to avoid these problems, but #332 proves I was mistaken.

[jonboulle]

can we land this and move on to #332 et al? needs another LGTM

[stevvooe]

@jonboulle I'd like to see this in but #332 goes way too far. I hope this PR isn't considered a pre-cursor.

[wking]

On Mon, Sep 26, 2016 at 11:44:44AM -0700, Stephen Day wrote:

@jonboulle I'd like to see this in but #332 goes way too far. I hope
this PR isn't considered a pre-cursor.

I think requiring application/vnd.oci.image.layer.tar+gzip to be
compressed with gzip makes sense regardless of whether we define
application/vnd.oci.image.layer.tar or a +gzip structured syntax
suffix. So I'm fine landing d58f4c7 as it stands (although I'd
rather be linking to 1, which is the same doc but in a more
obviously versioned location). Whether #332 or other optional
gzipping lands later is orthogonal.

[vbatts]

LGTM

[philips]

LGTM