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

From: Larry Masinter <[email-masked]>
Date: Mon, 9 Mar 2015 21:59:59 +0000

I went ahead and did a new version before the cutoff

>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

I’ll be at IETF Dallas to review changes.

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

I took this out, but asI think I want to put it back in before
Last Call, because I want people to look at the very incomplete
test cases during last call.

still want to point people to https://github.com/masinter/multipart-form-data 

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

I renamed it and added a reference

>
>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.

I tried.

>
>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.

I got rid of the ‘lower case’ and reworded.

>
>-- 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.

I removed the sentence as it is explained elsewhere and not
relevant to the section.

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

fixed

>
>-- 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.

fixed

>
>-- 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?

I tried rewriting, and added some additional material referencing
Content-Disposition filename discussion for MUAs.

>
>   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

Yes

>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?

The section now tries to explain

>
>-- 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."

I changed the SHOULD to a MUST

>
>-- 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".

fixed

>
>-- 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.

done, please review

>-- 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?

I rewrote, hopefully to make it clearer, why ‘well-defined ordering’
isn’t well-defined.

>
>-- 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?

I noted this in the “All form processing software” since the issue
is about forms and not this particular encoding.

>
>-- 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?
>

I made it clear it was a MIME template and added the missing parts.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 10 Mar 2015 14:19:20 -0400

> I went ahead and did a new version before the cutoff

Thanks, Larry.  And I've trimmed everything below that needs no
further comment.  For all the trimmed stuff: Thanks for addressing it.

> still want to point people to https://github.com/masinter/multipart-form-data

Ack.  You can put it back for now, or... I can make sure it's in the
last call note.  Let me know whether you think having it in the last
call note is good enough.

>>encoding.  You should rephrase this.

You succeeded.

>>the screen.  That would clarify the "not visible to users" part.

Reviewed (now Section 5.1.1).  You left out a word:

OLD
The field names in the underlying need not match what the
user sees on the screen.
NEW
The field names in the underlying form need not match what
the user sees on the screen.

--
I'm ready to request last call on this as soon as you give me the
go-ahead.  If you want to make one more revision before I do that, let
me know off list and I'll approve posting it during the pre-meeting
blackout.

Barry