Re: [Xml-sg-cmt] Fwd: docName - Re: Fwd: [django-project] Weird Internal Metadata error in I-D HTML

Robert Sparks <rjsparks@nostrum.com> Sat, 04 September 2021 17:22 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: xml-sg-cmt@ietfa.amsl.com
Delivered-To: xml-sg-cmt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8B63A1DB1 for <xml-sg-cmt@ietfa.amsl.com>; Sat, 4 Sep 2021 10:22:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.079
X-Spam-Level:
X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 qOfn-y87xWP8 for <xml-sg-cmt@ietfa.amsl.com>; Sat, 4 Sep 2021 10:22:17 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A476A3A1DB0 for <xml-sg-cmt@ietf.org>; Sat, 4 Sep 2021 10:22:15 -0700 (PDT)
Received: from unformal.localdomain ([47.186.34.206]) (authenticated bits=0) by nostrum.com (8.17.1/8.16.1) with ESMTPSA id 184HMB3x015545 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 4 Sep 2021 12:22:12 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1630776133; bh=IzQ7Ddx1MK3suVE9n3CJNDIMSGO3F10cdlfPqwLBVZg=; h=Subject:To:References:From:Date:In-Reply-To; b=puXf6z1Mq6YI6IF+Ws9hiTmzp5oz+JK9PXhbCWtbgxHQsTqQY5OJouX67T1YZEPG8 0zAQzu4V2YAZAT5EFAo33dobUPG5klh8r+tK1j8ZggZOzEx+4SwbtPrYliADLk/O+d 8Os8Kj2jfT9ZSxu9b2j2LOlrizSCRO6tA5W47Ydc=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.34.206] claimed to be unformal.localdomain
To: xml-sg-cmt@ietf.org, Kesara Rathnayake <kesara@staff.ietf.org>
References: <06C35681-F5E3-473F-BAF6-2ABF82A6DC8B@amsl.com> <728E07A7-EEB6-41A1-BA10-2E397F4FDB1F@amsl.com>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <14d0326c-d8d0-0a3c-d30a-7917dba79efe@nostrum.com>
Date: Sat, 04 Sep 2021 12:22:06 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <728E07A7-EEB6-41A1-BA10-2E397F4FDB1F@amsl.com>
Content-Type: multipart/alternative; boundary="------------B56B17370F5611516D965A5B"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml-sg-cmt/YhNZJmyn3x_hxheL3pXC5M0VEwA>
Subject: Re: [Xml-sg-cmt] Fwd: docName - Re: Fwd: [django-project] Weird Internal Metadata error in I-D HTML
X-BeenThere: xml-sg-cmt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Working list for the xml and style guide change management team <xml-sg-cmt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml-sg-cmt>, <mailto:xml-sg-cmt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml-sg-cmt/>
List-Post: <mailto:xml-sg-cmt@ietf.org>
List-Help: <mailto:xml-sg-cmt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml-sg-cmt>, <mailto:xml-sg-cmt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Sep 2021 17:22:23 -0000

Sandy and Alice have seen this before - repeating it here to help with 
the conversation:

Ultimately we're going to have to document the continued use of docname 
in v3 (vs the current 779* docs that say it is deprecated and unused), 
or put this information somewhere that's semantically well-labeled and 
stop using the older docname attribute.

Other people may be able to more quickly explain why continuing to use 
docname in the case Henrik points to below is the better choice - I 
suspect its so that we can treat older references and newer ones the same?

Kesara - could you code-mine and see what the code currently wants and 
does with any version in docname for a v3 document?

RjS

On 9/3/21 5:11 PM, Sandy Ginoza wrote:
> Hi All,
>
> Forwarding this mail in hopes we can discuss docName a bit.
>
> Have a great weekend!
>
> Thanks!
> Sandy
>
>> Begin forwarded message:
>>
>> *From: *Sandy Ginoza <sginoza@amsl.com <mailto:sginoza@amsl.com>>
>> *Subject: **Re: docName - Re: Fwd: [django-project] Weird Internal 
>> Metadata error in I-D HTML*
>> *Date: *September 1, 2021 at 6:28:06 PM PDT
>> *To: *Alice Russo <arusso@amsl.com <mailto:arusso@amsl.com>>
>> *Cc: *Robert Sparks <rjsparks@nostrum.com 
>> <mailto:rjsparks@nostrum.com>>, Jean Mahoney <jmahoney@amsl.com 
>> <mailto:jmahoney@amsl.com>>
>>
>> Hi Robert,
>>
>> Regarding docname=“draft”, is inclusion of the version number 
>> required?  We’ve started running into the question of whether the 
>> version number should match a) the approved version, b) the current 
>> datatracker version (versions submitted after the document enters the 
>> queue), or c) the version approved by the ADs (could be a or b).
>>
>> Please let me know if you prefer I send this to the full xml-sg-cmt.
>>
>> Thanks!
>> Sandy
>>
>>
>>> On Aug 24, 2021, at 9:57 AM, Alice Russo <arusso@amsl.com 
>>> <mailto:arusso@amsl.com>> wrote:
>>>
>>> Hi Robert,
>>>
>>> You wrote:
>>>> I note (and I am actually surprised - I've forgotten how we got 
>>>> here) that we are _publishing_ RFCs with docName not matching 
>>>> seriesInfo value, and I bet this will cause confusion in the future.
>>>
>>> I'm forwarding the mail below from 2019 for background re: setting 
>>> docName to the draft string.  (As a result of the exchange below, 
>>> grep shows "docName=\"draft" in the 439 RFCs published in the v3 era.)
>>>
>>> Alice
>>>
>>>> Begin forwarded message:
>>>>
>>>> From: Henrik Levkowetz <henrik@levkowetz.com 
>>>> <mailto:henrik@levkowetz.com>>
>>>> Subject: Re: docName - was: Re: [v3] "é" (acute/aigu accent) no 
>>>> longer accepted
>>>> Date: September 16, 2019 at 12:18:13 PM PDT
>>>> To: Alice Russo <arusso@amsl.com <mailto:arusso@amsl.com>>
>>>> Cc: RFC Editor <rfc-editor@rfc-editor.org 
>>>> <mailto:rfc-editor@rfc-editor.org>>
>>>>
>>>> Hi Alice,
>>>>
>>>> On 2019-09-16 20:56, Alice Russo wrote:
>>>>> Hi Henrik,
>>>>>
>>>>> On the topic of docName:
>>>>>
>>>>> Re:
>>>>>> On Sep 16, 2019, at 11:36 AM, Henrik Levkowetz 
>>>>>> <henrik@levkowetz.com <mailto:henrik@levkowetz.com>> wrote:
>>>>>>
>>>>>>> draft-ietf-mptcp-rfc6824bis-18.xml(4): Warning: Expected a 
>>>>>>> <link> with rel="prev" providing the datatracker url for the 
>>>>>>> origin draft, or alternatively a "docName" attribute on <rfc> 
>>>>>>> from which to construct such a <link> element.
>>>>>>
>>>>>> You should fix this one, too.  Provide docName="..." with the 
>>>>>> draft name
>>>>>> from which the RFC comes.
>>>>>
>>>>> OK; we can update our internal documentation accordingly.
>>>>>
>>>>> I must have misunderstood from a past thread bc I thought we weren't
>>>>> setting docName at all. If we set it to the draft string, it creates
>>>>> this in the HTML output:
>>>>> <link href="https://datatracker.ietf.org/doc/draft-foo-09 
>>>>> <https://datatracker.ietf.org/doc/draft-foo-09>" rel="prev">
>>>>
>>>> That's right, that's the intention.
>>>>
>>>>> Is the following accurate?
>>>>> - This link element is not displayed in the browser-rendered HTML
>>>>> (only viewable in the HTML source).
>>>>
>>>> Yes.
>>>>
>>>>> - This link element exists because it is specified in
>>>>> <https://tools.ietf.org/html/rfc7998#section-5.6.3 
>>>>> <https://tools.ietf.org/html/rfc7998#section-5.6.3>>.
>>>>
>>>> Yes.
>>>>
>>>>> Is there more understanding we should have?  From the RPC
>>>>> perspective, it seems odd that the docName is set to the drafts
>>>>> string (i.e., the RFC is no longer draft-foo-09).
>>>>
>>>> Yes, I can see that.  The attribute name is not appropriate for the use
>>>> it has when the document becomes an RFC.  "draftName" or 
>>>> "draft-name" would
>>>> have been better.  But docName has been with us since Marshall 
>>>> Rose's first
>>>> implementation of xml2rfc, I think, so I doubt we can fix that.
>>>>
>>>>
>>>> Best regards,
>>>>
>>>> Henrik
>>>>
>>>>>
>>>>> Thanks,
>>>>> Alice
>>>>>
>>>>> Background from May thread:
>>>>>
>>>>> On May 10, 2019, you wrote:
>>>>>> No, the docName should not change to a number; the docName is 
>>>>>> used to add
>>>>>> metadata about the draft from which an RFC is derived when 
>>>>>> writing a v3
>>>>>> RFC in html format, and to insert the draft name when writing 
>>>>>> draft output.
>>>>>
>>>>> And then later the same day:
>>>>>>>> Warning: Expected a <link> with rel='prev' providing the 
>>>>>>>> datatracker url for the origin draft.
>>>>>>>
>>>>>>> The v2v3 converter inserts a <link> with rel='prev' if docName 
>>>>>>> is given;
>>>>>>> for v3 xml you should set that.  I think, however, that this 
>>>>>>> warning should
>>>>>>> more correctly be a note or comment.
>>>>>>
>>>>>> No, I'm wrong.  It should be at least a warning, possibly an 
>>>>>> error.  This is
>>>>>> covered in https://tools.ietf.org/html/rfc7998#section-5.6.3 
>>>>>> <https://tools.ietf.org/html/rfc7998#section-5.6.3> .  This is
>>>>>> emitted only in RFC production mode.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>