> On Wed, 29 May 2002 00:34:21 -0700 (PDT), [EMAIL PROTECTED] wrote:
> > The IESG has reviewed draft-crispin-imapv-16.txt and has found a number
> > of issues that need to be addressed before the document can be approved
> > as a proposed standard:
> > (1) The AUTHENTICATE command -- which is recommended -- may fail
> > in practice because no mandatory-to-implement SASL mechanism is
> > specified. A mandatory-to-implement mechanism needs to be
> > specified to insure interoperability can be achieved.
> I agree with Alexey Melnikov that a mandatory to implement SASL mechanism is a
> moving target. There is currently no such thing in IMAP or, for that matter,
> in SASL. That's the way the SASL people designed it.
SASL is a generic facility used in multiple protocols. As such, it doesn't make
sense to have a mandatory to implement mechanism in SASL.
A specific protocol is another matter. The IESG's belief is that specific
protocols need to have one or more mandatory to implement SASL mechanisms.
> Furthermore, there are cases in which *no* offered mechanism is desirable.
> For example, a system which only has plaintext based authentication may choose
> to permit no authentication until after STARTTLS is negotiated.
Mandatory to implement doesn't mean mandatory to use. Just because you have to
implement something to be compliant does not mean all setups must make that
option available.
Similar arguments were made in the LDAP case, BTW. They did not fly.
> Do you still want anything done in the IMAP specification on this matter?
It is absolutely not a question of what I want. Had I wanted a mandatory to
implement SASL mechanism you would have heard that from me before I ever
approved the IETF-wide last call for this specification. So while as a matter
of policy I don't talk about who on the IESG is pushing a particular point, you
can take it as given that this isn't coming from me. I'm simply reporting what
the IESG has said about this.
Now, if the group decides to push back against the IESG's position, I will take
whatever justification for this position the group comes up with back to the
IESG and see what they say. However, I have to say that I think the chances
of the IESG changing their position on this are practically nonexistant.
[I'll deal with the points of clarification in another message]
> > (6) For sections--
> >
> > > 6.2.1. AUTHENTICATE Command
> >
> > and
> >
> > > 6.2.2. LOGIN Command
> >
> > some discussion of methods to limit the number of auth/login attempts
> > allowed and/or other mechanisms to discourage name/password
> > hacking (e.g. exponentially delay the server reply for failed attempts)
> > might be appropriate.
> I agree with Arnt Gulbrandsen, Barry Leiba, and Andreas Aardel Hanssen that
> this belongs in a separate BCP document, since it affects many protocols other
> than IMAP.
> Do you still want anything done in the IMAP specification on this matter?
I am willing to argue that this properly belongs in the revised SASL
specification, but it would help to have some degree of acceptance on the
SASL side as part of this.
> > (7) The references in this document should be split between normative and
> > informative.
> This is a strange requirement. I see many other examples of recently approved
> documents (e.g RFC 2821) which do not have such a split. I fail to see the
> benefit. Furthermore, a split between "normative" and "informative" can be
> extremely subjective with several of these documents.
The rationale here as I understand it is that this makes it easier during
standards advancement to figure out what the real dependencies are. But
regardless of whether or not you believe this is useful or strance or whatever,
having such a split is a recent requirement imposed by the RFC Editor and
approved by the IESG. As such, I believe this one is nonnegotiable.
Ned
