Subject: [core] media types in draft-ietf-core-coap

From: Cullen Jennings <[email-masked]>
Date: Sat, 6 Nov 2010 21:20:39 -0600

This is a pretty minor point in the overall design so I have been ignoring it for awhile but seems like it is about time to mention it. 

<rant>

Many the media types in Table 4 have one thing in common. Many of them are useless as media types and never should have been approved as media/types in the first place. Take text/xml or application/xml. The fact we can't even tell if is is text or an application is telling. And what does it mean? What can you do with these bits? What application do you hand them too? How do you interpret them?There is no information that helps answer that in this media type.  If an device receiving this knew the answer to these questions, then it would not need the media type in the first place. It's as useless as media type that indicated that the words where 8 bits long. Imagine application/8bit - it's just not helpful. Now that I look I see we actually have that media type - it's called application/octet-stream. Seriously, why bother. The more you think about it, the situation is about the same for  application/xml - yep, there will be angle brackets in the data but you still don't know what to do with it any more than what you did with application/8bit. For some of the types, such as  image/jpeg, it is clear and you do know what the media types is and how you can interpret the bits you find inside. But when we get to audio/raw, it's again close to useless without knowing how bits the samples where and what the same rate was, how many channels there were and how they were interlaced. 

</rant>

My suggestion is we update table 4 to have a column that is a reference to a spec that describes the semantic meaning of the information that one will find in this type of data. For types that do not have semantic meaning but are only a formatting container for some structure data inside of them, we do not put them in the table. So if some other organization defined a XML based format for caring power readings from a smart energy meter, it would be fine to have something like application/smart-energy-meter+xml but something that provide no real information about the contained data, such as as application/octet-stream does not go in the table. Remember that it fine to send a message with no Content-Type option for cases where it's just some bits and both ends know what to do with the bits.