Re: [Standards] XEP-0115 v. 1.5pre14
On Jan 15, 2008 3:33 AM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > I have updated the provisional version of XEP-0115 per recent list > discussion. I have only a minor word-smithing niggle: The collision and preimage section is a bit unclear - for the first halfread I though the terms were reversed (it's not vulnerable to collision, but might be to preimage sounds peculiar because collision is semi-possible, while preimage isn't), but I think I've understood now. Perhaps it could say something like 'not vulnerable to semi-possible* existing collision techniques, but could be possible to pre-image attacks if such are developed in the future." (*I forget the term). It might help thickies like me reading the spec. The 'pre-image would need' section says that it would have to remove a feature, but adding a feature could be equally DoS (say you supported xhtml-im and so the client stopped sending a as a poor example). I'm much happier with the text now though, thanks Peter. /K
[Standards] XEP-0115 v. 1.5pre14
I have updated the provisional version of XEP-0115 per recent list discussion. Rendered text: http://www.xmpp.org/extensions/tmp/xep-0115-1.5.html SVN diff from 1.5pre13: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0115.xml?r1=1572&r2=1579 SVN diff from 1.4: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0115.xml?r1=1145&r2=1579 Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] IQ set semantics
Tomasz Sterna wrote: Hi. I was looking for an information whether the IQ-set sent on ones behalf (to change its own settings) may or may not have the "to" attribute and how should it be processed by the server. We had some discussion about this a while back, and I tried to incorporate the results into the bis drafts. But maybe I didn't do a good job. :) http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-04.html#stanzas-attributes-to-c2s "2. A stanza sent from a client to a server for direct processing by the server (e.g., presence sent to the server for broadcasting to other entities) SHOULD NOT possess a 'to' attribute." It says that it SHOULD NOT posses a 'to' attribute. I think that one should be MUST NOT. Otherwise, how will the server know the presence is intended for broadcasting? But what to do if it does? Let's search further... http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-04.html#rules-local-node "3. If the JID is of the form <[EMAIL PROTECTED]> and there exists at least one connected resource for the node, the recipient's server SHOULD deliver the stanza to at least one of the connected resources if the stanza is a message or presence stanza and SHOULD handle it directly on behalf of the node if the stanza is an IQ stanza." OK. This says that the server should process the IQ on behalf of the "to" entity instead of forwarding to the client for processing. But I still am not sure what to do if the "to" is client's own bare JID. The real life case is XEP-0054: "A user may update his or her vCard by sending an IQ of type "set" to the server, following the format in the previous use case. If a user attempts to perform an IQ set on another user's vCard, the server MUST return a 403 "Forbidden" error." The "previous use case" does not contain a "to" attribute, so jabberd2 implementation checks whether it is not set. If it is - returns forbidden-error. The phrase "send an IQ-set to the server" is ambiguous. It could mean: 1. send an IQ-set over the stream you have established with your server but don't include a 'to' attribute" or 2. send an IQ-set with to='yourserver.tld' I think here (1) is intended but I can clean that up. Logic says that for IQs if "to" attribute is set to ones bare JID it should be handled like "to" was not set. But I cannot find a rule that says so in our protocol documentation. I agree that we need to explicitly state that rule. I'll work it into the stanza handling rules. "In the face of ambiguity, refuse the temptation to guess." - PEP-0020 Good advice. :) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0115 redux
Kevin Smith wrote: On Jan 14, 2008 4:33 PM, Joe Hildebrand <[EMAIL PROTECTED]> wrote: I'm not sure about the i18n section, it seems better to me to leave the name in. It reads fine to me. If you wanted, we might spell out the disco#info request to get the name, and specify that it MUST be cached on a per- node basis. Yes, we can always cache it that way to get the friendly name, good thinking Batman. How is this text as a new subsection under Implementation Notes? ** 8.5 Friendly Name The 'name' attribute of the service discovery element enables a responding application to specify the "friendly name" for its node. However, this attribute is excluded from the hash generation method, primarily because it is human-readable text and therefore may be provided in different localized versions. As a result, its inclusion would needlessly multiply the number of possible hash values and thus the time and resources required to validate values of the 'ver' attribute. However, a receiving application MAY send a service discovery information request to a particularly JID+node combination in order to determine the friendly name, then cache the result for that JID+node only. ** I have moved this from the Internationalization Considerations (and have deleted that section) since this seems to be only tangentially related to i18n. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] ProtoXEP: Game Support
Torsten Grote wrote: Michal 'vorner' Vaner said the following on 01/12/2008 11:13 AM: Discovering: Wouldn't it make sense use service disco to get supported/ongoing games too? (add items supported-games and ongoing-games to item list, and their sub-lists as games, for example) It seems to me defining new protocol for discovering is not needed, if there is a generic one. I used a separate mechanism for discovering individual games because there may be hundreds of games a client supports and this would blow up a disco response considerably. If you really expect a client to support hundreds of games (!), I think it would be best to offer each game as an item at a special disco node. Then another user can page through the items and see if one matches, use XEP-0059 to page through the items, etc. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] UPDATED: XEP-0155 (Stanza Session Negotiation)
Version 1.2 of XEP-0155 (Stanza Session Negotiation) has been released. Abstract: This specification defines a method for formally negotiating the exchange of XML stanzas between two XMPP entities. The method uses feature negotiation forms sent via XMPP message stanzas to enable session initiation between entities that do not share presence information or have knowledge of full JabberIDs and therefore is also suitable for use across gateways to SIP-based systems. A wide range of session parameters can be negotiated, including the use of end-to-end encryption, chat state notifications, XHTML-IM formatting, and message archiving. Changelog: Specified that IM message bodies must not be included; added boolean multisession field to explicitly determine whether multiple concurrent sessions are allowed between the full JIDs of the parties. (psa) Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0155.xml?r1=662&r2=1574 URL: http://www.xmpp.org/extensions/xep-0155.html
[Standards] UPDATED: XEP-0045 (Multi-User Chat)
Version 1.23 of XEP-0045 (Multi-User Chat) has been released. Abstract: This specification defines an XMPP protocol extension for multi-user text chat, whereby multiple XMPP users can exchange messages in the context of a room or channel, similar to Internet Relay Chat (IRC). In addition to standard chatroom features such as room topics and invitations, the protocol defines a strong room control model, including the ability to kick and ban users, to name room moderators and administrators, to require membership or passwords in order to join the room, etc. Changelog: [See revision history] (psa) Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0045.xml?r1=741&r2=1573 URL: http://www.xmpp.org/extensions/xep-0045.html
Re: [Standards] XEP-0115 redux
Dave Cridland wrote:
ISSUE #3: Which hashing algorithms?
Description: The Council discussion seemed to assume that version 1.5
[4] says SHA-1 is mandatory-to-implement ("MTI"). In fact, version 1.5
does not mandate implementation of any specific algorithm. Be that as
it may, some Council members suggested that we recommend MD5 instead
of SHA-1 (the only concrete reason I heard in the meeting is that MD5
output is smaller).
(Kind of. One issue is that MD5 might actually be more secure.)
Far be it from me to weigh in on such issues, because I am not a
cryptographer by any means. However, I have read some of the papers
referred to from RFC 4270 and some of the URLs you posted. It seems to
me that both MD5 and the SHA family use the Damgard-Merkle construction
(the "standard" way of making iterated hash functions). So are both MD5
and SHA-1 subject to some of the same vulnerabilities? Are there (again,
potential) vulnerabilities that SHA-1 is subject to but MD5 is not? For
example, Kelsey and Schneier 2004 suggests a line of reasoning whereby
SHA-1 could more easily subject to a preimage attack than previously
thought when large messages are used (for us that would equate to a
large value of "S" in XEP-0115), but the input messages are on the order
of 2^55 blocks long *and* they don't need to match any kind of defined
structure (as message would to be used in a preimage attack against
entity capabilities).
I will try to expand upon the text describing the (potential) preimage
attack so that we define it more clearly.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [Standards] ProtoXEP: Game Support
Torsten Grote wrote: Do you have any opinion on the disco for individual games? How many games do you expect clients to support? I see basically three ways to do it: 1. include games in normal disco as feature That seems OK. The nice thing is that if a user installs the checkers plugin (or whatever), it can send an entity capabilities update. 2. use info/item nodes in normal disco That might be appropriate. It depends on what we think a game is (is it a feature or an item?). 3. some "own" third way, as we did -1 Number 1 could blow up the disco response considerably, while Number 2 and 3 allow for a separate query for games. Unfortunately, I can't come up with a nice way to do Number 2. Using disco#info or disco#items is preferable. Our current solution is very similar to a disco#items query (e.g. MUC room query). Are there any good reasons not to do it that way? Yes, it's non-standard and other clients won't be able to play along. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] ProtoXEP: Game Support
Torsten Grote wrote: In my opinion this is one big hindrance for a large-scale adoption of Jabber. We estimate that there are 50+ million end users of Jabber technologies. But I guess that's not large-scale compared to MSN, eh? A fast growing pool of interoperable and fascinating games would drive many users to create and use Jabber accounts. Yes that might be fun. :) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Data Element
Michael Laukner wrote: Peter Saint-Andre wrote: Michael Laukner wrote: In case of XMPP: Juliet, I am at geo:47.123,9.3 and feeling kind of dizzy! FIXME,FIXME,FIXME Er, don't you really want this...? Juliet, I am at 47.8N,9.3E and feeling kind of dizzy! Juliet, I am at 47.8N,9.3E and feeling kind of dizzy! This message supports the consumer side. We can render the URI nicely as an image button and load the map application, but our end-nodes may also be producer. In this case we want to attach the geo-data directly (as gml, kml, geopriv) to a message, store them in the database on the server and send the URI to the MUC participants. Right. So you want something like this: Juliet, I am at 47.8N,9.3E and feeling kind of dizzy! Juliet, I am at 47.8N,9.3E and feeling kind of dizzy! Italy 47.8 Venice 9.3 (Or instead of using XEP-0080 format you can embed some Geography Markup Language XML or whatever you like for your application.) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0115 redux
On Jan 14, 2008 4:33 PM, Joe Hildebrand <[EMAIL PROTECTED]> wrote: > > I'm not sure about the i18n section, it seems better to me to leave > > the name in. > It reads fine to me. If you wanted, we might spell out the disco#info > request to get the name, and specify that it MUST be cached on a per- > node basis. Yes, we can always cache it that way to get the friendly name, good thinking Batman. /K
Re: [Standards] XEP-0115 redux
On Jan 14, 2008, at 8:14 AM, Kevin Smith wrote: A client MAY enable a human user to disable inclusion of the 'v' attribute, which specifies a version of the software. If the 'v' attribute is not included, the receiver SHOULD NOT automatically send Software Version requests to the sender, although it MAY allow Software Version requests to be sent at the request of the user. (the MUSTs on the version isn't really compatible with what's already out there, and we're aiming for backwards compat, I think) +1 I'm not sure about the i18n section, it seems better to me to leave the name in. It reads fine to me. If you wanted, we might spell out the disco#info request to get the name, and specify that it MUST be cached on a per- node basis. -- Joe Hildebrand
Re: [Standards] XEP-0115 redux
Kevin Smith wrote:
On Jan 11, 2008 11:29 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
Peter Saint-Andre wrote:
Based on the list discussion, I have updated the provisional version of
XEP-0115 (Entity Capabilities).
I think:
A client SHOULD enable a human user to disable inclusion of the 'v'
attribute, which specifies a version of the software. If the 'v'
attribute is not included, the receiver MUST assume that the version
is intended to be private, and MUST NOT automatically send Software
Version requests to the sender.
would be better as:
A client MAY enable a human user to disable inclusion of the 'v'
attribute, which specifies a version of the software. If the 'v'
attribute is not included, the receiver SHOULD NOT automatically send
Software Version requests to the sender, although it MAY allow
Software Version requests to be sent at the request of the user.
(the MUSTs on the version isn't really compatible with what's already
out there, and we're aiming for backwards compat, I think)
That fine with me.
I'm not sure about the i18n section, it seems better to me to leave the name in.
The text in the provisional Internationalization Considerations was
simply moved from the old Security Considerations (it seemed out of
place there).
By "leave the name in" do you mean changing the algorithm for generating
the message ("S") that's provided as input to the hashing function? That
would be a change from version 1.4 of the spec.
Right now "S" is constructed as follows (with special delimiters etc. as
described in the spec):
S = identities + features
Including the name(s) would mean changing the algorithm to:
S = identities + features + names
(or somesuch)
I don't see a compelling reason to change the algorithm. Indeed, adding
the name means that if, say, Psi and Gajim support the same features,
they would present different hashes since the name for one might be "The
Psi Client" and the name for the other might be "Gajim XMPP Client" or
whatever. IMHO that's not what we're trying to accomplish with caps.
Apart from these minor tweaks, I'm ok with this spec now.
Super!
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [Standards] ProtoXEP: Game Support
On Sat, 12 Jan 2008, Richard Dobson wrote:
Sure exactly, as I said you need some kind of neutral third party for a lot
of games, be that a server or a bot it doesnt matter, but you cant do as the
previous poster seemed to suggest (as far as I read it) and just use bog
standard MUC and RPC between the players for all games.
Just to be clear, I *did* mean that we have a referee bot in the MUC. (The
bot is the entity that sets up the MUC, in fact, although it currently
doesn't use any MUC administrator functions beyond that.)
I also want to address this bit from an earlier post:
Torsten Grote <[EMAIL PROTECTED]>:
In my opinion this is one big hindrance for a large-scale adoption of
Jabber. A fast growing pool of interoperable and fascinating games would
drive many users to create and use Jabber accounts.
What we've found is that there's no need to drive people towards Jabber
accounts -- you say "use your Livejournal or Google Chat address" and
everyone's there. Or you tell them to register on a web site (people do
that six times a day anyway) and then provision them a Jabber account.
("Plays games, plus you can chat with it!")
The sticky point is getting people to download software. We find, in this
day and age, that people won't play a game unless it runs in software they
already have. That's a big obstacle for Jabber gaming: you want that to
be a *fast-growing* pool of games, but nobody is going to download a new
client update every week because another game came out.
Our solution was to have a custom client which could download individual
game plugins itself. (In the form of Javascript code.) That worked great,
but then nobody downloaded the custom client in the first place.
The current plan is to grit our teeth and make it a web app. Yes, it's a
cliche, but people have web browsers and they expect everything to run in
them. We're still using Jabber on the back end, so they will still get
chat and federation with all the other Jabber users of the world.
We realize that "Jabber on the back end" doesn't do much for XMPP
advocacy, but it's better than nothing, and our primary goal is to get
people playing games. Whatever that takes.
The only flaw with the current plan is that it's a lot of work and it's
not done yet. :/
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
When Bush says "Stay the course," what he means is "I don't know what to
do next." He's been saying this for years now.
Re: [Standards] XEP-0115 redux
On Jan 11, 2008 11:29 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > Peter Saint-Andre wrote: > Based on the list discussion, I have updated the provisional version of > XEP-0115 (Entity Capabilities). I think: A client SHOULD enable a human user to disable inclusion of the 'v' attribute, which specifies a version of the software. If the 'v' attribute is not included, the receiver MUST assume that the version is intended to be private, and MUST NOT automatically send Software Version requests to the sender. would be better as: A client MAY enable a human user to disable inclusion of the 'v' attribute, which specifies a version of the software. If the 'v' attribute is not included, the receiver SHOULD NOT automatically send Software Version requests to the sender, although it MAY allow Software Version requests to be sent at the request of the user. (the MUSTs on the version isn't really compatible with what's already out there, and we're aiming for backwards compat, I think) I'm not sure about the i18n section, it seems better to me to leave the name in. Apart from these minor tweaks, I'm ok with this spec now. /K
Re: [Standards] ProtoXEP: Game Support
Do you have any opinion on the disco for individual games? I see basically three ways to do it: 1. include games in normal disco as feature 2. use info/item nodes in normal disco 3. some "own" third way, as we did Number 1 could blow up the disco response considerably, while Number 2 and 3 allow for a separate query for games. Unfortunately, I can't come up with a nice way to do Number 2. Our current solution is very similar to a disco#items query (e.g. MUC room query). Are there any good reasons not to do it that way? I would do it as option 2, where the main disco info would just have a feature of "http://jabber.org/protocol/games";, then if people want to retrieve a full list of the games you support they would do a disco#info query on the special node for games (http://jabber.org/protocol/games), e.g. id='req1' type='get'> node='http://jabber.org/protocol/games'/> id='req1' type='result'> node='http://jabber.org/protocol/games'> This allows easy use of disco without bloating the main response. Richard
Re: [Standards] ProtoXEP: Game Support
Richard Dobson said the following on 01/12/2008 08:40 PM: > Some notes to slightly enhance the protocol > ... > There is no need for the top level x element, that is only a historical > remnant that a few specs use, also regarding the invite it makes more > sense for the game element to be inside the invite rather than outside > it, I would also update all the other actions too so they dont use the x > element either. Thank you very much for your help! I adapted the ProtoXEP draft accordingly. > Also I would adjust the move action from: > ... > To be slightly more generic into a turn action that encapsulates the > move i.e.: > ... > Hope this helps. Good idea! :) I changed this also. Do you have any opinion on the disco for individual games? I see basically three ways to do it: 1. include games in normal disco as feature 2. use info/item nodes in normal disco 3. some "own" third way, as we did Number 1 could blow up the disco response considerably, while Number 2 and 3 allow for a separate query for games. Unfortunately, I can't come up with a nice way to do Number 2. Our current solution is very similar to a disco#items query (e.g. MUC room query). Are there any good reasons not to do it that way? > Richard Torsten
[Standards] IQ set semantics
Hi. I was looking for an information whether the IQ-set sent on ones behalf (to change its own settings) may or may not have the "to" attribute and how should it be processed by the server. http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-04.html#stanzas-attributes-to-c2s "2. A stanza sent from a client to a server for direct processing by the server (e.g., presence sent to the server for broadcasting to other entities) SHOULD NOT possess a 'to' attribute." It says that it SHOULD NOT posses a 'to' attribute. But what to do if it does? Let's search further... http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-04.html#rules-local-node "3. If the JID is of the form <[EMAIL PROTECTED]> and there exists at least one connected resource for the node, the recipient's server SHOULD deliver the stanza to at least one of the connected resources if the stanza is a message or presence stanza and SHOULD handle it directly on behalf of the node if the stanza is an IQ stanza." OK. This says that the server should process the IQ on behalf of the "to" entity instead of forwarding to the client for processing. But I still am not sure what to do if the "to" is client's own bare JID. The real life case is XEP-0054: "A user may update his or her vCard by sending an IQ of type "set" to the server, following the format in the previous use case. If a user attempts to perform an IQ set on another user's vCard, the server MUST return a 403 "Forbidden" error." The "previous use case" does not contain a "to" attribute, so jabberd2 implementation checks whether it is not set. If it is - returns forbidden-error. Logic says that for IQs if "to" attribute is set to ones bare JID it should be handled like "to" was not set. But I cannot find a rule that says so in our protocol documentation. "In the face of ambiguity, refuse the temptation to guess." - PEP-0020 -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
