draft-masinter-dated-uri-00.txt only has 8 versions but was produced as a response. It's useful to have a stable reference to the concepts -- so I and others can cite it. But more of a thought experiment than a technical proposal that I care that people implement one way or another. * Anything you can describe, you can have a URL for! * No, it isn't hard to give everyone permanent unique IDs by adding a short date to temporarily unique IDs. * No other distinguishing metadata is as good as a date. Why bother the RFC editor? If there is some kind of abuse you are aiming to quell, some examples might be helpful. -- https://LarryMasinter.net https://interlisp.org > -----Original Message----- > From: ietf <ietf-bounces@xxxxxxxx> On Behalf Of John C Klensin > Sent: Wednesday, January 12, 2022 3:11 PM > To: Scott O. Bradner <sob@xxxxxxxxx>; Mike StJohns > <mstjohns@xxxxxxxxxxx>; Fred Baker <fredbaker.ietf@xxxxxxxxx> > Cc: John Kunze <jakkbl@xxxxxxxxx>; ietf@xxxxxxxx > Subject: Re: Backdoor standards? > > Mike, > > First, to what Scott and Fred said, yes. > > Prior to when we made them readily available after the nominal six months, > they were still available to anyone who showed up with a subpoena or, IIR, a > small wad of cash to cover presumed Secretariat expenses to dig them out, > but my recollection (which Scott can probably confirm and recalibrate) is that > just became too much trouble... for us and the Secretariat, not (just) the > lawyers. > > Partially for the reasons you identify (which may not apply to this draft -- see > below) I've wondered whether we could make drafts moderately easy for > the lawyers to identify and find but destabilize URLs pointing to them. For > example, instead of having expired drafts with stable URLs, we could move > them to this-year.datatracker.ietf.org, then move then again to last- > year.datatracker.ietf.org, and so on, maybe making them still possible to find > via the Data Tracker, but making stable references to the URLs impossible > and getting to them a bit difficult or annoying, but not terribly so. Or, as a > different example, we could get rid of the equivalent to a stable > https://datatracker.ietf.org/doc/draft-whatever-whateverElse/ > and, after six months, change the file names to draft-screech-whatever and > set the tracker up so that, instead of supplying a clickable-URL, we simply > supplied the equivalent of "screech-whatever" as text and made people > copy that string and paste it in somewhere. The obvious question is whether > the tooling to support such a scheme would be worth the trouble. > My impression is that, in the past, the answer has been "no" > but, as we review and rewrite various tools, that decision may be worth > reviewing. > > That said, this document, however evolved, may be a poor example of your > concern. We do so say (see the first paragraph of > https://www.ietf.org/standards/ids/ ) "Other groups may also distribute > working documents as Internet-Drafts." so we are explicitly authorizing the > behavior with which you are concerned. And John Kunze (copied) is a long- > time and very constructive IETF participant -- see RFCs including 1625, 1736, > 2056, 2413, 2731, 5013, 5791, 8493, and 8574 -- who perfectly > well knows what the rules are. If I had to make a somewhat > educated guess (I hope he will confirm or correct as needed), what is going > on is exactly what the Abstract says is going on, i.e., that this is a gradually > developing and evolving spec in a different group (remember, we said such > groups could use I-Ds for that purpose), that it is valuable to both them and > us to have the IETF community be aware of the work, and, I hope that, when > it is stable, they will either bring it to us for standardization or bring a stable > and approved version to the IETF or ISE for informational publication as a > standard from another SDO. > > The ARK Identifier scheme is another variation on the idea, mentioned in RFC > 3986, of document identifiers/ names rather than locators. I think or at least > hope, that we gave up on the "one name system to rule them all" theme. > More familiar variations on that theme (with different design assumptions > and success criteria) are URNs (RFC 8141) and DOIs. > > John (Kunze), anything to add? > > best, > john (klensin) > > > > > --On Wednesday, January 12, 2022 13:24 -0800 Fred Baker > <fredbaker.ietf@xxxxxxxxx> wrote: > > > The primary reason that drafts remain available after six months is, > > I'm told, that lawyers want to be able to look up IPR. I suspect that > > your suggestion, which I otherwise support, would run afoul of that. > > What might be good would be to describe a mechanism that would allow > > the draft to vanish in six months but somehow remain available to an > > IPR search. > > > --On Wednesday, January 12, 2022 16:20 -0500 "Scott O. Bradner" > <sob@xxxxxxxxx> wrote: > > > leave it be > > > > having the old versions accessible is very useful for IPR disputes > > > > and I'm not sure we could write a ruleset that said no 3rd party > > standards repository that would not impact our own work > > > > Scott > > > >> On Jan 12, 2022, at 4:12 PM, Michael StJohns <mstjohns@xxxxxxxxxxx> > >> wrote: > >> > >> Hi - > >> I got curious when I saw a draft being published with a version > >> number of -33 - > >> https://datatracker.ietf.org/doc/html/draft-kunze-ark-33. I got even > >> more curious when I noticed that -00 of that ID had been uploaded > >> back in 2001. So I read the intro in the -33 version and found this: > >> > >> > >> > >>> This is a transitional draft. The ARK Alliance Technical Working > >>> Group ( https://wiki.lyrasis > >>> .org/display/ARKs/Technical+Working+Group) > >>> is in the process of revising the ARK spec via a series > >>> of Internet- Drafts. While the spec is in transition, > >>> new implementors should follow > >>> https://datatracker.ietf.org/doc/html/draft-kunze-ark-18. > >> > >> -18 having been uploaded in 2013. > >> I'm not sure there's anything that can or should be done, but IDs are > >> supposed to be transient documents that either go away or lead to an > >> RFC. Looking at the update history for this document, I'm pretty > >> sure the draft system has been co-opted to be a standards repository > >> for this specification. > >> AFAICT, this draft has never been submitted - in 20 years! - to any > >> RFC stream for publication and that's at least a violation of the > >> spirit of the ID system. I.e. a violation > >> of: > >> > >> > >>> It is inappropriate to use Internet-Drafts as reference > >>> material or to cite them other than as "work in progress. > >>> > >> > >> Perhaps we may want to think about making URL references to previous > >> (or long expired) versions quite a bit less stable to avoid gaming of > >> the system like this? Or prohibit updates of draft chains once a > >> draft has been expired for a year? > >> > >> Or leave it be? > >> > >> Mike > >> > >> > >> > >> > > >
