There's also a fair argument for making the reference to LMTP
informative. It's certainly not necessary (and if I understand
correctly, not common) to implement LMTP in order to implement SIEVE;
it's not even necessary to read RFC2033.
The informational nature of this reference could be made more obvious
in the text if we like. E.g. in the first instance:
1. Refuse message delivery by sending a 5XX response code over SMTP
[SMTP]. Optionally, if LMTP [LMTP] is used, refuse message
delivery by
sending a 5XX response code over LMTP. See Section 2.1.1 for more
details.
We could also gather the references to LMTP into one section.
But yes, if the main text stays like it is, the variance has to be
requested in IETF Last Call -- don't let your AD forget to do that ;)
Lisa
On Feb 13, 2008, at 12:04 PM, Aaron Stone wrote:
On Feb 13, 2008, at 10:40 AM, Alexey Melnikov wrote:
Ned Freed wrote:
First, a process issue: This document references RFC 2033 (LMTP)
normatively. I
have no problem with this but I don't believe the rules allow us
to have a
normative reference to a informational protocol specification.
We're going to
have to ask for an exception to be made.
Indeed. I was also thinking about revising LMTP spec to move it to
Standard Track, but it is sufficiently low on my list of IETF
priorities.
At the Vancouver IETF, both Lisa and Chris indicated that it would
be straightforward to get a variance for this. (As I understand, it
requires the IESG to sign off on the variance?)
Aaron