Subject: [xml2rfc] Possibly an RFCed question rather than a tools question, but here goes: References to conference papers

From: "David R. Oran" <[email-masked]>
Date: Mon, 24 Aug 2020 10:36:02 -0400

One of my docs is in IRSG review, and the reviewer objected that the 
references to conference papers don’t confirm to the generally 
accepted citation format. In particular, conference papers generally 
have the paper title in Italics, followed by the Conference name, 
followed by the conference date.

xml2rfc can’t seem to be cajoled to output this. It rejects an <em> 
element inside a title element, so I can’t put the title in italics. 
If I try to put the title in quotes (the alternative formulation), I get 
doubled double-quotes at the front of the title element.

Is there some work-around or do I just tell the reviewer “sorry, no 
can do”, complain to the RFCed?

Just as an additional aside, it would really be an improvement if the 
RFC reference format was enhanced to have some more of the abstract 
elements supported by BibTex, especially an <inProceedings> element to 
separate the paper title from the publishing vehicle.

Here’s an example:

         <reference anchor="Krol2018" 
target="https://conferences.sigcomm.org/acm-icn/2018/proceedings/icn18-final9.pdf">
           <front>
             <title>"RICE: Remote Method Invocation in ICN," in 
Proceedings of the 5th ACM Conference on Information-Centric Networking 
- ICN '18</title>
             <seriesInfo name="DOI" value="10.1145/3267955.3267956"/>
             <author surname="Król" initials="M." fullname="Michał 
Król" asciiSurname="Krol" asciiFullname="Michal Krol"/>
             <author surname="Habak" initials="K." fullname="Karim 
Habak"/>
             <author surname="Oran" initials="D." fullname="David 
Oran"/>
             <author surname="Kutscher" initials="D." fullname="Dirk 
Kutscher"/>
             <author surname="Psaras" initials="I." fullname="Ioannis 
Psaras"/>
             <date year="2018" month="September"/>
           </front>
         </reference>

DaveO

---

From: "John Levine" <[email-masked]>
Date: 24 Aug 2020 14:53:49 -0400

>followed by the conference date.

Every publisher and professional society has its own style guide,
which includes the reference formats. Elsevier alone has ten different
formats, which they describe here:

https://www.elsevier.com/editors-update/story/author-support/reference-formatting

If your draft is published as an RFC, the rendered versions will
follow the RFC style.

On the other hand, if the reviewer can only find italics in the
references to complain about, your paper must be in pretty good shape.

R's,
John
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Randy Bush <[email-masked]>
Date: Mon, 24 Aug 2020 12:04:16 -0700

> separate the paper title from the publishing vehicle.

i am lazy.  please either accept bibtex or can someone hack a converter
from bibtex to xml2rfc?  while you are at it, the inverse would be nice,
as i have to cite rfcs in papers.

randy

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 24 Aug 2020 21:05:52 +0200

FYI, this is what doilit (part of kramdown-rfc) generates:

$ doilit -x=Krol2018 10.1145/3267955.3267956

<reference anchor="Krol2018" >
  <front>
    <title>RICE</title>
    <author initials="M." surname="Król" fullname="Michał Król">
      <organization></organization>
    </author>
    <author initials="K." surname="Habak" fullname="Karim Habak">
      <organization></organization>
    </author>
    <author initials="D." surname="Oran" fullname="David Oran">
      <organization></organization>
    </author>
    <author initials="D." surname="Kutscher" fullname="Dirk Kutscher">
      <organization></organization>
    </author>
    <author initials="I." surname="Psaras" fullname="Ioannis Psaras">
      <organization></organization>
    </author>
    <date year="2018" month="September"/>
  </front>
  <seriesInfo name="Proceedings of the 5th ACM Conference on Information-Centric" value="Networking"/>
  <seriesInfo name="DOI" value="10.1145/3267955.3267956"/>
</reference>

I know the series info workaround is an ugly hack, but it works for me.

