Subject: Re: [xml2rfc] [django-project] RFC Bibtex format doi numbering incorrect

From: Robert Sparks <[email-masked]>
Date: Thu, 25 May 2017 14:49:38 -0500

Forwarding to what I hope is the best list...

On 5/20/17 3:25 PM, Stefan Viergutz wrote:
> Hello,
>
> i am using the bibtex format.
> The numbering for the DOI links are incorrect for RFC's with less than 
> 4 digits.
> If the links are generated, the leading zeros are missing.
>
> For Example RFC826 bibtex:
> https://datatracker.ietf.org/doc/rfc826/bibtex/
>
> doi = {10.17487/rfc826}
>
> should be:
>
> doi = {10.17487/rfc0826}
>
>
>
>
> or RFC1:
> https://datatracker.ietf.org/doc/rfc1/bibtex/
>
> doi = {10.17487/rfc1}
>
> should be:
>
> doi = {10.17487/rfc0001}
>
>
>
>
> Regards,
>
> Stefan Viergutz
>
>
>
> _______________________________________________
> Django-project mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/django-project

---

From: Julian Reschke <[email-masked]>
Date: Thu, 25 May 2017 23:19:00 +0200

> Forwarding to what I hope is the best list...

Out of curiosity: why is it incorrect? Do we have a precise description 
about what the format should be? Hopefully including RFC#s > 9999?

Best regards, Julian

---

From: Robert Sparks <[email-masked]>
Date: Thu, 25 May 2017 18:56:52 -0500

(fwiw, I didn't triage the message - just forwarded it.)

On 5/25/17 4:19 PM, Julian Reschke wrote:
> Out of curiosity: why is it incorrect? Do we have a precise 
> description about what the format should be? Hopefully including RFC#s 
> > 9999?
>
> Best regards, Julian

---

From: William Atwood <[email-masked]>
Date: Thu, 25 May 2017 20:49:22 -0400

Whoever originated this message discovered that entering

10.17487/rfc826

into the box on the website https://dx.doi.org/

gives a "not found" message.

Clearly there has to be agreement between the person who instantiated
the IETF DOIs in the first place, and the person who maintains/generates
the RFC BibTeX format.

As you say, I don't think that the person who generated the DOIs thought
about RFC numbers greater than 9999.  And it will happen quite soon. 
(Somewhat like exhausting IPv4 addresses...  :-) )

  Bill

On 25/05/2017 5:19 PM, Julian Reschke wrote:
> xml2rfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc

-- 

Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email:[email-masked]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 May 2017 14:06:30 +1200

> (Somewhat like exhausting IPv4 addresses...  :-) )

The suffix is any string that the originator (in this case, the RFC Editor)
happens to pick, and so far they have picked "RFC" followed by a four digit
number. But you can't rely on that; they could pick "fumbldook37" for
the next RFC published and still conform to the DOI standard.

Somebody, I think John Levine, explained this in detail on the rfc-interest
list a year or two ago.

   Brian

---

From: Stefan Viergutz <[email-masked]>
Date: Fri, 26 May 2017 08:32:00 +0200

The documents are registered with the DOI-Suffix RFC#### with four digits 
(e.g. RFC0001),
but in the Bibtex Files are no leading zeros for the DOI-Suffix (e.g. RFC1).

see source:

compare doi registration :
https://doi.org/10.17487/rfc0001
and bibtex entry(not found):
https://doi.org/10.17487/rfc1

Only the Bibtex file on the datatracker include the erroneous Identifier, 
rfc-editor displays the correct Identifier.
It seems to me there is a bug in the generation of the Bibtex-files.

The DOI is based on the doc-id from the rfc-index.xml. with the omnipresent 
format "RFCnnnn".
Reference:
Assigning Digital Object Identifiers to RFCs
https://datatracker.ietf.org/doc/rfc7669/

For future RFCs (10000+) could be worth looking into
if five digits could cause some trouble for the information systems.

Best Regards,

Stefan Viergutz

---

From: "John Levine" <[email-masked]>
Date: 26 May 2017 16:52:14 -0000

>about what the format should be? Hopefully including RFC#s > 9999?

DOIs are opaque identifiers.  The DOI of any RFC is whatever is in the
DOI field of the RFC Editor's database.  Any code that attempts to
guess the DOI from the RFC number is broken.

The DOI gemeration code uses the editor database internal identifier
as the last component of the DOI, because the code was easy to write.
Those identifiers currently all look like RFCnnnn but they may change
at any time without notice, since they're purely for the editor's
internal use.  In retrospect, using them was a mistake.  I should have
used something obviously opaque like a hash of the title and issue
date for the DOI.

In response to the question of what DOIs of RFCs past RFC9999 will be,
it doesn't matter.  If your code tries to guess, it is still broken.
The DOI is whatever the DOI is.  Don't guess, look it up.

R's,
John

---

From: Julian Reschke <[email-masked]>
Date: Sun, 28 May 2017 14:55:28 +0200

> guess the DOI from the RFC number is broken.

Wow. Really? Why not just define the mapping precisely?

> used something obviously opaque like a hash of the title and issue

Right. So if they are for the editor's internal use only, what's the 
correct way to compute the DOI for a RFC then?

> The DOI is whatever the DOI is.  Don't guess, look it up.

Where? I thought you just said the database is for internal use only?

Once again: just define the mapping precisely.

Best regards, Julian

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 28 May 2017 10:30:31 -0400

> Wow. Really? Why not just define the mapping precisely?

I don't know why, but presumably because it allows future flexibility.
In any case, the DOIs for existing RFCs have been *assigned*.  If you
use rsync to fetch ftp.rfc-editor.org::rfcs/rfc-index.txt, you seen
entries like this:

    0826 Ethernet Address Resolution Protocol: Or Converting Network Protocol
         Addresses to 48.bit Ethernet Address for Transmission on Ethernet
         Hardware. D. Plummer. November 1982. (Format: TXT=21556 bytes)
         (Updated by RFC5227, RFC5494) (Also STD0037) (Status: INTERNET
         STANDARD) (DOI: 10.17487/RFC0826) 

I would assume that the bibtex information for RFCs contains the DOIs as
Just Another Field.  But indeed, the "doi" field in
http://datatracker.ietf.org/doc/rfc826/bibtex/ doesn't match
rfc-index.txt:

	doi =		{10.17487/rfc826},

Dale

---

From: "John R Levine" <[email-masked]>
Date: 28 May 2017 11:00:37 -0400

> Wow. Really? Why not just define the mapping precisely?

Because we are not the only people in the world who use DOIs, and the
rule for everyone, not just us, is that they are opaque.  Our
references are supposed to show the DOI on every document that has
one, which includes anything published by the IEEE or ACM.  Where do
you get those?  If you don't, there's another bug report.

> Where? I thought you just said the database is for internal use only?

Huh.  This is just a wild guess, but how about looking up the DOI in the 
same place you get the title, authors, date and abstract.  Or are you 
saying you compute them from the RFC number, too?

R's,
John

---

From: "John R Levine" <[email-masked]>
Date: 28 May 2017 11:04:01 -0400

> use rsync to fetch ftp.rfc-editor.org::rfcs/rfc-index.txt,

It's easier to parse stuff out of rfc-index.xml in the same directory. 
Yes, Julian, there is a doi field.

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

---

From: Julian Reschke <[email-masked]>
Date: Sun, 28 May 2017 23:27:28 +0200

> you get those?  If you don't, there's another bug report.

What does this have to do with the mapping of RFC numbers to DOIs? I 
don't get it.

> saying you compute them from the RFC number, too?

Yes, of course I do.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 28 May 2017 23:29:56 +0200

> Yes, Julian, there is a doi field.

Which makes something that should be easy hard.

The only problem in computing you can't fix with additional indirections 
is the problem of too many indirections. And this is one too much, IMHO.

Best regards, Julian

---

