http://logs.xmpp.org/council/2019-01-09/#16:00:55
Dave got around to writing an agenda, though it seems to have been missed by many as it was not sent to 'standards', but only to the 'council' mailing list (to which Jonas is, curiously, not subscribed - Kev offers to do the magic.) 1) Roll Call Present: Kev, Jonas, Link, Georg, Dave Dave and Jonas apologise for their absence last week. 2) Agenda Bashing Did Dave forget anything? Jonas wouldn't know as he hasn't seen the agenda. Georg suggests splitting PR #727 (item 6a) into individual LCs for process' sake. 3) Proposed XMPP Extension: Order-By - https://xmpp.org/extensions/inbox/order-by.html Georg thinks it's a very specific use case, and defines two hard-coded properties (creation and modification timestamp) for ordering on, whereas it would be cleaner to allow ordering by any field. Jonas and Dave point out that the properties are external to the items themselves. Jonas wants to discuss further with the author about points already raised. Georg wonders why the properties couldn't be embedded in the items - Jonas say servers must not modify items; Georg suggests the client could add the timestamps itself, but Jonas says the author dislikes this as it would allow them to be spoofed. Georg thinks it needs to be renamed to "PubSub MAM Retrieval Ordered by Creation or Modification." Dave noticed that it apples to MAM but doesn't really discuss it, and presumably also has an impact on RSM. Jonas says it doesn't impact RSM, but the server might have to use different identifiers in RSM to work correctly; Dave thinks that's worth thinking about and mentioning. Kev says it does interact with RSM, but 'impact' is a matter of interpretation. Kev would like to see this have a little more work before being published, but couldn't find a reason to veto. Jonas: [on-list] Georg: [on-list] (with fallback to -1: very specific use case; requires [implementation] changes to other XEPs) Kev: +1 (not keen on it, but it clears the bar-of-incompetence for Experimental) Link: [on-list] (still catching up on everything) Dave: +0 (reserve the right to change that while others are still on-list) 4) Outstanding Votes Dave doesn't imagine there are any. Georg mutters something about spreadsheets and doom. 5) Next Meeting 2019-01-16 1600 UTC Georg will be in a present-absent quantum superposition for the next few months, but hopes reality will collapse into one possibility in time for next week. 6) AOB 6a) Cleaning up Deferred items (wrt PR #727 - https://github.com/xsf/xeps/pull/727) Jonas says the PR can't be applied as-is, and proposes that Editor just closes it; if such process is desired, a modification to XEP-0001 is needed. Dave asks whether someone wants to take on changing the process, or does nobody care about clearing out old Deferred XEPs. Link believes Obsolete is the correct status for those three XEPs (and more, but let's start small.) Jonas says they would have to be Draft to allow for obsoletion; Dave notes Proposed->Rejected exists; Jonas agrees rejecting would also be an option. Dave would happily allow Deferred->Rejected, as it feels more accurate. Dave puts forward two questions: What do we want the process to be? and Who wants to draft the PR to XEP-0001? Jonas can do the PR to XEP-0001. Kev adds a third question: Is there a problem with Deferred XEPs staying Deferred? Jonas (as Editor) has no problem with this. Georg suggests adding Proposed->Deprecated. Dave notes that Deferred is much the same as expired Internet Drafts in the IETF, which are sometimes 'un-expired' years later. Kev doesn't see a particular problem with something being Deferred for eternity, reflecting the actual state of "abandoned before advancement." Link would mainly like to solve the problem of people being expected to read Deferred XEPs (replete with a big red warning) because process is too slow. Georg, agreeing with Link, thinks 'Deprecated' is a stronger signal not to implement than 'Deferred.' Jonas says it's more worthwhile to tackle the XEPs that are worthy of advancement than those which are dead anyway. Kev asks if the problem is really one of rescuing XEPs from Deferred that shouldn't have been deferred, rather than moving them when they are abandoned - Link would like to do both in the end. Dave says moving an XEP from Deferred is easy, and isn't sure how to make that any faster. Jonas says the actually-abandoned XEPs aren't the actual issue. Link notes that fixing a typos in Deferred XEPs has moved them back to Experimental, and would like to avoid that; Jonas agrees. Georg says editorial changes shouldn't count; Jonas says it needs fixing, but is a separate issue - there are varying opinions (any change means someone cares enough, versus only non-editorial changes should un-defer) and maybe Board should clarify. Dave tries to move things along and requests that if someone cares they should take this to the standards mailing list; Georg pre-emptively volunteers Link; Link actively volunteers. Kev wouldn't oppose Deferred->Deprecated, but isn't sure it's worth the effort. 6b) PR #715 - XEP-0045: Add missing disco#info feature to example 4, 9, 78 and 218 - https://github.com/xsf/xeps/pull/715 Georg recalls that previous discussion ended with disagreement between the author and some council members over what would be the right thing. Dave thinks it became buried in discussion about whether disco#info responses should list support for disco#info (from PR #716 - https://github.com/xsf/xeps/pull/716). Link thinks fixing examples to match XEP-0030 is a no-brainer; Dave recalls that Council decided disco#info MUST be listed, in accordance with XEP-0030, therefore this PR should be applied to fix the examples. Georg assumes it will make the examples look more normative and less example-y; Dave thinks they will still look example-y, but will be more accurate. Jonas doesn't think it's relevant to the implementation of XEP-0045 and will just add noise. Georg thinks an example should focus on what's relevant to the XEP and not boilerplate from other specifications. Kev would prefer if disco examples listed only the parts relevant to their XEP. Dave is happy not to care, but would like to close this one way or another. Georg: -0 (I like my examples short and focused) Jonas: -0 Kev: -0 (Don't care) Dave: -0 Link: +1 Link thinks it would be useful to add "..." (indicating elision); Jonas and Georg think that would be great; Dave would be fine with it, and would consider it editorial. Jonas offers "<!-- ... -->" so as not to break schema validation; Dave and Georg give it the OK, as does Link. 7) Close That's all folks.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
