Name the part; distrust the filename

Each part MUST have Content-Disposition: form-data with a name parameter.

• Content-Disposition is a part header, inside the multipart body. Its form-data disposition and name parameter are both required. The name identifies the original form field; it does not identify or authenticate a person.
• For file contents, a filename SHOULD be supplied when meaningful and available. It is not mandatory when unavailable, meaningless or private. A missing filename is different from a missing required name parameter.
• Content-Type is optional for a part and defaults to text/plain. A file SHOULD use an appropriate media type if known, or application/octet-stream when not known. The label does not establish that the content is safe.
• Receivers must not use a supplied filename blindly or use directory path information. RFC 2183 section 2.3 requires checking local conventions, overwrite risk and security. Application storage and authorization policies are outside this format.
• A filename such as ../notes.txt must not select a parent directory. The example application chooses its own local storage identifier and performs separate content checks. No filesystem write or general filename sanitizer is implemented here.

The missing-name state illustrates a sender-side construction failure, not a new requirement that every receiver emit a particular error. The storage identifier is an explanatory application choice; it is not an RFC wire field or a promise of a complete safe-upload implementation.