From: "John Levine" <[email-masked]>
Date: 28 May 2017 21:49:29 -0000

>Which makes something that should be easy hard.

I'm sorry, but this is getting ridiculous.

Let's say I have a a document with a reference RFC7511 and run it
through xml2rfc.  Somehow, it will turn that reference into strings
like "Scenic Routing for IPv6" and "April 1, 2015".  Where do those
strings come from?

Wherever they come from, that's where the DOIs come from because
they're all stored in the same place.  Looking up DOIs is not
negotiable -- the rules about DOIs are fixed, and not only for the
IETF.  Please just fix the code.  It's hard to believe that looking up
one more field from the place where you look up a dozen already would
be hard.

R's,
John

---

From: Julian Reschke <[email-masked]>
Date: Mon, 29 May 2017 07:49:06 +0200

On 2017-05-28 23:49, John Levine wrote:
> ...

I'm not looking them up at all. I maintain an XML2RFC processor which is 
capable of

a) inserting DOIs when they are missing, and
b) checking RFC DOIs when they are present.

Neither should require an access to an external database.

Best regards, Julian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 May 2017 08:17:53 +1200

> Neither should require an access to an external database.

But it must, since the DOIs are arbitrary strings made up by the RFC Editor.
I don't understand your point: wherever you look up other arbitrary
strings, such as the document title, you can look up the DOI string.

I don't see why parsing <doi>10.17487/RFC0001</doi>
is any different from parsing <title>Host Software</title>

Regards
   Brian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 29 May 2017 22:30:17 +0200

> strings, such as the document title, you can look up the DOI string.

But I don't.

> is any different from parsing <title>Host Software</title>

The problem isn't parsing the rfc index, the problem is not necessarily 
having access to it.

I still don't get why we just define the mapping precisely.

Best regards, Julian

---

From: "John R Levine" <[email-masked]>
Date: 29 May 2017 17:12:25 -0400

>>  strings, such as the document title, you can look up the DOI string.

Then your code is even more broken than we realized.  If you are unable 
to fix it, I'm sure we can find someone who can.

Regards,

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 30 May 2017 00:07:11 +0200

Hi John,

> used something obviously opaque like a hash of the title and issue

Whatever was used, once you wrote the code, wouldn't it make sense to
publish where/how lookups should happen?  Has this been done?

And no matter how opaque the DOI series identifiers are in general, there's
still nothing that prevents the RFC Editor from _having_ a defined mapping
from RFC numbers to DOI and vice versa, if a decision is made that this
would be helpful, right?

	Henrik

---

From: "John R Levine" <[email-masked]>
Date: 29 May 2017 18:26:39 -0400

> publish where/how lookups should happen?  Has this been done?

Of course.  It's in RFC 7669.

> from RFC numbers to DOI and vice versa, if a decision is made that this

No.  I really, really, wish that people would stop trying to relitigate 
this settled fact.  We had the exact same argument before the IAB 
published RFC 7669 which says:

    DOIs are treated as opaque identifiers.  The DOI suffixes assigned to
    RFCs are currently based on the "doc-id" field of the RFC index in
    XML (rfc-index.xml), but the suffix of future RFCs might be based on
    something else if circumstances change.  Hence, the reliable way to
    find the DOI for an RFC is not to guess, but to look it up in the RFC
    index or on the RFC Editor website <https://www.rfc-editor.org/>.
    RFC references created from entries in the usual bibxml libraries
    will have DOIs included automatically.

Among the reasons not to change it is that RFCs can contain references to 
other kinds of documents, some of those other things also have DOIs, and 
those DOIs always have to be looked up.  I hope we agree that code that 
tried to guess some DOIs while looking up others would be fragile and 
likely to break in obscure ways.

As far as I can tell all of the code around the IETF that handles DOIs 
does it correctly except for Julian's, and by this time he could have 
fixed it with less effort than he's spent arguing that he doesn't want to.

R's,
John

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 30 May 2017 00:58:58 +0200

Hi John,

> published RFC 7669 which says:

So you are saying that even if the RFC-Editor wished to define and publish
an algorithmic mapping between RFC numbers and DOI identifiers, they would
not be permitted to do so?

	Henrik

---

From: Matthew Kerwin <[email-masked]>
Date: Tue, 30 May 2017 09:27:39 +1000

> not be permitted to do so?
This whole discussion is rather absurd, and I'm a bit disappointed to see
it happening. (Not you specifically, Henrik, I'm just replying to the last
message in the thread.)

The original bug report is legitimate, and should be corrected.  I.e. the
tool that generated this document:
https://datatracker.ietf.org/doc/rfc826/bibtex/ put the wrong value in the
'doi' field.  Presumably, that tool attempted to guess the value, rather
than fetching it from a reliable source (contrary to RFC 7669, questions of
which was published first notwithstanding), and guessed wrong.  Speaking as
a general programmery type person, but not someone familiar with the tools
and resources in question, I would assume that the tool should be able to
retrieve the value for 'doi' the same way it was able to retrieve the value
for 'title', from the same or a similar source, and if it were changed to
do so the bug would be fixed.  Please correct me if that assumption is
wrong.

Now, because I enjoy a good rabbit hole as much as the next person: Henrik,
the RFC Editor can define and publish such an algorithmic mapping, of
course.  If the goal is just to document the way in which they generate
DOIs, it's potentially interesting, but not really useful to anyone outside
the editors.  If, by publishing it, the RFC Editor wishes to make it
possible for consumers to correctly "guess" a DOI, then the document would
have to update RFC 7669 (with all the process and consensus that that would
involve.)

Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 30 May 2017 01:56:32 +0200

Hi Matthew,

On 2017-05-30 01:27, Matthew Kerwin wrote:
> 'doi' field.

Agreed.

My question above was prompted by what seemed to be increasingly bombastic
declarations, which didn't seem to lead towards actually resolving issues.

> Presumably, that tool attempted to guess the value, rather

I think that's right.  The code which generates the references on
tools.ietf.org is old TCL code which I very very happily leave to
Tony Hansen to poke at when necessary.  I'll have a look at the
datatracker code to see what happens there.

> have to update RFC 7669 (with all the process and consensus that that would

Which is what I'd expect, and a very sensible response.

Thank you :-)

	Henrik

---

From: "John Levine" <[email-masked]>
Date: 30 May 2017 00:33:31 -0000

>not be permitted to do so?

Not unless they could persuade the IAB to change RFC 7669.  Since that would
be a bad idea, I doubt they would do so.

What is the problem with looking up DOIs the same way we look up the
title, abstract, and umpteen other chunks of text in a reference?
Everyone else in the world does it.  Why are we so bleeping special?

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 30 May 2017 01:14:23 -0000

>datatracker code to see what happens there.

I updated the scripts that create the bibtex files to add the DOIs.  I
don't have the code handy (my copy is on a backup disk) but it
definitely was not in TCL.  Some of the code was PHP, some was perl,
and the changes were easy to add the DOI field to rfc-index.xml and to
add the DOIs to the bibtex files extracted from rfc-index.xml.

Incidentally, the bit about opaque identifiers wasn't obscure or
accidental.  There was a long thread on the ietf list, starting here.
Too much of it was rehashing misconceptions about DOIs, but a certain
amount was about the DOI format.  I shoulda taken Klensin's advice not
to make them look sort of mnemonic.

https://mailarchive.ietf.org/arch/msg/ietf/sJWpYADQrnzfqI8kMIaxtGSsreQ
https://mailarchive.ietf.org/arch/msg/ietf/N2_jzaYayp7396GAu_cr6GddUKA

>Which is what I'd expect, and a very sensible response.

I'm relieved we all agree about that.

R's,
John

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 30 May 2017 03:15:10 +0200

Hi John,

> Everyone else in the world does it.  Why are we so bleeping special?

In general, there's no problem in that.  There _is_ a problem in not even being
able to talk about when that might or might not be feasible, and how to handle
such a situation.  There is also a problem that there does not seem to be an
authoritative URL for such lookups.

May I point out that even when you quoted 7669, the quote did not show an easy
way to look up the correct DOI for a given RFC number?  If there's no clearly
publicised resource which lets you programmatically look up the DOI for each or
all RFCs, permitting authoritative information and easy local caching, there's
no wonder if toolmakers starts to think in terms of algorithmic derivation of
the DOIs for RFCs.

I know a few places I could go to get DOI information for RFCs, but should the
knowledge I have about URLs in this space be required?  And how authoritative
are the various resources I might think of?

Personally, I'm going to use my knowledge here to correct the datatracker's
bibtex record, but that doesn't resolve the general issue above.

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Tue, 30 May 2017 07:44:46 +0200

On 2017-05-30 00:26, John R Levine wrote:
> ...
> Among the reasons not to change it is that RFCs can contain references 
> to other kinds of documents, some of those other things also have DOIs, 
> and those DOIs always have to be looked up.  I hope we agree that code 
> that tried to guess some DOIs while looking up others would be fragile 
> and likely to break in obscure ways.
> ...

I did not suggest anything about non-RFC DOIs.

> fixed it with less effort than he's spent arguing that he doesn't want to.

The code we're talking about is *validation* code. It works for all 
published RFCs, and already has helped fixing broken references (when 
someone else copy/pasted a reference entry together).

I could fix this if there was an efficient way to lookup RFC information 
from rfc-editor.org, but that would require:

1) that the information is available per RFC (or set of RFCs), so it's 
not needed to pull the whole database

2) that the information is CORS-enabled, so it can be retrieved as side 
effect of displaying something in a browser

(that request isn't new, FWIW)

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 30 May 2017 08:12:56 +0200

Speaking of which:

> rfc7800: Unexpected DOI for RFC, found 10.17487/RFC7156, expected 10.17487/RFC7516
> rfc7800: Unexpected DOI for RFC, found 10.17487/RFC7157, expected 10.17487/RFC7517
> rfc7800: Unexpected DOI for RFC, found 10.17487/RFC7159, expected 10.17487/RFC7519
> rfc7880: Unexpected DOI for RFC, found 10.17487/RFC791, expected 10.17487/RFC0791
> rfc7881: Unexpected DOI for RFC, found 10.17487/RFC791, expected 10.17487/RFC0791
> rfc7882: Unexpected DOI for RFC, found 10.17487/RFC791, expected 10.17487/RFC0791

With that, I'll try to stay away from this discussion.

Best regards, Julian

---

From: "John R Levine" <[email-masked]>
Date: 30 May 2017 07:32:31 -0400

> The code we're talking about is *validation* code.

The way you validate a DOI is easy: you dereference it.  If the DOI is 
10.1234/something, you look up https://dx.doi.org/10.1234/something.  If 
it's valid, you'll get something back, if it isn't, you won't.  If your 
query accepts accept application/rdf+xml you will get back the document's 
bibliographic info in XML.

This works for all DOIs, not just RFCs.

Examples here: http://citation.crosscite.org/docs.html

Regards,

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 30 May 2017 10:13:30 -0400

> I still don't get why we just define the mapping precisely.

Let us at least state this position correctly.  The word is not
"precisely", since any well-defined mapping between RFCs and DOIs is
"precise", and the mapping defined in rfc-index.txt is well-defined.
The word you want is "algorithmically", and in particular in the sense
that one can predict the DOI that will be assigned to an RFC that does
not yet exist, based on its number.

> not be permitted to do so?

The Editor can publish whatever documentation they want to of their
current processes.  What they can't do is commit themselves to hold to
any particular algorithm for the indefinite future; what they say is not
a contract with the user.  Only the IAB can do that, and it hasn't.

> bibliographic info in XML.

Heh...  Liking to nit-pick requirement statements, I would revise this
to "you dereference it and verify that the bibliographic information you
obtain matches that of the document you think the DOI is for".

Dale

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Tue, 30 May 2017 15:56:16 +0000

On 5/29/17, 7:56 PM, "xml2rfc on behalf of Henrik Levkowetz" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Matthew,

And the bibxml tools happily use the DOI values as published by the RFC editor.

	Tony Hansen

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Tue, 30 May 2017 16:01:23 +0000

On 5/29/17, 9:14 PM, "xml2rfc on behalf of John Levine" <[email-masked] on behalf of [email-masked]> wrote:

Henrik was referring to the tools on tools.ietf.org, which I maintain. Not the tools on rfc-editor.org that you worked on, for which I thank you.

	Tony

---

From: "John Levine" <[email-masked]>
Date: 30 May 2017 21:04:28 -0000

>obtain matches that of the document you think the DOI is for".

Fair enough, although we could have quite the rabbit hole trying to
figure out how much fuzz between the DOI bibliographic stuff and
the document you want to tolerate.  In theory they're identical,
in practice things like authors' initials might not match.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 30 May 2017 21:16:33 -0000

>authoritative URL for such lookups.

I answered this privately, but in case anyone else was wondering,
they're in https://www.rfc-editor.org/rfc-index.xml along with the
rest of the bibliographic info for all of the RFCs.

The per-document pages on the RFC editor's web site are generated from
that file (I updated a bunch of them to include DOIs) so anyone who
wants the info might as well get it from the original source.

R's,
John

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 31 May 2017 01:31:32 +0200

> rest of the bibliographic info for all of the RFCs.

Thanks.  Finally an URL.

However, please note that this is not a lookup resource which encourages
on-the-fly lookups and caching.  It requires you to download the whole
corpus information every time you need an update ...

> wants the info might as well get it from the original source.

Ack.  Good.

	Henrik

---

From: "John R Levine" <[email-masked]>
Date: 30 May 2017 19:50:30 -0400

> corpus information every time you need an update ...

Sure, but I expect it's obvious how you'd cache a copy locally for 
lookups.  Downloading it once a day would be plenty.

Regards,

---

From: Julian Reschke <[email-masked]>
Date: Wed, 31 May 2017 08:01:20 +0200

> lookups.  Downloading it once a day would be plenty.

So if it's obvious, why do we have published RFCs with broken DOIs? This 
is something that could have been avoided if the formatter had done a 
sanity check.

Best regards, Julian

---

From: "John R Levine" <[email-masked]>
Date: 31 May 2017 09:06:50 -0400

> So if it's obvious, why do we have published RFCs with broken DOIs? This is 
> something that could have been avoided if the formatter had done a sanity 
> check.

Beats me.  If the references had come from bibtex, they'd be right, so who 
knows what other tools they haven't been using.  As you surely know, we 
can write all the tools we want but we can't force people to use them.

I would cheerfully have written a DOI checker (a real one, not just for 
RFCs) if anyone had asked, or if I had any idea that people would so 
relentlessly invent bad ones rather than looking the d*'d things up.

Regards,

---

From: Julian Reschke <[email-masked]>
Date: Wed, 31 May 2017 15:14:58 +0200

On 2017-05-31 15:06, John R Levine wrote:
>> So if it's obvious, why do we have published RFCs with broken DOIs? 
>> This is something that could have been avoided if the formatter had 
>> done a sanity check.
> 
> Beats me.  If the references had come from bibtex, they'd be right, so 
> who knows what other tools they haven't been using.  As you surely know, 
> we can write all the tools we want but we can't force people to use them.
> ...

Well, we know that an xml2rfc processor *is* used. That processor could 
do a sanity check on the DOIs, in which case the problem might have been 
detected during AUTH48.

Best regards, Julian

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Wed, 31 May 2017 18:06:13 +0000

On 5/31/17, 9:14 AM, "xml2rfc on behalf of Julian Reschke" <[email-masked] on behalf of [email-masked]> wrote:

If the bibxml references from xml2rfc.ietf.org are used, the DOIs will be exactly what are created by John’s tools on the RFC Editor site.

	Tony