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

[Christian Schudt]

Am 29.09.2015 um 02:02 schrieb Evgeny Khramtsov :

> Thu, 24 Sep 2015 13:10:44 +0300
> PG Stath  wrote:
> 
>> In general I think that XMPP might be missing developers not because
>> features are missing but because of non compatible extensions lists
>> and extension implementations among different libraries, servers and
>> applications.
> 
> Totally agreed. As a note, I think the list of deprecated XEPs should be
> revised and a transition mechanism should be developed. The specs are:
> 1) Avatars: XEP-0084 vs XEP-0153
> 2) Time: XEP-0090 vs XEP-0202. Yes, there are still abandoned quite
> popular clients with no support of XEP-0202.
> 3) Filetransfer. Tons of specs. The transition might be HTTP
> Upload + jabber:x:oob, until Jingle specs are finalized.
> 4) MUC. Inventing MUC2 will result in the similar problems. The
> transition will be painful due to MUC complexity.

I agree, too. The list can go on:
XEP-0054 vs. XEP-0292 (VCard)
XEP-0256 vs. XEP-0319 (Idle/Last active time, clients now need to append both 
extensions)
XEP-0136 vs. XEP-0313 (Archive)
XEP-0049 vs. XEP-0223 (Private storage, e.g. how do clients know where XEP-0048 
bookmarks are really stored?)
XEP-0079 vs. XEP-0334 (Message Processing, I believe 100% of 0334 can be 
covered with 0079, so why a new XEP?)
XEP-0191 vs. XEP-0016 (Blocking Users)
XEP-0085 vs. XEP-0022 (Ok, to be fair, this transition was successful I guess)
XEP-0249 vs. XEP-0045 (2 kinds of MUC invitations)
XEP-0186 vs. XEP-0126 (How to deal with invisibility?)

On top of that, different ways of storage or transports (e.g. as in XEP-0152) 
makes implementation not easier, especially for client developers.

- Christian

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

[Tobias Markmann]

On Tue, Sep 29, 2015 at 8:45 AM, Dave Cridland  wrote:

>
>
> On 29 September 2015 at 08:12, Christian Schudt 
> wrote:
>
>>
>> XEP-0256 vs. XEP-0319 (Idle/Last active time, clients now need to append
>> both extensions)
>>
>
> Can we do server translation of this? At least for the Idle case?
>

Yes we can! http://modules.prosody.im/mod_idlecompat.html

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

[Dave Cridland]

On 29 September 2015 at 08:12, Christian Schudt 
wrote:

>
> Am 29.09.2015 um 02:02 schrieb Evgeny Khramtsov :
>
> > Thu, 24 Sep 2015 13:10:44 +0300
> > PG Stath  wrote:
> >
> >> In general I think that XMPP might be missing developers not because
> >> features are missing but because of non compatible extensions lists
> >> and extension implementations among different libraries, servers and
> >> applications.
> >
> > Totally agreed. As a note, I think the list of deprecated XEPs should be
> > revised and a transition mechanism should be developed. The specs are:
> > 1) Avatars: XEP-0084 vs XEP-0153
> > 2) Time: XEP-0090 vs XEP-0202. Yes, there are still abandoned quite
> > popular clients with no support of XEP-0202.
> > 3) Filetransfer. Tons of specs. The transition might be HTTP
> > Upload + jabber:x:oob, until Jingle specs are finalized.
> > 4) MUC. Inventing MUC2 will result in the similar problems. The
> > transition will be painful due to MUC complexity.
>
> I agree, too. The list can go on:
> XEP-0054 vs. XEP-0292 (VCard)
>

There's also XEP-0154, which is deferred but not deprecated. One
server-side vCard implementation I wrote got amazingly complex trying to
design for this... My understanding is that's been fixed now.

But XEP-0292 does not offer any compatibility path back to XEP-0054 either;
we really need to fix this.


> XEP-0256 vs. XEP-0319 (Idle/Last active time, clients now need to append
> both extensions)
>

Can we do server translation of this? At least for the Idle case?


> XEP-0136 vs. XEP-0313 (Archive)
>

XEP-0136 is pretty much dead, I think, and XEP-0313 can be built
server-side on top of XEP-0136 stores with some effort.


> XEP-0049 vs. XEP-0223 (Private storage, e.g. how do clients know where
> XEP-0048 bookmarks are really stored?)
>

Private storage in these cases should be mapped to the right PEP node
transparently, so clients don't have to guess.


> XEP-0079 vs. XEP-0334 (Message Processing, I believe 100% of 0334 can be
> covered with 0079, so why a new XEP?)
>

We should definitely move XEP-0079 to deprecated. It's horribly complex,
and nobody implemented it that I can recall anyway.


> XEP-0191 vs. XEP-0016 (Blocking Users)
>

XEP-0016 covers three cases, in fact:
 - the blocking of users which is covered by XEP-0191.
 - invisibility, covered by XEP-0186.
 - weird stuff nobody used.

We should deprecate it.

XEP-0085 vs. XEP-0022 (Ok, to be fair, this transition was successful I
> guess)
>

Yes, definitely done; though we should consider revisiting XEP-0085 in MUC
cases.


> XEP-0249 vs. XEP-0045 (2 kinds of MUC invitations)
>

Complex.

We want to send a message direct from one user to another - the XEP-0249
case - but we also often need the MUC to know a user is to be invited - the
XEP-0045 case.


> XEP-0186 vs. XEP-0126 (How to deal with invisibility?)
>
>
As above; I have no idea why a client developer would prefer to use
XEP-0016 manipulation for invisibility.


> On top of that, different ways of storage or transports (e.g. as in
> XEP-0152) makes implementation not easier, especially for client developers.

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

[Tobias M]

> On 29.09.2015, at 10:10, Evgeny Khramtsov  > wrote:
> 
>> 
>> File transfer, on the other hand, could very usefully be done via
>> protocol translation. Converting SI to Jingle and back again - or
>> even terminating Jingle in the server and translating to HTTP -
>> really feels like it should be practical.
> 
> The problem is that Jingle FT is not even ready and lord knows how
> many years will be passed until this happens.

Not ready in what capacity? It’s implemented by Conversations, Gajim, Swift and 
web clients (maybe, don’t remember for sure). Pidgin does not support it 
currently, there was a dev branch once but it’s likely outdated now.

The standard is gaining maturity with the implementation experience and future 
implementors should have it way easier.

Cheers,
Tobias

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

[Evgeny Khramtsov]

Tue, 29 Sep 2015 10:17:12 +0100
Tobias M  wrote:

> Not ready in what capacity? It’s implemented by Conversations, Gajim,
> Swift and web clients (maybe, don’t remember for sure). Pidgin does
> not support it currently, there was a dev branch once but it’s likely
> outdated now.

Seems like I'm constantly repeating on the list...
Do those implementation resolve the following problems:
1) MUC friendly
2) Offline support

From what I know Jingle FT specs don't provide a solution for those
problems.

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

[Tobias M]

> On 29.09.2015, at 10:10, Evgeny Khramtsov  wrote:
> 
>> 
>> File transfer, on the other hand, could very usefully be done via
>> protocol translation. Converting SI to Jingle and back again - or
>> even terminating Jingle in the server and translating to HTTP -
>> really feels like it should be practical.
> 
> The problem is that Jingle FT is not even ready and lord knows how
> many years will be passed until this happens.

Not ready in what capacity? It’s implemented by Conversations, Gajim, Swift and 
web clients (maybe, don’t remember for sure). Pidgin does not support it 
currently, there was a dev branch once but it’s likely outdated now.

The standard is gaining maturity with the implementation experience and future 
implementors should have it way easier.

Cheers,
Tobias

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

[Evgeny Khramtsov]

Tue, 29 Sep 2015 10:49:35 +0100
Dave Cridland  wrote:

> Writing up use-cases for these things would be really interesting, by
> the way. In fact, writing up use-cases in general, and how to
> implement them with existing XEPs, would be interesting generally, I
> think. Maybe something to do on the Wiki?

Maybe. Better asking the Jingle FT authors. I'm not even sure they are
interested/aware of the problems.

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

[Christian Schudt]

> Seems like I'm constantly repeating on the list...
> Do those implementation resolve the following problems:
> 1) MUC friendly
> 2) Offline support
>
> From what I know Jingle FT specs don't provide a solution for those
> problems.

Funny, I've brought up exactly these two problems, too:
http://mail.jabber.org/pipermail/standards/2015-July/030049.html

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

[Evgeny Khramtsov]

Tue, 29 Sep 2015 08:28:45 +0100
Dave Cridland  wrote:

> File transfer, on the other hand, could very usefully be done via
> protocol translation. Converting SI to Jingle and back again - or
> even terminating Jingle in the server and translating to HTTP -
> really feels like it should be practical.

The problem is that Jingle FT is not even ready and lord knows how
many years will be passed until this happens.

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

[Dave Cridland]

On 29 September 2015 at 10:43, Evgeny Khramtsov  wrote:

> Tue, 29 Sep 2015 10:17:12 +0100
> Tobias M  wrote:
>
> > Not ready in what capacity? It’s implemented by Conversations, Gajim,
> > Swift and web clients (maybe, don’t remember for sure). Pidgin does
> > not support it currently, there was a dev branch once but it’s likely
> > outdated now.
>
> Seems like I'm constantly repeating on the list...
> Do those implementation resolve the following problems:
> 1) MUC friendly
> 2) Offline support
>
> From what I know Jingle FT specs don't provide a solution for those
> problems.
>

Ah! No, they don't, and yes, we should address these - but Jingle didn't
have those in-scope, rightly or wrongly.

Writing up use-cases for these things would be really interesting, by the
way. In fact, writing up use-cases in general, and how to implement them
with existing XEPs, would be interesting generally, I think. Maybe
something to do on the Wiki?

Dave.

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

[Evgeny Khramtsov]

Thu, 24 Sep 2015 13:10:44 +0300
PG Stath  wrote:

> In general I think that XMPP might be missing developers not because
> features are missing but because of non compatible extensions lists
> and extension implementations among different libraries, servers and
> applications.

Totally agreed. As a note, I think the list of deprecated XEPs should be
revised and a transition mechanism should be developed. The specs are:
1) Avatars: XEP-0084 vs XEP-0153
2) Time: XEP-0090 vs XEP-0202. Yes, there are still abandoned quite
popular clients with no support of XEP-0202.
3) Filetransfer. Tons of specs. The transition might be HTTP
Upload + jabber:x:oob, until Jingle specs are finalized.
4) MUC. Inventing MUC2 will result in the similar problems. The
transition will be painful due to MUC complexity.

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

[PG Stath]

Hi all,
My two cents for the thumbnails issue and the comment:
"The main advantage is a client code simplification. You need tons of
work to generate thumbnails for images and video files. Also, we cannot
just say a developer: hey, if your UI is slow, fix it. In the most
cases developers will find just an easier way and will not deal with
jabber, because simplier solutions exist. We now see this every time.
We're lacking developers because of this.'
I am working on an application that is very dependent in file transfer
related extensions, and HTTP upload would be extremely useful.

Existing protocols are complicated or slow or don't compatible among
different clients/libraries/setups etc.
My 2 cents is the extension should be the simplest possible. Thumbnails
would be cool, but reliable XMPP file transfer is missing, and I would
prefer to have the maximum compatibility among libraries and servers
implementing the extensions, than having to generate thumbnails myself.

In general I think that XMPP might be missing developers not because
features are missing but because of non compatible extensions lists and
extension implementations among different libraries, servers and
applications.


All the best!


On Fri, Sep 18, 2015 at 12:11 AM, Evgeny Khramtsov 
wrote:

> Thu, 17 Sep 2015 21:49:04 +0200
> Daniel Gultsch  wrote:
>
> > Hi,
> >
> > a couple of reason that speak against using the HTTP upload to create
> > thumbnails. (In no particular order)
> >
> > - the service should be agnostic towards the files. I assume you are
> > proposing to create thumbnails for images? What about video files?
> > what about images in exotic formats? do I know before hand if the
> > server will create a thumbnail for me? Will this be random? do you
> > add a way to discover 'known image formats'?
>
> This is not a very big problem. If a server is unable (unwilling) to
> generate thumbnails it sends empty response. A client then will
> generate a thumbnail if needed.
>
> > - in an idealistic world we will have more and more end-to-end
> > encryption. so any thumbnail creation will not work for those images.
> > so clients that handle end-to-end encryption will have to provide a
> > way to create their own thumbnails anyway.
>
> If someone wishes not to using thumbnails, it may ignore it in
> the response. I'd also like to admit, that crazy encryption of
> everything which is very popular nowdays should not affect everyone. I
> personally don't care whether my messages will be intercepted or not.
> So I don't want to suffer from limitations of any sort of encryption.
> If you want - go ahead. I don't. But that's a completely different
> topic.
>
> > - potential security leaks. For a server it is much safer just to copy
> > files and store them than to actually process them. media formats
> > have a long history of being exploitable.
>
> There are a lot of image servers which produces thumbnails without
> being exploitable. Care should be taken of course.
>
> > - very little actual gain. creating a thumbnail is not that expensive.
> > especially since your device is probably awake at this point anyway.
> > If the thumbnail creation will freeze your UI is probably up to your
> > implementation and can probably be avoided in most cases. the only
> > small benefit would be that you don't have to upload the actual
> > thumbnail. but considering that thumbnails are small... It don't
> > really see it.
>
> The main advantage is a client code simplification. You need tons of
> work to generate thumbnails for images and video files. Also, we cannot
> just say a developer: hey, if your UI is slow, fix it. In the most
> cases developers will find just an easier way and will not deal with
> jabber, because simplier solutions exist. We now see this every time.
> We're lacking developers because of this.
>
> > besides as of right now we don't have a proper way to send thumbnails
> > anyway. If we come up with a way to send thumbnails as dedicated
> > thumbnails it might be worth considering to send them base64 encoded
> > inband anyway. (right in the message stanza (you have to keep them
> > smaller than lets say 5KiB but for thumbnails thats probably
> > manageable)
>
> We have XEP-0264.
>
> I'd also like to note that if you don't want server-side thumbnails,
> don't use them. But there should be an option for those who wants.
>

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

[Daniel Gultsch]

Hi,

a couple of reason that speak against using the HTTP upload to create
thumbnails. (In no particular order)

- the service should be agnostic towards the files. I assume you are
proposing to create thumbnails for images? What about video files? what
about images in exotic formats? do I know before hand if the server will
create a thumbnail for me? Will this be random? do you add a way to
discover 'known image formats'?
- in an idealistic world we will have more and more end-to-end encryption.
so any thumbnail creation will not work for those images. so clients that
handle end-to-end encryption will have to provide a way to create their own
thumbnails anyway.
- potential security leaks. For a server it is much safer just to copy
files and store them than to actually process them. media formats have a
long history of being exploitable.
- very little actual gain. creating a thumbnail is not that expensive.
especially since your device is probably awake at this point anyway. If the
thumbnail creation will freeze your UI is probably up to your
implementation and can probably be avoided in most cases. the only small
benefit would be that you don't have to upload the actual thumbnail. but
considering that thumbnails are small... It don't really see it.

besides as of right now we don't have a proper way to send thumbnails
anyway. If we come up with a way to send thumbnails as dedicated thumbnails
it might be worth considering to send them base64 encoded inband anyway.
(right in the message stanza (you have to keep them smaller than lets say
5KiB but for thumbnails thats probably manageable)

cheers
Daniel

2015-09-03 13:11 GMT+02:00 Evgeny Khramtsov :

> Thu, 27 Aug 2015 16:10:18 + (UTC)
> XMPP Extensions Editor  wrote:
>
> > Version 0.1 of XEP-0363 (HTTP File Upload) has been released.
> >
> > 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.
> >
> > Changelog: Initial published version approved by the XMPP Council.
> > (XEP Editor (mam))
> >
> > Diff: http://xmpp.org/extensions/diff/api/xep/0363/diff/0.1/vs/0.1
> >
> > URL: http://xmpp.org/extensions/xep-0363.html
> >
>
> It would be great if the protocol supports image thumbnails
> (optionally). A server could generate thumbnails during upload so a
> client don't need to convert image locally. This will reduce
> cpu/battery usage on mobile devices, simplify clients code and will
> prevent UI from freezing during image transformation). I think
> there are two ways implementing it:
>
> 1) The thumbnail SHOULD be returned with HTTP response, e.g.:
> HTTP/1.1 200 OK
> Content-Type: text/xml
> ...
> uri='
> https://download.montague.tld/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/thumb.png
> '
>media-type='image/png'
>width='128'
>height='96'/>
>
> (the  element is described in XEP-0264)
>
> 2) Another way is introducing new stanza which will be sent by an XMPP
> server when upload is complete, for example:
>
>  to='ro...@montague.tld/garden
> type='set'>
>   
>   uri='
> cid:sha1+ffd7c8d28e9c5e82afea41f97108c6b4@bob.xmpp.org'
>  media-type='image/png'
>  width='128'
>  height='96'/>
>   
> 
>
> Also,  element could be extended to notify a client about
> upload status.
>
> This thumbnail then can be put into file-transfer offer using either
> jingle http transport protoXEP or directly into jabber:x:oob message,
> e.g:
>
>  from='co...@chat.shakespeare.lit/firstwitch'
> id='162BEBB1-F6DB-4D9A-9BD8-CFDCC801A0B2'
> to='hec...@shakespeare.lit/broom'
> type='groupchat'>
>   
> https://download.montague.tld/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/my_juliet.png
> 
>   
> 
> https://download.montague.tld/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/my_juliet.png
> 
> file
>   uri='
> https://download.montague.tld/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/thumb.png
> '
>  media-type='image/png'
>  width='128'
>  height='96'/>
>
>   
> 
>

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

[Evgeny Khramtsov]

Thu, 17 Sep 2015 21:49:04 +0200
Daniel Gultsch  wrote:

> Hi,
> 
> a couple of reason that speak against using the HTTP upload to create
> thumbnails. (In no particular order)
> 
> - the service should be agnostic towards the files. I assume you are
> proposing to create thumbnails for images? What about video files?
> what about images in exotic formats? do I know before hand if the
> server will create a thumbnail for me? Will this be random? do you
> add a way to discover 'known image formats'?

This is not a very big problem. If a server is unable (unwilling) to
generate thumbnails it sends empty response. A client then will
generate a thumbnail if needed.

> - in an idealistic world we will have more and more end-to-end
> encryption. so any thumbnail creation will not work for those images.
> so clients that handle end-to-end encryption will have to provide a
> way to create their own thumbnails anyway.

If someone wishes not to using thumbnails, it may ignore it in
the response. I'd also like to admit, that crazy encryption of
everything which is very popular nowdays should not affect everyone. I
personally don't care whether my messages will be intercepted or not.
So I don't want to suffer from limitations of any sort of encryption.
If you want - go ahead. I don't. But that's a completely different
topic.

> - potential security leaks. For a server it is much safer just to copy
> files and store them than to actually process them. media formats
> have a long history of being exploitable.

There are a lot of image servers which produces thumbnails without
being exploitable. Care should be taken of course.

> - very little actual gain. creating a thumbnail is not that expensive.
> especially since your device is probably awake at this point anyway.
> If the thumbnail creation will freeze your UI is probably up to your
> implementation and can probably be avoided in most cases. the only
> small benefit would be that you don't have to upload the actual
> thumbnail. but considering that thumbnails are small... It don't
> really see it.

The main advantage is a client code simplification. You need tons of
work to generate thumbnails for images and video files. Also, we cannot
just say a developer: hey, if your UI is slow, fix it. In the most
cases developers will find just an easier way and will not deal with
jabber, because simplier solutions exist. We now see this every time.
We're lacking developers because of this.

> besides as of right now we don't have a proper way to send thumbnails
> anyway. If we come up with a way to send thumbnails as dedicated
> thumbnails it might be worth considering to send them base64 encoded
> inband anyway. (right in the message stanza (you have to keep them
> smaller than lets say 5KiB but for thumbnails thats probably
> manageable)

We have XEP-0264.

I'd also like to note that if you don't want server-side thumbnails,
don't use them. But there should be an option for those who wants.

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

[Evgeny Khramtsov]

Thu, 3 Sep 2015 14:11:32 +0300
Evgeny Khramtsov  wrote:

> It would be great if the protocol supports image thumbnails
> (optionally). A server could generate thumbnails during upload so a
> client don't need to convert image locally. This will reduce
> cpu/battery usage on mobile devices, simplify clients code and will
> prevent UI from freezing during image transformation). I think
> there are two ways implementing it:
> 
> 1) The thumbnail SHOULD be returned with HTTP response, e.g.:
> HTTP/1.1 200 OK
> Content-Type: text/xml
> ...
> 
> uri='https://download.montague.tld/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/thumb.png'
>media-type='image/png'
>width='128'
>height='96'/>
> 
> (the  element is described in XEP-0264)
> 
> 2) Another way is introducing new stanza which will be sent by an XMPP
> server when upload is complete, for example:
> 
>  to='ro...@montague.tld/garden
> type='set'>
>   
>   
> uri='cid:sha1+ffd7c8d28e9c5e82afea41f97108c6b4@bob.xmpp.org'
>  media-type='image/png'
>  width='128'
>  height='96'/>
>   
> 
> 
> Also,  element could be extended to notify a client about
> upload status.
> 
> This thumbnail then can be put into file-transfer offer using either
> jingle http transport protoXEP or directly into jabber:x:oob message,
> e.g:
> 
>  from='co...@chat.shakespeare.lit/firstwitch'
> id='162BEBB1-F6DB-4D9A-9BD8-CFDCC801A0B2'
> to='hec...@shakespeare.lit/broom'
> type='groupchat'>
>   
> https://download.montague.tld/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/my_juliet.png
>   
> 
> https://download.montague.tld/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/my_juliet.png
> file
>   
> uri='https://download.montague.tld/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/thumb.png'
>  media-type='image/png'
>  width='128'
>  height='96'/>
> 
>   
> 

XSF guys, any repsonse on this? I could make a PR based on the way we
choose.

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

[Evgeny Khramtsov]

Thu, 27 Aug 2015 16:10:18 + (UTC)
XMPP Extensions Editor  wrote:

> Version 0.1 of XEP-0363 (HTTP File Upload) has been released.
> 
> 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.
> 
> Changelog: Initial published version approved by the XMPP Council.
> (XEP Editor (mam))
> 
> Diff: http://xmpp.org/extensions/diff/api/xep/0363/diff/0.1/vs/0.1
> 
> URL: http://xmpp.org/extensions/xep-0363.html
> 

It would be great if the protocol supports image thumbnails
(optionally). A server could generate thumbnails during upload so a
client don't need to convert image locally. This will reduce
cpu/battery usage on mobile devices, simplify clients code and will
prevent UI from freezing during image transformation). I think
there are two ways implementing it:

1) The thumbnail SHOULD be returned with HTTP response, e.g.:
HTTP/1.1 200 OK
Content-Type: text/xml
...


(the  element is described in XEP-0264)

2) Another way is introducing new stanza which will be sent by an XMPP
server when upload is complete, for example:


  

  


Also,  element could be extended to notify a client about
upload status.

This thumbnail then can be put into file-transfer offer using either
jingle http transport protoXEP or directly into jabber:x:oob message,
e.g:


  
https://download.montague.tld/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/my_juliet.png
  

https://download.montague.tld/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/my_juliet.png
file


  

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

[Sam Whited]

Should the application specific error codes in this document be
registered in the registry at https://xmpp.org/registrar/errors.html ?


Specifically example 7:

```

  2

```

Best,
Sam


On Thu, Aug 27, 2015 at 11:10 AM, XMPP Extensions Editor
 wrote:
> Version 0.1 of XEP-0363 (HTTP File Upload) has been released.
>
> 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.
>
> Changelog: Initial published version approved by the XMPP Council. (XEP 
> Editor (mam))
>
> Diff: http://xmpp.org/extensions/diff/api/xep/0363/diff/0.1/vs/0.1
>
> URL: http://xmpp.org/extensions/xep-0363.html
>



-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com

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

[XMPP Extensions Editor]

Version 0.1 of XEP-0363 (HTTP File Upload) has been released.

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.

Changelog: Initial published version approved by the XMPP Council. (XEP Editor 
(mam))

Diff: http://xmpp.org/extensions/diff/api/xep/0363/diff/0.1/vs/0.1

URL: http://xmpp.org/extensions/xep-0363.html