Returning Values from Forms: multipart/form-data
RFC 7578

Note: This ballot was opened for revision 08 and is now closed.

Barry Leiba Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) (was Discuss) No Objection

Comment (2015-04-08 for -09)
No email
send info
Thanks for adding the form-data parameter to the registration update.

I concur with Kathleen's comment to move the last paragraph in the security considerations to the front.

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2015-04-08 for -09)
No email
send info
- abstract: the "(re)defines" is a bit confusing, I'd say just
stick with "defines"

- 4.3, typo "may seems to be present"

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Comment (2015-04-06 for -08)
No email
send info
Please consider moving the last paragraph to the first in the security considerations section.  I agree with the point made by the SecDir reviewer that it improves readability and makes this point clear with reasons before subsequent paragraphs detail it a bit more specifically.
https://www.ietf.org/mail-archive/web/secdir/current/msg05555.html

I also agree with the SecDir reviewer and suggest you reword the following paragraph in Appendix B:
   More problematic is the ambiguity introduced because implementations
   did not follow [RFC2388] because it used "may" instead of "MUST" when
   specifying encoding of field names, and for other unknown reasons, so
   now, parsers need to be more complex for fuzzy matching against the
   possible outputs of various encoding methods.

Perhaps to something like:

   More problematic is the ambiguity introduced because implementations
   of [RFC2388] opted to not follow the specification of encoding field names when the term "may" appeared, where in hindsight it should have been "MUST". As a result,
   parsers need to be more complex for fuzzy matching against the
   possible outputs of various encoding methods.

If I go something wrong, hopefully you get the point and can easily adjust the text.

From the SecDir review:
Please correct me if I'm off base here, but it sounds like the ambiguity
set in because implementations WERE following RFC 2388 by making
choices on their own (due to the "may"s) rather than being directed to
make uniform choices which would have been mandated if that RFC had used
"MUST"s.

Thanks for your work on this draft!

Alvaro Retana No Objection

(Martin Stiemerling) No Objection