Re: Referencing RFC 2088

Alexey Melnikov <[email protected]> Tue, 08 Dec 2015 15:37:23 +0000
Newsgroups gmane.ietf.imapext
Message-ID <[email protected]>
Hi SM,

On 08/12/2015 15:05, S Moonesamy wrote:
> Hi Jay, Naren, Alexey,
>
> Although I did not mention all the working group participants by name, 
> please comment if you have an opinion about this.
>
> At 10:24 07-12-2015, Barry Leiba wrote:
>> -- Section 4 --
>>
>> "Client can avoid use of LITERAL+ [RFC2088], when maximum upload size
>>  supported by the IMAP server is unknown."
>>
>> What?
>> Don't you mean "The client SHOULD avoid"?  I'd even use this as an
>> opportunity to make it firmer, and say "The client MUST avoid". No?
>> If not, why not?
>>
>> And please don't say "LITERAL+"; please say "non-synchronizing
>> literals".  (We should use capability strings only when we're talking
>> about what's in the CAPABILITY response.)
>
> draft-ietf-imapapnd-appendlimit-extension-06 references RFC 2088. 
> Alexey is editing the second draft of the Working Group.  That draft 
> proposes to replace RFC 2088 and obsolete it in a few months (if there 
> is agreement to do that).
>
> The alternatives are:
>
>   (a) Keep the reference to RFC 2088
>
>   (b) Change the reference to draft-ietf-imapapnd-rfc2088bis
>
> If draft-ietf-imapapnd-rfc2088bis does not become an RFC, the 
> reference can be changed back to RFC 2088.  The impact on 
> draft-ietf-imapapnd-appendlimit-extension is that its publication as a 
> RFC will be delayed until draft-ietf-imapapnd-rfc2088bis is published 
> as a RFC.
>
> Which alternative do you prefer?
I slightly prefer to have a reference to draft-ietf-imapapnd-rfc2088bis, 
but if draft-ietf-imapapnd-rfc2088bis takes too long (we can discuss 
what exactly that means ;-)), I would be Ok with switching back to RFC 2088.

Best Regards,
Alexey

_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext