> 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.
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.
> 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:
Again, I'm not sure that helps for RFC 2793, which doesn't indicate
restricted usage.
> OLD:
>
> Beyond plain text, there are many formats for representing what might
[...]
> show subtypes of "text" to the user, while it is not reasonable to do
"present" might be an improvement over "show", as it accommodates
text-to-speech conversion (for visually impaired users).
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf