Re: [lemonade] Implementing drafts

[Alexey Melnikov <[e-mail]>]

Simon Josefsson wrote:

>Cyrus Daboo <[e-mail]> writes:
>  
>
>>>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.
>>
I would like to remind people that my draft is not intended as a 
standard track document, it only tries to establish a convention.

>> 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".'
>>
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...

>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.

>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.
>
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:
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