(The fact that doilit doesn’t make use of the subtitle information probably should be counted as a bug.)

Grüße, Carsten

> On 2020-08-24, at 16:36, David R. Oran <[email-masked]> wrote:
> 
> One of my docs is in IRSG review, and the reviewer objected that the references to conference papers don’t confirm to the generally accepted citation format. In particular, conference papers generally have the paper title in Italics, followed by the Conference name, followed by the conference date.
> 
> xml2rfc can’t seem to be cajoled to output this. It rejects an <em> element inside a title element, so I can’t put the title in italics. If I try to put the title in quotes (the alternative formulation), I get doubled double-quotes at the front of the title element.
> 
> Is there some work-around or do I just tell the reviewer “sorry, no can do”, complain to the RFCed?
> 
> Just as an additional aside, it would really be an improvement if the RFC reference format was enhanced to have some more of the abstract elements supported by BibTex, especially an <inProceedings> element to separate the paper title from the publishing vehicle.
> 
> Here’s an example:
> 
>     <reference anchor="Krol2018" target="https://conferences.sigcomm.org/acm-icn/2018/proceedings/icn18-final9.pdf">
>       <front>
>         <title>"RICE: Remote Method Invocation in ICN," in Proceedings of the 5th ACM Conference on Information-Centric Networking - ICN '18</title>
>         <author surname="Król" initials="M." fullname="Michał Król" asciiSurname="Krol" asciiFullname="Michal Krol"/>
>         <author surname="Habak" initials="K." fullname="Karim Habak"/>
>         <author surname="Oran" initials="D." fullname="David Oran"/>
>         <author surname="Kutscher" initials="D." fullname="Dirk Kutscher"/>
>         <author surname="Psaras" initials="I." fullname="Ioannis Psaras"/>
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc

---

From: Julian Reschke <[email-masked]>
Date: Mon, 24 Aug 2020 21:20:29 +0200

Am 24.08.2020 um 16:36 schrieb David R. Oran:
> ...
> element inside a title element, so I can’t put the title in italics. If
> I try to put the title in quotes (the alternative formulation), I get
> ...

/me confused.

The title is automatically put into double quotes. What am I missing here?

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 24 Aug 2020 21:30:54 +0200

> The title is automatically put into double quotes. What am I missing here?

I think that the inproceedings was munched into the title.
The seriesinfo hack doesn’t do that.
(Fixing the doilit subtitle bug right now.)

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 24 Aug 2020 21:44:47 +0200

> (Fixing the doilit subtitle bug right now.)

1.3.11: The auxiliary tool doilit no longer ignores subtitles.

For merging title and subtitle(s) into a single RFCXML title element, it uses the CMOS (*) convention of separating title from subtitle with a colon and multiple subtitles with a semicolon from each other (RFC 7322 is mute on the issue and defers to CMOS for style issues in general).

This probably needs to be updated on the server behind bibxml7 to have a widespread effect.

Grüße, Carsten

(*)
[CMOS]: Chicago Manual of Style, 16th ed. Chicago: University of Chicago Press, 2010.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 24 Aug 2020 21:48:50 +0200

On 2020-08-24, at 21:04, Randy Bush <[email-masked]> wrote:
> 
> while you are at it, the inverse would be nice,

https://datatracker.ietf.org/doc/rfc8798/bibtex/

