Hi, Alexey,
That would be great - and thanks for continuing to think about my comments.
Spencer
----- Original Message -----
From: "Alexey Melnikov" <alexey(_dot_)melnikov(_at_)isode(_dot_)com>
To: "Spencer Dawkins" <spencer(_at_)wonderhamster(_dot_)org>
Cc: <ietf(_at_)ietf(_dot_)org>; "General Area Review Team" <gen-art(_at_)ietf(_dot_)org>; "Lisa
Dusseault" <lisa(_at_)osafoundation(_dot_)org>
Sent: Tuesday, January 20, 2009 6:17 AM
Subject: Re: Gen-ART review of draft-melnikov-sieve-imapext-metadata-08
Spencer Dawkins wrote:
Hi, Alexey,
Hi Spencer,
Thanks for the quick response back... now I can remember what I said in
the review ;-)
Spencer
Spencer Dawkins wrote:
[...]
5. Security Considerations
Extensions defined in this document deliberately don't provide a way
to modify annotations.
Spencer: The next two paragraphs punt to "same as sieve script" - could
you
provide a specific reference for the reader here?
Reference to the Sieve document?
If that's where the security considerations for sieve scripts are
located - that would be fine.
After thinking more about this: RFC 5228 (Sieve base) doesn't describe how
Sieve scripts are stored and how to handle failure to retrieve them - this
is out of scope for both documents. However I can add an example of what I
meant here - if a Sieve script is stored in LDAP and the script can't be
retrieved when a message is processed, then the agent performing Sieve
processing can, for example, assume that the script doesn't exist, or
delay message delivery until the script can be retrieved successfully.
Annotations should be treated as if they are a part of the script itself,
so a temporary failure to retrieve them should be handled in the same way
as a temporary failure to retrieve the Sieve script itself.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf