Re: [secdir] SECDIR review of draft-ietf-appsawg-multipart-form-data-08

[Larry Masinter <[e-mail]>]

On 4/1/15, 10:14 AM, "Chris Lonvick" <[e-mail]<mailto:[e-mail]>> wrote:
> I would suggest placing the last paragraph of the Security Considerations section at the top of the section. That paragraph seems to be the most comprehensive in these considerations, and the other paragraphs seem to augment and give specific details. It just seems to me that it would provide a better flow to reading that section.

I tried it and it didn’t flow any better.  I’d make the edit if I felt it made a difference but I don’t think it helps.


Also, I'm just not sure that I'm following the second paragraph of
Appendix B:
   More problematic is the ambiguity introduced because implementations
   did not follow [RFC2388<https://tools.ietf.org/html/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.
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.

This is also editorial, as to who is at fault.  if the spec says “you can use method A for situation S” and
implementor says “didn’t say MUST, so I’ll use method B instead”, do you blame the spec writer or
the implementor.  I'd implementors to read IETF RFCs with engineering common sense and not play
legalistic games around normative terms. So I’lm going to stick with my language.


Finally, I usually advocate giving directions to implementers about what to do if they find implementations using the older, outdated spec. As an example, what should a receiver do if it gets a ContentType that does not have a "boundary" parameter? However, as I'm not really familiar with this technology, and as the document says there are many ways to do all of this, then I'm not sure that could or should be discussed. If it is something that would better define behavior then I would suggest providing some guidance here.

the boundary parameter is used in all multipart types, which are widespread in the Internet. The
common understanding of multipart is why we picked it for framing form-data, even though it’s
ugly and the probabilistic boundary generation drives lots of people crazy. So this kind of stuff that
is inherited from MIME doesn’t need discussing.

The main reason this update was even necessary is because that advantage wasn’t as great any more,
and thus the divergences from other multipart types.

Larry
—
http://larry.masinter.net