Subject: Re: [TOOLS-DEVELOPMENT] DOI processing for the RFC Editor

From: Robert Sparks <[email-masked]>
Date: Mon, 02 Jun 2014 16:17:02 -0500

On 5/30/14, 5:28 PM, Scott O. Bradner wrote:
> this talks about a program to "extract the data from the existing series“
>
> it would not be clear to me what this means - it could mean use the 
> rfc-index,
> it could mean processing all of the .txt files or it could 
> mean something else

It's not yet clear exactly where data will need to be extracted from,
determining that can be part of the project.
The _kind_ of data is stuff we would expect to find in the index, (like 
titles, number of pages, etc)
but the possibility exists that the documents might need to be combed.
If I can find a list of the needed data on the crossref site without too 
much digging, I'll reflect it here.
Otherwise, I'll characterize the type of data that will be extracted (as 
I did above) and make it more
explicit that one of the project tasks is to finish nailing down what's 
needed.
> in the 4th bullet under deliverables it might be good to say in the 
> description that the RFCs
> themselves will not be updated since they are not changed after being 
> published
> (i.e,. be extra clear on this point)
OK.
>
> the text mentions “ongoing maintenance” - does this refer to the 
> assignment of DOIs for new
> RFCs as they are produced or something else?  “ maintenance” seems a 
> funny term for something
> that gets assigned once & never changed
That was ongoing maintenance of the rfc-index and things like the bibxml 
files as new RFCs are
added to them. I'll try to make that clearer.
>
> Scott
>
> On May 30, 2014, at 4:28 PM, Robert Sparks <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Here is a first pass at a project SoW for automating working with 
>> DOIs for the RFC series.
>> (It is version -02 due to some early iteration with Heather and Alice).
>> One open question that I'm discussing with them is whether this will 
>> only update the bibxml files (the unnumbered collection consisting of 
>> the i-d and rfc references), or if it is also intended to put DOIs 
>> for other organizations documents when we can find them into bibxml2 
>> through bibxml5.
>> What else does this need to say?
>>
>> RjS
>> <DOI_Processing-02.pdf><DOI_Processing-02.docx>_______________________________________________
>> TOOLS-DEVELOPMENT mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/tools-development
>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 03 Jun 2014 13:22:29 -0500

Some further questions and comments now that my elbows are in the text
On 6/2/14, 4:17 PM, Robert Sparks wrote:
> The _kind_ of data is stuff we would expect to find in the index, 
> (like titles, number of pages, etc)
> If I can find a list of the needed data on the crossref site without 
> too much digging, I'll reflect it here.
> Otherwise, I'll characterize the type of data that will be extracted 
> (as I did above) and make it more
> explicit that one of the project tasks is to finish nailing down 
> what's needed.
I think I've been able to clarify this.
>> (i.e,. be extra clear on this point)
The 4th bullet is talking about future RFCs. Those _will_ contain the 
DOI (especially when we
are publishing in the new format). The point of this bullet is to get 
the DOI in an automated way
as part of that production so it can be there.

I changed the bullet to read

·Integrate the automated acquisition of DOIs for future RFCs into the 
workflow for producing that RFC

> That was ongoing maintenance of the rfc-index and things like the 
> bibxml files as new RFCs are
I struggled with this (wasn't sure after reading it where your confusion 
crept in). I'm making a guess
that it was because the sentence introducing the list tried to say two 
things at once. I've separated them
so that it looks like this:

> The project will automate both a bulk update to the following products 
> to reflect the DOI information for existing RFCs.
>
> ·http://www.rfc-editor.org/rfc-ref.txt
>
> ·The bibxml products at http://xml.resource.org/public/rfc/
>
> ·The individual RFC information pages (e.g. 
> http://www.rfc-editor.org/info/rfc6635)
>
> ·rfc-index.xml
>
> ·rfc-index.txt
>
> ·rfc-index.html
>
> The project will also automate the addition of the acquired DOI for 
> each new RFC into each of the above products.
>

Let me know if that addressed what was concerning you?

>>> only update the bibxml files (the unnumbered collection consisting 
>>> of the i-d and rfc references), or if it is also intended to put 
>>> DOIs for other organizations documents when we can find them into 
>>> bibxml2 through bibxml5.

---

From: Robert Sparks <[email-masked]>
Date: Tue, 03 Jun 2014 13:36:19 -0500

This incorporates the comments so far and adds a few things.

I have not tracked changes (it would have been very noisy to have done 
so), but the document is short enough that I don't feel too bad asking 
you to read through the whole thing again.

I'd like in particular to call attention to the added deliverable for 
updating the entries in bibxml2 (and others) for documents from other 
organizations to include DOIs.
This turns out to be a _requirement_ for participating in the DOI 
environment.

Heather, could you confirm my assumption that we will be registering all 
our RFCs (whether they are standards track or not) as "standards" using 
the grammar at 
<http://www.crossref.org/schema/documentation/4.3.0/4_3_0.html#standard> ?

Re: the open issue in the document : I'm raising the question of what a 
<reference> with a DOI in it would look like in v2 and v3 with the 
rfc-design team now. I suspect it will cause a change to the v3 grammar.

RjS

---

From: "Scott O. Bradner" <[email-masked]>
Date: Tue, 3 Jun 2014 14:41:01 -0400

better

tnx

Scott

On Jun 3, 2014, at 2:22 PM, Robert Sparks <[email-masked]> wrote:

>>> it would not be clear to me what this means - it could mean use the rfc-index,
>>> it could mean processing all of the .txt files or it could mean something else
>> 
>> The _kind_ of data is stuff we would expect to find in the index, (like titles, number of pages, etc) 
>> If I can find a list of the needed data on the crossref site without too much digging, I'll reflect it here.
>> Otherwise, I'll characterize the type of data that will be extracted (as I did above) and make it more
>> explicit that one of the project tasks is to finish nailing down what's needed.
>>> in the 4th bullet under deliverables it might be good to say in the description that the RFCs 
>>> themselves will not be updated since they are not changed after being published 
> The 4th bullet is talking about future RFCs. Those _will_ contain the DOI (especially when we
> are publishing in the new format). The point of this bullet is to get the DOI in an automated way
> ·      Integrate the automated acquisition of DOIs for future RFCs into the workflow for producing that RFC
>>> 
>>> the text mentions “ongoing maintenance” - does this refer to the assignment of DOIs for new
>>> RFCs as they are produced or something else?  “ maintenance” seems a funny term for something
>> That was ongoing maintenance of the rfc-index and things like the bibxml files as new RFCs are
> I struggled with this (wasn't sure after reading it where your confusion crept in). I'm making a guess
> that it was because the sentence introducing the list tried to say two things at once. I've separated them
>> The project will automate both a bulk update to the following products to reflect the DOI information for existing RFCs.
>> ·      http://www.rfc-editor.org/rfc-ref.txt
>> ·      The bibxml products at http://xml.resource.org/public/rfc/
>> ·      The individual RFC information pages (e.g. http://www.rfc-editor.org/info/rfc6635 )
>> ·      rfc-index.xml
>> ·      rfc-index.txt
>> ·      rfc-index.html
>> The project will also automate the addition of the acquired DOI for each new RFC into each of the above products.
> 
>>> On May 30, 2014, at 4:28 PM, Robert Sparks <[email-masked]> wrote:
>>> 
>>>> Here is a first pass at a project SoW for automating working with DOIs for the RFC series.
>>>> One open question that I'm discussing with them is whether this will only update the bibxml files (the unnumbered collection consisting of the i-d and rfc references), or if it is also intended to put DOIs for other organizations documents when we can find them into bibxml2 through bibxml5.
>>>> [email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Tue, 03 Jun 2014 20:47:11 +0200

> organizations to include DOIs.

To include the DOI itself, right?

> This turns out to be a _requirement_ for participating in the DOI

Why?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 03 Jun 2014 20:54:40 +0200

On 2014-06-03 20:36, Robert Sparks wrote:
> ...

A few comments... (BTW why are these documents not simply Internet 
Drafts????)

> •	Identify the data needed to apply for an DOI for an RFC, and for each data element, identify the appropriate source for that data.
> •	Build a program to extract that data from the existing series necessary to apply for a DOI for each existing RFC.

In a sane world, we'll identify what's missing in the XML version of the 
RFC index and just fix that.

> OPEN ISSUE: The grammar for <reference> is going to be different for xml2rfc v2 and v3, which will likely cause us to maintain parallel bibxml trees for each grammar. Do we want this project to create code that can speak both grammars? (For each of the grammars we decide to go with, this SoW should include an example of a <reference> populated with a mocked-up DOI.)

There are two obvious places to put the DOI in (target, and seriesInfo), 
and both exist in v2 already.

Best regards, Julian

---

From: Robert Sparks <[email-masked]>
Date: Tue, 03 Jun 2014 14:01:42 -0500

> A few comments... (BTW why are these documents not simply Internet 
Leaving room in case we need graphics as they mature (as the ipr and 
liaison tool SoWs did).
Finish v3 so I can do graphics there :)

>
>> •    Identify the data needed to apply for an DOI for an RFC, and for 
>> each data element, identify the appropriate source for that data.
>> •    Build a program to extract that data from the existing series 
>> necessary to apply for a DOI for each existing RFC.
>
> In a sane world, we'll identify what's missing in the XML version of 
> the RFC index and just fix that.
I'm anticipating that we'll find the information in the RFC index. If we 
have to go elsewhere for anything, then updating the index to include it 
seems sane. Don't know if that should be part of this project though.
>
>> OPEN ISSUE: The grammar for <reference> is going to be different for 
>> xml2rfc v2 and v3, which will likely cause us to maintain parallel 
>> bibxml trees for each grammar. Do we want this project to create code 
>> that can speak both grammars? (For each of the grammars we decide to 
>> go with, this SoW should include an example of a <reference> 
>> populated with a mocked-up DOI.)
>
> There are two obvious places to put the DOI in (target, and 
> seriesInfo), and both exist in v2 already.
>
> Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 03 Jun 2014 21:09:46 +0200

> Finish v3 so I can do graphics there :)

You can do graphics in v2 already; it's just harder to submit as 
internet draft. See 
<http://greenbytes.de/tech/webdav/draft-reschke-xml2rfc-latest.html#element.artwork>.

> seems sane. Don't know if that should be part of this project though.

If there's a problem with the index, we should fix the index, not create 
additional work somewhere else.

For instance, the reason why bibxml entries can not be generated simply 
from the index is that it doesn't maintain initials and surnames 
separately. Can we please fix this?

Best regards, Julian

---

From: Tony Hansen <[email-masked]>
Date: Tue, 03 Jun 2014 15:41:07 -0400

> seriesInfo), and both exist in v2 already.

I think it's worth spec'ing this out:

Here's a sample bibxml entry:

<reference anchor='RFC####'>
     <front>
         <title>Some Title Goes Here</title>
         <author fullname='J. Doe' initials='J.' surname='Doe'>
             <organization></organization>
         </author>
         <date month='June' year='2014'></date>
         <abstract>
             <t>Some abstract goes here</t>
         </abstract>
     </front>
     <seriesInfo name='RFC' value='####'></seriesInfo>
     <format octets='123456' 
target='http://www.rfc-editor.org/rfc/rfc####.txt' type='TXT'></format>
  </reference>

I take it you're talking about the <reference> target attribute?

Using the target attribute would change the above to:

     <reference anchor='RFC####' target='DOI URI GOES HERE'> ... 
</reference>

Using an additional <seriesInfo> would add a line like this:

     <seriesInfo name='DOI' value='DOI ID NUMBER GOES HERE' />

Another option might be the format, as in:

     <format type='DOI' target='DOI URI GOES HERE' />

Which would be preferred?

What would be the URI that would be used if one of the URI versions were 
chosen?

     Tony Hansen

---

From: Julian Reschke <[email-masked]>
Date: Tue, 03 Jun 2014 22:00:46 +0200

>              <t>Some abstract goes here</t>

We should get rid of the abstract entry in bibxml entries. It serves no 
purpose.

> target='http://www.rfc-editor.org/rfc/rfc####.txt' type='TXT'></format>

<format> is gone in v3.

> I take it you're talking about the <reference> target attribute?

Yes.

> Which would be preferred?

<format>: see above.

I believe reference/target is the right place for documents that have 
nothing else to link to.

> What would be the URI that would be used if one of the URI versions were

Purists would probably prefer the doi URN; my preference would be an 
HTTP URI (at dx.doi.org?).

Best regards, Julian

---

From: "Scott O. Bradner" <[email-masked]>
Date: Tue, 3 Jun 2014 16:26:35 -0400

On Jun 3, 2014, at 2:36 PM, Robert Sparks <[email-masked]> wrote:

> I'd like in particular to call attention to the added deliverable for updating the entries in bibxml2 (and others) for documents from other organizations to include DOIs.
> This turns out to be a _requirement_ for participating in the DOI environment.

can you state just what the requirement is - I assume that it is not a requirement to add
DOIs to documents published by other organizations (that would not make sense to me)

is it dealing with the case where a document from another organization already has a DOI
we are required to list the DOI wherever we refer to the document?

if that is the case I trust that there is not a requirement (which we could not meet) to
do this retroactively for documents we have already published

Scott

---

From: Robert Sparks <[email-masked]>
Date: Tue, 03 Jun 2014 15:33:59 -0500

> DOIs to documents published by other organizations (that would not make sense to me)
No, it's to include the DOIs for documents published by other 
organizations in any citations libraries we maintain.

> we are required to list the DOI wherever we refer to the document?
Yes
> do this retroactively for documents we have already published
As I understand it so far the requirement is for the citation library, 
and would not affect existing documents.

If you'd like to pick at the legalese, it's at
<http://www.crossref.org/08downloads/2014/2014_PILA_Membership_Agreement_5.21.pdf>
section 3.a.iv.

---

From: "Scott O. Bradner" <[email-masked]>
Date: Tue, 3 Jun 2014 16:37:46 -0400

there has to be a clearer way to say what they are saying

Cross-Linking. The PILA Member may maintain reference links that are not based on Digital Identifiers. However, other than for citations to Original Works, all of which said cited-Original Works are collectively hosted on a common hosting system or platform controlled by the PILA Member or its agent (“Internal Citations”), the CrossRef Member shall use Digital Identifiers (if a Digital Identifier has been registered for the cited item) for reference linking in the same manner(s) it may provide, offer or support all other (i.e., non-Digital-Identifier- based) reference linking. The PILA Member may not divert, interrupt or otherwise interfere or delay the resolution of said Digital Identifier-enabled reference citation links to the “Response Page” (defined below), and shall display the same to end-users (i.e., readers) in a manner that is no less prominent or immediate than other reference links (if any). For avoidance of doubt, the PILA Member is encouraged but not required to use Digital Identifiers for Internal Citations. 

but it seems that your interpretation fits what they say

tnx

Scott
On Jun 3, 2014, at 4:33 PM, Robert Sparks <[email-masked]> wrote:

> No, it's to include the DOIs for documents published by other organizations in any citations libraries we maintain.
> 
>> 
> As I understand it so far the requirement is for the citation library, and would not affect existing documents.
>

---

From: Tony Hansen <[email-masked]>
Date: Tue, 03 Jun 2014 17:27:26 -0400

>> Which would be preferred?

But if we chose to use it, that might give us a reason to keep it. :-)

> I believe reference/target is the right place for documents that have 

For RFCs, I think reference/target SHOULD be set to a URL for the RFC at 
rfc-editor.org.

> HTTP URI (at dx.doi.org?).

If we were to use <seriesInfo>, we can actually put there either the DOI 
ID number OR the DOI URN OR an HTTP URI. For that matter, we could have 
multiple <seriesInfo> entries if we chose to.

Just thinking out loud.

Ancillary to this is how the rfc-index.xml entry should specify the DOI 
value. Has anyone discussed this yet? Simplest suggestion: add a <doi> 
entry within <rfc-entry>.

     Tony

---

From: Julian Reschke <[email-masked]>
Date: Tue, 03 Jun 2014 23:35:30 +0200

> For RFCs, I think reference/target SHOULD be set to a URL for the RFC at

I agree. In this case we *do* have something better to link to, so why 
include a DOI?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 03 Jun 2014 23:37:28 +0200

> organizations in any citations libraries we maintain.

If that is indeed a requirement than my vote is to stop this activity 
altogether.

Best regards, Julian

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Fri, 06 Jun 2014 07:42:38 -0700

altogether.

I think DOIs provide enough value to enough of the community that this
requirement, while annoying, should not be considered a show stopper to
the project.

- -Heather

---

From: "Scott O. Bradner" <[email-masked]>
Date: Fri, 6 Jun 2014 10:50:31 -0400

adding a DOI field to the citation format used in RFCs should not be a big deal

it is a bigger deal to be sure that an author knows when a referenced document has a DOI and
is able to find that out so that it can be included

but, that said, I agree that the value to the reader makes the effort worthwhile

Scott

On Jun 6, 2014, at 10:42 AM, Heather Flanagan (RFC Series Editor) <[email-masked]> wrote:

> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQEcBAEBAgAGBQJTkdNeAAoJEER/xjINbZoGE58H/A3cyuVuf9yZHrIOWQOMgluM
> NP2J1POlW90OceGZXamGR7J/alY/I6iWUBMsjZNNxK6m+aHNf1KpvgJTfQL9K7Yn
> an1N6Cm+eUXydJCwQlZdtdix0UGW9DCxUt+ZRp+kUzXUqb0C75Czr6/TuDbVRh30
> UeRe7jUo9RcFV/8p5Dmfly1lWlVmS4LUQCF5yry9RaHVUZiHZFs2T4h2miTFX4WJ
> RLcwcI4Nt1Nx49hVn5MPBh2zuc9eg6gJw/Q0sFKPyaePPHdQgVRBFDhio8ydiSnJ
> u7OMi9jhjZqez+t7KkBQJtyhER4t6gnQwPWF3dJKAU8ZyzyUKo6+IcnpTPGUk50=
> =EdRZ
> -----END PGP SIGNATURE-----
> 
> _______________________________________________

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Tue, 10 Jun 2014 13:11:34 -0700

>
> Heather, could you confirm my assumption that we will be registering
> all our RFCs (whether they are standards track or not) as "standards"
> using the grammar at

Given the options available to us, yes we should use "standards".  (The
other option, which I don't think is particularly helpful, is to use
"report-paper" for anything not a Draft, Proposed, or Internet Standard.)

-Heather

---

From: Tony Hansen <[email-masked]>
Date: Tue, 10 Jun 2014 16:21:05 -0400

> "report-paper" for anything not a Draft, Proposed, or Internet Standard.)

This opens up a can of worms. :-(

     Tony Hansen

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Tue, 10 Jun 2014 13:39:40 -0700

On 6/10/14, 1:21 PM, Tony Hansen wrote:
>>> <http://www.crossref.org/schema/documentation/4.3.0/4_3_0.html#standard>
>>>
>>> ?

No, it just doesn't help the can of worms we already have from being
straightened out.  FWIW, our options are very limited:

* Journals
* Books
* Conference proceedings
* Components
* Dissertations and thesis
* Reports and working-papers
* Standards
* Database
(see <http://help.crossref.org/#deposits> for the definitions>)

I don't like it, but I don't see a way around it.  I don't think this is
a showstopper to using DOIs.

-Heather

---

From: Pete Resnick <[email-masked]>
Date: Fri, 13 Jun 2014 12:40:05 -0500

Someone needs to shoot me for poking my nose into something I should not 
be anywhere near, but it's Friday and I've lost the will to live:

Why don't use use "Reports and working-papers" for everything except 
standards track documents and use "Standards" for...you know....standards?

pr

On 6/10/14 3:39 PM, Heather Flanagan (RFC Series Editor) wrote:
> (see<http://help.crossref.org/#deposits>  for the definitions>)
>

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Fri, 13 Jun 2014 10:49:07 -0700

On 6/13/14, 10:40 AM, Pete Resnick wrote:
> Someone needs to shoot me for poking my nose into something I should
> not be anywhere near, but it's Friday and I've lost the will to live:

Careful, now.  With that attitude, I might start bringing you into the
format work. ;-)

> standards track documents and use "Standards" for...you know....standards?

When we (where "we" = Sandy, Alice, John L, and I) talked about this a
few months ago, the consensus was that the overall value of splitting
out the batches into "standards" and "report-papers" was not worth the
additional complexity, given the assumption that people weren't going to
go to this metadata field to answer the question "is this a standard or
not?"

I don't feel particularly strongly about this, so if others agree that a
split for "standards" (which I assume means Draft, Proposed, and
Internet) and everything else makes more sense, we can put that in the SoW.

-Heather

---

From: Robert Sparks <[email-masked]>
Date: Fri, 13 Jun 2014 13:13:07 -0500

> Internet) and everything else makes more sense, we can put that in the SoW.
Where would you put BCPs?

---

From: "Scott O. Bradner" <[email-masked]>
Date: Fri, 13 Jun 2014 14:15:28 -0400

BCP are defined (in 2026) as standards

Scott

---

From: Russ Housley <[email-masked]>
Date: Fri, 13 Jun 2014 14:21:57 -0400

> Internet) and everything else makes more sense, we can put that in the SoW.

