[Standards] LAST CALL: XEP-0363 (HTTP File Upload)
kevin.smith at isode.com
Mon Dec 11 20:15:38 UTC 2017
On 29 Nov 2017, at 19:16, Jonas Wielicki (XSF Editor) <jonas at wielicki.name> wrote:
> This message constitutes notice of a Last Call for comments on
> Title: HTTP File Upload
> This specification defines a protocol to request permissions from
> another entity to upload a file to a specific path on an HTTP server
> and at the same time receive a URL from which that file can later be
> downloaded again.
> URL: https://xmpp.org/extensions/xep-0363.html
> This Last Call begins today and shall end at the close of business on
> Please consider the following questions during this Last Call and send
> your feedback to the standards at xmpp.org discussion list:
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
Kinda. We do have file transfer mechanisms already. This tries to to address a use case that these have traditionally handled badly, although it’s not clear if an entirely new mechanism like this is required, or if it can be adequately addressed inside existing frameworks.
> 2. Does the specification solve the problem stated in the introduction
> and requirements?
> 3. Do you plan to implement this specification in your code? If not,
> why not?
> 4. Do you have any security concerns related to this specification?
Should probably mention that you’re going to be handing out your IP to whichever upload service you use.
> 5. Is the specification accurate and clearly written?
"The service SHOULD NOT impose sanctions on an entity for retrying earlier than the specified time.”
Seems a bit odd - what’s the point in specifying a limit if clients are allowed to ignore it, and the server has to process the request normally anyway?
"It is RECOMMENDED that the service stores the files for as long as possible which is of course limited by storage capacity.”
Seems like an odd place to put normative language to me, surely limits are a local policy choice?
" • Server operators SHOULD consider the responsibility that comes with storing user data and MAY consider appropriate measures such as full disk encryption.”
And I’m not sure that a XEP can do much normatively about full disk encryption.
Not related to the writing of the XEP, but the approach: this doesn’t cross security boundaries well. While jingle will fall back to IBB (and servers can enforce that fallback), keeping the flow under their control, and allowing data to cross network boundaries, 363 falls apart in the face of non-Internet (and even some Internet) use cases. This is going to become quite relevant to MIX, where you’re going to want to upload files to the MIX, but may well not be able to route to it and would need your server to do pass-through. I *think* (but have not tried to write it) that one could spec a relatively simple pass-through mechanism for this.
More information about the Standards