wasm-demo/demo/ermis-f/imap-protocol/cur/1600095023.22648.mbox:2,S

56 lines
2.0 KiB
Plaintext

MBOX-Line: From stephan at rename-it.nl Wed Jan 15 00:26:31 2014
To: imap-protocol@u.washington.edu
From: Stephan Bosch <stephan@rename-it.nl>
Date: Fri Jun 8 12:34:51 2018
Subject: [Imap-protocol] Login referrals resurrection?
In-Reply-To: <FF6E4621-3C20-4C20-AE79-9E62CC9322CC@iki.fi>
References: <FF6E4621-3C20-4C20-AE79-9E62CC9322CC@iki.fi>
Message-ID: <52D64637.5000203@rename-it.nl>
Hi,
On 1/14/2014 10:32 PM, Timo Sirainen wrote:
> Does anyone else think this would be worth maybe writing a new updated RFC2221bis and trying to convince client developers to implement it?
Oh, excellent opportunity to post the following problem with RFC2221
that emerged with the advent of RFC 5092 and RFC 3986 (I keep forgetting
about this). These RFCs updated the IMAP and generic URL scheme
respectively and added the IP-literal syntax element to accommodate for
IP6 addresses:
IP-literal = "[" ( IPv6address / IPvFuture ) "]"
The syntax of REFERRAL is specified in RFC2221, Section 5 and looks as
follows:
resp_text_code =/ "REFERRAL" SPACE <imapurl>
RFC 3501 shows the following for resp_text_code:
resp-text-code = "ALERT" /
"BADCHARSET" [SP "(" astring *(SP astring) ")" ] /
capability-data / "PARSE" /
"PERMANENTFLAGS" SP "("
[flag-perm *(SP flag-perm)] ")" /
"READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
"UIDNEXT" SP nz-number / "UIDVALIDITY" SP nz-number /
"UNSEEN" SP nz-number /
atom [SP 1*<any TEXT-CHAR except "]">]
Obviously, response code arguments cannot contain "]". However, with the
new IP-literal syntax element in the IMAP URL, the REFERRAL argument
could actually contain a "]" now. Clients that know about REFERRAL and
the most recent IMAP URL scheme version could still parse this with some
extra care, but clients that don't will fail to parse this properly.
This isn't easy to fix, since I don't see any means to escape the "]" in
the response code arguments.
Regards,
Stephan.