On 12 Apr 2005, at 19:45, Bruce Lilly wrote:
Date: 2005-04-12 11:58
From: Colin Perkins <csp(_at_)csperkins(_dot_)org>
I have reviewed draft-freed-media-type-reg-03.txt, and have a number
of
comments intended to align the registration procedures with the
current
practice defined RFC 3555. These primarily arise due to the widespread
use
of media subtype names to identify formats that can be conveyed within
RTP.
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).
RFC 2793 states "COMMON" usage, not restricted, and makes no mention of
any sort of restrictions under Interoperability considerations! RFC
2793 also says:
Applications which use this media type:
Text communication terminals and text conferencing tools.
The encoding considerations section of the registration limits this to
RTP. The lack of clarity on where to specify restricted domains of
applicability is one of the things I hope this update to the media type
registration guidelines will fix.
Surely when some content is reassembled from the individual packets, it
can be presented without special purpose software (other than that
required for charset issues and local presentation conditions). If
it cannot be presented, it's difficult to imagine how the media type
would be used in the stated intended applications. If a substantial
amount (more than one MTU) of text/plain is transmitted via some
application-level protocol over TCP (rather than RTP), one of course
has to reassemble the content for the application layer for
presentation. In what way does use of RTP instead of TCP (UDP, etc.)
at a transport protocol layer change that?
One might even ask in what sense -- at the application layer --
text/t140 is meant to be different from text/plain. Perhaps the issue
is not so much with the registration procedure draft as with the
text/t140 registration... or maybe RFC 2793 isn't a good example of
the issue you have in mind.
An alternative example would be draft-ietf-avt-text-red-05.txt which,
due to the way SDP/SIP signalling works, needs to use the same top
level media type as text/t140.
Colin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf