Subject: [apps-discuss] AD review of draft-ietf-appsawg-multipart-form-data-07

From: Barry Leiba <[email-masked]>
Date: Fri, 6 Feb 2015 09:34:14 -0500

Larry,
I'm sorry for the huge delay in handling this.  I've given the
document a review, and here are my comments -- most are editorial, but
there are a few that I think we should sort out before I request last
call.

--
Section 1 should have a note for the RFC Editor to remove it at
publication.  Better, just remove it now, yes?

-- Section 3 --

You should include a reference to the definition of URL encoding --
it's called "percent-encoding" in RFC 3986.

Also, that encoding isn't used just for non-ASCII characters, but for
any characters outside the set that can be legally included with ASCII
encoding.  You should rephrase this.

Also also, percent-encoding is not case-sensitive (the characters
don't have to be lower case).  If this differs from what's defined
elsewhere, it should explicitly say so, and why.

-- Section 5.1 --

   Each field's form data of the form is sent, in
   the order defined by the sending application and form, as a part of
   the multipart stream.

Can you re-word this and explain it better?  I find it unclear in a
few ways, the most important of which is that I don't know what "part
of the multipart stream" means.

   The boundary is supplied as a "boundary"
   parameter to the "multipart/form-data type".

The closing quote is misplaced.

-- Section 5.2 --

   with the body of the part corresponding to the form data of the
   "user" field.

"Corresponding to"?  I think "containing" is the right word here.

-- Section 5.3 --

   For form data that represents the content of a file, a name for the
   file SHOULD be supplied as well

Why "SHOULD"?  Why does this affect interoperability, if the other end
can't figure out whether you just didn't feel like including the file
name, or that the file name is meaningless or private?

   NOTE: the method in [RFC5987] for using a "filename*" paramter of the
   "Content-Disposition" header SHOULD NOT be used.

What method?  RFC 5987 does not contain any of the strings "filename",
"content-", nor "disposition".

Ah.  Perhaps you mean this?:

NEW
   The encoding method described in [RFC5987], which would add a
   "filename*" paramter to the "Content-Disposition" header, SHOULD
   NOT be used.
END

Again, why is this a 2119 "SHOULD NOT"?  What happens if I do use it?
Why might I decide use it, despite the "SHOULD NOT" here?

-- Section 5.4 --

   [RFC2388] suggested that multiple files for a single form field be
   transmitted using a nested multipart/mixed part.

   To match widely deployed implementations, multiple files SHOULD be
   sent by supplying each file in a separate part, but all with the same
   "name" parameter.

Is it intended that the mechanism in the first paragraph be
deprecated?  That's what it looks like from what you say in this
section.  So why not say that, and why is the SHOULD not a MUST (you
already advise receivers to tolerate the deprecated mechanism, so that
should be fine)?  That way, you'd be saying "MUST generate the new
way; SHOULD accept the old way on receipt."

-- Section 6.1 --

   While [RFC2388]
   suggested that non-ASCII field names should be encoded according to
   the method in [RFC2047] if they contain characters outside of US-
   ASCII, this practice doesn't seem to have been followed widely.

There's redundancy in there; I suggest removing " if they contain
characters outside of US-
   ASCII", as you already say "non-ASCII".

-- Section 6.1.1 --

   For broadest interoperability with existing deployed software, those
   creating forms SHOULD avoid non-ASCII field names.  This should not
   be a burden, because in general the field names are not visible to
   users.

I think it's worth adding a reminder that the field names in the
underlying form don't have to match the names the user might see on
the screen.  That would clarify the "not visible to users" part.

-- Section 6.2 --

   Form processors given forms with a well-defined ordering SHOULD send
   back results in the order received and preserve duplicate field
   names, in order.  Intermediaries MUST NOT reorder the results.  (Note
   that there are some forms which do not define a natural order of
   appearance.)

Why is this SHOULD, and not MUST?  What do I need to take into account
when I'm deciding whether to comply with this SHOULD or not?  Why
might I want or need not to do it?

-- Section 8 --
Now that many (all major) browsers have autofill options, it strikes
me that it might be possible for a server to include in an otherwise
unremarkable form some fields that are presented in a way that a user
won't notice (white on white, very tiny, or the like) and that have
names that the browser will fill information in when the user
autofills the other fields and doesn't notice that these are being
autofilled as well.  That could expose information that the user isn't
intending to send to this site.

This is a UI issue, not directly an issue with the protocol here...
but this is the only place to note the exposure and warn implementors
to be aware of it.  Might it be worth putting something in here?

-- Section 9 --
What is this meant to be?  It's not in the IANA Considerations
section.  It's not a complete template.  Is it meant to be an update
to the original template?  Or what?

--
Barry