rfc9755v3.txt   rfc9755.txt 
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. 1 change blocks. 
2 lines changed or deleted 2 lines changed or added

This html diff was produced by rfcdiff 1.48.