In issue 18891, Stephen Turnbull wondered if adding a datatype to represent mime types would be worthwhile.  

I think it would be.  A mimetype is a pair (maintype/subtype), and while one may test the subparts independently in logic, the representation and what needs to be passed from place to place in the code is always a pair.  Most importantly, having a datatype to represent this would eliminate a common class of errors: forgetting to test the component strings case-insensitively.  If one is manipulating a Message object, the get_xxx methods used to access the mimetype do do case coercion, but within the email code itself there are a number of places where the raw strings are manipulated, and I have already made, discovered, and fixed case insensitivity bugs in that code.

It is not clear at this point if the object should be exposed, though I'm inclined that way.  I'd propose using a string subclass with maintype and subtype attributes, and this object could then be returned by get_content_type without breaking backward compatibility.  Another advantage of using a string subclass is that the original casing of the values is easily retained and easily accessible, which while not critical is something the email package normally does (preserve the case of the original data).