rfc9755v3.txt		rfc9755.txt
	Internet Engineering Task Force (IETF) P. Resnick		Internet Engineering Task Force (IETF) P. Resnick
	Request for Comments: 9755 Episteme		Request for Comments: 9755 Episteme
	Obsoletes: 6855 J. Yao		Obsoletes: 6855 J. Yao
	Category: Standards Track CNNIC		Category: Standards Track CNNIC
	ISSN: 2070-1721 A. Gulbrandsen		ISSN: 2070-1721 A. Gulbrandsen
	ICANN		ICANN
	February 2025		March 2025
	IMAP Support for UTF-8		IMAP Support for UTF-8
	Abstract		Abstract
	This specification extends the Internet Message Access Protocol,		This specification extends the Internet Message Access Protocol,
	specifically IMAP4rev1 (RFC 3501), to support UTF-8 encoded		specifically IMAP4rev1 (RFC 3501), to support UTF-8 encoded
	international characters in user names, mail addresses, and message		international characters in user names, mail addresses, and message
	headers. This specification replaces RFC 6855. This specification		headers. This specification replaces RFC 6855. This specification
	does not extend IMAP4rev2 (RFC 9051), since that protocol includes		does not extend IMAP4rev2 (RFC 9051), since that protocol includes
	skipping to change at line 509 ¶		skipping to change at line 509 ¶
	all).		all).
	For these reasons, it was judged best to revise [RFC6855] and adopt		For these reasons, it was judged best to revise [RFC6855] and adopt
	the same syntax as IMAP4rev2.		the same syntax as IMAP4rev2.
	B.2. FETCH BODYSTRUCTURE		B.2. FETCH BODYSTRUCTURE
	[RFC6532] defines a new media type, message/global, which is		[RFC6532] defines a new media type, message/global, which is
	substantially like message/rfc822 except that the submessage may		substantially like message/rfc822 except that the submessage may
	(also) use the syntax defined in [RFC6532]. [RFC3501] and [RFC9051]		(also) use the syntax defined in [RFC6532]. [RFC3501] and [RFC9051]
	define a FETCH item to return the media type of the body of a		define a FETCH item to return the MIME structure of a message, which
	message, which servers usually compute once and store.		servers usually compute once and store.
	None of the RFCs point out to implementers that IMAP4rev1 and		None of the RFCs point out to implementers that IMAP4rev1 and
	IMAP4rev2 are slightly different, so storing the BODYSTRUCTURE in the		IMAP4rev2 are slightly different, so storing the BODYSTRUCTURE in the
	way servers and clients often do can easily lead to problems.		way servers and clients often do can easily lead to problems.
	This document makes the syntax optional, making it simple for server		This document makes the syntax optional, making it simple for server
	authors to implement this extension correctly. This implies that		authors to implement this extension correctly. This implies that
	clients need to parse and handle both varieties, which they need to		clients need to parse and handle both varieties, which they need to
	do anyway if they want to support both IMAP4rev1 and IMAP4rev2.		do anyway if they want to support both IMAP4rev1 and IMAP4rev2.
End of changes. 2 change blocks.
	3 lines changed or deleted		3 lines changed or added
This html diff was produced by rfcdiff 1.48.