Re: [Standards] XEP-0174: Serverless Messaging interactions with XEP-0115 Entity Capabilities
Peter Saint-Andre wrote: Alban Crequy wrote: I implemented an automatic caps lookup via disco in telepathy-salut (the XEP-0174 implementation in the Telepathy framework). It opens a stream only if a ver TXT record is advertised *and* if the ver record is not already known. Right, I see the need for that. But it's unfortunate. Still thinking... Maybe it is a bad idea, maybe not. We could provide a query TCP feature. So if you do not know the client, you open a connection and get the follwoing features: starttls (for real communication) and query to get the disco#query results and close the stream after that. Or we use a second port just for the query. Connect to that port and you get a stream with just the query results and the socket is closed again. I now, it is not a good solution, but I have the same problem as Alban. I need to know what the remote entity can do. Dirk -- I'm going to live forever, or die trying! -- Spider Robinson
Re: [Standards] XEP-0174: Serverless Messaging interactions with XEP-0115 Entity Capabilities
Dirk Meyer wrote: Peter Saint-Andre wrote: Alban Crequy wrote: I implemented an automatic caps lookup via disco in telepathy-salut (the XEP-0174 implementation in the Telepathy framework). It opens a stream only if a ver TXT record is advertised *and* if the ver record is not already known. Right, I see the need for that. But it's unfortunate. Still thinking... Maybe it is a bad idea, maybe not. We could provide a query TCP feature. So if you do not know the client, you open a connection and get the follwoing features: starttls (for real communication) and query to get the disco#query results and close the stream after that. Or in serverless mode you could automatically return the disco#info in the response, like so: stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' from='[EMAIL PROTECTED]' to='[EMAIL PROTECTED]' version='1.0' stream:features starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/ query xmlns='http://jabber.org/protocol/disco#info' node='some-node-here' identity category='client' type='pc'/ feature var='http://jabber.org/protocol/disco#info'/ feature var='http://jabber.org/protocol/disco#items'/ feature var='http://jabber.org/protocol/muc'/ /query /stream:features But that doesn't solve the problem of prompting the user when someone wants to open a stream (however, the interface could prompt the user only if the contact goes beyond the disco stage). Or we use a second port just for the query. Connect to that port and you get a stream with just the query results and the socket is closed again. I like that less well, but I'm not sure why. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] well-formedness
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 continue to support their legacy counterparts. The benefit of course would be that eventually we will have a sterilized network, where clients wouldn't need to worry about rolling out their own (non-conforming) namespace handling. In my opinion this is a better long term direction. I too think that is a worthy goal. The question is: how can we get there in a reasonable fashion? Why not limit the scope of XML-NAMES ? I think xml like this should be prohibited by the xmpp spec. snip/ Er yes, that *is* ugly. :) /psa
Re: [Standards] well-formedness
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 not going to be left behind. Newer servers and server versions are still going to continue to support their legacy counterparts. The benefit of course would be that eventually we will have a sterilized network, where clients wouldn't need to worry about rolling out their own (non-conforming) namespace handling. In my opinion this is a better long term direction. I too think that is a worthy goal. The question is: how can we get there in a reasonable fashion? Why not limit the scope of XML-NAMES ? I think xml like this should be prohibited by the xmpp spec. snip/ Er yes, that *is* ugly. :) An XMPP entity MAY choose to use prefixes as described in [XML-NAMES], on the condition that it does not generate XML which may be considered UGLY to a receiving XMPP entity. Moving forward, I'd also be in favour of specifying that RFC-compliant implementations MUST NOT send XML deemed invalid per XML-NAMES. Matthew.
Re: [Standards] well-formedness
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=detailaid=695401group_id=10127atid=110127 which references this section of XML Names: http://www.w3.org/TR/REC-xml-names/#ns-qualnames Which doesn't say anything about mandatory fatal errors. If you're parsing a static document, it's quite reasonable to generate a fatal error, but I don't think that's the right thing at all with an XML stream. Ah yes, a namespace aware parser (expat) is indeed being used with namespace awareness disabled... Right - and then namespaces are handled, so the overall result is that a namespace aware parser is used. If you're mandating that all XMPP implementations MUST use somebody else's parser, then I don't know quite what to say. I looked at the Gajim sources, and using 'http://www.gajim.org/xmlns/undeclared-root' as the namespace of all undeclared prefixes clearly does not conform with [XML-NAMES]. See: http://www.w3.org/TR/REC-xml-names/#ProcessorConformance Nonsense. A processor MUST report violations of namespace well-formedness - Gajim is doing so, signalling this condition using a specific namespace URI, so it clearly *does* conform. You may argue that I should have used some special non-string object instead, if you like, and that how Gajim handles this signal - by treating it as the unknown namespace it (kind of) is - is sufficiently simple and neat as to warrant being maligned as a hack, but it's a damn sight better than terminating the connection. Gajim does not conform to XML-NAMES. I reviewed the code, and it appears to act correctly for most XML. But it does not act correctly for prefixes on attributes Not that it did when expat was used to handle the namespaces, either. Making it handle these properly would involve quite a bit more rewriting. (Possible and desirable rewriting, to be sure, but nothing to do with the issue at hand, sorry). . And it does not have a single one of all those required checks for non-conforming XML (except the undeclared prefix check on tag names). XML-NAMES requires a number of checks for conformance, some of which are in http://www.w3.org/TR/REC-xml-names/#Conformance while others are sprinkled throughout the spec. I'll accept that - I didn't make it check for multiple colons, etc, and I might well allow a redefinition of xml: and xmlns:, which'd be confusing. I ought to fix these at some point. Incidentally, by stating except the undeclared prefix check, aren't you arguing that the code *is* following XML-NAMES in this regard? Dave, I don't think you want to conform to XML-NAMES. I think you'd prefer to sanitize the XML instead to make it conform to XML-NAMES. One step closer to HTML ;) The mechanism by which I happen to have chosen to report undeclared namespaces is merely a convenient mechanism which happens to have result I desired with minimal programming. I happen to think the code is less hacky than Expat's rather bizarre API, which has namespace handling hacked on via character delimiters, especially given how Gajim then used this API. (Either Expat looks up namespaces and then leaves you a non-standard notation to parse, or else you parse the standard notation and lookup namespaces yourself, in a more resilient manner - not a hard choice, really). What I'm trying to do is look at where we are now, and describe the best option for developers wishing to deploy now, especially bearing in mind we need to obtain the best result, where best is in terms of interoperability and potential efficiency. If you disagree with those goals, please say so - I don't think your goals are all that different. You appear to be arguing that the best interoperability (presumably) is achieved by producing only XML-NAMES conforming XML. I can agree with you there. I also think this doesn't always happen right now, and that therefore clients are best advised to handle Bad XMLNS in a graceful manner, in particular, not generated a fatal stream-level error. Furthermore, I note that if clients do this, the requirement to produce only Good XMLNS can be relaxed slightly, since no serious damage results. That is, avoid if possible - bad things may result, rather than avoid at all costs - bad things will result. SHOULD instaed of MUST in RFC 2119 terms. Finally, I note that the costs can be, in fact, remarkably high for a server in the case of forwarding stanzas, since in order to merely forward stanzas, a simple lexing pass is sufficient, whereas to check - in particular - for undeclared prefixes requires a full parse and lookup. These are expensive operations involving allocations, string compares, and other primitives that have a detrimental effect on short-term and long-term
Re: [Standards] XEP-0174: Serverless Messaging interactions with XEP-0115 Entity Capabilities
Le Tue, 21 Oct 2008 10:28:36 -0600, Peter Saint-Andre [EMAIL PROTECTED] a écrit : Justin Karneges wrote: On Monday 20 October 2008 11:42:39 Peter Saint-Andre wrote: Alban Crequy wrote: I need to know all the contact capabilities in Telepathy, even if there is no open stream. If an application want to display a contact chooser to start a VNC session, a game, or whatever on top of XMPP, I need to know which contacts are able to do VNC or a specific game. I implemented an automatic caps lookup via disco in telepathy-salut (the XEP-0174 implementation in the Telepathy framework). It opens a stream only if a ver TXT record is advertised *and* if the ver record is not already known. Right, I see the need for that. But it's unfortunate. Still thinking... One idea might be to use DNS-SD to share the disco information. Publish PTR records like _http://jabber.org/protocol/si/profile/filetransfer._xmpp.local. Maybe that would get out of hand, or not? Yes, I think that would get out of hand, but I think we'd need to profile this in real life (i.e., how many records / disco features are we talking about, how frequently would people ping contacts via serverless messaging just to get the disco#info results, etc.). Telepathy-salut will expose the usual feature records in a Jabber client, and a feature record per Telepathy tube type (it may be VNC, a Tetris game, a Go game, a DAAP music player, etc.). It will not change the advertised caps often but when a new software using Telepathy tube is installed or started. It has a cache, so it will not ask twice for the same caps hash. But every contact may have different caps hash because the caps set depends not only on the version of Telepathy Salut but also on whether other software using tubes are installed. It will ask for contacts' caps when going online and when the contacts' advertised hashs change, even if there is no contact chooser window displayed at this moment. -- Alban
Re: [Standards] XEP-0174: Serverless Messaging interactions with XEP-0115 Entity Capabilities
Le Tue, 21 Oct 2008 07:46:00 -0600, Peter Saint-Andre [EMAIL PROTECTED] a écrit : Dirk Meyer wrote: Peter Saint-Andre wrote: Alban Crequy wrote: I implemented an automatic caps lookup via disco in telepathy-salut (the XEP-0174 implementation in the Telepathy framework). It opens a stream only if a ver TXT record is advertised *and* if the ver record is not already known. Right, I see the need for that. But it's unfortunate. Still thinking... Maybe it is a bad idea, maybe not. We could provide a query TCP feature. So if you do not know the client, you open a connection and get the follwoing features: starttls (for real communication) and query to get the disco#query results and close the stream after that. Or in serverless mode you could automatically return the disco#info in the response, like so: stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' from='[EMAIL PROTECTED]' to='[EMAIL PROTECTED]' version='1.0' stream:features starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/ query xmlns='http://jabber.org/protocol/disco#info' node='some-node-here' identity category='client' type='pc'/ feature var='http://jabber.org/protocol/disco#info'/ feature var='http://jabber.org/protocol/disco#items'/ feature var='http://jabber.org/protocol/muc'/ /query /stream:features But that doesn't solve the problem of prompting the user when someone wants to open a stream (however, the interface could prompt the user only if the contact goes beyond the disco stage). Does any software prompt the user when a stream is opened at the moment? I don't see the need for that. I think it is bad to say there is a discussion if the TCP connection is opened. Instead we can use XEP-0085: Chat State Notifications for that. Or we use a second port just for the query. Connect to that port and you get a stream with just the query results and the socket is closed again. I like that less well, but I'm not sure why. I think it is better to keep the main protocol with a Jabber server and the XEP-0174 serverless protocol similar. If we start to use a different port for capability requests, why not do the same for Jingle calls, and any other extension which uses iq stanza? -- Alban
Re: [Standards] XEP-0174: Serverless Messaging interactions with XEP-0115 Entity Capabilities
Alban Crequy wrote: Le Tue, 21 Oct 2008 07:46:00 -0600, Peter Saint-Andre [EMAIL PROTECTED] a écrit : Dirk Meyer wrote: Peter Saint-Andre wrote: Alban Crequy wrote: I implemented an automatic caps lookup via disco in telepathy-salut (the XEP-0174 implementation in the Telepathy framework). It opens a stream only if a ver TXT record is advertised *and* if the ver record is not already known. Right, I see the need for that. But it's unfortunate. Still thinking... Maybe it is a bad idea, maybe not. We could provide a query TCP feature. So if you do not know the client, you open a connection and get the follwoing features: starttls (for real communication) and query to get the disco#query results and close the stream after that. Or in serverless mode you could automatically return the disco#info in the response, like so: stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' from='[EMAIL PROTECTED]' to='[EMAIL PROTECTED]' version='1.0' stream:features starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/ query xmlns='http://jabber.org/protocol/disco#info' node='some-node-here' identity category='client' type='pc'/ feature var='http://jabber.org/protocol/disco#info'/ feature var='http://jabber.org/protocol/disco#items'/ feature var='http://jabber.org/protocol/muc'/ /query /stream:features But that doesn't solve the problem of prompting the user when someone wants to open a stream (however, the interface could prompt the user only if the contact goes beyond the disco stage). Does any software prompt the user when a stream is opened at the moment? I don't see the need for that. I think it is bad to say there is a discussion if the TCP connection is opened. Instead we can use XEP-0085: Chat State Notifications for that. I don't know if there is. If not, then we don't have anything to worry about. I know that iChat doesn't do that. Or we use a second port just for the query. Connect to that port and you get a stream with just the query results and the socket is closed again. I like that less well, but I'm not sure why. I think it is better to keep the main protocol with a Jabber server and the XEP-0174 serverless protocol similar. If we start to use a different port for capability requests, why not do the same for Jingle calls, and any other extension which uses iq stanza? Ick, yeah. So let's avoid that. :) Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Call for Experience: XEP-0085 (Chat StateNotifications)
Hello, I fear something is not really clear enough in the XEP-85: User has effectively ended their participation in the chat session. User has not interacted with the chat interface, system, or device for a relatively long period of time (e.g., 2 minutes), or has terminated the chat interface (e.g., by closing the chat window). But I have the following setting dialogs in miranda ([.]=check box): (It's designed for other protocols like ICQ too) === options page A: (in the general option page) Become idle if the following is left unattended: [.]Windows [.]Miranda for [...] minute(s) [.] Do not let protocols report any idle information -- options page B: (in the jabber options) in the jabber option page: [.] Send chatstate changes if chat window closed === Option page 2 is clear, user close the chat window, jabber plugin send /gone But the orange part? What should miranda send when I setup in this dialog for e.g. 30 minutes? (And if the chat window is still open!) If miranda should send /inactive not /gone the orange part should removed from the XEP, this 2 minutes example AND if the windows closed is a little bit confusing. Peter (Today was a feature request in the miranda bugtracker, and I became confused about it, therefore this posting. ;) ) -- Lastwebpage Lastwebpage's Profile: http://www.jabberforum.org/member.php?userid=41 View this thread: http://www.jabberforum.org/showthread.php?t=925
Re: [Standards] Call for Experience: XEP-0085 (Chat StateNotifications)
Lastwebpage [EMAIL PROTECTED] wrote: Hello, I fear something is not really clear enough in the XEP-85: User has effectively ended their participation in the chat session. User has not interacted with the chat interface, system, or device for a relatively long period of time (e.g., 2 minutes), or has terminated the chat interface (e.g., by closing the chat window). But I have the following setting dialogs in miranda ([.]=check box): (It's designed for other protocols like ICQ too) === options page A: (in the general option page) Become idle if the following is left unattended: [.]Windows [.]Miranda for [...] minute(s) [.] Do not let protocols report any idle information -- options page B: (in the jabber options) in the jabber option page: [.] Send chatstate changes if chat window closed === Option page 2 is clear, user close the chat window, jabber plugin send /gone But the orange part? What should miranda send when I setup in this dialog for e.g. 30 minutes? (And if the chat window is still open!) If miranda should send /inactive not /gone the orange part should removed from the XEP, this 2 minutes example AND if the windows closed is a little bit confusing. Peter (Today was a feature request in the miranda bugtracker, and I became confused about it, therefore this posting. ;) ) Idle has nothing to do with XEP-0085 - it should just change its status then, it can leave active as your tab might still be open and the active tab. -- Jonathan signature.asc Description: PGP signature
