No Brian - this is NOT an issue of internal WG problems - its an issue of how the IETF interacts and uses or contributes to other SDO's efforts. That, if not proper for this mailing list is important and should be heard - so where do conversations in regard to organizational failings of the IETF go if not IETF@xxxxxxxx? Todd Glassey ----- Original Message ----- From: "Brian E Carpenter" <brc@xxxxxxxxxxxxxx> To: "Paul E. Jones" <paulej@xxxxxxxxxxxxxx> Cc: "'John C Klensin'" <john@xxxxxxx>; <dcrocker@xxxxxxxx>; "'Eliot Lear'" <lear@xxxxxxxxx>; <ietf@xxxxxxxx> Sent: Monday, August 14, 2006 2:22 AM Subject: Re: RFC 4612 - historic status > I suggest that instead of disturbing a couple of thousand people > with this discussion, it would be profitable to take it up > with the RAI Area Directors. They certainly know more about it > than I do. > > Brian > > Paul E. Jones wrote: > > 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 mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf