--On Monday, 14 August, 2006 08:56 +0200 Brian E Carpenter
<brc(_at_)zurich(_dot_)ibm(_dot_)com> 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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf