Hi,
1) I think Example 191 in http://xmpp.org/extensions/xep-0060.html
should have member-affiliation, outcast-affiliation, or
publisher-affiliation as a feature instead of modify-affiliations
(which is covered in the previous example).
2) And immediately preceding example 122, there is
Hi,
Also, in examples 191-194, I believe the sender's XML (sent back with
the error) should have been related to an attempt to modify the
affiliations since that is the subject of that section.
Brett
On Tue Oct 14 02:32:08 2008, Peter Saint-Andre wrote:
So anything starting with urn:xmpp:stream: would be handled in this
special way? I don't know whether I like that, since there are
exceptions for older namespaces etc.
Most of the exceptions are mandated to be supported by RFC 3920. The
On Tue, Oct 14, 2008 at 2:28 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
OK here's what I have now in my working copy of rfc3920bis:
An XMPP entity MUST NOT generate data that is not namespace-well-
formed. An XMPP server SHOULD NOT route or deliver data that is not
Unfortunately, this
The following unsupported type errors are in the schema, but I'm not
sure they can actually be triggered (and if so under what circumstances):
1) At the end of 8.1.3, it seems to me to indicate an error would not be
returned: If the create-and-configure option is not supported but the
Am 14.10.2008 um 04:12 schrieb Justin Karneges:
What I'd suggest as a solution to this problem is to have two levels
of
privacy: 1) roster subscriptions, and 2) presence. Contacts with
subscriptions would have full access, but those with just presence
(MUC
rooms, or directed presence with
Dave Cridland wrote:
On Tue Oct 14 02:32:08 2008, Peter Saint-Andre wrote:
So anything starting with urn:xmpp:stream: would be handled in this
special way? I don't know whether I like that, since there are
exceptions for older namespaces etc.
Most of the exceptions are mandated to be
Dave Cridland wrote:
On Tue Oct 14 02:35:08 2008, Peter Saint-Andre wrote:
Right, as long as you never send stream management data unless you first
learn that the other side supports the protocol, this seems fine.
But that's not what happens.
What happens is that the client (initiator)
On Tue Oct 14 15:53:03 2008, Peter Saint-Andre wrote:
What exactly do you mean by namespacing the namespaces?
Beginning stream namespaces with a specific prefix - essentially,
having non-extension namespaces in a specific part of the URN tree.
Dave.
--
Dave Cridland - mailto:[EMAIL
On Tue Oct 14 02:35:08 2008, Peter Saint-Andre wrote:
Right, as long as you never send stream management data unless you
first
learn that the other side supports the protocol, this seems fine.
But that's not what happens.
What happens is that the client (initiator) declares the namespace
Alban Crequy wrote:
Hi,
To start a link-local conversation with XEP-0174 between two clients,
any of the 2 clients can initiate the stream. If the 2 contacts start
to chat at the same time, we may have 2 streams initiated in both
directions. It seems this case does not happen often because
Dave Cridland [EMAIL PROTECTED] wrote:
No it wasn't.
A patch for ejabberd was ready in 2 days, I'm using that on my server
and never got a problem. For Gajim, it tooks *MONTHS* to get a fix.
Wasn't that bug even open for more than 1 year? So what's easier to fix
now? Clearly ejabberd…
--
Dave Cridland [EMAIL PROTECTED] wrote:
Erm. I wrote the fix for Gajim, I'm well aware of how long it took
me, from a first look to a fix. I'd put it at two days elapsed, but
about three hours of actual coding. I'd dispute the idea I was
trying to get it done for more than a year - I've
FYI.
Original Message
Date: Tue, 14 Oct 2008 12:36:42 +0100
From: Kevin Smith [EMAIL PROTECTED]
To: XMPP Council [EMAIL PROTECTED]
Subject: [Council] Council meeting 2008-10-15
Hi all.
Assuming I managed to do this correctly, there should be an agenda
for tomorrow's meeting
tis 2008-10-14 klockan 11:56 -0600 skrev Peter Saint-Andre:
Marcus Lundblad wrote:
One thing I was thinking about is determining the amount of time a user
has been idle. The way it works now is that, using this XEP, you'd
send out an iq/ get to find out.
Yes, polling is bad.
Do
On Tue, Oct 14, 2008 at 2:12 AM, Peter Saint-Andre [EMAIL PROTECTED]wrote:
1. Who has implemented XEP-0012? Please note that the protocol must
implemented in at least two separate codebases.
I implemented this for Pandion a long while back. Client requests the
iq:last time to show the user
Dave Cridland wrote:
On Tue Oct 14 15:53:03 2008, Peter Saint-Andre wrote:
What exactly do you mean by namespacing the namespaces?
Beginning stream namespaces with a specific prefix - essentially, having
non-extension namespaces in a specific part of the URN tree.
OK. I think that's fine:
On 14-Oct-08, at 4:36 AM, Jonathan Schleifer wrote:
Am 14.10.2008 um 00:11 schrieb Dave Cridland:
Yes, because sending large binary attachments would be so much
easier then.
If both are online at the same time, it is. And saves traffic. For
everyone - client and server.
And think of
On Tue, Oct 14, 2008 at 10:36:09AM -0600, Peter Saint-Andre wrote:
Maybe I agree with you (simple clients, complex servers), but I'd like
to hear what other server and client developers think.
XMPP has mostly avoided Postel's Law. Nobody has to deal with ill-formed
XML because nobody sends
Brendan Taylor wrote:
On Tue, Oct 14, 2008 at 10:36:09AM -0600, Peter Saint-Andre wrote:
Maybe I agree with you (simple clients, complex servers), but I'd like
to hear what other server and client developers think.
XMPP has mostly avoided Postel's Law. Nobody has to deal with ill-formed
XML
Thanks, I'll review these soon.
Brett Zamir wrote:
Hi,
1) I think Example 191 in http://xmpp.org/extensions/xep-0060.html
should have member-affiliation, outcast-affiliation, or
publisher-affiliation as a feature instead of modify-affiliations
(which is covered in the previous example).
Am 14.10.2008 um 00:11 schrieb Dave Cridland:
Yes, because sending large binary attachments would be so much
easier then.
If both are online at the same time, it is. And saves traffic. For
everyone - client and server.
And think of the joy of how this would interface with the massive
I think you should also describe what a XMPP client should do upon
receiving good XML 1.0 which is also bad XML 1.1.
My preference is that the client SHOULD NOT or MUST NOT interpret
it as a stream error.
On Oct 13, 2008, at 3:28 PM, Peter Saint-Andre wrote:
OK here's what I have now in
Sergei Golovan wrote:
On Tue, Oct 14, 2008 at 2:28 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
OK here's what I have now in my working copy of rfc3920bis:
An XMPP entity MUST NOT generate data that is not namespace-well-
formed. An XMPP server SHOULD NOT route or deliver data that is
On Tue Oct 14 20:45:43 2008, Brendan Taylor wrote:
XMPP has mostly avoided Postel's Law. Nobody has to deal with
ill-formed
XML because nobody sends ill-formed XML. Nobody sends ill-formed XML
because nobody accepts it, and what use is a client or server that
nobody can receive messages from?
Robert Quattlebaum wrote:
I think you should also describe what a XMPP client should do upon
receiving good XML 1.0 which is also bad XML 1.1.
My preference is that the client SHOULD NOT or MUST NOT interpret it
as a stream error.
XMPP 1.0 supports XML 1.0 only. A future version of XMPP
On Tue, Oct 14, 2008 at 11:21:43PM +0100, Dave Cridland wrote:
Where Postel's Law applies is that XMPP speakers need to cope with XML
which *is* well-formed, but might not be namespace well-formed. This, I'll
call Bad XMLNS.
Nice coinage :).
I don't think Postel's Law should have to apply
I was actually confused into thinking that XML 1.1 was just
XML1.0+Namespaces... Which happens to not be the case.
So replace XML 1.1 with XML 1.0+Namespaces, and my original
comment will make sense. :)
On Oct 14, 2008, at 3:49 PM, Peter Saint-Andre wrote:
Robert Quattlebaum wrote:
I
On Tue, Oct 14, 2008 at 02:23:52PM -0600, Peter Saint-Andre wrote:
So how would you tweak the text I proposed?
I would make the paragraph for namespace well-formedness identical to
the one for plain well-formedness.
I just noticed this clause:
... but MUST NOT return a stream error in
29 matches
Mail list logo
