> Re: Ietf Digest, Vol 15, Issue 19
> Date: 2005-07-11 19:13
> From: Colin Perkins <csp@xxxxxxxxxxxxx>
> To: iesg@xxxxxxxx
> CC: ietf@xxxxxxxx, Stephen Casner <casner@xxxxxxx>
>
> Now the initial internet-draft deadline has passed I want to respond
> to the main points of this message. I don't believe that a point-by-
> point rebuttal is useful, due to the length of the message and
> repetition of arguments.
Indeed repetition is not helpful, particularly when it is a repetition
of a misstatement of position or of facts. I'll limit my remarks to
those cases.
> The audio/amr format contains identical media data, but the RTP
> transport is defined to strip the initial magic number, which is
> redundant with fields in the RTP protocol headers. The wide band
> version of AMR, and the related EVRC formats are similar.
Audio/amr explicitly specifies two separate media formats; if it
were merely a matter of some RTP processing, such processing could have
been specified separately from the format.
> The thrust of most of the rest of this message seems to be that the
> use of MIME type to identify RTP audio and video formats is
> uncontroversial,
Not completely uncontroversial, just less damaging than incompatible
text registrations.
> but you have a serious concern over use of text
> formats with RTP, since you believe these will disrupt MIME
> operations due to "leakage". This concern difficult to justify for
> several reasons:
It's not about "leakage", it hasn't been about "leakage"; that is a
minor issue that has been turned into a strawman in order to
demonstrate how easily it can be knocked down.
> 1) These types have been in widespread use for several years now;
> there have been no reports of actual operational problems, opposed to
> the theoretical arguments being made here.
No, the proposed text/3gpp-tt hasn't been in use as a MIME type. Of
course there are no operational problems; they have been nipped in the
bud. To the extent that text/t140 hasn't caused operational problems,
that is because it has been largely ignored (not without cost) because
it is in fact not a valid MIME type.
The arguments are not "theoretical"; mixing disparate types of
registrations in the single MIME registry, some of which do not use
MIME mechanisms at all, makes extra work for implementers -- work
which yields no benefits, only wastes effort and creates confusion.
If our specifications and procedures do not benefit implementers --
indeed when they cause confusion and busy-work -- there is a problem
which needs to be addressed. In this case, separate registries for
MIME and non-MIME content is an appropriate solution.
> 2) As has been mentioned previously, the text/t140 format, which
> started this discussion,
No, the discussion started with an IESG I-D requesting discussion, and
that followed a failed attempt to register "text/3gpp-tt" in the MIME
registry despite many incompatibilities of the proposed format with
the requirements for registration under the "text" top-level type.
> does comply with the MIME registration rules
> for the text media type. The format is plain UTF-8 text with implicit
> timing data, there are no embedded control characters, the CRLF
> sequence is only used to identify line breaks, and a language tag is
> available.
RFC 2793 (the AVT 2793bis draft is unavailable) specifies:
This is an example of a T140 RTP packet without redundancy.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC=0 |M| T140 PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp (1000Hz) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ T.140 encoded data +
| |
+ +---------------+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[...]
Published specification: ITU-T T.140 Recommendation.
RFC 2793.
First, the content excluding "T.140 encoded data" is not delimited
as not part of the text content (vs. e.g. text/html, text/sgml,
text/enriched, etc.). Second, unless it is absolutely guaranteed
that neither octet of the sequence number, none of the 4 octets of
the timestamp, and none of the 4 octets of the SSRC identifier can
ever have values 0x00, 0x0A, or 0x0D, the format fails to comply
with the text media type requirements, which prohibit those values.
If the format specified in RFC 2793 is not intended as the media
type specification, then the MIME registration form should not have
specified RFC 2793 or 2793 should have specified the exact format,
with any special protocol use considerations specified in a separate
RFC worded as an Applicability Statement (per BCP 9).
> The claimed "massive backwards compatibility- and interoperability-
> breaking" changes you suggest would occur have not been needed in the
> five years since this format was registered;
Then why are they specified in the format? If the format doesn't
need binary data, why is it in fact specified as containing binary
data (as opposed to say tagged ASCII-digit based representations of
sequence numbers, timestamps, identifiers, etc.)?
Claiming that untagged binary data is compatible with MIME text types
demonstrates either a gross misunderstanding of MIME or deliberate
misrepresentation of facts.
> The use of MIME types to identify RTP payload formats does conform to
> the MIME rules including the additional rules for text formats.
Where in the specification is the restriction against 0x00, 0x0A, and
0x0D octets (except for CRLF pairs as line endings)? How precisely
do you expect a human to find the text without use of software when
there is no tagging or other delimiter between binary data embedded
in the format and text?
> Accordingly, the status quo, using a single registry as done for the
> past several yeas, should remain.
False premises.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf