[ncc-services-wg] Pre-PDP discussion: "All RIPE documents should be plain text"
Richard Hartmann richih.mailinglist at gmail.com
Mon Mar 18 19:00:09 CET 2013
On Mon, Mar 18, 2013 at 3:16 PM, Olaf Kolkman <olaf at nlnetlabs.nl> wrote: > > Note that the RFC Editor has just finished gathering requirements on how > to evolve the series to deal with i18n issues and inclusion of diagrams > (the document is approved for publication as RFC last week). > > http://tools.ietf.org/html/draft-iab-rfcformatreq-03 > > The RFC community is probably a little conservative as the RFC Series is > an 'archival series'. But that draft documents some pros and cons. The > issues that Gerry lists above can be found in the requirements draft. > We would see if we can find consensus on this, but personally, I wouldn't mind following the stricter rules of RFCs in policy documents. This would probably mean using nroff or similar as source format, but the actual documents would be text, if paginated inline. Pagination is a problem though. RFCs do not change very often whereas RIPE NCC policy documents do change quite frequently. Diffs between RFCs are uncommon and mostly useless whereas diffs between policy documents are very useful. This inline pagination would result in horribly mangled diffs, every time a line gets added/removed. I see that this point is being addressed in the draft, but there is no conclusion either way, yet. Other than that, after a quick glance, this draft sounds like a very interesting base for discussion and raises all major points. I know from personal experience how sluggish things are working with IDs and RFCs so I guess there is no ETA for releasing actual results? Richard PS: As noted in this thread, trailing whitespaces would allow reflowing quite easily. A line has a trailing whitespace? Reflow at will. It does not? It's static. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.ripe.net/ripe/mail/archives/ncc-services-wg/attachments/20130318/af72f26b/attachment.html>