So I think that as far as rosters go, this is duplicating XEP-0237 in a
considerably less efficient form.
XEP-0237§4 gives a fairly intense trip down implementation options, and
none of them require multiple versions of the roster as claimed by this
ProtoXEP. I have a personal preference for
On 1 September 2015 at 22:07, Sam Whited <s...@samwhited.com> wrote:
> On Tue, Sep 1, 2015 at 2:35 PM, Dave Cridland <d...@cridland.net> wrote:
> > So I think that as far as rosters go, this is duplicating XEP-0237 in a
> > considerably less efficient form.
>
&g
The usual terms are message recall, or retraction.
On 28 Aug 2015 17:59, Christian Schudt christian.sch...@gmx.de wrote:
Hi,
the wording is very inconsistent.
It sometimes says delete/deletion, sometimes remove/removal, even when
referring to the same use case (removal request“, deletion
On 27 August 2015 at 16:14, Vitaly Takmazov vitalys...@gmail.com wrote:
Hello!
It's here: http://wiki.xmpp.org/web/index.php?title=Myths
I don't understand where is the proper place to comment it, so I will
comment it here.
Thanks for taking the time to comment; it's really appreciated.
On 27 August 2015 at 21:42, Evgeny Khramtsov xramt...@gmail.com wrote:
Thu, 27 Aug 2015 17:13:14 +0100
Dave Cridland d...@cridland.net wrote:
The rest of these comments, though, I largely agree with - there's
been talk of putting together both a new profile XEP, listing the
things any
Folks,
I've avoided voting on this because I want to seek some community input on
it. Specifically, we (the XMP{P Standards Foundation) claim to be an Open
Standards organization, and it's not clear if this submission qualifies
because it has a dependency on STANAG 5066, which is not publicly
On 17 August 2015 at 20:15, Ben Langfeld b...@langfeld.me wrote:
On 17 August 2015 at 13:44, Kevin Smith kevin.sm...@isode.com wrote:
On 14 Aug 2015, at 20:11, Ben Langfeld b...@langfeld.me wrote:
2) 5.1 (Actors) places requirements that these JIDs for
components/mixers can only be only
I'm in full support of both the PRs raised (#50 and #51); these address all
the points I saw raised in discussion.
On 17 August 2015 at 18:37, Georg Lukas ge...@op-co.de wrote:
* Kevin Smith kevin.sm...@isode.com [2015-08-17 15:47]:
After discussion in the XSF MUC, I’ve pushed another change,
On 12 August 2015 at 07:12, Steve Kille steve.ki...@isode.com wrote:
Given that a MAM based approach may be the preferred medium term
approach, it seems to me that we should focus efforts to work out what the
medium term approach is going to be. If we end up deciding that a MAM
based
On 12 August 2015 at 09:01, Georg Lukas ge...@op-co.de wrote:
* Steve Kille steve.ki...@isode.com [2015-08-12 08:14]:
Given that a MAM based approach may be the preferred medium term
approach, it seems to me that we should focus efforts to work out what
the medium term approach is going
On 12 August 2015 at 10:54, Dave Cridland d...@cridland.net wrote:
On 12 August 2015 at 09:01, Georg Lukas ge...@op-co.de wrote:
* Steve Kille steve.ki...@isode.com [2015-08-12 08:14]:
Given that a MAM based approach may be the preferred medium term
approach, it seems to me that we
On 12 August 2015 at 11:22, Kevin Smith kevin.sm...@isode.com wrote:
While falling into the good/perfect/now/later trap, we do at least have a
story here that would solve this. MUC2 (which is being specced) should
solve the shared-nickname issues of MUC, and Dave’s
On 11 August 2015 at 00:05, Goffi go...@goffi.org wrote:
G'day,
It seems that in XEP-0060 nothing prevent a publisher to overwrite an item
published by somebody else (or at least it's ambiguous)
while that may be desirable in some cases, it's pretty bad with XEP-0277
comments.
In
I've noticed that a large well-funded group have been attending a number of
conferences and making unfortunately ill-informed statements about XMPP, in
favour of their own solution in a number of spaces in which we overlap.
In conformity with Napoleon's suggestion that one should never attribute
, since there's sectors using XMPP over low-bandwidth
for mission-critical messaging that are really eye-opening - and I didn't
even know about the disaster cases - links would be great.
Best,
Dominik
Am 10.08.2015 um 18:02 schrieb Dave Cridland:
I've noticed that a large well-funded group
On 10 August 2015 at 17:02, Dave Cridland d...@cridland.net wrote:
It's here: http://wiki.xmpp.org/web/index.php?title=Myths
I've added Myth Five : XMPP is unsuited to the web.
This is really an area I know very little about, so if Lance and Lloyd want
to check I'm not taking their names
On 29 July 2015 at 16:36, Daniel Gultsch dan...@gultsch.de wrote:
Don't get me wrong. There is definitely a place for Jingle and Jingle FT.
I don't want to deprecate Jingle at all. But Jingle is not always the right
tool for the job.
I see your point, but I'd prefer to see client developers
On 28 July 2015 at 10:11, Christian Schudt christian.sch...@gmx.de wrote:
Hi,
What about a client sending delayed stanzas upon stream resumption? Should
it add Delayed Delivery as well?
E.g. client sends a message, but no ack is received, so it stays in the
unacknowledged queue. Eventually
https://github.com/xsf/xeps/pull/32
Two things came up during community review of a patch to Openfire which are
not specified in the XEP. Both seem to be uncontentious, but will require
Council review, etc.
1) The specification makes no recommendation on what to do if the server
receives
On 28 July 2015 at 10:00, Florian Schmaus f...@geekplace.eu wrote:
On 28.07.2015 10:20, Dave Cridland wrote:
On 28 July 2015 at 08:22, Florian Schmaus f...@geekplace.eu
mailto:f...@geekplace.eu wrote:
On 27.07.2015 23:29, Sam Whited wrote:
Hi all,
I'd like
On 28 July 2015 at 08:22, Florian Schmaus f...@geekplace.eu wrote:
On 27.07.2015 23:29, Sam Whited wrote:
Hi all,
I'd like to propose that the Council vote to move XEP-0452: Client
State Indication into last call (the Proposed State), and then
hopefully into draft afterwards.
The
On 28 July 2015 at 10:11, Edwin Mons j...@edwinm.ik.nu wrote:
On 28/07/15 11:05, Dave Cridland wrote:
Also, why wrap the server notification in a message,
And not using a Nonza? Because most libraries provide a mechanism for
callbacks matching a given filter only for Stanzas. It's my
On 28 July 2015 at 10:13, Florian Schmaus f...@geekplace.eu wrote:
On 28.07.2015 11:05, Dave Cridland wrote:
On 28 July 2015 at 10:00, Florian Schmaus f...@geekplace.eu
mailto:f...@geekplace.eu wrote:
On 28.07.2015 10:20, Dave Cridland wrote:
On 28 July 2015
On 23 July 2015 at 08:43, Kevin Smith kevin.sm...@isode.com wrote:
FYI
Begin forwarded message:
From: Kevin Smith
Subject: [Council] Minutes 2015-07-22
Date: 23 July 2015 08:41:27 BST
To: XMPP Council
Logs: http://logs.xmpp.org/council/2015-07-22/
1) Roll call
Kev, Dave,
On 23 July 2015 at 10:23, Kevin Smith kevin.sm...@isode.com wrote:
On 23 Jul 2015, at 08:58, Dave Cridland d...@cridland.net wrote:
Dave abstains, Fippo, Kev, Lance, Matt to vote on list.
For the record, I didn't abstain.
He who writes the minutes…
But less flippantly, I think
On 22 July 2015 at 09:48, Max Beloborodko f1ashhims...@gmail.com wrote:
I'm messing with XEP-0206 and can't figure out
quote
If the BOSH body/ wrapper is not empty, then it SHOULD contain
...
One or more complete message/, presence/, and/or iq/ elements
qualified by the 'jabber:client'
On 22 July 2015 at 10:19, Kevin Smith kevin.sm...@isode.com wrote:
On 22 Jul 2015, at 09:57, Dave Cridland d...@cridland.net wrote:
On 22 July 2015 at 09:48, Max Beloborodko f1ashhims...@gmail.com
wrote:
I'm messing with XEP-0206 and can't figure out
quote
If the BOSH body
On 21 July 2015 at 10:53, Peter Membrey pe...@membrey.hk wrote:
Hi guys,
Thanks for the encouragement and feedback!
I'm working on the ProtoXEP now and I think it's coming along quite
nicely. I hope to be able to submit it soon.
I could use some guidance on how to best approach describing
I think this is a very high-quality submission, and there's no doubt in my
mind that we want this to be a XEP.
However, I expected this to be a (sorely-needed) major edit to XEP-0286,
which I wrote some years ago and has lagged behind the times. For the
record, I'm perfectly happy to completely
Can we add something into the security considerations for this document
which discusses the exposure of the jid in by, please?
Dave.
On 15 July 2015 at 16:12, Florian Schmaus f...@geekplace.eu wrote:
On 15.07.2015 10:12, Dave Cridland wrote:
Can we add something into the security considerations for this document
which discusses the exposure of the jid in by, please?
I had the same though, but then discarded adding
While we're on the subject, is there any benefit to having a reestablish
mechanism in a more general sense? I'm thinking about the number of times I
tell colleagues that I'll call them right back - would we save much effort
in negotiation if we chose to repeat a previous session rather than create
I think it's worth noting that low-bandwidth support is a key
differentiator for Isode's implementation, and so it's especially pleasing
to see this low-bandwidth binding of XML Streams be submitted for
standardization in this way. While I appreciate it's relatively niche, I
think it will benefit
On 2 July 2015 at 18:42, Peter Saint-Andre - yet pe...@andyet.net wrote:
As to years with more than 4 digits, those would be needed starting in the
year 1. Although I see no harm in mentioning the possibility of that, I
doubt that XMPP will still be in use 7985 years from now. ;-)
On 1 July 2015 at 09:20, Mickaël Rémond mrem...@process-one.net wrote:
Hello,
XEP-0160 clarify the best practice for offline message and states for
offline messages that headline message should not be stored for offline
delivery:
headline -- Messages with a 'type' attribute whose value is
On 30 June 2015 at 18:40, Peter Waher peter.wa...@clayster.com wrote:
Thanks for your input. For small devices, that do not wish to (or cannot)
perform a dynamic handshake, there's the concept of quick configurations
(§2.6). With a quick configuration ID, the entire setup is predefined. It
On 26 June 2015 at 05:41, Rick van Rein r...@openfortress.nl wrote:
I am thinking of constrained processing environments, such as clients on
microcontrollers. These may want to use EXI to avoid having to deal
with the full XML notation, and they would most certainly not be
serviced if they
I was looking at that earlier. I'm not wholly convinced that this replaces
the use case lost from jingle file transfer.
I'll go into this more when I'm not on my mobile, but I think the hey,
that didn't work case is the one missing.
On 29 Jun 2015 17:30, Peter Saint-Andre - yet pe...@andyet.net
https://xkcd.com/927/
On 28 June 2015 at 21:43, Daniel Gultsch dan...@gultsch.de wrote:
2015-06-28 20:36 GMT+02:00 Christian Schudt christian.sch...@gmx.de:
Jingle File Transfer might be rarely implemented currently, because it is
still in Experimental status. But a new (experimental)
On 26 June 2015 at 13:40, Peter Saint-Andre - yet pe...@andyet.net wrote:
On 6/26/15 5:57 AM, Dave Cridland wrote:
On 26 June 2015 at 00:51, Peter Saint-Andre - yet pe...@andyet.net
mailto:pe...@andyet.net wrote:
Lance Stout and I had a conversation the other day about what we
On 26 Jun 2015 07:24, Steve Kille steve.ki...@isode.com wrote:
I would like us to Get This Right, though. People have been mumbling
about replacing MUC for years, and I’ve always been resistant;
the discussions at the summit this year persuaded me that we finally
have requirements that MUC1
On 26 June 2015 at 00:51, Peter Saint-Andre - yet pe...@andyet.net wrote:
Lance Stout and I had a conversation the other day about what we call
guest access to an XMPP application. As example, consider a chat service
(text, video, what have you) that has registered users and the ability for
On 25 June 2015 at 15:28, Peter Saint-Andre - yet pe...@andyet.net wrote:
On 6/25/15 2:27 AM, Kevin Smith wrote:
Thinking a bit about the MUC2 stuff. MUC1 had Anon/semianon/nonanon.
s/had/has/
We’ve pretty much killed off fully anonymous rooms in MUC1.
I think those were never
On 25 Jun 2015 18:05, Kevin Smith kevin.sm...@isode.com wrote:
On 25 Jun 2015, at 16:59, Dave Cridland d...@cridland.net wrote:
Removing a widely deployed feature doesn't strike me as a viable option.
Well, if we s/widely deployed/widely required/ then I agree. But not
baking something
On 25 June 2015 at 09:27, Kevin Smith kevin.sm...@isode.com wrote:
Thinking a bit about the MUC2 stuff. MUC1 had Anon/semianon/nonanon. We’ve
pretty much killed off fully anonymous rooms in MUC1.
Can people share their thoughts on usecases for semi-anon, please? It’s
not entirely clear to me
Is this for any client connecting to a server running on Windows, or for
clients running on Windows connecting to any client, or some other
permutation?
On 24 June 2015 at 12:40, Mili Verma mili.ve...@isode.com wrote:
Hi,
I've proposed some changes to XEP-0233, mainly about how to construct
-Andre - yet pe...@andyet.net
wrote:
On 6/17/15 3:33 PM, Dave Cridland wrote:
On 17 June 2015 at 20:52, Curtis King ck...@mumbo.ca
mailto:ck...@mumbo.ca wrote:
On Jun 17, 2015, at 8:46 AM, Dave Cridland d...@cridland.net
mailto:d...@cridland.net wrote:
Folks
On 18 Jun 2015 15:40, Curtis King ck...@mumbo.ca wrote:
On Jun 18, 2015, at 7:25 AM, Dave Cridland d...@cridland.net wrote:
There's consensus, I would argue, given that it's extremely well
supported in servers, desktop and mobile clients. In fact, finding servers
that didn't support it a year
On 18 Jun 2015 19:21, Curtis King ck...@mumbo.ca wrote:
On Jun 18, 2015, at 8:45 AM, Dave Cridland d...@cridland.net wrote:
On 18 Jun 2015 15:40, Curtis King ck...@mumbo.ca wrote:
On Jun 18, 2015, at 7:25 AM, Dave Cridland d...@cridland.net wrote:
There's consensus, I would argue
On 17 June 2015 at 20:08, Sam Whited s...@samwhited.com wrote:
On Wed, Jun 17, 2015 at 10:46 AM, Dave Cridland d...@cridland.net wrote:
I think that these days, any server should be doing PEP. I suspect we're
nearing the point where we need to consider Carbons as a Core, rather
than
On 17 June 2015 at 22:41, Peter Saint-Andre - yet pe...@andyet.net wrote:
On 6/17/15 3:33 PM, Dave Cridland wrote:
I meant to say that Carbons wasn't even on there before, whereas it's
now pretty much essential.
Agreed with respect to the technology. With respect to the process
On 17 Jun 2015 22:56, Curtis King ck...@mumbo.ca wrote:
On Jun 17, 2015, at 2:33 PM, Dave Cridland d...@cridland.net wrote:
Two years ago I agreed with you entirely. I maintained this position
until I switched to a server and set of clients that supported it, and then
found it actually works
On 17 June 2015 at 20:52, Curtis King ck...@mumbo.ca wrote:
On Jun 17, 2015, at 8:46 AM, Dave Cridland d...@cridland.net wrote:
Folks,
Many moons past, before the dawn of a couple of years ago, we had things
like XEP-0302, which declared that - excitingly - advanced servers might
Folks,
Many moons past, before the dawn of a couple of years ago, we had things
like XEP-0302, which declared that - excitingly - advanced servers might
want to implement PEP.
I think that these days, any server should be doing PEP. I suspect we're
nearing the point where we need to consider
On 10 June 2015 at 05:58, Daniel Gultsch dan...@gultsch.de wrote:
Even though not yet quite perfect (see the discussion about Message-ID and
MR2) MAM works reasonable well. A MAM capable client has no trouble to
automatically catch up with lost messages. However if the MAM capable
client is
On 10 June 2015 at 15:37, Sam Whited s...@samwhited.com wrote:
Slightly OT:
On Wed, Jun 10, 2015 at 2:55 AM, Georg Lukas ge...@op-co.de wrote:
Still, we can not get rid of one as long as not all clients support the
other.
I disagree; the point of a standards body isn't to maintain every
On 5 Jun 2015 08:44, Florian Schmaus f...@geekplace.eu wrote:
On 05.06.2015 09:36, Dave Cridland wrote:
On 5 June 2015 at 07:24, Florian Schmaus f...@geekplace.eu
mailto:f...@geekplace.eu wrote:
On 04.06.2015 09:39, Kevin Smith wrote:
On 3 Jun 2015, at 16:02, XMPP Extensions
On 5 June 2015 at 07:24, Florian Schmaus f...@geekplace.eu wrote:
On 04.06.2015 09:39, Kevin Smith wrote:
On 3 Jun 2015, at 16:02, XMPP Extensions Editor edi...@xmpp.org wrote:
http://xmpp.org/extensions/inbox/nonza.html
The definition here seems potentially useful. I would add a
I'm in broad agreement with what Kurt writes below.
I think the only point where we differ is that the does MUC issue new ids
question is really one we could answer now (and if not directly answer,
certainly fix).
I would also add that using the stanza's id and from attributes, plus a
(possibly
On 3 June 2015 at 00:48, John Williams (johnwi3) john...@cisco.com wrote:
Thanks for the clarification.
Hum,.. not sure how useful this is, since a lot of stanzas are of little
long term interest (eg: chatstates), but as you describe it seems pretty
harmless.
So as things stand, if a TCP
On 31 May 2015 at 04:00, Kurt Zeilenga kurt.zeile...@isode.com wrote:
Why not consider the new feature an extension to the extension… and hence
something which doesn’t require a bump of the extension being extended?
Yes, that's another option.
It possibly means using a namespaced attribute
On 30 May 2015 at 08:33, Georg Lukas ge...@op-co.de wrote:
* Steffen Larsen zoo...@gmail.com [2015-05-30 08:37]:
No, I would go for a version bump, because it could break some clients.
A version bump, on the other hand, would break all clients. Some clients
haven't yet implemented the sm:2
What if, on a resumption failure, a server could include the 'h' attribute,
to mean I can't actually resume your state, but I did get all the stanzas
up until H.
I think this allows servers to hold onto this small amount of state for
considerably longer than it's desirable to keep a disconnected
On 27 May 2015 at 07:51, Lance Stout lancest...@gmail.com wrote:
/Puts on Council hat
I'm -1 on this for now because this really needs some more discussion on
the list as this duplicates quite a bit.
Likewise; my comments are unanswered.
Technical nitpicks for proposal as is:
- The
On 11 May 2015 at 19:21, XMPP Extensions Editor edi...@xmpp.org wrote:
Title: REST with XMPP
How is this materially different to XEP-0050?
The reason I ask is because my initial reaction was that the specification
essentially reinvents XEP-0004, but when I considered how it looked once
that
FYI.
I'll discuss this with the protoXEP author; I suspect he'll be quite
understanding.
Dave.
-- Forwarded message --
From: Dave Cridland d...@cridland.net
Date: 22 April 2015 at 17:42
Subject: Veto against namespaces protoXEP
To: XMPP Council coun...@xmpp.org
There is some
On 20 April 2015 at 18:40, Philipp Hancke fi...@goodadvice.pages.de wrote:
Am 20.04.2015 um 06:27 schrieb Florian Schmaus:
In order to make the following easier, I'd first like to define the term
Nonza:
A Nonza is every top level XMPP stream element which is not a Stanza.
(see also [1]).
On 18 Apr 2015 11:34, Thijs Alkemade th...@xnyhps.nl wrote:
On 18 apr. 2015, at 11:59, Thijs Alkemade th...@xnyhps.nl wrote:
On 18 apr. 2015, at 11:42, Georg Lukas ge...@op-co.de wrote:
1. When a user logs in for the first time, an asymmetric keypair is
created (I was thinking of
On 18 Apr 2015 03:58, Peter Saint-Andre - yet pe...@andyet.net wrote:
Ideally, to me, my message archive would be stored on a trusted device
that is under my control (say, a limited-access storage medium that I keep
in my house). This device could authenticate to my account and advertise
its
On 9 April 2015 at 08:27, Kevin Smith kevin.sm...@isode.com wrote:
1) I’m not sure that adding data-* to XEP-0071 would aid interoperability,
as the use of the data-* needs to be understood by both ends (e.g. in your
case it isn’t enough for xep71 to just say ‘you can use data-*’, because a
Folks,
I found myself in error about our namespaces recently, and noticed another
misconception floating about. While looking for a useful explanation of how
and why our slightly weird-looking namespaces work, I found this:
http://mail.jabber.org/pipermail/standards/2011-May/024561.html
So I'd
On 1 April 2015 at 18:33, Matthew Wild mwi...@gmail.com wrote:
On 1 April 2015 at 17:37, Dave Cridland d...@cridland.net wrote:
Folks,
Matthew Miller and Joe Hildebrand's Carbons XEP has been unchanged for 18
months, and represents a useful and well-deployed protocol, implemented in
most
Folks,
Matthew Miller and Joe Hildebrand's Carbons XEP has been unchanged for 18
months, and represents a useful and well-deployed protocol, implemented in
most (if not all) of the mainstream servers.
Mobile and Desktop clients alike appear to implement this widely.
I appreciate that the last
FYI.
-- Forwarded message --
From: Dave Cridland d...@cridland.net
Date: 25 March 2015 at 16:20
Subject: XMPP Council Minutes, 20150325T1600Z
To: XMPP Council coun...@xmpp.org
Present: Dave Cridland (Acting Chair), Philipp 'Fippo' Hancke, Lance Stout,
Matthew Wild
Apologies
On 16 March 2015 at 23:11, Lance Stout lancest...@gmail.com wrote:
This one may need to go to Peter for a philosophy question: what is to be
done when an implementation of feature Y MUST support X as a fallback, but
the user chooses to disable X.
MTI != MTD
Mandatory To Implement does not
On 3 March 2015 at 17:54, Florian Schmaus f...@geekplace.eu wrote:
Hi everyone,
I think I found an error in XEP-65:
Section 9.4 activate/ Element states that
This element is always empty and has no defined attributes.
when it should be
This element's XML character data contains always
Since XMPP folks are particularly interested in scram, I'd like to draw
attention to this work.
Note the venue for comments!
-- Forwarded message --
From: Stephen Farrell stephen.farr...@cs.tcd.ie
Date: 12 Feb 2015 01:25
Subject: [kitten] AD sponsoring draft-hansen-scram-sha256
I don't have anything useful to add here, really, but please can you guys
capture your knowledge into XEP-0286? It's clearly behind the times, as
it's 5 years old, but if we could capture some more modern thinking it
might become useful again.
Thanks,
Dave.
At the summit, a bunch of us decided to have a serious effort at a redesign
of multi user chat, to address shortcomings and emerging use cases.
The overall model was a service domain which exposed, at bare jid level, a
set of rooms, which acted more or less as pubsub services, with subsidiary
On 12 Feb 2015 14:00, Christian Schudt christian.sch...@gmx.de wrote:
Dave, maybe could you (or somebody else) elaborate on the shortcomings
and the different demands of things like buddycloud you have discussed
for those who didn't attend the summit.
Also what's so bad about multiple parties
On 4 February 2015 at 21:29, Kevin Smith kevin.sm...@isode.com wrote:
I’m -1 on the component-s2s spec. I’ve been backwards and forwards a
number of times on whether to use the veto or not, and I’m using it in the
lightest sense.
I'll elide the flame war if that's OK? I appreciate it's
On 3 Feb 2015 11:58, Goffi go...@goffi.org wrote:
Having a node attribute is defined in 313 as specifying you want to
search a pubsub archive instead of another type of archive. I don't see
the confusion.
It's explained in XEP-0313, but I think it's a bad idea to use common
terminology to
On 3 Feb 2015 09:37, Florian Schmaus f...@geekplace.eu wrote:
On 03.02.2015 10:04, Dave Cridland wrote:
On 2 Feb 2015 18:49, Peter Saint-Andre - yet pe...@andyet.net
mailto:pe...@andyet.net wrote:
On 2/2/15 5:22 AM, Hund, Johannes wrote:
Since it was undisclosed that even the NSA seems
On 21 January 2015 at 07:29, Lance Stout lancest...@gmail.com wrote:
I recall Ralph once noted that many of the major XEPs were each the third
try at the concepts. So here's hoping for components v3 :)
We can but hope. '114 just about does the job, '225 hasn't caught
anyone's imagination it
On 21 January 2015 at 14:55, Kevin Smith kevin.sm...@isode.com wrote:
My last point, though, is that this doesn’t allow a component to implement
presence-based pubsub stuff (not even the limited PEP profile), which it
sets out to do, as it doesn’t have any way of delegating the incoming
Thank you, Mr Miller!
On 20 January 2015 at 15:51, XMPP Extensions Editor edi...@xmpp.org wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: S2S Components
Abstract: This document describes a modernized method of connecting
'components' to a server, expressed
On 14 January 2015 at 05:57, David Bolack dbol...@missingworldsmedia.com
wrote:
On Monday, January 12, 2015 03:14 EST, Dave Cridland d...@cridland.net
wrote:
In general, proposing a XEP that's rejected because it's a terrible idea
adds more value than doing something that's a terrible
Also from the XSF Board minutes (sent to XSF Members):
On 12 January 2015 at 16:47, Dave Cridland d...@cridland.net wrote:
Dave reported that we are (based on previous years) approximately €1000
short of breaking even
While it's not absolutely essential that we break even with the Summit
Noting that this last call is over, I'd personally like to see the
rationale below captured in the document. It really wasn't clear to me, and
I don't think I'm unique here.
This is not intended to be a blocking comment for advancement.
On 16 Dec 2014 21:32, Lance Stout lancest...@gmail.com
On 8 January 2015 at 16:28, Edwin Mons j...@edwinm.ik.nu wrote:
Say I have the following situation:
1) a client with interest in mood publishes a PEP node
2) the client will receive said event back from the server
Would Retrieve Subscriptions list a subscription for that node? And what
On 29 December 2014 at 17:12, Sam Whited s...@samwhited.com wrote:
Regardless, I think this is out of the scope of what the OTR document
would define.
I think it'd be far more useful to define what current OTR usage is, and
what it protects against (and what it doesn't).
Writing what OTR
On 22 December 2014 at 01:19, Sam Whited s...@samwhited.com wrote:
Hi all,
XEP-0191 (Blocking command) specifies that once a contact is blocked, no
stanzas are delivered from them to the user:
Once the user has blocked communications with the contact, the
user's server MUST NOT deliver
On 22 December 2014 at 13:51, Sam Whited s...@samwhited.com wrote:
On 12/22/2014 04:19 AM, Dave Cridland wrote:
Slightly confused by this. XEP-0191 is server-side enforced, so the
behaviour will be applied and controlled by the server, not the client.
Gajim uses Privacy lists without
On 22 December 2014 at 14:47, Holger Weiß hol...@zedat.fu-berlin.de wrote:
* Kurt Zeilenga kurt.zeile...@isode.com [2014-12-22 05:31]:
I think if anything in XEP 191 needs to change, it's the discussion of
how one maps XEP 191 onto XEP 4 privacy lists that should change. It
should be
On 19 December 2014 at 20:31, Mathieu Pasquet mathi...@mathieui.net wrote:
On Fri, Dec 19, 2014 at 02:51:02PM -0500, Sam Whited wrote:
On 12/17/2014 11:46 AM, Winfried Tilanus wrote:
In response to my comment that it left a lot of information
unencrypted he suggested to start a
Further to the other comment, you suggested that implementing your own
system, designed from scratch, would be easier than implementing a system
which adheres to XMPP. This is absolutely correct.
XMPP is not a trivial protocol to implement. It's possible to build
something that will work to some
On 17 December 2014 at 05:15, Kurt Zeilenga kurt.zeile...@isode.com wrote:
While your OP implies that “we” (presumedly “the community”) should take a
step back and consider model and terminology issues, in your latest
comments, it seems more that you want the authors to adopt a this model and
On 17 December 2014 at 13:24, Kurt Zeilenga kurt.zeile...@isode.com wrote:
On Dec 17, 2014, at 3:52 AM, Dave Cridland d...@cridland.net wrote:
On 17 December 2014 at 05:15, Kurt Zeilenga kurt.zeile...@isode.com
wrote:
While your OP implies that “we” (presumedly “the community”) should take
Folks,
At the last Council meeting, I entered a position of -1 concerning
Privileged Entity:
http://xmpp.org/extensions/inbox/privilege-component.html
In order to explain my position better, it's worth examining how
authorization systems currently model the world. I'm going to use XACML
terms
forward, instead of simply
blocking progress.
Cheers
Goffi
Le mardi 16 décembre 2014, 16:12:00 Dave Cridland a écrit :
Folks,
At the last Council meeting, I entered a position of -1 concerning
Privileged Entity:
http://xmpp.org/extensions/inbox/privilege-component.html
In order
801 - 900 of 1591 matches
Mail list logo
