Re: [Emailcore] Navigating 5321bis (and predecessors)

John C Klensin <john@jck.com> Sat, 09 January 2021 22:24 UTC

Return-Path: <john@jck.com>
X-Original-To: emailcore@ietfa.amsl.com
Delivered-To: emailcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C65E3A044A for <emailcore@ietfa.amsl.com>; Sat, 9 Jan 2021 14:24:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUPbXoTJULsf for <emailcore@ietfa.amsl.com>; Sat, 9 Jan 2021 14:24:12 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07E13A046B for <emailcore@ietf.org>; Sat, 9 Jan 2021 14:24:12 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john@jck.com>) id 1kyMeZ-0009u5-8J; Sat, 09 Jan 2021 17:24:11 -0500
Date: Sat, 09 Jan 2021 17:24:04 -0500
From: John C Klensin <john@jck.com>
To: Alessandro Vesely <vesely@tana.it>, emailcore@ietf.org
Message-ID: <306A848BA9E6BE7CC38465E3@PSB>
In-Reply-To: <5f8f7894-b736-1f15-2dd4-865f68d6702d@tana.it>
References: <8034D30CAC474E52B15C1AC4@PSB> <5f8f7894-b736-1f15-2dd4-865f68d6702d@tana.it>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/emailcore/ffp2I5K-uAJIY5k1rFrYm4oLmTM>
Subject: Re: [Emailcore] Navigating 5321bis (and predecessors)
X-BeenThere: emailcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EMAILCORE proposed working group list <emailcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emailcore>, <mailto:emailcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emailcore/>
List-Post: <mailto:emailcore@ietf.org>
List-Help: <mailto:emailcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emailcore>, <mailto:emailcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Jan 2021 22:24:14 -0000


--On Thursday, January 7, 2021 10:25 +0100 Alessandro Vesely
<vesely@tana.it> wrote:

>> (2) Are there ways that we can mitigate the problems with
>> finding things. [...]  Would that be worth doing in terms of
>> finding information or is the table of contents sufficient?
>> Other ideas?
> 
> I think an index is useless nowadays, since page numbers are
> not a univocal reference anymore (they only appear in PDFs and
> are presumably going to depend on paper formats.)

I hope it is sorted out quickly --certainly before 5321bis is
ready-- but the xml2rfc vocabulary defines index ("<iref>")
elements which presumably means it is someone's problem (not
ours) to implement them in a way that is sensible for all
relevant output formats.  My personal opinion is that will mean
index entries have to end up targeting section numbers, not page
numbers, but I wait to see what others come up with.   However,
unless there is a proposal and community consensus to declare
that markup element useless and/or obsolete, I think we get to
assume that they will work in some meaningful way.

> Rather, I'd insert [See also <xref>] notes wherever
> appropriate.

As I think I mentioned in an earlier note, that is already
underway.  I welcome pointers to additional places where such
cross-references would be helpful.

best,
   john