KevMeeting with nothing on the agenda in ~55 minutes.
linuxwolfw00t
MattJhas joined
MattJIt took me a long time to work out "Today being Monday, tomorrow being Wednesday"
ralphmhas joined
KevMattJ: Submitted MAM yet?
MattJNot yet
ralphmMattJ: +1 on stream:error everywhere
MattJThanks, good to know I'm not just missing the point of that thread
MattJYou MUST answer <iq> requests, but does that mean we shouldn't send a stream:error if there are any outstanding?
KevOh, good question. Yes, I guess it does :)
ralphmIn Wokkel I just set up a general handler for that not-stanza-but-still-direct-child-of-the-stream-element-that-does-not-have-a-proper-name
linuxwolfor you treat the stream:error as a "catastrophic failure", like a severed network … d-:
ralphmlinuxwolf: I do. In Wokkel, you get a Deferred back when sending out an IQ. If the current stream disconnects, the deferred is fired with an exception to that effect.
linuxwolf/nod … it's what I've done just about everywhere, too
ralphmmostly because you can't know what really happens
linuxwolfif a server's at the point of emitting a stream:error, you have bigger problems than unanswered iq's
KevI think the order here is actually mandated.
KevBecause the server must be processing the stanzas in order - so if you send <iq/><message><illegal/></message> ther server isn't allowed to process the message (and find there's an error) until it's finished with the iq.
KevStream errors for server going down or whatever don't fit into this, I realise.
linuxwolfI rarely see the <illegal/>, but definitely see the crash (-:
Tobiashas joined
ralphm… which, in spite of the MUST, still allows for not sending a response
linuxwolfgraceful-crash?
MattJKev, define "finished" (with the iq)
linuxwolf(-:
MattJKev, does handling in order require responding in order?
KevOf course.
ralphmOf course roster pushes in any new design would be <message/> stanzas
KevIt's not handled until the server has replied.
MattJOk, so...
linuxwolfralphm: everything is pubsub
ralphmlinuxwolf: hah, earlier specs for pubsub used IQs for notifications
MattJKev, if you send a vcard request to an occupant in a MUC room, the server isn't allowed to process any further stanzas from you until that person's server responds with their vcard?
ralphmlinuxwolf: this is one reason I think that's a bad idea
linuxwolfin any new design, we can just do <publish/>, <subscribe/>, and <notify/> as TLS (top-level-stanzas)
linuxwolf"just"
ralphmlinuxwolf: I guess we'd just drop '<presence/>' and keep '<message/>' and '<iq/>'.
linuxwolfyeah, pretty much (-:
KevMattJ: It's not the server that's processing the iq.
MattJSo we can have a stream:error before the iq is responded to?
KevYes.
MattJGood
ralphmOf course
KevJust not before an iq is responded to by the server.
KevA roster get or whatever.
linuxwolfs/an iq is/an iq addressed to the server is/ ?
KevRight.
MattJI think you're talking about something aside from the main issue
KevNaturally.
stpeterhas joined
MattJMy original question was whether you could close a stream with unhandled iqs. We've establised a definite 'yes' for iqs sent to non-server JIDs
MattJand I see no reason a server must reply to an iq, if it's invalid for example, instead of throwing a stream error
ralphmKev: are you also saying that responses to iqs to the same entity should come back in order?
stpetergosh, its seems that I've missed a fun discussion
MattJand I'm thirdly not convinced (but admittedly on more shaky ground) that iqs must be responded to in order
MattJbecause I don't equate "handling" with "responding"
linuxwolfMattJ: I agree
ralphmMattJ: agreed, that seems QUITE problematic, to me.
MattJstpeter, pre-council meeting :P
linuxwolfespecially if dealing with large scale
stpetergrumbles about a conference call that someone expected him to be on right now
ralphmI think in-order processing is only about accepting stanzas in order and routing them in the same order as much as possible. Nothing beyond that.
ralphmstpeter: claim atmospheric issues
MattJor claim it's Tuesday
stpeterdamn proprietary Outlook invites
linuxwolfhah
linuxwolffumso
linuxwolf(f*** u microsoft office!)
KevRighty.
KevShall we have our not-a-meeting, then?
Kev1) Roll call.
KevI'm here.
linuxwolfpresente
stpeteris still on his conference call
MattJGift
ralphmhi
KevTobias: ?
Tobiaskev
Tobiasah..council meeting
Tobiasyoup..i'm here
KevDid anyone have anything for the agenda?
stpeterok my call is done
KevI'll add GSoC, then
Kev2) GSoC
KevThe applications are in, thanks to the people who answered my call for mentors and have commented on proposals.
KevI submitted the slot requests to Google yesterday, based on the applications people volunteered to mentor and the comments on the proposals.
KevThere's still time for people to comment on proposals if they want, but I'd rather they didn't juggle anything about too much, as we're pretty much done at this point (apart from the Jitsi guys deciding which proposals they want to accept - but they've chosen a number).
Tobiasok
KevThat's about it.
linuxwolfnice
KevWe've asked for more slots than is usual for us, so I'm expecting Carol not to be able to hand them all over, but hey ho.
linuxwolf(-:
stpeterKev: would you be so kind as to point me to the message on the GSoC list that says exactly where we complete certain tasks? or is it all somewhere at google.com and I just need to log in someplace?
KevWhen that happens I'll look at the comments and scores people have left on the proposals and try to pick the ones we select somewhat fairly.
Kevgoogle-melange.com
stpeterah ok
stpeterthanks
KevI think that's everything GSoCcish.
Kev3) Date of next meeting.
KevSBTSBC
Kev?
linuxwolfwfm
linuxwolfhopefully MAM will be a topic of discussion
linuxwolf/zing
KevWe can but hope. Nearly 50% of the XSF's GSoC applications were to work on MAM support.
stpeterheh
KevRight, SBTSBC it is.
Kev4) AOB?
ralphmnope
linuxwolfnada
MattJNone
Tobiasnope
KevSounds good then.
stpeterok thanks guys, I'm slowly getting back into mostly-xmpp mode, so I'll start working on things of interest here again soon
KevThanks all.
Kevbangs the gavel.
ralphmKev: I'm still interested in your responses to the pre-meeting discussion
Kevralphm: Interested in what way?
stpetercloses his computer and heads to the light rail station
ralphmKev: well, for example, the question I asked
KevThat's not entirely unambigous at this point :p
Kevstpeter: Enjoy.
stpeterhas left
linuxwolfgoes for caffeine
ralphmralphm: Kev: are you also saying that responses to iqs to the same entity should come back in order?
ralphm(and the stuff following that)
KevYes.
KevThe entity is obliged to process them in order, their server is obliged to send them to your server in order, and your server is obliged to send them to you in order.
ralphmKev: I'll rephrase
ralphmKev: are you saying that responses to iqs should come back in the same order as the requests?
KevTo a given bare JID? Yes.
ralphmAs I said before, that seems problematic.
KevI don't see why.
KevIt's what 6120 says you need to do.
ralphmIf I send an IQ to an entity that then goes out to request a web resource to produce a response, and I send it another unrelated IQ that can be responded to immediately, that is really an issue.
KevThe second iq must be pipelined until the first is processed.
ralphmI'm not sure if I agree this is what RFC 6120 says, but I do think it is stupid
ralphmand I don't see why you'd want that kind of behaviour
KevInteresting, I'm wrong, I think.
KevWhat I say only holds true if the entity is a server.
ralphmReally? Also, define 'server'
KevIf it's a client, there seems to be no restriction on the processing order of data it receives.
Kev"Thing at the S end of a C2S link, or at the end of an S2S link"
ralphmalso, 'processing' is rather vague
ralphmyou also mentioned MUC as an example
KevDid I?
ralphmOh, no MattJ did
ralphmHe mentioned waiting for the response to an vcard request
ralphma MUC will send this request on to the actual occupant. Do all groupchat messages have to be queued until the response can be sent back?
ralphm(for the requesting occupant)
KevThat's a fun question.
ralphmRFC 6120 says:
ralphmIf the server's processing of a particular request could have an effect on its processing of subsequent data it might receive over that input stream (e.g., enforcement of communication policies), it MUST suspend processing of subsequent data until it has processed the request.
ralphmI believe that the 'if' is rather (intentionally) vague, and not as strict as you seem to make it out to be.
KevRight.
ralphme.g. I'd say it does apply for subsequent publish requests to the same node
KevIt seems that the following cases are strictly linear:
ralphmbut not to different nodes, or any other unrelated iq or message
KevSending anything to your bare JID
Routing stanzas
Receiving routed stanzas
KevAnd that for other requests it's vague.
KevOh, no, I'm wrong.
KevTo your bare JID or to the server itself.
ralphmso that's all about delivery
ralphmand I agree with *that*
KevSo routing must always be in order, and processing must always be in order if it's your own server - but other entities can process in their own chosen way, subject to the note about subsequent data.
ralphmI still don't want my server to not respond to an iq:version if it is still figuring out what my roster is if the order of requests is 1) roster 2) version
KevThat much is entirely clear in 6120
KevIt must process those requests in order.
MattJProcess, or respond?
ralphmwhat MattJ says
ralphmthis is crucial
ralphmand not clear at all to me
KevThey're one and the same.
MattJand if this is ambiguous, I think it should be made clear that handle/process != respond
ralphmKev: I strongly disagree
ralphmKev: and I don't see any text to support that
KevIf I say "please get me my roster", you can't possibly claim to have completed processing of that request until you have given me my roster.
ralphmSure I can!
ralphmIf I set my mind to it.
ralphmKev: also, I am not sure that RFC 6120, section 10.1, shares your interpretation of 'processing' in this case.
ralphmIt does not talk about processing requests, but rather processing of stanzas.
Kev"e.g., in-order processing of a roster get and initial presence as described in [XMPP‑IM]"
KevI'd say that was pretty unambiguous.
ralphmI think that's because of the paragraph I pasted. So a business rule for this particular exchange of different related stanzas.
ralphmSo I agree on that example, but not on the general case.
KevBut when taken with the complete bullet:
"Stanzas sent by a client to its server or to its own bare JID for direct processing by the server (e.g., in-order processing of a roster get and initial presence as described in [XMPP‑IM])."
ralphmthere is no reason to delay responding to an iq:version request if you sent out a roster request before that
KevIt is clear that's just an example of the general case to which this rule applies.
ralphmKev: so if the current text divides us in interpretation, what do you think about what I say in reality? I'd be more than happy to suggest we amend this.
KevI think this is a good rule.
ralphmI think it is a nightmare.
KevI think it's possible to find cases where it doesn't serve a purpose (as in your example), but I don't think it's harmful, and I think it's much simpler than trying to create a list of all requests that must be processed in order, which requests they must be processed in order with and which can pass through, etc.
Kevralphm: In your particular example it's really easy for the client to just request the version first, if response to that is more urgent than getting its roster :)
ralphmKev: seriously?
ralphmKev: so an entity should guess how much time it takes for a server to respond to unrelated queries and order them accordingly before sending them out?
KevNo, not really, because just about all queries a client sends to a server it's going to get responses to ~instantly anyway.
KevTypically how many requests does a client make of its server? Roster, private, vcard, version maybe? These are all going to get processed quickly.
KevAnd for heavy processing platforms (i.e. not the clients own server), these rules don't apply.
ralphmI'm talking about XMPP Core, not necessarily about XMPP IM. So while such behaviour might be ok for IM clients, I'd certainly don't want to have such a thing anywhere that generic.
linuxwolfKev: disco
Kevlinuxwolf: Disco should return instantly too.
KevUnless you were just adding it to the list, rather than a counterpoint, in which case...right.
linuxwolfthis "instantly" is a big assumption, IMO
linuxwolfand I was adding to the list
Kevdisco#items to a MUC service, on the other hand, isn't subject to these rules.
ralphmKev: I'm willing to bet that most server developers strongly disagree with your stance on this.
linuxwolfthey do
ralphmKev: also, a muc service could be part of the server you are talking to. I.e. council@xmpp.org *and* ralphm@xmpp.org.
Kevralphm: It could, this is true.
linuxwolfin any case, if you want to be reasonably sure things are fully handled in the proper order, you wait for the previous iq before sending the next
linuxwolfand that is something we ought to recommend somewhere anyway
Kevlinuxwolf: Well, no, you don't need to, because 6120 says it'll do it for you.
linuxwolfKev: as this discussion points out, your stance is not universally accepted
ralphmlinuxwolf: so that's really a business rule of particular exchanges, not of all message/iq processing, right?
linuxwolfprocessing is a vague term
linuxwolfralphm: true, but at least for my experiences, it's true far more often than it's false
ralphmlinuxwolf: but individually, per types of exchanges (say presence/roster v.s. iq version v.s. pubsub publish)
ralphmlinuxwolf: not on all incoming messages/iqs
linuxwolfralphm: true
Kevlinuxwolf: It's not vague, at least for iqs it's fairly clearly defined.
KevAnd it includes sending the response.
ralphmKev: if people disagree with an interpretation (in general) it is not clearly defined
linuxwolfralphm: it comes down to what's important to "ensure" is handled
KevI don't see how you can possibly interprep 6120 to not think iq processing includes sending the result.
ralphmKev: see above.
Kevralphm: Which part of the text makes you think it doesn't include the return?
Kev"in general the server will respond to the IQ stanza"
linuxwolfKev: I don't think processing means it has to be completed; it has to be started in the received order, but not necessarily finished
linuxwolfwhich therefore means it doesn't necessarily have to respond in the received order
ralphmKev: the part that says "If the server's processing of a particular request could have an effect on its processing of subsequent data it might receive over that input stream"
ralphmKev: which for my example is false.
Kevralphm: Yes, that is for stanzas that don't fall under the previous list.
ralphmKev: not in my world
Kev"In-order processing applies (a) to any XML elements used to negotiate and manage XML streams, and (b) to all uses of XML stanzas"
KevThat really doesn't seem ambiguous.
ralphmas long as you talk about stanzas, it is about delivery
ralphmin my opinion
KevAnd to make sure people don't make that mistake while reading it, it then has bullet 1 in the following list to say that it also includes the processing.
linuxwolfI still think it comes down to how one defines processing
ralphmLet's put it differently: I am going to suggest this text gets changed.
ralphmbecause a) servers don't work that way, b) I think it is undesirable
ralphmc) it might even be harmful
ralphmit seems MattJ and linuxwolf agree with me. I'm curious about other server devs of course. I also think my interpretation shouldn't impact clients at all.
KevOther than changing the defined behaviour of the server.
ralphmKev: do you clients send out an iq and ignore or error on any other stanza from the same (local?) entity until that iq gets a response?
ralphmdo you*r*
KevIgnore or error? No. I'm not convinced it won't change behaviour, though, if the client e.g. doesn't know its own nickname before it tries to join bookmarked rooms.
ralphmKev: and to be sure: we don't agree that it changes the behaviour. My take is that it clarifies it.
ralphmKev: in general, if you need the output of one request as the input for another, you require order on the client side. That doesn't impact this at all.
linuxwolfKev: now this is just silliness … of course you can't act on data you don't yet know about, but that doesn't mean you can't handle an iq:version returning before that vcard or PEP item retrieve
Kevlinuxwolf: Unless the PEP item retrieve is also part of determining your nickname for joining MUCs, for example.
KevOr if the PEP retrieve is for your bookmarks and you get those before you know your nickname.
linuxwolfKev: right … but how does the iq:version impact this? Does swift break if it got the iq:version response before it got the PEP item-retrieve, even though you (theoretically) sent them in reverse order?
ralphmKev: again, if you need all responses, then yes, you should wait for all of them
KevOf course, clients could be written (subject to significant additional latency) to deal with not having guaranteed order - but at the moment 6120 says that the server will process its requests in order, and as such they don't need to.
linuxwolfthere is no additional latency
Kevlinuxwolf: There is if you're suggesting that where ordering matters you must wait for a reply to the previous before requsting the next, which you suggested earlier.
ralphmKev: only if you need the reponse!
linuxwolfKev: for those things that matter, you'd have to no matter what!
linuxwolfI think we're agreed you can't join rooms until you know what rooms to join, yes?
linuxwolfand, you can't join room until you know what the user's preferred and/or registered nick is, yes?
linuxwolfbut, that doesn't mean the client must way for the bookmark request to complete ...
linuxwolf… before requesting the PEP-registered nickname
ralphmKev: what linuxwolf and I are saying actually improves latency.
ralphmand also wastes less server resources as a bonus
linuxwolfnor does it mean you must wait for one particular MUC room to respond to your register get before you send the next
linuxwolffor those things I MUST have the result, they get sent serially, pending said response
KevExcept 6120 says you don't need to do that, because the server will enforce ordering.
KevSure, you *can* do it, but you don't need it.
ralphmassuming again that the MUC room is local, I'd say that communicating with two rooms is talking to different (bare) JIDs, so that doesn't apply.
ralphmKev: you keep repeating that the RFC says that, but it is your interpretation thereof
KevSure, based on reading the words in it :p
KevThe only way around it is if you start twisting 'processing' to mean 'doing some things it was asked to do, but not all of them'.
ralphmKev: accept that other people might interpret words differently. If you hate that, provide functional tests for the next revision.
linuxwolfKev: yes, a lot of have
linuxwolfbecause when you're dealing with 100k's to 1M's of users, it tend to need to
KevAnd elsewhere there's text that says, in a different context, that processing includes sending the reply.
ralphmI have to eat now
ralphmto be continued
linuxwolfI need to get back to my day job
KevOK, I found that 6121 says that IQ processing includes sending the reply stanza when the request is sent to the bare JID (8.5.2.1.2) - I imagine we can find similar text for the other cases.
XMPP Council - 2012-04-11