Specify mime type for car

[willscott]

do we have a recommended mime type to use with car files?

[rvagg]

Discussion here ipfs/in-web-browsers#170 and here ipfs/kubo#8234

@olizilla advocating for getting application/car registered here ipld/specs#368. That seems reasonable aside from the IETF/IESG barrier that someone would need to work through.

[lidel]

Somehow related: I've been thinking about content-type header that should be returned with dag-json and dag-cbor when ?format= is implemented on gateways (ipfs/kubo#8234).

There are two ways:

1. application/json and application/cbor (because technically they are)
2. application/vnd.ipld.dag-json and application/vnd.ipld.dag-json

If we go with application/car here, that implies we will go with (1) for dag-json/dag-cbor.
Any concerns around this?

[rvagg]

Sending as application/json and application/cbor seems fine, you lose the signalling but presumably such responses are coupled with CIDs in the request or some other means (?format=X or ?codec=X) so that the content signalling is still attached. Are there cases where it may not be though? What if you make a request with a root CID and a path that leads you to an arbitrary block, could we end up sending back data detached from format signalling leaving the user to rely on json and cbor without differentiation between plain json and cbor and dag-json and dag-cbor?

Re application/car the hesitation I have is that it's not registered! I'm unsure how difficult the path is to registration but I suspect, like most IEFT things, it's quite a bit of effort. Maybe we should be starting off with a vnd mime type until we have it locked in? application/vnd.ipfs.car might be more appropriate for now. Thoughts?

[lidel]

We are adding support for CARs on gateways (ipfs/kubo#8758), and I'd like to resolve this.

Registrations in the standards tree (without vnd. prefix) must be approved by the IESG or must correspond to a formal publication by a recognized standards body. We don't have RFC for CAR, so this is unlikely to happen any time soon.

👉 If we want to have type registered sooner than never, I agree, application/vnd.ipfs.car is the way to go.

I am happy to submit a registration request (i also want to submit a request for application/vnd.ipfs.block), but before I do that, we need to agree on the spec, namely, what are Optional Parameters we should include:

Content-Type := type "/" subtype *[";" parameter]

application/vnd.ipfs.car
application/vnd.ipfs.block

Version Parameter

Obvious one, makes it possible to handle versioning.

So implicit / explicit CAR versions would be:

application/vnd.ipfs.car
application/vnd.ipfs.car; version=1
application/vnd.ipfs.car; version=2

Gateway response would include an explicit version, and if one requests an unsupported version, they would get an error.

Good enough?

Are we happy with the above, or should we add anything else?

I AM TIMEBOXING THIS TO END OF THIS WEEK, will submit registration on Friday/Monday.

[warpfork]

(Weakly held and brief opinions, only because I'm poked -- I don't have a ton of familiarity or deeply held concerns about MIME types --)

• I guess I'd weakly advocate for application/vnd.ipld.car (over *ipfs*) -- it's a bit potæto potäto, but I tend to consider CARs a pretty well specified IPLD thing? Their spec lives on the ipld.io domain, etc.
• AFAIK, the version optional field does sound sufficient. I'm not aware of any other major parameters of note (CAR is supposed to be pretty KISS, after all).

👍

[lidel]

@warpfork vnd.ipld.* sgtm, but stepping back, should we in general go with codec names to remove ambiguity?

application/vnd.ipld.car
application/vnd.ipld.raw # instead of 'block' ?

Note this somehow impact future things, for example (no need to make decision on json/cbor behavior right now, but flagging here):

application/vnd.ipld.dag-json # instead of application/json
application/vnd.ipld.dag-cbor # instead of application/cbor

[BigLep]

2022-03-10: current plan is to submit this 2022-03-1425