--On Saturday, December 24, 2022 20:46 -0500 Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote: > Summary: This draft is currently not suitable for > publication as a standards-track RFC. The authors have > failed to adequately respond to feedback given to earlier > drafts, and this document fails to address identified concerns. > > Specific feedback: > > 1. Section 3 specifies Advice to Message Creators, but nothing > in this document forbids other parties besides message > creators adding an Expires field to a message. > > 2. Nothing in this document forbids parties other than the > recipient from deleting a message based on the Expires field. > Given that earlier versions of this document at least implied > such such deletion could occur, this omission is glaring. > > 3. Section 5 says "A message creator can put any date in an > Expires header field, ..." and then goes on to address > possible harms that could result "Without further knowledge of > the message creator". It completely fails to anticipate > that other agents NOT operated by the message creator, that > handle the message, could also add an Expires header > field. Given that this issue was already raised in Last > Call feedback to earlier versions of this document, this > omission is glaring. > > Recommendations: > > 1. This document should probably be abandoned. Similar > proposals have been informally discussed several times in the > past. The reason that they were never formally considered > for standardization is that nobody could find a reliable > solution to the obvious ways in which this header field could > be misinterpreted or misused. I personally don't see a way > to fix the problems without reliable authentication. It's > possible that, if properly used on both originator and > recipient ends, DKIM could be adequate, but the details remain > unspecified. > > 2. Perhaps more importantly, the authors of this proposal have > demonstrated an unwillingness to meet RFC 2026 criteria, and > an unwillingness to build consensus around their proposal. > So if there is continued interest in addressing this > document's problems, new authors should be identified. While mostly agreeing with Keith's analysis, let me add one thing to his feedback list: 4. At least part of the underlying problem here is that there has never been a clear definition of what "Expires" actually means. While I appreciate the consolidation of terminology in -08 onto "loses its validity", it is hard to believe that there is general consensus across the Internet about what it means for a message to be "valid". Realistically, that may depend on the contents of the message itself. Ignoring that complication and even if things are working perfectly and only the originator and recipient are involved, the message originator presumably has some intent about the meaning of the term and the actions to be taken. The recipient then either makes up their own definition or attempts to guess the intent of the originator. "Guess what I meant" has never been a good basis for designing protocols and is one of the things that can lead to the inappropriate deletion issues that are among Keith's concern. The observation that some historical specialized systems did define "Expires" (or some header fields that might be assumed to share semantics with it) in ways that are less fuzzy and appear to be inconsistent adds to that problem. The fact that I haven't seen those uses recently on the public Internet (or that one of the authors has not seen them at all) does not prove they are not still out there. It may just demonstrate that neither of us are part of the right groups or have looked in the right places recently. IMO, that just strengthens Keith's two Recommendations. It may add another possibility to the first of them: without, in any way, reducing the importance of adequate authentication of the originator of the header field, if we are serious about doing something along these lines, it is probably important to allow (require?) that originator to make the intent clear. That could be done with information in the content of the header field in addition to the date-time or by defining a new header field (with a new keyword/name) that incorporates the more precise definition. Finally, while it is probably less important than those above, another issue has been raised and not addressed in the current draft (draft-billon-expires-08). It is related to the inherent ambiguity of future dates and times that are not explicitly defined to be in UTC. For future dates, that ambiguity is not only about the difficulty of inferring whether "+0000" (or, for that matter, "-0000") means "UTC", "a local time zone with a zero offset from UTC", or "just guessing; no time zone information was really available", but about what time zone a particular location will observing at some point in the future. I can think of several fairly easy ways to get around the problem, including being specific about those options and supplying more locale information, suggesting (or requiring) that expirations not be specified to more precision than dates, or clearly identifying the problem as one of concern. Ignoring it entirely does not seem to me to be good enough. thanks, john -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
