[Tools-discuss] Re: Finding authors [was: sob@harvard.edu is not long for the world]

Jean Mahoney <jmahoney@amsl.com> Fri, 16 August 2024 21:35 UTC

Return-Path: <jmahoney@amsl.com>
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC4AC14CE29 for <tools-discuss@ietfa.amsl.com>; Fri, 16 Aug 2024 14:35:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Px-eqlgC4Dnr for <tools-discuss@ietfa.amsl.com>; Fri, 16 Aug 2024 14:35:53 -0700 (PDT)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 923C5C14CE22 for <tools-discuss@ietf.org>; Fri, 16 Aug 2024 14:35:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 64166424B42B; Fri, 16 Aug 2024 14:35:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysi5WmrG6y5N; Fri, 16 Aug 2024 14:35:53 -0700 (PDT)
Received: from [192.168.1.203] (unknown [47.186.48.51]) by c8a.amsl.com (Postfix) with ESMTPSA id 120BA424B42A; Fri, 16 Aug 2024 14:35:53 -0700 (PDT)
Message-ID: <62c32387-59f0-49b9-ade0-6bc3a3944925@amsl.com>
Date: Fri, 16 Aug 2024 16:35:52 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Toerless Eckert <tte@cs.fau.de>
References: <9EAE17CA-418D-48AB-9BAB-5E8F2ABF6D88@sobco.com> <a045de6c-8f09-4616-8e3a-032cab31569f@cs.tcd.ie> <8E5ECB74-746B-47DC-BC50-70CEEF3B9633@strayalpha.com> <A45F9A94-AA41-45B2-8457-0F52D0ADEAF4@terrym.net> <a27a369e-b484-4c46-88b3-af2d712b7b10@gmail.com> <CAKr6gn0frE0YqpC2KtKS90H1Cvs_AmZzzQzzYAj4oW+d_HOd_A@mail.gmail.com> <edcfd4dd-fab7-48c2-9905-336d33c763d8@gmail.com> <Zr7wDuirMvH4j6qS@faui48e.informatik.uni-erlangen.de> <bd5d3268-3dcb-4681-a1e8-0e5aa0406545@gmail.com>
Content-Language: en-US
From: Jean Mahoney <jmahoney@amsl.com>
In-Reply-To: <bd5d3268-3dcb-4681-a1e8-0e5aa0406545@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Message-ID-Hash: EHH65LFDUUTPVRVMNGPXT257M4GRQFM6
X-Message-ID-Hash: EHH65LFDUUTPVRVMNGPXT257M4GRQFM6
X-MailFrom: jmahoney@amsl.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tools-discuss.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: George Michaelson <ggm@algebras.org>, Terry Manderson <terry@terrym.net>, Tools Team Discussion <tools-discuss@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Tools-discuss] Re: Finding authors [was: sob@harvard.edu is not long for the world]
List-Id: IETF Tools Discussion <tools-discuss.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-discuss/uQSV7MkCjIZSChEuWmxYIGkYa9I>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-discuss>
List-Help: <mailto:tools-discuss-request@ietf.org?subject=help>
List-Owner: <mailto:tools-discuss-owner@ietf.org>
List-Post: <mailto:tools-discuss@ietf.org>
List-Subscribe: <mailto:tools-discuss-join@ietf.org>
List-Unsubscribe: <mailto:tools-discuss-leave@ietf.org>

Hi all,

On 8/16/24 3:47 PM, Brian E Carpenter wrote:
> On 16-Aug-24 18:22, Toerless Eckert wrote:
>> I would love a rendering option of RFC which has updated metadata.
> 
> I agree, but that's the main reason for always citing an RFC via its 
> info page, e.g.
> https://www.rfc-editor.org/info/rfc6826
> There you learn that the RFC has been updated by another, and that it 
> has no confirmed errata.
> 
> As far as I can see, showing current email addresses (when known) is "a 
> small matter of programming." But of course they are not in the metadata 
> today.

[JM] The rfc-editor.org database does contain author email addresses, 
and the database sends notifications to authors when errata reports are 
submitted for their RFCs [1]. We can update email information upon 
request from the authors. This is currently a manual process. The RPC 
will be leveraging the author contact info found in datatracker in the 
future.

> 
> However, this line is presumably generated from the metadata:
> 
>>> Discuss this RFC: Send questions or comments to the mailing list 
>>> mpls@ietf.org

[JM] Yes, this is metadata, and we can update this information (also a 
manual process) as working groups change. For instance, RFC 3261 came 
out of the sip working group, which is now closed, so readers are 
directed to contact the sipcore working group [2].

Best regards,
Jean

[1] https://datatracker.ietf.org/doc/draft-rpc-errata-process/
[2] https://www.rfc-editor.org/info/rfc3261

> 
>     Brian
> 
> 
>> Such as current standard track status - and maybe current email
>> addresses of authors/contributors - although i am aware of an important
>> use-case for this. Maybe it is not a bad thing if you need to apply some
>> IETF knowledge to do the mapping. Old authors may like their peace an 
>> quiet ;-)
>>
>> Doing the mapping today is not really be that big a problem
>> for somebody who loves to do web programming to do this. But agreeing
>> on some standard add-on header with such "current" metadata would be nice
>> anyhow.
>>
>> The mapping from old-email to new email is already publically possible
>> with some heuristics:
>>
>> https://datatracker.ietf.org/person/<old-email>
>>
>> Gets you the persons datatracker page
>> if <old-email> was once captured by datatracker due to role or draft/rfc.
>>
>> Then you need to apply the heuristic to find one or more "current" email
>> from the role section or latest draft/rfc section on that page. Aka: what
>> i guess we're all doing manually anyhow when we need to find such an 
>> email.
>>
>> Of course that's just a heuristic.
>>
>> Most simple way to allow datatracker persons to post an "authoritative"
>> personal email on datatracker would be to add a tag "personal_email"
>> to the list of tags for "Additional person resources".
>>
>> Cheers
>>      Toerless
>>
>> On Thu, Aug 15, 2024 at 05:12:52PM +1200, Brian E Carpenter wrote:
>>> [Attempting to switch lists...]
>>>
>>> The topic is finding current addresses for authors of older RFCs.
>>>
>>> George,
>>>
>>> We cannot change the RFC text; that's a rule. So the solution has to 
>>> be external to the RFC itself. (See my comments in line below.)
>>>
>>> The datatracker already has the information needed. Taking myself as 
>>> an example, it knows that brian@dxcoms.cern.ch, 
>>> brian@hursley.ibm.com, brian@icair.org, brc@zurich.ibm.com, and 
>>> brian.e.carpenter@gmail.com are all the same person. Also, my 
>>> datatracker profile knows which address is currently primary.
>>>
>>> Therefore, writing a function that delivers current addresses for the 
>>> authors of RFC N, in cases where the tracker has this information, is 
>>> entirely possible, for people who know how to access the 
>>> datatracker's database. authors_of_rfc(2119) would return 
>>> ("sob@sobco.com") authors_of_rfc(1671) would return 
>>> ("brian.e.carpenter@gmail.com")
>>>
>>> So we could have an API and a web tool for this.
>>>
>>> Whether the effort for this is justified is for discussion.
>>>
>>> On 15-Aug-24 15:19, George Michaelson wrote:
>>>> I think I must misunderstand what you're trying to say, because this
>>>> reads as the other half, and does not address what  I think Terry
>>>> proposed: The embedded values in the RFCs are held to be immutable,
>>>> but these contact strings are anything but immutable, as we all know.
>>>> user@host is not a constant which alters the normative force or
>>>> semantics of a document, its a reference to the authors.
>>>
>>> It doesn't matter. Published RFCs are immutable. This can only be 
>>> handled
>>> as metadata.
>>>
>>>>
>>>> If the author reference in an RFC was abstracted to a DOI or an ORCID
>>>> or similar, noting Phils comments to the need to make it trustable
>>>> through cryptography, then the document suffers no loss of
>>>> information, when the user@host has to change. That crytographic
>>>> management is btw completely outside the RFC process. It manages a
>>>> value expressed into an RFC.
>>>>
>>>> An abstracted contact ID could be external, or could be internal. I
>>>> prefer internal, managed inside IETF process, and amenable to an XML
>>>> definition so it can be tokenised properly in the web display and
>>>> datatracker.
>>>
>>> s/IETF process/RFC Editor process/
>>>
>>>>
>>>> Ie its not "listing the emails" its tying the identity information of
>>>> the author to something outside of the RFC which can itself remain
>>>> substantively immutable, when emails change.
>>>
>>> Certainly one could imagine this added to the metadata for an RFC,
>>> but that would be a complicated discussion over in RFC Editor land.
>>>
>>> Regards
>>>     Brian
>>>
>>>>
>>>> G
>>>>
>>>> On Thu, Aug 15, 2024 at 11:47 AM Brian E Carpenter
>>>> <brian.e.carpenter@gmail.com> wrote:
>>>>>
>>>>> Terry,
>>>>>
>>>>> We effectively have that already. Try these:
>>>>>
>>>>> https://datatracker.ietf.org/person/sob@harvard.edu
>>>>> https://datatracker.ietf.org/person/terry@terrym.net
>>>>> https://datatracker.ietf.org/person/brian@dxcoms.cern.ch
>>>>>
>>>>> The only issue I see is that if you have no formal role (lucky 
>>>>> me!), no current email address is listed. That could be an option 
>>>>> in the user's profile, or "author" could be added as a new role. 
>>>>> (If you like that, we could discuss it at tools-discuss@ietf.org)
>>>>>
>>>>> Regards
>>>>>       Brian Carpenter
>>>>>
>>>>> On 15-Aug-24 11:46, Terry Manderson wrote:
>>>>>>
>>>>>>
>>>>>>> On 15 Aug 2024, at 7:54 AM, touch@strayalpha.com wrote:
>>>>>>>
>>>>>>> Although I appreciate the impact this has to our RFCs, we all 
>>>>>>> experience this (touch@isi.edu is no more as well), though 
>>>>>>> perhaps not to the same degree.
>>>>>>>
>>>>>>> I’ll step in here to defend Harvard’s decision; having an email 
>>>>>>> available to someone who no longer holds an official position is 
>>>>>>> a significant legal risk.
>>>>>>>
>>>>>>> Emails, URLs, and even RFC numbers change (remember back when TCP 
>>>>>>> was “always” RFC793?). Search engines mitigate this problem, as 
>>>>>>> would (preferably) a bounce message from Harvard providing the 
>>>>>>> next known email, at least for a while.
>>>>>>>
>>>>>>> Joe
>>>>>>>
>>>>>>
>>>>>> I'm looking at this from the impact to the RFCs and the link 
>>>>>> between RFC authors and other inquisitive minds. Especially while 
>>>>>> the author is still interested in responding to email questions.
>>>>>>
>>>>>> I wonder if a level of abstraction can be created through an 
>>>>>> "author profile" that ties together all past author's address 
>>>>>> blocks and can provide the "latest known" address.
>>>>>>
>>>>>> Just a thought.
>>>>>>
>>>>>> Cheers,
>>>>>> Terry
>>
> -----------------------------------------------
> Tools-discuss mailing list -- tools-discuss@ietf.org
> To unsubscribe send an email to tools-discuss-leave@ietf.org
> https://mailarchive.ietf.org/arch/browse/tools-discuss/