On Tue, Oct 27, 2020 at 04:57:38PM -0700, Jim Fenton wrote: > but if some > people are reading HTML versions, PDF versions, and TXT versions, the > pagination is different anyway (and nonexistent for HTML) so trying to > reference something by page number is problematic. The thread is getting long so it is hard to not miss things said earlier, so let me repeat: My proposal was to add on IETF pages renderings with page numbers (not to remove any of the non-paginated renderings), AND make sure the pagination is consistent across them. References to pages number where and are always problematic, we already have rules in IETF/RFC-editor forther not to alow them in our own work product, but we can not prohibit others to do them, but most scientific yournal formatting guidelines AFAIK also prohibit them. Besides, if someone really wants to use it, they can do so today, pointing to the IETF provided PDF rendering, which has page numbers, but (IMHO silly) no pages in the TOC. > References should be to > section numbers, and if sections are so big that it???s hard to find some > text there, the author should really think about structuring the document > with smaller subsections. Nobody disagrees, we just got a dogmatic division whether those arguments can be reasonably used as an argument for IETF not to provide renderings with pagination (also in TOC). > What does seem strange (and maybe it has changed in the past year) is that > the plain text and PDF versions have tables of contents, and the html > version does not. I would like for the html version to have a table of > contents with links to anchors for each section. The native HTML version, e.g.: https://www.rfc-editor.org/rfc/rfc8815.html seems to have the TOC as a HTML object that is now rendered independenlty by browsers from the text. On my browser there is a menu button on the top right that you can click on whereever you are in the text. cheers Toerless > > -Jim > > > On Tue, Oct 27, 2020, 6:51 PM Phillip Hallam-Baker > > <phill@xxxxxxxxxxxxxxx> > > wrote: > > > > > Whooaah there... > > > > > > What is the status of this poll? I am all for moving from the > > > subjective > > > consensus model in which certain parties get a veto because their > > > opinions > > > are considered weightier than the rest of us. Objective measures of > > > consensus are good. But is this an official poll? What does it mean? > > > > > > But of course, as John K. pointed out, this is not actually an IETF > > > process. Only of course it is in every meaningful sense except > > > insofar as > > > IETF rules of the road apply. > > > > > > > > > Page numbers is not the hill I would choose to die on here. They > > > don't > > > work in HTML and the whole point of this process is that the TXT > > > documents > > > reflect very badly on the IETF as an organization. It spoke of an > > > organization that is stuck in the 1960s ranting on about how vinyl is > > > better than CD. > > > > > > There are serious issues with the new format. Not least the fact > > > that SVG > > > is not actually supported. The supported format is SVG/Tiny which is > > > an > > > obsolete format originally proposed back in the WAP days as a means > > > of > > > crippling the spec to fit the capabilities of the devices back > > > before Steve > > > Jobs showed us an iPhone for the first time. There are no tools that > > > produce SVG/Tiny, not even GOAT - I had to modify the source code to > > > comply. > > > > > > I don't mind retooling to support an improved specification. Having > > > to > > > retool to support an obsolete one is nonsense. > > > > > > > > > Anyway, how about as a compromise, authors can opt to suppress > > > generation > > > of the TXT version so that the page number issue doesn't come up at > > > all? > _______________________________________________ > rfc-interest mailing list > rfc-interest@xxxxxxxxxxxxxx > https://www.rfc-editor.org/mailman/listinfo/rfc-interest -- --- tte@xxxxxxxxx
