|
Re: RTP vs. MIME
2005-07-22 15:55:23
On 22 Jul 2005, at 16:25, Bruce Lilly wrote:
...
To the extent that transport protocol overhead has been erroneously
included in what is purported to be a media format specification,
that is a problem with the registration and/or specification.
There is nothing in the MIME rules which requires an RFC to include
only a MIME registration template. Despite your attempts to claim
otherwise, it is entirely legitimate and appropriate for an RFC to
include both a media type registration and some other specification.
And I would add that that causes problems for MIME reviewers and
implementers, and said problems would be alleviated by a separate
registry with separate rules, where RTP-specific registrations can
conflate transport bits with format bits or not without causing
problems for MIME reviewers and implementers.
The documents clearly separate "transport bits" from "format bits",
so this is not an issue. This separation has been repeatedly
explained to you, and is documented in these particular
specifications, and the RTP specification (RFC 3550 -- STD 64).
You are confusing the applicability statement which
describes RTP-specific processing with the description of the media
type.
I see nothing in 3267 labeled "applicability statement"; I do see
multiple "format" descriptions.
There is no requirement in RFC 2026 for the explicit label
"applicability statement" to appear anywhere, so this cannot be your
complaint. You will find several format descriptions in the RFC: two
RTP payload formats, and two media types. The two RTP payload format
definitions (section 4 of RFC 3267) describe how the two media types
are conveyed within RTP, but don't define the media types. The two
media types are described in section 5 of RFC 3267, with reference to
the 3GPP specifications which define the bit patterns and semantics
of the speech frames. The media type registrations are in section 8
of RFC 3267. You are, as I previously stated, confusing the RTP
specific processing (an "RTP Payload Format") with the description of
the media type.
The formats are specified in the following:
[1] 3GPP TS 26.090, "Adaptive Multi-Rate (AMR) speech
transcoding",
version 4.0.0 (2001-03), 3rd Generation Partnership Project
(3GPP).
[2] 3GPP TS 26.101, "AMR Speech Codec Frame Structure", version
4.1.0 (2001-06), 3rd Generation Partnership Project (3GPP).
[3] 3GPP TS 26.190 "AMR Wideband speech codec; Transcoding
functions", version 5.0.0 (2001-03), 3rd Generation
Partnership
Project (3GPP).
[4] 3GPP TS 26.201 "AMR Wideband speech codec; Frame
Structure",
version 5.0.0 (2001-03), 3rd Generation Partnership Project
(3GPP).
26.090, according to http://www.3gpp.org/ftp/Specs/html-info/26090.htm
is "AMR speech Codec; Transcoding Functions". Transcoding
functions and
media formats are separate types of specifications. "Frame structure"
specifications *might* be applicable, *if* the media format is
identical
to said "frame structure", but I see nothing in the registration form
that says so, and several parts of section 5 imply otherwise; sections
5, 5.1, and 5.2 make no reference to what precisely comprises "speech
frames" or "speech bits" or indeed why two different terms are used.
The 3GPP documents are, without any doubt, both applicable and
appropriate specifications for these formats. There are several
dozen independent and interoperable implementations based on the
specifications, using the media formats both with RTP and in more
traditional MIME contexts such as file downloads. These
implementations are in daily use by tens of millions of users. By any
measure, this meets the necessary standards of specification clarity
for the community which is implementing the standard.
That is a very good reason for a separate registry. There is no
question that the proposed media type did not meet the
requirements for registration in the text top-level MIME
registry; it should never have been proposed to register it
there. With a separate RTP registry, those interested in RTP can
establish whatever rules or lack of rules for things to be
considered as RTP "text".
You seem to be complaining because we asked the advice of the MIME
community on whether the 3GPP timed text format should be registered
under text or video, and then took that advice. Quite how this can be
construed as a failure of the process, or as a statement that RTP is
not appropriate for use with MIME types is beyond me.
One might as well ask whether or not an elephant is eligible for a dog
license. The question shouldn't even be asked. And it wasn't a
simple
matter of "took that advice", there was argument that even though the
media clearly was incompatible with text, that it should be registered
under text anyway, presumably merely because some RTPers would like it
that way with no regard for the registry's rules. That the question
was asked is itself an indication of a problem (the rules are quite
clear and are not new; they have been in RFC 2046 which is now more
than eight years old). That RTPers would like to do things
incompatible
with MIME and the MIME registry is a clear indication that both RTP
and
MIME communities would best be served by separate registries with
separate rules tailored to the needs of their respective communities.
Both seem quite clear from consideration of the facts... [in the
interest
of keeping at least this IETF list discussion civil and professional,
I'll not comment re. your "is beyond me" statement other than to note
that the implications seem clear to me]
That is your interpretation of our motives, with which I completely
and utterly disagree. Your reasoning leads to anyone from asking for
advice related to MIME registration procedures being labelled as
doing "things incompatible with MIME", which is patently absurd. We
asked for advice, that advice was given and taken, and the format is
now registered under video. The registration procedures worked as
defined.
[text/t140]
The issue is that there has to be a specification of the format.
The
registration form points to RFC 2793. The format specified in
2793 is
what is shown above. If the authors of 2793 meant that something
else
was in fact the media format, then that something else should have
been specified, as I said earlier:
RFC 2793 is made obsolete by RFC 4103.
Same situation. Moreover, the IANA MIME registry for text/t140
points to
[RFC-ietf-avt-rfc2793bis-09.txt] (I checked again now). Why
haven't the
AVT/RTP folks made sure that the IANA registry points to something
reasonable?
RFC-ietf-avt-rfc2793bis-09.txt is the document which became RFC 4103.
You should ask the IANA why they haven't updated their web page: the
failings in internal IANA and RFC Editor procedures are not the fault
of AVT.
As stated previously, the first 12 octets are part of the RTP header,
and the media data occupies the part of the packet labelled "T.140
encoded data". This is clearly stated in section 3.5 of RFC 4103 and
several times later in that document, and has been explained several
times on this mailing list. The format of the "T.140 encoded data" is
defined in ITU T.140, as indicated in sections 3.2 and 10.1 of RFC
4103. The issues you raise are explicitly addressed in the RFC.
No, while the RTP content may be specified for RTP, I can find
nothing in
2793 or 4103 that says what the MIME media format comprises.
In section 10.1 of RFC 4103 it states, using a standard MIME
registration template, that the media format is defined in ITU-T
recommendation T.140. If you read that ITU recommendation, you will
find it clearly defines the format.
So where precisely is the MIME media format specification, in a form
which clearly states that it is a MIME media format specification?
As I stated previously, the format is defined in ITU T.140 and
registered in RFC 4103. In section 10.1 of RFC 4103 ("Registration of
MIME Media Type text/t140") it clearly states:
Published specification: ITU-T T.140 Recommendation. RFC 4103.
I see "RFC 4103", but as noted above, there does not appear to be
anything
in 4103 that says what comprises the MIME media type format, if
indeed the
media is at all suitable for MIME.
RFC 4103 references ITU recommendation T.140. The ITU recommendation
states what comprises the media format content.
T.140 is not freely available; I have asked for specific
confirmation that
it in fact clearly and explicitly defines a MIME media type format,
but as
of yet I have seen no such confirmation. Two simple yes/no
questions for
somebody with access to T.140:
1. does T.140 contain the acronym/word "MIME"?
No, it does not. The media type registration template is in RFC 4103,
with the media format being defined in T.140. This is entirely
appropriate, and is consistent with other MIME registrations (e.g.
"application/postscript" and "image/tiff" are exactly the same, with
the MIME template being in an RFC separate to the media format
specification).
2. does T.140 contain the acronym "RTP"?
No, it does not. The media type is independent of RTP.
We're discussing MIME registrations using MIME registration forms
and
MIME registration procedures. RTP is irrelevant to MIME, and as
discussed earlier could and should be handled via an Applicability
Statement as defined in BCP 9 (RFC 2026) section 3.2. Details of
how a media type is transported via a specific protocol are issues
for an Applicability Statement, not for a MIME media registration.
Indeed this is true. That is why RFC 4103 contains both a MIME media
type registration and a statement of applicability which describes
how that media type is transported using RTP.
I see nothing in 4103 or the other RFCs discussed that resembles any
indication of an Applicability Statement. Indeed "pplicab" does not
appear anywhere in any of those RFCs, as it would if there were an
Applicability Statement or statement of applicability or any such
thing. Instead there are descriptions of formats, and as MIME media
types have formats, that is what has been discussed.
Nothing in RFC 2026 requires the words "applicability statement" to
be in the RFC. The RFCs clearly state that they define "RTP payload
formats", a term defined in RFC 3550 (STD 64), which define "how a
particular kind of payload data, such as H.261 encoded video, should
be carried in RTP" (see section 13 of RFC 3550). This is clearly an
applicability statement for a media format, defining how that media
format can be transported within RTP.
In addition, these documents also register media formats, with
reference to external specifications of those formats.
Despite this, you have
repeatedly complained that the RTP specific parts of the RFC do not
conform to the MIME rules, when they clearly do not need to conform
to those rules since - as you point out - "RTP is irrelevant to
MIME".
No, I have noted that the format specifications that are presented in
the RFCs referenced as the format specification show content which is
incompatible with MIME.
No, they do not. The specifications of the media formats conform to
all MIME rules applicable to the top-level media types under which
they are registered. The specifications of the RTP payload formats do
not conform to MIME rules, but do not need to since they are not part
of MIME.
You have stated that those are in fact not formats (though that is
how they are labeled) but instead comprise some sort of
Applicability Statement (though neither that term nor anything
resembling it appears in the RFCs).
Again, you are confusing an "RTP Payload Format", defining the RTP
specific processing of a media format, with the media format itself.
[This is referring to sections 4 and 5 of RFC 3267]
The term "RTP Payload Format" is clearly defined in RFC 3550 (STD
64). Since section 4 of RFC 3267 describes an RTP payload format, it
seems an appropriate term to use. Section 5, as you might expect from
its title, describes a file format. Both formats use the media types
registered in sections 8.1 and 8.2 of RFC 3267. There is nothing
inappropriate in this terminology - MIME does not disallow other uses
of the term "Format".
True, and unless I misunderstood earlier statements to the effect that
RTP does not use MIME mechanisms (e.g. Content-Type field), section 4
seems irrelevant (except that parts of section 5, which would seem to
be relevant to MIME, refer back to section 4 "formats").
Section 4 of RFC 3267 is indeed irrelevant to MIME, as it defines an
RTP payload format. As Steve and I have repeatedly explained, the
equivalent sections of RFC 4103 are also irrelevant to MIME, since
they also define an RTP payload format. For this reason, your
complaints about the alleged non-conformance of RFC 4103 with MIME
rules make no sense, since they relate to the RTP payload format,
which we agree is irrelevant to MIME.
Section 5 might be relevant to MIME; at best though it is poorly
specified as it does not stand alone (in part because of cross-
references to the RTP-specific section 4).
Section 5 defines a MIME format, yes.
The comment to which you are responding was about RFC 3267. That RFC
specifies a media file format consisting of a concatenated sequence
of audio frames with a magic number header for identification in
section 5. Since this is an audio format, there is no need for the
data to be compatible with the MIME text top-level type.
True, my error. It's not clear precisely why we're discussing audio;
IIRC somebody said the amr subtypes were defined for combined MIME/RTP
use, but recent discussion seem to indicate that the format specified
isn't in fact for MIME, but is an RTP-specific transport data
specification. Which seems contrary to the claim of combined use.
The formats are widely used with RTP, and for more traditional MIME
file transfer purposes.
[RFC 3267]
The text makes reference to
section 4.1 or RFC 1890, which is RTP-specific whereas the section
making that reference is the Multi-channel Header subsection of
the "Storage Format" section. The Storage Format section ends
with a
subsection "Speech Frames" which defines a binary one-octet header
which refers to a non-existent section 4.1.2 and to 4.3.3 (RTP-
specific)
[...]
RFC 3267 is an audio format
Yes, OK, but where are the missing 4.1.2,
The reference to section 4.1.2 would appear to be an incorrect
reference to section 4.3.2. We'll add this to the errata list for the
RFC.
and why are sections supposedly dealing with a MIME type referring
to RTP-specific transport protocol data specifications (as seems to
be the claim)?
Because the format of the data is the same in both cases, and it
seemed easier to reference the specification rather than copy-and-
paste the text.
I don't think you are concerned, from a MIME perspective, that
some of the octets of the TCP header carrying email may be 0x00,
0x0A or 0x0D.
MIME media type registrations do not include TCP packet header data
in the media format specifications. They specify exactly and
exclusively the media format to be registered. MIME media type
registrations should not include RTP packet header data. They
should
specify exactly and exclusively the media format to be registered.
Look for example at RFC 3023, which defines several media types
in the
text and application trees. It contains no TCP header packet
data or
HTTP start lines or header fields, etc. -- only the
specifications for
the media types defined.
Your complaint now seems to be that we have used a single document
both to register a media type, and to explain how that media type is
transported within RTP. RFC 2048 does not prohibit this, and RFC 2026
explicitly allows the applicability statement for a technical
specification to be part of the same document as that specification.
The incompatibilities with text media types and RTP remain.
No, they do not: this assertion is factually incorrect. The RTP use
of text media formats is in full compliance with all the MIME rules
for text media. Your complaints relate to the RTP headers, which are
not part of the media format data, and so do not need to conform to
MIME rules.
It has been claimed as justification for a combined registry that
some few audio types (but not text, video, model, multipart, image,
message, application types) are registered for combined use. On
examination, the specifications containing the registrations do not
clearly specify how those media are formatted in a MIME context.
Rather than being a rather weak argument in favor of a combined
registry, it appears that the media types are in fact not used with
MIME and that argues in favor of a separate registry.
On the contrary, the media types in question are in daily use by tens
of millions of users, both with RTP in more traditional MIME uses.
Colin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
|
|