I notice that the tendency with nearly all of the specifications
produced in recent months is to class a new subtype under
Content-type:Application. Some of these involve data that are
text (usually standard, simple ASCII) and would be moderately (or
even highly) understandable to a human if the content were
presented to their screen.
If this is the case the types should have been registered under text. The
minimal MIME conformance guidelines make this quite clear, I believe.
I wonder whether such data would not be better classed under
Content-type: Text?
It is a judgement call the registrar of the type has to make. However, I
don't know what subtypes you are referring to. Would you care to elaborate?
Not a big deal? Probably not.
Actually, it can be a very big deal. Most agents will offer to show an
unencoded application/whatever as text, but many won't allow it if an encoding
has been applied. (For one thing, the EOL sequence in this case is entirely
arbitrary.) A subtype of text doesn't have this limitation.
However under Content-type:Application typical mail readers will
take the most conservative stance, restricting all handling of the
data to processing it through a separate program; hence if they don't
know the sub-type, they won't process it. Under Content-type:text,
minimal handling, by displaying to the screen, would seem entirely
reasonable.
It is not only reasonable, it is required. See Appendix A.
Do folks care about this? Any suggestion for language to give guidance
to Mime body-part spec writers?
The necessary language is already in place. You can lead a horse to water
but...
Ned