IANA Registry of Media Types

[rickbeerendonk]

Any plans for adding EDN to the IANA registry of media types?
http://www.iana.org/assignments/media-types/index.html

[richhickey]

That would be ideal. I don't know what is involved, nor how that would pour concrete over the specification.

[ghost]

Application form: http://www.iana.org/form/media-types

[madbonkey]

@richhickey In regard to the concrete, from RFC 6838 - Section 5.5 ("Media Type Specifications and Registration Procedures"):

Once a media type has been published by the IANA, the owner may
request a change to its definition. [...] The same procedure that would be appropriate
for the original registration request is used to process a change
request.

Interesting tidbits:

• "Media type registrations may not be deleted [but declared OBSOLETE]"
• "The owner of a media type may pass responsibility to another person [...]"
• "The IESG may reassign responsibility for a media type [...]"

[aadrian]

Any news on this issue?

Many formats that have way less impact than EDN have been registered.

Not having the format "officially" registered, makes it quite hard (often imposible) to use EDN in many projects e.g. where this matters :( .

[puredanger]

What would the recommended type be?

[puredanger]

I suppose application/edn ?

[greglook]

application/edn is certainly the de-facto standard in most Clojure projects.

[rschmitt]

@puredanger application/edn falls under the RFC 6838 standards tree, which has pretty strict requirements:

   The standards tree is intended for types of general interest to the
   Internet community.  Registrations in the standards tree MUST be
   either:

   1.  in the case of registrations associated with IETF specifications,
       approved directly by the IESG, or

   2.  registered by a recognized standards-related organization using
       the "Specification Required" IANA registration policy [RFC5226]
       (which implies Expert Review).

   The first procedure is used for registrations from IETF Consensus
   documents, or in rare cases when registering a grandfathered (see
   Appendix A) and/or otherwise incomplete registration is in the
   interest of the Internet community.  The registration proposal MUST
   be published as an RFC.  When the registration RFC is in the IETF
   stream, it must have IETF Consensus, which can be attained with a
   status of Standards Track, BCP, Informational, or Experimental.
   Registrations published in non-IETF RFC streams are also allowed and
   require IESG approval.  A registration can be either in a stand-alone
   "registration only" RFC or incorporated into a more general
   specification of some sort.

   In the second case, the IESG makes a one-time decision on whether the
   registration submitter represents a recognized standards-related
   organization; after that, a Media Types Reviewer (Designated Expert
   or a group of Designated Experts) performs the Expert Review as
   specified in this document.  Subsequent submissions from the same
   source do not involve the IESG.  The format MUST be described by a
   formal standards specification produced by the submitting standards-
   related organization.

The vendor tree described in the subsequent section is more realistic:

   A registration may be placed in the vendor tree by anyone who needs
   to interchange files associated with some product or set of products.
   However, the registration properly belongs to the vendor or
   organization producing the software that employs the type being
   registered, and that vendor or organization can at any time elect to
   assert ownership of a registration done by a third party in order to
   correct or update it.  See Section 5.5 for additional information.

This would make for a media type like application/vnd.clojure.edn, which is of course completely non-interoperable with the de facto standard of application/edn that everyone is already using.