On 12 Apr 2005, at 17:57, ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
...
The rules for display of text media types assume that such types are,
to
some extent, readable without special purpose viewing software. This
is
certainly true for most types, but some existing types have
restrictions
on their use which are incompatible with this rule (e.g. the
"text/t140"
type specified in RFC 2793 is a framed encoding defined only for
transfer
via RTP and cannot be directly displayed). The following edit to
Section
4.2.1 ("Text Media Types"), third paragraph, is one way to resolve
this
inconsistency, by noting that subtypes which are defined with
restricted
usage cannot necessarily be directly displayed:
...
NEW:
Beyond plain text, there are many formats for representing what
might
be known as "rich text". An interesting characteristic of many
such
representations is that they are to some extent readable even
without
the software that interprets them. It is useful, then, to
distinguish them, at the highest level, from such unreadable data
as
images, audio, or text represented in an unreadable form. In the
absence of appropriate interpretation software, and provided the
subtype
^^^^^^^^^^^^^^^^^^^^^^^^
is not defined for restricted usage, it is reasonable to show
subtypes
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
of "text" to the user, while it is not reasonable to do so with
most
non
textual data. Such formatted textual data should be represented
using
subtypes of "text".
I'm quite sympathetc to the underlying problem, but IMO this change is
unacceptable, in that in order to make it work the fact that a given
subtype is intended for restricted usage would have to be known to the
display agent. The whole idea of having top-level types is predicated
on not needing this sort of exception information.
Sure, but if the display agent is unaware of the restrictions, it won't
ever be able to receive the media data. The example I have in mind in
"text/t140" which is UTF-8 text framed within RTP packets [RFC 2793].
The media type is defined only for use with RTP, and an agent that
doesn't know how to decode RTP framing (i.e. a sequence of UDP packets
with explicit time and ordering data) will never see the data.
Colin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf