<div dir="ltr"><div><div>Erik, Andrew:<br><br></div>It seems like the well established pattern on the web is application/xxx+json: see GitHub's application/vnd.github.v3+json et al. Flipping the hierarchy around could add confusion.<br>
<br></div>Looking at <a href="http://tools.ietf.org/html/draft-bray-i-json-00#section-5">http://tools.ietf.org/html/draft-bray-i-json-00#section-5</a>, the new I-JSON now *does* have room for profiles. So the future of being more precise about GeoJSON could look like "application/json; profile=<a href="http://geojson.org/profiles/collection">http://geojson.org/profiles/collection</a>", where <a href="http://geojson.org/profiles/collection">http://geojson.org/profiles/collection</a> identifies a profile that extends I-JSON and has type: FeatureCollection at the top.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 4, 2013 at 3:47 PM, Erik Wilde <span dir="ltr"><<a href="mailto:dret@berkeley.edu" target="_blank">dret@berkeley.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">hello andrew.<div class="im"><br>
<br>
On 2013-11-04, 12:34 , Andrew Turner wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I prefer post-fix the content type since geoJSON is a subset of JSON<br>
application/json+geo<br>
For one, this makes it clear that it is `application/json` plus another<br>
thing '+geo'. Additionally this would permit multiple suffix (e.g.<br>
'application/json+geo+ld'. Last, practically code can evaluate<br>
'contenttype =~ /application\/json/ and it would account for subsets.<br>
</blockquote>
<br></div>
i see your motivation, but it might be a better idea to stick to what <a href="http://tools.ietf.org/html/rfc6839" target="_blank">http://tools.ietf.org/html/<u></u>rfc6839</a> is saying. there are no multiple suffixes in that system, and the generic part goes last. this might not be the most sophisticated system in the world, and media types in general are not a very well modeled space. but GeoJSON probably shouldn't design and define its own way of how media types work. and given the above RFC, i am pretty confident that a registration request for application/json+geo would be rejected at this point in time.<div class="HOEnZb">
<div class="h5"><br>
<br>
cheers,<br>
<br>
dret.<br>
<br>
-- <br>
erik wilde | mailto:<a href="mailto:dret@berkeley.edu" target="_blank">dret@berkeley.edu</a> - tel:<a href="tel:%2B1-510-2061079" value="+15102061079" target="_blank">+1-510-2061079</a> |<br>
| UC Berkeley - School of Information (ISchool) |<br>
| <a href="http://dret.net/netdret" target="_blank">http://dret.net/netdret</a> <a href="http://twitter.com/dret" target="_blank">http://twitter.com/dret</a> |<br>
______________________________<u></u>_________________<br>
GeoJSON mailing list<br>
<a href="mailto:GeoJSON@lists.geojson.org" target="_blank">GeoJSON@lists.geojson.org</a><br>
<a href="http://lists.geojson.org/listinfo.cgi/geojson-geojson.org" target="_blank">http://lists.geojson.org/<u></u>listinfo.cgi/geojson-geojson.<u></u>org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Sean Gillies
</div>