KevI'm fine with the idea of this, and the implementation, except that section 4 (update namespaces) is wrong.
stpeterKev: how do you think we should handle the namespace versioning?
KevThe namespace should only be updated if there's an incompatible schema change (or usage change).
KevElse we have the situation like:
Kevmd5 is MAY, SHA1 SHA2 are MUST. SHA3 comes out and the XEP then becomes the same but with SHA3 as MUST (for example).
KevNow someone who implemented it yesterday is unable to interop with someone implementing it tomorrow, even though they support several MTI hashes in common.
Kev(Because the namespace has changed)
stpeterright
stpeterone question is: do we need a way to discover which hashes the other party supports?
KevSo I think you use the hashes you support, and if the other side supports them great, otherwise you can't interop.
stpeterI might agree that changing the namespace might not be the best way to perform that discovery
Kevstpeter: Is the assumption that you only send one negotiated hash, or that you send those you support?
stpeterKev: it might depend on the protocol
KevI was assuming you'd send those hashes you support.
KevMaximum interop, for not a huge amount of overhead (unless we start talking about supporting hundreds of hashes).
MattJYeah, discovery brings just a small optimisation (which may not actually be worth it in some cases)
stpetersure, but why eat of processor time to generate hashes that the other party doesn't support? (e.g., in file transfer)
stpeters/of/up/
Kev(This is notable not suitable if you're doing something like password hashing, where having multiple is a vulnerability, of course).
Kevstpeter: Right, in that case we probably want negotiation.
KevWell, I say negotiation.
KevI mean caps.
stpeterso if I want to send you a bunch of large-ish files, I don't want to figure a checksum for SHA1, SHA2, and SHA3
KevRight.
stpeterso discovery might be good
stpeterbut
stpeterwe don't need a namespace change to do that
KevSo I have sha1, sha2 in my caps. You know what I support, pick the one that suits you best, use it.
KevRight.
Zashhas joined
stpeterwe could have separate disco features
KevSo I think we add discovery, and remove namespace changes.
stpeterthat would work for me
MattJ+1
KevGreat.
MattJI have a small proposal, but I haven't thought it out yet
linuxwolfhas left
linuxwolfhas joined
stpeterMattJ: proposal for...?
MattJThis XEP
MattJJust typing :)
stpeterheh ok
MattJ(if only we had a way of transmitting my text as I typed...)
KevYes, that could get hilarious in MUCs :)
MattJInstead of a <hash> element for each algorithm, what if that element contained all the algorithms?
Kev85 in MUCs would be sensible, though.
KevMaybe Swift should start doing that.
MattJKev, it should - I'm pestering for Gajim support
MattJA number of clients are doing it now
MattJ(finally)
MattJMaybe an example of my hash idea would be clearer
MattJIt's not so different really, except in the implementation you just have to iterate over the child elements of a single tag
KevOh, I see.
MattJrather than cherry-pick all elements with the hashes namespace from amidst the rest
KevRight, that's neater if you have multiple hashes, yes.
KevRight, although your library's going to be doing that for you.
MattJYeah, sorry, I'm lazy :)
stpeteryou say potayto, I say potahto
MattJKev, depends how high-level it is, also - I write the library, so no it isn't :)
stpeternods
stpeterI like that a bit better
stpeterso I'll make version 0.0.2
MattJThanks
KevThanks Peter.
KevSo, has anyone read any of http://xmpp.org/extensions/inbox/realtimetext.html ?
KevI have a longish list of issues with it, but I don't think they're sufficiently fundamental to block publication - and it's written like a XEP now, mostly, which makes life much better.
MattJNot the new version in detail, and I'm not sure I'm capable right now
stpeterI haven't done so
MattJIt didn't make me go "aargh" like the first one did though
Kev:)
stpeterheh
MattJIf you're happy with publication then I probably am too, but I'll take time this week to review it and put my thoughts on-list (assuming we won't vote until next meeting?)
linuxwolfhas left
linuxwolfhas joined
stpeterI'll do the same
linuxwolfhas left
KevWe can't vote until next meeting, indeed.
KevI'll post my thoughts to the list in advance.
stpeterexcellent
stpeterany other non-business for discussion in this non-meeting? ;-)
stpeterI just updated XEP-0233
stpeterand I poke some SASL people about reviewing it
stpeterpoked, that is
KevNot according to the agenda.
KevUnless someone else has something.
stpeterso I might request a Last Call about that one before long
MattJiirc I read an email where stpeter said we could discuss something at the meeting
MattJtries to find it
stpeteryes
stpeterfile transfer
stpeterif we plug this hashes stuff into XEP-0234, then 260 and 261 are left waiting
MattJAh, ok
stpeterso I wonder if it makes sense to take care of those first
stpeterwe said we'd bundle them with 234
bearhas left
stpeterbut they're basically done, I think
bearhas joined
stpetersomething to discuss next time, I suppose
stpetershall we schedule the next meeting?
KevNext Wednesday, presumably.
MattJFine with me
stpeterWFM
KevRighty.
stpeterupdates the hashes spec and adds Matthew and Kev as authors
KevAww shucks.
Kev(And thanks)
stpeter:)
KevRighty, I guess we're done with the non-meeting, then.
stpeteryep
stpeterupdates the calendar
KevThanks.
KevAnd thanks both for turning up!
stpeterwe're here for you!
MattJHeh, thanks :)
linuxwolfhas joined
stpeterhmm
stpeterit would be handy to reference hash algorithms like this... urn:iana:hash-function-text-names:sha-256
stpeterI've poked IANA about setting up a urn:iana namespace so that we don't have to manage a separate set of disco features in the urn:xmpp tree for cryptographic hashes (although I don't see any great harm in doing so)
XMPP Council - 2011-06-22