Subject: [rfc-i] what metric replaces page-count?

From: Michael Richardson <[email-masked]>
Date: Sun, 11 Apr 2021 16:11:00 -0400

If RFCs won't be paginated, how will I know approximately how long a document is?
Our datatracker says the number of pages in the date column.
kilo-word-count?

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 11 Apr 2021 22:12:59 +0200

On 2021-04-11, at 22:11, Michael Richardson <[email-masked]> wrote:
> Signed PGP part

Use the page count of the PDF then.
(This is less stable over time, as the rendering may change, but probably as useful as the existing page count.)

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Apr 2021 08:50:05 +1200

> (This is less stable over time, as the rendering may change, but probably as useful as the existing page count.)

Yes, my guess is that PDF will become the go-to version for people (such as lawyers and judges) who want page references for new-format RFCs.

    Brian

---

From: Nico Williams <[email-masked]>
Date: Sun, 11 Apr 2021 19:25:19 -0500

On Mon, Apr 12, 2021 at 08:50:05AM +1200, Brian E Carpenter wrote:
> Yes, my guess is that PDF will become the go-to version for people
> (such as lawyers and judges) who want page references for new-format
> RFCs.

So.. pagination forever then?

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 12 Apr 2021 18:46:45 +0200

On 2021-04-12, at 16:55, Richard Barnes <[email-masked]> wrote:
> 
> Lawyers and judges are happy to cite by section.  Time to move on from tired, inaccurate metaphors.

Yes, but assessing the size of a document (which is what this thread is about) by section count doesn’t work so well.  The page count of the PDF is the only ready-made metric we have today.  Putting in another metric (e.g., word count(*)) might be helpful.

Grüße, Carsten

(*) ...where that often doesn’t actually count words but characters and then divides that count by 6 (or 5!), which better copes with different complexity grades.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 12 Apr 2021 13:12:16 -0400

On Mon, Apr 12, 2021 at 12:46 PM Carsten Bormann <[email-masked]> wrote:

> Yes, but assessing the size of a document (which is what this thread is
> about) by section count doesn’t work so well.  The page count of the PDF is
> the only ready-made metric we have today.  Putting in another metric (e.g.,
> word count(*)) might be helpful.
>

I must admit that Richard's mail really annoyed me -- I started writing a
replay, but then realized that it was ranty and not likely to change
anyone's views.
I've now calmed down somewhat, and so will try and explain.

The tone of "Time to move on from tired, inaccurate metaphors" smacks of
stating a position as fact, and that disagreement means that you are stuck
in the dark ages / ab absurdo.

I've been using page count as a metric for tracking the amount of document
review I've performed, how much I'm reading, etc. Yes, it's not a perfect
metric, but it's one I've been using and is "good enough" for letting me
know roughly how much I've reviewed this month versus last month, how much
I've read in total, etc. I've got a system, and it works *for me*.
I really disliked the tone of "Time to move on from..." - I understand that
Richard doesn't happen like this metric - but I'm disappointed that,
increasingly, if you don't agree with someone in the IETF, the tone pivots
to implying that there is something wrong with them, or that they are
stupid, or similar...

W

>
> Grüße, Carsten
>
> (*) ...where that often doesn’t actually count words but characters and
> then divides that count by 6 (or 5!), which better copes with different
> complexity grades.
>
> ___________________________________________________________
> Tools-discuss mailing list - [email-masked]
> This list is for discussion, not for action requests or bug reports.
> * Report datatracker and mailarchive bugs to: [email-masked]
> * Report tools.ietf.org bugs to: [email-masked]
> * Report all other bugs or issues to: [email-masked]
> List info (including how to Unsubscribe):
> https://www.ietf.org/mailman/listinfo/tools-discuss
>

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 12 Apr 2021 10:32:45 -0700

> to implying that there is something wrong with them, or that they are

A strong +1 to what Warren said. As some of you might remember, I 
opposed the creation of official PDFs because their use should be 
discouraged in normal practice. I still fee that way. However, there's a 
wide gap between "you would likely be better served by the new shiny if 
you gave it a chance" and "you're wrong for wanting the old thing".

I still hope that the v3bis work spends no time on improving the PDF 
format because it hinders the more valuable use cases, but I don't want 
them to deprecate it now that the costs have been sunk and there are a 
few people who find it useful.

--Paul Hoffman

---

From: Richard Barnes <[email-masked]>
Date: Mon, 12 Apr 2021 10:55:46 -0400

Lawyers and judges are happy to cite by section.  Time to move on from
tired, inaccurate metaphors.

https://guides.ll.georgetown.edu/bluebook/citing-other

On Sun, Apr 11, 2021 at 4:50 PM Brian E Carpenter <
[email-masked]> wrote:

> > (This is less stable over time, as the rendering may change, but
> probably as useful as the existing page count.)
>
> Yes, my guess is that PDF will become the go-to version for people (such
> as lawyers and judges) who want page references for new-format RFCs.
>
>     Brian
>

---

From: Ole Jacobsen <[email-masked]>
Date: Mon, 12 Apr 2021 13:07:09 -0700

And sections NEVER span more than a single page, do they now?

That would be "inaccurate" I guess.

Ole

> On Apr 12, 2021, at 07:55, Richard Barnes <[email-masked]> wrote:
> 

Ole J. Jacobsen
Editor and Publisher
The Internet Protocol Journal
Office: +1 415-550-9433
Cell:   +1 415-370-4628
Web: protocoljournal.org
E-mail: [email-masked]
E-mail: [email-masked]
Skype: organdemo

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Apr 2021 18:42:13 -0400

> in the dark ages / ab absurdo.

+1

    > to implying that there is something wrong with them, or that they are

This is really the origin of my question.
The IESG has used page-count as a metric.

It's interesting to look at documents in different WGs (or for different
protocols), and see how they vary in size.  How much is Protocol, and how
much is Security Consideration?

John Levine's "but IDs still have page count" helps me not at all when
comparing two RFCs.  It this a document I can read over a coffee break, or do
I need to lock-myself in the wifi-free tree-house all afternoon?

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Apr 2021 18:43:55 -0400

> And sections NEVER span more than a single page, do they now?

It's a good reason to err on the side having more section headers than fewer
ones.  For numbering points rather than "*" them.

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Apr 2021 18:09:14 -0500

> tired, inaccurate metaphors.

But Michael was not asking about citations.  He was asking for a
complexity metric.

Speaking of sections for citations _and_ metrics, the ITU-T x.68x and
x.69x series documents do a great job of breaking everything down into
many many teeny tiny sections, which makes it very easy to refer very
specifically to parts of their texts, and since they're all small,
counting them might be a useful metric.

I think it would be much harder for us to adopt that approach than
anything we might do regarding pagination, but I have to say that I like
many-tiny-sections, and it would be especially nice to have all MUSTs,
SHOULDs, and so on, referenceable by section number just by dint of
their containing sections being so small.

Many-tiny-sections is _mostly_ a matter of style, but in the ITU-T specs
I mentioned, only top-level sections and sub-sections have titles, with
sub-sub-sections having no title and the first paragraph on the same
line as the subsection number.  That may require xml2rfc support.  E.g.:

   8.   Basic encoding rules
   ...
   8.19 Encoding of an object identifier value

   8.19.1 The encoding of an object identifier value shall be primitive.

   8.19.2 The contents octets shall be an (ordered) list of encodings of
   subidentifiers (see 8.19.3 and 8.19.4) concatenated together.

   Each subidentifier ...

   8.19.3 The number of subidentifiers ...

where sections and sub-sections have titles, but sub-sub-sections do
not.

This is almost like having paragraph numbering as a sort of sub-section
numbering, except that you can see that's not quite the rule (e.g.,
x.690 section 8.19.2 has two paragraphs).  But I would be fine with that
too.

That said, x.68x and x.69x series documents not only have many tiny
sections, they are also paginated.

Unpopular idea: maybe we should revisit the no-pagination decision.

Nico

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Apr 2021 18:12:32 -0500

On Mon, Apr 12, 2021 at 01:12:16PM -0400, Warren Kumari wrote:
>                                   [...] - but I'm disappointed that,

Thanks for the reminder that this doesn't just happen on the general
list.  I wish we could stop arguing in this way.  If you catch me doing
it, please let me know.

Nico

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Apr 2021 18:14:49 -0500

On Mon, Apr 12, 2021 at 10:32:45AM -0700, Paul Hoffman wrote:
> A strong +1 to what Warren said. As some of you might remember, I opposed
> the creation of official PDFs because their use should be discouraged in
> normal practice. I still fee that way. However, there's a wide gap between
> "you would likely be better served by the new shiny if you gave it a chance"
> and "you're wrong for wanting the old thing".

Remind me why we're losing pagination?  It's mostly about the tooling,
right?

Feel free to do so off-list to avoid flame war potential.  I do accept
that we're losing pagination.

Nico

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 13 Apr 2021 09:06:28 +0900

I'm not sure why apparently nobody got this, but RFCs still have page 
counts. Here is a very recent example, (see
https://mailarchive.ietf.org/arch/msg/ietf-announce/GGb94E77Boes9UWUjunO3CIhH70)

         RFC 8997

         Title:      Deprecation of TLS 1.1 for
                     Email Submission and Access
         Author:     L. Velvindron,
                     S. Farrell
         Status:     Standards Track
         Stream:     IETF
         Date:       March 2021
         Mailbox:    [email-masked],
                     [email-masked]
         Pages:      6
         Updates:    RFC 8314

         I-D Tag:    draft-ietf-uta-tls-for-email-05.txt

         URL:        https://www.rfc-editor.org/info/rfc8997

         DOI:        10.17487/RFC8997

The information isn't available at 
https://www.rfc-editor.org/info/rfc8997, but it must be somewhere. I 
have no idea how it's calculated. It could be made available more 
widely. This would help people who measure reading effort in pages but 
would still inhibit citing by page.

> Yes, but assessing the size of a document (which is what this thread is about) by section count doesn’t work so well.  The page count of the PDF is the only ready-made metric we have today.  Puttin…

Another count is bytes. I seem to remember when RFC (or was in I-D) 
announcements came with byte counts. Checking, I found that up to RFC 
8649, there is a 'Character' count (see 
https://mailarchive.ietf.org/arch/msg/ietf-announce/B2v9FoL7UpnVS20fNmViiDwWfxU), 
but there isn't anymore starting with RFC 8650 
(https://mailarchive.ietf.org/arch/msg/ietf-announce/VVRlgHG5zAov4N6xSPLEDPziaOg). 
Such a count could be reintroduced if appropriately defined. It should 
probably only count net content characters, not gross count including 
markup.

> (*) ...where that often doesn’t actually count words but characters and then divides that count by 6 (or 5!), which better copes with different complexity grades.

Both on a personal level and/or on an institutional level, it may be 
possible to develop some estimates of characters per page or words per 
page, and so on.

Regards,   Martin.

---

From: tom petch <[email-masked]>
Date: Tue, 13 Apr 2021 12:33:30 +0100

> ones.  For numbering points rather than "*" them.

When this topic surfaced a few months ago I pointed to such as
draft-ietf-teas-yang-te
where there is a section of 52 pages and another of 58 pages.  The 
feedback I got suggested to me that those who designed this new, 
pageless system had no acquaintance with YANG or any such language in 
documents.  Perhaps we will have to create a YANG2.0 language to cater 
for our XML, pageless world!

Tom Petch

> .

---

From: Michael Richardson <[email-masked]>
Date: Tue, 13 Apr 2021 12:09:21 -0400

> But Michael was not asking about citations.  He was asking for a

Thank you.

    > 8.19.1 The encoding of an object identifier value shall be primitive.

I personally find this presentation ugly and very disruptive to reading.
If the size of the "8.19.1" could diminish such that it was significantly
smaller, than I'd be happy.  That might be a matter of some extra CSS.
(When CSS was invented, I was told we were supposed to be able to cascade
local CSS, but in practice, that has always been difficult)

    > x.690 section 8.19.2 has two paragraphs).  But I would be fine with that

So, in your view, the size metric would then be the number of sections.
{I do not support revisiting the decision}

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Apr 2021 11:26:38 -0500

> local CSS, but in practice, that has always been difficult)

Well, it is somewhat disruptive because the section numbering indents
the first paragraph of the untitled section.  But the net benefit of
this style is that it permits highly specific references, and as an
implementor I find that convenient.

> So, in your view, the size metric would then be the number of sections.

For documents written in this style, yes.  Generally, no.

It has been pointed out to me that "extra CSS" is all I need to get
visible paragraph numbering in HTML renderings.  A button to make them
visible would be a better UI.  (Writing CSS is not a UI.)

If we want to be able to use paragraph numbering as a short-hand
references, I think we'll want to a) standardize on reference form (when
not using URIs), like 1.2.3-4, b) have paragraph numbering be visible by
default, at least in txt and PDF renderings.  I suspect most would find
visible paragraph numbering disruptive to reading, so I won't bother
proposing that :)  The x.690 examples I gave are a bit less extreme than
numbering every paragraph, so maybe more acceptable?

Nico