Curtis King wrote:
>
> On 27-Oct-08, at 3:28 PM, Peter Saint-Andre wrote:
>
>> What about things like SOAP over XMPP? There are lots of prefixes in
>> that spec:
>>
>> http://xmpp.org/extensions/xep-0072.html
>>
>> However that's just about the only such spec I know of.
>
> I never said it would
On Tue, Oct 28, 2008 at 3:41 PM, Pedro Melo <[EMAIL PROTECTED]> wrote:
>
> On Oct 28, 2008, at 5:23 AM, Sergei Golovan wrote:
>>
>> There's another extension (and it's even implemented):
>> http://code.google.com/apis/talk/jep_extensions/roster_attributes.html
>
> No, the router part of your server
On Oct 28, 2008, at 5:23 AM, Sergei Golovan wrote:
On Tue, Oct 28, 2008 at 1:28 AM, Peter Saint-Andre
<[EMAIL PROTECTED]> wrote:
What about things like SOAP over XMPP? There are lots of prefixes in
that spec:
http://xmpp.org/extensions/xep-0072.html
However that's just about the only such
On Tue, Oct 28, 2008 at 1:28 AM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
>
> What about things like SOAP over XMPP? There are lots of prefixes in
> that spec:
>
> http://xmpp.org/extensions/xep-0072.html
>
> However that's just about the only such spec I know of.
There's another extension (an
On 27-Oct-08, at 3:28 PM, Peter Saint-Andre wrote:
What about things like SOAP over XMPP? There are lots of prefixes in
that spec:
http://xmpp.org/extensions/xep-0072.html
However that's just about the only such spec I know of.
I never said it would be painless :-)
I think all sides have p
Curtis King wrote:
>
> On 21-Oct-08, at 6:47 AM, Peter Saint-Andre wrote:
>
>> Curtis King wrote:
>>>
>>> On 20-Oct-08, at 7:37 PM, Peter Saint-Andre wrote:
>>>
>
> Please understand that even if we use MUST instead of SHOULD with
> respect to namespace-awareness, the existing servers
Brendan Taylor wrote:
> Throwing another idea out there; since we're not *really* using
> namespaces anyways, could we just reject elements and attributes with
> colons in their names? (besides the xml: attributes, of course)
> IIRC XMPP entities aren't expected to understand namespace prefixes
> a
On Sat, Oct 25, 2008 at 11:48 AM, Artur Hefczyc
<[EMAIL PROTECTED]> wrote:
>> Just so you know, that parser is not a conforming XML parser. Tigase
>> happily accepts data that is not XML-well-formed, and happily routes
>> or delivers it.
> That's true but please note that XMPP stream is not really
On Sat, Oct 25, 2008 at 3:48 PM, Artur Hefczyc <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am glad somebody has responded to my post :-)
>
>>> Without tests I can't really say how much the resource usage would grow
>>> but I can imagine it could be significant.
>>> One of the reason for a good performan
Hi,
I am glad somebody has responded to my post :-)
Without tests I can't really say how much the resource usage would
grow
but I can imagine it could be significant.
One of the reason for a good performance in Tigase server is a very
lightweight XML parser I have written.
Just so you know
On Fri, Oct 24, 2008 at 3:12 AM, Artur Hefczyc <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am the server developer so let me add something to the discussion
> even if this is not a direct response to anybody post.
>
> I think I understand the point but my opinion is if people want to push
> more and mor
Throwing another idea out there; since we're not *really* using
namespaces anyways, could we just reject elements and attributes with
colons in their names? (besides the xml: attributes, of course)
IIRC XMPP entities aren't expected to understand namespace prefixes
anyhow.
(I've never written a pa
On 23-Oct-08, at 3:12 PM, Artur Hefczyc wrote:
Hi,
If the server had to validate XMLNS as well it would significantly
affect the server performance and memory consumption as it would need
to keep information about XMLNS for stanzas currently parsed for all
network connections.
Good point. I
On 23-Oct-08, at 11:58 AM, Sergei Golovan wrote:
On Thu, Oct 23, 2008 at 10:38 PM, Curtis King <[EMAIL PROTECTED]> wrote:
One the of the big strength of the xmpp model is that servers can
route and
do all the heavy lifting for the business rules, etc by just parse
the outer
parts of the
Hi,
I am the server developer so let me add something to the discussion
even if this is not a direct response to anybody post.
I think I understand the point but my opinion is if people want to push
more and more processing on the server to make live easier on the
client side then the server ins
On Thu Oct 23 19:58:32 2008, Sergei Golovan wrote:
On Thu, Oct 23, 2008 at 10:38 PM, Curtis King <[EMAIL PROTECTED]>
wrote:
>
> One the of the big strength of the xmpp model is that servers can
route and
> do all the heavy lifting for the business rules, etc by just
parse the outer
> parts
On Thu, Oct 23, 2008 at 10:38 PM, Curtis King <[EMAIL PROTECTED]> wrote:
>
> One the of the big strength of the xmpp model is that servers can route and
> do all the heavy lifting for the business rules, etc by just parse the outer
> parts of the xml stanza.
XML is such a wondeful language where y
On 21-Oct-08, at 6:47 AM, Peter Saint-Andre wrote:
Curtis King wrote:
On 20-Oct-08, at 7:37 PM, Peter Saint-Andre wrote:
Please understand that even if we use MUST instead of SHOULD with
respect to namespace-awareness, the existing servers are not
going to
be left behind. Newer servers a
Dave, what text would you propose?
As a reminder, the provisional text in version -08 of rfc3920bis is:
***
12.3. Well-Formedness
There are two varieties of well-formedness:
o "XML-well-formedness" in accordance with the definition of "well-
formed" in Section 2.1 of [XML].
o
On Tue Oct 21 00:53:35 2008, Waqas wrote:
The expat parser (as an example) in namespace-aware mode reports a
fatal error on undeclared prefixes. This was added in response to
this
bug report:
http://sourceforge.net/tracker/index.php?func=detail&aid=695401&group_id=10127&atid=110127
which ref
On Tue, Oct 21, 2008 at 2:47 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> Curtis King wrote:
>>
>> On 20-Oct-08, at 7:37 PM, Peter Saint-Andre wrote:
>>
Please understand that even if we use MUST instead of SHOULD with
respect to namespace-awareness, the existing servers are no
Curtis King wrote:
>
> On 20-Oct-08, at 7:37 PM, Peter Saint-Andre wrote:
>
>>>
>>> Please understand that even if we use MUST instead of SHOULD with
>>> respect to namespace-awareness, the existing servers are not going to
>>> be left behind. Newer servers and server versions are still going to
On 20-Oct-08, at 7:37 PM, Peter Saint-Andre wrote:
Please understand that even if we use MUST instead of SHOULD with
respect to namespace-awareness, the existing servers are not going to
be left behind. Newer servers and server versions are still going to
continue to support their legacy count
Waqas wrote:
> On Mon, Oct 20, 2008 at 9:01 PM, Dave Cridland <[EMAIL PROTECTED]> wrote:
>
>> If you receive invalid XMLNS, however, it might have come from anywhere, and
>> merely been forwarded on to you. ANd there's at least three ways of handling
>> it.
>>
>> a) Assume that undeclared prefixes
---snip---
I should clarify my position. I would like:
"An XMPP entity MUST NOT send out data that is not namespace-well-formed"
This includes data which it generates, and data which it routes or delivers.
What an entity which is routing or delivering may do is accept data
which is not namespac
On Mon, Oct 20, 2008 at 9:01 PM, Dave Cridland <[EMAIL PROTECTED]> wrote:
> On Mon Oct 20 04:40:56 2008, Waqas wrote:
>>
>> On Tue, Oct 14, 2008 at 3:28 AM, Peter Saint-Andre <[EMAIL PROTECTED]>
>> wrote:
>> > "an entity SHOULD be liberal in accepting such data."
>>
>> This translates to:
>>
>> "a
On Mon Oct 20 04:40:56 2008, Waqas wrote:
On Tue, Oct 14, 2008 at 3:28 AM, Peter Saint-Andre
<[EMAIL PROTECTED]> wrote:
> "an entity SHOULD be liberal in accepting such data."
This translates to:
"an entity SHOULD NOT use a namespace-validating parser (as
defined
in [XML-NAMES])"
No, I
On Tue, Oct 14, 2008 at 3:28 AM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
>
> OK here's what I have now in my working copy of rfc3920bis:
>
> ***
>
> 12.3. Well-Formedness
>
> There are two varieties of well-formedness:
>
> o "XML-well-formedness" in accordance with the definition of "wel
Brendan Taylor wrote:
> On Wed, Oct 15, 2008 at 06:11:56AM -0600, Peter Saint-Andre wrote:
>> Brendan Taylor wrote:
>>> I just noticed this clause:
>>>
>>> ... but MUST NOT return a stream error in response to the receipt
>>> of [Bad XMLNS].
>>>
>>> Why is that there? Silently dropping the stan
On Wed, Oct 15, 2008 at 06:11:56AM -0600, Peter Saint-Andre wrote:
> Brendan Taylor wrote:
> > I just noticed this clause:
> >
> > ... but MUST NOT return a stream error in response to the receipt
> > of [Bad XMLNS].
> >
> > Why is that there? Silently dropping the stanza seems like a bad ide
Brendan Taylor wrote:
> 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 M
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 respon
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 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
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
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?
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
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-for
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 i
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'
On Tue Oct 14 17:59:35 2008, Jonathan Schleifer wrote:
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
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…
--
Jo
On Tue Oct 14 17:45:03 2008, Jonathan Schleifer wrote:
Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> Maybe I agree with you ("simple clients, complex servers"), but
I'd
> like to hear what other server and client developers think.
For Gajim, it was very hard to patch it.
No it wasn't.
Da
Jonathan Schleifer wrote:
> Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
>
>> Maybe I agree with you ("simple clients, complex servers"), but I'd
>> like to hear what other server and client developers think.
>
> For Gajim, it was very hard to patch it.
> For ejabberd, the patch was pretty easy.
Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> Maybe I agree with you ("simple clients, complex servers"), but I'd
> like to hear what other server and client developers think.
For Gajim, it was very hard to patch it.
For ejabberd, the patch was pretty easy.
I know, there is no patch in ejabberd
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 t
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,
OK here's what I have now in my working copy of rfc3920bis:
***
12.3. Well-Formedness
There are two varieties of well-formedness:
o "XML-well-formedness" in accordance with the definition of "well-
formed" in Section 2.1 of [XML].
o "Namespace-well-formedness" in accordance wi
48 matches
Mail list logo
