Re: [Standards] Security issues with XHTML-IM (again)

> On 13 Oct 2017, at 15:14, Sam Whited wrote: > > On Fri, Oct 13, 2017, at 03:55, Kevin Smith wrote: >> But I think that it’s fundamentally weird to claim that when >> implementing markdownish, non-diligent devs won’t just inject HTML, but >> while implementing XHTML-IM they will. > > I agree.

Re: [Standards] "Self-destruct" message timeout deletion hints

> On 1 Nov 2016, at 17:43, forenjunkie wrote: > > But it doesnt work with a decentral, open source kind of system. > > a feature like that depends on the other side deleting the message. > > you are lying to your users the minute you offer this feature in your client > and not show a disclaim

Re: [Standards] MIX progress

> On 5 Jul 2016, at 10:11, Florian Schmaus wrote: > > On 05.07.2016 10:56, Ashley Ward wrote: >> >>> On 5 Jul 2016, at 09:51, Florian Schmaus wrote: >>> >>> On 05.07.2016 10:08, Evgeny Khramtsov wrote: >>>> Tue, 5 Jul 2016 09:55:53 +

Re: [Standards] MIX progress

> On 5 Jul 2016, at 09:56, Ashley Ward wrote: > > >> On 5 Jul 2016, at 09:51, Florian Schmaus wrote: >> >> On 05.07.2016 10:08, Evgeny Khramtsov wrote: >>> Tue, 5 Jul 2016 09:55:53 +0200 >>> Florian Schmaus wrote: >>> >>&g

Re: [Standards] MIX progress

> On 5 Jul 2016, at 09:51, Florian Schmaus wrote: > > On 05.07.2016 10:08, Evgeny Khramtsov wrote: >> Tue, 5 Jul 2016 09:55:53 +0200 >> Florian Schmaus wrote: >> >>> I'd also welcome if XEP development, especially for such an important >>> one like MIX, would be more open. >> >> For the recor

Re: [Standards] Proposed XMPP Extension: Content Types in Messages

> On 19 Jan 2016, at 19:41, Matthieu Rakotojaona > wrote: > > It looks like this XEP hands messages that have a single > element, but the RFC says you can have multiple elements, each with > its own xml:lang. Is it expected that this works only with single > elements ? > > Side question: are

Re: [Standards] XEP-0314 Security Labelling in Pubsub

> On 12 Jan 2016, at 10:14, Dave Cridland wrote: > > What I'd prefer is that we make it a (negotiated) child of the . So > that's what I've actually written. > > The reasons we didn't go this route were because the element contains > only one element, the payload. I'm thinking that - with ne

Re: [Standards] Markdown in XMPP IM

> On 7 Jan 2016, at 12:44, Peter Waher wrote: > > Hello all > > > If anything we should define a small microformat that looks good > > formatted or in plain text (which could just be a specific Markdown > > flavor minus the raw HTML stuff) and mandate that all clients that > > support the spec

Re: [Standards] Markdown in XMPP IM

> On 6 Jan 2016, at 19:29, Dave Cridland wrote: > > > Ash's suggestion of an additional marker element is probably easier for most > implementations to handle, though. > > Not particularly keen on an alternate body, since the only thing I can think > of to sensibly degrade Markdown into is i

Re: [Standards] Markdown in XMPP IM

> On 6 Jan 2016, at 18:04, Travis Burtrum wrote: > > On 01/06/2016 12:53 PM, Ashley Ward wrote: >> text/x-markdown > > Except markdown means nothing, there is no standard, and no common > implementation. > > I love markdown, but just because your markdown convert

Re: [Standards] Markdown in XMPP IM

> On 6 Jan 2016, at 16:28, Goffi wrote: > > Le mercredi 6 janvier 2016, 15:29:31 Peter Waher a écrit : > >>> Alternatively, if it's just about easier input, support Markdown on >>> the sending side and use XHTML-IM. I don't think we really need more >>> ways of formatting messages. >> >> You w

