Re: [Standards] XEP-0313 Message Archive Management Message Removal
On 18 May 2013 14:33, Kim Alvefur wrote: > On Sat, 18 May 2013, 14:23:43 CEST, Spencer MacDonald > wrote: >> Also you may say something that is "confidential" that you might want to >> remove after the recipient has acknowledged it. > > You really want to use some end-to-end encryption for that. > > Carbons (XEP-280) has a method for excluding single messages from processing. > That could be used to signal a wish for having a message excluded from > archiving, possibly broken out into a XEP of its own. +1, I like that approach (partly because it doesn't necessarily need adding to XEP-0313, yay!). XEP-0136's controls for this were quite complicated, but a simple tag that disables carbons, archiving and perhaps other kinds of server processing would be quite welcome. > Or maybe security-labels. Now you go and ruin it... :) Regards, Matthew
Re: [Standards] Using .well-known/ to supplement XEP-0156
Hello > So XEP-0156 details how to use DNS records to advertise alternative ways to > connect to an XMPP server, namely BOSH and soon WebSocket. That's great, > except that in the browser you can't make arbitrary DNS requests, which > severely limits the usefulness of this method. > >Any interest in standardizing some .well-known/ document to expose alternative >connection endpoints? There's probably something like this that already exists >that we can profile or register with, right? > >-- Lance What about the UPnP method? Using SSDP? Creating some well defined UPnP Device interface for XMPP Servers & XMPP Clients, perhaps exposing the features of each device at the same time? Saves time as you don't have to do service discovery on each device. Sincerely, Peter Waher
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
On Sat, May 18, 2013 at 1:04 PM, XMPP Extensions Editor wrote: > Version 0.9 of XEP-0301 (In-Band Real Time Text) has been released. > Abstract: This is a specification for real-time text transmitted in-band > over an XMPP session. > Real-time text is text transmitted instantly while it is being typed or > created. > URL: http://xmpp.org/extensions/xep-0301.html There is now multiple open-source implementations of XEP-0301 to try: 1. Easy: Web based version. Just logon using Google credentials and chat XEP-0301 right away. http://tap.gallaudet.edu/rtt/ (This is a strophe.js JavaScript XEP-0301 plugin; Chris Vogler will release it on GIT shortly). 2. Downloadable C# client for XEP-0301 for Windows. http://www.realjabber.org/ They also interop with each other. There are also other prototype implementations (e.g. Gunnar's Omnitor, Indigital Inc., Gregg Vanderheiden's Trace Center), which are not listed here. Gallaudet Univerity's TAP (Technology Access Program) released the Javascript version of XEP-0301, showing real-time text streaming between web browsers. We all have unamious agreement that XEP-0301 is mature for LAST CALL. The out-in-open independently developed implementations is proof. I am hereby submitting a request to XSF to proceed with LAST CALL. Sincerely, Mark Rejhon Primary Author of XEP-0301
Re: [Standards] XEP-0313 Message Archive Management Message Removal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/18/13 6:23 AM, Spencer MacDonald wrote: > No problem, I can understand your concerns as XEP-0136 is very > bloated and complicated. > > Simply if you say something that is incorrect or in the wrong chat > then you will want to delete it. > > Also you may say something that is "confidential" that you might > want to remove after the recipient has acknowledged it. > > XEP-0308: Last Message Correction, kind of deals with these issues > but unless you fetch your entire archive you might not get the > corrections for previous messages. > > Maybe the solution isn't Message Removal, but rather better > integration between these 2 XEPs. Sounds reasonable. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRl7PRAAoJEOoGpJErxa2pXKEQAIulJYirAa7XGhlUJwQeuSRd XZM8Pm4zMaP7q1iCL4F5ym5H4/jheDfhamBeDD7mi6ZtNJN18X91xFQHnZPKVPVA 03rSfK/ybJJydXLKIPAojxT486D0X80spzCblE0cSaXywFMjibW4rxXvCqgvuFLe u9X7Sr/ZlcwpssiU0rBEhiZsq+/lZiSFIe18dL0ejs3O4VH4s0yBxCymAmRSHNbf OrBvVgSdp+PRdhpynd/HKQgXJb551EjvYKKDGUyuu4tNZVdAyQeO/yyepXXngLTw mVUWWtqsp8BZTU7NfLEVme089sW6fB+X5Bq6BlwRm+2kbr7JIOrtWqsmKnJH0ZHb c5VXlbX3pMfoxW7KRC65rjgMr2B81Br1dHm3Z47JODoZ+ph3QMYZ86CPfY4NzSLf 7waXUJW8bQhiB1+Vo7H+mjfukn0/bKd1/tpthhPf0vyF4FCtOcojmA8iD+/9ue2z 8CRz6vQPX2cmiqiCFKOCT/odDKNTag8ajm1tqWUxSxHEiS9K1n45psGwyjPi3tJM W/EM3fklxlzmJWOceJHF4DAK2rBY5Gvk74KCfpaxMWOKME6t9naiJHfXfxAPZh1/ bMcZYigDKVl+YwuMIiXHWlJkgKVC9pm6bW1zTwfQdwiipRwa5sm7lEPih7lxOK1m 1Ywluc6yq6ohvs7/bkTS =9Z9C -END PGP SIGNATURE-
[Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
Version 0.9 of XEP-0301 (In-Band Real Time Text) has been released. Abstract: This is a specification for real-time text transmitted in-band over an XMPP session. Real-time text is text transmitted instantly while it is being typed or created. Changelog: Minor corrections and clarifications. (MDR) Diff: http://xmpp.org/extensions/diff/api/xep/0301/diff/0.8/vs/0.9 URL: http://xmpp.org/extensions/xep-0301.html
Re: [Standards] Using .well-known/ to supplement XEP-0156
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/18/13 8:50 AM, Matthew Wild wrote: > On 18 May 2013 14:44, Matthew Miller > wrote: >> As a self-proclaimed member of the DNS anti-proliferation league, >> I fully support this. (-: > > Let's just define a way to put arbitrary TXT records in > .well-known, and make way for the inevitable DNS over HTTP. As they > say, if you can't beat them... > > But yes, BOSH is an interesting case because the clients that > would want to use it also generally can't access DNS. I think it > would be worth adding to XEP-0153. s/0153/0156/ The "let's put arbitrary discovery information in DNS TXT records" idea was a hack to avoid registering new DNS RRs (which was perceived as hard). The webby approach is to use well-known URIs (RFC 5785), web linking (RFC 5988), host-meta and JRD files (RFC 6415), and in some cases WebFinger instead of DS TXT records. Pick your poison. I suggest that we update XEP-0156 to document the webby approach in addition to the TXT approach, and include a method for WebSocket. Then the XMPP Registrar can register the new link relations with the IANA: http://www.iana.org/assignments/link-relations/link-relations.xml Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRl7IKAAoJEOoGpJErxa2pGqIP/1cRN14T828vTr3SmEjT2LsA oSp/aJJxjwoGkU/sgcxyGynmQF1ymQL2ezrjk5tdwlj3M/ClWtD+sVtic9bf2A9u tnIKnUA1b4sWnt3vV6BR8oJrvIefOE2iOLnrYvZmdcZ09Yx770CXw+MMHT3Heybl oeYSjGd8Lt2eI1bKrANSUAdW86XYPx5tzBb1IlmqV+onWGikXRsHwCmwo4J5/DG2 M/YgYQkdDab2G25A2Dpr8RXHmKvNvCz9bc0S5ChBar7PfrB5pB/sJU4wbfteaVPb KMPEO13fowBXrLQNmiAc2OtELwXa4XD/tdUyHOgP2Kltqw7xDRlNup9GRScm1sNH sGxjIfRMCVaTooeK5TQAG7GOSSuDsvSKWjDXxrzFYvwbGAK/8lk/b8R339dSZGdV sFBbEg1+BjBqAwrIjY4Qw9W4wv7CDjppgtt4wCtCJ28NhUwauEIbEuMPQRcLj/8m ieHsCkmpI8AyeKw6mX8NX7kVxA1Z4AS8BPe2NTQT46Ap8iAJAhRedF3QiLSq3tP5 vJo8U8rZvotaDjo4TQhBcLFcoTeboKhvdAb7Zc/ALP8KA2ym5J9QGvXm6nfdzXGT 5i5wpO86tSDNwiSMX7ir4oTJsPSJGWr/ABb+DKcTpznPhYStOOi9O8Xp/TuHQfUQ DLUUiJ8BacY3WAEmnWWR =DurO -END PGP SIGNATURE-
Re: [Standards] Using .well-known/ to supplement XEP-0156
On 2013-05-18 15:44, Matthew Miller wrote: > As a self-proclaimed member of the DNS anti-proliferation league, I fully > support this. (-: As a self-proclaimed member of the anti-HTTP resistance, I wish to express my great annoyance. :P -- Kim signature.asc Description: OpenPGP digital signature
Re: [Standards] Using .well-known/ to supplement XEP-0156
On 18 May 2013 14:44, Matthew Miller wrote: > As a self-proclaimed member of the DNS anti-proliferation league, I fully > support this. (-: Let's just define a way to put arbitrary TXT records in .well-known, and make way for the inevitable DNS over HTTP. As they say, if you can't beat them... But yes, BOSH is an interesting case because the clients that would want to use it also generally can't access DNS. I think it would be worth adding to XEP-0153. Regards, Matthew
Re: [Standards] Using .well-known/ to supplement XEP-0156
As a self-proclaimed member of the DNS anti-proliferation league, I fully
support this. (-:
I'd be happy to help out this together. It would help solve some problems
we are facing.
- m&m
{mobile}
On May 18, 2013 7:38 AM, "Peter Saint-Andre" wrote:
> +1. Yes there is a registry at IANA, I can provide pointers a bit later.
>
> Sent from mobile, might be terse
>
> On May 17, 2013, at 8:12 PM, Lance Stout wrote:
>
> > So XEP-0156 details how to use DNS records to advertise alternative ways
> to connect to an XMPP server, namely BOSH and soon WebSocket. That's great,
> except that in the browser you can't make arbitrary DNS requests, which
> severely limits the usefulness of this method.
> >
> > Any interest in standardizing some .well-known/ document to expose
> alternative connection endpoints? There's probably something like this that
> already exists that we can profile or register with, right?
> >
> > -- Lance
>
Re: [Standards] Using .well-known/ to supplement XEP-0156
+1. Yes there is a registry at IANA, I can provide pointers a bit later. Sent from mobile, might be terse On May 17, 2013, at 8:12 PM, Lance Stout wrote: > So XEP-0156 details how to use DNS records to advertise alternative ways to > connect to an XMPP server, namely BOSH and soon WebSocket. That's great, > except that in the browser you can't make arbitrary DNS requests, which > severely limits the usefulness of this method. > > Any interest in standardizing some .well-known/ document to expose > alternative connection endpoints? There's probably something like this that > already exists that we can profile or register with, right? > > -- Lance
Re: [Standards] XEP-0313 Message Archive Management Message Removal
On Sat, 18 May 2013, 14:23:43 CEST, Spencer MacDonald wrote: > Also you may say something that is "confidential" that you might want to > remove after the recipient has acknowledged it. You really want to use some end-to-end encryption for that. Carbons (XEP-280) has a method for excluding single messages from processing. That could be used to signal a wish for having a message excluded from archiving, possibly broken out into a XEP of its own. Or maybe security-labels. -- Kim
Re: [Standards] XEP-0313 Message Archive Management Message Removal
No problem, I can understand your concerns as XEP-0136 is very bloated and complicated. Simply if you say something that is incorrect or in the wrong chat then you will want to delete it. Also you may say something that is "confidential" that you might want to remove after the recipient has acknowledged it. XEP-0308: Last Message Correction, kind of deals with these issues but unless you fetch your entire archive you might not get the corrections for previous messages. Maybe the solution isn't Message Removal, but rather better integration between these 2 XEPs. Regards Spencer On Sat, May 18, 2013 at 12:46 PM, Matthew Wild wrote: > Hi, > > On 17 May 2013 20:49, Spencer MacDonald > wrote: > > One of the features from XEP-0136 that I would like to see included in > > XEP-0313 is message removal. > > > Would it be possible to include this? > > Without saying yes or no... I'll just ask, what's the actual use case? > > I am really keen to prevent feature creep in this specification. After > all, pretty much everything in XEP-0136 was wanted by somebody at some > point. If we similarly include everything everyone asks for then the > new specification will end up a pointless exercise - we'll just end up > with XEP-0136 under a new namespace. > > Regards, > Matthew >
Re: [Standards] XEP-0313 Message Archive Management Message Removal
Hi, On 17 May 2013 20:49, Spencer MacDonald wrote: > One of the features from XEP-0136 that I would like to see included in > XEP-0313 is message removal. > Would it be possible to include this? Without saying yes or no... I'll just ask, what's the actual use case? I am really keen to prevent feature creep in this specification. After all, pretty much everything in XEP-0136 was wanted by somebody at some point. If we similarly include everything everyone asks for then the new specification will end up a pointless exercise - we'll just end up with XEP-0136 under a new namespace. Regards, Matthew
