Subject: Re: [apps-discuss] Working Group Last Call on draft-ietf-appsawg-multipart-form-data

From: Salvatore Loreto <[email-masked]>
Date: Thu, 6 Nov 2014 14:28:21 +0000

Hi there,

I am acting as shepherd for the appsawg-mutlipart-form-data

The wg lc for this draft has been issued on September 16, but since then nobody has sent
any comment/feedback to the list.

We really need people reviewing this document and providing their feedback
in order to determine if there is or not working group consensus to be publish this draft.

best regards
Salvatore

---------- Forwarded message ----------
From: Murray S. Kucherawy <[email-masked]<mailto:[email-masked]>>
Date: Tue, Sep 16, 2014 at 1:09 PM
Subject: Working Group Last Call on draft-ietf-appsawg-multipart-form-data
To: IETF Apps Discuss <[email-masked]<mailto:[email-masked]>>

Working Group Last Call: draft-ietf-appsawg-multipart-form-data

Colleagues,

This note starts a Working Group Last Call for draft-ietf-appsawg-multipart-form-data.  The document seems to have stabilized and I believe Larry got the help he needed in setting up test cases he needed.

Please provide review comments or expressions of support for the current version either on this list or privately to [email-masked]<mailto:[email-masked]> on or before October 3, 2014.  Be as detailed as possible.  The co-chairs need to determine if the document has working group consensus, which means we need to know people have read the latest version and agree with its content and with the idea that it is ready to proceed.  A simple “+1” doesn’t tell us anything.

Also, if any participant has knowledge of IPR that needs to be declared on this work, please do so, as required by BCPs 78 and 79.

<name> is fulfilling the duties of document shepherd.

-MSK, APPSAWG co-chair

---

From: Ned Freed <[email-masked]>
Date: Thu, 06 Nov 2014 08:02:05 -0800 (PST)

> in order to determine if there is or not working group consensus to be publish this draft.

A few comments.

The wording in section 5.1 is a little odd. Quotes are only required
around parameter values when a tspecial character is present. But the way
this section is worded makes it sound like parameters always have to be
quoted and systems that emit an unquoted parameter are doing something
that's at a minimum wierd if not downright incorrect. I don't have
alternate wording to suggest, but some clarification would be good.

I question the need to reference RFC 1806 in section 5.2. RFC 2183  is the
standards-track specification of content-disposition which replaced the
experimental RFC 1806. (OTOH, the documents say that RFC 2183 updates RFC 1806;
I don't understand why it didn't obsolete it. So maybe there's some need to
reference it...)

Section 5.2 makes use of the content-disposition "name" parameter. When I
checked the IANA registry for this parameter
(http://www.iana.org/assignments/cont-disp/cont-disp.xhtml#cont-disp-2) I
noticed something odd: The parameter is supposedly defined in RFC 2388, which
is the earlier version of this document. Moreover, RFC 2388 just talks about
the parameter, it doesn't actually say it registers it.

I suggest adding appropriate registration text to the IANA Considerations
section and updating the registry to point to this document.

Section 5.9 talks about what MIME fields are supported in form data parts,
but doesn't go so far as to say they MUST NOT be present. It might be
a good thing to clarify whether they are simply ignored if present or whether
they might actually screw things up if you include them.

Section 8 and/or the security considerations in section 9 probably should
say something about privacy and integirty protection for form data.

All media types are supposed to state whether or not they involve executable
content, so this needs to be mentioned in section 9.

That's it.

				Ned

---

From: t.petch <[email-masked]>
Date: Fri, 7 Nov 2014 18:14:53 +0000

Saving the RFC Editor a little work mostly

s.4

/there are a generally series of fields,/there are generally aseries of
fields,/

' restricting field names to ASCII  will help avoid some
interoperability issues.'
worth making a SHOULD?

s.5.1

/Each field's form data of the form is /Each field's form data is/

/prepared to acommodate./prepared to accommodate./

s.5.3

Should there be a reference for '"file:" URI' or has that been omitted
because there is no good one:-(

s.5.6
/In the case where the form data text,/  In the case where the form data
is text,/

s.8
I think that the Security Considerations should be stronger about
protecting the privacy of confidential information

s.9
The registration has two references to this document - these should
probably be called out as RFCxxxx with the usual note to replace xxxx
with the RFC number

Tom Petch

----- Original Message -----
From: "Salvatore Loreto" <[email-masked]>
To: "IETF Apps Discuss" <[email-masked]>
Sent: Thursday, November 06, 2014 2:28 PM

Hi there,

The wg lc for this draft has been issued on September 16, but since then
nobody has sent
any comment/feedback to the list.

We really need people reviewing this document and providing their
feedback
in order to determine if there is or not working group consensus to be
publish this draft.

best regards
Salvatore

---------- Forwarded message ----------
From: Murray S. Kucherawy
<[email-masked]<mailto:[email-masked]>>
Date: Tue, Sep 16, 2014 at 1:09 PM
Subject: Working Group Last Call on
draft-ietf-appsawg-multipart-form-data
To: IETF Apps Discuss
<[email-masked]<mailto:[email-masked]>>

Colleagues,

This note starts a Working Group Last Call for
draft-ietf-appsawg-multipart-form-data.  The document seems to have
stabilized and I believe Larry got the help he needed in setting up test
cases he needed.

Please provide review comments or expressions of support for the current
version either on this list or privately to
[email-masked]<mailto:draft-i
[email-masked]> on or before October
3, 2014.  Be as detailed as possible.  The co-chairs need to determine
if the document has working group consensus, which means we need to know
people have read the latest version and agree with its content and with
the idea that it is ready to proceed.  A simple “+1” doesn’t tell us
anything.

Also, if any participant has knowledge of IPR that needs to be declared
on this work, please do so, as required by BCPs 78 and 79.

-MSK, APPSAWG co-chair

------------------------------------------------------------------------
--------

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: t.petch <[email-masked]>
Date: Tue, 11 Nov 2014 11:11:55 +0000

I note that this I-D specifies

   Encoding considerations:  Common use is BINARY.

Looking at
http://www.iana.org/assignments/media-types/multipart/related
I see

Encoding considerations:   Multipart content-types cannot have
                           encodings.

I have looked at more recent RFC, such as RFC6838, and can see nothing
to gainsay this.  Does this restriction still apply?

(and yes, I have told IANA that
http://www.iana.org/assignments/media-types/multipart/report
yields 404)

Tom Petch

----- Original Message -----
From: "Salvatore Loreto" <[email-masked]>
To: "IETF Apps Discuss" <[email-masked]>
Sent: Thursday, November 06, 2014 2:28 PM
Subject: Re: [apps-discuss] Working Group Last Call
ondraft-ietf-appsawg-multipart-form-data

Hi there,

best regards
Salvatore

---------- Forwarded message ----------

Colleagues,

-MSK, APPSAWG co-chair

---

From: Ned Freed <[email-masked]>
Date: Tue, 11 Nov 2014 18:01:10 -0800 (PST)

> to gainsay this.  Does this restriction still apply?

Atually, both of these are more or less correct. It's all in how you look at
it: A multipart cannot have a non-identity content-transfer-encoding, but you
can talk about its encoding considerations, which are effectively the union of
all the parts.

That said, I find the first to be preferable. For one thing, it provides more
information. But perhaps more importantly, it's not beyond possibility that the
restriction on encodings of multipart will be lifted at some point just as the
restriction on message types was.

				Ned

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 13 Nov 2014 13:17:51 +0900

> /there are a generally series of fields,/there are generally aseries of

/there are a generally series of fields,/there are generally a series of
  fields,/

(missing space)

Regards,   Martin.