My understanding of the working group consensus was "we want it to look as much like RFC9051 as possible", so it's clear that servers MUST NOT send modified UTF-7 once UTF8=ACCEPT has been set. I suspect servers will probably just make their best guess about what the client is doing, as always.
So I have no strong preference either way. I'm not worried about throwing it back to the working group for a couple of weeks, or just accepting that text - either way I expect servers will use the same codepath for IMAP4rev2 for this, so the outcome will be the same either way in the long term. Bron. On Mon, Feb 10, 2025, at 21:34, Arnt Gulbrandsen wrote: > Hi, > > I have reviewed the changes you made; very nice work. Thanks. > > I would like to insert one additional paragraph, to clarify a > nonobvious consequence. In section 7, the second-to-last paragraph > starts with "All IMAP servers that support "UTF8=ACCEPT" SHOULD > accept UTF-8 in mailbox names". Please insert the following > paragraph after that paragraph: > > Note that when mailbox names comply with with the Net-Unicode > Definition ([RFC5198] as described in the previous paragraph, they > cannot any longer comply with the modified UTF-7 convention > described in [RFC3501]. This implies that once UTF8=ACCEPT is > enabled, neither clients nor servers may send mailbox names using > modified UTF-7, they may only send UTF-8. (The same applies when > IMAP4rev2 has been enabled. "A&-B" is an example that shows the > conflict clearly.) > > Arnt > -- Bron Gondwana, CEO, Fastmail Pty Ltd br...@fastmailteam.com
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
