Re: Call for comment: <draft-iab-doi-04.txt> (Assigning Digital Object Identifiers to RFCs)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 7/7/15 10:27 AM, Melinda Shore wrote:
> On 7/6/15 11:36 PM, Eliot Lear wrote:
>> There goes the whistle.  Unsupported assertion while claiming same,
>> Offense.  5 yard penalty.  How about instead pointing out the incorrect
>> statements and test your assertion?
> I assume that this is some sort of sports metaphor?
>
> I've pointed this out several times but the justifications
> presented in the intro are largely false, and if they're
> not false it's because they're hedged.  Statements like
> "organizations that use DOIs can have trouble locating
> documents that don't have DOIs" are true only because of
> the presence of the word "can"; I think you'd be extremely
> hard-pressed to find an organization that can't track down
> a publicly-available document that doesn't have a DOI
> assigned.

That seems like a fair criticism, and at the very least calls for some
justification for that particular sentence.  Thank you for being specific.

>
> There have also been suggestions that since the local part
> of a DOI is opaque its structure doesn't actually matter.
> I would argue that its structure doesn't matter to the
> IDF but should matter to us, much in the same way that
> a protocol that carries an encrypted blob of something
> doesn't care about what's inside that blob but the blob's
> sender and recipients care a very great deal.  That's
> a feature of plain old layering and encapsulation.  At
> this point we have enough experience with naming to be
> reluctant to adopt flat namespaces when avoidable, I think.

Do we have any reason to believe that we will be scaling a DOI to beyond
the use of RFC such that a flat name won't suffice?  Additional
hierarchy comes with its own complexities.

>
> I'm not opposed to putting DOIs on RFCs despite seeing scant
> benefit from doing so.  I am opposed to putting out documents
> that provide justifications that are not actually correct.
>

Fair enough.

Eliot

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]