Here is a link to the rendered version: https://geekplace.eu/xeps/xep-jet/xep-jet.html
Greetings vv Am 06.09.2017 um 18:46 schrieb Paul Schaub: > > Hello everyone! > > To get back to topic: I made some changes based on your feedback. > Basically my plan is to split JET up into a main XEP and some > subprotocols. > > As Daniel suggested, JET will only contain reusable stuff and has no > more mentions of OMEMO and OX. Instead I used "stub" encryption > methods (like it is done with transports in XEP-0166 for example). > > Clients now have to cache the TS until the end of the Jingle session. > I'm not sure, whether this is long enough to (for example) resume > interrupted file transfers, but since JET is designed to be used not > only with file transfer, I found this a reasonable decision. > > There is a new section about ranged transfers. This also covers how > resumed file transfers are handled. > > Last but not least there is now a section about how to determine > support. I'm not quite sure, if I got the wording right on the "stub" > encryption method. Please let me know, if you know how to improve that :) > > The next days I will start working on JET-OMEMO. Maybe Daniel knows a > good way to encrypt TS rather than treating it as a message body? > Also, if someone wants to get involved and think about a proper JET-OX > specification, please feel free to leave me feedback and suggestions! > > My changes can be found here: > https://github.com/vanitasvitae/xsf-xeps/blob/jet/inbox/jet.xml A > rendered version follows soon. > > I'm not sure, whether I should open a new PR at this stage. Any > thoughts on that? > > Greetings vv > > Am 01.09.2017 um 11:38 schrieb Jonas Wielicki: >> On Freitag, 1. September 2017 11:19:29 CEST Daniel Gultsch wrote: >>> What you are describing as incubating can be experimental. But in that case >>> we need to bump XEPs to draft sooner >> What about lowering the deferral period to 6 months instead of 12? Would >> that >> help to encourage movement to Draft? >> >>> In any case 'experimental' should not be a mix of XEPs that can't actually >>> be implemented (PAM, JET) and XEPs that are working good enough and are >>> actually widely implemented (like MAM) >> +1. This is also a good thing for PR reasons I think. >> >> kind regards, >> Jonas >> >> >> _______________________________________________ >> 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] > _______________________________________________
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
