stpeterI still have 3 I-Ds to submit before the cutoff on Monday, sigh
m&mdo you want to skip on editor stuff then>
m&m?
stpeterit's OK, let's make some progress
m&malright
m&mfirst, something we're going to need to address
m&mKev found what he feels are substantive changes in XEP-0030
m&maround how xml:lang factors into uniqueness
stpeterright, I saw a message about that somewhere
stpeterdid we track down the check-in that modified this?
m&myes, sometime back in 2008
stpeterthis paragraph, eh? "Each <identity/> element MUST possess the 'category' and 'type' attributes specifying the category and type for the entity, and MAY possess a 'name' attribute specifying a natural-language name for the entity; the <identity/> element MAY also possess a standard 'xml:lang' attribute, which enables the entity to return localized results if desired (i.e., the <query/> element MAY include multiple <identity/> elements with the same category+type but with different 'xml:lang' values, however the <query/> element MUST NOT include multiple <identity/> elements with the same category+type+xml:lang but with different 'name' values)."
KevI think I suggested list discussion, mostly (disclaimer, I'm ill today, not firing on all cylinders).
KevJust to check we weren't about to include a substantive change without discussion.
KevIt looks like the change in question was ages old, but never included in a new revision.
KevAnd at some point it accidentally got regenerated into the current version, like the 313 stuff.
stpeterI'd need to review the discussion list history from June of 2008
stpeterand earlier
stpeterperhaps this was discussed as part of the run-up to 2.4 but was left out somehow.
KevI didn't do that. But yes, that would be sensible.
stpeterI can't recall.
KevI think I did a search of my mail archives for likely-looking queries and didn't find anything, but maybe I'm mistaking it for something else.
KevAnyway - my block was the temporary check-we-don't-accidentally-break-something type, not the this-must-not-happen type.
stpeterI don't have a quick answer.
KevI'm not sure that -1s are the appropriate mechanism here, but I don't think we have anything else available to say "Oh, wait, a minute, before we do that...", because otherwise the votes expire and it runs through on majority.
stpeterI might have been thinking this was a sensible clarification, I might have received some implementation feedback asking for clarification, it could have resulted from discussion about XEP-0115 somewhere, etc.
Kev-1 on something that seems broadly right feels wrong, but there we go.
m&mI'm now thinking of XMP Council's -1 as equivalent to the IESG's *DISCUSS*
stpetercf. Section 5.1 of XEP-0115
stpetere.g., "Sort the service discovery identities [15] by category and then by type and then by xml:lang (if it exists), formatted as CATEGORY '/' [TYPE] '/' [LANG] '/' [NAME]. [16] Note that each slash is included even if the LANG or NAME is not included (in accordance with XEP-0030, the category and type MUST be included)."
stpeterSo they have to be unique.
stpeterm&m: right, "let's have a chat about this"
stpetershall we take it to the list?
stpeteror is it already there? ;-)
m&mthe list discussion hasn't started yet
stpetersee also https://github.com/xsf/xeps/commit/bf110edfccddf0c22089df2861e0231bdb05c3a2#diff-5313e01f95bfb0963280ca4dfb497800L275
stpeterbut this was in XEP-0115 earlier
stpeterthis looks like the kind of thing that someone asked me about and we clarified it in two places
stpeterhowever, the constraint was already in XEP-0115 by then
stpeternow I'd need to go through the history of XEP-0115 too
stpeterprobably not the best use of our time here :-)
m&mprobably not (-:
stpetershall we move along to things we can settle now?
m&mlet's
KevIf this is already covered in the general lore by 115 and it was just missing from 30, let me know and I'll remove my -1. I was concerned that it might be adding in multi-lang without discussion.
m&mI do recall this being discussed for 115
stpeterBTW this xml:lang rule was not in version 1.4 of XEP-0115 and was added for version 1.5, published in February 2008
stpeterso we can look at the discussion leading up to 1.5
m&manyway … let's move on
stpeterof which there was much, I think - or at least lots of release candidate versions of 1.5 leading up to publication and approval in Feb 2008
stpeternod
stpeteryep
stpeternext conundrum? ;-)
m&mwe've got action we can take for 115, which is to get back to Kev on details, then decide what's next
m&ms/115/30/
m&mhttps://github.com/xsf/xeps/pull/40
m&mI believe this just needs to be merged into the next release
m&mnope, I need to reach out to Kev and MattJ about reviewing the latest changes
m&mI'll send that note out shortly
m&mhttps://github.com/xsf/xeps/pull/41
m&mthis is ready to take to council
m&min the past, this would have been an 1.yrcX interim release
m&mwell, tmp publish
stpeteralso BTW https://github.com/xsf/xeps/commit/6057a1fb42c18d1dddf07cdc0daa72696c327734#diff-5313e01f95bfb0963280ca4dfb497800 - that's where we made the change to 115
m&mstpeter: you're having a tough time moving on today (-:
stpeterm&m: agreed on #41
stpeterI am - now I'm fascinating by what happened here :-)
m&mI don't blame you … gone down a bunch of rabbit holes like this in the past myself
KevI've just been through (quickly) the 100ish post thread about 115. I'll remove my -1.
m&mnoted and thanks, Kev
stpeterKev: yeah lots of discussion in January 2008! http://mail.jabber.org/pipermail/standards/2008-January/thread.html
m&mfor #41, I suggest we ask the council if they're good going to draft from the changelog
stpetermoves on mentally :-)
KevMail sent.
m&mand render upon request
m&mtrying to avoid publish snafus
stpeteron https://github.com/xsf/xeps/pull/63 I asked Lance to make some fixes - I can ping him about that
m&mthanks
m&m#82 is on hold, waiting on Mr. Wild
m&msame with #83, actually (-:
SamWhited#83 I need to sit down and rework; I just keep forgetting to do it.
SamWhitedBased on list feedback and discussion from last week.
stpeterit's still on my list to go through XEP-0198 proposals but I haven't carved out the time yet
m&mso #84 on hold pending author
stpetersee above on needing to update a few Internet-Drafts :-)
m&mright
stpeteralso I'm way behind on a certain MUC/MIX discussion :-)
KevThat one just needs you to say "Kev, make the changes" and watch while I fail to find time :)
m&mI still haven't had time to read all of the changes to #91
m&mfailing to find time is a running theme
stpeteralways :-)
KevYes, sorry.
m&mwe're all guilty
stpeterLance says he'll update XEP-215 per #63
m&mcool
KevUnless we're desperately short of people I'll drop Council next year. Won't give me much extra time, but will cut back the amount of stuff I'm committing to and struggling with.
stpeterhttps://github.com/xsf/xeps/pull/94 LGTM as I replied there
stpeterKev: yeah I might need to do some recruiting it seems
stpeterI'm the only person who's put a hat into the ring for anything ;-)
m&mstpeter: agreed, just needs some massaging to get its editorial version
stpeterm&m ok good
m&m#95 is pending a response from stpeter I think
stpeteryeah I _just_ replied
m&mlooks like #96 is also ready for merging
stpeter+1 on #96
m&mI just took it over to track my failures (-:
m&m#98 is just fixing examples, and stripping extraneous whitespace.
m&mI think it's good to merge as an editorial revision
stpeteragreed
m&m#100 needs some council discussion still, I think
m&mneed to make sure that makes it onto their next agenda
SamWhitedCan we go ahead and merge #99 so I can use it? It works fine (at least on Linux; might be able to install things with homebrew on macs). People can improve it later if they want to support their system more generically.
m&mSamWhited: let me try it out … sorry, it kept slipping
stpeterI think it would be good to have a discussion on the list about deprecating stream compression entirely given the attacks that exist - or at least have a discussion about whether those attacks apply to XMPP, because if they do then deprecating stream compression would seem to be the right thing to do.
SamWhitedm&m: Many thanks :)
m&mstpeter: agreed
stpeteror at least, "might" be the right thing to do
m&mI'm not entirely sure these attacks are applicable to XMPP, given its stateful nature
SamWhitedhas left
m&mbut the discussion is good to have
SamWhitedI know we did a big security analysis when we implemented it; pretty sure the answer ended up being "as long as there are flushes on stanza boundaries on both ends it will be okay", but I'll see if I can't get the official report or discussion. Might have good info, I dunno.
SamWhiteds/flsuhes/full flushes/
m&mthat would be great, Sam
SamWhitedgoes to figure out who did that... it was shortly before I started here.
stpeter:)
stpeterthanks, Sam!
m&mso, uh, #106 seems contested to me (-:
stpeter106 or 104?
m&mgah, yeah 104
stpeterk
m&mI merged 0016 and 104 in an odd way
SamWhited<insert-evil-laugh-here>
stpeterI haven't looked at #106 yet
stpeter(FWIW)
stpeterSam suggested that I need to post in the privacy lists discussion
SamWhitedPlease and thank you :)
m&mso, #106 is still pending author?
KevI think I suggested that Sam suggested that ... :)
SamWhitedindeed
stpeterI haven't been closely tracking that thread, but given that I've been the one slowly pushing forward with alternatives (invisibility and blocking commands), I think it's safe to say that I am not a huge fan of privacy lists - and we developed privacy lists originally to address a requirement that we misunderstood from RFC 2779 way back in the early days of the XMPP WG!