Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On Thu, Aug 18, 2011 at 6:43 PM, Peter Saint-Andre wrote: > I've completed a round of revisions to XEP-0045 (Multi-User Chat) in an > effort to incorporate developer feedback I've received since the last > version 3 years ago. The XMPP Council would like to vote on these revisions > before the end of September or possibly early October, so it would be great > if folks could check the diff in the next few weeks: > > http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc5 > 1. Using GC instead of "groupchat 1.0" in various places This doesn't affect me, but new readers of the document might find it confusing. 2. Room subject The current text suggests the room should send a subject if it's set. I'd like it to send in the case when it's not set. The subject will then act as a clear end marker for room history. 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. 4. Presence from existing occupant to bare room JID The MUC's behavior is currently undefined. At least for the type="unavailable" case (and perhaps also for the available case), the MUC should handle and treat it as if it was sent to the occupant's nick. 5. Both and in a single message "(A message with a and a is a legitimate message, but it SHALL NOT be interpreted as a subject change.)" I object to this. It complicates subject handling. I believe much existing MUC software considers a message a subject change if it has a in it. How should software determine this? Assume it's a subject change if there's no ? What if there is not body, but xHTML-IM is included? What if there's no body, but some ? 6. action nick and jid for kicks and bans Examples 85 and 108 have been updated from to , but the text immediately before them still says "the bare JID of the user who initiated [...]". What I'd like here is to allow the room to include a nick and/or a bare/full JID. A nick is useful for general consumption, but a service should be allowed to turn this off. And a service should be allowed to include JID in the stanzas going to occupants who are allowed to see JIDs (moderators). And I don't see any particular reason to not make them full JIDs. 7. Section 16.1 restates what RFC6122 already specifies (and calls it RFC6120 instead). And I have mixed feelings about that MUST NOT. 8. Presence subscriptions I've been wanting to add this in Prosody, but have worried about client behavior on receiving both MUC-specific, and normal presence from the same JID. I'm +1 to it though. Many users do add rooms as contacts. 9. In schema section 18.2 http://jabber.org/protocol/muc#user I'd like changed to , to allow one element for each session in a multi-session nick when including 'jid'. 10. MUC child element in presence errors "Note: If an error occurs in relation to joining a room, the service SHOULD include the MUC child element (i.e., ) in the stanza of type "error"." What is the rationale behind this SHOULD? 'id' attributes are the canonical XMPP way for matching stanzas to error replies; RFC6120#8.1.3 is quite clear that 'id' attributes can be depended on to work fine with presence. IIRC, in Prosody, we added this specifically because Gajim was having issues with nick changes (I note that you didn't specify the above quoted text for this and other error cases). But should this really be a SHOULD? 11. Full-to-bare JID rewriting to support vCards All(?) implementations are doing it, but it's not specified anywhere. Should it be? 12. History management Should it perhaps be noted that clients shouldn't depend on getting only what they asked for? I don't think all MUC implementations support history management. And 'maxchars' is particularly troublesome, as anything between the MUC history code and the client could modify the stanza. Misc: s/"non"/"none"/ "Nicknames can contain virtually any Unicode character introduces the possibility of nick spoofing" - grammar fail. s/hte/the/ All this came from skimming the diff. I'll probably have more feedback when I manage to review the entire spec in detail while looking at Prosody's code. -- Waqas Hussain
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
Am 20.09.2011 00:44, schrieb Peter Saint-Andre: On 9/19/11 4:33 PM, Alexander Holler wrote: Am 19.09.2011 20:47, schrieb Peter Saint-Andre: - Which nicks are reserved? (owner, admins, members) - Owners, admins ormembers without reserved nicks? Nicks are reserved based on registering with the room. Nicks of owners and admins are not reserved automatically, unless an implementation decides that is a nice feature. Registering with a room is getting the affiliation member. So how does an owner or admin reserves a (his) nick? I think especially those want to have their nick registered. Nick are reserved by registering with the room. Are, now I'm getting it. registering with a room does mean at first getting the nick reserved. Becoming a member (if not already) is just a minor matter. I've read it the other way, that registering with a does mean at first becoming a member. Regards, Alexander
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 9/19/11 4:40 PM, Alexander Holler wrote: > Am 19.09.2011 20:23, schrieb Peter Saint-Andre: >> On 9/6/11 10:38 AM, Alexander Holler wrote: >>> Looking again at XEP-0045, >>> >>> I don't see a reason why a request for voice should be handled in >>> another way than a request for membership. ;) >>> >>> In fact I would suggest to replace both with an unified "request for >>> affiliation" which should work like the request for membership in 7.10 >>> (with an attribute 'affiliation' and maybe a xmlns something other than >>> 'jabber:iq:register'). >> >> Is there a strong reason to change this now, other than protocol hygiene? > > No, but maybe adding some muc-features which are making it obvious what > is supported by the server is an option. I don't know if there is an > implemention which supports e.g. those voice-requests as described, > those I've tested seem not to have it implemented. If you test more implementations and find that none of them support the feature (and the developers say they have no plans to implement the feature), then it might make sense to remove the feature from the spec. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 9/19/11 4:33 PM, Alexander Holler wrote: > Am 19.09.2011 20:47, schrieb Peter Saint-Andre: > >>> - Which nicks are reserved? (owner, admins, members) >>> - Owners, admins ormembers without reserved nicks? >> >> Nicks are reserved based on registering with the room. Nicks of owners >> and admins are not reserved automatically, unless an implementation >> decides that is a nice feature. > > Registering with a room is getting the affiliation member. So how does > an owner or admin reserves a (his) nick? I think especially those want > to have their nick registered. Nick are reserved by registering with the room. >>> - What happens with reserved nicks when someone changes his nick? Does >>> the reserved nick changes too? >> >> Implementation specific. > > Hmm, that means clients never can implement reserved-nick-handling > because they just don't know how the server behaves. Changing your in-room nick is temporary. If you want to reserve a different nick, you can register it in the usual way. I have no idea if current implementations let you reserve more than one nick (probably not). We might want to define that behavior a bit more carefully. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
Am 19.09.2011 20:23, schrieb Peter Saint-Andre: On 9/6/11 10:38 AM, Alexander Holler wrote: Looking again at XEP-0045, I don't see a reason why a request for voice should be handled in another way than a request for membership. ;) In fact I would suggest to replace both with an unified "request for affiliation" which should work like the request for membership in 7.10 (with an attribute 'affiliation' and maybe a xmlns something other than 'jabber:iq:register'). Is there a strong reason to change this now, other than protocol hygiene? No, but maybe adding some muc-features which are making it obvious what is supported by the server is an option. I don't know if there is an implemention which supports e.g. those voice-requests as described, those I've tested seem not to have it implemented. Regards, Alexander
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
Am 19.09.2011 20:47, schrieb Peter Saint-Andre: - Which nicks are reserved? (owner, admins, members) - Owners, admins ormembers without reserved nicks? Nicks are reserved based on registering with the room. Nicks of owners and admins are not reserved automatically, unless an implementation decides that is a nice feature. Registering with a room is getting the affiliation member. So how does an owner or admin reserves a (his) nick? I think especially those want to have their nick registered. - What happens with reserved nicks when someone changes his nick? Does the reserved nick changes too? Implementation specific. Hmm, that means clients never can implement reserved-nick-handling because they just don't know how the server behaves. Regards, Alexander
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
Am 19.09.2011 20:49, schrieb Peter Saint-Andre: On 8/18/11 3:00 PM, Alexander Holler wrote: Am 18.08.2011 15:43, schrieb Peter Saint-Andre: I've completed a round of revisions to XEP-0045 (Multi-User Chat) in an effort to incorporate developer feedback I've received since the last version 3 years ago. The XMPP Council would like to vote on these revisions before the end of September or possibly early October, so it would be great if folks could check the diff in the next few weeks: http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc5 A rendered version is here: http://xmpp.org/extensions/tmp/xep-0045-1.25.html Thanks for the update. I will try to read (again) as much as I can. At first I would strongly suggest to replace at least that 'oldhag' which is e.g. used for a new nick with something else. I've wondered some minutes when I first read that example in 7.6 until I have read further. For other people like me, who like stupid looking but easy to read docs, here is something I've done to my copy of XEP-0045 (.example and .test are reserved by RFC 2606): - sed \ -e 's/chat.shakespeare.lit/chat.example/g' \ -e 's/shakespeare.lit/home.test/g' \ -e 's/firstwitch/occupant1owner/g' \ -e 's/secondwitch/occupant2admin/g' \ -e 's/thirdwitch/occupant3none/g' \ -e 's/crone1/user1owner/g' \ -e 's/wiccarocks/user2admin/g' \ -e 's/hag66/user3none/g' \ -e 's/oldhag/newnick/g' \ -e 's/coven/room1/g' \ -i xep-0045.html - ;=) Fun Shakespeare examples have kept me motivated in writing all this documentation for the last 10+ years. I won't be changing them now. Than, maybe, just bringing the examples in section 9 in line with the rest of the documentation is an option. Using the above sed is a good way to see the problematic examples. E.g. the example in 9.1 will change from --- --- to --- --- I don't remember which examples really confused me most during my first reading, but that one is surely one of those candidates because it isn't obvious what is room, service, occupant or real JID. The problem will become obvious (through the sed) because all JIDs are at home.test. ;) Regards, Alexander
[Standards] UPDATED: XEP-0220 (Server Dialback)
Version 0.12 of XEP-0220 (Server Dialback) has been released. Abstract: This specification defines the Server Dialback protocol, which is used between XMPP servers to provide identity verification. Server Dialback uses the Domain Name System (DNS) as the basis for verifying identity; the basic approach is that when a receiving server accepts a server-to-server connection from an originating server, it does not process traffic over the connection until it has verified a key with an authoritative server for the domain asserted by the originating server. Although Server Dialback does not provide strong authentication or trusted federation and although it is subject to DNS poisoning attacks, it has effectively prevented most instances of address spoofing on the XMPP network since its development in the year 2000. Changelog: Corrected several small errors and added sentence about the undesirability of the stream features child element, per list discussion. (psa) Diff: http://xmpp.org/extensions/diff/api/xep/0220/diff/0.11/vs/0.12 URL: http://xmpp.org/extensions/xep-0220.html
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 8/18/11 3:00 PM, Alexander Holler wrote: > Am 18.08.2011 15:43, schrieb Peter Saint-Andre: >> I've completed a round of revisions to XEP-0045 (Multi-User Chat) in an >> effort to incorporate developer feedback I've received since the last >> version 3 years ago. The XMPP Council would like to vote on these >> revisions before the end of September or possibly early October, so it >> would be great if folks could check the diff in the next few weeks: >> >> http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc5 >> >> A rendered version is here: >> >> http://xmpp.org/extensions/tmp/xep-0045-1.25.html > > Thanks for the update. I will try to read (again) as much as I can. > > At first I would strongly suggest to replace at least that 'oldhag' > which is e.g. used for a new nick with something else. I've wondered > some minutes when I first read that example in 7.6 until I have read > further. > > For other people like me, who like stupid looking but easy to read docs, > here is something I've done to my copy of XEP-0045 (.example and .test > are reserved by RFC 2606): > > - > sed \ > -e 's/chat.shakespeare.lit/chat.example/g' \ > -e 's/shakespeare.lit/home.test/g' \ > -e 's/firstwitch/occupant1owner/g' \ > -e 's/secondwitch/occupant2admin/g' \ > -e 's/thirdwitch/occupant3none/g' \ > -e 's/crone1/user1owner/g' \ > -e 's/wiccarocks/user2admin/g' \ > -e 's/hag66/user3none/g' \ > -e 's/oldhag/newnick/g' \ > -e 's/coven/room1/g' \ > -i xep-0045.html > - > > ;=) Fun Shakespeare examples have kept me motivated in writing all this documentation for the last 10+ years. I won't be changing them now. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 8/19/11 1:02 PM, Alexander Holler wrote: > Am 18.08.2011 23:00, schrieb Alexander Holler: >> Am 18.08.2011 15:43, schrieb Peter Saint-Andre: >>> I've completed a round of revisions to XEP-0045 (Multi-User Chat) in an >>> effort to incorporate developer feedback I've received since the last >>> version 3 years ago. The XMPP Council would like to vote on these >>> revisions before the end of September or possibly early October, so it >>> would be great if folks could check the diff in the next few weeks: >>> >>> http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc5 >>> >>> A rendered version is here: >>> >>> http://xmpp.org/extensions/tmp/xep-0045-1.25.html >> >> Thanks for the update. I will try to read (again) as much as I can. > > Here is my current list of open questions: > > - Which nicks are reserved? (owner, admins, members) > - Owners, admins ormembers without reserved nicks? Nicks are reserved based on registering with the room. Nicks of owners and admins are not reserved automatically, unless an implementation decides that is a nice feature. > - What happens with reserved nicks when someone changes his nick? Does > the reserved nick changes too? Implementation specific. > I don't know why fully-anonymous rooms got removed, according tothe > history this was done 2002. But I think there are good reasons for rooms > where even moderators or owners shouldn't be able to see real JIDs. E.g. > thinking about countries where people have to fear speaking freely > without beeing anonymous. There might be possibilities to discover real > JIDs when access to the machine running the service is available, but if > someone (a owner or moderator) doesn't have such, he can't be get under > pressure to reveal real JIDs because he just can't see them. > > So here are my 2ยข for in regard to fully-anonymous rooms: > > - muc_fullyanonymous in service discovery is missing, > - make a note about problems with fully-anonymous rooms, e.g how to ban > someone without revealing his jid in the list of outcasts, how to remove > an outcast if the outcast was done based on the nick only, possible > solution: outcasts with a timeout). Besides removing outcasts, I think > anything else could be handled through the use of nicks only. > > To not having the need to define how fully-anonymous rooms are handled, > maybe the xep could just list the value 'none' for whois (no change > needed), add muc_fullyanonymous to service discovery and say everything > else in regard to how fully-anonymous rooms are handled (if supported) > is implementation specific. Feel free to write and submit a proposal for fully anonymous rooms. IMHO this is out of scope for XEP-0045, and has been since 2002. We are trying to *not* add new features to XEP-0045 at this point, and in fact to remove features if they are not used. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 8/31/11 11:41 AM, Alexander Holler wrote: > Just to summarize the problems I see with those requests (to change > affiliation): > > 1. I haven't found out how the user has to build such an request. E.g. > the request for voice as described in the XEP doesn't work with either > ejabberd or M-Link ( or I did something wrong during my short tests ;) ). > > 2. The service has to parse and translate every request into a form > which is then presented to moderators. The service has to replace all > labels and has to check every type. > > And because I think there should be standardized way for those requests > I don't see why using a form for such a request offers any benefit over > something like this: > - > to='ro...@chat.example.com'> > > > > > - > > In both cases the service has to generate a form which is then > send/presented to moderators, but parsing _and_ verifying something like > the above message is much easier than parsing _and_ verifying a form. I see no compelling reason to change this. I might see a reason to remove the feature entirely, if no one supports it. At this point in the life cycle of XEP-0045, we're trying to clean up some minor problems and clarify some issues for implementers, not make any changes of significance, and certainly not merely for the sake of consistency or elegance. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 9/6/11 10:38 AM, Alexander Holler wrote: > Looking again at XEP-0045, > > I don't see a reason why a request for voice should be handled in > another way than a request for membership. ;) > > In fact I would suggest to replace both with an unified "request for > affiliation" which should work like the request for membership in 7.10 > (with an attribute 'affiliation' and maybe a xmlns something other than > 'jabber:iq:register'). Is there a strong reason to change this now, other than protocol hygiene? Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 9/6/11 8:17 AM, Ralph Meijer wrote: > On Tue, 2011-09-06 at 15:37 +0200, Alexander Holler wrote: >> Am 06.09.2011 11:09, schrieb Ralph Meijer: >>> On Tue, 2011-09-06 at 09:24 +0200, Alexander Holler wrote: [..] I don't see any reason why the user should send a form to the server. If using a form is wanted, the correct way would be that the user requests a form for the request from the server, and sends back the result, which is then processed by the server (resulting in a form for the moderator). The described way where the user generates a form only makes sense, if that form is forwarded to the moderator. But that would result in the possible problems I've described (e.g. hidden fields and wrong labels). >>> >>> I don't see how requesting a form from the service first somehow makes >>> this better. An attacker could simply ignore that form and submit its >>> own bad one. >> >> Whats the point that the user sends labels? >> >> Where do the user gets the list of required fields from? > > Ah, these are valid concerns. Looking into it in more detail, of course > the form for requesting voice, as shown in example 74 of XEP-0045 > v1.25rc5, is of type 'submit'. The form sent to the moderator for > approval, as shown in example 103 is of type 'form', as at should be. > The latter is thus an entirely different one, with additional fields > muc#jid, muc#roomnick and muc#request_allow, constructed by the MUC > service. > > You are taking the associated prose, that suggests to 'forward the > request', too literal. > > The form sent by the user's client can be entirely constructed by the > client, without displaying it as such to the user. As it is of type > 'submit', no labels are required. The required field is 'muc#role' and > the value is 'participant'. The type and label attributes should > probably be removed from the example. > > Even thought this is currently not specified, future extensions could > define how an interaction might be, with additional fields required of > the user. Your suggestion of first requesting a form to get these fields > (as with registering a nick or configuring a room) seems the obvious > solution to that. If there is no immediate need for this, I suggest we > leave things as is, though. I've reworded those sections to remove the ambiguity. Section 7.13 The service then proceeds as described in the Approving Voice Requests section of this document. Section 8.6 As noted in the Requesting Voice section of this document, an occupant requests voice by sending a voice request data form to the service. The service then SHOULD use that voice request data form as the basis for a voice approval data form that it generates and sends to the room moderator(s). The voice approval data form is contained in a stanza, as shown below. /psa
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On 9/19/11 11:03 AM, Peter Saint-Andre wrote: > On 7/7/11 11:37 AM, Peter Saint-Andre wrote: >> On 7/7/11 2:51 AM, Kevin Smith wrote: >>> On Wed, Jul 6, 2011 at 5:59 PM, Peter Saint-Andre >>> wrote: On 5/17/11 2:26 PM, Kevin Smith wrote: > On Tue, May 17, 2011 at 9:20 PM, Peter Saint-Andre > wrote: 1. Child elements as in 0.9: >>> >>> I'm not opposed to this, I think. It has the advantage of not breaking >>> the existing implementations. >> >> The concern is, what happens when someone adds new sub-features in the >> future? > > Hopefully we wouldn't spec new features without versioning and start > seeing interoperable implementations prior to realising in the future > :) > > 3. More features: >>> >>> This one breaks existing dialback error implementations, but not >>> general dialback implementations. This one doesn't seem particularly >>> harmful, compared to (2), and I'll go along with the majority if it's >>> what's deemed sensible. >> >> #3 is more consistent with what we do in service discovery. IMHO that's >> a good thing. > > Yes, #3 is what we have previously agreed is the Right Thing to do > with features. In this case we didn't, and implementations sprouted up > and were deployed before we noticed, so it's a question now of whether > the pragmatic thing is to use what we have, or to break > implementations and maintain spec-hygiene. Kev, I've thought about this some more and I think it's OK to retain this: That's what we've had since version 0.5 of the spec, published on 2010-03-18. I don't like it and I think we need to add a note that this is not the recommended way of defining stream features so that other specs won't emulate this approach, but the protocol hygiene is just not important enough to me here. >>> >>> I'm happy with notes saying that this is the Wrong Thing to do, and we >>> can even give a footnote of what the Right Way is, if we want. >> >> I'll work up some text along those lines for review on the list. > > My apologies for the delay. I propose that we add the following > paragraph at the end of Section 5.2: > >As a general rule, stream feature elements containing child elements >that advertise particular sub-features are not encouraged. The >format shown above is used for the sake of backward compatiblity >with existing implementations and deployments. Sorry, I think that belongs in Section 2.4.2. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On 7/7/11 11:37 AM, Peter Saint-Andre wrote: > On 7/7/11 2:51 AM, Kevin Smith wrote: >> On Wed, Jul 6, 2011 at 5:59 PM, Peter Saint-Andre wrote: >>> On 5/17/11 2:26 PM, Kevin Smith wrote: On Tue, May 17, 2011 at 9:20 PM, Peter Saint-Andre wrote: >>> 1. Child elements as in 0.9: >>> >>> >>> >>> >>> >>> >> >> I'm not opposed to this, I think. It has the advantage of not breaking >> the existing implementations. > > The concern is, what happens when someone adds new sub-features in the > future? Hopefully we wouldn't spec new features without versioning and start seeing interoperable implementations prior to realising in the future :) >>> 3. More features: >>> >>> >>> >>> >> >> This one breaks existing dialback error implementations, but not >> general dialback implementations. This one doesn't seem particularly >> harmful, compared to (2), and I'll go along with the majority if it's >> what's deemed sensible. > > #3 is more consistent with what we do in service discovery. IMHO that's > a good thing. Yes, #3 is what we have previously agreed is the Right Thing to do with features. In this case we didn't, and implementations sprouted up and were deployed before we noticed, so it's a question now of whether the pragmatic thing is to use what we have, or to break implementations and maintain spec-hygiene. >>> >>> Kev, I've thought about this some more and I think it's OK to retain this: >>> >>> >>> >>> >>> >>> >>> >>> That's what we've had since version 0.5 of the spec, published on >>> 2010-03-18. I don't like it and I think we need to add a note that this >>> is not the recommended way of defining stream features so that other >>> specs won't emulate this approach, but the protocol hygiene is just not >>> important enough to me here. >> >> I'm happy with notes saying that this is the Wrong Thing to do, and we >> can even give a footnote of what the Right Way is, if we want. > > I'll work up some text along those lines for review on the list. My apologies for the delay. I propose that we add the following paragraph at the end of Section 5.2: As a general rule, stream feature elements containing child elements that advertise particular sub-features are not encouraged. The format shown above is used for the sake of backward compatiblity with existing implementations and deployments. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0198: Stream Management - Clarifications
Hello, Am 19.09.2011 10:20, schrieb Dave Cridland: You don't appear to be disagreeing with me, but instead arguing about something I've never mentioned. Exactly, it was more a response to the original request (but I've just answered to the last message of the thread, yours). I don't see any reason to modify the XEP, it's just fine. Therefore I've answered later on to another message in the thread. ;) Regards, Alexander
Re: [Standards] XEP-0198: Stream Management - Clarifications
On Sat Sep 17 18:44:28 2011, Alexander Holler wrote: Am 16.09.2011 21:24, schrieb Dave Cridland: On Fri Sep 16 17:58:17 2011, Kim Alvefur wrote: I think it shouldn't hurt if meant "I'd really like you to send an now, please", and the other party SHOULD reply with , but not MUST. No, that would be bad. I do not wish to second guess why I'm not getting an , I just want to get one. If an implementation for whatever reason sends a whole bunch of s at the same time, then why reply with more than one . I don't want to optimize the protocol for poorly written implementations. If the other end is asking for lots of acknowledgements, either send them or go talk to a different peer. Send as many as you like, but at least one per received. I don't see any reason why there should be an error defined for. It's just like if you never get an return for an iq stanza. If the sender for an doesn't get an in whatever time he wants one, it's the sender of the decision what to do. It's extremly unlikely that a receiver of an is interested in an error, if he doesn't send an and through that clearly violates the MUST (send ) in the XEP. And defining some arbitrary (response) time doesn't make sense (imho). You don't appear to be disagreeing with me, but instead arguing about something I've never mentioned. I'm saying that receivers of an MUST send an . Receivers of two 's MUST send one for each. If receivers of an withhold an , that indicates some problem with the connection (including application-level congestion). If no at all is sent, then the peer that's missing the response might do all sorts of things to try to recover, up to and including sending a timeout error, or simply dropping the connection - and that seems entirely fine; either the connection or the other peer is broken. If a peer is sending lots of 's, then this is a poor implementation, but you still MUST reply to each individually. Could be there's been a period of congestion and you're actually seeing one per minute coming through in a big bunch. Introducing variance in whether or not to respond to an or not simply breaks the protocol. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
