Unformatted text preview: ntially, and the boundary between the parts is the string NextPart,
preceded by two hyphens at the start of a line.
Each boundary can be followed with a line specifying the header fields for the next part.
Everything in the message before the first boundary is ignored, as is everything following
the final boundary.
Since a blank line follows the first boundary, and not header fields, the content type of the
data between the first and second boundaries is assumed to be text/plain with a
character set of us-ascii. This is a textual description of the new RFC.
The second boundary, however, is followed by header fields. It specifies another
multipart message, with a boundary of OtherAccess. The subtype is
alternative, and two different alternatives are present. The first OtherAccess
alternative is to fetch the RFC using electronic mail, and the second is to fetch it using
anonymous FTP. A MIME user agent would list the two alternatives, allow us to choose
one, and then automatically fetch a copy of the RFC using either mail or anonymous FTP.
To: [email protected]
Subject: RFC1479 on IDPR Protocol
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Fri, 23 Jul 93 12:17:43 PDT
From: "Joyce K. Reynolds" <[email protected]>
the first boundary
A new Request for Comments is now available in online RFC
(details here on the new RFC)
Below is the data which will enable a MIME compliant Mail
Reader implementation to automatically retrieve the ASCII
version of the RFCs.
the second boundary
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
a nested multipart message with a new
server="[email protected]" file:///D|/Documents%20and%20Settings/bigini/Doc...omenet2run/tcpip/tcp-ip-illustrated/smtp_sim.htm (21 of 23) [12/09/2001 14.47.52] Chapter 28. SMTP: Simple Mail Transfer Protocol Content-Type; text...
View Full Document
- Spring '12