[AVT] Re: Comments on draft-freed-media-types-reg-01.txt

ned.freed at mrochek.com ned.freed at mrochek.com
Thu Sep 9 17:37:52 CEST 2004

> > > 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"?

Encoding considerations is really intended to be a single value chosen
from a list. As such, this really belongs under restrictions on usage.

> This is how it would look like in our case:

> "Encoding considerations:

> 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 [].

Wrong RFC # here,, I believe. Additionally, I don't see this as a case of
noncompliance with the revised rules. A better approach would be to say that
this type is incompatible with use of text media types in other protocols.

> 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'
> rules.

I don't think having this sort of historical note in a registration is
appropriate either. 


More information about the Ietf-types mailing list