John, In the case of RFC 4612, I was not terribly surprised given the fact that RFC 4351 had already gone through the same discussion. In any case, the ITU had long finished its work on T.38 before the IETF completed its work on the audio/t38 registration. T.38 does not reference RFC 4612, obviously. In the case of RFC 4351, that was a surprise and I argued with a few folks over the decision to make it historic. However, I lost the argument. However, losing the argument does not change the minds of those doing work in the ITU. I did report the situation to folks in the ITU and there was serious consideration given to just not publishing the IETF text at all OR just re-publishing it and not referencing the IETF text. (V.151 now references RFC 4351, which I think was the best outcome in spite of the "historic" status.) I will not disagree with the beauty of media type separation. Nonetheless, I think it is important to consider the fact that the different organizations have different ways at looking at a problem. The IETF views voice and DTMF as "audio", video as "video", fax as "image", and TTY/TDD tones as "text". If I were to implement a PC application, that would all make perfect sense. But, what do we call video with embedded text sub-titles? What is the difference between "image" and "voice" to a gateway that is responsible for receiving signals from a PSTN circuit, transporting those over IP, and delivering those back to a PSTN circuit? If one has a rack of gateway boxes that provide service to 100,000 DS0s, how much additional money does the buyer want to pay in order to cleanly separate those media streams received over that circuit? Cost was definitely a consideration in the decision-making process. I'm still beside myself that folks are willing to say that DTMF is a special case of audio, while fax or text tones received from a switched circuit are not. Following the logic of separating text and fax, DTMF should have been separated and placed into the call signaling path. In any case, as I said: I'm more or less the guy caught in the middle of two organizations with differing opinions. The IETF can do what it wants. The ITU can do what it wants. At the end of the day, we are all scrambling to get the aging SIP stuff to work in the face of Skype dominating the market ;-) My point: doing something the most architecturally "pure" way does not necessarily lead to profit or success in a reasonable time frame. Compromises must be made and progress must be hastened. By the time you get it all working the "right" way, technology will change, values will change, and applications will change. This is probably much less true for transport-layer matters than applications. Applications can be quite flexible. The nice thing about applications is that they can change over time. While audio and fax might be sent over the same RTP session today (they are not, BTW: today, fax is sent as "image/t38" and it's very painful and entirely insecure), that can be changed over time to operate over a separate path (cleanly). It may or may not be RTP by then, because perhaps that might also change. Perhaps fax will disappear completely. Perhaps a fax machine will be a device that has a keyword that allows one to enter an e-mail address, scan pages, and transmit TIFF or PDF files. Perhaps the World's preferred file formats might also change. Perhaps it will be Microsoft's new XPS? Paul > -----Original Message----- > From: John C Klensin [mailto:john@xxxxxxx] > Sent: Monday, August 14, 2006 3:53 AM > To: Brian E Carpenter; Eliot Lear > Cc: Paul E. Jones; dcrocker@xxxxxxxx; ietf@xxxxxxxx > Subject: Re: RFC 4612 - historic status > > > > --On Monday, 14 August, 2006 08:56 +0200 Brian E Carpenter > <brc@xxxxxxxxxxxxxx> wrote: > > > Eliot Lear wrote: > >> Paul E. Jones wrote: > >> > >>> I wonder how customers might react to seeing new gateway > >>> hardware produced utilizing "historic" RFCs. What does that > >>> mean? > > > > It means that one standards body has decided to cite a > > specification > > that has been deprecated by another. > > > > It would have been better, imho, if ITU had decided to cite > > the non-deprecated > > image/* MIME types, but that is not a decision the IETF can > > control. > > Brian, > > I don't know the history of this, but it seems to me that, while > the IETF can't "control" the decision, there are extensive > provisions in the Liaison relationship with ITU that should > prevent such things from happening, or at least that should > prevent anyone involved from being surprised when they do. > Surprises are bad. In my opinion at least, the primary role of > a liaison relationship is to prevent the other body from being > surprised: one may not always agree, but one should reasonably > expect to agree to disagree rather than having an action taken > that appears unpredictable. It sounds to me from Paul's note > as if there was surprise here and surprise, to me, implies that > either someone was falling down on the job or, less likely, > deliberately ignoring clear signals. > > I suspect that, had I known about this and paid attention, I > would have agreed with the general thrust of the IESG decision: > I still believe that there is some advantage in differentiation > among the top-level media types for which knowledge of subtype > is needed to do anything useful. Unlike what Paul seems to > imply by his assertion that the signaling mechanisms are > essentially audio because they are analogous to DTMF tones, I > believe those non-text top-level types are differentiated by the > base capability that is required to _render_ the type, while the > subtype determines what is needed to interpret it so that it can > be rendered. On that basis, fax has been considered an image > type since MIME was first defined. So the questions this raises > for me about about procedures and how we work with other > organizations, not about whether giving this document a > deprecated status was appropriate. > > So... > > (1) Were the relevant ITU groups told, in a timely and > unambiguous way, about the IESG ("IETF") concerns about the > registrations and media types involved here? > > (2) Did they respond in a useful way? If so, was there any > consideration given to including a summary of the dialog, or a > reference to it, in the RFC-published document(s). > > (3) Was there any attempt made to incorporate text into the > document or, if necessary, to publish a separate document, > explaining the concerns? Such an arrangement would presumably > give the reader an understanding of the issues rather than > relying on the reader to notice a maturity level classification > and then interpret it as meaning that the IETF did not recommend > its use. > > (4) As I read it, RFC 2026 is quite clear that one can combine a > maturity level of Informational or even Standards Track with a > recommendation level of "Limited Use" or "Not Recommended" [RFC > 2026, Sections 3.3(d) and (e)]. Was that option considered? > While we have, de facto, defaulted all protocol-specification > RFCs to "Elective", the recommendation level machinery still > exists in RFC 2026 and, as far as I know, no effort has been > made to remove or deprecate it. > > If the answers to the questions above are "no", then why not? > Can we fix things at this point, presumably by publishing a > brief A/S explaining the issues and assigning a "limited use" or > "not recommended" status (presumably all of the needed > information is in the tracker) and then reclassifying the > subject documents as Informational... since it clearly provides > information about a media type that is in active use, however > well- or ill-advised that use might be? > > And, to raise a much broader question out of context, should the > various documents that describe and specify RFC documentation > (charters, RFPs, etc.) have been modified, in the wake of > effective elimination of STD 1, to require that recommendation > levels be included in RFC indexes and other relevant materials. > > john > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf