Subject: [Xml-sg-cmt] Use of Reference elements in bibxml

From: Robert Sparks <[email-masked]>
Date: Fri, 4 Feb 2022 08:30:47 -0600

Working through the new bibxml service, I've been reminded that the 
datatracker is currently generating bibxml-ids with a deprecated element:

<?xml version="1.0" encoding="UTF-8"?>
<reference anchor="I-D.sparks-sipcore-multiple-reasons">
    <front>
       <title>Multiple SIP Reason Header Field Values</title>
       <author fullname="Robert Sparks">
      </author>
       <date month="November" day="12" year="2021" />
       <abstract>
      <t>   The SIP Reason Header Field as defined in RFC 3326 allows 
only one
    Reason value per protocol value.  Practice shows it is useful to
    allow multiple values with the same protocol value.  This update to
    RFC 3326 allows multiple values for an indicated registered protocol
    when that protocol defines what the presence of multiple values
    means.

      </t>
       </abstract>
    </front>
    <seriesInfo name="Internet-Draft" 
value="draft-sparks-sipcore-multiple-reasons-00" />
    <format type="TXT" 
target="https://www.ietf.org/archive/id/draft-sparks-sipcore-multiple-reasons-00.txt" 
/>
</reference>

In particular at <format>.

The new service plans to instead emit.

<reference 
target="https://www.ietf.org/archive/id/draft-sparks-sipcore-multiple-reasons-00.txt" 
anchor="I-D.sparks-sipcore-multiple-reasons">
   <front>
     <title>Multiple SIP Reason Header Field Values</title>
     <author fullname="Robert Sparks"/>
     <date year="2021" month="November" day="12"/>
     <abstract>
       <t>The SIP Reason Header Field as defined in RFC 3326 allows only 
one Reason value per protocol value. Practice shows it is useful to 
allow multiple values with the same protocol value. This update to RFC 
3326 allows multiple values for an indicated registered protocol when 
that protocol defines what the presence of multiple values means.</t>
     </abstract>
   </front>
   <seriesInfo name="Internet-Draft" 
value="draft-sparks-sipcore-multiple-reasons-00"/>
</reference>

We had (I thought) an open question around the deprecation of <format> 
at 
https://datatracker.ietf.org/doc/html/draft-levkowetz-xml2rfc-v3-implementation-notes-13#section-3.1.27, 
but I'm not finding a ticket (open or closed). Am I missing something?

RjS

---

From: Robert Sparks <[email-masked]>
Date: Fri, 4 Feb 2022 08:49:48 -0600

On the off chance that any of you have mail ingestion systems that 
rewrote the xml in the previous message in a way that broke it, it's at

https://mailarchive.ietf.org/arch/msg/xml-sg-cmt/jxDibCUKZHvlC2BeqCqtQzsxfSk

RjS

(yes, the irony of the line-fold rewriting at mailarchive is not lost on 
me).

---

From: "John R Levine" <[email-masked]>
Date: 4 Feb 2022 12:23:45 -0500

> We had (I thought) an open question around the deprecation of <format> at 

No, I think you're right, we never resolved it.

I am of two minds about the fornat question.  On the one hand, we publish 
in multiple formats and plan to do so indefinitely.

On the other hand, this is a bibliography entry so it makes sense to have 
one link to the info page, not try and guess what formats are available. 
In practice you cannot tell what RFCs have what formats without looking at 
the web site.  The entries in rfc-index.xml say which ones are supposed to 
be there, but some are missing, and in several cases there are two 
different PDFs (printout of the text, and either a scan of a paper 
document or converted Postscript), so this is another place where I don't 
think the benefit from the extra details are worth it.  Sort of like the 
postal thing.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Robert Sparks <[email-masked]>
Date: Mon, 7 Feb 2022 10:02:18 -0600

> No, I think you're right, we never resolved it.
Was this a single issue from the draft that we missed, or do we need to 
scrape the draft again?
>
> I am of two minds about the fornat question.  On the one hand, we 
> publish in multiple formats and plan to do so indefinitely.
>
> On the other hand, this is a bibliography entry so it makes sense to 
> have one link to the info page, not try and guess what formats are 
> available. In practice you cannot tell what RFCs have what formats 
> without looking at the web site.  The entries in rfc-index.xml say 
> which ones are supposed to be there, but some are missing, and in 
> several cases there are two different PDFs (printout of the text, and 
> either a scan of a paper document or converted Postscript), so this is 
> another place where I don't think the benefit from the extra details 
> are worth it.  Sort of like the postal thing.
You're still thinking with RFC blinders on. The bibxml references for 
_drafts_ could be constructed pointing to all versions the datatracker 
knows about. Or it could point only to the datatracker's main page 
instead of the txt version of the document, but there's a lot of dissent 
in the community about what "real" customers of our products should see 
most easily.

---

From: "John R Levine" <[email-masked]>
Date: 7 Feb 2022 11:17:02 -0500

> Was this a single issue from the draft that we missed, or do we need to 

Not sure.

>> one link to the info page, not try and guess what formats are available. ...

> _drafts_ could be constructed pointing to all versions the datatracker knows 
> about. Or it could point only to the datatracker's main page instead of the 
> txt version of the document, but there's a lot of dissent in the community 
> about what "real" customers of our products should see most easily.

Yes, I know, and I find it extremely frustrating that many people seem to 
worry only about saving one click today, without any thought to what will 
make RFCs useful to people a decade or two from now.

I would be OK with some sort of shortcut pointer that we allow in I-D's 
but not in prepped RFCs, although I realize this would drive the 
aforemntioned people nuts.

Regards,