Considering the text/t140 media type (RFC 4103) which caused this
controversy:
On 1 Jul 2005, at 22:49, Bruce Lilly wrote:
...
While the proposed RTP "text" types would present a small but non-zero
security risk, the essential properties of MIME text types of
having the
characteristics above are not shared by the RTP types:
o clearly software which understands the format is required. The
format
includes embedded binary formatting information
No, it does not. The format contains only plain UTF-8 text. You may
be confused because the RFC describing the media type also explains
how that type is to be transported within RTP, since several features
of RTP are configured according to the media type parameters, and
repeats the definition of the RTP headers.
o not readable without software; indeed as pointed out, the RTP types
cannot even be save in a file format without conversion software
The contents of the RTP packets are plain UTF-8 text. It can
trivially be saved as a text/plain file, but doing so will lose the
timing information provided by the RTP headers (it is the presence of
the additional timing parameters that require this to be a separate
media type to text/plain for use with RTP). There are other media
types, under audio/* and video/* where this is a more complex
process, but that does not affect this case.
o it would be most unreasonable to try to present the RTP types
without
appropriate interpretation software
One clearly needs an implementation of a transport protocol to
receive data sent in that protocol. Once the data has been received
from the transport protocol, the contents are plain UTF-8 text with
implicit timing information.
o CRLF octets may appear in the RTP types (as binary data 0x0D0A)
where
they do not represent a line ending. Note the BCP 14 "MUST" keyword
in the approved RFC 2046 text, indicating interoperability issues of
a serious nature (refer to BCP 14 section 6). [BCP14]
The text/t140 format contains UTF-8 text. The CRLF octets are only
used to represent a line ending, not in any other case, in
conformance with these rules.
o the proposed RTP registrations provide no charset parameter,
defaulting
to US-ASCII as far as MIME implementations are concerned
The charset is always UTF-8 for text/t140. When signalled in SDP,
there is also provision for a language tag.
o fallback treatment as text plain is a problem for the RTP type
because
of the incompatibilities above.
The content is plain UTF-8 text.
Colin
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf