Re: [xml2rfc] xml2rfc.tools.ietf.org::xml2rfc.bibxml/bibxml3

Henrik Levkowetz <henrik@levkowetz.com> Tue, 26 November 2019 21:12 UTC

Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1748D120B49 for <xml2rfc@ietfa.amsl.com>; Tue, 26 Nov 2019 13:12:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 SKAy_fXF6GZQ for <xml2rfc@ietfa.amsl.com>; Tue, 26 Nov 2019 13:12:10 -0800 (PST)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01391120B1C for <xml2rfc@ietf.org>; Tue, 26 Nov 2019 13:12:10 -0800 (PST)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:57652 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <henrik@levkowetz.com>) id 1iZi7z-0003ZI-PC; Tue, 26 Nov 2019 13:12:09 -0800
To: Sandy Ginoza <sginoza@amsl.com>
References: <m2k18qepu2.wl-randy@psg.com> <ebaa8b50-cf02-35f8-ba07-7770b60ecfd8@levkowetz.com> <2D13379B-3242-494D-A630-75D45F055E7A@tzi.org> <2787aed2-9d9d-b865-46fe-80d1b4d3c75b@levkowetz.com> <4ADDECD7-34B2-4F5E-8804-264F1390564E@att.com> <63F8C87D-F285-4A65-859E-CD2835D534BA@tzi.org> <41f3858e-9788-b238-6b7b-4f129c7d1012@levkowetz.com> <3DEA06EF-D486-4B85-94F5-CEFD5B8B9382@amsl.com> <d71863ec-f83e-85e1-dd1e-9f5da0d4d487@levkowetz.com> <E9679DA2-13FF-4AF7-9610-B55778715686@amsl.com>
Cc: Carsten Bormann <cabo@tzi.org>, "HANSEN, TONY L" <tony@att.com>, XML2RFC Interest Group <xml2rfc@ietf.org>
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <aa37451d-956e-ff14-734f-f95b7df7b172@levkowetz.com>
Date: Tue, 26 Nov 2019 22:11:59 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <E9679DA2-13FF-4AF7-9610-B55778715686@amsl.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="mU39C30JrfNAal8K7hQBrCajkV1CufeX3"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, tony@att.com, cabo@tzi.org, sginoza@amsl.com
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/F2HKgWq6qZSoU5RTpoS-qhQ-t3w>
Subject: Re: [xml2rfc] xml2rfc.tools.ietf.org::xml2rfc.bibxml/bibxml3
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Nov 2019 21:12:15 -0000

Hi Sandy,

On 2019-11-26 21:50, Sandy Ginoza wrote:
> Hi Henrik,
> 
> Ahh, thanks!  Apologies for assuming the string would still start
> with "reference.I-D”.  I’m happy to be rid of that construction, but
> it seems like a good idea to continue to accept "reference.I-D” since
> that is what appears in the already published v3 RFCs.

Indeed.

> I retested — the only unexpected difference is the appearance of
> Jordi’s name in the references. See
> 
> https://www.rfc-editor.org/v3test/rfc8683.xml 
> https://www.rfc-editor.org/v3test/rfc8683-rfcdiff.html
> 
> Looking at this now, I question whether showing J. Palet is correct,
> but that is how his name has appeared in the references in the past.

I believe the correct surname for Jordi is 'Palet Martinez'.  If one is
to omit one, omitting the maternal surname ('Martinez') is in my 
understanding (usually) the correct thing to do for Spanish surnames, so
past usage seems acceptable.

I think we need to refine the name handling in the datatracker even more
to deal correctly with author names.  With input in the form of xml
submissions, we will have better incoming data than before.


Best regards,

	Henrik


> 
> Thanks,
> Sandy 
> 
>> On Nov 26, 2019, at 12:31 PM, Henrik Levkowetz <henrik@levkowetz.com> wrote:
>> 
>> Hi Sandy,
>> 
>> On 2019-11-26 21:07, Sandy Ginoza wrote:
>>> Hi Henrik
>>> 
>>> Thanks for your quick work on this.  
>>> 
>>> Just fyi that I tested this — the reference entry matches output from
>>> entries pointing to https://xml2rfc.ietf.org/public/rfc/bibxml3/, but
>>> I don’t think it’s solved the issue regarding having references for
>>> the most recent versions of the I-Ds. For example, when I use the
>>> following:
>>> 
>>> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.palet-v6ops-464xlat-opt-cdn-caches.xml"/>
>> 
>> Umm.  Yes, that's not the right form.  You're probably getting an old copy
>> from cache.  The form available currently (I'm changing that to accept the
>> form you used for the next release, based in part on your experience) is
>> this:
>> 
>> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-palet-v6ops-464xlat-opt-cdn-caches.xml"/>
>> 
>>> I get a ref for -03, even though the datatracker shows draft-palet-v6ops-464xlat-opt-cdn-caches-04.
>> 
>> ... which (the correct form above) has -04 content.
>> 
>>> I also tried using the version number
>>> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.palet-v6ops-464xlat-opt-cdn-caches-04.xml"/>
>>> 
>>> but I got the following error:
>>> Error: Unable to resolve external request: "https://datatracker.ietf.org/doc/bibxml3/reference.I-D.palet-v6ops-464xlat-opt-cdn-caches-04.xml"
>>> Error: XInclude processing failed: could not load https://datatracker.ietf.org/doc/bibxml3/reference.I-D.palet-v6ops-464xlat-opt-cdn-caches-04.xml, and no fallback was found, line 1597
>>> Unable to complete processing rfc8683.xml
>> 
>> Yes, same problem -- you're using
>> 'reference.I-D.palet-v6ops-464xlat-opt-cdn-caches-04.xml' as part of the
>> URL, instead of 'draft-palet-v6ops-464xlat-opt-cdn-caches-04.xml'.
>> 
>> 
>> Best regards,
>> 
>> 	Henrik
>> 
>>> Thanks,
>>> Sandy 
>>> 
>>> 
>>> 
>>>> On Nov 9, 2019, at 7:40 AM, Henrik Levkowetz <henrik@levkowetz.com> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> On 2019-11-07 06:53, Carsten Bormann wrote:
>>>>> On Nov 7, 2019, at 04:56, HANSEN, TONY L <tony@att.com> wrote:
>>>>>> 
>>>>>> Yeah, I started writing a replacements a few times too. I think the proper mechanism is through a Django template.
>>>>> 
>>>>> Probably, as long as you prepend a cache.
>>>>> The last thing we need is longer access times for the bibxml fetches…
>>>> 
>>>> My trial implementation of bibxml3 entries generated on-the-fly from the
>>>> datatracker database is now deployed.
>>>> 
>>>> I'd appreciate people trying it out.
>>>> 
>>>> The URLs are of the form
>>>> 
>>>> https://datatracker.ietf.org/doc/bibxml3/<DRAFTNAME>.xml
>>>> and
>>>> https://datatracker.ietf.org/doc/bibxml3/<DRAFTNAME>-<REV>.xml
>>>> 
>>>> 
>>>> Best regards,
>>>> 
>>>> 	Henrik
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> xml2rfc mailing list
>>>> xml2rfc@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/xml2rfc
>>> 
>>> 
>> 
> 
>