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