Re: [Standards] Multiple body/ elements in a HTTP request with BOSH
Well, you could treat it as multiple XML documents then. In fact, if you use HTTP keep-alive for Bosh communication you allow for multiple body elements. However, these would be separated with HTTP headers. In any case I am pretty sure Tigase would accept multiple body elements on a bosh connection. However, I think it would be really better to send multiple stanzas inside a single body element. Artur On Dec 6, 2012, at 3:05 PM, Waqas Hussain waqa...@gmail.com wrote: 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 edhe...@gmail.com 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 body/ element to save bandwidth during the session. Am I authorized to put multiple body/ elements in the same HTTP BOSH request ? Tim
[Standards] Logo image is missing
Hi, Looks like the XMPP logo image is missing. The FAQ page has a few links to logo in different format: http://xmpp.org/about-xmpp/faq/ None of the images is available under the links. Artur
Re: [Standards] Chat continuation on different device
On Dec 24, 2011, at 10:32 AM, Kim Alvefur wrote: On Fri, 2011-12-23 at 20:01 -0800, Artur Hefczyc wrote: Hi, I frequently switch IM client running on different devices (mobile, laptop, ) and I would love to have a feature to continue last chat with some recent chat messages displayed on a new device. I have an idea how to implement it in the Tigase server and our mobile client (described below) and I was wondering if there is any XEP which could aid in this task from the protocol side. XEP-0280: Message Carbons is also meant for this use case. The idea is following: 1. User chats with a friend on one device 2. Server records and remembers somehow last chats (by thread id for example) 3. User switched devices and opens chat window with a friend in the second client 4. The client requests from the server last chat with this friend (we could add some parameters here, like last chat not older than 10 minutes for example) 5. If there is no chat history the server returns an empty list, otherwise the server returns a list of chat messages 6. The client displays messages received from the server and allows the user to continue conversation. The difference being that with Carbons you opt in to receiving all messages as they are sent. This does not solve the problem really. It causes a few problems: 1. First, when I talk on a desktop client I do not really want my battery drained on mobile with constant messages sent to my mobile client. 2. It does not solve a problem in case when my mobile/desktop client is not running during the chat and then I want to switch device and start a new client. I think a simple XEP specifying: send me my chat history for the last thread would be good enough and would solve both above cases. Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/ smime.p7s Description: S/MIME cryptographic signature
[Standards] Chat continuation on different device
Hi, I frequently switch IM client running on different devices (mobile, laptop, ) and I would love to have a feature to continue last chat with some recent chat messages displayed on a new device. I have an idea how to implement it in the Tigase server and our mobile client (described below) and I was wondering if there is any XEP which could aid in this task from the protocol side. The idea is following: 1. User chats with a friend on one device 2. Server records and remembers somehow last chats (by thread id for example) 3. User switched devices and opens chat window with a friend in the second client 4. The client requests from the server last chat with this friend (we could add some parameters here, like last chat not older than 10 minutes for example) 5. If there is no chat history the server returns an empty list, otherwise the server returns a list of chat messages 6. The client displays messages received from the server and allows the user to continue conversation. I know of XEP-0136: Message Archiving which in theory could be used here as well. However, for once it is overkill for such a simple task and secondly the protocol requires a few packets exchange before the client can load last collection which increases traffic and delays. Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/ smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] throttling
My opinion on this is that we don't need application-layer throttling mechanisms. If a server wants to punish a peer, it can simply stop reading from the connection for a while. The peer doesn't have to know about this (such a notification MAY be useful for UI purposes, but I personally doubt it). I think this is not enough. Simply stop reading does not work if you want to throttle only certain types of stanzas. Also, what if MUC component wants to throttle one account? Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/ smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] stanza order and MUC
Right. Ordering is important enough that I think this issue deserves more than one sentence in the RFC. It seems our choices are: 1) Entity is a Full JID. Resource locking (RFC 3921) and MUC (XEP-0045) need repairs, or we just live with their problems and try not to repeat them. 2) Entity is a Bare JID. Everything works as Jeremy Himself intended. I think it needs a bit more explanation. I guess not everybody (myself for example) knows what Jeremy Himself intended. Specifically, the Bare JID may have a few connections to the server and there might be packets addresses to different resources. What the above sentence means in this context? Can developers of various servers describe their current ordering policies? It would be interesting to see just how the spec has been interpretted so far. I tried a few different approaches. It is quite easy to switch between them in the Tigase. In order processing per TCP/IP stream, per sender address, per received address (not bare JID though, I will try that next time I run tests). Even though it appears to be working correctly in the test system, nothing seems to guarantee 100% packet in order delivery in some border cases unless you switch to single threaded mode which is not feasible. Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
Re: [Standards] stanza order and MUC
On Sep 29, 2010, at 10:07 PM, bschumac wrote: On 9/29/10 1:02 PM, Justin Karneges wrote: In other words, the XEP is saying to send like this: presence to=user from=room/existing_occupant1/ presence to=user from=room/existing_occupant2/ presence to=user from=room/new_occupant/ However, any XMPP server (whether the one the MUC component is connected to, or the user's, which may be over s2s) may route these stanzas in any order, because the from JIDs are all different. It would be perfectly legal for the user's server to relay the stanzas to the user in this order: presence to=user from=room/existing_occupant2/ presence to=user from=room/new_occupant/ presence to=user from=room/existing_occupant1/ I see this issue becoming greater as XMPP servers become more optimized, threaded, clustered, etc. Maintaining delivery order comes at a cost, and you can be sure implementors will avoid that cost where allowed (indeed, this thread was prompted after discussions I had with Artur of Tigase and his desire to bend delivery rules for speed sake). I believe the RFC is ambiguous in this regard and the XEP depends on an understood reading of the RFC that perhaps isn't spelled out well enough. Section 10.1 of RFC3921bis [1] simply states: An XMPP server MUST ensure in-order processing of XML stanzas between any two entities. This includes stanzas sent by a client to its server for direct processing by the server (e.g., in-order processing of a roster get and initial presence as described in [XMPP‑IM]). In my opinion the expected behavior in this regard has always been between two Bare JIDs -- from: localp...@domainpart to: localp...@domainpart. I am afraid, in most cases there is no such thing like between two bare JIDs. If two users talk to each other and each of these users have two connections (resources) then what in this context mean between two Bare JIDs. Please note also the RFC says between any two entities. Even though it does not specific whether this is between the entity sending the packet and receiving the packet or between the entity in 'from' address and 'to' address which is not always the same thing. I assume the RFC means between entities specified in 'from' and 'to' address. Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
Re: [Standards] stanza order and MUC
On Sep 29, 2010, at 10:17 PM, Florian Zeitz wrote: On 29.09.2010 21:02, Justin Karneges wrote: On Wednesday 29 September 2010 11:06:39 Matthew A. Miller wrote: On Sep 29, 2010, at 11:42 , Justin Karneges wrote: The rule is that stanzas must be delivered in order for a given source/destination JID pair. However, a MUC service sends stanzas from many different JIDs if you consider the varying resources, and therefore it cannot have any expectation that its sent stanzas will maintain order. This means that when a client joins a room, the room history might be received before the presence ack of the join attempt, and individual messages within the room history itself might get reordered. I believe sections 7.1.3 and 7.1.15 of XEP-0045 account for the order of presence and room history correctly. Yes, the XEP specifies the order that the MUC service should send out stanzas when it matters. The problem is that the stanzas are formulated in such a way that we can't expect XMPP-Core delivery order rules to hold. from Section 7.1.3: Note: The order of the presence stanzas sent to the new occupant is important. The service MUST first send the complete list of the existing occupants to the new occupant and only then send the new occupant's own presence to the new occupant. This helps the client know when it has received the complete room roster. In other words, the XEP is saying to send like this: presence to=user from=room/existing_occupant1/ presence to=user from=room/existing_occupant2/ presence to=user from=room/new_occupant/ However, any XMPP server (whether the one the MUC component is connected to, or the user's, which may be over s2s) may route these stanzas in any order, because the from JIDs are all different. It would be perfectly legal for the user's server to relay the stanzas to the user in this order: presence to=user from=room/existing_occupant2/ presence to=user from=room/new_occupant/ presence to=user from=room/existing_occupant1/ I see this issue becoming greater as XMPP servers become more optimized, threaded, clustered, etc. Maintaining delivery order comes at a cost, and you can be sure implementors will avoid that cost where allowed (indeed, this thread was prompted after discussions I had with Artur of Tigase and his desire to bend delivery rules for speed sake). Hi, 3920bis actually doesn't talk about a source/destination JID pair, but says: An XMPP server MUST ensure in-order processing of XML stanzas between any two entities. I would argue that the two entities in this case are the MUC component and the users server. The server must then process the stanzas in the order it received them from the MUC, where processing means sending them to the client. The interesting question seems to me: Can a server actually make that promise? It'd have to be able to distinguish r...@server/nick from u...@server/resource. Indeed, how is the server supposed to distinguish between the MUC component and other entity? In theory the server can query each sender and received for service disco to find out. In theory possible, even though highly inefficient still does not solve the problem fully. Please note, the MUC component is just one of border cases which may cause such problems. There are lots of different use cases where we can encounter similar problems with packets ordering between entities which are visible behind multiple JIDs/resources. Or it'd have to process all stanzas coming over the same XMPP stream in-order, which might actually be the intended behavior. What you mean by XMPP stream? Does it include S2S and all external components too? What about built-in components? Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
[Standards] XEP-0079 Advanced Message Processing
Hi,
I am almost finishing implementation of this XEP.
Either I am wrong or there is a mistake in following XEP's examples:
7, 8 and 9 which show the server response to the user/client.
Let me take the example 7 as an example ;-)
Example 7. Alert Response
message from='hamlet.lit'
to='berna...@hamlet.lit/elsinore'
id='chatty2'
amp xmlns='http://jabber.org/protocol/amp'
status='alert'
from='franci...@hamlet.lit'
to='berna...@hamlet.lit/elsinore'
rule action='alert' condition='deliver' value='stored'/
/amp
/message
The incorrect part in my opinion is 'to' and 'from' attributes
in the message or/and in the amp element.
The alert is sent back to the original message sender
('berna...@hamlet.lit/elsinore')
in the above example, therefore this JID should be placed in 'from' attribute in
amp element. Or I am wrong and misunderstood the XEP?
Artur
--
Artur Hefczyc
http://www.tigase.org/
http://artur.hefczyc.net/
[Standards] XEP-0225 Component Connections - namespaces again
I have already mentioned about the issue here in another thread but I think it is best to discuss it separately. The XEP uses 'jabber:client' namespace which is great as it avoid xmlns problems I have recently encountered with s2s connections and XEP-0114 connections. I have implemented the XEP in the Tigase server and it supports both multiple connections on single port, domains bindings, etc... There is one significant problem though. The XEP uses the same exact elements and namespace for protocol handshaking (authentication, tls, etc) as the client to server connection. This makes it actually impossible to put c2s connection managers behind XEP-0225 link as then there is no way to reliably detect whether the SASL or starttls comes from the client or from the component on the other side of the link. Of course we can guess (the link is already authenticated to this SASL request must come from the client) but this is not a good way to do it. My suggestion is to modify the XEP to simply say something like this: All packets with top-level element within namespace 'urn:xmpp:component:0' are the XEP-0225 handshaking stanzas, all packets within 'jabber:client' are the client stanzas which should be forwarded to/from external component. Ideally this approach could be adopted for all other connections (s2s, xep-0114, etc). I know that's not going to happen any time soon though. Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
[Standards] Is there any support XEP-0079 in clients?
Hi, I have just added initial version of XEP-0079 (Advanced Message Processing) support in the Tigase server. I wonder if there is any client offering support too to see how it works. For anybody interested in trying it out. The jabber.me/tigase.im service runs with Tigase version offering AMP right now. Any comments are very welcomed. Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
Re: [Standards] Stanza namespaces
Hi, I normally don't participate to such discussions because they tend to be lengthy with no practical outcome. However, I encountered a few problems related to xmlns handling recently both with jabber.org (M-Link) and transports and also with XEP-0225. I think sharing my thought and experience might be useful. In XMPP, each stream has a default namespace. Stanzas are the elements with local-name message, presence, or iq, qualified by that default namespace. Streams also have other, specifically documented, top-level elements, such as those for SASL, or TLS negotiation - these being explicitly signalled as being acceptable. Other unknown top-level elements will cause the connection to be dropped. My understanding of the spec is that it defines a default namespace for top level elements but it does not forbids you from sending elements within a different namespace as long as this different namespace can be understood. The thing is that converting namespaces between jabber:client, jabber:server, jabber:component:accept does not make much practical sense and on the server side it does impact the performance. Please note, right now from the server point of view we have 2 namespaces: jabber:client and jabber:server. During s2s communication the server blindly converts xmlns from jabber:client to jabber:server when sending the packet and the receiving server blindly converts xmlns from jabber:server to jabber:client. There is no practical meaning for this xmlns conversion and there is no way we can extend it. I mean, let's say we create a monitor component and we would like it to send packets within jabber:monitor namespace (for whatever reason). There is currently now way we can send such packets through s2s and preserve the namespace. So I suggest we understand the spec as it defines a default namespace for top-level elements unless the element has a different namespace set. Just think of a practical implications and what would serve us best. The only place where I can see usage for a different namespaces are the protocol control packets: s2s handshaking, XEP-0225 handshaking, XEP-0114 handshaking etc... Especially for the XEP-0225 this is quite important. Right now it shares the same xmlns for the connection handshaking and other traffic. Therefore it is impossible to put c2s connection manager over the XEP-0225 connection because you never know whether the SASL or startls packets refers to the XEP-0225 connection or the c2s user connection. In particular, §4.5.2 of rfc3920bis states: A default namespace declaration is REQUIRED and defines the allowable first-level children of the root stream element. Note that §A.1 includes: xs:choice minOccurs='0' maxOccurs='1' xs:choice minOccurs='0' maxOccurs='unbounded' xs:element ref='client:message'/ xs:element ref='client:presence'/ xs:element ref='client:iq'/ /xs:choice xs:choice minOccurs='0' maxOccurs='unbounded' xs:element ref='server:message'/ xs:element ref='server:presence'/ xs:element ref='server:iq'/ xs:element ref='db:result'/ xs:element ref='db:verify'/ /xs:choice /xs:choice (In other words, either client or server+db elements appear, never both). And §4.6.3.24 describes the unsupported-stanza-type stream error: The initiating entity has sent a first-level child of the stream that is not supported by the server or consistent with the default namespace. Now... My assertion is that if a server sees, on an S2S stream, a top-level element of local-name message qualified by a namespace of jabber:client, for example, it should - for strict conformance with the specification - issue a stream error and shut down the stream. I do not know what was the original author's intention for this statement. My understanding of this is that: the server supports both jabber:client and jabber:server namespaces. 'OR' returns false if both sides of the OR are false. Therefore, if the server receives jabber:client packet over s2s stream it should still be acceptable because this 'first-level child element' is supported by the server which fulfils the first requirement. In a recent change to M-Link, we tightened up our handling of namespaces on stanzas, so we are now conformant WRT the above. Regardless whose understanding is correct about the spec above. I am also concerned what are the benefits of that change? One of the greatest advantages of the XMPP protocol you hear is it's flexibility and openness. I am really keen on staying 100% close to the spec but in places where the spec is not 100% clear, I prefer not to put artificial restrictions. Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
Re: [Standards] Stanza namespaces
Note: Because a client sends stanzas over a stream whose default namespace is 'jabber:client', if the server to which the client is connected needs to route a client-generated stanza to another server then it MUST re-scope the stanza so that its default namespace is 'jabber:server' (i.e., it MUST NOT send a stanza qualified by the 'jabber:client' namespace over a stream whose default namespace is 'jabber:server'). Similarly, a routing server MUST re-scope a stanza received over a server-to-server stream (whose default namespace is 'jabber:server') so that the stanza is qualified by the 'jabber:client' namespace before sending it over a client-to-server stream (whose default namespace is 'jabber:client'). *** That might not be precise enough, and it leaves out the error handling. That seems fairly definitive and, as Dave mentions, the error handling is already defined elsewhere. It's definitive, but it might not be correct. Do we need to be so strict about this? That's the question. Especially that it also applies to the external component protocol - XEP-0114 which also uses separate namespaces (2!!) for sending stanzas. Even though XEP-0225 seems to be re-using jabber:client namespace, which in my opinion is move in a good direction, it needs some corrections too. As I mentioned, it doesn't have a separate namespace for the handshaking packets, hence causing conflicts if you want to put c2s connection manager behind the XEP-0225 component. Artur
Re: [Standards] component connections
I notice that Tigase 5.0 Beta has support for XEP-0225. Is anyone interested in finishing that XEP and pushing it forward? I am interested :-) As I have already implemented it and it is in use I have a few comments and a few changes to propose. I did not have enough time yet to describe it but I will try to send a message tomorrow with my suggestions and concerns about the XEP. Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
Re: [Standards] XEP-0225: Component Connections
Hi Peter, XEP-0225 will soon be automatically deferred because it has not been updated in ~12 months. Can anyone report on implementation experience or provide suggestions for improvement? Also, would anyone like to take over maintainership of this spec? (I just created my list of priorities for Q4 and this spec didn't make the cut, though I'm happy to help work on it if we receive feedback.) I am working on the implementation right now so I soon can have some comments and possibly suggestions for improvements. Give me a few more days please. Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
Re: [Standards] XSF Server Test Suite
This is the direction things are heading. The syntax is just something that we came up with at the last summit but I've exptended it. Perhaps is over complicated for the task. Perhaps these test scripts should be written in XML in order to avoid specialized parsers. Are there any decent C-syntax-style parsers out there already? In any case, I'd like to hear how people think this should be done. It is not a major issue but something to keep in mind designing the test suite. From my experience from working on the test suite for XMPP the most difficult part is to test cases when there are 2 or more user connections needed at the same time. As an example let's take presence subscription. You would like to test it for a different response from the other user - subscription approved, rejected. What about the case when the second user is offline at the time of the request sending and so on These are the cases which require a bit more complex logic/engine than just simple send some packet, receive response and compare it with pattern. Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
Re: [Standards] Idle sreams in RFCbis
Hi, I would like to provide feedback on these two sections: 5.7.3. Handling of Idle Streams http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-09.html#streams-close-idle 12.7. Whitespace http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-09.html#xml-whitespace In 5.7.3, it says: The typical method for detecting an idle TCP connection is to send a space character (U+0020) over the TCP connection between XML stanzas, which is allowed for XML streams as described under Section 12.7 (Whitespace). Strictly speaking: - the sending entity does not detect the loss of connection when it sends whitespaces I think you are not right here. From my experience the sending entity only can detect connection loss not the receiving. This is because sometimes TCP/IP doesn't get notified of simple connection loss if there is no data transmission over the link. Only when you attempt to send some data, even a single character, the TCP/IP stack tries to deliver it to the destination address. Of course if the connection is broken, the attempt fails and an error is returned to sending application. Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
Re: [Standards] interop testing effort
Hi, I wasn't part of the discussion so please let me add something to it before the meeting. It might be worth looking at. As you may know I work on the Tigase server and also on Tigase Test Suite. While the test suite might not be suitable and convenient to use by everybody there are parts which could be easily reused by any other project in any language. http://projects.tigase.org/testsuite/trac/browser/trunk/tests/data a simple example: http://projects.tigase.org/testsuite/trac/browser/trunk/tests/data/PubsubGetVersion.cot These are just simple text files describing what has to be sent to the server and what is expected as a response. The TTS is written in Java and part of the TTS code is a loader for these .cot files. Of course my .cot files have some limitations but this format could be a good starting point and this way everybody could easily contribute writing new test cases. What is left to do is the loader and runner for these files which could be written in any language. Artur On 18 May 2009, at 23:30, Peter Saint-Andre wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathan Fritz has been pushing for a kick-ass interoperability testing effort, kind of a real-time analogue to http://validator.w3.org/ but for XMPP. See this post and follow-ups: http://mail.jabber.org/pipermail/members/2009-May/005084.html We will hold a meeting about this on Thursday, May 21 at 18:00 UTC in the xmpp:foundat...@conference.jabber.org room. See you then! Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoR4W4ACgkQNL8k5A2w/vxvMgCgtrzmFN5o8eYPix73ZNMPdRwJ O6QAoJ7evWtWvOGlMc697Up20C+D1Nkq =NMoX -END PGP SIGNATURE- Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
Re: [Standards] interop testing effort
Hi, These are just simple text files describing what has to be sent to the server and what is expected as a response. The TTS is written in Java and part of the TTS code is a loader for these .cot files. Do you parse those text strings and compare the resulting XML elements? Otherwise, this will be pretty limited to one server, as it will even fail if you use instead of ' or vice versa. It's still standard-compliant then, but different. Maybe it's my fault as I said these are just simple text files. In some way they are but they contain XML stanza to send and receive and the stanza contain also variables which can be replaced based on some configuration settings. What exactly happens with these files is just matter of implementation and I didn't want to talk about implementation. But in case of Tigase Test Suite, yes they are loaded and parsed as XML elements. So the comparison is done between 2 XML elements not between 2 strings of characters. Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
Re: [Standards] XEP-50: Ad hoc command protocol is stateful
Hi, On 12 Dec 2008, at 10:06, Remko Tronçon wrote: I was implementing XEP-50 and was dumbfounded to find the protocol is stateful. Can't you make it stateless by passing your state in non-final command responses through hidden fields? This is exactly what I do in the Tigase server for different ad-hoc commands, setting configuration, retrieving statistics and so on. It works very well, at least it works well with Psi client. I think Coccinella improved support for ad-hoc commands recently too. Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/ Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
Re: [Standards] well-formedness
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, 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 XML stream either. I would rather call my parser: XMPP parser then. And please note. All these increased resource usage would be only needed because _sometimes_ it _may_ happen that maybe 1/1mln packet might have incorrect XMLNS.. I am not sure if this is worth the cost. What is the cost? Has anyone actually tried determining the actual cost? I just don't think the cost of simply validating namespaces is significant, and it certainly is not prohibitive. This cost might be ignored on the client side but on the server side everything counts. Imagine you have to parse XMPP packets on 150k active connections. The traffic during my load tests was 10k packets/sec. Every instruction you add to the data processing is multiplied by the number of packets. Of course if the XMLNS validation would be 1% of all operations performed by the parser it could be probably ignored. I think, however that XMLNS validation could require even more processing than all other parser tasks. Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
Re: [Standards] well-formedness
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 installations will become more and more expensive. 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. Don't even mention the CPU usage to perform all the validation. 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. And please note. All these increased resource usage would be only needed because _sometimes_ it _may_ happen that maybe 1/1mln packet might have incorrect XMLNS.. I am not sure if this is worth the cost. I am not speaking just about XMLNS validation here. I would like you to keep it in mind on any occasion you want to push even more processing to the server. And this is not just for my own comfort to have less development work to do. It seems to me that fast and low resources consuming servers are good for us all. I don't mean I don't want to add more stuff to the server and put more processing on the server at all cost. I like software development and I am always happy to implement something new. Even if this is just iq:iq... Sometimes however it is better to do more on the client side if possible. Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
Re: [Standards] invisibility
Hi, While reviewing XEP-0186 just now, I noticed that when a resource goes invisible, its server must send presence of type unavailable from that resource. As far as I can see, when a contact's server receives unavailable presence from the user (and if the user+contact have a two-way presence subscription), it will stop sending presence updates to the user (if that was the last online resource for the user). This somewhat defeats the purpose of invisibility, no? The implication is that the user's information about the presence of its contacts will soon become stale. But I suppose that's one price you pay for invisibility, which I continue to think is a stupid concept anyway. :) I thought we gave up with invisibility anyway. Especially that this can be quite easily achieved with privacy lists without those unwanted side effects. And privacy lists give us much more flexibility to set invisibility for a single user, group. Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
Re: [Standards] invisibility
Especially that this can be quite easily achieved with privacy lists I thought we did the contrary: introduce an invisibility extension because: a) Implementing this in a client using privacy lists is quite some work, is not atomic, has nasty corner cases that are hard to solve, and is even harder to implement if you take into account existing privacy lists, and b) Would avoid servers having to implement privacy lists (which is no longer in rfc3920) just to provide invisibility. Working alone on such a big project I must admit I am not following all discussions careful enough and I am quite often loosing track of changes in RFCs and XEPs. This is why I was not aware of the conclusion of that discussion. I will try to dig the subject in the list archives to not bring the it back again. Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)
On 3 Sep 2008, at 15:13, Peter Saint-Andre wrote: Pedro Melo wrote: On Sep 3, 2008, at 5:47 AM, Peter Saint-Andre wrote: Justin Karneges wrote: Dragging this over from jdev: Hmm. XMPP is not optimized for sending around 100k+ messages. Would 64KB chunks a reasonable thing to do? That's probably still too high. There is currently no specified maximum size for XMPP stanzas, but individual implementations may enforce different values. The original jabberd 1.0 server had around a 10KB maximum. The general consensus is that stanzas should be small, and this is largely in part because large stanzas block transmission of other stanzas (you cannot send many stanzas in parallel over one stream). Right now it's fuzzy as to how small you should chunk your data for maximum compatibility. I think we should define the largest stanza size that must be supported by clients and servers. We could just make this value 1 bytes, from the opening '' to the final '' of the stanza. The text should go into RFC 3920bis as a SHOULD. This way, stanzas 1 bytes or smaller are guaranteed to succeed in transmission. Stanzas larger than 1 bytes would still be transmittable, but without any guarantees that the other side will accept it (which is not any worse than the situation today). A question: which stanza error are we supposed to use to reject a stanza that is too large? Such an error would be very useful to determine the MTU. http://www.xmpp.org/extensions/inbox/stanzalimits.html Why not make section 3 a stream feature instead? Like: stream:features limits xmlns='urn:xmpp:tmp:stanza-limits' size65355/size rate10/rate /limits /stream:features This would signal the client that the max stanza size is 65355 bytes, and the max allowed rate of stanzas per second is 10. I like that. /psa +1 I like this too. The server can inform a client ahead of time what traffic limits are going to be enforced. Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
Re: [Standards] NEW: XEP-0245 (The /me Command)
Atulesh, Your posts to this list are off-topic. They are in fact spam here. This is STANDARDS discussion list, please stop posting your messages here. If you really don't want to contact Ignitesoftware (Jive Software) directly please, at least use Jabber development list for your posts. Artur On 19 Jun 2008, at 06:24, Atulesh MORE wrote: Hey friends, I have use xiff flash api, and i just want to know about the way to understand flow in openfire server code when flash chat api request to openfire, Thanks From Atulesh On Thu, Jun 19, 2008 at 3:18 AM, XMPP Extensions Editor [EMAIL PROTECTED] wrote: Version 0.1 of XEP-0245 (The /me Command) has been released. Abstract: This specification defines recommended handling of the /me command in XMPP instant messaging clients. Changelog: Initial published version. (psa) Diff: N/A URL: http://www.xmpp.org/extensions/xep-0245.html Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
Re: [Standards] NEW: XEP-0245 (The /me Command)
Atulesh, I am sorry I was going to put the link in my previous email. Here is a list of all Jabber mailing lists: http://www.jabber.org/discussion-lists Artur On 19 Jun 2008, at 07:40, Atulesh MORE wrote: I m sorry Mr Artur, But can u please suggest me the Jabber forum. On Thu, Jun 19, 2008 at 12:07 PM, Artur Hefczyc [EMAIL PROTECTED] wrote: Atulesh, Your posts to this list are off-topic. They are in fact spam here. This is STANDARDS discussion list, please stop posting your messages here. If you really don't want to contact Ignitesoftware (Jive Software) directly please, at least use Jabber development list for your posts. Artur On 19 Jun 2008, at 06:24, Atulesh MORE wrote: Hey friends, I have use xiff flash api, and i just want to know about the way to understand flow in openfire server code when flash chat api request to openfire, Thanks From Atulesh On Thu, Jun 19, 2008 at 3:18 AM, XMPP Extensions Editor [EMAIL PROTECTED] wrote: Version 0.1 of XEP-0245 (The /me Command) has been released. Abstract: This specification defines recommended handling of the / me command in XMPP instant messaging clients. Changelog: Initial published version. (psa) Diff: N/A URL: http://www.xmpp.org/extensions/xep-0245.html Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/ Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
Re: [Standards] Proposed XMPP Extension: IO DATA
On 4 Apr 2008, at 12:05, Richard Smith wrote: Johannes Wagener wrote: Proposed XMPP Extension: IO DATA snip I second this proposal. I've read this XEP and I love it. This is exactly what I needed when I was working on the server configuration via XMPP. I decided to use ad-hoc commands because that was the best available way to do it. But I really struggled with conversion data between string and other types. Using this XEP would be much, much more efficient and easier to implement as I could just skip all types conversion stuff and detecting/ remembering what type apply to which configuration parameter. I second this XEP as an official XMPP XEP :-) Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
