Subject: [apps-discuss] Kathleen Moriarty's No Objection on draft-ietf-appsawg-multipart-form-data-08: (with COMMENT)

From: "Kathleen Moriarty" <[email-masked]>
Date: Mon, 06 Apr 2015 15:20:58 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-appsawg-multipart-form-data-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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!