Re: [Standards] Markdown in XMPP IM

> On 6 Jan 2016, at 16:28, Goffi wrote: > > Le mercredi 6 janvier 2016, 15:29:31 Peter Waher a écrit : > >>> Alternatively, if it's just about easier input, support Markdown on >>> the sending side and use XHTML-IM. I don't think we really need more >>> ways of formatting messages. >> >> You w

Re: [Standards] Proposed XMPP Extension: Jingle ICE Transport Method

> On 17 Dec 2015, at 15:15, Peter Saint-Andre wrote: > > The trickle reference needs to point to draft-ietf-ice-trickle too. > > Sent from mobile, might be terse Yeah, I noticed and corrected that shortly after I published it (My bad, although I’m going to blame it on Google’s result order!)

Re: [Standards] Proposed XMPP Extension: Jingle ICE Transport Method

> On 17 Dec 2015, at 12:49, Philipp Hancke wrote: > > Also, the 6544 reference is not work in progress ;-) Thanks Philipp, I’ve updated the reference to 6544 in the entities file and rebuilt the html. — Ash smime.p7s Description: S/MIME cryptographic signature ___

Re: [Standards] Deprecating IBR

> On 11 Nov 2015, at 11:42, Georg Lukas wrote: > > * Dave Cridland [2015-11-11 08:58]: >>> What do you suggest to replace it with? >> [...] we need, I think, a mechanism which takes a potential new user >> through new account creation, and helps in configuring their client, >> and ideally works

Re: [Standards] IQ type=set to query messages in XEP-0313

Maybe it's because it’s not actually getting something as part of the iq, but actually just triggering a replay of the message archive? — Ash > On 27 Oct 2015, at 10:45, Michael Uvarov wrote: > > Hi, > > I have a question about XEP-0313. > There is part that is counterintuitive: > > Example

Re: [Standards] script running amok?

On 9 Feb 2015, at 08:21, Stefan Strigler wrote: > > Hey there! > > Found these in hundreds this morning in editors inbox: > > From: standards@xmpp.org on Fri Feb 6 09:20:15 > 2015 > Subject: There where errors during the run of > /home/xsf/editor-auto-test/xsf-too

Re: [Standards] What does "The message headers matched a filter rule" mean?

> On 21 Nov 2014, at 16:04, Peter Waher wrote: > > I’ve tried (unsuccessfully) to mail the editor, and always get the response > the message is held until the list moderator can review it for approval, > based on the fact that “The message headers matched a filter rule”. What does > this mean?

Re: [Standards] OTR

On 7 Nov 2014, at 15:27, Peter Saint-Andre - &yet wrote: > > On 11/7/14, 7:39 AM, Stefan Strigler wrote: >> 2014-11-07 13:02 GMT+01:00 Winfried Tilanus > >: >> >>On 11/07/2014 10:55 AM, Dave Cridland wrote: >> >>> Is anyone willing to help work on a XEP to e

Re: [Standards] Whiteboarding with XMPP

On 23 Sep 2014, at 16:01, Steven Lloyd Watkin wrote: > How similar is the spec to HTML5 canvas drawing methods? It would be great if > we could get something that matched that as closely as possible, meaning > browser whiteboarding apps would be very simple to create using XMPP. I think most

Re: [Standards] Cleaning the Wiki

On 2 Sep 2014, at 11:28, Kevin Smith wrote: > On Tue, Sep 2, 2014 at 11:16 AM, Ashley Ward wrote: >> I can imagine a world of fairies and unicorns where (for example) we have an >> (openid enabled) gitlab, sufficiently automated that we have a repo per xep >> which is wr

Re: [Standards] Cleaning the Wiki

On 2 Sep 2014, at 11:29, Kevin Smith wrote: > On Tue, Sep 2, 2014 at 11:27 AM, Kevin Smith wrote: >> On Tue, Sep 2, 2014 at 8:12 AM, Ashley Ward wrote: >>> I think there are enough people talking about his that we could add this to >>> discuss as a summit agenda i

Re: [Standards] Cleaning the Wiki

On 2 Sep 2014, at 07:54, Cramer, E.R. (Eelco) wrote: > At my office I run a gitlab server that we use for our projects. > > Both the hosted gitlab at http://gitlab.com as a self hosted instance of the > gitlab community edition support multiple ways of signing up (using an openid > account, a

Re: [Standards] Cleaning the Wiki

On 2 Sep 2014, at 09:17, Kevin Smith wrote: > There's an assumption running through a lot of posts in this thread > that moving to a github-like pull request model would be a good thing. > Our situation is somewhat different to the typical OSS project hosting > on github. The primary responsibili

Re: [Standards] Cleaning the Wiki

Excuse the top post, I'm on my phone. I personally think GitHub would work really well for this workflow for a number of reasons. It's simple for anyone to obtain an account, it would encourage more people to contribute, it lowers the barrier and makes changes much less onerous, encouraging minor

Re: [Standards] Patches for XEP-45: Multi-User Chat

On 1 Sep 2014, at 08:47, Florian Schmaus wrote: > since my merge requests at > https://gitorious.org/xmpp/xmpp/merge_requests got unnoticed, I was told > to use the standards ML instead. The editor team are currently working on a git based workflow which should make this sort of thing actually

Re: [Standards] [buddycloud-dev] XEP-0060 and mark read up to point.

On 28 Jul 2014, at 18:14, Simon Tennant wrote: > IMHO this is something that should be solved in that node rather than running > parallel nodes or adding a PEP dependency. > > Almost like returning a different metadata key-value pair to each requesting > JID. Now you mention it, it feels like

Re: [Standards] [buddycloud-dev] XEP-0060 and mark read up to point.

On 28 Jul 2014, at 14:06, Simon Tennant wrote: > For buddycloud channels, we're looking for a sensible way to store a users > read state per publish-subscribe node. > > For example: > a pub-sub node has a large number of posts > user reads some of them from oldest to newest on one device > clie

Re: [Standards] Proposed XMPP Extension: Buddycloud Channels

On 28 Apr 2014, at 17:11, XMPP Extensions Editor wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Buddycloud Channels > > Abstract: This document describes a profile and conventions for usage > of the PubSub protocol in the context of a

Re: [Standards] [Members] IETF 89 and the XMPP WG meeting - are you going?

On 19 Feb 2014, at 17:16, Mike Taylor wrote: > please do add your name to the wiki page noted below so we can figure > things out *before* the event. I’ve also added a section about the meetup in the evening - note that volunteers for talks are always welcome too! — Ash

[Standards] BOSH updates from last summit

I was just thinking about the updates we discussed about the BOSH spec. I think all the patches were posted to the mailing list, but did anyone actually make the updates to the spec itself in the end? I'm happy to trawl back through the mailing list and make the updates. This was the wiki page

Re: [Standards] Out of band: MIME type

On 18 Jul 2013, at 08:30, Daniele Ricci wrote: > Greetings, > I found out to be needing a "type" attribute in the element in > XEP-0066 [1]. I guess it could be useful as a hint to know in advance > the mime type of what we are going to download (e.g. for http URIs). > What do you think? Could

Re: [Standards] XEP-0160 and 'chat' messages

On 17 Jul 2013, at 16:11, Peter Saint-Andre wrote: > What is the relation, if any, between hints and the Message Stanza > Profiles document? > > http://xmpp.org/extensions/xep-0226.html Interesting thought. The IM profile (in section 8.5.2.1.1.) states things like "the server SHOULD either (a)

[Standards] XEP-0160 and 'chat' messages

I am currently looking at implementing the rules around storing messages described in xep-0160 in openfire. The second rule states that messages of type 'chat' should be stored unless they only contain chat state notifications, which is fine. But I was wondering whether this could be generalise

[Standards] Error in xep-0334 (message hints)

Hi All, Small thing, but I just noticed an error in xep-0334: In Example 1, the "No storage" hint is , however in 4.2 it's -- Ash

Re: [Standards] XEP tagging idea..

On 6 Jun 2013, at 20:58, Steffen Larsen wrote: > I was wondering why we do not have any searchable tags on the different XEPs. Sounds like a pretty good idea. It could also help people to find related XEPs, e.g. all the XEPs relating to PubSub like 60, 248, 253, 163, etc. Who would maintain the

[Standards] [BOSH] Patch update

Hi All, I've tweaked the wording a bit for the re-requested rid stuff. Patch is attached. Wording is now: If the connection manager receives a request for a 'rid' which has already been received but to which it has not yet responded then it SHOULD respond immediately to the existing request with

[Standards] BOSH Updates

I have come up with some wording for the issue http://wiki.xmpp.org/web/BoshIssues#Re-requesting_RIDs It basically boils down to adding the following to section 14.3 (Broken Connections): "If the client resends a request for a 'rid' which the connection manager has already received but to which i

Re: [Standards] pubsub purge_offline

On 18/02/2013 18:19, "Ralph Meijer" wrote: >On 2013-02-18 17:34, Kevin Smith wrote: >> >> Thoughts? > >Maybe this option is not very well suited for the case where there are >potentially multiple publishers, as one of them going offline would >result in the retraction of items published by othe

Re: [Standards] PEP - Public PubSub subscribed list

On 15/02/2013 22:42, "Dave Cridland" wrote: > Yes, but jid and node, please. Might not be a server as such. Very good point :) My Little Pony - Fan Club ... -- Ash

Re: [Standards] PEP - Public PubSub subscribed list

On 15/02/2013 14:48, "Tim" wrote: >We are currently working on the XEP. Is there some comments to make on >this new structure ? Adding arbitrary attributes to the element would either require namespacing them, or a change to the pubsub schema. Also the element should contain a single child ele

Re: [Standards] PEP - Public PubSub subscribed list

ny more important problems with >pubsub now. > >On 02/11/2013 08:04 PM, Ashley Ward wrote: >> Then perhaps we could just go full circle back to where you started and >> have a simple xep which says something along the lines of >> >> - >> If an entity wishes to

Re: [Standards] PEP - Public PubSub subscribed list

y is to make application specific extension >and forget about it... Until the moment another client will implement >it's own version of the same protocol (we should agree that the problem >is widespread enough). Then it will become a hell which can be prevented >earlier than can be a

Re: [Standards] PEP - Public PubSub subscribed list

On 11/02/2013 11:36, "Sergey Dobrov" wrote: >This fact will do this protocol even more complicated. I think this is the exact reason why it should be application specific. Trying to cover all the bases to make it general purpose would be extremely complicated. At the moment your home server do

Re: [Standards] PEP - Public PubSub subscribed list

On 11/02/2013 10:24, "Sergey Dobrov" wrote: >Don't you guys think that the fact that PEP has subscribers from a >user's roster does such feature dangerous? Yes, I agree. You wouldn't want to make this the general case as there are serious privacy concerns with automatically sharing this informat

Re: [Standards] PEP - Public PubSub subscribed list

Le 08/02/2013 08:48, Tim a écrit : >The idea here is to use PEP to store a list of pubsub nodes and > allowing a user to notify its contacts when he wants to share some of > theses. Quite like the idea of making this information available on a pep node, but I think you would need to consider diff

Re: [Standards] [Summit] BOSH actions

On 05/02/2013 20:27, "Peter Saint-Andre" wrote: >A: Top-posting. > >Q: What is the most annoying behavior on email discussion lists? I just assumed everyone liked playing mailing list Jeopardy! ;) >Hey Ash, it was great to meet you in Brussels! You too! Feels really good to be involved with s

Re: [Standards] [Summit] BOSH actions

Great. I guess that BOSH was originally intended as a general transport, but in this day and age would anybody actually use it for anything other than xmpp? I'd say probably not. In which case let's just concentrate on making it work really well, and as simply as possible, for XMPP. I'd really li