That reasoning concerns me.  It contributes to a misunderstanding of the difference between standards-track, informational, and experimental.

I'm not sure where to put BCPs, but I generally agree with Pete's observation.

Russ

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Fri, 13 Jun 2014 11:44:41 -0700

> That reasoning concerns me.  It contributes to a misunderstanding of the difference between standards-track, informational, and experimental.

Fair enough.  Then we will modify the SoW and the DOI I-D to note that
Draft, Proposed, and Internet Standards as well as BCPs will be in
"standards" and all else will be in "reports-papers".

-Heather

---

From: Tony Hansen <[email-masked]>
Date: Fri, 13 Jun 2014 14:45:02 -0400

> I'm not sure where to put BCPs, but I generally agree with Pete's observation.

I would mark all of experimental standards, draft standards, proposed 
standards, full standards, internet standards and BCPs as DOI 
"standards". Everything else would be marked as "reports & working-papers".

     Tony Hansen

---

From: Robert Sparks <[email-masked]>
Date: Tue, 17 Jun 2014 15:18:19 -0500

Trying to capture this in the SoW. One point to watch for in the next 
version.
Experimental is not standards-track per 2026. The next draft will put 
experimental in to reports and papers.

On 6/13/14, 1:45 PM, Tony Hansen wrote:
>> That reasoning concerns me.  It contributes to a misunderstanding of 
>> the difference between standards-track, informational, and experimental.
>>

