[Standards] Fwd: Re: [Simple] SIMPLE chat: Internationalization and normalization of nicknames
FYI, there's discussion happening on the SIMPLE WG list about internationalization of nicknames in chatrooms. There might be value in pursuing a common approach. Please follow up on the sim...@ietf.org list: https://www.ietf.org/mailman/listinfo/simple Original Message Subject: Re: [Simple] SIMPLE chat: Internationalization and normalization of nicknames Date: Thu, 01 Mar 2012 15:26:00 -0700 From: Peter Saint-Andre stpe...@stpeter.im To: Ben Campbell b...@nostrum.com CC: Simple WG sim...@ietf.org On 3/1/12 3:12 PM, Ben Campbell wrote: On Mar 1, 2012, at 3:55 PM, Miguel A. Garcia wrote: Dear all: I am trying to address the last known issue of the SIMPLE chat draft. This came through Enrico Marocco's Appsdir review, and the comment was: The document doesn't describe allowed characters in Nicks and any normalization that needs to be applied. So, I got advice from Alexy Melnikov, indicating that we should take a look at the ResourcePrep in: http://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/ The idea is to inspire on the ResourcePrep and adapted to Nicknames in SIMPLE chat. However, there is a dependency on the completion of the Precis Framework: https://datatracker.ietf.org/doc/draft-ietf-precis-framework/ This means that SIMPLE chat will need to add a normative dependency to the Precis Framework, and if SIMPLE chat is approved and arrives to the RFC Editor before the Precis Framework, it will stay there until the framework reaches the RFC editor. (as individual) I concur with this approach in general, although I think we will find some differences between the Resource parts in 6122/6122bis and the use of nicknames in simple-chat. In particular: 1) A resource part identifies something. That makes uniqueness and comparisons fairly important. OTOH, a nickname is really for human display purposes. We still need to be able to compare them for reservations to work. And the human readability part means we should at least mention character confusion issues. In the chatroom context, XMPP resourceparts are mostly used for display purposes but also for some authorization decisions (e.g., we can kick people based on their nickname). As far as I understand it, the uses are really quite similar in XMPP chatrooms and SIMPLE chatrooms. 2) The 6122bis resource parts live inside URIs, while simple-chat nicknames are just strings. Well, we don't really use URIs in XMPP. Probably you mean JIDs (JabberIDs). In that case, yes, they are used sometimes for addressing in XMPP chatrooms (e.g., to send a private message to another occupant). I'm not sure that these differences really change the outcome much--they're just things to think about. Although I think that XMPP resourceparts *as they are used in chatrooms* are quite similar to SIMPLE nicknames, resourceparts are used in other contexts (e.g., as device/connection identifiers) so the resourceprep replacement that's developed in the XMPP WG won't be quite what you need anyway. However, there probably is value in thinking about nicks in general, because it's possible that we could define the same PRECIS profile for use in both XMPP chatrooms (XEP-0045) and SIMPLE chatrooms. A common approach might be good. Peter -- Peter Saint-Andre https://stpeter.im/ ___ Simple mailing list sim...@ietf.org https://www.ietf.org/mailman/listinfo/simple
Re: [Standards] XEP-0301 Session handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/28/12 11:28 PM, Gunnar Hellström wrote: Returning to the initial question of this thread: Is there a common way to indicate session start and session end. Peter Saint-Andre skrev 2012-02-29 04:20: Yes, but that doesn't necessarily mean you need an explicit negotiation protocol. Right. The first need I thought about can in fact be reduced to a text session indicator, not even linked to RTT support. I will take a scenario to make the need clear. Assume that there is a SIP based stock exchange service, sending stock exchange information in text in sessions. It continues as long as a terminal is connected. A terminal indicates by a BYE that it leaves the session, so that the server can release the resources. During the session, the text information may be provided through RFC 4103 or RFC 3428 or RFC 4975. (RFC 4103 makes most sense of course for the RTT example, but let us look at it in general). Also assume that you want to make this service available to XMPP users through a gateway. Setting up a chat session to the gateway causes it to set up a SIP session with the stock exchange server. Messages or real-time text is flowing from the stock exchange server to the XMPP client. Then, the XMPP user want to leave the session. What does the user do and what does the gateway use as an indication that the session is over and it can take down the session towards the server? I really think that if you want to gateway between SIP and XMPP, you want to use Jingle. Such gatewaying was one of the core considerations for Jingle. Now, I haven't looked at RFC 4103 in quite a while, but we can certainly write a spec that defines how to translate between XEP-0301 and RFC 4103 (e.g., how to translate the SDP). Personally I don't think we absolutely need a way to complete a formal negotiation over XMPP itself, because I tend to think that just sending a chat message is a much more natural interaction, but *if* we think we need such a negotiation method, we should just use Jingle. 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/ iEYEARECAAYFAk9OcRQACgkQNL8k5A2w/vzgqwCgiBcvV337uC0aDPVQ0zJ2zY+x dGsAoKhCEcelqsbgJFE5fF1trjKBFkPU =NhyO -END PGP SIGNATURE-
Re: [Standards] Pubsub: Item Publisher again.
On 2/24/12 5:51 AM, Sergey Dobrov wrote: Hello, I already asked but nothing happened: http://xmpp.org/extensions/xep-0060.html#publisher-publish-success-publisher says: If configured to do so, the service can include the publisher of the item when it generates event notifications. This isn't clear at all. How it should be configured? How to check if the service WILL include the publisher? I think this is a gap in the spec. Something to fix when we work on revisions later this year (I'll have cycles starting in April). Can we REQUIRE a service to include this? Because, it's really the only way to check if item publisher was not spoofed. For now I using that feature but have no any way to do it consistently. Without it, any publisher can sign it post with any other. The http://xmpp.org/extensions/xep-0060.html#impl-association doesn't reply to the question because it describes another behavior of the attribute and not switching it on or off. Right. We need to define the configuration option for this. Peter -- Peter Saint-Andre https://stpeter.im/
[Standards] Obsoleting XEP-0130 (Waiting Lists)
hat type='editor'/ During the XMPP Council meeting earlier today, I raised the issue of Obsoleting XEP-0130 (Waiting Lists). This protocol was designed mostly by a few folks from Jabber Inc. and France Telecom, and used primarily in France Telecom's XMPP-based messaging service. That service went offline in ~2007 and I have verified that support for the protocol was removed from the Jabber XCP codebase some time ago. I am not aware of any other existing deployments, since they would have been provided to interoperate with France Telcom's service. Therefore I think it is appropriate to change the status of XEP-0130 to Obsolete. If you have any concerns about this action, please post to this list by March 16, 2012. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Pubsub to atom mapping :)
On 2/28/12 1:56 AM, Sergey Dobrov wrote: On 02/28/2012 06:36 AM, Peter Saint-Andre wrote: On 2/27/12 12:36 AM, Sergey Dobrov wrote: The other thing here is linking: atom:link needs attributes ref and href, but href usually points to the atom feed at all and ref points to the specific entry in the feed by it's atom:id. Then, should we point to the node there and not to the specific item in the node? Then we can exclude atom:id from entries as superfluous. Have we to change Atom's xmlns then? I don't see any harm from duplicating the atom:id in the payload. The only one: what if some software will write different values to there? Which one will be trusted then? Yeah, I thought about that. It might depend on who is relying on which attribute. E.g., the base XMPP implementation might rely on the pubsub ItemID for tracking purposes related to the message transport, whereas the Atom payload might be handed off to a higher-level application that relies on the atom:id for things like de-duplication. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] long specs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/27/12 4:02 PM, Peter Saint-Andre wrote: On 2/15/12 1:07 PM, Peter Saint-Andre wrote: On 2/15/12 12:48 PM, Kurt Zeilenga wrote: On Feb 15, 2012, at 8:26 AM, Peter Saint-Andre wrote: I'd be willing to work on this, but I want to make sure that people think there's value in doing so. Personally, I not sure what I hate more, overly long documents or specifications unnecessarily split over multiple documents. I don't consider XEP 45 or XEP 60 to be overly long. Half the feedback I receive is (a) it's too hard to read a long spec. The other half is (b) it's too hard to read multiple specs. For XEP-0060, the feedback is heavily weighted toward (a). For XEP-0045, it's about evenly weighted. My conclusion is that we really need to split up XEP-0060, and that splitting XEP-0045 into user vs. admin use cases would be helpful. Over the weekend I took a rough cut at splitting up XEP-0045. Here's what I came up with (page lengths are based on print-to-PDF in Firefox): XEP-0045 = 141 pages Architecture, Requirements, Discovery, Security = 35 pages Occupant Use Cases = 56 pages Administration = 68 pages Because more than one person has asked about the split files, I've placed them here: http://www.saint-andre.com/jabber/tmp/muc-arch.html http://www.saint-andre.com/jabber/tmp/muc-occupant.html http://www.saint-andre.com/jabber/tmp/muc-admin.html 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/ iEYEARECAAYFAk9NN+oACgkQNL8k5A2w/vwYKACgkVYFy00xLTlppsW/KJl0yk8u lc0AoNe44vM9zidMpipzOho74jncGE4N =Ia5C -END PGP SIGNATURE-
Re: [Standards] XEP-0301 Session handling
Hi Gunnar! On 2/28/12 4:07 PM, Gunnar Hellström wrote: Sometimes it is very helpful with a clear beginning and a clear end of an XMPP text session. Some people have thought so in the past: http://xmpp.org/extensions/xep-0155.html That was mainly developed for the purpose of end-to-end encryption (XEP-0116). Personally I think it would be good to deprecate it. For example if you are gatewaying to a SIP call, and want to cause a hangup on the SIP side, or get an indication to the XMPP side when the SIP side has closed the session. We have Jingle for multimedia session management. We could use it for managing a text session, although personally I think that's overkill. * Question*: I wonder if there is a session start - session end indication that has dominating support among XMPP text messaging implementations that can be used as the default mechanism for XEP-0301 real-time text session control. http://xmpp.org/extensions/xep-0085.html might be most appropriate. Right now in XEP-0301, there is an start event and a cancel event defined in section 4.2.3 with indications that they MAY be used to indicate session start and end. See http://xmpp.org/extensions/xep-0301.html I have found some other mechanisms, and I wonder if the start and cancel events should be deleted from XEP-0301, and instead some already existing mechanism used, in order to not increase the number of optional ways to handle session start and end. Probably a good idea. It seems to me that there is a basic mechanism for session control defined in RFC 6121 section 5.1 Initiation of a session should begin with a message with type=chat, Both parties shall set their presence show/ to chat End of session should be signaled by indicating directed presence unavailable. A change of show/ to anything else than chat should also be taken as indication of end of session. An example is presented in section 7 of RFC 6121. I think XEP-0085 (Chat State Notifications) is more relevant. I don't think it would be good to overload show/ states because those are related to presence in general, not a particular chat session. I assume that there are a multitude of exceptions when this sequence does not occur, but it seems to me to be a good basic sequence to support. On top of that, there seems to be a range of more comprehensive session control options: -XEP-0166 Jingle session establishment. If we want formal session management for RTT sessions then I think Jingle is the way to go, but I am not convinced that we need formal session management. -XEP-0155 Session establishment I think we should deprecate that. -XEP-0045 Multi-User Chat ( that also uses directed unavailable presence for closing the session as the main method above.) MUC is multi-user, not one-to-one, so I think it's not general enough for use in RTT. * Proposal:* So, for XEP-0301, I want to check if it would be wise to delete the start and cancel events from chapter 4.2.3 and instead insert a new subsection in chapter 6 saying: 6.4 Session control Session control is essentially out of scope for this media related extension. A recommendation is though to follow the basic principles described in RFC 6121 section 5.1. Any further session handling such as Jingle, MUC or the Session establishment extension may be added as found suitable for each specific application of this extension. My primary question is: do we need formal management of RTT sessions? I don't think we do, and I think we can handle them informally using a combination of RFC 6121 and XEP-0085. However, if we really really need formal management then I would suggest using Jingle. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0301 Session handling
On 2/28/12 4:47 PM, Mark Rejhon wrote: I'm interested in feedback about session negotiation techniques, and about simplifying XEP-0301 by removing the start/cancel attributes (which are OPTIONAL) which are actually not currently used in any of the several XEP-0301 implementations I have seen, including the latest version of RealJabber (software installer package now available at www.realjabber.org http://www.realjabber.org ...) I also need to define a mechanism where both sides of a XEP-0301 compliant client can negotiate the simultaneous enabling of real-time text on both sides, on an example mainstream client that might have RTT disabled by default. For example, it should be possible for software vendors to add an activation button for real-time text -- like there's already a button for audio or video in many popular IM clients. One technical method behind the scenes is to use the event=start/event=cancel , but a different method is to also automatically prompt to send return RTT if it detects incoming RTT. *Use Case Example #1:* Alice messages Bob. Alice enables real-time text by clicking a button. On Bob machine, when his software receives an rtt element for the first time, the software can prompt Bob to enable the real-time text feature, as follows: / Alice is now sending real-time text. Click [Accept] to transmit your typing live too./ *Use Case Example #2:* Alice messages Bob. Alice enables real-time text by clicking a button. Bob's IM client is preconfigured to automatically accept real-time text. Upon receiving Alice's real-time text in rtt, Bob automatically enables sending of rtt. A notification message simply gets displayed in the message history: *** /Alice has activated real-time text. / /Your typing is now being transmitted live./ If this method is done, then it is not necessary to worry about using the event='start' / event='cancel' for the purposes of RTT-specific session signalling, and I can just remove it from XEP-0301 to simplify. Also, it is noted that XEP-0301 section 5 already provides a mechanism for a client to detect whether the remote client has RTT support, before transmitting outgoing unsolicited rtt. Mark, the model you're searching for is what we use in XEP-0085. Please take a look at the text there and see if you can re-use it for RTT. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0301 Session handling
On 2/28/12 6:13 PM, Mark Rejhon wrote: On Tue, Feb 28, 2012 at 7:04 PM, Peter Saint-Andre stpe...@stpeter.im mailto:stpe...@stpeter.im wrote: On 2/28/12 4:47 PM, Mark Rejhon wrote: [snip] *Use Case Example #1:* Alice messages Bob. Alice enables real-time text by clicking a button. On Bob machine, when his software receives an rtt element for the first time, the software can prompt Bob to enable the real-time text feature, as follows: / Alice is now sending real-time text. Click [Accept] to transmit your typing live too./ *Use Case Example #2:* Alice messages Bob. Alice enables real-time text by clicking a button. Bob's IM client is preconfigured to automatically accept real-time text. Upon receiving Alice's real-time text in rtt, Bob automatically enables sending of rtt. A notification message simply gets displayed in the message history: *** /Alice has activated real-time text. / /Your typing is now being transmitted live./ If this method is done, then it is not necessary to worry about using the event='start' / event='cancel' for the purposes of RTT-specific session signalling, and I can just remove it from XEP-0301 to simplify. Also, it is noted that XEP-0301 section 5 already provides a mechanism for a client to detect whether the remote client has RTT support, before transmitting outgoing unsolicited rtt. [snip] Mark, the model you're searching for is what we use in XEP-0085. Please take a look at the text there and see if you can re-use it for RTT. Hello, Yes, but it does not answer the question of how to negotiate the enabling of RTT. There are three angles that are covered, two of them answered, and one of them not. *[Answered] **Matter of Compatibility between XEP-0301 and XEP-0085:* XEP-0085, if used, is very easily complementary with RTT. You just simply send composing/ with the first rtt/ element transmitted from any other state (i.e. active/ or paused/) I should add a sentence about this general practice. *[Answered] Matter of Simplifying XEP-0305 by removing its session signalling* XEP-0085 can easily justify the removal of the *event='start'* and *event='cancel'* * * *[To Discuss] Matter of negotiation of activation of RTT feature* /However/, XEP-0085 doesn't answer the question of an appropriate negotiation model for deciding whether or not to enable RTT for a chat session. (RTT is most ideal when both ends enable it) Peter, do you think that my use case examples seem appropriate behaviour? Comments would be appreciated about this. I'm suggesting that you use a model similar to XEP-0085 -- if the other side advertises it (disco/caps), send the first message with some kind of RTT element. If the response comes back without an RTT element, don't include any RTT elements in subsequent messages within that conversation. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0301 Session handling
On 2/28/12 7:33 PM, Mark Rejhon wrote: On Tue, Feb 28, 2012 at 9:02 PM, Peter Saint-Andre stpe...@stpeter.im mailto:stpe...@stpeter.im wrote: I'm suggesting that you use a model similar to XEP-0085 -- if the other side advertises it (disco/caps), send the first message with some kind of RTT element. If the response comes back without an RTT element, don't include any RTT elements in subsequent messages within that conversation. Hello! This works in niche clients. However, when bringing real-time text to the mass market, it is presumed that vendors (i.e. Microsoft, Google) will want it to be disabled by default. That's a client configuration and UI issue, not a protocol issue. 1. If the interlocutor doesn't advertise support for RTT, consider RTT unavailable for this conversation and don't proceed to #2. 2. If the interlocutor advertises support for RTT, prompt your user about whether to try RTT (or have some setting about try RTT with known contacts or somesuch). 3. If you try RTT but the interlocutor doesn't include RTT extensions, don't include RTT in subsequent messages. I still don't see the need for protocol-level *negotiation* here. However, if you are convinced that we need it, then we already have a protocol for that: Jingle. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0301 Session handling
Hi Florian! On 2/28/12 7:42 PM, Florian Zeitz wrote: Am 29.02.2012 03:02, schrieb Peter Saint-Andre: On 2/28/12 6:13 PM, Mark Rejhon wrote: *[To Discuss] Matter of negotiation of activation of RTT feature* /However/, XEP-0085 doesn't answer the question of an appropriate negotiation model for deciding whether or not to enable RTT for a chat session. (RTT is most ideal when both ends enable it) Peter, do you think that my use case examples seem appropriate behaviour? Comments would be appreciated about this. I'm suggesting that you use a model similar to XEP-0085 -- if the other side advertises it (disco/caps), send the first message with some kind of RTT element. If the response comes back without an RTT element, don't include any RTT elements in subsequent messages within that conversation. Peter I tend to disagree with this. It would inherently require that both sides do RTT. That was the assumption behind chat state notifications. I think it's a reasonable assumption, but I also think that reasonable people can disagree about it. I don't see any reason to enforce this artificial requirement. It is perfectly fine for just one side to send RTT messages, while the other one uses normal chat messages. If someone doesn't want to receive RTT messages, he should just not include the feature in the disco response. Sure. Also I see absolutely no reason for any session negotiation for this XEP whatsoever, especially without an option for the receiving party to decline the session. A simple on/off switch on the sending end (only availabe when the disco feature is present) seems sufficient to me. I too agree that we don't need session negotiation. As a side note. What you described is actually quite different from what XEP-0085 says. You're mixing the usual disco case with the backwards compatibility case where no feature is present, but chat states might still be supported. Quite possibly. :) Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0301 Session handling
On 2/28/12 8:15 PM, Mark Rejhon wrote: Hello, That's a client configuration and UI issue, not a protocol issue. Actually, we've found it is a very important long-term interoperability issue -- please see my big email, we have plans to add RTT to multiple open source clients. We've explained several scenarios (i.e. a Year 2014 build of Pidgin talking to a Year 2014 build of Adium ) Even if the interoperability is accomplished by a software practice, the software practice still needs to be 'standardized' between different brands, and therefore must be mentioned in XEP-0301, and therefore relevant discussion Yes, but that doesn't necessarily mean you need an explicit negotiation protocol. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] long specs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/15/12 1:07 PM, Peter Saint-Andre wrote: On 2/15/12 12:48 PM, Kurt Zeilenga wrote: On Feb 15, 2012, at 8:26 AM, Peter Saint-Andre wrote: I'd be willing to work on this, but I want to make sure that people think there's value in doing so. Personally, I not sure what I hate more, overly long documents or specifications unnecessarily split over multiple documents. I don't consider XEP 45 or XEP 60 to be overly long. Half the feedback I receive is (a) it's too hard to read a long spec. The other half is (b) it's too hard to read multiple specs. For XEP-0060, the feedback is heavily weighted toward (a). For XEP-0045, it's about evenly weighted. My conclusion is that we really need to split up XEP-0060, and that splitting XEP-0045 into user vs. admin use cases would be helpful. Over the weekend I took a rough cut at splitting up XEP-0045. Here's what I came up with (page lengths are based on print-to-PDF in Firefox): XEP-0045 = 141 pages Architecture, Requirements, Discovery, Security = 35 pages Occupant Use Cases = 56 pages Administration = 68 pages The document that most client developers would read is the one on occupant use cases. Would they find 56 pages less intimidating than 141 pages? Probably. (And probably we could move some stuff out of the occupant use cases -- requesting voice, that kind of thing.) Would it be worth our time to split things up this way? Perhaps. 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/ iEYEARECAAYFAk9MC2kACgkQNL8k5A2w/vxtXgCdEcshiapn1LRQT79pwrQ0k6QO 4+AAoM3YYDxYJvoHAzsKtuF47LYLKOow =slhU -END PGP SIGNATURE-
Re: [Standards] Pubsub to atom mapping :)
On 2/27/12 12:36 AM, Sergey Dobrov wrote: I think now that the second option is more suiting: it will be easier to add the ability to view item's revisions than make some kind of item grouping. Yes, I think that's good: pubsub itemid = atom:id. The other thing here is linking: atom:link needs attributes ref and href, but href usually points to the atom feed at all and ref points to the specific entry in the feed by it's atom:id. Then, should we point to the node there and not to the specific item in the node? Then we can exclude atom:id from entries as superfluous. Have we to change Atom's xmlns then? I don't see any harm from duplicating the atom:id in the payload. Any opinions? On 02/24/2012 08:10 PM, Sergey Dobrov wrote: Hello, Pubsub specifications often refers to the Atom format as a payload. Nevertheless, there are some confusing things that makes it hard to understand how to map atom to pubsub in some cases that are outside of the specifications. The reason I want to solve them is in XEP-277 which I need to update to implement some of must have feature into my microblogging platform. Here I suggest to discuss these problems. The hardest problem here is how to map atom:id (http://tools.ietf.org/html/rfc4287#page-19) element to the pubsub item id and closely connected to it problem with the Update post feature. The problem is that we have two different entry id fields and it very important to understand which means what to make protocol useful. I see two possible ways here: 1) pubsub item id identifies the concrete revision of an item. Thus, if we have to update the item then we just post a new item to the node with the same atom:id and another pubsub id. Benefit here is that if we link from another place to this item (for example, in the in-reply-to) then it will be a link to this concrete revision and will never confuse with other revisions. Another benefit is that we can to track any changes to the entry since all of them are stored in the node. But this option has one strong disadvantage: we have no way to group these entries to make it possible, for example, to retract the entry entirely with all of it's revisions. I have no idea how we can solve the issue yet. 2) pubsub item id = atom:id. Thus, if we have to update the item then we just update the item. :) Possibly, we need to refuse to use atom:id in payload at all since it's confusing to have two identities that means the same thing. How to address the entry then? Thanks for your attentions, I hope that I was clear enough. Have a good weekend, btw. :) -- Peter Saint-Andre https://stpeter.im/
[Standards] obsoleting XEP-0130 (Waiting Lists)?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As far as I have been able to determine, the technology defined in XEP-0130 (Waiting Lists) is obsolete. I plan to raise the issue of obsoleting the spec itself in the next XMPP Council meeting. 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/ iEYEARECAAYFAk9GyPYACgkQNL8k5A2w/vxjAACgrko9Y1ieKBzYE2+14kHKNJMo tkoAni8aYC/nExtEougzpvLLcyVsi46E =DidZ -END PGP SIGNATURE-
[Standards] Fwd: Re: [jdev] XEP 0172 in MUCs
FYI, I plan to update XEP-0172 along these lines. Original Message Subject: Re: [jdev] XEP 0172 in MUCs Date: Mon, 20 Feb 2012 01:07:47 +0500 From: Waqas Hussain waqa...@gmail.com Reply-To: Jabber/XMPP software development list j...@jabber.org To: Jabber/XMPP software development list j...@jabber.org On Tue, Feb 14, 2012 at 3:54 AM, Peter Saint-Andre stpe...@stpeter.im wrote: Hallo Thijs, On 1/4/12 10:26 AM, Thijs Alkemade wrote: Hello, As a client developer, I'm a bit confused about how XEP 0172 (User Nickname) is intended to be used with MUCs. From the XEP: A user MAY specify his or her persistent nickname as well. This may be desirable because the user's preferred room nickname is already taken or because the service locks down room nicknames. So should a client should interpret the XEP-0172 nickname as a replacement for the MUC-nickname? I think it would be supplemental. This could lead to confusing situations with the same nick being used multiple times. If the service locks down room nicknames, then it supposedly has a good reason for that, and implementing a way to circumvent that sounds like a bad idea. I think you're right. The reason I'm asking this is because Google Talk (the web interface) uses, for ad-hoc private group chats, random strings as room nicks, and then sends the user's real name as a nick element. I think all users would rather see the real name instead of the random string, but I'm worried about the implications of changing this. I've read the Security Considerations of XEP-0172, but I don't think that really answers this. I agree with you that it's preferable to allow real roomnicks. We might want to update XEP-0172 to make that clearer, or even deprecate its use in chatrooms... I strongly support deprecating its use in chatrooms. We've seen this cause issues in the Prosody chatroom. This was on my list of things to post on the standard list, but somehow I never did. This issue that we saw was different clients showing users different nicks for the same user, users auto-completing the wrong nick, and conversations getting derailed due to that. A quick survey of the participants in that discussion showed that the affected clients had no visual indication that the nick being displayed and in the UI wasn't the real room nick. This has obvious security implications, e.g., it easily allows impersonation. -- Waqas Hussain ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [Standards] Pubsub: override item id when publish
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/17/12 4:50 AM, Sergey Dobrov wrote: On 02/15/2012 11:52 PM, Peter Saint-Andre wrote: Hi Sergey, Hello again. On 2/15/12 9:15 AM, Sergey Dobrov wrote: So I suggest to add to 7.1.2 that client MUST always check if service has changed the item id. Then it will be possible to do serial items ids also. Do anyone know if this will be a problem for anything? I think this is similar to joining a chatroom or setting a resourcepart when logging in: the server has the right to change the identifier that was provided by the user. So I think this is something we should fix when we revise XEP-0060 later this year. Ok, that's great, I am using this feature now and it seems to work excellent. But I have one adjacent question: is it possible for a pubsub service to modify a payload someway? For example, to filter spam / obscene or inadmissible expressions, also it may be useful to add an alternate link to atom payloads with a web representation of the item because client can't know where exactly it will be located. So if it is possible then client should know how the item is now looks. It may be done with including the changed payload into the same result iq, I think. :) Yes, that's a good suggestion! 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/ iEYEARECAAYFAk8+dpsACgkQNL8k5A2w/vw7bwCgrRrALUVl07Ze2iz76yL73yl7 26wAoIJzwcYugGy72nYDrTwK9WkpO3dj =o1px -END PGP SIGNATURE-
[Standards] long specs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We have two really long specs: XEP-0045 and XEP-0060. In the XMPP Council meeting just now, we talked about some ways to shorten these documents. The rough consensus seemed to be that for XEP-0045 we could probably move the moderator/admin/owner use cases to a separate spec. A quick visual comparison of the following two URLs indicates that we'd cut about 40% (or more) of XEP-0045 by doing that: http://xmpp.org/extensions/xep-0045.html#moderator http://xmpp.org/extensions/xep-0045.html#statuscodes Notice also the length of these sections: http://xmpp.org/extensions/xep-0045.html#registrar-formtype http://xmpp.org/extensions/xep-0045.html#schemas-admin http://xmpp.org/extensions/xep-0045.html#schemas-owner I'd be willing to work on this, but I want to make sure that people think there's value in doing so. Ralph Meijer might post separately about XEP-0060. 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/ iEYEARECAAYFAk873LEACgkQNL8k5A2w/vyESgCg8yF0UCmUj4ByeRX5f4jrkmc7 Ar4AoIbq3BRwQN1Xaf2oUQP5rtLK/Wj8 =Zj2k -END PGP SIGNATURE-
Re: [Standards] long specs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/15/12 9:35 AM, Dave Cridland wrote: On Wed Feb 15 16:26:25 2012, Peter Saint-Andre wrote: We have two really long specs: XEP-0045 and XEP-0060. In the XMPP Council meeting just now, we talked about some ways to shorten these documents. The rough consensus seemed to be that for XEP-0045 we could probably move the moderator/admin/owner use cases to a separate spec. A quick visual comparison of the following two URLs indicates that we'd cut about 40% (or more) of XEP-0045 by doing that: http://xmpp.org/extensions/xep-0045.html#moderator http://xmpp.org/extensions/xep-0045.html#statuscodes Notice also the length of these sections: http://xmpp.org/extensions/xep-0045.html#registrar-formtype http://xmpp.org/extensions/xep-0045.html#schemas-admin http://xmpp.org/extensions/xep-0045.html#schemas-owner I'd be willing to work on this, but I want to make sure that people think there's value in doing so. Ralph Meijer might post separately about XEP-0060. I'm happy with splitting these up, but can we also manage to sort out some related updates to XEP-0001: a) I'd like to be able to have stable and working copies of the same spec, particularly for major revisions like XEP-0045 is currently going through. I think this is a matter of best practices for how the spec authors work, i.e., placing interim versions in a source control branch. b) I'd like to be able to have the ability to enter a XEP that's been hived off from another mature XEP (or RFC) directly into Draft, for instance. This has come up previously. Yes, we need that. 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/ iEYEARECAAYFAk8734MACgkQNL8k5A2w/vyYiQCgqEylSmab3FyyoJmTy1s1O1hh TFEAoJYedTE2ZXbgXGht7yC57M4Kv9Q1 =dIVE -END PGP SIGNATURE-
Re: [Standards] Pubsub: override item id when publish
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Sergey, On 2/15/12 9:15 AM, Sergey Dobrov wrote: I am working on a gateway to a legacy microblogging network now (juick.com) and I have a problem: items ids have rules that predefined by legacy network rules, so I want pubsub publish to redefine item id when publish request is done. The XEP-60 describes mechanism that can be useful for it (7.1.2. Success case: If the publish request did not include an ItemID, the IQ-result SHOULD include an empty item/ element that specifies the ItemID of the published item.), but it doesn't cover the case if user included item id. So I suggest to add to 7.1.2 that client MUST always check if service has changed the item id. Then it will be possible to do serial items ids also. Do anyone know if this will be a problem for anything? I think this is similar to joining a chatroom or setting a resourcepart when logging in: the server has the right to change the identifier that was provided by the user. So I think this is something we should fix when we revise XEP-0060 later this year. 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/ iEYEARECAAYFAk874sMACgkQNL8k5A2w/vyAmQCghecSNitc9NsoCE9h5q4MQmp1 16UAnRhdwFu14AUVBTSCeFQtzakwT1+t =+ZCA -END PGP SIGNATURE-
Re: [Standards] long specs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/15/12 10:17 AM, Kevin Smith wrote: On Wed, Feb 15, 2012 at 5:15 PM, Dave Cridland d...@cridland.net wrote: On Wed Feb 15 17:00:18 2012, Matthew Wild wrote: On 15 February 2012 16:39, Dave Cridland d...@cridland.net wrote: On Wed Feb 15 16:38:27 2012, Peter Saint-Andre wrote: a) I'd like to be able to have stable and working copies of the same spec, particularly for major revisions like XEP-0045 is currently going through. I think this is a matter of best practices for how the spec authors work, i.e., placing interim versions in a source control branch. There are informal methods for handling this, yes - I think we'd benefit from formal ones. I'm not overly keen on this. Could you describe a bit more what a world where we implement this looks like? Multiple live versions of the same spec seems... a step in the wrong direction. RFC 822 is an Internet Standard (STD 11) RFC 2822 was a Proposed Standard, which obsoleted RFC 822. RFC 5322 obsoletes 2822, and is a Draft Standard. So we're in the interesting position of having a standard which is obsoleted twice over. This is rather weird - and a bit sucky. In the XMPP world, this doesn't happen - we only have XEP-0045. But for lengthy revision processes, I think having actual published sub-versions would make more sense - that is, we have XEP-0045, but we also have (say) XEP-0045-1 which might be Experimental. It'd allow review cycles to be shorter, but also allow the newer spec to be seen at an easy to find location. For a similar example, look at the progression of draft-ietf-xmpp-3920bis-XX against RFC 3920. The drafts weren't stable (we considered them equivalent in principle to an Experimental XEP), up until RFC 6120 was published, when RFC 3920 effectively vanished. But it meant that in most cases, we could do incremental reviews. But this works with what we have, doesn't it? Peter often posts RC versions, which work with Tobias's fancy XEP-diff tool, and which we can review in full, etc. etc. Yeah, I think that works fine. We just need to start putting those interim versions in a source control branch so that they don't get published accidentally. 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/ iEYEARECAAYFAk878loACgkQNL8k5A2w/vyLXgCeNcfHDFO9a4uSEWD8+7khYbkm H2gAnR38f1mXRtIMem6v36zrwQwdFjBh =Mduv -END PGP SIGNATURE-
Re: [Standards] XEP-0045 nick changes
On 2/15/12 5:01 AM, Dave Cridland wrote: On Tue Feb 14 04:09:45 2012, Peter Saint-Andre wrote: On 1/24/12 2:58 PM, Dave Cridland wrote: I recall - ages ago - that we were going to, at one point, mention that if you change your nickname, you should send unavailable persence after the change to the old nick: C: presence to='room@service/new_nick'/ S: presence from='room@service/old_nick' type='unavailable'...110/303.../presence S: presence from='room@service/new_nick'/ C: presence to='room@service/old_nick' type='unavailable'/ The problem being that currently, the server must track directed presence, and so if you change your nickname, the server keeps tracking the old nickname too - and will eventually have to send an unavailable anyway. Well, the server could do that immediately (when it accepts the nick change), no? No, your server has no real idea it *is* a nick change, without tracking a lot more. It sounds like someone needs to write a spec proposal. Have at it. :) Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] long specs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/15/12 12:48 PM, Kurt Zeilenga wrote: On Feb 15, 2012, at 8:26 AM, Peter Saint-Andre wrote: I'd be willing to work on this, but I want to make sure that people think there's value in doing so. Personally, I not sure what I hate more, overly long documents or specifications unnecessarily split over multiple documents. I don't consider XEP 45 or XEP 60 to be overly long. Half the feedback I receive is (a) it's too hard to read a long spec. The other half is (b) it's too hard to read multiple specs. For XEP-0060, the feedback is heavily weighted toward (a). For XEP-0045, it's about evenly weighted. My conclusion is that we really need to split up XEP-0060, and that splitting XEP-0045 into user vs. admin use cases would be helpful. 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/ iEYEARECAAYFAk88EG8ACgkQNL8k5A2w/vyaOwCfUBBv7bE94Om9ImDOoeIQmiTi 8a8AoLqKW6ul2QrXIuhMZJEWVILGjXVt =x30E -END PGP SIGNATURE-
Re: [Standards] XEP-0045 nick changes
On 2/14/12 12:59 AM, Kim Alvefur wrote: On 1/24/12 2:58 PM, Dave Cridland wrote: I recall - ages ago - that we were going to, at one point, mention that if you change your nickname, you should send unavailable persence after the change to the old nick: C: presence to='room@service/new_nick'/ S: presence from='room@service/old_nick' type='unavailable'...110/303.../presence S: presence from='room@service/new_nick'/ C: presence to='room@service/old_nick' type='unavailable'/ The problem being that currently, the server must track directed presence, and so if you change your nickname, the server keeps tracking the old nickname too - and will eventually have to send an unavailable anyway. Well, the server could do that immediately (when it accepts the nick change), no? Would it need to after the target JID sends unavailable? No, but depending on clients to do this seems slightly unrealistic, if they haven't been doing it up till now. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] comments on XEP-0289
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/7/12 10:56 PM, Curtis King wrote: On 2012-02-07, at 6:10 PM, Peter Saint-Andre wrote: At the XMPP Summit, I finally had a chance to chat with Kevin Smith about XEP-0289, and on the plane back from Brussels I've reviewed that spec in more detail. Herewith some feedback, which is terse because I'm running out of battery power and my plane going to land soon. First, I like the XEP-0289 approach and in general I prefer it to what I wrote up in XEP-0281 (especially the more natural use of presence from one room to join the other room, instead of the IQ-ish approach in 281). However, much is left unspecified in XEP-0289 and I have a lot of questions. :) I have implemented a modified version of 289 which supports both master to master and slave to master. I was hoping we would have an updated XEP before the summit but that didn't happen. First, terminology. I like MUC mirroring instead of federated MUC (because there's confusion with server federation -- you could argue that our current model already is federated MUC). I would change things as follows (you can figure out particular terminology I use below from the parts of the JIDs): sou...@home.near.tld (the source room) source\40home.near@mirror.far.tld (the mirror room) I got rid of all jid escaping to avoid any client changes. In one sense, I like the JID\20Escaping stuff, because it shows the relationship between the source room and the mirror room. Questions: - from the perspective of a far user, is the mirror room just a standard MUC room? if not, why not (and exactly how)? Looks just like a standard MUC room. - do mirror rooms support all the usual MUC features (history, room administration etc.)? if not, why not? All still supported. - in particular, can the mirror room be administered? if not, why not? Yes - there might be some limitations for slaves to have central control of kicks, bans, etc. Right, that's what I was worried about -- synchronization of room configurations could get messy (you'll notice that's just the point in XEP-0281 where I left off...). - does / can the mirror room retrieve history on joining the source room? Yes, a must. Well, that might depend on deployment scenarios, no? If this is truly to be used in highly constrained environments, then history retrieval might be optional. - are there distinct disco identities for source rooms and mirror rooms? yes - but the client wouldn't know it. The goal is to have XEP-289 server only as much as possible. I think there might be value in knowing that a given room is a mirror. - does the source room config indicate that the room is (can be) mirrored? not currently. - does the mirror room config indicate what the source room is? not currently. Again, there might be value here. - can mirror rooms themselves be mirrored? (ick) No. A room is either a slave or master. Slaves can not have multiple masters nor other slaves. Sounds like a good idea. - do / can mirror rooms / services communicate with each other? I don't follow the question. Let's say that mirror1 and mirror2 lost connectivity to the source room (perhaps the source server goes offline). There might be value in allowing those mirror rooms to share their view of the room while the source room is offline. - does the mirror room wait for presence fan-out from the source room before sending presence to far users? Depends. Masters no, slaves yes. But all mirrors are caching presence, history, etc. I think you misunderstood my question. Far user joins mirror room. Mirror sends presence update to source room. Does mirror room wait to send that user's presence to everyone in the mirror room (pending receipt of presence from the source room)? - does or should the mirror room include delayed delivery info in the messages that it sends to far users? No, it behaves as a normal MUC room. I'll have to think about that some more. - can the source service explicitly request that the mirror service shall mirror a particular room (as in XEP-0281)? probably not needed, but good to make it clear - what happens if a near user tries to join a mirror room? is that user redirected from the mirror room to the source room? How would you know where the user is? So, no. You would know based on the domainpart of the joining user's full JID. The updated xep will make this clearer. Great. - can a far user join the source room directly? Sure, why not? Because, based on policy, the mirror might want all of the users in its administrative domain to join the mirror instead of the source. can the source room redirect a far user to the mirror room (as in XEP-0281)? No. Here again, policy might dictate joining the room that's closest to you. I would not want to forbid this behavior, but I don't think it needs to be part of the base spec. - we need to show
Re: [Standards] Status of XEP 0075
On 1/9/12 4:32 PM, Markus Kohlhase wrote: Hi, I'd like to discuss the status of XEP 0075 with you. My motivation to use it is to write an XMPP based application. It's a distributed system with a web client for managing some entities. There are several ways to communicate with application servers, e.g. - XEP 0009: Jabber RPC - XEP 0050: Ad-Hoc Commandd - XEP 0072: SOAP Over XMPP But there are some drawbacks. Jabber RPC/XML-RPC is an old and great protocol. But if you want to manage a lot of entities with its properties it's sometimes complicated to map the methods to the entities. Ad-Hoc Commands are designed for human interaction and support only simple data structures (XEP-0004). Of course you can use XEP 0244 but it's still not really suited for machine to machine interaction. SOAP is a modern way to interact between multiple systems but for my case its too bloated for my needs. In my opinion JOAP is a great protocol for handling a bunch of objects. My questions: - Are there any other similar protocols? Perhaps IO Data: http://xmpp.org/extensions/xep-0244.html - Is it worth to work on that protocol? Maybe. :) It's very old and might not reflect up-to-date thinking about interactions between entities. - What do you think should be improved? I haven't looked at JOAP in 9 years, so I'm not sure what I'd change. XEP-0244 is the most recent attempt to work on something similar. XEP-0072 is indeed bloated, but you get all that SOAP stuff for free in various libraries, so it might be worth a closer look. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Jingle specification bug - missing error condition
On 1/26/12 10:29 AM, Peter Saint-Andre wrote: On 1/26/12 9:18 AM, Peter Saint-Andre wrote: On 1/26/12 4:53 AM, Ben Langfeld wrote: Gentlemen, I believe I have found a minor bug in XEP-0166, as follows: 1) An example states that a security-required/ error element be included in a response, qualified by the urn:xmpp:jingle:errors:1 namespace: http://gitorious.org/xmpp/xmpp/blobs/master/extensions/xep-0166.xml#line1399 2) The table of error conditions does not include security-required/: http://gitorious.org/xmpp/xmpp/blobs/master/extensions/xep-0166.xml#line1415 3) The schema does not include security-required/: http://gitorious.org/xmpp/xmpp/blobs/master/extensions/xep-0166.xml#line1724 I am unsure if it is the schema or the example which is correct. If someone can nudge me in the right direction, I can get a patch submitted today. Thanks for the bug report. I think that was an oversight in the table and schema, but I'll double-check and post again. Now I'm not so sure. Let's look at the paragraph before that example: If one of the parties attempts to send information over the unsecured XMPP signalling channel that the other party expects to receive over the encrypted data channel... That's kind of a strange scenario. You and I have set up an encrypted data channel, but I try to send data to you over the signalling channel that you would have expected me to send to you over the data channel. Perhaps we were thinking of XTLS at the time, but even that spec [1] does not use the security-required/ error. So I now think that this is extraneous text that needs to be removed. I'll forward this message to the jin...@xmpp.org list for verification. I've received no verification, but I still think this is the right thing to do. I'll bring it up in the next XMPP Council meeting. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Response Stream Namespace Qualification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/30/12 2:53 PM, Mike Wacker wrote: I saw this excerpt in RFC 6120, 4.8.2: An entity MAY declare a content namespace as the default namespace for data sent over the stream (i.e., data other than elements qualified by the stream namespace). If so, (1) the content namespace MUST be other than the stream namespace, and (2) the content namespace MUST be the same for the initial stream and the response stream so that both streams are qualified consistently. The content namespace applies to all first-level child elements sent over the stream unless explicitly qualified by another namespace (i.e., the content namespace is the default namespace). Reading that section, it suggests that the initial and response stream should always be qualified consistently, not just if the initiating entity declares a content namespace (e.g.: if the initial stream uses the stream namespace as the default namespace, then so should the response stream). However, this section on content namespaces is the only time the RFC mentions anything about qualifying the two streams consistently. If they are supposed to be qualified consistently, SHOULD or MUST they be qualified consistently? Yes, that's something to consider for rfc6120bis. I'll add it to my list. More importantly, would it be reasonable to expect that some clients would assume the initial and response streams are qualified in the same way instead of checking the stream header of the response stream to see how the response stream is qualified (in case it's qualified differently than the initial stream)? It's not clear to me what you intend the behavior of such clients to be. When you say expect that some clients would assume..., does that assumption have behavioral implications (e.g., return an error if the streams are not qualified consistently)? 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/ iEYEARECAAYFAk850mcACgkQNL8k5A2w/vwFbQCfXStBfPd7BpqSZXrsV2MQSHK9 EWkAnjaOnqWIIjxJzdimB0VIo86Otyul =c8Hv -END PGP SIGNATURE-
Re: [Standards] XEP-0115 Feedback
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Old thread alert! On 11/16/11 10:22 AM, Mike Wacker wrote: My apologies for the slow reply. It's been busy. :) (1) In 5.4. Processing Method, step 3.3 states, If the response includes more than one service discovery identity with the same category/type/lang/name, consider the entire response to be ill-formed. Should that actually be category/type/lang instead? XEP-0030 states, the query/ element MUST NOT include multiple identity/ elements with the same category+type+xml:lang but with different 'name' values. Thus, the only change here would be that XEP-0115 disallows results which are already disallowed by XEP-0030. Yes, consistency between XEP-0030 and XEP-0115 would be good on this point. (2) We may want to put a cautionary note in XEP-0128 about what should or should not be included as an extension. For example, if a client included a public encryption key in a disco#info response via service discovery extensions, and this key was different for each user (or resource), then every user would publish a different verification string, meaning that entity capabilities would perform no better than disco flooding for that given client. I'd prefer to disallow XEP-0128 forms from the XEP-0115 algorithm (or whatever algorithm replaces it). The primary reason we allowed XEP-0128 forms was to include software information (XEP-0232), but that spec never gained consensus. If all users of a client would coalesce around a small subset of all possible values for any extensions added, then entity capabilities would still work as designed. However, I would argue IMHO that clients SHOULD NOT (or maybe even MUST NOT) introduce new information via service discovery extensions that would likely be different for each user or resource. I'll save a longer rant about the tendency for developers to say, Let's make XYZ extensible! without considering, for example, the performance and/or security implications of such extensibility. This isn't the first context where I've seen extensibility potentially cause such issues, nor am I the first person to have such complaints :) Sure, rant away! ;-) 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/ iEYEARECAAYFAk853ZUACgkQNL8k5A2w/vzahQCgklTLp94W/0Nx9fRkaprTLERF M7wAoJEF9i7GL0UkXicjdviaE8FYkhW/ =2VGJ -END PGP SIGNATURE-
Re: [Standards] XEP-0045 nick changes
On 1/24/12 2:58 PM, Dave Cridland wrote: I recall - ages ago - that we were going to, at one point, mention that if you change your nickname, you should send unavailable persence after the change to the old nick: C: presence to='room@service/new_nick'/ S: presence from='room@service/old_nick' type='unavailable'...110/303.../presence S: presence from='room@service/new_nick'/ C: presence to='room@service/old_nick' type='unavailable'/ The problem being that currently, the server must track directed presence, and so if you change your nickname, the server keeps tracking the old nickname too - and will eventually have to send an unavailable anyway. Well, the server could do that immediately (when it accepts the nick change), no? Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] MAM
On 2/10/12 12:01 PM, Kim Alvefur wrote: On Thu, 2012-01-12 at 15:09 +0700, Sergey Dobrov wrote: On 01/12/2012 01:41 AM, Kim Alvefur wrote: On Tue, 2012-01-10 at 17:33 +0700, Sergey Dobrov wrote: Matt Wild's upcoming archiving spec is a good candidate for this. /K Where I can take a look on it? Here: http://matthewwild.co.uk/uploads/message-archive-management.html I've read the spec and I really like it, thank you for your work! My wishes to it: 1) Some way to retrieve a number of messages which will be retrieved with a query. May be useful when synchronize a large archive to show, for example, a progress of the process. I think this is covered by Result Set Management integration, if the implementation supports that in combination with MAM. Matthew, may the XEP Editor consider MAM contributed to the XSF inbox, or would you like to make further changes before the XMPP Council considers it for acceptance as a XEP? Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] MAM
On 2/10/12 2:59 PM, Matthew Wild wrote: On 10 February 2012 21:09, Peter Saint-Andre stpe...@stpeter.im wrote: On 2/10/12 12:01 PM, Kim Alvefur wrote: On Thu, 2012-01-12 at 15:09 +0700, Sergey Dobrov wrote: On 01/12/2012 01:41 AM, Kim Alvefur wrote: On Tue, 2012-01-10 at 17:33 +0700, Sergey Dobrov wrote: Matt Wild's upcoming archiving spec is a good candidate for this. /K Where I can take a look on it? Here: http://matthewwild.co.uk/uploads/message-archive-management.html I've read the spec and I really like it, thank you for your work! My wishes to it: 1) Some way to retrieve a number of messages which will be retrieved with a query. May be useful when synchronize a large archive to show, for example, a progress of the process. I think this is covered by Result Set Management integration, if the implementation supports that in combination with MAM. Matthew, may the XEP Editor consider MAM contributed to the XSF inbox, or would you like to make further changes before the XMPP Council considers it for acceptance as a XEP? I really would like to make further changes, the version I uploaded is very much a work in progress 'preview' that is not ready for implementation yet in my opinion. I understand the purpose of 'experimental' status, but I would rather get things mostly right on the first attempt than submit a protoXEP that I have substantial protocol changes queued for. That said, you can consider even what is there a contribution to the community, and if people really think it's worthy of submission in its current state then I won't hold it back. I suggest giving it a week... if I haven't officially submitted it by then, let's move forward with the current draft. The summit highlighted the widespread interest in this spec to me, so I really shall try my best to get it cleaned up and submitted in the coming days. Fair enough, thanks! Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] UPDATED: XEP-0300 (Use of Cryptographic Hash Functions in XMPP)
On 2/8/12 10:12 AM, XMPP Extensions Editor wrote: Version 0.3 of XEP-0300 (Use of Cryptographic Hash Functions in XMPP) has been released. Abstract: This document provides recommendations for the use of cryptographic hash functions in XMPP protocol extensions. Changelog: Modified XML structure to remove wrapper element; added recommendations for new XMPP extensions; softened recommendations for existing extensions. (psa) Diff: http://xmpp.org/extensions/diff/api/xep/0300/diff/0.2/vs/0.3 URL: http://xmpp.org/extensions/xep-0300.html This version incorporates feedback from Waqas Hussain. Kev and Matthew, please check this as co-authors to make sure that you think we're on the right track. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] [XEP-0234] File checking in JingleFT
On 12/12/11 11:32 AM, Jefry Lagrange wrote: I was thinking that maybe we propose a separate XEP for file checking. Still, some changes should have to be done to JingleFT such as allowing range transfer reuse the session and add a limit attribute in the range file transfer. So that it can send chunks of data (with offset and limit). Well, XEP-0234 is not finished, so should have been done is a bit pessimistic. I have just updated the spec to track the latest changes to XEP-0300 and I'd be happy to make further changes so that we can support future checking algorithms. I agree that we also need to provide clearer documentation of ranged transfers (e.g., reusing the Jingle session ID). Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XMPP logo licensing
Closing the loop... http://xmpp.org/about-xmpp/faq/ Peter -- Peter Saint-Andre https://stpeter.im/
[Standards] comments on XEP-0289
At the XMPP Summit, I finally had a chance to chat with Kevin Smith about XEP-0289, and on the plane back from Brussels I've reviewed that spec in more detail. Herewith some feedback, which is terse because I'm running out of battery power and my plane going to land soon. First, I like the XEP-0289 approach and in general I prefer it to what I wrote up in XEP-0281 (especially the more natural use of presence from one room to join the other room, instead of the IQ-ish approach in 281). However, much is left unspecified in XEP-0289 and I have a lot of questions. :) First, terminology. I like MUC mirroring instead of federated MUC (because there's confusion with server federation -- you could argue that our current model already is federated MUC). I would change things as follows (you can figure out particular terminology I use below from the parts of the JIDs): sou...@home.near.tld (the source room) source\40home.near@mirror.far.tld (the mirror room) Questions: - from the perspective of a far user, is the mirror room just a standard MUC room? if not, why not (and exactly how)? - do mirror rooms support all the usual MUC features (history, room administration etc.)? if not, why not? - in particular, can the mirror room be administered? if not, why not? - does / can the mirror room retrieve history on joining the source room? - are there distinct disco identities for source rooms and mirror rooms? - does the source room config indicate that the room is (can be) mirrored? - does the mirror room config indicate what the source room is? - can mirror rooms themselves be mirrored? (ick) - do / can mirror rooms / services communicate with each other? - does the mirror room wait for presence fan-out from the source room before sending presence to far users? - does or should the mirror room include delayed delivery info in the messages that it sends to far users? - can the source service explicitly request that the mirror service shall mirror a particular room (as in XEP-0281)? probably not needed, but good to make it clear - what happens if a near user tries to join a mirror room? is that user redirected from the mirror room to the source room? - can a far user join the source room directly? can the source room redirect a far user to the mirror room (as in XEP-0281)? - we need to show examples of room joins from far users other than the first one -- in particular, I would assume that the source room sends only one presence notification to the mirror room, which is then fanned out to all of the far users - can / should the mirror room assume the equivalent of nomirror for the presence of near and far users? that would save quite a bit of bandwidth - I'm not really convinced about nomirror for messages, but I am open to being convinced - example 2 seems strange, because the 'from' address is the room JID of the mirror room, not the occupant JID of the far user -- note that in example 5 the source room seems to know the occupant JID of the far user in the mirror room, but currently there's no way for it to know that! - must the far user's roomnick be the same in the source room and the mirror room? - what error would the source room return to the mirror room on join if the mirroring service is not trusted? (a rogue mirroring service could simply include the MUC namespace and thus join as a normal occupant, instead of including the special mirroring extension -- that's something for the security considerations) - what error or status notification would the mirror room return to the far user if s2s is down? would it return any status at all? - I don't mind the JID\20Escaping stuff for room names, but I suppose others might consider it ugly Kev, I'd be happy to work with you on improving XEP-0289. Peter -- Peter Saint-Andre https://stpeter.im/
[Standards] Obsoleting XEP-0237: Roster Versioning
At the XMPP Summit just now, Florian Zeitz and Jonathan Schleifer pointed out that XEP-0237 has actually been obsoleted by RFC 6121, so I think we should make that official. Something to add to the Council agenda. /psa
Re: [Standards] UPDATED: XEP-0300 (Use of Cryptographic Hash Functions in XMPP)
Waqas, I've incorporated all of your feedback into the spec, and will check it with my co-authors here at the XMPP Summit before pushing out a revision. On Fri, Dec 09, 2011 at 01:38:12AM +0500, Waqas Hussain wrote: On Tue, Dec 6, 2011 at 3:32 AM, Peter Saint-Andre stpe...@stpeter.im wrote: On 12/5/11 3:16 PM, XMPP Extensions Editor wrote: Version 0.2 of XEP-0300 (Use of Cryptographic Hash Functions in XMPP) has been released. Abstract: This document provides recommendations for the use of cryptographic hash functions in XMPP protocol extensions. Changelog: Updated to reflect initial analysis of existing XMPP protocol extensions. (psa) Diff: http://xmpp.org/extensions/diff/api/xep/0300/diff/0.1/vs/0.2 URL: http://xmpp.org/extensions/xep-0300.html Folks, I started to look at XEP-0300 in relation to existing extensions. Please review my work so far, and do your own thinking about how useful (or not useful) XEP-0300 is. I'm curious about the descriptive feature namespaces (urn:xmpp:hash-function-textual-names:md5)... I'm sure there is something behind not using urn:xmpp:hash:md5, or similar :) Also, the encapsulating hashes xmlns='urn:xmpp:hashes:0'/ element isn't really necessary, except for cases where only a single element is allowed (pubsub). I recall we were measuring bytes when defining entity caps in presence, which would suggest changing this protocol to more compact. A consistent approach to hashes is a good thing. Changing widely deployed protocols is a bad thing. The nature of the XEP makes it awkward to use in many protocols (as noted at the end of this message). I'm -0 on this XEP. Of the XEPs listed in XEP-0300 section 4.5, the widely deployed protocols are entity caps, vcard based avatars, and socks5 bytestreams. BOSH is widely deployed, but I don't think the hashing part is. I'd suggest leaving vCard based avatars alone. Entity caps is arguably supposed to change, due to security issues. I'm not sure about the SOCKS5 XEPs. They are quite widely deployed, and if we do change things, backwards compatibility will need to be kept. That said, changing things in these various protocols would be fairly awkward, given the existing use of attributes for hashes. e.g., it would be fairly awkward to change the BOSH 'key' and 'newkey' attribute to elements in body/. -- Waqas Hussain --
Re: [Standards] NEW: XEP-0309 (Service Directories)
On 1/14/12 3:20 PM, Waqas Hussain wrote: On Wed, Jan 11, 2012 at 12:36 AM, XMPP Extensions Editor edi...@xmpp.org wrote: Version 0.1 of XEP-0309 (Service Directories) has been released. Abstract: This specification shows how to combine and extend a number of existing XMPP protocols for improved sharing of information about XMPP servers. Changelog: Initial published version. (psa) Diff: N/A URL: http://xmpp.org/extensions/xep-0309.html http://code.google.com/p/prosody-modules/source/browse/mod_service_directories/mod_service_directories.lua This is a work in progress implementation, is mostly untested, and will contain bugs. Testers appreciated. Both the directory and normal server side of the protocol are implemented. Missing features: - More complete pubsub support (currently only supports getting all items) - Persistence (all data is currently kept in memory) This module does not serve vcard4 queries (that would be part of mod_vcard in Prosody trunk). Thanks, Waqas. I'll read that on the flight to Brussels tomorrow. I hope to install it at xmpp.net soon. :) Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Comments on XEP-45 1.25rc12
On 1/31/12 5:57 PM, Florian Zeitz wrote: Hi everyone, someone just pointed out to me that the current revision of XEP-45 prescribes JIDs to modify the moderator list. This seemed quite strange to me, and after examining 1.25rc12 it seems this was fixed in example 148 in section 9.8. In fact, I think we didn't touch that text at all in the revision process, because it's the same in 1.24. Compare the following two URLs side by side: http://xmpp.org/extensions/xep-0045.html#modifymod http://xmpp.org/extensions/tmp/xep-0045-1.25.html#modifymod However, the accompanying text was not adapted. I hope/think that is an oversight that should be fixed. It might be something that we want to fix, but we didn't change it so far. I think it should read: «In order to do so, the admin MUST send the changed items (i.e., only the delta) back to the service; each item MUST include the 'nick' attribute and 'role' attribute (set to a value of moderator to grant moderator status or participant to revoke moderator status) but SHOULD NOT include the 'jid' attribute and MUST NOT include the 'affiliation' attribute (which is used to manage affiliations such as admin rather than the moderator role):» I'd be fine with that, but I'd also like to see more discussion before we change it in the spec. Also in 15.5.3 « field var='muc#roomconfig_allowinvites' type='boolean' label='Roles that May Send Private Messages'/ field var='muc#roomconfig_allowpm' type='list-single' label='Whether to Allow Occupants to Invite Others'/ » seem to have the labels switched around. Additionally I think muc#roomconfig_allowpm should be a list-multi. Fixed in my working copy. Thanks for the feedback! Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Comments on XEP-45 1.25rc12
On 1/31/12 6:29 PM, Florian Zeitz wrote: Am 01.02.2012 02:20, schrieb Peter Saint-Andre: On 1/31/12 5:57 PM, Florian Zeitz wrote: Hi everyone, someone just pointed out to me that the current revision of XEP-45 prescribes JIDs to modify the moderator list. This seemed quite strange to me, and after examining 1.25rc12 it seems this was fixed in example 148 in section 9.8. In fact, I think we didn't touch that text at all in the revision process, because it's the same in 1.24. Compare the following two URLs side by side: http://xmpp.org/extensions/xep-0045.html#modifymod http://xmpp.org/extensions/tmp/xep-0045-1.25.html#modifymod Right, as I said the text is unchanged, the example (138 in the former 148 in the later) however is. I think it should read: «In order to do so, the admin MUST send the changed items (i.e., only the delta) back to the service; each item MUST include the 'nick' attribute and 'role' attribute (set to a value of moderator to grant moderator status or participant to revoke moderator status) but SHOULD NOT include the 'jid' attribute and MUST NOT include the 'affiliation' attribute (which is used to manage affiliations such as admin rather than the moderator role):» I'd be fine with that, but I'd also like to see more discussion before we change it in the spec. I'd be surprised if this was more than correctly documenting the status quo, because I doubt implementations special case this particular role change, however if someone disagrees I'd certainly like to hear that. Ah, now I see that you are right: we fixed the example (now 148, then 138) but did not update the text. Your proposed text is fine with me, thanks for sending it! Peter -- Peter Saint-Andre https://stpeter.im/
[Standards] Call for Experience: Advancement of XEP-0047 (In-Band Bytestreams) to Final
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At its meeting on December 20, 2011, the XMPP Council agreed to issue a Call for Experience regarding XEP-0047 (In-Band Bytestreams), in preparation for perhaps advancing this specification from Draft to Final in the XSF's standards process. To help the Council decide whether this XEP is ready to advance to a status of Final, the Council would like to gather the following information: 1. What software has implemented XEP-0047? Please note that the protocol must be implemented in at least two separate codebases (and preferably more). 2. Have developers experienced any problems with the protocol as defined in XEP-0047? If so, please describe the problems and, if possible, suggested solutions. 3. Is the text of XEP-0047 clear and unambiguous? Are more examples needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have developers found the text confusing at all? Please describe any suggestions you have for improving the text. If you have any comments about advancing XEP-0047 from Draft to Final, please provide them by the close of business on Friday, February 24, 2012. After the Call for Experience, this XEP might undergo revisions to address feedback received, after which it will be presented to the XMPP Council for voting to a status of Final. You can review the specification here: http://www.xmpp.org/extensions/xep-0047.html Please send all feedback to the standards@xmpp.org discussion list. Thanks! 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/ iEYEARECAAYFAk8nH7UACgkQNL8k5A2w/vzSQwCffoBBmDnr+jJ3aOqrS6LF89AN WpwAnA+1oPOYJ79N1NkK+1cd9dNu1HhL =ld4P -END PGP SIGNATURE-
Re: [Standards] Jingle specification bug - missing error condition
On 1/26/12 4:53 AM, Ben Langfeld wrote: Gentlemen, I believe I have found a minor bug in XEP-0166, as follows: 1) An example states that a security-required/ error element be included in a response, qualified by the urn:xmpp:jingle:errors:1 namespace: http://gitorious.org/xmpp/xmpp/blobs/master/extensions/xep-0166.xml#line1399 2) The table of error conditions does not include security-required/: http://gitorious.org/xmpp/xmpp/blobs/master/extensions/xep-0166.xml#line1415 3) The schema does not include security-required/: http://gitorious.org/xmpp/xmpp/blobs/master/extensions/xep-0166.xml#line1724 I am unsure if it is the schema or the example which is correct. If someone can nudge me in the right direction, I can get a patch submitted today. Thanks for the bug report. I think that was an oversight in the table and schema, but I'll double-check and post again. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0045 1.25rc10 comments
On 1/25/12 4:04 PM, Peter Saint-Andre wrote: It may make sense to extend 210 to (2) and (3). That's the path I took based on your feedback (however, I notice that I didn't add anything about status code 210 to the section on user-requested nick changes, which is another time when the service might modify the user's nick). Actually there is an example of that and some associated text, but I didn't see it on a quick review. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0045 1.25rc10 comments
Snipping areas of agreement... On 1/24/12 2:14 AM, Kevin Smith wrote: On Mon, Jan 23, 2012 at 11:46 PM, Peter Saint-Andre stpe...@stpeter.im wrote: On 1/19/12 7:49 AM, Kevin Smith wrote: Some comments, a couple of which predate the patch but most of which are a consequence of it: Redefining the meaning of 'room JID' seems unwise at this stage See other message in this thread. Ok. I note that, given the existing body of code, literature and experience, changing this now is somewhere between ineffective (if people continue to use room JID) and confusing. But I won't block on it if everyone else thinks it's an improvement. I think it's an improvement, and a much less significant change than node = localpart. Table 5: Role State Chart and supporting text - could do with tidying up a little - I think we've discussed this previously. It's ok for an owner to kick an admin (and probably an admin to kick an admin, or an owner an owner), but not an admin kick an owner. Isn't that what this proviso text is all about, right after the table? * A moderator MUST NOT be able to revoke moderator status from an occupant who is equal to or above the moderator in the hierarchy of affiliations. I think that owners not being able to kick owners is largely pointless (as they could just demote them first and then kick them), but ok. Indeed it probably is useless, but it's always been useless. :) The concern is more about a non-admin moderator (which is allowed, since moderator is a role) kicking an admin or owner. not the nick (and thus implicitly the full JID) as with roles. - isn't right, it's the nick, not the user's full JID, that defines roles (the user may have multiple full JIDs with the same nick) - so I think the parenthesised bit should go. But a nick is associated with a full JID. The point of the parenthical remark is to remind the reader that a role is *not* associated with a bare JID. (Thus implicitly.) A nick *isn't* associated with a single full JID, it's associated with a set of full JIDs - all those sharing the nick in the room. It's not associated with a bare JID, either, as there may be multiple nicks with same bare JID in the room. I thought we agreed to define that multi-JID support in a separate spec? (s/one result may be that/ e.g./, the user's nickname is reserved in the room). - I don't like this change, it implies membership always reserves the nick. *** First, it's a MAY, i.e., OPTIONAL for a server to support, so always is incorrect. Second, this was intended as something that a server might do (it's not even an all-caps MAY), so I suggest changing may to might. The full paragraph was: The member affiliation provides a way for a room owner or admin to specify a whitelist of users who are allowed to enter a members-only room. When a member enters a members-only room, his or her affiliation does not change, no matter what his or her role is. The member affiliation also provides a way for users to register with an open room and thus be lastingly associated with that room in some way (e.g., the user's nickname is reserved in the room). My concern is that the e.g. isn't clear (to me) whether it is giving an example of one way a service might make registered users lastingly associated with the room, or whether it's saying that it is an example of one of the things that does happen when you register with a room. So the previous text of one result may be that seemed less ambiguous to me. I'm not seeing a big difference here, but in my working copy I've changed it to: one result might be that the service could reserve the user's nickname in the room ** An admin or owner MUST NOT be able to revoke moderation privileges moderator status from another admin or owner. - This is somewhat silly [and always has been] and leads to the 'owner removes admin state, removes moderator state, kicks, promotes back to admin' dance. Yes, it's always been a bit silly. Probably we were paranoid about room takeovers at the time we wrote that text. Suggested fix? A moderator SHOULD NOT be able to revoke moderation privileges from someone with a higher affiliation them themselves (i.e. an unaffiliated moderator may not remove moderation privileges from an admin or owner, and an admin may not from an owner ? With minor edits, changed in my working copy to: A moderator SHOULD NOT be allowed to revoke moderation privileges from someone with a higher affiliation than themselves (i.e., an unaffiliated moderator SHOULD NOT be allowed to revoke moderation privileges from an admin or an owner, and an admin SHOULD NOT be allowed to revoke moderation privileges from an owner). The room SHOULD also reflect the original 'id' value, if provided in the presence stanza sent by the user. - this is a significant change, is it necessary? ** How many clients include IDs in presence/ notifications? Few or none, I
[Standards] registration policies in XEP-0309
In XEP-0309, I have a vCard slot for a registration URI: registration xmlns='urn:xmpp:vcard:registration' urlhttps://register.jabber.org//url /registration (Yes, it should be uri, not url.) In essence I (as someone running a server directory) would like a way to capture the server's registration policy in the contact vCard. This helps those who use the directory information (e.g., clients) to do things like show a drop-down menu of servers that allow an end user to register in-band (note that support for jabber:iq:register does not necessarily imply that the server allows in-band registration, since the server might allow password changes but not registration). Here's one possible way to do it: 1. If in-band registration is supported, include the XMPP URI of the server itself: registration xmlns='urn:xmpp:vcard:registration' urixmpp:example.com/uri /registration 2. If out-of-band registration is supported, include the appropriate URI (typically HTTPS): registration xmlns='urn:xmpp:vcard:registration' urihttps://register.example.org//uri /registration 3. If no registration is supported (e.g., enterprise deployment), don't include the registration/ element. There might be more elegant ways to do it, but this one seems acceptable to me. Feedback is welcome. :) Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0045 1.25rc10 comments
On 1/24/12 11:14 AM, Peter Saint-Andre wrote: After jabbering with Kev for a bit, here's a follow-up on the status code 210 issue (originally raised by Waqas Hussain). If the user's nickname is modified by the service as a result of registration and the user is in the room, the service SHOULD include status code 210 in the updated presence notification that it sends to all users. - this is new, I think, couldn't it break things? *** In what way does that break things? Prior to this change, 210 could only be received on 'your own' stanzas, so it's been reasonable for clients/libs to assume any time it sees 210 it's receiving its own stanza (and, given that servers tend to only send one status code at a time (to work around buggy clients), this is probably a sensible thing to do). If clients start receiving 210 from other people, I think it's entirely likely that things will break. But we have a separate status code (110) for self-presence. First, I found the original message from Waqas: http://mail.jabber.org/pipermail/standards/2011-September/025183.html He wrote: ### 3. Service changing room nick I'd like some text stating that a service can change the occupant's nick at any time, including room join. An occupant MUST listen for status code=100 in available presence for their current nick. ### I think Waqas meant that the client needs to listen for status code 110 (self-presence) plus 210 (nick changed) but I'm not sure. Waqas, please confirm. Via IM, Kev pointed out that this should be for self-presence only. I think he's right about that, so one of the paragraphs currently in the working version is wrong (right after Example 76): If the user's nickname is modified by the service as a result of registration and the user is in the room, the service SHOULD include status code 210 in the updated presence notification that it sends to all users. I think the other instances are correct (after Examples 23 and 50 respectively): If the user has connected using a MUC client (as indicated on joining the room by inclusino of the MUC extension), then the service MUST include a status code of 210 in the presence broadcast that it sends to the new occupant. and: If the service modifies the user's nickname in accordance with local service policies, it MUST include a MUC status code of 210 in the presence stanza sent to the user. An example follows (here the service changes the nickname to all lowercase). See Example 51: Example 51. Occupant Changes Nickname, Modified by Service presence from='ha...@shakespeare.lit/pda' id='nx6z2v5' to='co...@chat.shakespeare.lit/OldHag'/ presence from='co...@chat.shakespeare.lit/oldhag' id='D0E2B666-3373-42C9-B726-D52C40A48383' to='ha...@shakespeare.lit/pda' x xmlns='http://jabber.org/protocol/muc#user' item affiliation='member' jid='ha...@shakespeare.lit/pda' role='participant'/ status code='110'/ status code='210'/ /x /presence So I propose that we fix the text after Example 76: OLD If the user's nickname is modified by the service as a result of registration and the user is in the room, the service SHOULD include status code 210 in the updated presence notification that it sends to all users. NEW If the user's nickname is modified by the service as a result of registration and the user is in the room, the service SHOULD include status code 210 in the updated presence notification that it sends to the user. Now, Kev raised another issue, which is that some clients don't properly handle presence updates with more than one status code (e.g., they might read only the first status code). My reply to that is: fix your client or file a bug report. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0045 1.25rc10 comments
On 1/24/12 2:22 PM, Kevin Smith wrote: On Tue, Jan 24, 2012 at 6:14 PM, Peter Saint-Andre stpe...@stpeter.im wrote: Snipping areas of agreement... On 1/24/12 2:14 AM, Kevin Smith wrote: not the nick (and thus implicitly the full JID) as with roles. - isn't right, it's the nick, not the user's full JID, that defines roles (the user may have multiple full JIDs with the same nick) - so I think the parenthesised bit should go. But a nick is associated with a full JID. The point of the parenthical remark is to remind the reader that a role is *not* associated with a bare JID. (Thus implicitly.) A nick *isn't* associated with a single full JID, it's associated with a set of full JIDs - all those sharing the nick in the room. It's not associated with a bare JID, either, as there may be multiple nicks with same bare JID in the room. I thought we agreed to define that multi-JID support in a separate spec? We did, I just think having that parenthesised text (and thus implicitly the full JID) confuses things, given that (whichever spec it's documented in) MUC sharing is increasingly well deployed. But this is minor, I don't think it's worth spending more time on. Y'know, you're right. I've removed that parenthetical remark. See other message about the status code 210 issue... /psa
Re: [Standards] XEP-0045 1.25rc10 comments
On 1/24/12 2:53 PM, Kevin Smith wrote: On Tue, Jan 24, 2012 at 9:26 PM, Peter Saint-Andre stpe...@stpeter.im wrote: On 1/24/12 11:14 AM, Peter Saint-Andre wrote: After jabbering with Kev for a bit, here's a follow-up on the status code 210 issue (originally raised by Waqas Hussain). I think Waqas meant that the client needs to listen for status code 110 (self-presence) plus 210 (nick changed) but I'm not sure. Waqas, please confirm. Aside: In fact, 210 is completely redundant, as if you receive a 110 from a nick that wasn't what you expected, you know your nick has been changed, but this isn't relevant here. Via IM, Kev pointed out that this should be for self-presence only. I think he's right about that, so one of the paragraphs currently in the working version is wrong (right after Example 76): If the user's nickname is modified by the service as a result of registration and the user is in the room, the service SHOULD include status code 210 in the updated presence notification that it sends to all users. This was my complaint. Sorry if I was unclear and seemed to be complaining about the other uses. So I propose that we fix the text after Example 76: OLD If the user's nickname is modified by the service as a result of registration and the user is in the room, the service SHOULD include status code 210 in the updated presence notification that it sends to all users. NEW If the user's nickname is modified by the service as a result of registration and the user is in the room, the service SHOULD include status code 210 in the updated presence notification that it sends to the user. +1 OK, I've checked a new version into source control: http://xmpp.org/extensions/tmp/xep-0045-1.25.html http://xmpp.org/extensions/diff/api/xep/0045/diff/1.25rc11/vs/1.25rc12 /psa
Re: [Standards] XEP-0045 1.25rc10 comments
On 1/19/12 8:11 AM, Ralph Meijer wrote: On 2012-01-19 15:49 , Kevin Smith wrote: Redefining the meaning of 'room JID' seems unwise at this stage (especially as it seems we then continue to use the current meaning elsewhere in the document). *** The previous naming was very confusing. The 'Room JID' should be the JID that represents the room itself, without the resource part. Having a new 'Occupant JID' to denote the entity's JID within the room (i.e. Room JID + nick as resource) is very much clearer, to me. Clarity was the point of that change. When working on the MUC client implementation in Wokkel, I was now able to use consistent names for variables matching these terms. This made it so much more readable. If the renaming hasn't been done consistently throughout XEP-0045, that should obviously be addressed. Perhaps even the spec author got confused! I've just double-checked all instances and it does seem that I did not make this change consistently throughout the document. Fixed in my working copy. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0045 1.25rc10 comments
MUST send all discussion history messages before delivering the room subject and any live messages sent after the user enters the room. However, I append sentence to the latter paragraph: The service MUST send all discussion history messages before delivering the room subject and any live messages sent after the user enters the room. Note well that this means the room subject (and changes to the room subject prior to the current subject) are not part of the discussion history. 7.4 - MAY return an error if you can't send - why not MUST? Yeah, I think MUST is better here. I can't recall why we said it was MAY. 1:1 conversion-MUC conversion: it's not a change, but I object to normative language on the UI here. Sure. I've cleaned that up in my working copy. If the user's nickname is modified by the service as a result of registration and the user is in the room, the service SHOULD include status code 210 in the updated presence notification that it sends to all users. - this is new, I think, couldn't it break things? *** In what way does that break things? The current published version (1.24) has: The service MAY rewrite the new occupant's roomnick (e.g., if roomnicks are locked down). If the service does not accept the new occupant's requested roomnick but instead assigns a new roomnick, it MUST include a status code of 210 in the presence broadcast that it sends to the new occupant. Waqas Hussain (IIRC) pointed out that this code was not sent in other cases where the roomnick might be changed on the server side, so for the sake of consistency I added text about that. If the removed member is not currently in the room, the service SHOULD send a message to the user's bare JID indicating the change in affiliation. - I don't understand where this came from or what it achieves - clients can't rely upon receiving such a message (and I don't think examples are given). It also seems to be an interesting spam angle. I note we've removed the equivalent bit about losing ownership. *** I have no problem with removing that text and have done so in my working copy, although I rather doubt that it's a significant spam angle because it needs to be triggered by the room owner or admin. With my Council hat on, *** are the things that I'd like to see changed before publishing or at least for me to be shouted down on (i.e. at least discussed and consensus reached). See discussion above. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0045 1.25rc10 comments
snip/ For ease of tracking, I've checked in my working copy as 1.25rc11... http://xmpp.org/extensions/tmp/xep-0045-1.25.html http://xmpp.org/extensions/diff/api/xep/0045/diff/1.25rc10/vs/1.25rc11 /psa
[Standards] Fwd: [Summit] deadline for FOSDEM talks
FYI. Original Message Subject: [Summit] deadline for FOSDEM talks Date: Wed, 11 Jan 2012 10:31:27 -0700 From: Peter Saint-Andre stpe...@stpeter.im Reply-To: XMPP Summit sum...@xmpp.org To: XMPP Summit sum...@xmpp.org If you'd like to give a talk in the XMPP devroom at FOSDEM 2012, please post to sum...@xmpp.org by the end of this week, because we need to send the list of talks to the FOSDEM organizers on January 15th. Thanks! http://mail.jabber.org/mailman/listinfo/summit Peter -- Peter Saint-Andre http://stpeter.im/ ___ Summit mailing list Event: http://xmpp.org/participate/the-xmpp-summit/xmpp-summit-10/ Info: http://mail.jabber.org/mailman/listinfo/summit Unsubscribe: summit-unsubscr...@xmpp.org ___
[Standards] Fwd: [Summit] Brussels discussion topics
FYI regarding the upcoming meetings in Brussels. Please join the sum...@xmpp.org list to discuss: http://mail.jabber.org/mailman/listinfo/summit Original Message Subject: [Summit] Brussels discussion topics Date: Mon, 09 Jan 2012 13:16:57 -0700 From: Peter Saint-Andre stpe...@stpeter.im Reply-To: XMPP Summit sum...@xmpp.org To: XMPP Summit sum...@xmpp.org What technical topics would folks like to discuss at the XMPP Summit next month? Here are some possibilities: * internationalization (rfc6122bis) * end-to-end encryption (rfc3923bis) * cryptographic hash agility (XEP-0300) * message carbons (XEP-0280) * Jingle file transfer (XEP-0234) * vCard4 (XEP-0292) * fast reconnect (XEP-0305) * message forwarding (XEP-0297) * real-time text (XEP-0301) * distributed chatrooms I've added those here: http://wiki.xmpp.org/web/Summit_11 Feel free to bring up other topics here or on the wiki so that we can formulate an agenda. Lightning-style or longer talks are also welcome on Friday February 3rd or Monday February 6th. And we are still looking to fill out the devroom schedule on Saturday at FOSDEM: http://wiki.xmpp.org/web/FOSDEM_2012 Peter -- Peter Saint-Andre http://stpeter.im/ ___ Summit mailing list Event: http://xmpp.org/participate/the-xmpp-summit/xmpp-summit-10/ Info: http://mail.jabber.org/mailman/listinfo/summit Unsubscribe: summit-unsubscr...@xmpp.org ___
[Standards] service directories
I've updated the Network Information Sharing (and renamed it) to include a scenario about publishing such data, too: http://xmpp.org/extensions/inbox/network.html Continued feedback is welcome. Peter -- Peter Saint-Andre http://stpeter.im/
Re: [Standards] service directories
On 1/9/12 2:23 PM, Peter Saint-Andre wrote: I've updated the Network Information Sharing (and renamed it) to include a scenario about publishing such data, too: http://xmpp.org/extensions/inbox/network.html I just pushed out version 0.0.3, adding an ad-hoc command for triggering the presence subscription from the server. Peter -- Peter Saint-Andre http://stpeter.im/
Re: [Standards] typos in RFC6120 and XEP-220
Noted. Thanks for the bug reports! On 1/4/12 6:18 AM, Nobuo Ogashiwa wrote: Dear all, I found some typos in RFC6120 and XEP-220. In RFC6120, I think that the word 'FDQN' should be 'FQDN'. 3. If a response is received, it will contain one or more combinations of a port and FDQN, each of which is weighted and prioritized as described in [DNS-SRV]. (However, if the result of the SRV lookup is a single resource record with a Target of ., i.e., the root domain, then the initiating entity MUST abort SRV processing at this point because according to [DNS-SRV] such a Target means that the service is decidedly not available at this domain.) 4. The initiating entity chooses at least one of the returned FQDNs to resolve (following the rules in [DNS-SRV]), which it does by performing DNS A or lookups on the FDQN; this will result in an IPv4 or IPv6 address. 5. The initiating entity uses the IP address(es) from the successfully resolved FDQN (with the corresponding port number returned by the SRV lookup) as the connection address for the receiving entity. Saint-Andre Standards Track [Page 17] RFC 6120XMPP Core March 2011 6. If the initiating entity fails to connect using that IP address but the A or lookups returned more than one IP address, then the initiating entity uses the next resolved IP address for that FDQN as the connection address. 7. If the initiating entity fails to connect using all resolved IP addresses for a given FDQN, then it repeats the process of resolution and connection for the next FQDN returned by the SRV lookup based on the priority and weight as defined in [DNS-SRV]. In XEP-220's Example 14, I think that /db:result should be /db:verify. send: db:verify from='sender.tld' id='D6229F' to='target.tld' type='error' error type='cancel' item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/ /error /db:result Regards, Nobuo Ogashiwa JID: ogash...@c.kyoai.ac.jp, ogash...@nlab.im Web: http://nlab.jp/xmpp/
Re: [Standards] XMPP logo licensing
On 12/29/11 8:22 PM, Ludovic BOCQUET wrote: Le 09/12/2011 20:39, Peter Saint-Andre a écrit : On 12/6/11 11:16 AM, Filipus Klutiero wrote: Le 2011-12-06 12:22, Peter Saint-Andre a écrit : On 12/6/11 10:18 AM, Filipus Klutiero wrote: Le 2011-12-06 10:13, Peter Saint-Andre a écrit : On 12/6/11 6:34 AM, Kim Alvefur wrote: On Tue, 2011-12-06 at 01:50 -0500, Filipus Klutiero wrote: Hi, is XMPP's logo licensed? Apparently a free license would help including it on Wikipedia ( http://fr.wikipedia.org/wiki/Fichier:Logo_XMPP.svg ). This page[1] it's designed by this designer[2], who has a BY-NC-ND badge at the bottom of the page. I don't know if that means that license applies to all logos or just the site. [1]: http://xmpp.org/about-xmpp/xsf/website-credits/ [2]: http://www.rajasandhu.com/ The whole xmpp.org website (including the logo) is under a slightly modified MIT license. The licensing used by the logo designer is irrelevant, since the XSF paid for the logo and can put it under whatever license it prefers. Peter Great, thanks Is there a page on the website that states the website is under a license, or some other official offer of the logo which someone could check to verify its license? http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/ If desired we can add a clarifying note about non-XEP files on the site. Peter The XSF IPR Policy says: This document defines the official policy of the XMPP Standards Foundation regarding intellectual property rights (IPR) pertaining to XMPP Extension Protocol specifications (XEPs). If that page is intended to licence something other than XEPs, I would say that is more than unclear. Please do let me know if a licence statement on the website or on the logo exists or is added. Yes, I'll add something soon and post back to the list. Peter Have you news about this? Because I already spoke with you about this, there is a long time ago... Yeah, last week or the week before I added a copyright notice at the bottom of every page on xmpp.org. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Any JID domain register.
On 12/19/11 3:16 AM, Sven-Erik Tiberg wrote: Are there listing server to lookup / register any Jabber Domains. You mean like http://www.jabberes.org/servers/ and http://xmpp.org/resources/public-services/ ? Or name standard suggestion to set new Jabber Domains / Virtual Hosts. If you will run your owner server, you can call it whatever you'd like. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0077: disco feature
For review... On 12/13/11 4:54 PM, Peter Saint-Andre wrote: On 12/13/11 10:21 AM, Matthew Wild wrote: On 13 December 2011 17:01, Peter Saint-Andre stpe...@stpeter.im wrote: On 12/13/11 8:48 AM, Peter Saint-Andre wrote: On 12/12/11 1:52 PM, Kim Alvefur wrote: On Mon, 2011-12-12 at 12:43 -0700, Peter Saint-Andre wrote: XEP-0077 (In-Band Registration) does not define a disco feature for advertising support for jabber:iq:register. I have a use case in which this would be very handy. I'm pretty sure this is already standard practice for at least gateways, despite lack of a defined feature. Any concerns about adding this to XEP-0077? +1 OK, I'll generate a slight update to XEP-0077 in time for the next meeting of the XMPP Council. http://xmpp.org/extensions/diff/api/xep/0077/diff/2.3/vs/2.4rc1 http://xmpp.org/extensions/tmp/xep-0077-2.4.html Peter -- Peter Saint-Andre https://stpeter.im/
[Standards] for review: XEP-0045 1.25rc9
The latest diff is here: http://xmpp.org/extensions/diff/api/xep/0045/diff/1.25rc8/vs/1.25rc9 The diff from 1.24 is here: http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc9 The rendered copy is here: http://xmpp.org/extensions/tmp/xep-0045-1.25.html I'm hoping that we can wrap this up early in the new year so that I can move on to cleaning up XEP-0060. :) Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Use of Message Forwarding in other XEPs
On 12/15/11 10:22 AM, Matthew Wild wrote: On 15 December 2011 15:27, Matthew A. Miller linuxw...@outer-planes.net wrote: On Nov 1, 2011, at 15:36, Kim Alvefur wrote: Hi! I've noted that Message Forwarding [XEP-0297] doesn't give any recommendations for how (or if) you should indicate to which extension it belongs. Is this something that would be desirable? Currently Message Carbons [XEP-0297] has what can be seen as an indicator inside the forwarded/ element[1]. Would it be better or worse to, let's say, have this as a child of the parent message/? 1: http://xmpp.org/extensions/xep-0280.html#example-13 To be honest, I don't remember why I chose to put the indicators as children of the forwarded/ instead of as siblings. I can see either pattern making sense, and am happy to change XEP-0280 if the current pattern is too strange. Maybe one of XEP-0297's authors can comment on this? I'm inclined to say it should be a sibling. When you consider how an application is going to sensibly handle this, it's going to first want to categorize it as a carbons message before extracting the message contents from forwarded/. Partly the principle is that you can judge a message type by the namespaces of its immediate children. Shades of XEP-0226, eh? http://xmpp.org/extensions/xep-0226.html Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] SASL + OAuth
On 12/8/11 3:36 PM, Peter Saint-Andre wrote: Have any server or client developers here considered adding support for the emerging SASL mechanism for OAuth? http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth That would seem to open up some interesting authentication possibilities (e.g., integration with various web apps)... Potentially more motivation: OAuth2 is used in the XMPP implementation of Windows Live... http://the.taoofmac.com/space/links/2011/12/15/0856 /psa
Re: [Standards] RFC 6121, Sec 3.1, 3.2, and 4.3.2
Sorry about the delayed reply... On 11/15/11 11:22 AM, Dave Richards wrote: Am I missing something or is there a bit of a hole in these sections regarding denying a subscription? In 3.1.2 (subscription request outbound), the user's server pushes a roster entry containing the potential contact with a subscription state of none and with notation that the subscription is pending. In 3.2.3 (subscription cancellation inbound), the user's server is supposed to ignore the subscription cancellation unless the contact is in the user's roster with subscription='to' or subscription='both' And a few lines later: Otherwise ... if the contact is in the user's roster with a subscription state other than those described in the foregoing check -- then the user's server MUST silently ignore the unsubscribed notification by not delivering it to the user, not modifying the user's roster, and not generating a roster push to the user's interested resources. Seems like a subscription denial/rejection would never get processed on the user side. 3.1.6 (subscription approval inbound) talks about subscription none/from with pending out, which seems should also be considered in 3.2.3. That does seem to be a bit a hole -- Section 3.2.3 should say mention the outbound pending case. I've made a note to fix that in 6121bis. In an unrelated issue, 4.3.2, #1 says to send unsubscribed if the contact account does not exist or the user's bare JID is in the contact's roster with a subscription state other than From, From + Pending Out, or Both. Seems like this should also be the case if the contact account exists but is not in the user's roster at all. All other roster states are covered by available/unavailable, so it seems lack of a response would indicate that the account at least exists, which might be considered leaking information, as well as leaving the user with apparently a dead to subscription to the contact. We kind of assume that not being in the roster is equivalent to being in the roster with a subscription state of None, but you're right that this too could use with some clarification in 6121bis. Thanks for the feedback! Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0306: MUC status codes
Done. Updated XEP to be published shortly... On 9/26/11 11:38 AM, Peter Saint-Andre wrote: After last week's XMPP Council meeting, a few folks had a discussion about MUC status codes (XEP-0306)... http://xmpp.org:5290/muc_log/muc.xmpp.org/council/110921/#16:22:29 Ralph Meijer's point was that it would be good to use the same kind of approach we followed for core stanza errors. So instead of what we have in XEP-0306 right now: presence from='co...@chat.shakespeare.lit/thirdwitch' id='n13mt3l' to='ha...@shakespeare.lit/pda' x xmlns='http://jabber.org/protocol/muc#user' item affiliation='member' role='participant'/ status code='100'/ status code='110'/ conditions xmlns='urn:xmpp:muc:conditions:0' realjid-public/ self-presence/ /conditions /x /presence We could define each new condition element as a child of the related status code: presence from='co...@chat.shakespeare.lit/thirdwitch' id='n13mt3l' to='ha...@shakespeare.lit/pda' x xmlns='http://jabber.org/protocol/muc#user' item affiliation='member' role='participant'/ status code='100' realjid-public xmlns='urn:xmpp:muc:conditions:0'/ /status status code='110' self-presence xmlns='urn:xmpp:muc:conditions:0'/ /status /x /presence This would enable us to eventually get rid of the 'code' attribute, just as we did for stanza errors. I rather like that idea so I plan to update XEP-0306 accordingly. (Dave Cridland brought up a separate issue, which is that many implementations don't support more than one status/ element in MUC presence, for example reading/showing only the first or the last instance. But that's a separate issue...) Peter
Re: [Standards] PubSub Collection Nodes (XEP-0248) question.
On 12/6/11 12:16 PM, Florent Le Coz wrote: I’m taking a closer look at this XEP because I’m wanting to write an XEP using Collection Nodes, and I have a question: Why are Collection nodes not allowed to contain items? I see many use-cases for it and it doesn’t really introduce any additional complexity: by doing a disco#items query on a collection node the service would just return all the children nodes AND items. Items and nodes can easily be distinguished by looking at the presence or not of the “node” attribute in each item elements returned. This would allow a lot of nice possibilities, like a graph of messages (similar to a newsgroup message thread, with any level of depth). Is there a reason why it is not allowed in the current state of the XEP? Perhaps because we haven't given it enough thought. Right now I can't quite remember why we did it this way, and I haven't had time to work on XEP-0248 in quite a while. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0077: disco feature
On 12/12/11 1:52 PM, Kim Alvefur wrote: On Mon, 2011-12-12 at 12:43 -0700, Peter Saint-Andre wrote: XEP-0077 (In-Band Registration) does not define a disco feature for advertising support for jabber:iq:register. I have a use case in which this would be very handy. I'm pretty sure this is already standard practice for at least gateways, despite lack of a defined feature. Any concerns about adding this to XEP-0077? +1 OK, I'll generate a slight update to XEP-0077 in time for the next meeting of the XMPP Council. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0077: disco feature
On 12/13/11 8:48 AM, Peter Saint-Andre wrote: On 12/12/11 1:52 PM, Kim Alvefur wrote: On Mon, 2011-12-12 at 12:43 -0700, Peter Saint-Andre wrote: XEP-0077 (In-Band Registration) does not define a disco feature for advertising support for jabber:iq:register. I have a use case in which this would be very handy. I'm pretty sure this is already standard practice for at least gateways, despite lack of a defined feature. Any concerns about adding this to XEP-0077? +1 OK, I'll generate a slight update to XEP-0077 in time for the next meeting of the XMPP Council. Hmm, here's a question: if an XMPP server advertises a service discovery feature of jabber:iq:register, is the server indicating that it supports in-band *registration* (as in, anyone can create an account using jabber:iq:register), in-band password changes, or both? I know that some servers allow password changes but not registration (depending on configuration). We might want to define a separate disco feature for password changes, leaving jabber:iq:register for the registration use case. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0077: disco feature
On 12/13/11 10:21 AM, Matthew Wild wrote: On 13 December 2011 17:01, Peter Saint-Andre stpe...@stpeter.im wrote: On 12/13/11 8:48 AM, Peter Saint-Andre wrote: On 12/12/11 1:52 PM, Kim Alvefur wrote: On Mon, 2011-12-12 at 12:43 -0700, Peter Saint-Andre wrote: XEP-0077 (In-Band Registration) does not define a disco feature for advertising support for jabber:iq:register. I have a use case in which this would be very handy. I'm pretty sure this is already standard practice for at least gateways, despite lack of a defined feature. Any concerns about adding this to XEP-0077? +1 OK, I'll generate a slight update to XEP-0077 in time for the next meeting of the XMPP Council. Hmm, here's a question: if an XMPP server advertises a service discovery feature of jabber:iq:register, is the server indicating that it supports in-band *registration* (as in, anyone can create an account using jabber:iq:register), in-band password changes, or both? I know that some servers allow password changes but not registration (depending on configuration). We might want to define a separate disco feature for password changes, leaving jabber:iq:register for the registration use case. Tricky I know, but as far as I'm concerned it's only saying it supports the protocol, not that changing the password is enabled or allowed for any particular user. Otherwise we would have to be delivering different disco features to different clients. Yeah, maybe I'm adding too much complexity to the problem. Advertising jabber:iq:register is probably enough. But: I'm interested because if we know which servers support in-band *registration* (as opposed to just password changes) then we can determine which servers to add to the list that gets downloaded by clients like Pidgin. /me ponders Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] when to stop send presences in case of from subscription?
On 12/12/11 1:43 AM, Sergey Dobrov wrote: On 12/12/2011 02:37 AM, Kevin Smith wrote: On Fri, Dec 9, 2011 at 12:15 PM, Sergey Dobrov bin...@jrudevels.org wrote: snip/ 9. How A's server can know that it don't have to send statuses to B anymore? It doesn't - it continues to send A's status to B whenever A changes it. (RFC6121, 4.4.2) /K Even if A will logged out and then again logged in? I mean, once sent probe presence will mean that A's presence will be sent forever till subscription is active? When A logs out, A's server sends unavailable presence and then there is no need for it to send presence to B until A logs in again. I think we might have a failure of communication here. Could you explain your question in a bit more detail? Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] UPDATED: XEP-0267 (Server Buddies)
On 12/10/11 2:18 AM, Kim Alvefur wrote: I had some thougts about using PEP in combination with this for sharing things like peer server certs seen, and incident reports. My current plan is to use this as the basis for automating data gathering for http://xmpp.org/resources/public-services/ (along with server vCards and disco features for I'm a public server and I support jabber:iq:register). More on that soon. :) But yes, once we have server buddies we can use PEP for some interesting features. /psa
[Standards] XEP-0077: disco feature
XEP-0077 (In-Band Registration) does not define a disco feature for advertising support for jabber:iq:register. I have a use case in which this would be very handy. Any concerns about adding this to XEP-0077? Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] UPDATED: XEP-0267 (Server Buddies)
On 12/12/11 2:10 PM, Kim Alvefur wrote: On Mon, 2011-12-12 at 20:36 +, XMPP Extensions Editor wrote: Changelog: Updated ad-hoc command with field for the sending server; added XMPP Registrar Considerations. (psa) What about the 'to' attribute of the iq/ ? I suppose that might do it...
Re: [Standards] Schemas in XEPs
If the content doesn't match the schema, they bounce the message with an error (or perhaps quarantine it somehow). These are military deployments in which they don't like to have rogue XML sent around. On 12/10/11 6:56 AM, Hannes Tschofenig wrote: Peter, provide more details. And, explain what you mean by schema checking? Ciao Hannes On Dec 9, 2011, at 8:10 PM, Peter Saint-Andre wrote: In addition, I know of at least one large deployment community that performs active schema-checking for XMPP traffic. Those folks would like it if our schemas were normative, I'd bet. :)
Re: [Standards] Schemas in XEPs
On 12/9/11 9:24 AM, Dave Cridland wrote: On Thu Dec 8 23:13:38 2011, Matthew A. Miller wrote: I'd like to point out that all of our XML Schemas are non-normative. They're provided for informational use, and ought not be considered the absolute record of authority. What follows is my understanding; we should probably have this documented somewhere (a Tao Of XSF XEP?): - The schemas in XEPs are not normative. - We do, however, try to keep them aligned properly with the text, and will accept bug reports with gratitude. - The schemas in RFCs *are* normative. - The IETF does, however, accept errata should they not match the text or the intent. So in both cases, we'd expect the schemas to be right, and welcome fixes; technically, though, there's a distinction in normativeness (normativity?) between RFC and XEP. RFC 6120 says: The following schemas formally define various namespaces used in this document, in conformance with [XML‑SCHEMA]. Because validation of XML streams and stanzas is optional, these schemas are not normative and are provided for descriptive purposes only. /psa
Re: [Standards] Schemas in XEPs
On 12/9/11 9:46 AM, Dave Cridland wrote: On Fri Dec 9 16:44:23 2011, Peter Saint-Andre wrote: On 12/9/11 9:24 AM, Dave Cridland wrote: On Thu Dec 8 23:13:38 2011, Matthew A. Miller wrote: I'd like to point out that all of our XML Schemas are non-normative. They're provided for informational use, and ought not be considered the absolute record of authority. What follows is my understanding; we should probably have this documented somewhere (a Tao Of XSF XEP?): - The schemas in XEPs are not normative. - We do, however, try to keep them aligned properly with the text, and will accept bug reports with gratitude. - The schemas in RFCs *are* normative. - The IETF does, however, accept errata should they not match the text or the intent. So in both cases, we'd expect the schemas to be right, and welcome fixes; technically, though, there's a distinction in normativeness (normativity?) between RFC and XEP. RFC 6120 says: The following schemas formally define various namespaces used in this document, in conformance with [XML‑SCHEMA]. Because validation of XML streams and stanzas is optional, these schemas are not normative and are provided for descriptive purposes only. I sit corrected - I'd assumed that the normal status quo of the IETF held with those. I don't think there is a normal status quo at the IETF regarding the normativity of schemas. Peter -- Peter Saint-Andre https://stpeter.im/
[Standards] Fwd: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt
FYI (this has an impact on XEP-0068). Original Message Subject: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt Date: Fri, 09 Dec 2011 17:19:10 + From: Alexey Melnikov alexey.melni...@isode.com To: apps-disc...@ietf.org apps-disc...@ietf.org Dear WG participant, I would like to initiate WGLC on draft-ietf-appsawg-xdash-02.txt. Due to holiday season the WGLC is going to be a long one and will end on January 6th. Please send any comments directly to the apps-discuss mailing list, or directly to editors of the draft and myself. Please send an email even if you reviewed the document and found no issues with it. Thank you, Alexey, as an APPSAWG co-chair. ___ apps-discuss mailing list apps-disc...@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss
Re: [Standards] Schemas in XEPs
On 12/9/11 11:05 AM, Bala Pitchandi wrote: I strongly disagree that XSD (RelaxNG or any other way of specifying the structure of the XML messages) is a waste of time. If you don't have a schema, you'll either end up implementing all the validation manually or worse crash on invalid input. XSD parser-validators (they exist) do all that work for you, and are optimized to do that. Without a schema, all we have is the text and examples which could be interpreted in many ways by how they are written and how they are understood by the reader. Requiring a schema also forces the XEP authors to think hard and come up with a design that's structured, extensible (Yes, XSD schemas can be made extensible). No argument here. In addition, I know of at least one large deployment community that performs active schema-checking for XMPP traffic. Those folks would like it if our schemas were normative, I'd bet. :) Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Schemas in XEPs
On 12/9/11 11:23 AM, Mike Wacker wrote: On 12/9/2011 9:49 AM, Dave Cridland wrote: On Fri Dec 9 17:35:47 2011, Hannes Tschofenig wrote: Over the time I have gotten the impression that an XML schema is really a waste of time. It creates the illusion that there is something that provides help (to implementers and to those who read the specification) but in reality it doesn't. Working on different specifications I later thought that the problem is with the readability and extensibility of the XML schema and then we switched to Relax NG in some IETF working groups. That turned to be a mistake as well. When it comes to extensibility a Relax NG schema is equally bad. The extensibility mechanism of XML would prevent you from getting any meaningful validation anyway. So, validation isn't useful because more or less everything validates (after you add the extension points everywhere). So, I believe we are doing fine without XML schema but with lots of examples. Implementers just look at examples. Maybe you could therefore recommend not to use XML schemas (or Relax NG schemas). Or at least move them out of the XEP itself, perhaps? I think we vaguely require them, at present. I'd be happy with hosting them out of the XEP itself, which'd make them more obviously informative. The XSF Board chair and the XMPP Council chair have been trying to figure out how we go about such a decision, and decided the best thing to do was seek consensus on the lists as a first step. Dave. Since I seemed to have re-opened this rather large can of worms, I'll offer my own thoughts. I have actually found the schemas to be useful, even though I understand their limitations. You just need to put their value in the proper context. And even though they are not normative, there is still some sort of normative constraint for the XML, and to some extent the schemas do capture that. Here's an example from XEP-0045, 6.4 Discovering Room Items: These item/ elements are qualified by the disco#items namespace, not the muc namespace; this means that they cannot possess 'affiliation' or 'role' attributes, for example. One direction we could go with the schemas is to build schemas that will not capture every normative constraint, but will catch most violations. Not all invalid XML would be rejected by the schema, but valid XML would never be rejected by the schema. This would assign some normative value to the schemas and help us from both a standards and interopability perspective. Yes, that all seems reasonable. However, there will always be some rules that schemas cannot cleanly capture, and for those people will still need to read the RFCs and XEPs. (However, the one major obstacle to that approach would be extension attributes [see RFC 6120, 8.4. Extended Content], though I don't know if there are any XEPs which actually use those.) So far we have avoided those almost entirely, although I started to consider them again when thinking about XEP-0300 recently. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XMPP logo licensing
On 12/6/11 11:16 AM, Filipus Klutiero wrote: Le 2011-12-06 12:22, Peter Saint-Andre a écrit : On 12/6/11 10:18 AM, Filipus Klutiero wrote: Le 2011-12-06 10:13, Peter Saint-Andre a écrit : On 12/6/11 6:34 AM, Kim Alvefur wrote: On Tue, 2011-12-06 at 01:50 -0500, Filipus Klutiero wrote: Hi, is XMPP's logo licensed? Apparently a free license would help including it on Wikipedia ( http://fr.wikipedia.org/wiki/Fichier:Logo_XMPP.svg ). This page[1] it's designed by this designer[2], who has a BY-NC-ND badge at the bottom of the page. I don't know if that means that license applies to all logos or just the site. [1]: http://xmpp.org/about-xmpp/xsf/website-credits/ [2]: http://www.rajasandhu.com/ The whole xmpp.org website (including the logo) is under a slightly modified MIT license. The licensing used by the logo designer is irrelevant, since the XSF paid for the logo and can put it under whatever license it prefers. Peter Great, thanks Is there a page on the website that states the website is under a license, or some other official offer of the logo which someone could check to verify its license? http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/ If desired we can add a clarifying note about non-XEP files on the site. Peter The XSF IPR Policy says: This document defines the official policy of the XMPP Standards Foundation regarding intellectual property rights (IPR) pertaining to XMPP Extension Protocol specifications (XEPs). If that page is intended to licence something other than XEPs, I would say that is more than unclear. Please do let me know if a licence statement on the website or on the logo exists or is added. Yes, I'll add something soon and post back to the list. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Proposed changes to XEP-0135
Jefry has sent me a patch. I'll work to process it soon. On 11/28/11 3:07 PM, Jefry Lagrange wrote: Thanks for your response. ;-) I'm not sure it's a good idea to overload the disco request this way. Perhaps having the filter in a separate namespace would be ok, but I think perhaps it would be better to use another protocol for this. Yeah, I wasn't sure about it either. But this way is at least consistent with what the XEP says about asking for file information. The XEP currently uses disco requests extensively in section 4 and 5. If disco overuse is a problem, wouldn't it be better to stop using it in those sections as well? Alternatively we could use a new stanza, like match /match, with a new namespace. But it wouldn't be consistent. We would want to keep requesting file list and requesting file information, within the same namespace as finding specific files. The filter I propose has no new elements. Everything is reused from XEP-122. A new extension for it would be small, and it wouldn't contain new information. Cheers, On Mon, Nov 28, 2011 at 9:41 AM, Matthew Wild mwi...@gmail.com wrote: On 27 November 2011 03:50, Jefry Lagrange jefry.re...@gmail.com wrote: Hi, I been working on some changes to XEP-0135. * Replacing SI file transfer with jingle FT Good :) * Replacing section 6, with a link pointing to section 5 of XEP-0234, which already covers the same function. Makes sense. * Adding support for pubsub, only for finding files using the method I introduce bellow. It doesn't make much sense to traverse the directory of every user subscribed to a pubsub, but it will make a lot of sense searching for specific files. (XEP-0137 does not suffice for this) Agreed. 5.5 Finding Specific Files Finding files by asking for a file list is not very practical if there are too many files being shared. It is very resource intensive and it is understood that the user may not be interested in all of the files, but rather he or she would be interested in finding one specific file or one specific kind of file (text, image or videos). In order to do this, the identity stanza is used to match files by one or more fields i.e. 'name', 'date', 'size', etc... Example XX. Finding Specific Files iq type='get' from='ha...@shakespeare.lit/pda' to='darkc...@shakespeare.lit' id='find45' query xmlns='http://jabber.org/protocol/disco#info' node='files' identity category='filesys' type='file' name='file1' / /query /iq I'm not sure it's a good idea to overload the disco request this way. Perhaps having the filter in a separate namespace would be ok, but I think perhaps it would be better to use another protocol for this. Example XX. Finding files using Regular Expressions Another useful feature, but I even more strongly feel this shouldn't be done over disco. Any feedback would be greatly appreciated, I just want to know if I am on the right track here. Absolutely, I'd love to see this spec revived. I look forward to seeing a new XEP draft :) Regards, Matthew
[Standards] administrivia
Needless to say, this person has been modded. On 12/8/11 5:51 AM, wang chun wrote: *From wang chun* engineer at Trident MultiMedia China I'd like to add you to my professional network on LinkedIn. - wang
[Standards] SASL + OAuth
Have any server or client developers here considered adding support for the emerging SASL mechanism for OAuth? http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth That would seem to open up some interesting authentication possibilities (e.g., integration with various web apps)... Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Answering directed probe
Old thread alert! On 9/18/11 9:48 PM, Justin Karneges wrote: On Sunday, September 18, 2011 09:19:54 AM Tomasz Sterna wrote: Quoting from RFC6121: 4.3.2. Server Processing of Inbound Presence Probe If there is a resource matching the full JID and the probing entity has authorization via a presence subscription to see the contact's presence, then the server MUST return an available presence notification, which SHOULD communicate only the fact that the resource is available (not detailed information such as the show/, status/, priority/, or presence extensions). May I ask what is the rationale behind this? Why the server should not answer with the presence stanza of the probed resource? I believe this is to ensure consistency with section 4.6.6. Basically, if you are probing a full JID then it means you're checking on a known session. Whether the user is in your roster (4.3.2) or not (4.6.6), the response should be the same. The meaning of these empty presence stanzas is a little funky. I think it's supposed to mean the presence is unchanged since the last one sent. As far as I can tell this conflicts with the fact that an empty presence stanza already has meaning (online) but perhaps in most modern client implementations there is at least some other element like c in there to ensure distinction. At the time of writing RFC 6121, we thought there was a good reason for the empty presence stanza (essentially: yep, that resource is still online), but now I'm not so sure. Something to revisit when working on 6121bis. :) Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Proposal for XEP-0302
Old thread alert! On 9/12/11 5:37 PM, Andreas Monitzer wrote: Hi, I'd like to propose XEP-0084 User Avatar to be included for the advanced client in the 2012 compliance suite. The vcard-temp-based avatars are a huge legacy that I'd be very delighted to see gone. User Avatar is already supported in all libpurple-based clients and I believe in others as well (unfortunately, Psi uses an incompatible old version of the protocol), and it's much easier to implement than XEP-0153. I'm fine with vcard-temp being in there until XEP-0292 is no longer experimental, but avatars should move forward. +1 here. (However, we dropped the ball on XEP-0302.) Right now, the Facebook and GTalk servers only support XEP-0153, which is very unfortunate. By the way, I think it's a bit strange to require PEP in the advanced client, but not a single PEP-based XEP. A client that supports PEP but no protocol based on it is not distinguishable from a client that does not support PEP at all. Agreed. XEP-0292 has some PEP features in there, but we probably can't require that until 2013 or 2014 (although I'd like to kill off vcard temp as soon as possible). Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XMPP logo licensing
On 12/6/11 6:34 AM, Kim Alvefur wrote: On Tue, 2011-12-06 at 01:50 -0500, Filipus Klutiero wrote: Hi, is XMPP's logo licensed? Apparently a free license would help including it on Wikipedia ( http://fr.wikipedia.org/wiki/Fichier:Logo_XMPP.svg ). This page[1] it's designed by this designer[2], who has a BY-NC-ND badge at the bottom of the page. I don't know if that means that license applies to all logos or just the site. [1]: http://xmpp.org/about-xmpp/xsf/website-credits/ [2]: http://www.rajasandhu.com/ The whole xmpp.org website (including the logo) is under a slightly modified MIT license. The licensing used by the logo designer is irrelevant, since the XSF paid for the logo and can put it under whatever license it prefers. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XMPP logo licensing
On 12/6/11 10:18 AM, Filipus Klutiero wrote: Le 2011-12-06 10:13, Peter Saint-Andre a écrit : On 12/6/11 6:34 AM, Kim Alvefur wrote: On Tue, 2011-12-06 at 01:50 -0500, Filipus Klutiero wrote: Hi, is XMPP's logo licensed? Apparently a free license would help including it on Wikipedia ( http://fr.wikipedia.org/wiki/Fichier:Logo_XMPP.svg ). This page[1] it's designed by this designer[2], who has a BY-NC-ND badge at the bottom of the page. I don't know if that means that license applies to all logos or just the site. [1]: http://xmpp.org/about-xmpp/xsf/website-credits/ [2]: http://www.rajasandhu.com/ The whole xmpp.org website (including the logo) is under a slightly modified MIT license. The licensing used by the logo designer is irrelevant, since the XSF paid for the logo and can put it under whatever license it prefers. Peter Great, thanks Is there a page on the website that states the website is under a license, or some other official offer of the logo which someone could check to verify its license? http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/ If desired we can add a clarifying note about non-XEP files on the site. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] UPDATED: XEP-0300 (Use of Cryptographic Hash Functions in XMPP)
On 12/5/11 3:16 PM, XMPP Extensions Editor wrote: Version 0.2 of XEP-0300 (Use of Cryptographic Hash Functions in XMPP) has been released. Abstract: This document provides recommendations for the use of cryptographic hash functions in XMPP protocol extensions. Changelog: Updated to reflect initial analysis of existing XMPP protocol extensions. (psa) Diff: http://xmpp.org/extensions/diff/api/xep/0300/diff/0.1/vs/0.2 URL: http://xmpp.org/extensions/xep-0300.html Folks, I started to look at XEP-0300 in relation to existing extensions. Please review my work so far, and do your own thinking about how useful (or not useful) XEP-0300 is. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] RFC 6121, Sec 3.1, 3.2, and 4.3.2
I'm at the IETF meeting in Taipei this week so I don't have time to look into this, but I might have time on the plane home Saturday, or for sure early next week. On 11/16/11 2:22 AM, Dave Richards wrote: Am I missing something or is there a bit of a hole in these sections regarding denying a subscription? In 3.1.2 (subscription request outbound), the user's server pushes a roster entry containing the potential contact with a subscription state of none and with notation that the subscription is pending. In 3.2.3 (subscription cancellation inbound), the user's server is supposed to ignore the subscription cancellation unless the contact is in the user's roster with subscription='to' or subscription='both' And a few lines later: Otherwise ... if the contact is in the user's roster with a subscription state other than those described in the foregoing check -- then the user's server MUST silently ignore the unsubscribed notification by not delivering it to the user, not modifying the user's roster, and not generating a roster push to the user's interested resources. Seems like a subscription denial/rejection would never get processed on the user side. 3.1.6 (subscription approval inbound) talks about subscription none/from with pending out, which seems should also be considered in 3.2.3. In an unrelated issue, 4.3.2, #1 says to send unsubscribed if the contact account does not exist or the user's bare JID is in the contact's roster with a subscription state other than From, From + Pending Out, or Both. Seems like this should also be the case if the contact account exists but is not in the user's roster at all. All other roster states are covered by available/unavailable, so it seems lack of a response would indicate that the account at least exists, which might be considered leaking information, as well as leaving the user with apparently a dead to subscription to the contact. After a brief look I did not find any previous discussion of these, so if there is can someone please point me there? If not, what do you think? Thanks, Dave Richards
[Standards] Fwd: Re: [Council] Agenda
FYI for those of you who don't follow the coun...@xmpp.org list (yes, anyone can subscribe), there's an XMPP Council meeting later today. Original Message Subject: Re: [Council] Agenda Date: Wed, 09 Nov 2011 06:35:54 -0700 From: Peter Saint-Andre stpe...@stpeter.im Reply-To: XMPP Council coun...@xmpp.org To: ke...@kismith.co.uk, XMPP Council coun...@xmpp.org On 11/9/11 6:23 AM, Kevin Smith wrote: Right, I'm probably missing stuff here, please bash as appropriate. 1) Roll call 2) Account manangement protoXEP. Community feedback seems to have finished coming in, and the author has responded. 3) XEP-0258. Last call feedback has been integrated. Accept as Draft? 4) http://xmpp.org/extensions/inbox/correction.html I've made the changes pre-approved a few months ago. Accept as Experimental? 5) ... 5a. XEP-0009 v2.2 http://xmpp.org/extensions/tmp/xep-0009-2.2.html http://xmpp.org/extensions/diff/api/xep/0009/diff/2.1/vs/2.2rc1 5b. XEP-0068 v1.2 http://xmpp.org/extensions/tmp/xep-0068-1.2.html http://xmpp.org/extensions/diff/api/xep/0068/diff/1.1/vs/1.2pre1 5c. http://xmpp.org/extensions/inbox/muc-unique.html 5d. http://xmpp.org/extensions/inbox/dmuc3.html /psa
Re: [Standards] I18N and disco#items
On 11/9/11 4:32 PM, Mike Wacker wrote: Since an item node for a disco#items query has a name attribute for a natural-language name, does that mean that item nodes should also have a corresponding xml:lang attribute? For disco#info queries, the potential need for an xml:lang attribute is called out in XEP-0030, section 3.1 [Basic Protocol for disco#info] (although it's never reference in the schema). But there's no mention of xml:lang at all in section 4.1 [Basic Protocol for disco#items]. However, it wouldn't be too hard to find a context where the results of a disco#items query would be displayed to the user, which would seem to suggest internationalization is necessary here. XMPP is an XML technology, thus xml:lang is allowed on any element. Naturally, we could add an example of that to XEP-0030. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Regarding capitalization of base64 type in Jabber-RPC (XEP-0009)
On 10/7/11 8:04 AM, Gerard Maas wrote: Hi Peter, Many thanks for your swift action. We will be contributing an XEP-0009 implementation to SleekXMPP (Python) , so being compliant with the standard, and therefore having an implementation that is interoperable, is very valuable for us. The XMPP Council discussed this matter in its meeting today and approved the change, so I'll publish the revised spec and schema sometime soon. Peter -- Peter Saint-Andre https://stpeter.im/
[Standards] 1.25rc8 of XEP-0045
Updated per list discussion... Rendered: http://xmpp.org/extensions/tmp/xep-0045-1.25.html Last diff: http://xmpp.org/extensions/diff/api/xep/0045/diff/1.25rc7/vs/1.25rc8 Diff from 1.24: http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc8 /psa
Re: [Standards] XEP-0045 1.25rc7
On 10/6/11 4:36 AM, Alexander Holler wrote: Am 05.10.2011 21:56, schrieb Mike Wacker: On 10/4/2011 11:15 AM, Alexander Holler wrote: If the server never times out a room that is created but not configured and unlocked, then an easy DOS vector is to flood the server with room creation requests but never configure any of the rooms. Since these unconfigured rooms never time out, these creation requests will eventually starve the server of resources. Throttling won't work here, as it will slow but not stop the eventual starvation. Two mitigations would be to either time-out unconfigured rooms or put a cap on the number of unconfigured rooms a single user can create. You could also have a max cap of total rooms for all users, but that also has DOS implications because even if malicious users can't DOS the server, they can DOS other users trying to create rooms if they can hit the server cap. Whats the difference between unconfigured and configured rooms? It's as easy to DOS a server with configured rooms as with unconfigured rooms and it will cost a malicious client almost nothing to configure a room along with the creation. Regards, Alexander Good call, Alexander, my initial line of inquiry began with the question of what if a malicious client intentionally did not configure the room, but configuring the room does not make the problem go away. In fact, configured rooms present additional complications. If a user sends an occasional message to each room after its unlocked, this would also with little cost to the hacker would prevent the server from timing out and destroying the room due to inactivity. That's not an attack we've seen in the wild, as far as I know. The solution is simple, a (service global) limit for ownerships in rooms. XEP-0045 doesn't cover service-global features. We've always said we might write a spec about that, though. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0045: Reserved Nicks and GC Compatibility
On 10/5/11 2:11 PM, Mike Wacker wrote: On 10/4/2011 10:14 AM, Peter Saint-Andre wrote: On 10/3/11 5:11 PM, Mike Wacker wrote: Hello, One of the tenets of XEP-0045 is backwards-compatibility with groupchat 1.0. Additional features do not necessarily introduce incompatibility. The old Groupchat 1.0 protocol had very few features. Yes, a feature, for example, to request a unique nick would not create an incompatibility since old clients wouldn't use the feature. If you still let the client use any nick, it's backwards-compatible. But if you locked down nicks and required the client to use the nick returned by the feature, you would impact a pre-existing scenario, entering a room. I was wondering if reserved nicks break this tenet. XEP-0045 says clients SHOULD first try to discover a reserved nick, if any, before entering a room. However, the server MAY lock down nicks and return an error if the reserved nick is not used. If it does lock down nicks, then the client actually MUST (not SHOULD) check for a reserved nick before entering the room, since using any other nick would cause an error. Rooms with nick lockdown are typically deployed in very controlled environments (e.g., military systems where each person must be identified exactly as they are registered or authenticated). Or an easy way to avoid dealing with nick conflicts. If you locked down nicks, you could also have a predetermined 1:1 mapping between nicks and bare jids that can be calculated either way with O(1) space. While there always expected use cases, I find it's generally not good to assume a feature would only be used in a certain way :) But since the server can rewrite nicks, is it safe to say the client MUST gracefully handle this scenario? The one area where that causes concern for me is existing groupchat 1.0 clients, I obviously do not know how they would handle a nick rewrite. I used the Wayback Machine to look at the old page about the groupchat 1.0 protocol and early versions of JEP-0045, and none of them indicate support for discovering reserved nicks, meaning the client has to set the nick instead. Correct. Thus, it seems like older clients, including groupchat, would actually break if the server locked down nicks and returned an error if the reserved nick was not used to enter a room. So you couldn't join the room. Again, such rooms will be deployed in very controlled environments. (Though I don't know the history of groupchat other than what old docs said, so someone can correct me if there's some missing piece here not mentioned in the docs.) RC7 for XEP-0045 1.25 allows servers to rewrite nicks. If a nick rewrite does not break old groupchat clients, perhaps we should say the server MUST rewrite the nick instead of returning an error if the nicks are locked down and a nick other than the reserved one is used to enter the room. I do think that such an approach is more consistent with Postel's Law, so I'll adjust the text accordingly. Thinking about this further, it strikes me that old groupchat 1.0 clients will not know anything about the 210 status code, so in that case it would be better for the service to return an error. Note that the service knows which clients support groupchat 1.0 and which clients support MUC, so it can send an error to the former and a nick change to the latter. /psa
Re: [Standards] XEP-0054 (vcard-temp) Issues
On 10/27/11 2:54 PM, Bala Pitchandi wrote: The DTD in section 9 http://xmpp.org/extensions/xep-0054.html#dtd mandates that the element vCard must contain VERSION, FN, N but the examples in section 3.1 do not comply. Particularly the vCard retrieval request (Section 3.1, example 1) has an empty vCard element. !-- Individual vCard container -- !ELEMENT vCard ( (VERSION, FN, N), Maybe the intent was to add a “?” at the end to make the sequence of Version, Full Name Name optional, like: !-- Individual vCard container -- !ELEMENT vCard ( (VERSION, FN, N)*?*, Even with this fix, examples other than the vCard retrieval request need to be corrected to include the VERSION. http://xmpp.org/extensions/xep-0054.html#impl
Re: [Standards] jabber:iq:roster Issue
On 10/27/11 2:59 PM, Bala Pitchandi wrote: Which is correct? RFC 6121 is correct.
Re: [Standards] Subscribers List
On 10/27/11 3:06 PM, Bala Pitchandi wrote: So does that mean, a XMPP client implementation MUST add a presence subscriber to its roster, if it wants to keep track of its watchers? Yes. XMPP's presence and subscription model is different from SIP's. You will need to change your way of thinking for it to make sense. :) /psa
Re: [Standards] XEP-0054 (vcard-temp) Issues
On 10/27/11 3:03 PM, Bala Pitchandi wrote: The implementation note (pasted below) does not say that VERSION element is optional: Some Jabber implementations add a 'version' attribute to the vCard/ element, with the value set at 2.0 or 3.0. The DTD is incorrect, and the examples in draft-dawson-vcard-xml-dtd-01 clearly show that version information is to be included by means of a 'version' attribute, not the VERSION/ element as defined in the DTD. However, to conform to draft-dawson-vcard-xml-dtd-01, the value should be 3.0, not 2.0. It's optional -- we assume 3.0 because that's what we inherited from the Dawson I-Ds. And read the history about this -- XEP-0054 is a bastard child, which is why we've defined XEP-0292 (but no implementations yet, AFAIK). /psa
Re: [Standards] XEP-0054 (vcard-temp) Issues
On 10/27/11 3:19 PM, Bala Pitchandi wrote: I agree with you on xCard/XEP-0292. I would rather implement that than implementing XEP-0054 but like you said no one (*cough* Google *cough*) has implemented it yet. To be fair, vCard4 is new. But we need to figure out how to bootstrap implementations... /psa
