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@xxxxxxxxxxxx] > Sent: Thursday, August 10, 2006 2:13 PM > To: Brian E Carpenter > Cc: ietf@xxxxxxxx > 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@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf