https://logs.xmpp.org/council/2021-04-14?p=h#2021-04-14-d547e271b8aac8b2
1) Roll Call
Present: Zash, Dave, Jonas, Georg, Daniel
2) Agenda Bashing
Georg would like to add an AOB about the XEP-0280 Last Call.
3) Editor's Update
* XEPs now have BibLaTeX citations, so that's nice
4) Items for Voting
None.
5) Pending Votes
Dave votes on "Deprecate XEP-0013 (Flexible Offline Message Retrieval)": +1
(acknowledging there are useful bits which aren't present in simple Blocking
and Invisibility)
Relieved, Sam dashes off to see what can be deprecated next.
All but Dave are pending on advancing XEP-0313 (Message Archive Management) and
all on XEP-0280 (Message Carbons).
Georg notes the lack of server developer feedback on the 'carbons:rules'
namespace; Dave adds that last week Georg suggested having strict rules on what
gets archived in 0313, which already exist in 0280, though there is no server
developer feedback on these (as Georg said) - Jonas casts the runes and invokes
the server developer summoning ritual; Zash mysteriously appears, as if he had
been present all along. Zash has probably already written that feedback
somewhere in a Prosody issue comment ("It's unclear to me what messages would
have IM payloads but are not be type = chat|normal|groupchat. We don't want to
carbon type=groupchat that happens to have chatstates for example." [1]), but
wonders whether the rules should be enshrined in both 0280 and 0313,
particularly when they will inevitably need to be updated to account for new
payloads in the future - Georg gives a fascinating lecture on the benefits of
namespace versioning.
Dave suggests separating the rules into their own XEP, then advancing 0280 and
0313, and have the new XEP reference those two; though Dave suspects some
people might be unhappy with advancing 0280 without such rules. Jonas doesn't
see an issue with separating them out from 0280, as they're 'scoped' in their
own namespace already. Georg refuses to advance 0313 until these rules are
written down somewhere. Daniel isn't sure they would both have the same rules -
Jonas doesn't think the new XEP would have to define the same rules for both,
and having a central place for routing rules in the pre-XMPP-2.0 world is a
Good Thing™; Georg is equally convinced they must not be identical; Zash adds
that it doesn't even make sense, as they apply to different subsets of stanzas,
though there will be some overlap. Georg surmises that, firstly, Someone™ needs
to write down the rules (which would require adequate server developer feedback
- Zash can repeat what Prosody does, which is believed to be sensible at this
time.)
Daniel isn't sure server developers care about the rules, but client developers
should know which messages they want and under which circumstances - Dave isn't
sure that's true, as both sides care, even if they have different
considerations. Kev's limited experience of clients trying to say what they
want storing is that it's a disaster. Georg is reminded of many a joyful night
spent debugging corner cases in search of answers to "why didn't that message
arrive on this device?!"
Jonas pleads for a way forward - Georg suggests that server developers should
be contractually obliged to respond to his emails - Jonas hopes Georg will also
be the one paying them. Dave believes that "what servers should store" is a
different issue to "how should clients obtain what is stored"; 0313
concentrates primarily on the latter, and seems to be stable and worthwhile -
Jonas agrees, but someone still needs to write down "what should servers store"
in a document. Dave questions whether it needs to be this document, and right
now - Georg believes so: not having this information in 0280 has caused many
years of frustration, incompatibility, and lost messages; Jonas doesn't think
it needs to be in 0313, but the issue was not having the information anywhere,
rather than it not being in 0280 specifically. Dave questions Georg whether
0280 and 0313 being in Experimental for so long has generated any confusion and
frustration - Georg's point is that the knowledge does already exist in a
distributed brain-cluster database, but not in a document, and continuing not
to write it down will only prolong the pain. Georg considers "what kind of
information will this query return" to be a very important part of a protocol.
Zash suggest that each new XEP could declare how it should affect
Carbons/MAM/etc, and then that could be summarised somewhere - Jonas thinks it
could be called "Routing Considerations" - Georg doesn't disagree in principle.
Zash offers to translate 'mod_carbons' into an email as feedback - Jonas hopes
that will make Georg happy - Georg would prefer that it was a delta on 0280
plus a rationale. Dave finds a nice corner in which to cry, silently, longing
for a possible former life as a sheep farmer.
Jonas votes on both 0280 and 0313: +1 (based on running code and it works good
enough)
Jonas thinks the rules can be written in a separate document, and any future
changes to such rules should go into a separate "Legacy Routing Rules"
document, which can be used as a reference to build a better IM-NG world for
great public good!
Georg checks when the votes expire - next week - Georg will sit on his vote on
0313 for another week, hoping that somebody will respond to his LC email [2].
Jonas encourages everyone to cast their votes on-list.
Zash still wants to do a sweep of previous LCs, but hasn't got to that yet.
6) Date of Next
2021-04-21 1500 UTC
7) AOB
Jonas checks that everyone is okay with the long meeting becoming even longer -
nobody starts a fight, but Zash is low on energy.
Concerning XEP-0280 (Message Carbons), Georg thinks bridge carbons should
probably go into its own XEP so it doesn't block advancement - Zash would
welcome a modern bridge XEP.
Georg also thinks that XEP-0334 (Message Processing Hints) is in a sad state,
but is included in 0280 - should we get rid of Hints altogether, and is that
possible without bumping 0280?
Additionally, Georg asks whether the stripping of the 'private' element can be
undone without bumping 0280 - Jonas doubts it - Georg argues that it's not
Draft yet - Zash asks whether it would break anything.
Jonas checks whether Georg means to get rid of Hints as a concept, or just
XEP-0334 - Georg thinks the concept of Hints makes sense in the context of a
respective XEP that's actually affected by them. Jonas doesn't see a problem
with using the relevant XML from 0334 and dropping the XEP, because
compatibility; doesn't see Carbons as something which must be perfect.
Dave thought a previous Council had effectively killed 0334 - Sam owns up to
vetoing the last time it was proposed for advancement: his rationale at the
time being that it would never be finalised because the scope was too vague,
and additional hints would be needed, or changes to existing hints, and it
would become stuffed with additions that have no other obvious home - Jonas
thinks that seems realistic.
Georg asks whether it makes sense to keep hints, with their semantics defined
inside the relevant documents, under a common namespace - Jonas isn't so sure,
though they should be kept in cases where they're already used and not change
their namespace for some sake. Georg asks, then, does it make sense to keep the
'no-copy' hint inside 0280 - Jonas thinks so - Georg doesn't recall a version
of Carbons that required the addition of 'no-copy' without also requiring
'private', but now a receiving server will strip 'private' and retain
'no-copy'. Jonas asks what problem Georg is actually trying to solve - Georg
says it's excessive XML bloat, plus consistency with his next point - Jonas
thinks IM-NG might be a better place to work on that, and the time already sunk
into this doesn't seem worth the gain, especially considering that Carbons is
only meant to be an intermediate solution.
Georg rephrases his question: does anybody on Council think a namespace would
be warranted if both 'no-copy' and "the receiving server SHOULD remove the
<private/> element before delivering to the recipient" were removed from 0280 -
Jonas thinks yes; Zash thinks yes in theory, but maybe not in practice (what
would break?) - Georg adds that it's still in Experimental - Jonas explains
that advancement of Carbons could be delayed for yet another six months with no
real gain. Georg doesn't think anything would break, and isn't even sure
servers are following that SHOULD - neither is Jonas, but he lacks the domain
knowledge.
Noting the time, Jonas suggests this will have to be continued next week.
8) Close
Thanks everyone, Tedd, and Västerbotten cheese.
Kev thinks that a client telling the remote server how to process a stanza,
changing which of the recipient's clients will receive it, while stripping that
instruction, is harmful - Georg fully agrees.
[1] https://issues.prosody.im/1486
[2] https://mail.jabber.org/pipermail/standards/2021-April/038283.html
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