@misc{rfc8798,
	series =	{Request for Comments},
	number =	8798,
	howpublished =	{RFC 8798},
	publisher =	{RFC Editor},
	doi =		{10.17487/RFC8798},
	url =		{https://rfc-editor.org/rfc/rfc8798.txt},
        author =	{Carsten Bormann},
	title =		{{Additional Units for Sensor Measurement Lists (SenML)}},
	pagetotal =	9,
	year =		2020,
	month =		jun,
	abstract =	{The Sensor Measurement Lists (SenML) media type supports the indication of units for a quantity represented. This short document registers a number of additional unit names in the IANA registry for units in SenML. It also defines a registry for secondary units that cannot be in SenML's main registry, as they are derived by linear transformation from units already in that registry.},
}

Grüße, Carsten

---

From: "Randy Bush" <[email-masked]>
Date: Mon, 24 Aug 2020 13:02:37 -0700

> https://datatracker.ietf.org/doc/rfc8798/bibtex/

ooooo!  thanks.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Aug 2020 08:57:26 +1200

> 	url =		{https://rfc-editor.org/rfc/rfc8798.txt},

That's wrong for recent RFCs. It should perhaps be https://www.rfc-editor.org/rfc/rfc8798.html, but actually the DOI points to https://www.rfc-editor.org/info/rfc8798 and that is valid for old and new format RFCs. So,

url =		{https://rfc-editor.org/info/rfc8798},

Regards
    Brian

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 24 Aug 2020 23:03:14 +0200

> url =		{https://rfc-editor.org/info/rfc8798},

BTW, this is a web page that suggests I should download Adobe Reader.
You couldn’t make this up while on the wildest drugs.

Grüße, Carsten

---

From: Randy Bush <[email-masked]>
Date: Mon, 24 Aug 2020 14:08:05 -0700

> BTW, this is a web page that suggests I should download Adobe Reader.

it could have said flash

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Aug 2020 09:32:57 +1200

>> BTW, this is a web page that suggests I should download Adobe Reader.

I suggest you take the aesthetic complaint to the RFC Editor. That is nevertheless the source of the canonical version (txt for old ones, xml for new ones) so for formal citation purposes I don't see what alternative there is.

   Brian

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 25 Aug 2020 01:04:44 +0200

(The subject line is useless by now; this is a tangent (links to RFCs) of a tangent (bibtex for RFCs) of the original discussion.  Wrong mailing list, too.  EWONTFIX.)

> On 2020-08-24, at 23:32, Brian E Carpenter <[email-masked]> wrote:
> 
> I suggest you take the aesthetic complaint to the RFC Editor.

I think Randy's comment may have been a bit opaque (it sure hit the mark), but that is a different construction site.

Anyway:

> That is nevertheless the source of the canonical version (txt for old ones, xml for new ones) so for formal citation purposes I don't see what alternative there is.

Well, for a very long, long time the stable, and useful link for RFC 8798 would have been 

http://tools.ietf.org/html/rfc8798

Which is slowly being eclipsed by (sometimes linked from the above):

https://www.rfc-editor.org/rfc/rfc8798

One of these two is still my personal preference for a link I would like to see in my papers, even if it isn’t canonical (in my part of the world, the only more canonical link is, unfortunately, https://doi.org/10.17487/RFC8798 — which redirects to https://www.rfc-editor.org/info/rfc8798.)

Yes, the http:// had to change.
But clearly, we are missing out on [1] here to a larger extent than necessary.

(I can only hope the recent discussion about RFC governance doesn’t make us change the domain name “rfc-editor.org”.)

Grüße, Carsten

[1]: https://www.w3.org/Provider/Style/URI.html "Cool URIs don't change”

---

From: "John Levine" <[email-masked]>
Date: 25 Aug 2020 14:44:02 -0400

>You couldn’t make this up while on the wildest drugs.

While I realize that the vast majority of current web browsers already
know how to handle PDFs, there's still people at the end of the long
tail using browsers that don't. What advice would you offer them?

Adobe's reader works and has been ported to every platform anyone has
ever heard of.  It seems as good a suggestion as any.

R's,
John

PS: That link has been there for many years and we've never gotten a
complaint I can recall. What's different now?

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 25 Aug 2020 21:44:55 +0200

Hi John,

I apologize for never having looked closely at the RFC editor info pages; so far, they hadn’t been elevated to a status that would have many users look at them (me obviously being an example for that).

> complaint I can recall. What's different now?

OK, let me start with the question at the end.  What’s different now?
It’s 2020.  People who have been around computers (which probably is a valid description of our clientele) know how to handle PDF.  

But, OK, 4 people are born every second who don’t.  There is a minute chance that they make it through life not learning about PDF before opening up an RFC info page and wanting to read a PDF.  Or, more likely, they do know, but the system they happen to use at that instance is ancient enough not to be able to handle PDF.

What do we want to do to people that are clueless about PDF or that find themselves at an ancient system?  Probably not offer a convenient affordance to mindlessly install a specific product that is known to have been one of the most useful entry points for system security attacks [1].

We don’t need to endorse a specific product any more.  Our PDFs don’t need the proprietary features of that product (which are the most useful part for an attacker).  We don’t need to help perpetuate the dogged myth that you need that product to work with PDFs (*).

So what should be done instead?

When you get a coordinate in Wikipedia, this is not shown as a Google Maps link, but you are led to a page that offers links to a choice of map products that enable you to look at a map situated at that coordinate.  Many people probably do click on Google Maps then, but that interstitial reinforces the concept of Pluralism of Operators and Technologies [2], which should be dear to our heart.  Design for Choice [3], not only our protocols, but also our websites.

Grüße, Carsten

[1]: https://thehackernews.com/search/label/Adobe%20Reader (random link)
(*): I’ve seen IETF chairs use that product on platforms that have better native capabilities.  Makes me wonder…
[2]: https://www.identityblog.com/stories/2005/05/13/TheLawsOfIdentity.pdf (and not just of identity)
[3]: https://dl.acm.org/doi/10.1145/633025.633059

---

From: "John R Levine" <[email-masked]>
Date: 25 Aug 2020 16:38:08 -0400

> When you get a coordinate in Wikipedia, this is not shown as a Google Maps link, but you are led to a page that offers links to a choice of map products that enable you to look at a map situated at…

As we say, please send text.

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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 25 Aug 2020 23:30:23 +0200

> As we say, please send text.

The best text may be no text (i.e., not offering any help with displaying PDFs).

If you do want such help on the RFC editor pages, I could definitely write this, but it sure will be opinionated.

Grüße, Carsten

---

From: Robert Sparks <[email-masked]>
Date: Thu, 27 Aug 2020 11:58:18 -0500

On 8/25/20 3:38 PM, John R Levine wrote:
>> When you get a coordinate in Wikipedia, this is not shown as a Google 
>> Maps link, but you are led to a page that offers links to a choice of 
>> map products that enable you to look at a map situated at that 
>> coordinate.  Many people probably do click on Google Maps then, but 
>> that interstitial reinforces the concept of Pluralism of Operators 
>> and Technologies [2], which should be dear to our heart.  Design for 
>> Choice [3], not only our protocols, but also our websites.
>
What about replacing the link with a link to 
https://en.wikipedia.org/wiki/List_of_PDF_software?

---

From: "John R Levine" <[email-masked]>
Date: 27 Aug 2020 13:08:37 -0400

> https://en.wikipedia.org/wiki/List_of_PDF_software?

At this point, I am inclined to agree with Cartsten that if your browser 
doesn't already know how to show you a PDF, you've got more problems than 
any link can solve.

Regards,

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 27 Aug 2020 19:09:01 +0200

On 2020-08-27, at 18:58, Robert Sparks <[email-masked]> wrote:
> 
> What about replacing the link with a link to https://en.wikipedia.org/wiki/List_of_PDF_software?

That occurred to me, too.

It is certainly a second best to writing some specific help, but it is a bit defocused from the task “I want to read a PDF document”.  E.g., it doesn’t point out that you don’t need “PDF software” because the browser already does it (myth #1 to be busted).  The list of software includes PDF creation software as well as viewing software, and the matrix with the platforms is ordered in such a way to you can’t simply link to the viewing software.

I would have used the link as a “further information” catch-all at the end of a much shorter “how-to” section.  See https://www.howtogeek.com/360744/what-is-a-pdf-file-and-how-do-i-open-one/ for a not quite perfect example of such a section.

Grüße, Carsten