[Standards] File hosting XEP?
Hello all, hope you are all good. Me and Jaussoin Timothée faced with a problem to attach files to microblog posts. The easier way to do that is to serve files somewhere and link to them from the posts. But what is the appropriate way to do that? 1) upload to a web server and link as http-link. But how to upload? If we will just create an API and then upload files through it then it will not be reusable. We have a XEP-0129 (WebDAV File Transfer) but it's deferred and doesn't determine some things like what exactly server we have to PUT files to. 2) Use native file serving protocol: we have XEP-0135 which is seems to be good for me, but it's deferred again and doesn't define a way to upload files to a hosting. Also, it doesn't support Jingle File Transfers. So it needs to be finished. Also, we have XEP-0214 which seems to me too complicated. And it's also deferred, not finished, without an ability to upload files. Also, we need an ability to make a link to files, which, possibly, will need an invitation of new link schema. (?) So, if we want to take care about finish, which XEP should it be? What is the other nuances or guidelines? Thanks. -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] File hosting XEP?
-Original Message- From: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] On Behalf Of Sergey Dobrov Sent: Tuesday, August 14, 2012 4:44 AM To: standards@xmpp.org Subject: [Standards] File hosting XEP? Hello all, hope you are all good. Me and Jaussoin Timothée faced with a problem to attach files to microblog posts. The easier way to do that is to serve files somewhere and link to them from the posts. But what is the appropriate way to do that? Having files somewhere and linking to them sounds a lot like Out-Of-Band Data (XEP-0066). It covers the linking part (mainly used in SI File Transfers and Message stanzas) and leaves the transferring of the files and how they are stored on the server to you. 1) upload to a web server and link as http-link. But how to upload? If we will just create an API and then upload files through it then it will not be reusable. We have a XEP-0129 (WebDAV File Transfer) but it's deferred and doesn't determine some things like what exactly server we have to PUT files to. 2) Use native file serving protocol: we have XEP-0135 which is seems to be good for me, but it's deferred again and doesn't define a way to upload files to a hosting. Also, it doesn't support Jingle File Transfers. So it needs to be finished. Also, we have XEP-0214 which seems to me too complicated. And it's also deferred, not finished, without an ability to upload files. Also, we need an ability to make a link to files, which, possibly, will need an invitation of new link schema. (?) Again, see if XEP-0066 is what you need. So, if we want to take care about finish, which XEP should it be? What is the other nuances or guidelines? Thanks. -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] File hosting XEP?
On 08/14/2012 07:47 PM, Todd Herman wrote: -Original Message- From: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] On Behalf Of Sergey Dobrov Sent: Tuesday, August 14, 2012 4:44 AM To: standards@xmpp.org Subject: [Standards] File hosting XEP? Hello all, hope you are all good. Me and Jaussoin Timothée faced with a problem to attach files to microblog posts. The easier way to do that is to serve files somewhere and link to them from the posts. But what is the appropriate way to do that? Having files somewhere and linking to them sounds a lot like Out-Of-Band Data (XEP-0066). It covers the linking part (mainly used in SI File Transfers and Message stanzas) and leaves the transferring of the files and how they are stored on the server to you. Sure, but how client will upload it's attachments? I can do it in a client-specific way, but then others will not be able to implement the same thing. -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Mon, Aug 13, 2012 at 1:06 PM, Kurt Zeilenga kurt.zeile...@isode.com wrote: The spec originally allowed previous non-last correction, and the community cried foul I found a thread that occurred during the initial consideration of the XEP (when it was proposed), starting at: http://mail.jabber.org/pipermail/standards/2011-November/025394.html I noticed that the original title did say Last. I see Ben Langfeld arguing that it shouldn't be restricted to last. I see Dave Cridland being mildly terrified about allowing change to any previous message. And your response. Not much crying. Was there some other thread? Ok, perhaps it's just illustrates the need to be very plainly clear within Security Considerations -- about the privacy/security implications of permitting message correction, and to mention that the UI needs to be very plainly clear that message correction is going on. In fact, message correction doesn't have to defacto replace the old stanza, but display it as an addendum (with a very clear EDITED tag or icon).Discussion forums, Facebook, etc, allowing editing -- they often to give you access to old versions of the text (revision history accessible by end user). And the edited version can be color coded out. Implementers are smart enough to be creative here, but we don't need to include such implementation detail. So I'd say, just enhance the Security Considerations to satisfy the terrified people -- obvious stuff to make sure implementers avoid abuse. We know we don't want it to be 'abused' for general-purpose messaging, and the pressure for accountability will ensure that implementers do it properly, if implementers choose to permit it during general-purpose messaging. Also, make sure that the protocol and spec is written as such that multi-message correction doesn't screw up with 1-message orrection. As I've learned with 0301 (har har) there's also the temptation to include the kitchen sink (e.g. disco for # of messages allow to correct, server disco for permissions, disco for time limit of message correction, etc) but I'd leave that out today -- and theoretically that can be dealt with separately someday (e.g. separate Message Correction Extensions XEP), provided the protocol is written generically enough today to be acceptable without that now, while being co-operative with future disco extensions. Mark Rejhon
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/13/12 3:03 PM, Andreas Kuckartz wrote: Kurt Zeilenga: From a user perspective, often what I want to correct isn't the last stanza I sent. I support that argument. Several Social Networking Services provide similar features and I expect XMPP to also support that. rantLook, folks, if we want the ability to reach back and edit everything under the sun, then by all means let's define that using pubsub under something like XEP-0277. IM, by contrast, is an ever-flowing stream and sometimes you make mistakes when typing such messages (as people do in email messages to lists like this one). Do you have the ability to edit every email message you've ever sent? No, so just get over it./rant Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAqdAYACgkQNL8k5A2w/vy1bACggPxlTVpMwyUnQVvojBO6DOfO d4cAoJnZ+wBlRfP9gpUerv0DiLCf0PEd =gHS2 -END PGP SIGNATURE-
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/14/12 9:51 AM, Peter Saint-Andre wrote: On 8/13/12 3:03 PM, Andreas Kuckartz wrote: Kurt Zeilenga: From a user perspective, often what I want to correct isn't the last stanza I sent. I support that argument. Several Social Networking Services provide similar features and I expect XMPP to also support that. rantLook, folks, if we want the ability to reach back and edit everything under the sun, then by all means let's define that using pubsub under something like XEP-0277. IM, by contrast, is an ever-flowing stream and sometimes you make mistakes when typing such messages (as people do in email messages to lists like this one). Do you have the ability to edit every email message you've ever sent? No, so just get over it./rant In fact, I'd argue that this spec is a technical solution to a social problem, and thus is wrongheaded. It's easy enough to send a new message correcting the old one (e.g., sorry, I meant to say Y instead of X or s/X/Y/). People do that all the time. Magically and invisibly changing a message after the fact strikes me as a really bad idea. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAqdXEACgkQNL8k5A2w/vxNAgCguIGgTZYYLeXFm/TkGPPkonQM YFcAniN5KfWX2x9uY3jbasHs8+WDW9pT =xURZ -END PGP SIGNATURE-
Re: [Standards] File hosting XEP?
Sure, but how client will upload it's attachments? I can do it in a client-specific way, but then others will not be able to implement the same thing. If I understand correctly, what you want to do is to attach files to a microblog post. Since you can use Out of Band Data for that, you can upload the file out of band without the need of xmpp e.g. uploading it to an FTP. True, the client has to be modified to support this, but since it isn't covered in any XEP afaik, you would have to modify it anyway. Therefore, your client will be able to upload files while other clients will not until their devs deem it a necessary feature. On Tue, Aug 14, 2012 at 9:04 AM, Sergey Dobrov bin...@jrudevels.org wrote: On 08/14/2012 07:47 PM, Todd Herman wrote: -Original Message- From: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] On Behalf Of Sergey Dobrov Sent: Tuesday, August 14, 2012 4:44 AM To: standards@xmpp.org Subject: [Standards] File hosting XEP? Hello all, hope you are all good. Me and Jaussoin Timothée faced with a problem to attach files to microblog posts. The easier way to do that is to serve files somewhere and link to them from the posts. But what is the appropriate way to do that? Having files somewhere and linking to them sounds a lot like Out-Of-Band Data (XEP-0066). It covers the linking part (mainly used in SI File Transfers and Message stanzas) and leaves the transferring of the files and how they are stored on the server to you. Sure, but how client will upload it's attachments? I can do it in a client-specific way, but then others will not be able to implement the same thing. -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder. -- Jefry Lagrange
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
I think XEP 308 is actually going to lead to a lot of user confusion. The problem is that corrections are actually counter to the chat or conversational model. In the real world (i.e., face-to-face conversation), there's no rewind button. If you make an error, you have to say something like: Pardon me, I meant no when I said yes. And in today's XMPP IM use, we have shorthands for this, like, I can send: s/yes/no/ to correct a previous yes. The problem I have with XEP 308, is that that the fact that's a correction is a correction will be lost upon users which don't use clients which support XEP 308. Illustration: you: Question? me: yes then as you send Really?, I send correction from yes to no. If your client doesn't support corrections, you see: you: Really? me: no and I see: you: Question? me: no you: Really? to which I now respond, yes. So we've conclude our discussion, but without understanding that I corrected my first answer to your first question. Now if XEP 308 were only sent when the client new the receiving client(s) supported XEP 308, then we'd assured to that at some indication of correction was presented to the reader. But 308 doesn't require sending clients do discovery and not offer correction when the receiving clients(s) don't support XEP 308. And even if 308 did mandate such, many client developers would likely ignore the requirement. But a mandate would be a good start. Use in MUC will always be problematic, me thinks. -- Kurt
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Aug 14, 2012, at 8:57 AM, Peter Saint-Andre stpe...@stpeter.im wrote: In fact, I'd argue that this spec is a technical solution to a social problem, and thus is wrongheaded. It's easy enough to send a new message correcting the old one (e.g., sorry, I meant to say Y instead of X or s/X/Y/). People do that all the time. Magically and invisibly changing a message after the fact strikes me as a really bad idea. The more I think about it, the more I think I that this XEP is a bad idea. Basically, the kind of user confusion I illustrated in by prior post can really only be addressed if this extension is mandatory to implement (for all clients). And, I don't think extensions should be mandatory to implement. They should be truly optional. -- Kurt
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On 2012-08-14 20:09, Kurt Zeilenga wrote: On Aug 14, 2012, at 8:57 AM, Peter Saint-Andre stpe...@stpeter.im wrote: In fact, I'd argue that this spec is a technical solution to a social problem, and thus is wrongheaded. It's easy enough to send a new message correcting the old one (e.g., sorry, I meant to say Y instead of X or s/X/Y/). People do that all the time. Magically and invisibly changing a message after the fact strikes me as a really bad idea. The more I think about it, the more I think I that this XEP is a bad idea. Basically, the kind of user confusion I illustrated in by prior post can really only be addressed if this extension is mandatory to implement (for all clients). And, I don't think extensions should be mandatory to implement. They should be truly optional. -- Kurt I think this extension gets rid of one annoying characteristic of XMPP IM. - The message borderline being an artificial borderline for corrections. If an implementer really thinks it is risky, and that it can cause undetected modifications, then the implementation can require from the user that there is no text in the current message before the last message may be entered for correction. So, if you have started to type the new current message, you need to erase it before entering the previous message for correcting it. That will make corrections appear with care and only when it is felt efficient by the typing user. There is no difference in the protocol for this feature, so it does not need to influence the specification. I hope that the current discussion, with some voices saying that correction of last message should not be allowed, will not influence the acceptance of XEP-0308. /Gunnar
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) - Logic of example 1.
On 2012-08-14 03:09, Mark Rejhon wrote: Barry may have presented a compromise I can accept. The first (introductory) stanza is still full word, and the second and third is not too difficult for most readers to figure out. On 2012-08-13 8:44 PM, Barry Dingle btdin...@gmail.com mailto:btdin...@gmail.com wrote: Mark, Regarding the example in 4.1, I agree with Gunnar. The first example gives the wrong initial impression by sending only complete words in the rtt/. (It made me go and double check how the protocol worked.) I suggest that we keep the first rtt/ as is, but slightly change the second and third rtt/ text contents to: *tmy J**/t* and *tuliet!/t* respectively. This retains the readability but also shows that the rtt/ is sent independently of word boundaries. Cheers, /Barry This was item #5 Let us try to keep track of the issue numbers and their state. I accept the solution. /Gunnar
[Standards] XEP-0308 and Linear Real-Time Text (TDD/textphones) - it is NOT a technical solution to social problem in this case.
On Tue, Aug 14, 2012 at 3:21 PM, Kim Alvefur z...@zash.se wrote: On 2012-08-14T20:09:28 CEST, Kurt Zeilenga wrote: The more I think about it, the more I think I that this XEP is a bad idea. I think the concept itself is a bad idea, but since some people really want to have this feature, having a XEP for it might be better than not having one. I do agree with Peter about this largely being a technical solution to a social problem. Actually, not necessarily a technical solution to a social problem, for certain situations: It solves the linear real-time text problem. TDD's (text telephones) transmit as a single stream of continuous real time text, with no message boundaries. Gatewaying instant messaging (with XEP-0301 real time text) to text telephones or other linear real-time text technologies, represents some compromises when needing to backspace across message boundaries (e.g. to the previous message). The existence of XEP-0308 solves this problem. And, the existence of multiple-message correction allows backspacing back across more than one message (especially if several Enter keypresses were accidentally hit on a TDD / text telephone) Therefore, XEP-0308 (as agreed by me and Gunnar) is one solution to the linear real time text problem; it makes it possible to backspace across message boundaries, when gatewaying between linear real-time text to instant messaging, and vice-versa. Sincerely, Mark Rejhon
Re: [Standards] XEP-0308 and Linear Real-Time Text (TDD/textphones) - it is NOT a technical solution to social problem in this case.
On Tue, Aug 14, 2012 at 11:37 PM, Mark Rejhon marky...@gmail.com wrote: On Tue, Aug 14, 2012 at 3:21 PM, Kim Alvefur z...@zash.se wrote: On 2012-08-14T20:09:28 CEST, Kurt Zeilenga wrote: The more I think about it, the more I think I that this XEP is a bad idea. I think the concept itself is a bad idea, but since some people really want to have this feature, having a XEP for it might be better than not having one. I do agree with Peter about this largely being a technical solution to a social problem. Actually, not necessarily a technical solution to a social problem, for certain situations: It solves the linear real-time text problem. TDD's (text telephones) transmit as a single stream of continuous real time text, with no message boundaries. Note -- RFC4103 is another linear real-time text technology that has no concept of message boundaries. (On RFC4103, you can backspace linefeeds). So the combination of 0301 and 0308 can enhances gateway interop with linear real-time text technologies; Sincerely, Mark Rejhon Gatewaying instant messaging (with XEP-0301 real time text) to text telephones or other linear real-time text technologies, represents some compromises when needing to backspace across message boundaries (e.g. to the previous message). The existence of XEP-0308 solves this problem. And, the existence of multiple-message correction allows backspacing back across more than one message (especially if several Enter keypresses were accidentally hit on a TDD / text telephone) Therefore, XEP-0308 (as agreed by me and Gunnar) is one solution to the linear real time text problem; it makes it possible to backspace across message boundaries, when gatewaying between linear real-time text to instant messaging, and vice-versa. Sincerely, Mark Rejhon
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Tue, Aug 14, 2012 at 1:44 PM, Kurt Zeilenga kurt.zeile...@isode.com wrote: I think XEP 308 is actually going to lead to a lot of user confusion. The problem is that corrections are actually counter to the chat or conversational model. In the real world (i.e., face-to-face conversation), there's no rewind button. If you make an error, you have to say something like: Pardon me, I meant no when I said yes. And in today's XMPP IM use, we have shorthands for this, like, I can send: s/yes/no/ to correct a previous yes. The problem I have with XEP 308, is that that the fact that's a correction is a correction will be lost upon users which don't use clients which support XEP 308. Illustration: you: Question? me: yes then as you send Really?, I send correction from yes to no. If your client doesn't support corrections, you see: you: Really? me: no and I see: you: Question? me: no you: Really? to which I now respond, yes. So we've conclude our discussion, but without understanding that I corrected my first answer to your first question. Now if XEP 308 were only sent when the client new the receiving client(s) supported XEP 308, then we'd assured to that at some indication of correction was presented to the reader. But 308 doesn't require sending clients do discovery and not offer correction when the receiving clients(s) don't support XEP 308. And even if 308 did mandate such, many client developers would likely ignore the requirement. But a mandate would be a good start. Use in MUC will always be problematic, me thinks. Kurt brings up a good case for making 0308 disco a requirement, though several considerations first, arguing towards 0308 from another angle: 1. Kurt's scenario can also occur during traditional corrections no - oops, yes, when there's a high network latency for delivery. (causing message-crossed-each-other scenarios) In such a situation, the message history order on the recipient is not necessarily the same as the message history order on the sender. This problem is widespread when network latencies become very high (and when message delivery receipts timestamps are not used to reorder the messages to sync message history order on both sender and recipient). It's a common problem on other networks, such as SMS. It's already caused huge numbers of misunderstandings, when the word yes references a different message at the recipient end than sender end. Also, overloaded servers, including for MUC, inject latency sufficient enough to cause message-crossed-each-other scenarios too. 2. In such scenarios (overloading) user behaviour has already adapted to be cautious of sending one-word responses to rapid questions. Users already adapt to behavior. 3. The advantages outweigh the disadvantages. Present instant messaging has its own existing social problems, and general purpose instant messaging (or even texting) is already a (mostly great) technical solution to many of them already. Messaging is an artificial invented solution that has its own excellent pros and cons. I'll compare the social problems with the social advantages in a balanced way: -- e.g. messaging social problems include multitasking distractions, wrong-window messaging, lack of emotion transmission, message boundaries preventing natural conversation afforded via alternate means (e.g. audio, video, real time text), the average increase of information overload for the average human, etc. Instant messaging is already an artifical solution to life in society. -- e.g. messaging social advantages include catering to fastest human method of input: reading - humans can speedread hundreds of WPM (usually faster than listening), ability to re-read text easily (you can't replay a live telephone conversation easily), asynchronousness of message-by-message makes it easier to multitask multiple conversations at the same time discreetly, the quietness of text based communications keeping work environments less noisy, the ease of logging text-based conversations, etc. Given such a perspective (chat is just a technical solution to a social problem), I believe it's just merely status quo feelings that is providing 0308 resistance. Thanks Mark Rejhon
