[Standards] Council Minutes 2021-08-11

Jonas Schäfer jonas at wielicki.name
Wed Aug 11 15:43:34 UTC 2021


https://logs.xmpp.org/council/2021-08-11#2021-08-11-9c0056346fa591e6

1) Roll Call

Emerging from a horrifying reading, Jonas opens the meeting a tad late.

Present: Jonas, Zash, Daniel, Georg

2) Agenda Bashing

None.

3) Editor’s Update

- Pubsub Caching Hints have been accepted as New as per council vote
- The Moved 2.0 protoxep has been merged into '283 and authorship has been 
transferred to MattJ as discussed.

4) Items for Voting

None.

5) Pending Votes

- Everyone except Dave on ProtoXEP
  https://xmpp.org/extensions/inbox/disco-feature-attachment.html

A lot of discussion following up on the mailing list thread and the discussion 
in xsf at . An opinionated summary by Jonas is available in the thread [1].

Referring to the discussion in xsf@ [2], Jonas changes his vote to -1, with 
the following rationale, quoted verbatimly:

> - Any disco#info feature needs to be backed by some kind of implementation 
text
> - Even though for some combination of features the implementation may be 
obvious, it should still be written down somewhere, because obvious doesn't 
really work
> - If there is text backing the implementation of a combination of two 
features, that is the obvious place to declare a disco#info feature string
> - If there is a place where a disco#info string is written down which needs 
to be read by implementors anyway, there is no benefit from having a way to 
construct such a string; an opaque string match is required in the 
implementation anyway.
> and to bring this to the point which IMO makes this -1-worthy: it misleads 
implementations and specification authors to think that they can just slap 
together two feature strings and it will be immediately clear what is supposed 
to happen there.

Daniel notes that while Jonas' concerns may be valid and he even shares them, 
they may not completely warrant a -1 from his perspective (while respecting 
Jonas' choice).

Georg adds that introducing a semantic separator in an opaque string is 
problematic.

Jonas explicitly acknowledges that there is a problem to be solved regarding 
the discoverability of optional RSM for various protocols. He changes his vote 
to -0.

Dave, however, is convinced of the arguments and changes his vote to -1, with 
the suggestion to resolve this by explicitly writing down the missing 
interactions and feature combinations for RSM + * in separate documents to 
solve the problem "for now".

With that, the ProtoXEP is vetoed (but see [1]).

6) Date of Next

Everyone in for +1w.

7) AOB

None.

8) Ite Meeting Est

Thanks everyone.


   [1]: https://mail.jabber.org/pipermail/standards/2021-August/038490.html
   [2]: https://logs.xmpp.org/xsf/2021-08-09#2021-08-09-4407b454a06caebc ff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20210811/59839387/attachment.sig>


More information about the Standards mailing list