[AVT] Re: Comments on draft-freed-media-types-reg-01.txt
rey at panasonic.de
Thu Sep 9 11:54:06 CEST 2004
I am the editor of the 3GPP timed text draft. I have a question regarding
MW2. THanks in advance
> > MW2: Section 4.2.1, third paragraph:
> > "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, 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"."
> > When one has limited usage, like say "only for usage in RTP" I think
> > there are need to consider some wider interpretation of what "to some
> > extent readable" means. We had an example in the 3GPP timed text
> > discussion, where the RTP payload format consists of embedded UTF-8 or
> > UTF-16 strings in an otherwise binary format. However for RTP that is
> > the common case. Should such any clarification on the performance of
> > such consideration be written into this spec or do it belong to a
> > further registration document in relation do a specific domain of usage?
> I would say it belongs in the registration document.
does such a clarification belong under "Encoding considerations" or under
"Restrictions on usage"? Until now most payload formats included a sentece
like "This type is only defined for transfer via RTP." under encoding
considerations. In this case, is it not more appropriate to do this under
"Restrictions on usage"?
This is how it would look like in our case:
RTP payloads conforming to this payload format do not comply with the strict
rules for registration under the 'text' top-level MIME type, as outlined in
RFC 2026 and its revision RFCYYYY . The reason for this is that the RTP
client must, at least, understand the payload format fields (in binary) in
order to decode the timed text contents (partly text strings, partly
binary). This binary information is not considered 'directly readable'
without 'special software' as required for 'text' subtypes (in contrast to
text strings). Around the 60th IETF it was decided to relax these rules for
RTP payload formats. In particular, it was allowed to register RTP payload
formats under the 'text' top-level type (if appropriate) as long as the
domain of applicability of the format is clearly specified (e.g. only for
transmission using RTP). This payload format complies with these 'relaxed'
Restrictions on usage:
This type is only defined for transfer via RTP."
More information about the Ietf-types