Re: [rfc-i] deprecating relref

Kent Watsen <kent+ietf@watsen.net> Mon, 26 April 2021 15:33 UTC

Return-Path: <rfc-interest-bounces@rfc-editor.org>
X-Original-To: ietfarch-rfc-interest-archive@ietfa.amsl.com
Delivered-To: ietfarch-rfc-interest-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830713A2566; Mon, 26 Apr 2021 08:33:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.75
X-Spam-Level:
X-Spam-Status: No, score=-4.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=amazonses.com
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 o9SQ83np5KSD; Mon, 26 Apr 2021 08:33:50 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3C0B3A2546; Mon, 26 Apr 2021 08:33:50 -0700 (PDT)
Received: from rfcpa.amsl.com (localhost [IPv6:::1]) by rfc-editor.org (Postfix) with ESMTP id 6C2E5F406F0; Mon, 26 Apr 2021 08:33:39 -0700 (PDT)
X-Original-To: rfc-interest@rfc-editor.org
Delivered-To: rfc-interest@rfc-editor.org
Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 0808EF406F0 for <rfc-interest@rfc-editor.org>; Mon, 26 Apr 2021 08:33:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at rfc-editor.org
Authentication-Results: rfcpa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_MMcIAiyM9g for <rfc-interest@rfc-editor.org>; Mon, 26 Apr 2021 08:33:34 -0700 (PDT)
Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) by rfc-editor.org (Postfix) with ESMTPS id 9B427F406DB for <rfc-interest@rfc-editor.org>; Mon, 26 Apr 2021 08:33:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1619451224; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=rbE7CGWLmrIEB94PfDP7dUkowIONp6VeGJX90XED7N8=; b=gOJsfJibg0LPYBBSs6SW9mRyzbhiOXdG4POffSxJD73qp0ySiOQxgF/IuIFb9xhY mDxfa8QBgjzDjj+/XWoLdbvN7tzckjFyNTDXSWgsSFooP7TjbCB6zGQ3cDHOdkf785H /U/9LuQpSsODrXPbUJOP5lWkcccIA2a3x0C660o0=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <010001790ed09edc-faa57af2-36be-4ab4-8b4e-7ee426d2e772-000000@email.amazonses.com>
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Mon, 26 Apr 2021 15:33:43 +0000
In-Reply-To: <b44e7c12-1b15-0615-1871-9dce7b891f08@mozilla.com>
To: Peter Saint-Andre <stpeter@mozilla.com>
References: <060157d4-68a0-9729-cf0e-9eaa38ce45d8@mozilla.com> <0100017900eba149-1ec61a85-0716-484f-9772-3938d37392e8-000000@email.amazonses.com> <b44e7c12-1b15-0615-1871-9dce7b891f08@mozilla.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2021.04.26-54.240.48.90
Subject: Re: [rfc-i] deprecating relref
X-BeenThere: rfc-interest@rfc-editor.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <rfc-interest.rfc-editor.org>
List-Unsubscribe: <https://www.rfc-editor.org/mailman/options/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <http://www.rfc-editor.org/pipermail/rfc-interest/>
List-Post: <mailto:rfc-interest@rfc-editor.org>
List-Help: <mailto:rfc-interest-request@rfc-editor.org?subject=help>
List-Subscribe: <https://www.rfc-editor.org/mailman/listinfo/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=subscribe>
Cc: RFC Interest <rfc-interest@rfc-editor.org>
Content-Type: multipart/mixed; boundary="===============7916032807096722652=="
Errors-To: rfc-interest-bounces@rfc-editor.org
Sender: rfc-interest <rfc-interest-bounces@rfc-editor.org>

No, especially if there’s a graceful migration, as I’d rather not have to update my 10+ I-Ds using <relref>  ;)

I think what I’m missing is that it seems the current <xref> definition has the ability to reference an anchor point in a document already, but maybe not, as the examples in RFC 7991 don’t speak to the case directly...

Assuming a document current has:

    <relref section=‘2.1.4.7' target='I-D.ietf-foobar’/>

    ["I-D.ietf-foobar" is a work-in-progress]


And that Section 2.1.4.7 is defined as:

    <section title=‘The “foo-grouping” Grouping' anchor=‘foo-grouping'>

Would this work, or planned to work?

    <xref target='I-D.ietf-foobar#foo-grouping'>  


PS: It would be an improvement to reference an “anchor”, so that relocations in a base document don’t require a manual update to other documents referencing it.

Thanks,
Kent


> On Apr 26, 2021, at 11:12 AM, Peter Saint-Andre <stpeter@mozilla.com> wrote:
> 
> Hi Kent,
> 
> If (as explained below) the unique attributes of relref were migrated to
> xref, would you still have a separate need for relref?
> 
> Peter
> 
> On 4/23/21 4:48 PM, Kent Watsen wrote:
>> I’m a drive-by tourist here and just noticing this thread, but I’ve been making extensive use of <relref> in my documents.  Enabling authors to link to the specific section in an RFC is very useful.   
>> 
>> Looking into <xref>, I’m guessing that linking to an “anchor” is better because it would automatically update if the linked-section moves, such as when the target document is a work-in-progress - yes?
>> 
>> Kent
>> 
>> 
>> 
>>> On Apr 8, 2021, at 8:20 PM, Peter Saint-Andre <stpeter@mozilla.com> wrote:
>>> 
>>> Hi all,
>>> 
>>> The RFC XML and Style Guide change management team [1] recently
>>> discussed the differences between xref and relref elements [2] and
>>> determined that (a) relref has not been used in source documents
>>> provided by authors and (b) if it had been used, the xml2rfc tool would
>>> have transformed relref to xref while adding any of the attributes
>>> defined in RFC 7991 for relref but not xref (sectionFormat, section,
>>> relative, derivedLink). Therefore our recommendation is to deprecate
>>> relref in 7991bis and likely add some or all of the relref attributes to
>>> xref.
>>> 
>>> Peter
>>> 
>>> [1]
>>> https://mailarchive.ietf.org/arch/msg/rfc-interest/_13Fne0Pxv233coED2BiRY_IJR4/
>>> 
>>> [2] https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/172
>>> 
>>> _______________________________________________
>>> rfc-interest mailing list
>>> rfc-interest@rfc-editor.org
>>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>> 
> _______________________________________________
> rfc-interest mailing list
> rfc-interest@rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest