On Sun, Jun 21, 2020 at 10:34 AM Waqas Hussain wrote:
> On Tue, Jun 16, 2020 at 1:13 PM Jonas Schäfer wrote:
>
>> > Alternatively, if we do still want to use Docker, why not just use
>> > whatever GitHub's CI is or one of the many CI solutions that can work
>&g
On Tue, Jun 16, 2020 at 1:13 PM Jonas Schäfer wrote:
> > Alternatively, if we do still want to use Docker, why not just use
> > whatever GitHub's CI is or one of the many CI solutions that can work
> > with GitHub without setting up lots of new infrastructure, repos,
> > syncing, etc? (ie. Travis
On Mon, Feb 4, 2019 at 2:19 PM Jonas Schäfer wrote:
> This message constitutes notice of a Last Call for comments on
> XEP-0335.
>
> Title: JSON Containers
> Abstract:
> This specification defines an element to be used for encapsulating
> JSON data in XMPP.
>
> URL: https://xmpp.org/extensions/xe
On Thu, Apr 23, 2015 at 3:52 AM, Kim Alvefur wrote:
> tors apr 23 02:35:24 2015 GMT+0200 skrev Waqas Hussain:
> > On Wed, Apr 22, 2015 at 3:41 AM, Florian Schmaus
> wrote:
> >
> > > The discussion drifted a bit into whether non-stanza top-level stream
> >
edge server scenarios), while non-stanzas are passed through
to the XMPP core/router. The idea of XMPP reverse proxies has very
interesting deployment implications, and something we have experimented
with.
--
Waqas Hussain
operating.
It certainly isn't (and shouldn't be) disallowed.
Use-case: you can in theory start a BOSH stream, and use 198 to upgrade to
a WebSocket stream later. It's an interesting idea, where you can swap the
low level transport based on changing network conditions without
interrupting the user's session.
I'm not sure if this works in Prosody (if it doesn't, then advertising it
is a bug).
--
Waqas Hussain
's no way to
reliably check for compatibility until after you've sent some messages.
History sync is one area of XMPP that's terribly broken. All the popular
XMPP protocols involving history (MUC, offline messages, PubSub, etc) have
large gaps and race conditions, making reliable sync impossible. Heck many
of the specs only work on the assumption of synchronised clocks. This is a
separate email though.
--
Waqas Hussain
implementing it for Prosody in a few minutes the day the XEP was
first published:
https://code.google.com/p/prosody-modules/source/browse/mod_ipcheck/mod_ipcheck.lua
I'm aware of one private BOSH application that uses this.
--
Waqas Hussain
MUST. Specs
shouldn't dictate implementation details.
2. To protect clients, a better limit would be on what the server sends on
behalf of users, not on what the server receives, with the goal of
protecting other clients (remember how conference.jabber.org's disco#items
response used to be too large, and got dropped by a lot of federated
servers?)
3. One interesting case where limits limited a useful stanza was the
conference.jabber.org disco#items response
--
Waqas Hussain
That's the normal way to initiate a conversation with a bare
JID when you don't have a full JID available.
Regarding presence subscriptions, is your component doing any roster
handling? It has to send a subscription request to the user, and receive
the user's subscription acceptance, optionally storing this information (as
the component's roster), after which it can probe the user (assuming the
user accepted). The XMPP server does not manage rosters or subscriptions
for XEP-0114 components. It only does so for users. The server mainly
handles XMPP Core (RFC 6120) for components, while everything in XMPP IM
(RFC 6121) is up to the components themselves.
Prosody plug: I've switched to writing components as Prosody plugins, so I
can reuse a lot of Prosody's c2s machinery, and I wrote
mod_component_client to then allow Prosody to act as a XEP-0114 component
to other servers.
--
Waqas Hussain
in and owner affiliations,
not members. And they are also optional for implementations.
Your suggestion of using presence for this doesn't fit the MUC
protocol very well. Instead it would be useful to update the XEP to be
consistent about the messages it already sends (send for all
affiliations, not select ones), while allowing implementations freedom
in what they send (it should remain a MAY, and deployments should be
free to limit broadcasts to e.g., moderators only).
--
Waqas Hussain
On Mon, Dec 9, 2013 at 4:04 PM, Waqas Hussain wrote:
> On Mon, Dec 2, 2013 at 9:58 AM, Peter Waher wrote:
>> Hello Philipp
>>
>> Thanks for your input. I've updated the according to your comments, and
>> attach a new version.
>>
>> Best regards,
&g
7;s a use-case where specifying the data-type would
help the receiver (particularly when this would generally be the same
in every log message sent by the entity)? And while you are using
'xs:*', the 'xs' namespace isn't defined in the XML stream the stanza
is in.
--
Waqas Hussain
On Sat, Oct 12, 2013 at 6:31 PM, Dave Cridland wrote:
>
> On 12 Oct 2013 17:17, "Waqas Hussain" wrote:
>> As a general rule, if you embed one textual language inside another,
>> escaping is pretty much mandatory. If you see a way around it, you are
>> probably m
probably mistaken and missing the edge cases.
--
Waqas Hussain
On Wed, Sep 25, 2013 at 4:47 PM, Matt Miller wrote:
>
> On Sep 25, 2013, at 2:24 PM, Waqas Hussain wrote:
>
>> On Wed, Sep 25, 2013 at 4:00 PM, Kim Alvefur wrote:
>>> Hello,
>>>
>>> On 2013-06-09 20:40, Mathieu Pasquet wrote:
>>>> I was star
On Wed, Sep 25, 2013 at 4:00 PM, Kim Alvefur wrote:
> Hello,
>
> On 2013-06-09 20:40, Mathieu Pasquet wrote:
>> I was starting to implement carbons in poezio when I came across some
>> kind of design issue that I haven’t been able to work out.
>>
>> However, in the case of private MUC messages (XE
Nope, that would be a malformed XML document. What are you trying to do?
On Fri, Dec 7, 2012 at 4:01 AM, Jaussoin Timothée wrote:
> Hye everyone,
>
> All the question is in the title of my message. I've read that BOSH allow
> to add more than one stanza per element to save bandwidth during
> t
On Mon, Feb 20, 2012 at 1:18 PM, Sergey Dobrov wrote:
> On 02/20/2012 02:56 AM, Waqas Hussain wrote:
>>
>> Have you looked at http://jkaluza.fedorapeople.org/remote-roster.html ?
>>
>> Prosody and Spectrum have implementations for sections 2.3, 2.4 and
>> 2.
sts (currently local
components) to edit roster items for that host (mostly normal
jabber:iq:roster queries). This lets Spectrum cleanly manage the
user's transport contacts.
http://code.google.com/p/prosody-modules/source/browse/mod_remote_roster/mod_remote_roster.lua
--
Waqas Hussain
On Wed, Jan 25, 2012 at 2:26 AM, Peter Saint-Andre wrote:
> On 1/24/12 11:14 AM, Peter Saint-Andre wrote:
>
> After jabbering with Kev for a bit, here's a follow-up on the status
> code 210 issue (originally raised by Waqas Hussain).
>
>>>>> "If the user&#x
does not serve vcard4 queries (that would be part of
mod_vcard in Prosody trunk).
--
Waqas Hussain
elease (we have a basic
experimental plugin), but the feature is requested fairly often. I'll
omit the moral of this story, and let readers decide on their own.
--
Waqas Hussain
use of attributes for hashes. e.g., it
would be fairly awkward to change the BOSH 'key' and 'newkey'
attribute to elements in .
--
Waqas Hussain
ld be to simply make a
merkel hash file available as a separate file transfer, and only
transfer the root hash in the jingle negotiation. This also allows
ranged transfer of only necessary parts of the hash file, and doesn't
need base64 encoding.
Do we have anything like Jingle URIs? Something like XEP-0231: Bits of
Binary, but for Jingle. That would be useful in general, and for this
specific solution.
--
Waqas Hussain
On Wed, Sep 28, 2011 at 1:44 AM, Peter Saint-Andre wrote:
> On 9/27/11 7:29 AM, Waqas Hussain wrote:
>> On Tue, Sep 27, 2011 at 2:36 AM, Peter Saint-Andre
>> wrote:
>>> On 9/19/11 11:34 PM, Waqas Hussain wrote:
>>>
>>>> 3. Service changing room nic
On Tue, Sep 27, 2011 at 2:13 AM, Peter Saint-Andre wrote:
> On 9/24/11 1:53 PM, Waqas Hussain wrote:
>>
>> I note that this feature has no disco feature defined.
>
> MUC does not have the plethora of disco features that PubSub has. You
> decide whether that'
On Tue, Sep 27, 2011 at 2:36 AM, Peter Saint-Andre wrote:
> On 9/19/11 11:34 PM, Waqas Hussain wrote:
>
>> 3. Service changing room nick
>>
>> I'd like some text stating that a service can change the occupant's
>> nick at any time, including room join. An
ed has already been done to support
multi-session nicks. I think the only change required would be to make
the internal data structures use fullrealjid+fullroomjid as a key
where they currently use just fullrealjid.
--
Waqas Hussain
actions with room-level registration.
I do intend to implement these in Prosody.
P.S. An important thing in this is the room requesting additional
information. One obvious example is captcha support. How should that
flow? The room should send a captcha form IQ-set or message to the
requester?
--
Waqas Hussain
t;> feature (and the developers say they have no plans to implement the
>> feature), then it might make sense to remove the feature from the spec.
>
> Since sending a private messages to administrators is always possible (even
> without voice), I think there isn't really a need for this feature.
That's not true. PMs to room admins are not always possible. For
example, jab...@conference.jabber.org has PMs disabled for
non-moderators, and sending to admins doesn't work.
--
Waqas Hussain
s/"non"/"none"/
"Nicknames can contain virtually any Unicode character introduces the
possibility of nick spoofing" - grammar fail.
s/hte/the/
All this came from skimming the diff. I'll probably have more feedback
when I manage to review the entire spec in detail while looking at
Prosody's code.
--
Waqas Hussain
On Thu, Sep 15, 2011 at 1:37 AM, Matthew A. Miller
wrote:
>
> On Sep 14, 2011, at 13:40, Waqas Hussain wrote:
>
>>
>> So.. which caps is included in presence? The current exploitable one?
>> Then this doesn't help with preventing poisoning, does it?
>>
>
e much worse than just using
a new XEP, which would be a perfectly smooth transition.
I have assumed the whole point of all this effort to keep the old XEP
is to get rid of the transition period, so if you are not going to
cache exploitable caps at all, might as well define a clean new XEP.
--
Waqas Hussain
t; [1] http://www.w3.org/TR/xmlschema-2/#string
> [2] http://www.w3.org/TR/2008/REC-xml-20081126/#NT-Char
> [3] http://xmpp.org/registrar/disco-features.html
> [4] http://www.jclark.com/xml/xmlns.htm
>
Okay.. let's see... while that was a nice try, it still doesn't work..
First, are you mandating that every client include that disco form in
their caps, even if they don't use any dataforms? If yes, ugly. If no,
they are still open to attack.
Second, I'm assuming you want to keep backwards compatibility, i.e.,
clients with the current exploitable caps still get their caps cached.
If so, then I can simply bypass your protection:
assume you have
feature: "!"
feature: "f1"
feature: "f2"
feature: "f3"
then I can replace that all with:
!
f2
f3
I suspect I may have missed something, because this was too easy.
--
Waqas Hussain
On Mon, Sep 5, 2011 at 5:39 PM, Dave Cridland wrote:
> On Wed Aug 31 06:48:26 2011, Waqas Hussain wrote:
>>
>> Most protocol attacks are based on unexpected input. Attackers
>> wouldn't really care whether the values they send are registered or
>> usable in any way
On Wed, Aug 31, 2011 at 7:10 AM, Peter Saint-Andre wrote:
> On 8/30/11 5:41 PM, Waqas Hussain wrote:
>>> Can we agree that attacks #1, #3, and #4 are easily overcome by proper
>>> handling of inputs?
>>>
>>
>> Those examples, yes. The attack, no. Rea
are willing to update the algorithm in a
non-backwards compatible way? It doesn't seem to be to not force
developers to write more code. All these fixes are going to lead to
more code. Next thing we know, we'll be validating xml:lang is
following the large BNF specified in RFC 4646. It doesn't seem to be
interop, or you wouldn't suggest this change. What is it then?
> Peter
--
Waqas Hussain
On Tue, Aug 30, 2011 at 11:37 PM, Peter Saint-Andre wrote:
> On 8/30/11 10:58 AM, Waqas Hussain wrote:
>>
>> The problem here seems to be people focusing on the exact bytes of the
>> example I happened to type out for these attacks, and not the general
>> logi
On Tue, Aug 30, 2011 at 5:49 AM, Peter Saint-Andre wrote:
> On 8/26/11 4:32 PM, Waqas Hussain wrote:
>>
>> The proposed changes don't solve the problem. See what I wrote in the
>> "Attempting to fix the algorithm" section of the email you linked.
>> Part
eason we don't have a standard is because
there are multiple possible load balancing strategies, none of which
is perfect.
Prosody allows components which are "node@host" or "host/resource". I
haven't verified if this works for external components, but we've used
it to do a number of interesting things with internal components
(e.g., MUC loaded on "r...@example.com", with "example.com" being a
normal host with user accounts).
> Jehan
>
--
Waqas Hussain
e new XEP.
Codes 170 to 174 in MUC were specific to configuration change, but I'd
like these to be sendable by the service outside of configuration
change (e.g., on room join).
> 100
> 172
is redundant. can be used in its place.
If the client really wants to know whether thi
x27;s the stream feature for? Is
the client expected to not pipeline unless it has seen the feature in
a previous connection to the host? Why? Given that the failure case is
harmless, and that pipelining might work on many existing servers, why
wouldn't it want to use it on first connect? Would using it violate
any specification?
--
Waqas Hussain
ict"). This
constructs a new stanza with to and from swapped. Looking at
ejabberd's MUC code, they seem to have something just like that. XMPP
is so consistent in this that we have pretty much no manual error
stanza construction other than that function.
--
Waqas Hussain
tions are.
>
> I can see arguments for both, but I personally prefer getting a 'reply'
> from the JID sent to, as it eases response checking a bit. I.e. how
> implementations are doing it now. I suggest we fix the examples in
> XEP-0045 to that effect.
+1. How implementations are doing it is logical and consistent with
other XMPP specifications.
--
Waqas Hussain
r home
page: http://codex.xiaoka.com/wiki/jabberd2:start (the link on the
page has been changed to an older version of the spec, which is
better).
That said, I suppose I'm being too pessimistic. The idea is good
enough to deserve an implementation.
--
Waqas Hussain
Receipts being included in
more clients. They make a huge difference when you are on a bad
network (e.g., most mobile networks outside of central city areas
across the world).
--
Waqas Hussain
s have an index at the end), and then request relevant portion(s)
of the archive with the content of interest.
> --
> Glenn Maynard
>
--
Waqas Hussain
We can always
add tags later in new namespaces, even defined in new XEPs, e.g.
...
or
...
--
Waqas Hussain
On Thu, Apr 7, 2011 at 12:13 AM, Dave Cridland wrote:
> On Wed Apr 6 19:55:17 2011, Waqas Hussain wrote:
>>
>> Also, PEP in MUC is not a solved problem. I do like avatars in MUC.
>
> I'd note that in Belgium, the consensus seemed to be to solve that problem
> rather
the future. It
would be nice to have this also requestable via IQ (possibly a pubsub
IQ).
--
That was a brain dump more than anything. Let me know if I overlooked
anything obvious.
--
Waqas Hussain
mw)
>
> Diff: N/A
>
> URL: http://xmpp.org/extensions/xep-0295.html
>
>
{
"implemented": "http://blog.prosody.im/json-encodings-for-xmpp/";,
"working_demo": "http://prosody.im/chat/";,
"documentation":
"http://code.google.com/p/prosody-modules/wiki/mod_json_streams";
}
--
Waqas Hussain
Use , which is defined in Atom
Someone
xmpp:some...@example.com
I prefer .
--
Waqas Hussain
validator on the two largest examples within
the vcardxml draft. As I half expected, they failed.
The schema seemed long enough that I gave up on figuring out how
compatible this is with the existing vcard-temp. It looks like mapping
vCard4, vcard-temp, User Avatar, etc to a single backend is going to
be much more work than I had anticipated.
--
Waqas Hussain
ight, then this would make my life much more easier
> since I don't need to implement exceptions for the own jid.
>
> cheers,
> Sebastian
Your client shouldn't disallow it. However, this is a relatively
recent change, and your client should handle a error
properly.
--
Waqas Hussain
On Thu, Dec 2, 2010 at 7:58 PM, Peter Saint-Andre wrote:
> On 12/2/10 7:50 AM, Waqas Hussain wrote:
>> On Thu, Dec 2, 2010 at 7:54 AM, XMPP Extensions Editor
>> wrote:
>>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>>
>>> Tit
n works with Prosody trunk, and verifies that
the user knows the room password. This would be far more interesting
with some per-user credentials.
--
Waqas Hussain
ayed Delivery.
from='kingrich...@royalty.england.lit/throne'
id='bi29sg183b4v'
to='northumberl...@shakespeare.lit/westminster'>
That would be because of that 'from' attribute on the
element, among other things.
--
Waqas Hussain
ful is this?
This requires some thinking, and perhaps testing to determine interop
issues. I'll also need to review our code to determine how significant
a change this would be in Prosody's MUC implementation.
This may also affect other XEPs (distributed MUC, etc). I haven't checked yet.
--
Waqas Hussain
rosody
2. jabberd2
3. ejabberd
4. Tigase
5. Openfire
6. Gloox
7. Spectrum (based on Gloox)
8. Twisted (used by PyICQt, etc)
9. Verse
Seeing as how noone follows that MUST, and it's useless anyway, that
whole parenthesis should be removed.
--
Waqas Hussain
contain full JIDs?
>From the same section you copied the rules from:
"Note: The ban list is always based on a user's bare JID."
- http://xmpp.org/extensions/xep-0045.html#modifyban
Also, 'outcast' is an affiliation, and
"Affiliations are granted, revoked, and maintained based on the
user's bare JID."
- http://xmpp.org/extensions/xep-0045.html#affil
--
Waqas Hussain
On Mon, Sep 20, 2010 at 6:41 AM, Florian Zeitz wrote:
> On 19.09.2010 04:09, Waqas Hussain wrote:
>>
>> That's only partially true. Full JIDs are still not allowed.
>>
> Not as far as I can tell. XEP-45 explicitly says:
>
> When an entity is banned from a r
On Sun, Sep 19, 2010 at 7:22 AM, Matthew Wild wrote:
> On 19 September 2010 03:11, Waqas Hussain wrote:
>> On Wed, Sep 15, 2010 at 8:44 AM, Justin Karneges
>> wrote:
>>> In trying to reduce the number of network round trips in our plain
>>> (non-XMPP)
>&g
On Wed, Sep 15, 2010 at 8:44 AM, Justin Karneges
wrote:
> In trying to reduce the number of network round trips in our plain (non-XMPP)
> BOSH implementation, I wonder about putting data in the session creation
> request and response exchanges. In XEP-0124, there is no mention about
> whether th
filiation changes?
2. If an owner removes affiliation of an occupant, who had affiliation
inherited from a hostname, what happens?
3. If there's a single owner 'example.com'. m...@example.com joins, and
is an owner. Can it remove example.com from the owners list, given
that it itself is an owner, and has a different JID? Can it see itself
in the owners list?
The above list isn't exhaustive. The point is, this wouldn't be a
simple two-line change.
--
Waqas Hussain
t way to set vcard for a
> conference?
>
I'm not sure if this needs to be in XEP-0045 explicitly. It's simply
the logical connection between two basic XMPP building blocks (MUC and
vCards), so it should implicitly be assumed to work.
--
Waqas Hussain
On Sat, Jul 17, 2010 at 3:10 AM, Peter Saint-Andre wrote:
> On 7/16/10 3:58 PM, Waqas Hussain wrote:
>
>> I'd love that. Not having a fixed timestamp was one reason last
>> activity didn't make it into XEP-0227 (IIRC it was the only data
>> servers commonly st
On Sat, Jul 17, 2010 at 2:39 AM, Peter Saint-Andre wrote:
> There's an inconsistency between last activity (XEP-0012) and various
> other time-related specs (XEPs 82, 202, 203). Consider:
>
> id='last1'
> to='ro...@montague.net/orchard'
> type='result'>
>
>
>
> vs.
>
> from='jul..
won't change existing behavior at all.
> If either of clients do not support element, it won't notice
> anything. It will just process notification and following
> notification either will not be sent or will be ignored. If both of
> them are supporting new XEP, then after receiving notification,
> you'll get notification just after message on the other side will
> be marked as "read".
> Now, tell me, how this extension of the original behavior can break it,
> making "awkward, error prone, and of limited utility"? Or how it can make
> suffer anyone?
>
Yes, as noted above: does what you want.
--
Waqas Hussain
limited utility: i.e., very unwelcome.
A lot of people are on wireless networks, or have otherwise turbulent
connections, or have servers which crash. This isn't a rare problem at
all. Your useful ability can be achieved through other means
(XEP-0085: Chat State Notifications). Don't force the rest of us to
suffer please.
--
Waqas Hussain
ccount cancellation (SHOULD NOT inclde 'from'
or 'to' attributes) should apply to password change as well. And it
should be clarified that the server should in fact handle
jabber:iq:register stanzas to both the user's bare JID, and to the
host itself.
--
Waqas Hussain
On Wed, Jun 9, 2010 at 5:51 AM, XMPP Extensions Editor wrote:
> Version 0.3 of XEP-0109 (Out-of-Office Messages) has been released.
>
> Abstract: This document defines an XMPP protocol extension for communicating
> out-of-office status.
>
> Changelog: [See revision history] (rdp)
>
> Diff: http:/
onses.
Currently SIFT allows blocking IQs based on payload. The server
auto-reponds with an error. It would be interesting if the server
could be made to reply with an IQ result preset by the client.
Maybe something along these lines:
[...] service discovery reply payload here [...]
The above example has some issues (think service discovery nodes), but
the approach is worth considering regardless. This fits perfectly for
version replies, etc.
4. mod_sift for Prosody
Our implementation is a work in progress, but it does the basics.
Hopefully we'll have some implementation experience soon. Now if only
those client developers hurry up.
Docs: http://code.google.com/p/prosody-modules/wiki/mod_sift
Source:
http://code.google.com/p/prosody-modules/source/browse/mod_sift/mod_sift.lua
--
Waqas Hussain
On Sun, Feb 28, 2010 at 1:08 AM, Stephan Maka wrote:
> Waqas Hussain wrote:
>> I propose that we start a small project to act as an aggregator for existing
>> open source implementations which could be used as references. Once we have
>> that going, an implementation selecte
On Mon, Feb 22, 2010 at 1:26 PM, Simon Josefsson wrote:
> Waqas Hussain writes:
>
>> There are a number of algorithms an XMPP developer needs to deal with,
>> either directly or through a library. Some of these are defined in XEPs,
>> while some are external specifica
,
under a permissive license.
I’m hoping to not be the only one who sees this as a problem we should
solve. What does everyone else think?
--
Waqas Hussain
according to section 4.3. Example 12 in that list would be
correct with the above suggested correction to section 4.3.
--
Waqas Hussain
e the dummy feature. The thread on the security ML
talks about several related attacks, of which this one is probably the most
minor.
On Wed, Sep 23, 2009 at 8:28 PM, Peter Saint-Andre wrote:
> On 9/23/09 8:05 AM, Waqas Hussain wrote:
>
> > Sure, but I see no point in implementations ac
ally talks about missing 'type'
> > attributes. This ought to be fixed.
>
> That's a spec bug in XEP-0115, because 'type' is a MUST in XEP-0030.
>
> Peter
>
--
Waqas Hussain
able because it simplifies implementations, and
is exactly the same as popular hashing functions (MD5, SHA, etc). Specifying
minimum lengths is fine, but is there a reason for receiving implementations
to actually enforce these limits?
The caps algorithm in XEP-0115 actually talks about missing 'type'
attributes. This ought to be fixed.
--
Waqas Hussain
are more than
three levels deep in the document. Text about this needs to be added to the
XIncludes section, and the Security Considerations section.
--
Waqas Hussain
On Wed, Sep 9, 2009 at 10:58 PM, Peter Saint-Andre wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 9/6/09 12:28 PM, Waqas Hussain wrote:
>
> > Now with the short answers out of the way, I do have some concerns.
> >
> > The specification does three
On Mon, Sep 7, 2009 at 12:12 AM, Egon Willighagen <
egon.willigha...@gmail.com> wrote:
> Dear Wasaq,
>
> On Sun, Sep 6, 2009 at 8:28 PM, Waqas Hussain wrote:
> > Some problems with the XEP:
> >
> > 1. The XEP basically allows a service to expose a set of gl
surance that it didn’t change since you
last checked). For something like Prosody, where we might be exposing
hundreds of functions, which can appear and disappear when modules
(including third-party modules) are loaded/unloaded, this makes for some
nastiness.
--
Waqas Hussain
d messages from an entity would
always be ordered by timestamp? A specific case I'm thinking of is
history sync for distributed MUC rooms (of course, that has additional
quirks and concerns).
--
Waqas Hussain
> 1. Who has implemented XEP-0202? Please note that the protocol must be
> implemented in at least two separate codebases (and preferably more).
Prosody has had a mod_time since November 2008 (before Prosody 0.1 was
released).
e specification accurate and clearly written?
Yes.
> Your feedback is appreciated!
Good.
--
Waqas Hussain
e that EXTADD is indeed correct an I'll file
> the appropriate bugs at the Psi and Gajim bugtracker.
>
> Regards,
> Daniel Willmann
>
EXTADD is correct. EXTADR is not.
Neither the vcard-temp XEP, nor draft-dawson-vcard-xml-dtd-01 have any
mention of EXTADR.
--
Waqas Hussain
On Fri, May 15, 2009 at 8:15 AM, Peter Saint-Andre wrote:
>> The namespace seems to have retained its roots instead of using sift.
>
> Not sure what you mean here.
>
s/urn:xmpp:dc:0/urn:xmpp:sift:0/ under
http://xmpp.org/extensions/inbox/sift.html#registrar-ns
lear and nobody will ever have any problem reading
> it. Examples are way more confusing because of some theoretical idiot
> that's implementing example and not the XEP. Do we really want to make
> obscure examples because of people that are probably incapable of
> implementing it at all?
>
I for one don't see the examples as obscure at all.
--
Waqas Hussain
r" approach. I would prefer to err on the
>> side of not misleading clients about sequentiality ("the examples have
>> A and B so I suppose the next 'ver' will be C" and then the
>> client breaks when that's not the case).
>>
>> Peter
>>
>
> Ok, so in order to not confuse stupid programmers with a specific
> implementation, we will confuse them with one entirely impossible. I
> get your thinking *THUMBS UP*
>
Programmers for whom ver='qAxdnWNcA+lYf7CoN5wpBsvVVno=' would be
entirely impossible... I think those exact programmers are the reason
for not using ver='1' :-)
The XEP is short and clear. The 'ver' attribute is an opaque string
for clients, and client programmers shouldn't care what it's value is.
I don't see a problem here.
--
Waqas Hussain
On Tue, May 12, 2009 at 4:40 AM, Justin Karneges
wrote:
> On Monday 11 May 2009 16:28:00 Waqas Hussain wrote:
>> On Mon, May 11, 2009 at 7:10 PM, Peter Saint-Andre
> wrote:
>> > Can you trust the order of items?
>>
>> Err, explain to me why you wouldn't. O
order of your XML, the various XMPP
specs' dependency on in-order processing would be affected. Sending
multiple stanzas in a single TCP/BOSH packet would start having
consequences.
> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
--
Waqas Hussain
ing, or is this historical baggage? I don't see anything gained
by explicitly specifying order. Part of some discarded list editing
protocol maybe?
--
Waqas Hussain
f course, change dramatically if we
> introduce a non-meshed routing architecture between servers - since that
> reassociates responsibility anyway, it's not a problem there. (FWIW, I would
> note that this already occurs between client and home server).
>
> Dave.
> --
> Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
> - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
> - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>
--
Waqas Hussain
On Thu, Mar 5, 2009 at 5:37 PM, Pedro Melo wrote:
> Hi,
>
> On Feb 28, 2009, at 10:18 AM, Waqas Hussain wrote:
>>
>> On Thu, Feb 26, 2009 at 9:32 AM, Pedro Melo wrote:
>>>
>>> On Feb 25, 2009, at 7:36 PM, Pavel Simerda wrote:
>>>>
>>>
y.
If there is an inconsistency, the receiving server can take an
appropriate action.
What action is appropriate is open for debate. What should the
resulting state be? The lowest common permissions (possibly sending
unsubscribe[d] to the contact or changing the user's subscription for
contact)? The highest common permissions (possibly sending a
subscrive[d] to the contact and changing the user's subscription for
the contact)?
>From an IM user's point of view, trying to settle on the highest
common permissions seems more appropriate (and less confusing).
--
Waqas Hussain
re not a replacement for privacy lists. I have often wanted to
appear offline to a select group of people, but that doesn't mean I
don't want to see their presence.
Partial roster activation is a much much more attractive feature for
me than partial roster retrieval. I would probably never consider
using partial roster retrieval for my jabber account.
Anyway, some things to consider for roster views:
1. More than one activated group at a time needs to work
2. They may be more useful if they worked based on filters on all data
associated with a contact, e.g., groups, subscription, hosts
3. IM users would obviously want to change the activated groups more
than once during a session, so that needs to be covered
Fabio Forno's email covers 1 and 2. As for the RFC vs XEP argument, my
personal opinion is to keep the RFC short, and have these in an XEP,
but I don't feel too strongly about that.
--
Waqas Hussain
't display it
though. Sending unavailable presence for unavailable participants with
messages in history may cause some clients to display leave messages
including JIDs, but that's a hack.
--
Waqas Hussain
> --
> Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
> - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
> - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>
--
Waqas Hussain
1 - 100 of 106 matches
Mail list logo
