Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify mime type for car #238

Closed
willscott opened this issue Sep 15, 2021 · 10 comments
Closed

Specify mime type for car #238

willscott opened this issue Sep 15, 2021 · 10 comments
Assignees
Milestone

Comments

@willscott
Copy link
Member

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

@rvagg
Copy link
Member

rvagg commented Sep 15, 2021

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
Copy link
Contributor

lidel commented Sep 16, 2021

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
Copy link
Member

rvagg commented Sep 17, 2021

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
Copy link
Contributor

lidel commented Mar 7, 2022

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
Copy link
Contributor

warpfork commented Mar 7, 2022

(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
Copy link
Contributor

lidel commented Mar 7, 2022

@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
Copy link
Contributor

BigLep commented Mar 10, 2022

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

@lidel
Copy link
Contributor

lidel commented Mar 25, 2022

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
[email protected].

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
[email protected]


Name: Marcin Rataj
Email: [email protected]

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: [email protected]

Intended usage: Common
N/A

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

</details>

@BigLep
Copy link
Contributor

BigLep commented Mar 29, 2022

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

@lidel
Copy link
Contributor

lidel commented Mar 30, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants