Re: [Standards] XEP-0363 and Message MIME content type

[Daniel Gultsch]

I fully agree with you that just putting the url in the body and doing
magic based on the file extension and HEAD request isn't a good solution.

oob isn't of any help here either because it doesn't include the content
type or the file size. (and especially not extended information like
resolution (as in height and width of an image) or duration (for audio))

There has been discussions on the summit regarding a 'reference' xep that
let's you reference arbitrary items via and uri and some additional
information.
I would really like that xep to cover our use case here as well.

For people how haven't been at the summit this reference xep will probably
look a bit like how twitter is referencing links or images in their api. I
don't have a link right now but maybe someone else can provide this.

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

Re: [Standards] XEP-0363 and Message MIME content type

[Peter Saint-Andre]

On 1/29/16 9:38 AM, Anurodh Pokharel wrote:

Hi all,
  In the process of implementing XEP-0363  (HTTP file uploads
http://xmpp.org/extensions/xep-0363.html) in Monal, I've come to the
realization that it would make a lot of sense to include MIME content
type and size in the message stanza.  I've done a bit of searching and I
haven't found any XEP that defines this behavior.  If any of this sounds
like it's already been done, please point me in the right direction.



We have something like that in XEP-0234 (see Section 5):

http://xmpp.org/extensions/xep-0234.html

Peter


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

Re: [Standards] XEP-0363 and Message MIME content type

[Anurodh Pokharel]

Thanks, I think out of band data on messages is an easy solution.

HEAD is part of the HTTP spec but is not uncommon for it to be blocked on
server configurations. Additionally,  depending on the way the media is
served (e.g. via a script that hides the actual path) you may not actually
get any info from the server.

I really think we should include a recommended means of transmitting
metadata in the upload XEP. This is one of those things thats only useful
if clients standardize on the way they communicate.  Including the URL in
the message body bothers me. Specifically, writing clients that
automatically call HEAD on any URL received should be explicitly
discouraged because of how easily that feature can be abused to expose a
target's IP address.

-Anu

On Fri, Jan 29, 2016 at 12:09 PM, Kim Alvefur  wrote:

> Hi,
>
> On 01/29/2016 05:38 PM, Anurodh Pokharel wrote:
> >  In the process of implementing XEP-0363  (HTTP file uploads
> > http://xmpp.org/extensions/xep-0363.html) in Monal, I've come to the
> > realization that it would make a lot of sense to include MIME content
> type
> > and size in the message stanza.  I've done a bit of searching and I
> haven't
> > found any XEP that defines this behavior.  If any of this sounds like
> it's
> > already been done, please point me in the right direction.
>
> It does not specify how the URL is sent. I know at least one
> implementation just dumps it in a message , which would not let
> you specify any additional metadata.
>
> Something like OOB  combined
> with SHIM  could carry more
> detailed metadata.  Or Jingle FT with the HTTP transport method:
> 
>
> > Essentially as I understand it, the issue is HTTP file uploads are
> designed
> > to solve the problem of people using dropbox or some other third party
> > cloud service and replace that with an XMPP server that performs all of
> > this internally.  This is great but simply posting a link to an image or
> > video alone isn't very useful to the recipient. One way of resolving this
> > is to have the receiving client present the link or preform an HTTP HEAD
> > call  to try to determine the media type and based on the response try to
> > display the content inline. The problem here are there is nothing in the
> > spec that requires the server serving the "attachment" to  support HEAD.
> > There is no guarantee that every HTTP configuration would allow this
> call.
>
> I believe existing implementations do HEAD requests first to determine
> size and content type. I *think* the HEAD method is required by the HTTP
> specification.
>
> > At the moment, on the client, we would have to scrape the URL to try to
> > determine the media type (audio, video, image etc). While HEAD solves the
> > problem,  I believe rather than require HEAD support, it may make sense
> to
> > include the content type and size in the message stanza that has the URL
> of
> > the uploaded file. This would be the same data passed to the server in
> the
> > upload request.  HEAD would require 2 HTTP calls, first the HEAD to
> > determine MIME  content type and and size and the second GET to fetch the
> > actual media  The sender is aware of both the type and size and this
> allows
> > the receiver to determine several things from the message stanza it self:
> >
> > 1. Is it a format that can be displayed inline?
> > 2. Is the file small enough to download automatically? In particular,
> this
> > is a concern for mobile users.
> > 3. Is the file in a format that can can be streamed rather than kept in a
> > local cache? This would make sense for audio and video.
>
>
> > There are certain security considerations. Auto downloading content to
> > display inline must require the receiver to trust/know the sender to
> > prevent abuse (spam, web bugs to expose IP). Additionally, any decisions
> to
> > download content based on the content size assumes the sender is honest
> > about size.
>
>
> --
> Kim "Zash" Alvefur
>
>
> ___
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
>
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0363 and Message MIME content type

[Kim Alvefur]

Hi,

On 01/29/2016 05:38 PM, Anurodh Pokharel wrote:
>  In the process of implementing XEP-0363  (HTTP file uploads
> http://xmpp.org/extensions/xep-0363.html) in Monal, I've come to the
> realization that it would make a lot of sense to include MIME content type
> and size in the message stanza.  I've done a bit of searching and I haven't
> found any XEP that defines this behavior.  If any of this sounds like it's
> already been done, please point me in the right direction.

It does not specify how the URL is sent. I know at least one
implementation just dumps it in a message , which would not let
you specify any additional metadata.

Something like OOB  combined
with SHIM  could carry more
detailed metadata.  Or Jingle FT with the HTTP transport method:


> Essentially as I understand it, the issue is HTTP file uploads are designed
> to solve the problem of people using dropbox or some other third party
> cloud service and replace that with an XMPP server that performs all of
> this internally.  This is great but simply posting a link to an image or
> video alone isn't very useful to the recipient. One way of resolving this
> is to have the receiving client present the link or preform an HTTP HEAD
> call  to try to determine the media type and based on the response try to
> display the content inline. The problem here are there is nothing in the
> spec that requires the server serving the "attachment" to  support HEAD.
> There is no guarantee that every HTTP configuration would allow this call.

I believe existing implementations do HEAD requests first to determine
size and content type. I *think* the HEAD method is required by the HTTP
specification.

> At the moment, on the client, we would have to scrape the URL to try to
> determine the media type (audio, video, image etc). While HEAD solves the
> problem,  I believe rather than require HEAD support, it may make sense to
> include the content type and size in the message stanza that has the URL of
> the uploaded file. This would be the same data passed to the server in the
> upload request.  HEAD would require 2 HTTP calls, first the HEAD to
> determine MIME  content type and and size and the second GET to fetch the
> actual media  The sender is aware of both the type and size and this allows
> the receiver to determine several things from the message stanza it self:
> 
> 1. Is it a format that can be displayed inline?
> 2. Is the file small enough to download automatically? In particular, this
> is a concern for mobile users.
> 3. Is the file in a format that can can be streamed rather than kept in a
> local cache? This would make sense for audio and video.


> There are certain security considerations. Auto downloading content to
> display inline must require the receiver to trust/know the sender to
> prevent abuse (spam, web bugs to expose IP). Additionally, any decisions to
> download content based on the content size assumes the sender is honest
> about size.


-- 
Kim "Zash" Alvefur



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0363 and Message MIME content type

[Daniele Ricci]

There wasn't much interest I think. But I have to say that I didn't
take the initiative either :-)
http://mail.jabber.org/pipermail/standards/2013-September/027992.html

On Fri, Jan 29, 2016 at 5:38 PM, Anurodh Pokharel  wrote:
> Hi all,
>  In the process of implementing XEP-0363  (HTTP file uploads
> http://xmpp.org/extensions/xep-0363.html) in Monal, I've come to the
> realization that it would make a lot of sense to include MIME content type
> and size in the message stanza.  I've done a bit of searching and I haven't
> found any XEP that defines this behavior.  If any of this sounds like it's
> already been done, please point me in the right direction.
>
> Essentially as I understand it, the issue is HTTP file uploads are designed
> to solve the problem of people using dropbox or some other third party cloud
> service and replace that with an XMPP server that performs all of this
> internally.  This is great but simply posting a link to an image or video
> alone isn't very useful to the recipient. One way of resolving this is to
> have the receiving client present the link or preform an HTTP HEAD call  to
> try to determine the media type and based on the response try to display the
> content inline. The problem here are there is nothing in the spec that
> requires the server serving the "attachment" to  support HEAD.  There is no
> guarantee that every HTTP configuration would allow this call.
>
> At the moment, on the client, we would have to scrape the URL to try to
> determine the media type (audio, video, image etc). While HEAD solves the
> problem,  I believe rather than require HEAD support, it may make sense to
> include the content type and size in the message stanza that has the URL of
> the uploaded file. This would be the same data passed to the server in the
> upload request.  HEAD would require 2 HTTP calls, first the HEAD to
> determine MIME  content type and and size and the second GET to fetch the
> actual media  The sender is aware of both the type and size and this allows
> the receiver to determine several things from the message stanza it self:
>
> 1. Is it a format that can be displayed inline?
> 2. Is the file small enough to download automatically? In particular, this
> is a concern for mobile users.
> 3. Is the file in a format that can can be streamed rather than kept in a
> local cache? This would make sense for audio and video.
>
> There are certain security considerations. Auto downloading content to
> display inline must require the receiver to trust/know the sender to prevent
> abuse (spam, web bugs to expose IP). Additionally, any decisions to download
> content based on the content size assumes the sender is honest about size.
>
>
> Thanks,
> -Anu
>
>
> ___
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>



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

[Standards] XEP-0363 and Message MIME content type

[Anurodh Pokharel]

Hi all,
 In the process of implementing XEP-0363  (HTTP file uploads
http://xmpp.org/extensions/xep-0363.html) in Monal, I've come to the
realization that it would make a lot of sense to include MIME content type
and size in the message stanza.  I've done a bit of searching and I haven't
found any XEP that defines this behavior.  If any of this sounds like it's
already been done, please point me in the right direction.

Essentially as I understand it, the issue is HTTP file uploads are designed
to solve the problem of people using dropbox or some other third party
cloud service and replace that with an XMPP server that performs all of
this internally.  This is great but simply posting a link to an image or
video alone isn't very useful to the recipient. One way of resolving this
is to have the receiving client present the link or preform an HTTP HEAD
call  to try to determine the media type and based on the response try to
display the content inline. The problem here are there is nothing in the
spec that requires the server serving the "attachment" to  support HEAD.
There is no guarantee that every HTTP configuration would allow this call.

At the moment, on the client, we would have to scrape the URL to try to
determine the media type (audio, video, image etc). While HEAD solves the
problem,  I believe rather than require HEAD support, it may make sense to
include the content type and size in the message stanza that has the URL of
the uploaded file. This would be the same data passed to the server in the
upload request.  HEAD would require 2 HTTP calls, first the HEAD to
determine MIME  content type and and size and the second GET to fetch the
actual media  The sender is aware of both the type and size and this allows
the receiver to determine several things from the message stanza it self:

1. Is it a format that can be displayed inline?
2. Is the file small enough to download automatically? In particular, this
is a concern for mobile users.
3. Is the file in a format that can can be streamed rather than kept in a
local cache? This would make sense for audio and video.

There are certain security considerations. Auto downloading content to
display inline must require the receiver to trust/know the sender to
prevent abuse (spam, web bugs to expose IP). Additionally, any decisions to
download content based on the content size assumes the sender is honest
about size.


Thanks,
-Anu
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___