On Fri, Oct 04, 2019 at 01:55:15PM -0400, Michael StJohns wrote: > On 10/4/2019 12:48 PM, Nico Williams wrote: > > The ITU-T has a much better document naming scheme, and they too have an > > immutability property. Thus ASN.1 is the x.680 document series (x.680, > > x.681, x.682) and the encoding rules for ASN.1 are the x.690 series, > > and each document gets a "version number" in the form of publication > > year and month, and old versions remain accessible and unchanged. > > *laugh* But then you end up with weirdnesses like X.500 vs X.509. I *know* > why the certificate stuff started out in Directory oh so many years ago, but > in hindsight maybe not where it should be today? You could always assign a new series identifier when an old one stops bein relevant to a larger family. And, frankly, though I detest x.400 and x.500 as much as anyone, the series naming is just fine. I couldn't care less that ITU-T's PKI series is x.509 which means it's related to ITU-T's x.500 directory series. (x.509 and PKIX being related to x.500 is why we have the monstrosity of x.500 naming in PKIX, but we're moving past that, and we've done a lot of PKIX work here instead of there.) The point is that series naming is very helpful in reducing the number of things I have to recall in order to find a relevant specification. Organizing knowledge is, in fact, helpful. If I'm looking for some ASN.1 encoding rules spec, I just start by looking for x.690 and go from there. Try that with RFCs -- you'll need a search engine, and the RFC-Editor's search engine is damned near useless, while the I-D tracker is ever so slightly better, but still, nothing like free-text search. Now, maybe we just need to improve those search engines, or outsource the whole thing to general purpose search engines. But because these documents are the sort that can be organized with relatively little effort, doing so seems like no-brainer. An argument that organizing RFCs this way would be more expensive that one might think would be an interesting argument. An argument that it would be less useful than one might think would also be interesting. That related series might diverge in time is not really an interesting argument, IMO. > Or you end up with something like DNS running out of series numbers > and others requiring a series for a single document. ITU tends to be I wouldn't give lonely RFCs a series number, nor did it follow from what I wrote that I would. > MUCH more formal about which documents and standards they will even > start working on (e.g. a "work plan") before they ever start > allocating numbers. They also *require* a document to reviewed each > period of time and updated - that would be a substantial change to our Not relevant to the series concept. > model. Then you have things like TLS 1.0, 1.1, 1.2 and 1.3 that > share a negotiating strategy and have similar protocols, but might be > hard to characterize as the same protocol in the ISO model meaning. The point is to organize the specs in a meaningful way. For users and implementors, organizing TLS 1.0 through 1.3 as a single versioned series is perfectly reasonable. If at some point we end up wanting a new series for just TLS 1.53, then we could do that too. > If you go into the other direction, you get things like IEEE 802.11 which > depends on 802.1 and has a bunch of sub standards ( *pun intended*) such as > 802.11ac and that collection seems to change each time I go looking. Thus versioning. There has to be some degree of immutability. But also some degree of familiarity where it's useful. > In any event I think it's TANSTAAFL - you pick one approach, you close off > others and each has its own flaws. Not so. You could have a document appear in any of zero, one, or N > 1 series -- whatever's appropriate. > I'm not opposed to having the conversation, but we need to pick something > that works for how we do things, or we need to change how we do standards. > And that's a conversation I'm not sure we're quite yet ready to have. If you laugh at, and discount an idea without considering it in any seriousness, then you're right: you're not ready to have that discussion. Nico --
