Re: [lemonade] Implementing drafts

[Simon Josefsson <[e-mail]>]

Cyrus Daboo <[e-mail]> writes:

>> 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.
>
> While I think this is a good idea, I think we could get by with a less
> formal approach. Specifically it should be left up to individual
> drafts to define the capability string for implementations of that
> specific draft, whilst also indicating what the final (RFC) capability
> string is expected to be.
>
> So for example, the following text (which would be used in the final
> RFC version):
>
> 'The ANNOTATEMORE extension is present in any IMAP4 [RFC3501]
> implementation which returns "ANNOTATEMORE" as one of the supported
> capabilities in the CAPABILITY command response.'
>
> Would become in the preceeding drafts:
>
> 'The ANNOTATEMORE extension is present in any IMAP4 [RFC3501]
> implementation which returns "ANNOTATEMORE" as one of the supported
> capabilities in the CAPABILITY command response. This capability
> string will be used when this draft is published as an
> RFC. Experimental implementations of this draft MUST use the
> capability response "X-ANNOTATEMORE-05", and MUST NOT use the
> capability response "ANNOTATEMORE".'

For what it's worth, I tend to agree with Cyrus.  One practical
problem with draft-melnikov-imap-transitional-capa-00 is that many
drafts undergo mostly editorial changes, sometimes all the way from
version 00 up to, say, 15, without affecting the actual protocol.
Experimental implementations of that same protocol thus might not
interoperate well, hurting preliminary testing of the protocol, which
works against the motivation for the X-DRAFT-* idea.

However, I agree with the motivation for the draft.  Preliminary
testing is important, and often lead to improvements of the drafts.
But I feel recommending IMAP capability document authors to use the
text Cyrus suggested, would be more flexible, and would even simplify
interoperability testing over Alexey's proposal.

Writing down the above recommendations in at least a draft is probably
required, if any IMAP capability authors are ever going to be aware of
them, though.

Regards,
Simon

(With apologies if I misunderstood
draft-melnikov-imap-transitional-capa-00, I haven't read it in
detail.)