--On Friday, 29 November, 2019 06:01 +0100 Julian Reschke <julian.reschke@xxxxxx> wrote: >... >> Well, causing old tools, even non-public tools, to not work as >> they did before and without changes to those tools is a >> disruptive change. >> ... > > John, with all due respect, there's a reason I asked, so for > me this > question definitively is not the "wrong" question. > When we had these discussions many years ago, the assumption > was that > tools that operate on plain text RFCs would strip pagination > first (or > ignore it altogether) before doing what they need to do next. > I would > like to understand whether this assumption was wrong, and how > *exactly* > tools now break. Ok, that is fair. As can't speak for others but, as I think I said in my earlier note, some of my tools do searches on "[Page". I don't remember why but suspect it may have had to do with skipping over boilerplate or the like when those formats were changing. I don't know if my tools have other sensitivities (see below) and won't know until I try to use them and see what (if anything) breaks or do a careful code search. I'm also not claiming that it would be hard to change those tools --I just don't know without looking -- just that making me (and others) spend time adapting is possibly not in the best interests of the IETF if the total amount of time someone can spend on IETF work is limited and that adaptation time takes away from doing technical work. >... >> That is certainly what 7994 says. To me, the important >> question is whether publication in that (and other) documents >> is sufficient to warn the community about changes that may be >> incompatible with tools or working procedures used by >> contributors. If the answer is "yes", then every one of us is >> responsible for being thoroughly familiar with every RFC or >> announcement that might affect IETF procedures, publications, >> and other ways in which we do things so there is an >> opportunity to raise timely objections. I don't think we >> want to go there but should instead assume that people in the >> community should be warned by explicit questions and requests >> for consensus before incompatible changes are made. YMMD, of >> course, >> ... > > Heather has sent out mails, published FAQs, explained things > at the > plenary, and had a poster at the RFC desk for a long time. I > would say > this was hard to miss. Most of those messages have said that v3 is coming, there are big changes, throughput of the Production Center is likely to slow down. And, fwiw, I've seen the "RFC desk" twice in about three years and, for personal (but IAB/IETF-induced) reasons, have been somewhat tuned out). AFAICT, none of those messages have clearly said "if you are dependent on pagination and/or per-page headers or footer, get over it", at least without having that information buried (however unintentionally) in a lot of material that was basically noise. > PS: I have many other issues with the V3 switch, mainly that > we are now publishing "canonical" versions in a undocumented > and un-reviewed format. In comparison to that, the changes in > the produced text format currently seem to be a minor issue. What seemed to be a high likelihood of something like this happening was one of several reasons why some of us were concerned about, and opposed to, making the XML format the canonical/archival one. In this case, that concern was that, once actual deployment started, the community would discover a need to make adjustments to what was basically an untested specification. The need to debug something that had previously been tested only among the developers and other very interested parties and to make adjustments as the code was developed and evolved should come as a surprise to no one with any experience in programming or product deployment. Having the documentation be somewhat out of synch with that is no surprise either. Whether it is a minor detail or not depends on how the community reacts to the change. As I understand the announcements that have been made, people have the option of submitting text and having the Production Center sort of the details. So, suppose that, either because of the interactions with existing tools or because v3 is a someone-undocumented or under-documented moving target, some of us drop back to preparing documents using nroff (or one of its descendants), MS Word, or text directly and then submit the text files? You may know things that I don't, but I'd assume that would either require much more staff in the Production Center or would slow document throughput to a trickle for a long time. I would consider that a much more major issue that either the tools issue or the undocumented and un-reviewed format ones that feed into it. As usual, YMMD. john
