Hi, I think it would be good to concentrate on the task that this XEP wants to solve (its hard enough), and not invent new ones.
- No this XEP should not invent a new 0030 - No this XEP should not improve/destroy current crypto mechanics by adding various information's into the payload. If you feel this is necessary update the corresponding crypto XEP. This XEP should be a simple standard that tells developers what content to expect when decrypting a full stanza payload, and what to put into when encrypting. Nothing more. Regards Philipp Am Mo., 24. Juni 2019 um 23:38 Uhr schrieb Maxime Buquet <[email protected]>: > On 2019/06/24, Dave Cridland wrote: > > On Mon, 24 Jun 2019 at 20:11, Paul Schaub <[email protected]> wrote: > > > Am 24.06.19 um 19:04 schrieb Ненахов Андрей: > > > > So much for deniability. > > > > > > Yeah, I'd rather keep it flexible and let the encryption XEP which > > > defines a SCE profile decide, which fields to use and not to use. OX > for > > > instance should probably use the "full stack" of affix elements, while > > > OTR would stay away from most of them (except maybe timestamp). > > > > > I would rather everything used the same. > > I think the point of this XEP is to enforce only meaning of elements it > provides for other XEPs to use. > > As Paul said, I also think profiles of this XEP (other XEPs reusing SCE) > should define how these elements are used. Somebody might come up with > an encryption mechanism that doesn't fit our model of REQUIRED elements. > > -- > Maxime “pep” Buquet > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
