As far as I can tell, if the community wants expiry retained (even if
marked differently) then part of the process of removing the origin mark
is to determine what community agreement is for the destination.
Removing it without such a determination seems to assume that the
question of whether expiry is a thing is not a community agreement. It
seems to me that it is very much a community agreement. And abolishing
it without replacing it is going to mislead a lot of people as far as I
can tell.
You assert that this draft only needs to do part of the job. I presume
there is reasoning that I do not follow that leads you to this conclusion.
Yours,
Joel
On 1/25/2024 9:09 PM, Martin Thomson wrote:
On Fri, Jan 26, 2024, at 12:32, Joel Halpern wrote:
Your draft, as I read it, calls for removing the notion of draft
expiry. If you want to move the marking for expiry to the datatracker
and associated metadata, that would not be a "no-expiry" It would be a
"move-expiry" request. If that is what you want, then write that.
In a move, you have an origin and a destination. This is the origin part of that move only.
A draft, which might become RFC, only needs to do the origin part.
This one goes further, based on feedback from the design team, and has some non-normative text that suggests how the datatracker (as the destination for that move) might accept the responsibility for expiration or what-have-you. This doesn't need to be documented in an RFC, because it is then a policy that can be managed through the datatracker change management processes. The draft includes some suggestions to highlight that there are a range of options available, because people were concerned that we hadn't paid sufficient attention to the receiving end.