Re: [Standards] Fwd: [Summit] BOSH actions

; /Steffen >> >> On Feb 4, 2013, at 10:06 PM, "Peter Saint-Andre (psaintan)" >> wrote: >> >>> That sounds sensible. >>> >>> Sent from mobile, might be terse >>> >>> On Feb 4, 2013, at 1:26 PM, "Ashley Ward" >&

Re: [Standards] Fwd: [Summit] BOSH actions

It would be great to keep them consistent, but is it worth potentially breaking implementations? I think the main problem with accept was that the example was inconsistent with the text. In fact, I very much doubt anyone should be using that option as xmpp mandates the use of utf-8, and I doubt an

[Standards] FW: [Council] XEP-0258 1.1

Looks good - worth making the point about the transience of a label catalog. Slight grammar error though: "Two identical catalog requests may returned different results". Another thought - if there is a chance that the catalog may change between the client requesting it and then sending a message

Re: [Standards] Comments Needed: Upgrading XEP-0301 to Draft. (In-Band Real Time Text)

> Yes that is the topic at hand, isn't it? I would say that, if anything, adding > an implementation note that it is acceptable to include a in a RTT > update, and that it may be used to differentiate sessions in conjunction with > full JIDs would be sufficient. > +1 for this idea :) ~~~ Ash

Re: [Standards] Comments Needed: Upgrading XEP-0301 to Draft. (In-Band Real Time Text)

In one of our chat clients we have developed it is possible for a user to have what amounts to multiple conversations occurring at the same time with a single other user (I.e. In our case a user can have multiple chat tabs open to another user). Reading the 301 spec, there doesn't seem to be any w

Re: [Standards] Proposed XMPP Extension: Security Labels in PubSub

Yeah - sorry about that! I had two copies of it on my file system and of course sod's law meant that I sent the wrong one! Thanks to Peter for updating it! --- Ash On 19/06/2012 17:47, "Todd Herman" wrote: >I was going to say. There were no periods and parts had "blah blah blah" >in it. :) >

Re: [Standards] BOSH and broken HTTP connections

On 29/05/2012 18:38, "Kevin Smith" wrote: >> >> * The server responds to the existing connection with some kind of error >> condition, and for the new connection to pick up the long poll from >>there >> >> >I don't know how others feel about this, but I suspect the right thing >to do when re-re

[Standards] BOSH and broken HTTP connections

lient) Any thoughts very much appreciated. I just thought it would be good to formalise the server behaviour in this condition. Thanks, Ashley Ward

Re: [Standards] XEP-0258 and XEP-0060

On 18/11/2011 11:12, "Ralph Meijer" wrote: >I don't see any reason why you couldn't add as a child >of next to . If that's the case then that sounds like a good solution to me :) Ash

Re: [Standards] XEP-0258 and XEP-0060

On 18/11/2011 06:47, "Ralph Meijer" wrote: >On Thu, Nov 17, 2011 at 07:55:09PM +, Ashley Ward wrote: >> On 17/11/2011 18:53, "Ralph Meijer" wrote: >> [..] >>Yeah. I think it would make most sense for the label to be contained >> within the

Re: [Standards] XEP-0258 and XEP-0060

On 17/11/2011 21:18, "Dave Cridland" wrote: > >In addition, if the server has a clearance for a seperate pubsub >service, it's going to need to decide what to do if different items >do and do not pass the ACDF. This is tricky, because the model only >allows for all-pass or all-fail. That's true

Re: [Standards] XEP-0258 and XEP-0060

On 17/11/2011 18:53, "Ralph Meijer" wrote: >On Thu, 2011-11-17 at 10:38 +, Ashley Ward wrote: >> I am currently looking into the possibility of extending the use of >> security labels to pub sub, and was wondering if anyone else has any >> thoughts on this

[Standards] XEP-0258 and XEP-0060

Any feedback much appreciated. Thanks, Ashley Ward