> Thanks for the answer. It helps indeed. It would help better if this is > documented with one paragraph in the text of the document. While developers > know well the details, users and operators may be less familiar with these. I'm going to push back on this a bit. It's effectively axiomatic that in order to understand a protocol extension you first need to understand the protocol and it's extension mechanism. Having every extension reiterate a subset of how the extension mechanism works seems pointless at best and more likely counterproductive - covering only a subset of the mechanism, which is all you're be able to do without repeating a significant amount of RFC 5228 will give the (incorrect) impression that it's all you need to know. Now, it would be one thing if there was a section in RFC 5228 that describes the extension mechanism - if that were the case we could just reference it. But for better or worse RFC 5228 isn't constructed that way. Perhaps more than any other protocol, Sieve is designed to be extended easily, and the discussion of how that works appears throughout the document. Finally, if we're going to talk about implementation and use issues in regards to this extension - and I'm not saying we should - such text would be better spent on discussing the interplay between this extension and where sieves are evaluated. Ned
