Date: 2005-04-12 11:58 From: Colin Perkins <csp@xxxxxxxxxxxxx>
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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf