> Date: 2005-07-06 04:06 > From: Stephen Casner <casner@xxxxxxx> Stephen, you wrote: > That's not it. Of course all the existing registrations would be > copied. However, all of the many RTP-related RFCs that refer to MIME > registrations would become obsolete and need to be revised. A fair > number of those RFCs are referenced by other SDO's documents. Are any of those RFCs on the Standards Track? Are they all at full Standard? Those which are Standards Track but not yet full Standard need to be followed up on to advance on the Standards Track, and that would be a good time to do a global replace of MIME with RTP and add an IANA considerations section directing IANA to mark the type in the MIME registry as obsolete. Should take about 30 seconds to do that. The MIME registrations will never go away (unfortunately for MIME), so if a particular implementer goes ferreting through the MIME registrations because he has an old copy of a document that says MIME, he'll still find the type. > Some of the motivations for moving the RTP > namespace into the MIME namespace were: > > - To avoid different names for the same media format, such as MIME's > audio/basic and RTP's PCMU. More on this below. To date, I know of no "same media format" for MIME and RTP; Magnus specifically mentioned audio/amr, which has different formats, and alluded to a tiny number of others but was not specific. I could find no other references to audio/basic or PCMU in your message. > - To help populate the MIME audio and video spaces which were very > sparse. Filling up the MIME registry with names of things that cannot be used in MIME doesn't seem like a sound reason. > The AVT working group did a lot of work between then and now to > specify the mechanism for the registrations and to create > registrations with what I believe was careful attention to detail. > This process has imposed very little load on the "MIME folks"; in > fact, it has received little notice until the recent consideration of > two subtypes under the text major type. That is because of the way MIME works and has always worked; the text type is for media containing human-readable (w/o software) text. The fallback is to text/plain, which is what the Internet Message Format carries in the absence of MIME. There are relatively few interoperability considerations for audio and video media subtypes, so the attitude is largely "ho hum, another subtype; who cares". Not for text. More below. > In my opinion, we should set a fairly high bar for the decision to > change from the status quo and induce the overhead of obsoleting a > large number of RFCs. Red herring. The MIME types remain; no RFCs are obsoleted, and there is ample opportunity to adjust those specifications as necessary and with minimal effort in the course of the normal Standards Track progression. > There is no proposal to change the way email, html, and fax use MIME > types. On the contrary, any registration of a format which requires software for interpretation, contains binary content, etc. under the MIME text type would require massive backwards compatibiliy- and interoperability- breaking changes. Given the mission-critical use of the affected applications (e.g. IETF business such as this and other mailing lists) that is simply unacceptable. > Perhaps "clean up" is not the most appropriate term. I would > say what's needed is to be more specific about the domains in which > media types are used, without changing at all how they have been or > will be used for email, etc. Perhaps we can agree that only "domains" which respect the long-standing requirements for registration under the text media type are permitted to use text subtypes. > > > The issue I see is that with two separate registries one will not > > > seriously consider the names in the other registry. > > > > Why should a MIME implementer need to "consider" RTP names or vice versa; > > e.g. text/plain or text/html vs. RTP? > > This question does not make any sense. It is a simple question, and it would help understanding if there were an answer rather than a brush-off. Why would an RTP implementer care about text/html if RTP cannot carry text/html? > Someone wanting to know more > about text/plain would look up that media type. Yes. Now why would an RTP implementer care about text/plain? > However, it would be > good if someone who was thinking about sending snippets of audio > captured from a GSM phone considering the registration of audio/GSM > that is defined currently only for the transport via RTP. If sending via RTP, sure. If the type cannot be used in the MIME "domain", then there's no point for sending it via MIME as that type. Now perhaps some GSM phone software implementer might wish to convert that type to something amenable to storage in a file and transport via MIME; such an implementer will need to consult the specifications applicable to both sides of the conversion software regardless of whether there is one registry or two -- a clear division in two registries helps such an implementer by focusing his attention on appropriate types for each side, and helps other implementers as well. > > Why? An particular implementation is either handling RTP streams or MIME > > data, and would only need to be concerned with the appropriate registry. > > It seems to me that the main concern in this discussion is "leakage". It's an operational concern which may adversely affect security and interoperability. The main concern is about appropriate use of the MIME registry so that interoperability and security are not adversely affected in widely-deployed, mission-critical applications which have always conformed to the MIME rules. > Leakage occurs precisely then implementors and users don't reference > documentation. If the documentation says that a particular media type is registered in the "Multipurpose Internet Mail Extensions (MIME)" registry as a MIME type and that media type isn't suitable for MIME use, then the documentation is at fault and may lead implementers astray. > If we have different names for the same media format > when carried in RTP and in email, I'm still waiting to hear of such a case which is truly "the same media format". > this increases the likelihood that > the name from one domain will be used incorrectly in the other. I still haven't heard an explanation of where the *name* (as distinct from some protocol-specific code) is actually used in RTP. Having separate registries for separate things does not imply such problems. One could in theory register a language tag "foo", a charset "foo", a text media subtype "foo", an SMTP protocol type "foo", an diagnostic type "foo", an MTA name type "foo", etc. There is no doom-and-gloom usage problem because each namespace has a specific application; a charset name won't end up as a media subtype or vice versa, a language tag won't end up in a Received field "with" component, etc. > I believe it is better to have an entry in one > unified registry that says for subtype foo that "this type is defined > only for transport in RTP" than to have separate registries with > nothing for the name foo in the MIME registry. I understand that that is the belief of many RTP folk, but I see no rationale supporting that in the wide community interest. > That is, negative > information is better than no information. Negative information is e.g. the fact that text/foo isn't registered as a MIME type. Registering text/foo in the MIME registry with some note saying "don't use this MIME type for MIME" buried in gobbledygook in a hundred-page specification isn't negative information; it's contradictory information, obfuscated. > I don't understand this point. Are you saying that all audio should > be only one subtype, No. > and that a compression scheme such as AMR should > be expressed as a content-transfer-encoding or the equivalent? That > would be a pretty extreme view. It's not necessarily my position, but that is more-or-less the way MIME works. See some discussion on the ietf-822 mailing list, e.g. http://www.imc.org/ietf-822/mail-archive/msg05807.html Depending of course on pertinent details such as whether compression is in some way specific to audio (e.g. mu-law as used in telephony) or just some way to compress non-specific data tacked onto a basic media type. > RTP does not communicate the "audio/amr" selection at all. RTP > carries a small integer Payload Type that is dynamically bound to a > payload format such as audio/amr by some signaling protocol. So what's the problem? Use the same integer, bind it to some name in an RTP registry (use audio/amr or something else; that's up to RTP to specify) and carry on as before. > Are the only applications of "text/plain" ones that put that string > after "Content-Type: " ? As text/plain is the default, e.g. in the absence of a Content-Type field, that's a loaded question. "text/rtf" in a MIME context is always identified as such by a Content-Type field. > I doubt that this is a significant problem on either the MIME or RTP > side. In both cases, the application supports some set of types which > it keeps in its one little list. The application does not go to IANA > to look up the name in a registry. Many applications have lists of MIME media types; while it's true that applications don't consult the IANA MIME registry in real time, the lists come from somewhere -- putting the burden on thousands of application developers to wade through irrelevant registrations doesn't solve the problem, it shifts the burden (RFC 1925 "(6)"). > > In any event, merely looking up something in a registry simply confirms > > whether or not there is a registered type. At least in the case of > > MIME, it may be necessary for an implementer to determine what parameters > > are required, which optional parameters are valid, what effect any > > parameters might have on processing, etc. As the registry is currently > > organized, that means wading through each registration form in detail > > and consulting the detailed specification. Why should MIME > > implementation programmers have to wade through RTP registration forms -- > > what purpose would that serve? > > The implementer of a system wanting to use a media type will look for > a registration of a type that corresponds to that medium. The mind boggles. If one has a media type, that media type has a name, and that is the registered (or private-use) name. One doesn't pick some name because it looks nice; the point is to communicate information from sender to receiver about what the media actually *is*. Exceptions being miscreants such as those who propagate worms etc. by mislabeling content and relying on non-conforming implementations to do nasty things with such content. > One hopes > that the subtype name choices allow a more narrow search than linear. One hopes that choices in a MIME context allow for all MIME types and can be readily expanded as new MIME types are added. > An implementor wanting to specify a MIME media type for a new format > would do well to reference the registration for RTP transport of that > format (if it existed) because it is likely that at least some of the > parameters required to identify the type for RTP will also be needed > to identify the type for MIME usages. Assuming that you mean a specification writer rather than implementer, that makes no sense as RTP transport is incompatible with MIME (at least as Magnus has described the issues w.r.t. media formats). > > Unless I'm reading RFC 3267 incorrectly, there are in fact *two* > > separate formats, one for RTP use (sect. 4) and one for MIME (sect. 5). > > One of which will never be seen in MIME, and one of which will never > > be seen in RTP. So why force two sets of programmers to wade through > > twice as many format specifications than either will need? > > The frames of audio are the same in both cases, so defining both uses > together makes a lot of sense. Well, audio is fundamentally an analog signal, which can be digitized and formatted in many ways. SUre, a given audio signal can be represented in different formats, and it makes some sense to define some common operations. > Further, many applications or > application suites will use both means of transport. With conversion between the different formats, one of which actually uses some sort of code for identification, and the other uses a name. > > With separate registries, the need to redesign the pages would be > > avoided, which is of course easier than such a redesign. > > These are trivialities that do not cross the high bar. It's real work for IANA and for implementers who have to consult the IANA registry (adapting to changes in format, etc.). > Nothing about framing needs to be included in the main MIME documents > nor the registration form. It *is* currently in the draft registration procedure. > All that's needed is a recognition that > media types may be used differently in different domains, In the MIME registry, "text" means what (primarily) RFC 2046 says it means, and that is human-readable w/o software, no binary content, CRLF line endings, no lone CR or LF, etc. If you want different rules, you need a different registry. > > > > These have been observed issues with use of the MIME registry for RTP > > > > > > What are you referring to. > > > > The "what is framed" question and the comments about incompatibility > > of proposals for registration under the MIME top-level text media type. > > There is a certain amount of angst in the current discussions, but I > believe it is the result of misperceptions. I believe Colin's > messages expressed the issues well. A number of strong theoretical > concerns have been described, but they don't map to reality. Careful, that path leads to solipsism. The reality for MIME is documented in the MIME RFCs and is a universal reality. You can of course pretend that there is some different "reality"... > > 3267 gives very different format specifications and different security > > considerations; precisely my point. > > The sequence of audio frames is just the same in both modes of use. That's nice; the sequence of words, paragraphs etc. represented by text/html and text/rtf may be the same, but the formats are quite different; while a human may ignore the (non-binary) markup and understand the content, the formats remain distinct and should be labeled distinctly. Feeding one format into an interpreter designed for the other is unlikely to be useful. > > Re workload: > > o for whom? > > For the AVT working group in particular, which has operated in good > faith building in the MIME registry for years. I see. Workload for MIME implementers doesn't count. Workload for IANA doesn't count. Workload for the MIME media types reviewer doesn't count. But 30 seconds in the course of a required update is a big deal, because some AVT WG editor will have to do it. As for "good faith building in the MIME registry", playing by the MIME registry rules for text media subtypes is necessary to qualify as "good faith". > > o short-term or long-term? > > > > A single registry means more work for MIME implementers and reviewers, > > both short-term and long-term, and doesn't improve the situation. > > I don't think that is true. As I said, specification of additional, > domain-specific details for registration procedures falls to those > working in the domain. Let's see, there are >600 types and ~70 of those are for RTP, so specification of the "additional ... details" means an order of magnitude more work for MIME folk than AVT/RTP folk (not to mention IANA's work). Yes, I see why that looks favorable from the AVT point of view. > We have been registering RTP payload formats > for some time with little impact on MIME reviewers until the recent > discussion ensued. And I can't see how the impact of an audio/amr > registration on MIME implementors interested only text/plain can be > any more than trivial. Apples vs. Oranges. Audio details are largely uninteresting as far as MIME implementations are concerned. About the only item of interest is whether or not some required parameter is specified (as with "rate" for audio/L16). And the extent of that is that if a MIME implementation encounters such a type which is specified as having a required parameter, but the parameter is in fact not present, there is a MIME error. For video, as far as I know there are no required parameters for subtypes that would affect parsing of a MIME message. Text/directory has specific processing requirements and a required charset parameter, text/plain has specific characteristics, and most text types can specify a charset parameter, which may affect the fallback mechanisms. As for "MIME implementors interested only text/plain", that might well be the empty set, as explained below. > I doubt that anyone reads through all the full specifications in the > registry to decide which type to use. So do I; but that's not what was claimed. An implementer who needs to handle MIME messages needs to understand the implications of each MIME media type, including parameters and interaction with the specified fallback mechanisms (RFCs 2046, 2049). > Finding a type is not hard. I doubt that anybody wakes up in the morning and stops to think "what media type name shall I look for today". Somebody with a media type to send presumably knows what type it is, and need not look for a name -- he already knows what type he has (and MIME types specifically provide for things such as magic numbers to facilitate association of the name in some non-MIME environments). Somebody receiving a named media type via MIME is informed what the media type is; that type is either supported or not by the recipient's application -- if not, some implementer needs to set to work, and that brings us back to the main issue, namely non-MIME clutter in the MIME registry makes extra work for MIME implementers with negative benefit to the community. > Learning the details of how to implement that type correctly requires > looking at the full specification for that type, not not others. No. The fallback mechanisms specifically require handling of unrecognized types as if they were a specific registered type (sometimes conditionally, as in the case of text, where there is a condition related to the specified charset (default US-ASCII)), and obviously (at least to MIME implementers) those specific types need to be supported in accordance with the MIME specifications -- RFC 2049 goes into some detail about this. MIME applications deal with the gamut of MIME types; one does not use one mail user agent (MUA) for text/plain and a different one for text/html and yet another for a message with a combination of text/html, image/jpeg, and audio/32kadpcm -- a hypothetical MUA which could handle only a single media type would be at best a niche product; it would certainly not be used by recipients of a rich variety of MIME messages, at least not without some add-on support for real MIME media type handling. A conforming MIME implementation, upon receiving a hypothetical unrecognized type "text/foo" MUST operate in a specific manner: 0. in the absence of a charset parameter, the charset defaults to US-ASCII, which must be recognized 1. if the specified charset (default US-ASCII) is unrecognized, the media must be treated as application/octet-stream. Application./octet-stream has certain handling requirements, and obviously a conforming implementation needs to handle application/octet-stream appropriately. 2. if the charset (default US-ASCII) is recognized, the media type must be treated as text/plain, which has its own requirements. There are similar considerations for the other top-level media types, so the absolute minimum that a conforming MIME implementation must handle includes text/plain, application/octet-stream, multipart/mixed, multipart/alternative, multipart/digest, and message/rfc822; also encodings quoted-printable, base64, 7bit, 8bit, and binary; and charsets US-ASCII and the ISO-8859 family. The idea that a MIME implementation can be based on "the full specification for [a single] type, and not others" represents at best a serious lack of understanding of MIME. In the case of the specific hypothetical "text/foo", with no charset parameter and no specified transfer encoding, a conforming MIME implementation will treat that type as 7bit, text/plain, US-ASCII. In turn, that means that the media represented by that type: a) may not contain any octets with the high-order bit set (no binary data) b) may not contain any octet with value 0x00 (i.e. ASCII NUL, therefore no binary data) c) must contain a CRLF (0x0D0A) pair with at most 998 other octets between such pairs, and those pairs must represent line endings d) there may be no lone x0D or 0x0A octets (no binary data) e) obviously, the charset of text must be US-ASCII Now there are many ways in which a text media type containing ancillary timing information could be made to fit within the MIME framework. As an arbitrary example: i) a charset parameter could be specified, default US-ASCII, only MIME text/plain-compatible charsets allowed (RFC 2046). That permits use of e.g. utf-8 if a charset parameter is specified, however the default must be US-ASCII. ii) CRLF line endings iii) timing information in ASCII alphanumeric format, with some suitable markup mechanism (e.g. XML). Binary data cannot work unless there is some mechanism to prevent 0x00, 0x0A, and 0x0D octets. None of which is rocket science, and the last consideration could be addressed in a variety of MIME-compatible ways. But RTF folk have instead, despite "careful attention to detail", proposed a format which does not use US-ASCII as a default charset, which has no provision for a charset parameter, no requirement for use of charsets compatible with MIME (indeed, an explicit use of UTF-16, which is not MIME-compatible for text/plain), which does specify CRLF line endings, and which includes binary data with no provision to exclude 0x00, 0x0A, or 0x0D octets. In short, it is incompatible with the MIME text top-level type. The simple rule -- necessary to ensure interoperability -- is "MIME registry, MIME rules". If the RTP specification writers were to conform to the MIME rules -- which are in plain view in RFCs 2046 & 2049 -- there wouldn't be an issue; mind you, the types might be of little interest outside or RTP, and would still cause busy-work for MIME implementers. As conformance is not the path chosen by the RTP folk, the only ways forward that do not sacrifice interoperability have already been proposed, viz: 1. a separate registry 2. a separate top-level type for RTP "text" (using some other type name) with fallbacks and defaults different from the MIME top-level text type 3. conformance to MIME criteria _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf