Just a +1 to the thrust of Paul's suggestion. The I-D does appear a bit over complex to me, S. Paul Hoffman wrote: > At 2:20 PM -0400 8/23/08, John C Klensin wrote: >> --On Saturday, 23 August, 2008 14:55 +0200 Frank Ellermann >> <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@xxxxxxxxx> wrote: >> >>> John C Klensin wrote: >>> >>>> My hope is that we can discuss and figure out whether >>>> the community likes and will accept the general idea. >>> What *is* the general idea ? If it's "attaching" one >>> or more figures / images to an RFC I'm fine with it. >> That is it. No intention to solve all possible problems, just >> what appears to us to be a large and growing subset in which >> pretty-printed figures, images, and the like would significantly >> add to RFC comprehensibility without having to reopen the debate >> about alternate base formats, searchability, etc., etc. > > While it is easy to agree with the "no intention to solve all > possible problems", the proposed solution is much more difficult than > is needed, and is also prone to problems in the long term. > > From the draft, the problem to be solved is: > > Documents in the RFC series normally use only plain-text ASCII > characters and a fixed-width font. However, there is sometimes a > need to supplement the ASCII text with graphics or picture images. > > Given that problem statement, a simple solution would be for RFCs to > be able to reference art files archived by the RFC Editor using > format-neutral URLs. Initially, those art files could be GIFs, PNGs, > or PDFs. Years from now, when there are no commonly-available readers > for a particular image type that was used earlier, the RFC Editor of > the time can convert the old images to newer ones. > > An example of a format-neutral URL might be > <http://www.rfc-editor.org/rfcs/rfc5110.art>. > > This proposal takes no changes from the current format for Internet > Drafts or RFCs. It does require that the RFC Editor add some tools > and maintain URLs in a consistent manner, but that is what they are > paid to do. It also avoids the problems that have been listed so far. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf