Mr. Jones - welcome to the smoke screen. What you are finding is that this
IETF does not have most of the formal infrastructure that its documents
allude to. It has no formal method of creating Informational Filings and in
all instances passes them off as Historic as though only genesis that
happens within the IETF counts in this world.
Understand some of my frustration at trying to get other key entities to
adopt processes with the IETF when they have no
1) process for inducting information from external sources that is
published for reference and not for development or respect for copyrights of
contributors, or those filing for informational purposes where there is no
copyright conveyance beyond joint-publication rights.
2) process for accepting formal notice of anything relative to this
thing called erroneously a Request For Comments (which based on IETF
processes could be called an Internal Technology Vetting Document since it
really isn't a 'request for anything' but rather a proclamation for people
to base other things on.
3) method at the organizational level of cross-collaboration on
anything with anyone... there have been some unusual instances in various
WG's where cross-collaboration between other externals and the WG occurred
on a project level; but at the organizational and more importantly the
brand-recognition level - this IETF has nothing really implemented to
address these needs.
Ah well...
todd glassey
----- Original Message -----
From: "Paul E. Jones" <paulej(_at_)packetizer(_dot_)com>
To: <dcrocker(_at_)bbiw(_dot_)net>; "'Brian E Carpenter'"
<brc(_at_)zurich(_dot_)ibm(_dot_)com>
Cc: <ietf(_at_)ietf(_dot_)org>
Sent: Sunday, August 13, 2006 8:09 PM
Subject: RE: RFC 4612 - historic status
Dave,
This is the second document this year that I published through the IETF
that
was classified as "historic". The was RFC 4351.
In both cases, I was working in the ITU on fax and modems issues and with
people looking for a way to efficiently transport modulated signals
between
two PSTN gateways over IP. For both cases, consideration was given to:
1) We needed a way to provide security
2) We were working with a narrow scope (GW to GW)
3) We wanted something that would not be resource intensive
4) We wanted to minimize signaling requirements
Since, for all intents and purposes, "fax" signaling or "text" signaling
between two PSTN gateways is nothing more than an alternative
representation
of "audio", it was decided that we would define a means of switch media
types on the fly. The reasoning seems good, engineers liked it, and the
standards were approved (ITU-T Rec. T.38 and ITU-T Rec. V.151).
We were able to meet all of the above (and other) requirements using this
method. For the folks I worked with, it was really no different than
sending RFC 2833 to represent DTMF. (There are known differences in the
media characteristics, such as a change in bandwidth usage, transmission
rates, etc. However, all of those aspects were well understood and not
really subject matter for these RFCs, anyway.)
We could have elected to not publish RFC 4351 and simply include it in
ITU-T
V.151. Now, we have an "historic" document in the IETF referenced by a
brand new international standard published by the ITU. Now, that is
silly.
To some extent, I regret having presented the text to the IETF in the
first
place.
In the case of the audio/t38 document (RFC 4612), this was written only
because, if I read RFC 4288 correctly, such a document is needed to
register
a MIME type in the IETF tree.
In the case of MIME, we could have used a different tree (e.g.,
audio/itu.t38). However, as far as I know, there is no such tree.
Secondly, while it might be easy to get such a tree, there are various SDP
parameters and other such things the ITU has defined in recommendation
(e.g., V.150) for which there are no "trees". I like symmetry.
For those SDP parameters to which I refer (ITU-T Rec. V.150 being one such
standard containing unregistered parameters), the IETF has apparently
refused to publish an RFC for at least one SDP parameter (gpmd). This
leaves the industry in a very awkward situation, since we have SDP
parameters appearing in ITU standards that are not registered with IANA.
The short of it is that the cooperative spirit and the process are broken
to
some degree. I don't have my favorite standards body, though I have
worked
in many of them like a good number of the other folks in the IETF. So,
don't assume I'm arguing from one side or another. I'm just an engineer
caught in the middle of standards-making organizations trying to get my
job
done.
I wonder how customers might react to seeing new gateway hardware produced
utilizing "historic" RFCs. What does that mean?
Paul
-----Original Message-----
From: Dave Crocker [mailto:dhc2(_at_)dcrocker(_dot_)net]
Sent: Thursday, August 10, 2006 2:13 PM
To: Brian E Carpenter
Cc: ietf(_at_)ietf(_dot_)org
Subject: Re: RFC 4612 - historic status
Brian E Carpenter wrote:
Historically, "documenting for reference" produces an Informational
status,
rather than Historic.
Yes, and the idea was to make a stronger statement than "for
reference".
iirc, we considered briefly approving it for Informational and then
immediately reclassifying it as Historic. But that seemed silly.
If the IETF wanted to "make a statement" why not merely add text that
makes the
desired statement?
Again, this has been the usual approach. Why change from that?
Going to Informational and then Historic would, indeed, be silly. It
confuses
the semantics of Informational, since it implies that Informational has
some
sort of standards status.
The model that has the IETF focus heavily on matters of "precedence",
particularly with respect to specifications that are not standards
track,
seems
questionable, at best. It means that rather than relying on questions
of
technical efficacy, scaling, and the like, the IESG is instead worrying
about
future, hypothetical, unstated human abuses.
At the least:
concern that the format not become a precedent
for future media types
should produce explicit text added to the document, so that readers can
understand whatever problems there are with this approach.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf