Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)

[Ruslan Marchenko]

Am 14.01.2020 um 22:41 schrieb Jonas Schäfer:

This message constitutes notice of a Last Call for comments on XEP-0363. The
Last Call was restarted after the Council election, because the previous
Council did not vote on the ongoing LC.

Title: HTTP File Upload
Abstract:
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
2020-01-28.

Please consider the following questions during this Last Call and send
your feedback to the standards@xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?

Yes

2. Does the specification solve the problem stated in the introduction
and requirements?

Yes

3. Do you plan to implement this specification in your code? If not,
why not?

Yes (implemented)

4. Do you have any security concerns related to this specification?

No

5. Is the specification accurate and clearly written?

Yes

Your feedback is appreciated!


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)

[Jonas Schäfer]

14 Jan 2020 10:41:23 pm Jonas Schäfer :

> This message constitutes notice of a Last Call for comments on XEP-0363. The
> Last Call was restarted after the Council election, because the previous
> Council did not vote on the ongoing LC.
>
> Title: HTTP File Upload
> Abstract:
> 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
> 2020-01-28.
>
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?

Yes. While we have Jingle FT for peer-to-peer file transfer, there is no 
trivial, specified or widely deployed way for peer-to-multipeer transfer. This 
XEP provides that feature.


> 2. Does the specification solve the problem stated in the introduction
> and requirements?

Yes. The awkward wording of the last Requirement can easily be fixed in Draft.

> 3. Do you plan to implement this specification in your code? If not,
> why not?

aioxmpp has support for it, I built a few tools around it, and I think I even 
added support in JabberCat.

> 4. Do you have any security concerns related to this specification?

None above and beyond what's already in the document.

> 5. Is the specification accurate and clearly written?

Yes.

> Your feedback is appreciated!
>


--
Jonas Schäfer
This was sent from mobile, and I'm not good with those. Sorry for brevity and 
such.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)

[Dave Cridland]

On Tue, 14 Jan 2020 at 21:41, Jonas Schäfer  wrote:

> This message constitutes notice of a Last Call for comments on XEP-0363.
> The
> Last Call was restarted after the Council election, because the previous
> Council did not vote on the ongoing LC.
>
> Title: HTTP File Upload
> Abstract:
> 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
> 2020-01-28.
>
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
>
>
Yes. While there is some overlap between this specification and Jingle FT,
there is no particular reason why these two cannot be used in a useful
combination in the future.


> 2. Does the specification solve the problem stated in the introduction
> and requirements?
>
>
I'm not convinced the last bullet point is a requirement, actually, but if
it is it is not met.

I think it would be more useful to move this bullet into the Security
Considerations.


> 3. Do you plan to implement this specification in your code? If not,
> why not?
>
>
Not currently; while we move images around we have rather higher
requirements on access control as our images contain sensitive patient
data, and the simplistic approach taken here is insufficient. However,
there are multiple ways to address this and we might revisit.


> 4. Do you have any security concerns related to this specification?
>
>
As mentioned above, I don't think "weak security" is a requirement as such,
and the Security Considerations do not actually make it explicit that this
is the model. It would seem more useful to move that bullet into Security
Considerations and rephrase it slightly.


> 5. Is the specification accurate and clearly written?
>

Yes - and incidentally vastly improved since it's original Last Call.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)

[Holger Weiß]

* Jonas Schäfer  [2020-01-14 22:41]:
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?

As far as I can see, it's currently our only solution for media sharing
that works reliably with offline recipients, multiple devices, and group
chats.  Similar functionalty could be built using Jingle File Transfer,
but we're probably far away from having this properly spec'ed and
implemented.

> 2. Does the specification solve the problem stated in the introduction
> and requirements?

Yes.

> 3. Do you plan to implement this specification in your code? If not,
> why not?

I've implemented it (server-side).

> 4. Do you have any security concerns related to this specification?

No.

> 5. Is the specification accurate and clearly written?

Yes.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)

[Guus der Kinderen]

On Tue, 14 Jan 2020 at 22:42, Jonas Schäfer  wrote:

> This message constitutes notice of a Last Call for comments on XEP-0363.
> The
> Last Call was restarted after the Council election, because the previous
> Council did not vote on the ongoing LC.
>
> Title: HTTP File Upload
> Abstract:
> 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
> 2020-01-28.
>
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
>
>
Functionally, existing specs cover "transferring data". This protocol,
however, fill the gap of the unavailability of one such protocol that's
easily implemented/adopted.


> 2. Does the specification solve the problem stated in the introduction
> and requirements?
>
> Yes - the last requirement is worded a bit awkwardly perhaps (not doing
something makes for a weird requirement).


> 3. Do you plan to implement this specification in your code? If not,
> why not?
>
>
I have (server-sided)


> 4. Do you have any security concerns related to this specification?
>
>
None other than that are explicitly stated in the specification.


> 5. Is the specification accurate and clearly written?
>
> Yes


> Your feedback is appreciated!
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)

[Daniel Gultsch]

The previous last call for this was mostly ignored; which I’m
interpreting as most people are generally happy with this XEP. However
for due process I think we need to collect some feedback so let me
start with mine.

Am Di., 14. Jan. 2020 um 21:43 Uhr schrieb Jonas Schäfer :

> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?

Yes and no. There is arguably some overlap with Jingle File Transfer.
However Jingle FT is still experimental (or technically even deferred
at this point) and much much harder to implement.

> 2. Does the specification solve the problem stated in the introduction
> and requirements?

Yes

> 3. Do you plan to implement this specification in your code? If not,
> why not?

I have implemented it.

> 4. Do you have any security concerns related to this specification?

No

> 5. Is the specification accurate and clearly written?

Yes.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] LAST CALL: XEP-0363 (HTTP File Upload)

[Jonas Schäfer]

This message constitutes notice of a Last Call for comments on XEP-0363. The 
Last Call was restarted after the Council election, because the previous 
Council did not vote on the ongoing LC.

Title: HTTP File Upload
Abstract:
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
2020-01-28.

Please consider the following questions during this Last Call and send
your feedback to the standards@xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?

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?

5. Is the specification accurate and clearly written?

Your feedback is appreciated!


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] LAST CALL: XEP-0363 (HTTP File Upload)

[XSF Editor]

This message constitutes notice of a Last Call for comments on
XEP-0363.

Title: HTTP File Upload
Abstract:
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
2019-01-22.

Please consider the following questions during this Last Call and send
your feedback to the standards@xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?

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?

5. Is the specification accurate and clearly written?

Your feedback is appreciated!
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)

[Goffi]

Hi,

I'm developer of Salut à Toi and HTTP Upload is implemented there, here are 
my feedbacks:

> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?

Well it's hard to answer. I would say no because Jingle is already doing 
that in a better way.

On the other hand, HTTP libraries are more common that Jingle libraries, 
making the implementation more easy for HTTP upload.

At the end, I don't think it's really filling a gap, but its existence make 
sense in a way.

> 2. Does the specification solve the problem stated in the introduction
> and requirements?

The problem stated in introduction is not true, it's absolutely possible to 
use Jingle to send a file to multiple resources or to make it work offline, 
we do it in SàT with a server side component.

But HTTP Upload implementation is truly easy on client dev perspective, 
supposing we have already HTTP libraries + certificate checking facilities 
in the used programming language (which is most of time true). That's the 
main interested of this XEP.

> 3. Do you plan to implement this specification in your code? If not,
> why not?

already implemented

> 4. Do you have any security concerns related to this specification?

my main concern is about file deletion. We have no way to know which files 
are already uploaded, for how long and how to delete them.

I think this specification should return the expiration date of the file, 
in the same way as it returns max-file-size in section 3 and example  4.

About user request of file deletion, this could probably be done in an 
external XEP, but it's an important missing part in my point of view. 

> 5. Is the specification accurate and clearly written?

yes, redaction is good and spec is well explained.


additional notes:

- there is no validation schema in section 11

- there is no short name


++
Goffi



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] LAST CALL: XEP-0363 (HTTP File Upload)

[XSF Editor]

This message constitutes notice of a Last Call for comments on
XEP-0363.

Title: HTTP File Upload
Abstract:
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
2018-06-19.

Please consider the following questions during this Last Call and send
your feedback to the standards@xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?

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?

5. Is the specification accurate and clearly written?

Your feedback is appreciated!
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)

[Dave Cridland]

Re-reading this and other feedback, I'm going to push back on moving
this to Draft until substantial improvements are done to Security
Considerations in particular, and normative language use in general.

On 12 December 2017 at 11:07, Dave Cridland  wrote:
> On 11 December 2017 at 20:15, Kevin Smith  wrote:
>> On 29 Nov 2017, at 19:16, Jonas Wielicki (XSF Editor)  
>> wrote:
>>> This message constitutes notice of a Last Call for comments on
>>> XEP-0363.
>>>
>>> Title: HTTP File Upload
>>> Abstract:
>>> 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
>>> 2017-12-12.
>>>
>>> Please consider the following questions during this Last Call and send
>>> your feedback to the standards@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.
>>
>
> The fact it's a new mechanism worries me less than it being a new *model*.
>
>>> 2. Does the specification solve the problem stated in the introduction
>>> and requirements?
>>
>> Yes.
>>
>>>
>>> 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?
>>
>
> I think the impact of imposing a short-term storage is that clients
> (or indeed users) expecting long-term storage will suffer
> interoperability issues if they rely on this.
>
> Furthermore, it seems possible that one of the suggestions for use
> given elsewhere - PEP avatars - would be badly broken if the server
> implements RFC 748.
>
> So yes, I think this *is* an interoperability statement, but I don't
> think it's addressed well in practical terms beyond handwaving, and
> the specification is insufficient to describe the "RECOMMENDED" and
> the pitfalls of ignoring it.
>
>> "   • 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.
>>
>
> Oh, I think it can -  this MAY is a security threat mitigation -
> although the actual threat is not discussed, and being truly optional
> it serves essentially no benefit. You could do a lot more fun things
> than this, depending on the threat model.
>
> On the other hand "Server operators SHOULD consider" is useless - this
> appears to be ordinary English language, used as a sort of security
> virtue signalling, and masquerading as RFC 2119. There is no
> interoperability benefit here, nor any security threat or mitigation
> defined.
>
> In general, the Security Considerations section appears to be written
> like this throughout. "Client implementors MUST consider" does not
> make any interoperability statement either.
>
> What's needed here is a set of threats, and how to mitigate them, and
> not vague platitudes on how it'd be nice if we all really thought
> about it.
>
>>
>> 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 

Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)

[Sam Whited]

On Tue, Dec 12, 2017, at 15:49, Ruslan N. Marchenko wrote:
> Yes, I don't like the approach with wide open PUT limited by certain 
> high-level content constraints and (luckily) headers in the latest
> revision.
> At least content hash (as in jingle) would be beneficial. Shall we say 
> slot path element (public one) should be content hash (and hence part of 
> request)?
> That allows all 3 parties (sender, mediator, receiver) to verify somehow 
> validity of the content. Otherwise there's possibility of the content 
> injection.

The PUT is not necessarily wide open: that's a matter of service policy.
The addition of required headers means that you could require the PUT to
contain a token that is unique to the specific upload slot being
requested.
Since there are no interoperability concerns if different servers
implement this in different ways no specific mechanism needs to be
mandated by this spec.

You may not always know the content hash up front, and it may not be
desirable to read large files twice (first to generate the hash, the
second time to actually send the file to the server).

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)

[Ruslan N. Marchenko]

On 29.11.2017 20:16, Jonas Wielicki (XSF Editor) wrote:

This message constitutes notice of a Last Call for comments on
XEP-0363.

Title: HTTP File Upload
Abstract:
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
2017-12-12.

Please consider the following questions during this Last Call and send
your feedback to the standards@xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?

I'm not quite sure about it. Alas it works.

2. Does the specification solve the problem stated in the introduction
and requirements?

That it does.

3. Do you plan to implement this specification in your code? If not,
why not?

Yes, because it works already.

4. Do you have any security concerns related to this specification?
Yes, I don't like the approach with wide open PUT limited by certain 
high-level content constraints and (luckily) headers in the latest revision.
At least content hash (as in jingle) would be beneficial. Shall we say 
slot path element (public one) should be content hash (and hence part of 
request)?
That allows all 3 parties (sender, mediator, receiver) to verify somehow 
validity of the content. Otherwise there's possibility of the content 
injection.

5. Is the specification accurate and clearly written?


XMPP part yes. The rest is left to implementers.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)

[Guus der Kinderen]

On 29 November 2017 at 20:16, Jonas Wielicki  wrote:

> This message constitutes notice of a Last Call for comments on
> XEP-0363.
>
> Title: HTTP File Upload
> Abstract:
> 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
> 2017-12-12.
>
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
>
>
Yes


> 2. Does the specification solve the problem stated in the introduction
> and requirements?
>
>
Yes


> 3. Do you plan to implement this specification in your code? If not,
> why not?
>
>
Yes


> 4. Do you have any security concerns related to this specification?
>
>
Perhaps warnings should be added that explicitly state that the TLS
configuration of the file transfer might differ from that of the XMPP
client connection, and that the receiving end might not want to
auto-display/execute data.


5. Is the specification accurate and clearly written?
>
>
Yes


> Your feedback is appreciated!
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)

[Dave Cridland]

On 11 December 2017 at 20:15, Kevin Smith  wrote:
> On 29 Nov 2017, at 19:16, Jonas Wielicki (XSF Editor)  
> wrote:
>> This message constitutes notice of a Last Call for comments on
>> XEP-0363.
>>
>> Title: HTTP File Upload
>> Abstract:
>> 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
>> 2017-12-12.
>>
>> Please consider the following questions during this Last Call and send
>> your feedback to the standards@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.
>

The fact it's a new mechanism worries me less than it being a new *model*.

>> 2. Does the specification solve the problem stated in the introduction
>> and requirements?
>
> Yes.
>
>>
>> 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?
>

I think the impact of imposing a short-term storage is that clients
(or indeed users) expecting long-term storage will suffer
interoperability issues if they rely on this.

Furthermore, it seems possible that one of the suggestions for use
given elsewhere - PEP avatars - would be badly broken if the server
implements RFC 748.

So yes, I think this *is* an interoperability statement, but I don't
think it's addressed well in practical terms beyond handwaving, and
the specification is insufficient to describe the "RECOMMENDED" and
the pitfalls of ignoring it.

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

Oh, I think it can -  this MAY is a security threat mitigation -
although the actual threat is not discussed, and being truly optional
it serves essentially no benefit. You could do a lot more fun things
than this, depending on the threat model.

On the other hand "Server operators SHOULD consider" is useless - this
appears to be ordinary English language, used as a sort of security
virtue signalling, and masquerading as RFC 2119. There is no
interoperability benefit here, nor any security threat or mitigation
defined.

In general, the Security Considerations section appears to be written
like this throughout. "Client implementors MUST consider" does not
make any interoperability statement either.

What's needed here is a set of threats, and how to mitigate them, and
not vague platitudes on how it'd be nice if we all really thought
about it.

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

As noted above, this is changing file transfer from being a
communications path into a store and forward. I don't think that's
necessarily a bad thing, actually, but there's a lot of deployments
where, as you say, this model isn't going to work at all, and it'd be
interesting to consider how they might be unified.

> /K
> ___
> Standards mailing list
> 

Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)

[Dave Cridland]

On 12 December 2017 at 09:10, Daniel Gultsch  wrote:
> 2017-12-11 21:15 GMT+01:00 Kevin Smith :
>> On 29 Nov 2017, at 19:16, Jonas Wielicki (XSF Editor)  
>> wrote:
>>> 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.
>
> I can add that.
>
>>
>>>
>>> 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?
>
> The point is that clients don't have to parse the timestamp and could
> just retry at their own convenience.
> Retrying earlier will of course give them the exact same error message
> again but it won't get them locked out for good or anything.

You say "will of course", but the specification says "SHOULD NOT", so
what are the reasons you're anticipating a server might impose
sanctions?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)

[Daniel Gultsch]

2017-12-11 21:15 GMT+01:00 Kevin Smith :
> On 29 Nov 2017, at 19:16, Jonas Wielicki (XSF Editor)  
> wrote:
>> 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.

I can add that.

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

The point is that clients don't have to parse the timestamp and could
just retry at their own convenience.
Retrying earlier will of course give them the exact same error message
again but it won't get them locked out for good or anything.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)

[Kevin Smith]

On 29 Nov 2017, at 19:16, Jonas Wielicki (XSF Editor)  
wrote:
> This message constitutes notice of a Last Call for comments on
> XEP-0363.
> 
> Title: HTTP File Upload
> Abstract:
> 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
> 2017-12-12.
> 
> Please consider the following questions during this Last Call and send
> your feedback to the standards@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?

Yes.

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

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] LAST CALL: XEP-0363 (HTTP File Upload)

[XSF Editor]

This message constitutes notice of a Last Call for comments on
XEP-0363.

Title: HTTP File Upload
Abstract:
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
2017-12-12.

Please consider the following questions during this Last Call and send
your feedback to the standards@xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?

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?

5. Is the specification accurate and clearly written?

Your feedback is appreciated!
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___