---

From: "Scott O. Bradner" <[email-masked]>
Date: Tue, 17 Jun 2014 17:10:39 -0400

experimental docs could become standard track but not many do

and the independent steam can publish experimental RFCs 

imo - experimental RFCs should not be tagged standards but I do not feel too strongly about it

but if experimental RFCs are so tagged then it would make sense that any info RFC
that deals directly with standard activity (e.g. requirements RFCs) should also get 
tagged as standards

Scott

On Jun 17, 2014, at 4:18 PM, Robert Sparks <[email-masked]> wrote:

> Trying to capture this in the SoW. One point to watch for in the next version.
> Experimental is not standards-track per 2026. The next draft will put experimental in to reports and papers.
> 
>> I would mark all of experimental standards, draft standards, proposed standards, full standards, internet standards and BCPs as DOI "standards". Everything else would be marked as "reports & working-papers".
>> 
>>    Tony Hansen
>>

---

From: Bob Hinden <[email-masked]>
Date: Tue, 17 Jun 2014 14:21:53 -0700

Reading this discussion, I am starting to think that the initial recommendation is right, that is, only use one category.  Our documents are clearly marked as to their status (standards, experimental, etc.), the DOI only needs to indicate that they are all RFCs.  So IMHO "Reports and working-papers" is fine.  Anything more is indicated in the document.  The DOI is not intended to replace our own status.

Bob

---

From: Alice Russo <[email-masked]>
Date: Tue, 17 Jun 2014 17:34:05 -0400

+1. I had a similar rationale & conclusion when discussing this w/ Heather & John L. awhile ago.

Thanks,
Alice

---

From: Tony Hansen <[email-masked]>
Date: Tue, 17 Jun 2014 22:24:11 -0400

The initial recommendation was to use the single category of "standards".

Changing that to using the single category of "reports and 
working-papers" is an interesting counter proposal.

     Tony Hansen