Enum imap_types::response::data::BodyStructure

pub enum BodyStructure<'a> {
    Single {
        body: Body<'a>,
        extension: Option<SinglePartExtensionData<'a>>,
    },
    Multi {
        bodies: Vec<BodyStructure<'a>>,
        subtype: IString<'a>,
        extension_data: Option<MultiPartExtensionData<'a>>,
    },
}

Variants

Single

Fields

body: Body<'a>

extension: Option<SinglePartExtensionData<'a>>

Extension data

Extension data is never returned with the BODY fetch, but can be returned with a BODYSTRUCTURE fetch. Extension data, if present, MUST be in the defined order.

Any following extension data are not yet defined in this version of the protocol, and would be as described above under multipart extension data.

For example, a simple text message of 48 lines and 2279 octets can have a body structure of:

("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 2279 48)

Multi

Fields

bodies: Vec<BodyStructure<'a>>

subtype: IString<'a>

extension_data: Option<MultiPartExtensionData<'a>>

Multiple parts are indicated by parenthesis nesting. Instead of a body type as the first element of the parenthesized list, there is a sequence of one or more nested body structures. The second (last?!) element of the parenthesized list is the multipart subtype (mixed, digest, parallel, alternative, etc.).

For example, a two part message consisting of a text and a BASE64-encoded text attachment can have a body structure of:

(
    ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)
    ("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff") "<960723163407.20117h@cac.washington.edu>" "Compiler diff" "BASE64" 4554 73)
    "MIXED"
)

Extension data follows the multipart subtype. Extension data is never returned with the BODY fetch, but can be returned with a BODYSTRUCTURE fetch. Extension data, if present, MUST be in the defined order.

See ExtensionMultiPartData.

Any following extension data are not yet defined in this version of the protocol. Such extension data can consist of zero or more NILs, strings, numbers, or potentially nested parenthesized lists of such data. Client implementations that do a BODYSTRUCTURE fetch MUST be prepared to accept such extension data. Server implementations MUST NOT send such extension data until it has been defined by a revision of this protocol.

Example (not in RFC)

Multipart/mixed is represented as follows…

(
    ("text" "html" ("charset" "us-ascii") NIL NIL "7bit" 28 0 NIL NIL NIL NIL)
    ("text" "plain" ("charset" "us-ascii") NIL NIL "7bit" 11 0 NIL NIL NIL NIL)
    "mixed" ("boundary" "xxx") NIL NIL NIL
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            |
            | extension data
)

Trait Implementations

impl<'a> Clone for BodyStructure<'a>

fn clone(&self) -> BodyStructure<'a>

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl<'a> Debug for BodyStructure<'a>

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl<'a> Encode for BodyStructure<'a>

fn encode(&self, writer: &mut impl Write) -> Result<()>

impl<'a> Hash for BodyStructure<'a>

fn hash<__H: Hasher>(&self, state: &mut __H)

Feeds this value into the given Hasher.

fn hash_slice<H>(data: &[Self], state: &mut H) where
    H: Hasher, 

Feeds a slice of this type into the given Hasher.

impl<'a> PartialEq<BodyStructure<'a>> for BodyStructure<'a>

fn eq(&self, other: &BodyStructure<'a>) -> bool

This method tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &BodyStructure<'a>) -> bool

This method tests for !=.

impl<'a> Eq for BodyStructure<'a>

impl<'a> StructuralEq for BodyStructure<'a>

impl<'a> StructuralPartialEq for BodyStructure<'a>