Subject: Re: [MMUSIC] Re: [AVT] Naming of RTP payload formats within SDP

From: Stephen Casner <[email-masked]>
Date: Fri, 1 Jul 2005 10:21:29 -0700 (PDT)

On Wed, 22 Jun 2005, Dave Singer wrote:

> For me, if the IANA is managing two spaces, it can be clear which one
> is which and we can avoid arguments like -- "audio/whatever" may make
> sense as a file format (i.e. MIME) but none as an RTP format, or
> vice-versa.
>
> Logically we then have
> mime/audio/midi
> rtp/audio/amr
>
> (where mime/ and rtp/ are separate IANA entry points).

The problem is that the mime/ and rtp/ are only implicit.  When you
see "audio/amr" in the wild, how do you know whether it came from
mime/ or rtp/ ?  People who don't read specifications would use rtp/
type names when sending email and mime/ type names when sending RTP,
just like the problem you have now with misuse of RTP typenames for
MPEG4 files.  I believe it is better to have a single registry so that
there is only one place to look.  For people who are willing to read,
they will find a registration that says the type in question is
defined only for use with RTP.  If the registries were separate, then
a person looking for an rtp/ name in the mime/ tree would find
nothing, and might assume that the registration was just not completed
yet or that the place they were looking was not up-to-date.  That is,
having negative information to proscribe an undefined action is better
than having no information.

Splitting the namespaces does not help, and since it is a change from
the status quo, can only serve to require more work.

Colin already replied about the motivation for keeping the spaces
together (audio/basic vs. audio/pcmu).

                                                        -- Steve

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Dave Singer <[email-masked]>
Date: Fri, 1 Jul 2005 10:53:08 -0700

>together (audio/basic vs. audio/pcmu).

I'm honestly cool either way.  What I am not happy with is when we 
get resistance from the 'true mime' people to a registration which is 
RTP-specific.  As long as we can agree on having registrations which 
are specific to one or other community (and as I say, I have a hard 
time thinking of cases where the exact same bit-format and rules 
applies to RTP packets and files), and that the usage of that 
community will determine the appropriateness of the registration, 
that's fine.  (There is of course abundant common general review to 
be done, of course, as well).

We should probably make clear that text/* in RTP means that the 
resulting data is of text data type, and could therefore be read by a 
screen reader, presented visually, and so on.  It would not mean that 
the RTP packets are written in text.  Some 'cleanup' of what text/* 
means in 'true mime' might also be in order, but that is not my 
community.
-- 
David Singer
Apple Computer/QuickTime