On 14.10.19 14:28, Georg Lukas wrote:
> * Florian Schmaus <f...@geekplace.eu> [2019-10-11 12:35]:
>> I am going to give feedback based on
>> https://op-co.de/tmp/xep-0423.html
>> which is, if I understood Georg correctly, the current state.
> 
> Yes, it is. Thank you very much for your feedback!
> 
>> There are two protocol extension evaluations that are currently missing:
>>
>> XEP-0114: Jabber Component Protocol → XEP-0225: Component Connections
>> XEP-0115: Entity Capabilities → XEP-0390: Entity Capabilities 2.0
>>
>> The right hand side of the arrows should probably be mentioned in "3.
>> Future Development" or probably even in § 2.
> 
> Both RHS XEPs are Deferred,

Which is irrelevant to this consideration. In fact, if anything, it is
an argument to include them to increase their visibility and the number
of implementations, which, in return, provide feedback, hence continuing
the standardization process.

> and I'm not sure what their actual state and
> practical relevance is.

Their practical relevance is very high: both are huge improvements of
their predecessors.

>> I would add a note that Jingle IBB is the most reliable transport, and
>> (I assume) hence the only Jingle transport explicitly mentioned, because
>> this is the first transport you probably want to implement, while noting
>> that it is the most inefficient transport.
> 
> I'd rather have such a note in XEP-0234, if it isn't there already (it
> mandates IBB already, BTW, so technically 0261 does not need to be
> mentioned in the CS).

If the jingle xep already spells it out, then there is indeed no need to
mention it in the compliance suites again.

>> And, of course, I miss XEP-0374: "OpenPGP for XMPP Instant Messaging"
>> from being mentioned in "3. Future Development".
> 
> I see your intent, but in the long term, I'm not sure how many E2EE XEPs
> we can put into the CS.

We are opening up an old discussion here: it is unlikely that we will
ever come up with a single E2EE XEP, since E2EE schemes tend to have
different properties. There is no one-size-fits-all. OMEMO and OpenPGP
are on opposite sides of the spectrum of encryption properties and thus
are not competing specifications. Therefore both should be mentioned.

>> - Remove "and related specifications" from the MIX reference, as it
>>   is just unnecessary noise.
> 
> That was mainly a reminder for me to put into place all the MIX XEPs, as
> there is a bunch, and I wrote that in a hurry.

Please do not mention all MIX XEPs in the compliance suite. The main
entry point to MIX is a single XEP, and this is the only one the
compliance suite should mention.
-
 Florian

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________

Reply via email to