[Sorry for cross-post, please limit your replies to IMAPEXT]

Rob Siemborski wrote:

On Fri, 16 Jul 2004, Arnt Gulbrandsen wrote:

(I'll be happy with either, though. And I wish people would mention it on the list when they freeze a draft by releasing code widely.)

(oh -- Squirrelmail [and I presume pine] have also deployed this on the client side).


The problem is often times the only way to fully vet a draft is to implement and actually use code with it. There are a few significant problems in a number of IMAP extensions that weren't fully implemented by anyone before they became RFCs.

On the other hand, great progress was made on ANNOTATEMORE only after Cyrus implemeted and deployed early drafts of it (and then had to go back and fix it when the syntax was substantially improved after problems were found).

I don't think deployment of code by itself should freeze a draft -- if there are substantial problems with it that appear after deployment, these need to be addressed. That doesn't appear to be the case here.

I wrote a draft that tries to address this problem to some extend: http://www.melnikov.ca/mel/Drafts/draft-melnikov-imap-transitional-capa-00.txt

(I've submitted it before July 12, but I am not sure if it gets published, as I forgot to add IPR disclosure text)

The draft suggests a new convention for transient IMAP capabilities, which should be used until the document discribing an IMAP extension becomes RFC. For example, the transient capability for SASL-IR extension as defined in draft-siemborski-imap-sasl-initial-response-03.txt would be X-DRAFT-I03-SASL-IR, where 03 is the draft revision, "I" stands for individual submission.

Alexey




Reply via email to