Reference RFC 7578 instead of RFC 2388

RFC 2388 has been obsoleted by RFC 7578.
Fixes whatwg#398

* Remove note about non-usage of multipart/mixed, since the new RFC no longer recommends it either:
  > § 4.3. Multiple Files for One Form Field
  > [...] [RFC2388] suggested that multiple files for a single form field be
  > transmitted using a nested "multipart/mixed" part.  This usage is
  > deprecated.
* Remove remark about field names not using RFC 2047's 7-bit-safe "encoded-word" encoding method,
  since the new RFC no longer recommends it:
  > § 5.1. Non-ASCII Field Names and Values
  > [...] While [RFC2388] suggested that non-ASCII field names be encoded according
  > to the method in [RFC2047], this practice doesn't seem to have been
  > followed widely.
* Remove requirement about not using RFC 2231 encoding for filenames, since the new RFC
  no longer recommends that encoding.

source

@@ -55507,33 +55507,25 @@ fur
 
    <li>
 
-    <p>Encode the (now mutated) <var>form data set</var> using the rules described by RFC 2388,
+    <p>Encode the (now mutated) <var>form data set</var> using the rules described by RFC 7578,
     <cite>Returning Values from Forms: <code data-x="">multipart/form-data</code></cite>, and return
-    the resulting byte stream. <ref spec=RFC2388></p>
+    the resulting byte stream. <ref spec=RFC7578></p>
 
     <p>Each entry in the <var>form data set</var> is a <i>field</i>, the name of the entry is the
     <i>field name</i> and the value of the entry is the <i>field value</i>.</p>
 
     <p>The order of parts must be the same as the order of fields in the <var>form data set</var>.
     Multiple entries with the same name must be treated as distinct fields.</p>
 
-    <p class="note">In particular, this means that multiple files submitted as part of a single
-    <code data-x="">&lt;input&nbsp;type=file&nbsp;multiple></code> element will result in each file
-    having its own field; the "sets of files" feature ("<code>multipart/mixed</code>") of RFC 2388
-    is not used.</p>
-
     <p>The parts of the generated <code>multipart/form-data</code> resource that correspond to
     non-file fields must not have a <code>Content-Type</code> header specified. Their names and
-    values must be encoded using the character encoding selected above (field names in particular do
-    not get converted to a 7-bit safe encoding as suggested in RFC 2388).</p>
+    values must be encoded using the character encoding selected above.</p>
 
     <p>File names included in the generated <code>multipart/form-data</code> resource (as part of
     file fields) must use the character encoding selected above, though the precise name may be
     approximated if necessary (e.g. newlines could be removed from file names, quotes could be
     changed to "%22", and characters not expressible in the selected character encoding could be
-    replaced by other characters). User agents must not use the RFC 2231 encoding suggested by RFC
-    2388.</p> <!-- this isn't a willful violation since 2388 doesn't make it a requirement, it just
-    vaguely suggests it -->
+    replaced by other characters).
 
     <p>The boundary used by the user agent in generating the return value of this algorithm is the
     <dfn><code>multipart/form-data</code> boundary string</dfn>. (This value is used to generate the
@@ -55545,8 +55537,8 @@ fur
 
   </div>
 
-  <p>For details on how to interpret <code>multipart/form-data</code> payloads, see RFC 2388. <ref
-  spec=RFC2388></p>
+  <p>For details on how to interpret <code>multipart/form-data</code> payloads, see RFC 7578. <ref
+  spec=RFC7578></p>
 
 
 
@@ -115574,7 +115566,7 @@ INSERT INTERFACES HERE
    <dd>SVG images <ref spec=JPEG></dd>
 
    <dt><dfn><code>multipart/form-data</code></dfn></dt>
-   <dd>Form submission <ref spec='RFC2388'></dd>
+   <dd>Form submission <ref spec='RFC7578'></dd>
 
    <dt><dfn><code>multipart/mixed</code></dfn></dt>
    <dd>Generic mixed content <ref spec=RFC2046 /></dd>
@@ -115968,9 +115960,6 @@ INSERT INTERFACES HERE
    <dt id="refsRFC2318">[RFC2318]</dt>
    <dd><cite><a href="https://tools.ietf.org/html/rfc2318">The text/css Media Type</a></cite>, H. Lie, B. Bos, C. Lilley. IETF.</dd>
 
-   <dt id="refsRFC2388">[RFC2388]</dt>
-   <dd><cite><a href="https://tools.ietf.org/html/rfc2388">Returning Values from Forms: multipart/form-data</a></cite>, L. Masinter. IETF.</dd>
-
    <dt id="refsRFC2397">[RFC2397]</dt>
    <dd><cite><a href="https://tools.ietf.org/html/rfc2397">The "data" URL scheme</a></cite>, L. Masinter. IETF.</dd>
 
@@ -116019,6 +116008,9 @@ INSERT INTERFACES HERE
    <dt id="refsRFC7303">[RFC7303]</dt>
    <dd><cite><a href="https://tools.ietf.org/html/rfc7303">XML Media Types</a></cite>, H. Thompson, C. Lilley. IETF.</dd>
 
+   <dt id="refsRFC7578">[RFC7578]</dt>
+   <dd><cite><a href="https://tools.ietf.org/html/rfc7578">Returning Values from Forms: multipart/form-data</a></cite>, L. Masinter. IETF.</dd>
+
    <dt id="refsSCSU">[SCSU]</dt>
    <dd>(Non-normative) <cite><a href="http://www.unicode.org/reports/tr6/">UTR #6: A Standard Compression Scheme For Unicode</a></cite>, M. Wolf, K. Whistler, C. Wicksteed, M. Davis, A. Freytag, M. Scherer. Unicode Consortium.</dd>