Loading ...
Sorry, an error occurred while loading the content.

1016Re: MIME types

Expand Messages
  • Stephen M. McKamey
    May 6, 2008
    • 0 Attachment
      I would also support a #4 as you've described as long as whatever it
      is works within the IANA restraints. It has been a while now since I
      sifted through the RFCs but it might be a good time to revisit. The
      commentary which influenced my initial stance was in the XML MIME
      Type RFC:

      http://tools.ietf.org/html/rfc3023#page-32

      Definitely worth a read as they've justified the reasoning for XML's
      usage of the "+xml" style. They also discuss some alternatives.

      Thanks,
      smm

      --- In json@yahoogroups.com, "Kris Zyp" <kriszyp@...> wrote:
      >
      > Thank you Stephen, this exactly what I was asking! Thanks for
      clearly articulating this. I was also wondering if there is an option
      #4, which may be an enhancement of #1, where we also use
      application/json, but we include extra info after a semicolon to
      denote structure/application information. JsonML might be:
      > application/json; type=jsonml
      >
      > Or something like that. I believe there other types that use
      something like this to include extra info; multipart includes
      boundary definition after a semicolon, and I have seen charset info
      included after a semicolon. However, I am not sure what the semantic
      intents and constraints are for this approach, it may be
      inappropriate to define subtypes in this manner. I really am fine
      with any of these approaches and just wanted to get some consensus. I
      am perfectly content to follow your (Stephen) precedent with {x-}
      application/subtype+json.
      >
      > Thanks,
      > Kris
      >
      >
      > ----- Original Message -----
      > From: Stephen M. McKamey
      > To: json@yahoogroups.com
      > Sent: Tuesday, May 06, 2008 8:17 AM
      > Subject: [json] Re: MIME types
      >
      >
      > No offense, but I think the replies thus far have missed Kris'
      > point. Kris is trying to get opinions on additional MIME types
      for
      > specific applications of JSON. These aren't necessarily messaging
      > envelopes and are still platform-agnostic. These are situations
      > where JSON is the format but the structure is important. Examples
      > from the XML world:
      >
      > - ATOM: "application/atom+xml"
      > - XHTML: "application/xhtml+xml"
      > - XSLT: "application/xslt+xml"
      > - SVG: "image/svg+xml"
      >
      > As you can see, these are all valid XML formats but it makes
      sense
      > due to their profileration to give them a MIME type that allows
      > better assumption of a subset of XML. I wouldn't want to
      interpret
      > SVG as an XHTML document and such it is nice to be able to
      > communicate between client-server the "types" that are accepted.
      >
      > As I see it, opinions on this will more or less fall into three
      main
      > camps:
      >
      > 1) avoid MIME variants at all costs
      > 2) standardize and use for every standardized variant
      > 3) standardize and use sparingly where justified
      >
      > There is the strict purist/minimalist perspective which would
      suggest
      > #1. This has the advantage of remaining simple, pure and keeps
      JSON
      > as just JSON. I can respect that. And judging by Kris' question
      he
      > is probably okay with that as well if that is the group concensus.
      >
      > There are circumstances that #2 or #3 would be nice however. For
      > instance when I make a request for JsonML, it is nice to be able
      to
      > inform the server that as a client I can accept a JsonML response
      > (and in response that the format is actually JsonML and not just
      JSON
      > data which must be processed differently). This is a more
      specific
      > requirement than just being able to parse JSON. Essentially JSON
      > data needs to be in a particular structure or it doesn't make
      sense
      > to a JsonML builder.
      >
      > Now that being said, the risk of opening this Pandora's Box is
      that
      > every developer and their mom might begin creating MIME types for
      > every piece of ad hoc JSON data. Granted if we went with #3, we
      > could just rely on IANA to police the JSON MIME type horizon. As
      it
      > is, in order to officially have a "application/XXXX+json" MIME,
      you
      > have to have a formalized standard and they have to accept your
      > application. See [ http://www.iana.org/assignments/media-types/ ]
      > for more info.
      >
      > My only real fear is that if we don't pick a standard of some
      kind
      > then we run into the issues where incompatibility makes the
      feature
      > useless. Initially JavaScript itself suffered from this issue
      until
      > it was later better standardized (see RFC-4329) but this caused
      > confusion and incompatibility for years.
      >
      > My suggestion would be option #3 with IANA policing the
      > official "application/XXXX+json" MIME space, but also some
      standard
      > set in place for "X-" MIME types. For instance a JsonML MIME type
      > isn't official, so technically it should be
      > "x-application/jsonml+json" rather
      than "application/jsonml+json".
      > This is the official way of "experimentally" creating a MIME type.
      >
      > I hope this makes sense and that we can come to some sort of
      > consensus.
      >
      > smm
      >
      > --- In json@yahoogroups.com, "kriszyp" wrote:
      > >
      > > I wanted to see if there was any prevailing consensus on if and
      how
      > > JSON subsets and alternatives should be denoted with MIME
      types.
      > There
      > > are a growing number of JSON subsets like JSON-RPC, JSONT,
      JsonML,
      > > JSON Schema, etc. There may be benefits in being able to define
      > which
      > > subset is begin used as a MIME type. XML has used a subtype+xml
      > > convention, and I noticed that Stephen McKamey is using this
      > precedent
      > > to suggest denoting JsonML as "application/jsonml+json". I am
      > > perfectly fine with using this convention, I just wanted to see
      if
      > > others felt this was the way to go, or if it is preferable to
      do
      > more
      > > "minor" subtyping that would not suggest a need for IANA
      > registration
      > > like "application/json; rpc", or something like that.
      > >
      > > I am also curious if there any thoughts about JSON supersets.
      There
      > > have been little efforts to create any formal proposals in this
      > area,
      > > but I don't think it is totally uncommon to use additional
      > JavaScript
      > > constructs for JSON-esque data, and postel's law application to
      JSON
      > > almost invariably means allowing for additional JavaScript
      defined
      > > flexibility (non-quoted keys, comments, etc). One could think of
      > > JavaScript expressions as a type unto themselves, the true
      superset
      > of
      > > JSON (JavaScript itself is not actually a correct superset of
      JSON
      > > because JSON is not valid JavaScript by itself, it must be
      enclosed
      > in
      > > paranthesis to make it a JavaScript expression). Generally
      > JavaScript
      > > libraries that don't do validation before an eval (Dojo and many
      > > others) are actually full JavaScript expression acceptors, and
      > > non-JavaScript libraries and JavaScript libraries that do
      validation
      > > (like json.org's library) would be only JSON acceptors. I am
      > wondering
      > > if MIME type definition might be valuable here as well
      (providers
      > > would know if they can include comments, for example).
      > >
      > > Anyway, I am not really making any proposals, just curious it
      there
      > > are prevailing feelings towards MIME types for defining
      different
      > JSON
      > > formats.
      > >
      > > Thanks,
      > > Kris
    • Show all 9 messages in this topic