The question is clear enough, but let me flesh it out with the actual example I am encountering:
In interpreting an RSS feed, there is an image specified sometimes where it is not known what kind of image it is, but it is nonetheless clear that the link type is an image, such as in this example:
<itunes:image href="http://static1.doda.com/57914/1500w/" />
That iTunes spec does not enter the image type attribute for the image. So then let's say I am taking this image link (with others) and re-syndicating it, but now as a standard ATOM link. To specify it is an image, the type attribute of the link needs to start with image (as an image MIME type), and yet what should I do about the subtype:
<link href="http://static1.doda.com/57914/1500w/" type="image" /> //??
I'm guessing MIME types can never do this, but is that the case? Can the subtype ever be left off? Another solution is not so happy either: to enter a FALSE but common subtype (e.g.: "image/jpeg").
--- update ---
Thanks to Julien for that research. So one solution just occurred to me: using a generic subtype of a given value such as: unknown, or none.
image/unknown
image/none
Maybe just go with 'unknown', but 'none' has it's benefits as well. This might be especially useful if a lot of people started using one (or both) of these values when they don't know the subtype.
I would love to hear in the comments how that idea strikes you guys, yea or nea? Good idea or bad?
Yes, in theory, the RFC4287 says:
Whatever a media type is, it contains at least one slash
atomMediaType = xsd:string { pattern = ".+/.+" }
Now, from experience, there are many feeds out there which do not include the sub-type. Be robust: if you publish a feed, make sure you include both... and if you consume feeds, be ready to handle feeds where it's missing!