Simon Josefsson wrote:
Cyrus Daboo <[EMAIL PROTECTED]> writes:I would like to remind people that my draft is not intended as a standard track document, it only tries to establish a convention.
The draft suggests a new convention for transient IMAP capabilities,
which should be used until the document describing 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.
In this particular case, no matter how many MUSTs you put, I don't think people would listen. This also made me think that it might be better not to declare the final capability name until a particular extension is published as an RFC...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.
This is valid point. But see also my comment below.
An advantage of using the formal procedure established in draft-melnikov-imap-transitional-capa-00 is that it is sufficient for an implementor to know 2 things to construct a required capability name: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.
1). Base capability name.
2). Name of the draft.
The second part is also important for another reason. Let's say I see a capability name "X-ANNOTATEMORE-05". How do I know which draft revision has defined it? Without searching for the string in all revisions of the draft (and one might not have them at hand), this might be a bit problematic. So to some extent the draft is trying to address lack of a registry for transient capabilities.
Another advantage is that an implementation (server or client) aware of the convention is now able to support a range of revisions of the same extension:
capability strings for all revisions of the same extension start with "X-DRAFT-" prefix and end with "base capability name". To some extent this addresses the issue that Simon has raised.
(And you know what, I was actually thinking about adding code to my IMAP server that can list additional capabilities by specifying them in a configuration file. Maybe it is a hack ;-), but it is really not that difficult to do.)
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.
At least we have an agreement on this part.
Regards, Simon
(With apologies if I misunderstood
draft-melnikov-imap-transitional-capa-00, I haven't read it in
detail.)
Alexey
