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

[lidel]

Submitted request for application/vnd.ipld.car
(+ similar one for application/vnd.ipld.raw for completeness, as we use both in ipfs/kubo#8758)

Click to expand

```

To whom it may concern:

This is an automatically generated message to notify you that we have
received your request, and it has been recorded in our ticketing
system with a reference number of 1228646. To check the status
of your request, please see:

https://tools.iana.org/public-view

If you have any problems accessing this page, please contact
iana@iana.org.

There is no need to reply to this message right now. IANA staff will
review your message shortly.

If this message is in reply to a previously submitted ticket, it is
possible that the previous ticket has been marked as closed. As we
review this ticket, we will also review previous correspondence and
take appropriate action.

To expedite processing, and ensure our staff can view the full history
of this request, please make sure you include the follow exact text in
the subject line of all future correspondence on this issue:

     [IANA #1228646]

You can also simply reply to this message, as this tag is already in
the subject line.

Thank you,

The Internet Assigned Numbers Authority
iana-mime@iana.org

---

Name: Marcin Rataj
Email: lidel@protocol.ai

Media type name: application
Media subtype name: vnd.ipld.car

Required parameters: N/A

Optional parameters:
version=n; where n is the CAR format version

Encoding considerations: binary

Security considerations:
The media type contains no executable code.

All processors should rigorously verify data integrity
based on expected CIDs of blocks included inside a CAR.
Unexpected blocks must be discarded.

https://docs.ipfs.io/concepts/glossary/#cid
https://ipld.io/specs/transport/car/

Interoperability considerations:
N/A

Published specification:
https://ipld.io/specs/transport/car/

Applications which use this media:
The CAR format (Content Addressable aRchives)
can be used to store content addressable objects
in the form of IPLD block data as a sequence of bytes.

The CAR format is intended as a serialized representation
of any IPLD DAG (graph) as the concatenation of its blocks,
plus a header that describes the graphs in the file (via root CIDs).

The requirement for the blocks in a CAR to form coherent DAGs
is not strict, so the CAR format may also be used
to store arbitrary IPLD blocks.

Used extensively in
IPLD https://ipld.io
IPFS https://ipfs.io

Fragment identifier considerations:
N/A

Restrictions on usage:
N/A

Provisional registration? (standards tree only):
N/A

Additional information:

1. Deprecated alias names for this type: N/A
2. Magic number(s): N/A
3. File extension(s): car
4. Macintosh file type code: N/A
5. Object Identifiers: N/A

General Comments:

Person to contact for further information:

1. Name: Marcin Rataj
2. Email: lidel@protocol.ai

Intended usage: Common
N/A

Author/Change controller: Protocol Labs https://protocol.ai

</details>

[BigLep]

As of 2022-03-29, this is in "expert review" state with IANA: https://tools.iana.org/public-view/viewticket/1228646

[lidel]

Submitted updated version after the initial feedback from IANA Operations Manager.
I'll continue posting updates for each request in dedicated issues:

• raw [IANA #1228643] Request for media type application/vnd.ipld.raw ipfs/in-web-browsers#191
• car [IANA #1228646] Request for media type application/vnd.ipld.car ipfs/in-web-browsers#192