The introduction references the last paragraph of the security
considerations, but as far as I can see that paragraph doesn't have
anything to do with security and I think it would make more sense to
include this text in the introduction...
Finally, users of any auto-reply mechanism should really think about
whether automatic replies are necessary, and at what interval they
make sense when they are. Email is not Instant Messaging, and
senders generally expect that replies might take a while. Consider
whether it's truly important to tell people that you'll read their
mail in an hour or so, or whether that can just be taken as how email
works. There are times when this makes sense, but let's not use it
to exacerbate information overload.
Works for me.
And for me as well. I've made the change in my working copy.
This document normatively references several other I-Ds. Does the WG
have any concerns that the referenced I-Ds will change materially? It
seems perhaps safer to advance the referenced I-Ds first, just in case.
The document references 3 other drafts. One of them is still being worked on
(Sieve external list), the other 2 are already in IESG review.
So far the proposed changes to Seive external list don't invalidate
examples.
The only relevant change I foresee in external-list is the use of a
"pab" URI scheme. The autoreply doc will wait in the RFC-ed queue for
external-list anyway, and if we decide to change one of the examples
to use "pab:default", say, we can do that during AUTH48. It won't
change the substance of the autoreply doc, in any case.
Barry
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve