> Date: 2005-07-20 16:31 > From: Colin Perkins <[EMAIL PROTECTED]>
> On 20 Jul 2005, at 18:26, Bruce Lilly wrote: > > I recall making no statements about RTP or the way it conveys data > > save for the fact that that is as irrelevant to defining a media type > > as are details of TCP or UDP etc. > > You have made, and continue to make, numerous statements about RTP > payload formats and their associated media type registrations which > are factually incorrect. The most obvious of these is your insistence > on treating the RTP transport protocol headers as part of the media > data, as you repeatedly do in the message to which I am replying. I have made statements about the only publicly- and freely-visible format specification which is referenced by MIME registration forms. 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. 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. > 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. > 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. > > 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] [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? > 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. > > 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. 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"? 2. does T.140 contain the acronym "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. > 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. 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). > [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 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). > 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. [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, and why are sections supposedly dealing with a MIME type referring to RTP-specific transport protocol data specifications (as seems to be the claim)? > >> 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. 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. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
