[dmarc-ietf] Section 12.2.2

["MH Michael Hammer (5304)" <[e-mail]>]

John Levine posted regarding using HTTP (see below) and this came up in the BOF as well. Perhaps we could have the discussion on the list and perhaps even have some conclusions for last call on the draft.

> 
> * Decide whether to remove section 12.2.2 since I don't think anyone has
> ever implemented and it's rather badly specified.  Every http POST I've ever
> seen has had an application/x-www-form-urlencoded or multipart/form-
> data body.  While there's nothing in the http spec that forbids other random
> multiparts, I wouldn't want to write it into a standards track document unless
> I was confident that web servers would do something reasonable.  Note that
> an http PUT means to replace whatever is at the URL with the body of the
> message, which is not what you want.
> POST makes more sense, but for a POST to work reliably you'd be much
> better off with the gzip file inside a multipart/form-data.  The Subject field it
> describes is also pretty dodgy since I don't know anyone who uses them with
> http, and would in any event be redundant with the filename in the form-
> data.  The section is also somwhat underspecified on the response side, since
> it gives no hint as to what http return codes might be returned and how a
> receiver should interpret them, e.g., if it gets a 302 should it really go re-post
> it somewhere else?  If it gets a 4xx should it keep sending subsequent
> reports?
>