On 06/10/2013 04:15 PM, Hans-Christoph Steiner wrote: > > On 06/10/2013 06:45 PM, Paul Wouters wrote: >> On Wed, 5 Jun 2013, Hans-Christoph Steiner wrote: >> >>> Rate limiting will affect both XMPP in-band and OTR in-band the same. Only >>> an >>> out-of-band file transfer would get around that. So we'll need to find a >>> way >>> to deal with that gracefully regardless of whether its in-band XMPP or OTR. >> >> Why not provide a URI that defines the transport mechanism? If we are >> now already discussing the limits of one kind of file transfer >> mechanism, we're bound to need different ones over time. >> >> Providing a URI could also mean I can encrypt it and put it up on an ftp >> server. >> >> Paul > > I like that idea, so you'd have something like: > > XMPP-side-channel:// > XMPP-in-band:// > otr-in-band:// > https:// > ftp:// > sftp://
This seems to fit with the idea to have HTTP-like headers and verbs. So you could do something like: OFFER otr-in-band:/filename1.ext and if peer approves, their user-agent does: GET otr-in-band:/filename1.ext > > etc. > > .hc > _______________________________________________ > OTR-dev mailing list > OTR-dev@lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > _______________________________________________ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
