Let me try to write a brief comment on this, mostly skipping over points that several others have made... If we could confine those who read or reference I-Ds to active participants in the IETF who would know to check the status, I think this proposal would work. Even then, I'm not completely convinced anything is broken. That is, in part, because we know enough to check the datatracker when status is significant. I'd rather see effort go into making status and expiration-related information in the datatracker more clear and precise. My far greater concern is that we already have a problem with people citing or using Internet-Drafts as IETF positions or specifications. Sometimes that is done maliciously or as a deliberate misrepresentation. Sometimes, probably more often, it is the result of ignorance or carelessness. The draft even mentions an archive of I-Ds, further raising the question of how they are different from RFFCs. The "Status of This Memo" boilerplate does not help much: it may provide ussome legal coverage, but it is clearly boilerplate and there is a long history of people not reading such stuff especially if it is more than a sentence or two long. So. unless we want to create confusion between permanent, carefully reviewed (even if by different processes in different streams) RFCs, we keep expiration dates and carefully avoid terms like "published", favoring "posted" instead. Is an expiration date a perfect solution for documents that may be download and kept for future use? Of course not, but it conveys a useful and important hint. Assuming instead that a reader will know that they have to look elsewhere to find status is profoundly unrealistic. So, if were are convinced there is a problem that needs solving (like many others, I have not been convinced yet, I suggest considering two options, neither of which is really new: (1) Fix the boilerplace among the lines that Scott and Brian recommend, being careful about "work in progress" without qualifying language _and_provide text near that "Expires" field in the header that says something like "up-t0-date status information available at [URL) (or providing that information in the boilerplate but explicitly pointing to it from the header.. It seems to me that would address the alleged problem. or (2) Let's see if we can figure out a way that would turn into something more like what some comments in these threads seem to assume, e.g., document that are not available from an "archive" except for, e.g., legal proposes with a court order but that can be retrieved only online and in real time, with a 24 hour expiration and an explicit pointer to the datatracker for the next up to date version. If that process retrieves the same document for years, so it goes: after all, if it doesn't expire until the datatracker says it does, that is the practical effect. But if the IETF (and the other streams) and documents needs to have a collection of documents that are community-approved and that don't expire, that are posted rather than passed though a formal publication process, and are not treated as works in progress even on the day they are posted (much less years later when there is not active interest in them), ... we have RFCs for that and the distinction should be important enough to us to keep I-Ds as second-class, "anyone can post without any review proceses", expiring options. john
