su. den 11. 12. 2022 klokka 19.00 (-0500) skreiv John R. Levine: > On Sun, 11 Dec 2022, Barry Leiba via Datatracker wrote: > > Reviewer: Barry Leiba > > Review result: Ready > > > > Thanks for addressing my review comments on version 06. Nothing more to say here: it’s ready to go. > > I did one more tweak and changed the meaning to "loses its validity" to > match what's in RFC 4021 and be clear this really is the same as > the Expires header that was defined in 1998. Yes, RFC 4021 uses the term "validity", but RFC 2156 does not. I don't think it is worthwhile to keep this wording when it makes the header a question of values (pun intended). I agree with Viktor Dukhovni, > The interpretation I would prefer see is "no longer timely or > actionable". It is too late to act on the content of an expired > message (sale over, poll closed, lunch date missed, ...) although I would suggest the shorthand "outdated". Failing that, a full paragraph like what Viktor wrote would not be amiss. >From draft version 8: > 4. Advice to Message Readers > > Message readers, such as mailbox providers, web mail and MUAs could > de-emphasize the display of expired messages or determine not do > display them. They could allow users to control the actions to take > for expired messages.¶ I agree with Keith Moore, "mailbox providers" must be removed from that list. I also agree that the system *default* operation should not be to hide or downgrade such messages, but enabling this could be made very easy for the user, the same way an IMAP client typically has a toggle to show/hide message with \Deleted set. Suggested replacement text: 4. Advice to Message Readers Message readers, such as web mail and MUAs, can provide functionality for users to de-emphasize the display of expired messages or not to display them, or to specify automatic actions for expired messages. (the next paragraph is fine, I include it here for context) > The information provided in the header field is intended to be used as > a signal to provide an improved experience to the end-user. For > instance, systems might allow automatic rules to clean up expired > email from specific message creators or with defined characteristics, > or to provide a mode to quickly handle all expired email.¶ My suggested replacement text is intended to also make clear that "systems might allow automatic rules" only when explicitly enabled by the user. I don't really have a problem with the text in the Security considerations. Perhaps the interaction with DKIM is worth a few words? I do NOT think we should (even) recommend to add the (usually missing) Expires to the list of signed headers, and I do not think the existence of DKIM validation for Expires should be used as input in the handling of a message with the Expires header set, either. So .. perhaps mentioning DKIM will only risk giving someone the wrong idea. Lastly, thanks for bringing up this draft, I think it is useful to have Expires better defined for e-mail. -- venleg helsing, Kjetil T. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
