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