No subject

Fri Feb 11 05:14:17 PST 2011

way it 
would be set. But since that is draft we can change that so that it
more sense.
> > ofdT.Channel.Interfaces.Securable.EncryptionState(u)=0 {PROPOSED}
> Moved from the Encryptable proposal, presumably?

Yes and this may be better than the other methods above.
> >
ofdT.Channel.Interfaces.Securable.AuthenticationChannel(o)=ofdT.Channel.Interface.OTRAuthentication {PROPOSED}
> I assume you mean "the object path of a channel implementing
> OTRAuthentication"?

Yes, how would I properly show that for the spec?
> For generic E2E support, this would in fact have to be the object path
> a channel implementing both ofdT.Channel.Type.PeerAuthentication and
> interface mentioned in the EncryptionInterface property (which would
> be either OTR or XTLS to start with).

OK, thank you, but how should it look?
> > Please note: I am recommending that
> > {DRAFT} be renamed, or that some of the properties and methods be
> > to ofdT.Channel.Interfaces.Securable as DRAFT properties.
> Encryptable should indeed be called Securable - I made that change
> adding a partial version of it to the spec. For E2E support, you'll
> need the rest of the interface.

I agree and I like what you had added so far, just hoping to enhance it
> The DRAFT thing only works at a per-interface granularity, so the way
to do
> this would be to have something like this:
> ofdT.Channel.Interface.Securable (stable)
> ofdT.Channel.Interface.Securable.DRAFT (not stable)
> and move properties from the draft to the stable one as they become

OK I appreciate that insight and will make sure I type it correctly in
the spec.
> > 1. git://  My git branch for
Spec, re-based with Origin.
> For those following along at home, the web interface for that branch
> <>. Some quick notes about
> Your commits that say "Re-basing the file forward" seem to have lost
> original commit messages? Commit messages should briefly describe what
> (first line) and why (subsequent lines, after an empty line). Browse
> through the git history to see how they work in practice.

I fixed much of this by not rebasing.
> You seem to have committed the conflict marker lines (starting with
> =======, >>>>>>>), which isn't how they're meant to work (and will
> processing of the XML). When you get conflict markers, it means that
> made in one commit conflicted with changes from another commit, and
> couldn't work out what the desired result is. The intention is that
you work
> out how to merge the two sets of changes ("resolve the conflict"),
> the conflict markers and commit the result.
> For instance, if a commit from you and a commit from Cosimo both added
> text, the right conflict resolution might be to add both bits of text
- unless
> your text and Cosimo's text contradict each other or are redundant, in
> case you might choose one and delete the other.

OK I understand a little better, but as you have seen GIT is not my
strong suite,
perhaps in the future I will get better with GIT.
>     S

-----------Next is the second Email from Sjoerd----------------

> On Mon, 2011-01-03 at 11:48 +0000, Simon McVittie wrote:
> > On Wed, 22 Dec 2010 at 03:11:19 +0430, WolfRage wrote:
> > > My purpose here is to patch this bug #296867 (Launch Pad) which is
> > > #16891 on the Free Desktop Bugzilla.
> > 
> > FWIW, Telepathy's official bug tracking is via, so
we generally
> > consider fd.o bug numbers to be the important one; Launchpad bugs
> > specific to Ubuntu (or other projects hosted on Launchpad, which
we're not).
> > 
> > We usually do this sort of discussion on a fd.o bug report so it's
easier to
> > find (mailing list archives split by month aren't very useful for
> > projects). If you don't mind, I'll direct subsequent discussion to
> > relevant bugs - anyone who's interested in following it can add
themselves to
> > the bugs' Cc lists.
> > 
> Yeah, but people don't. I'd really prefer it if we used the
> to get at least a rough consensus and afterward have the details
> out on bugreport. Mailinglists really have a much higher visibility
> people so are easier to take part in for the casual observers that
> want to subscribe to lots of bugs :)

Hopefully posting in both areas will suffice and will not bloat the bug
too much. 
> -- 
> Sjoerd Simons <sjoerd.simons at>
> Collabora Ltd.

In closing, I will be updating cosimoc's spec and will post that to my 
GIT in the coming days, and we will change it as we go. Because 
I have enough of a start that I should begin putting it all into
Looking forward to all replies and thank you all for your help. 

- -
Quote: "Opportunities multiply as they are seized." "Can you imagine
what I would do if I could do all I can?" Sun Tzu, The Art of War. 

Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit

  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
First sorry for the long delay between emails. I was traveling and once I did get home I needed time to adjust to the new addition to the family. I also had to catch myself back-up to speed on OTR and Telepathy.<BR>
I am going to respond to all three of the emails that I received back all at once using the standard notation, hopefully this will bring every one back up to speed. Sorry for the overly long email. <BR>
I will also be posting this working email to the bug post, bug #16891, which should meet everyones requirements.<BR>
&gt; &gt; On Wed, 2010-12-22 at 03:11 +0430, WolfRage wrote:<BR>
&gt; &gt; Hello Developers of Telepathy,<BR>
&gt; &gt; <BR>
&gt; &gt; This is the beginning of many emails to come as we discuss and iron out the details of OTR support in Telepathy.<BR>
&gt; <BR>
&gt; \o/ :)<BR>
&gt; <BR>
&gt; &gt; This is my thought process or plan so far: If the CM that is being used<BR>
&gt; &gt;&nbsp; has OTR built into then OTR will be available, but not started, it can<BR>
&gt; &gt;&nbsp; be activated via the D-Bus. By available I mean that the CM will<BR>
&gt; &gt;&nbsp; provide the preferences below signifying that the capability for OTR<BR>
&gt; &gt;&nbsp; exists. User's will have preferences implemented through:<BR>
&gt; <BR>
&gt; Hard to look at things just by the property names, especially for those<BR>
&gt; on the list that haven't discussed things with you on the telepathy irc<BR>
&gt; channel :) (btw it's org.freedesktop.Telepathy.Connection, not<BR>
&gt; Connections)<BR>
I felt this was the best way to discuss the properties, as it is the way <BR>
that I was introduced to them. Also if some one seriously wants to provide input<BR>
to the OTR portion of telepathy I feel they should take some time to understand<BR>
the architecture of telepathy as I have. Also thank you for the correction I will<BR>
use the correct property in the future.<BR>
&gt; <BR>
&gt; &gt;&nbsp; org.freedesktop.Telepathy.Connections.Interface.OTR.Advertise(b)<BR>
&gt; &gt;&nbsp; {PROPOSED}<BR>
&gt; <BR>
&gt; This is, i assume, about actively advertising OTR in direct text chat by<BR>
&gt; using the spaces and tabs morse code thingy (and not about advertising<BR>
&gt; it in, say, your xmpp disco capabilities)?<BR>
Yes, this will decied whether or not that happens as a setable property, defaulting<BR>
to false.<BR>
&gt; <BR>
&gt; &gt;&nbsp; org.freedesktop.Telepathy.Connections.Interface.E2ESecurity.Opportunistic(b)<BR>
&gt; &gt;&nbsp; {PROPOSED}<BR>
&gt; <BR>
&gt; And this one would be about opportunistically enable E2E security<BR>
&gt; without the user asking for it.<BR>
Advertise will be to have the program show it has OTR capabilities. Opportunistic will<BR>
tell the system to enable OTR if the other program Advertises OTR. <BR>
&gt; <BR>
&gt; <BR>
&gt; &gt; Default settings for the Securable properties of a OTR aviable channel will be:<BR>
&gt; &gt; org.freedesktop.Telepathy.Channel.Interfaces.Securable.Encrypted(b)=FALSE<BR>
&gt; &gt; org.freedesktop.Telepathy.Channel.Interfaces.Securable.Verified(b)=FALSE<BR>
&gt; &gt; org.freedesktop.Telepathy.Channel.Interfaces.Securable.Upgradeable(b)=TRUE<BR>
&gt; &gt; org.freedesktop.Telepathy.Channel.Interfaces.Securable.EncryptionRequired(b)=FALSE {PROPOSED}<BR>
&gt; &gt; org.freedesktop.Telepathy.Channel.Interfaces.Securable.EncryptionInterface(s)=&quot;OTR&quot; {PROPOSED}<BR>
&gt; <BR>
&gt; Does this refer to yet another interface on the channel that indicate<BR>
&gt; some OTR specific bits about the encryption ? And if so which ones?<BR>
Securable has been added by Simon and so I am simply extending his interface with <BR>
a few more properties for OTR.<BR>
&gt; <BR>
&gt; &gt; org.freedesktop.Telepathy.Channel.Interfaces.Securable.EncryptionState(u)=0 {PROPOSED}<BR>
&gt; &gt; org.freedesktop.Telepathy.Channel.Interfaces.Securable.AuthenticationChannel(o)=org.freedesktop.Telepathy.Channel.Interface.OTRAuthentication {PROPOSED}<BR>
&gt; <BR>
&gt; That should just be pointing to a channel object path, not an interface.<BR>
OK, I was just following the convention created by Cosimoc. I will correct this.<BR>
&gt; <BR>
&gt; As a general nitpick i'm not sure if Securable isn't too general,<BR>
&gt; something that would indicate that this is e2e security would be good.<BR>
I am willing to change it, but I think this will be a larger discusion with Simon. <BR>
&gt; <BR>
&gt; &gt; The Object org.freedesktop.Telepathy.Channel.Type.PeerAuthentication<BR>
&gt; &gt;&nbsp; {DRAFT} will be inherited by<BR>
&gt; &gt;&nbsp; org.freedesktop.Telepathy.Channel.Interface.OTRAuthentication<BR>
&gt; &gt;&nbsp; {PROPOSED}<BR>
&gt; &gt; <BR>
&gt; &gt; The Object org.freedesktop.Telepathy.Authentication.Proposal {DRAFT}<BR>
&gt; &gt;&nbsp; will be inherited by<BR>
&gt; &gt;&nbsp; org.freedesktop.Telepathy.Authentication.Proposal.OTR {PROPOSED}<BR>
&gt; <BR>
&gt; Why is there a need for OTR specific interfaces here? How does OTR<BR>
&gt; autthentication/verification differ from say XTLS? Also if we're calling<BR>
&gt; the channel property Verified we should probably use that jargon in<BR>
&gt; these names as well.<BR>
This is a tough one to answer, as I have briefly learned about XTLS, but<BR>
my focus is on OTR. However I do believe that there are many differences,<BR>
for one the handshake is very different from that of XTLS. OTR conducts it's<BR>
handshake in plaintext and continues to establish the secure stream completly<BR>
on top of the chat, not as a seperate stream. So the protocol for the two<BR>
are quite different in both behavior and initiation. <BR>
&gt; &gt; <BR>
&gt; &gt; Please note: I am recommending that<BR>
&gt; &gt;&nbsp; org.freedesktop.Telepathy.Channel.Interfaces.Encryptable {DRAFT} be<BR>
&gt; &gt;&nbsp; renamed, or that some of the properties and methods be moved to<BR>
&gt; &gt;&nbsp; org.freedesktop.Telepathy.Channel.Interfaces.Securable as DRAFT<BR>
&gt; &gt;&nbsp; properties.<BR>
&gt; <BR>
&gt; That's fine that's why it's a draft.<BR>
&gt; <BR>
&gt; &gt; I am looking for feedback on what people's thoughts on this plan so far<BR>
&gt; &gt;&nbsp; are, also any suggestions and ideas that people have for input will be<BR>
&gt; &gt;&nbsp; reviewed by myself. <BR>
&gt; &gt; <BR>
&gt; &gt; I still have a lot of developer reading to do, I have been working my<BR>
&gt; &gt;&nbsp; way into and through the documentation for OTR, and Telepathy. I also<BR>
&gt; &gt;&nbsp; need to do some code familiarization for Butterfly, but things are<BR>
&gt; &gt;&nbsp; progressing smoothly as I have time I will continue to absorb all that<BR>
&gt; &gt;&nbsp; I can. I have so far taken the e2e-encryption spec branch that was<BR>
&gt; &gt;&nbsp; created by cosimoc and re-based it against the current spec branch. I<BR>
&gt; &gt;&nbsp; will continue to keep my branch up to date as I work, I hope that<BR>
&gt; &gt;&nbsp; re-base at least once a month, to reduce the headaches when we finally<BR>
&gt; &gt;&nbsp; to try to merge the OTR branch back in.<BR>
&gt; <BR>
&gt; Please don't take the big-bang approach, start requesting merging for<BR>
&gt; bits and pieces ASAP. It's fine to have DRAFT specification in<BR>
&gt; telepathy-spec and ditto in CMs. For the process to work well, merging<BR>
&gt; bits and pieces that can be reviewed is important :)<BR>
To be honest I did not understand this comment, completely. I think I am <BR>
only scratching the surface of what needs to be done. So far I am only<BR>
doing spec work, which is what I was told should be done before I code.<BR>
I agree with that as it will reduce the errors and the number of changes<BR>
that I make to my code. Which hopefully will make the code stable faster.<BR>
But once this email is underway, I will begin typing up the code changes,<BR>
and then get them to you and the others for review.<BR>
&gt; <BR>
&gt; &gt;&nbsp; There is obviously still lots<BR>
&gt; &gt;&nbsp; of work to be done just on Spec alone before I begin to program<BR>
&gt; &gt;&nbsp; anything. I plan on programming support for OTR in Butterfly CM first<BR>
&gt; &gt;&nbsp; as it is programmed in python, the language I am most comfortable,<BR>
&gt; &gt;&nbsp; then I will port it to Haze (libpurple) and latter to the other CM's. <BR>
&gt; <BR>
&gt; <BR>
&gt; <BR>
&gt; -- <BR>
&gt; Sjoerd Simons &lt;<A HREF="mailto:sjoerd.simons at">sjoerd.simons at</A>&gt;<BR>
&gt; Collabora Ltd.<BR>
Thank you Sjoerd for your comments. <BR>
-----------Next is the Email from Simon----------------<BR>
&gt; On Wed, 22 Dec 2010 at 03:11:19 +0430, WolfRage wrote:<BR>
&gt; &gt; My purpose here is to patch this bug #296867 (Launch Pad) which is bug<BR>
&gt; &gt; #16891 on the Free Desktop Bugzilla.<BR>
&gt; <BR>
&gt; FWIW, Telepathy's official bug tracking is via, so we generally<BR>
&gt; consider fd.o bug numbers to be the important one; Launchpad bugs are<BR>
&gt; specific to Ubuntu (or other projects hosted on Launchpad, which we're not).<BR>
I understand, I was simply stating that I filed my bug via Launchpad and that<BR>
is the bug that I initially set out to fix. I do understand that telepathy<BR>
is not a launchpad project, and will use the Free Desktop bug number from now<BR>
&gt; <BR>
&gt; We usually do this sort of discussion on a fd.o bug report so it's easier to<BR>
&gt; find (mailing list archives split by month aren't very useful for long-running<BR>
&gt; projects). If you don't mind, I'll direct subsequent discussion to the<BR>
&gt; relevant bugs - anyone who's interested in following it can add themselves to<BR>
&gt; the bugs' Cc lists.<BR>
OK I will post this and future discussion there as well and I agree mailing-list<BR>
can be hard to follow.<BR>
&gt; <BR>
&gt; You may find it easier to discuss things in email / on bugs if you abbreviate<BR>
&gt; org.freedesktop.Telepathy to ofdT throughout :-) I've done that when quoting<BR>
&gt; you, for a bit more clarity.<BR>
Glad to not have to type out ofdT any more thanks for the abreviation. <BR>
&gt; <BR>
&gt; &gt; ofdT.Connections.Interface.OTR.Advertise(b) {PROPOSED}<BR>
&gt; <BR>
&gt; (It's Connection, not Connections.)<BR>
Noted, thank you.<BR>
&gt; <BR>
&gt; This would presumably be a ConnectionManager parameter [1] with the<BR>
&gt; Conn_Mgr_Param_Flag_DBus_Property flag indicating that it's also the name of<BR>
&gt; a D-Bus property [2]?<BR>
&gt; <BR>
&gt; [1] &lt;<A HREF=""></A>&gt;<BR>
&gt; [2] &lt;<A HREF=""></A>&gt;<BR>
I will need to research this and get back to you.<BR>
&gt; <BR>
&gt; &gt; Default settings for the Securable properties of a OTR aviable channel<BR>
&gt; &gt; will be:<BR>
&gt; <BR>
&gt; (D-Bus terminology: these are properties.)<BR>
&gt; <BR>
&gt; &gt; ofdT.Channel.Interfaces.Securable.Encrypted(b)=FALSE<BR>
&gt; &gt; ofdT.Channel.Interfaces.Securable.Verified(b)=FALSE<BR>
&gt; &gt; ofdT.Channel.Interfaces.Securable.Upgradeable(b)=TRUE<BR>
&gt; <BR>
&gt; (It's Channel.Interface, not Interfaces.)<BR>
Noted, thanks.<BR>
&gt; <BR>
&gt; Upgradeable=TRUE doesn't seem to tell us whether it's possible to make<BR>
&gt; Encrypted become true, or whether it's possible to make Verified become true,<BR>
&gt; or both. Perhaps Encryptable, Verifiable as separate properties?<BR>
When I was thinking of these properties, I think that Encrypted tells us if the channel<BR>
is currently encrypted, same with verified. But Upgradeable indicates that they can<BR>
be encrypted.<BR>
I created them to use more boolean values and less unsigned integer values. <BR>
We discussed this as a better way to limit the choices for a property.<BR>
These would replace ofdT.Channel.Interface.Encryptable.DRAFT.EncryptionState and ofdT.Channel.Interface.Encryptable.DRAFT.EncryptionStateChanged<BR>
&gt; <BR>
&gt; &gt; ofdT.Channel.Interfaces.Securable.EncryptionRequired(b)=FALSE {PROPOSED}<BR>
&gt; <BR>
&gt; This is presumably requestable (includable in a channel request) but can't<BR>
&gt; otherwise be changed?<BR>
&gt; <BR>
&gt; I'm not sure that we need this property - we could just say that putting<BR>
&gt; Encrypted=TRUE in a channel request means encryption is required? In practice<BR>
&gt; the recommended thing would be to say Encrypted=TRUE, Verified=TRUE (to require<BR>
&gt; both), or not mention either of them (to have the default behaviour -<BR>
&gt; opportunistic encryption if you don't mind server-side logs becoming useless,<BR>
&gt; or no encryption if you want server-side logs to be useful).<BR>
Interesting, I felt that the two properties would only be set to true once that<BR>
had been confirmed, that is the way Cosimoc intended any ways.<BR>
But for EncryptionRequired, this would be false, as OTR can encrypt virtually<BR>
any chat(IM) protocol. But you are right it may not be needed. <BR>
&gt; <BR>
&gt; I suppose if you'd enabled opportunistic encryption, it might even make<BR>
&gt; sense to say Encrypted=FALSE in a channel request, to turn off opportunistic<BR>
&gt; encryption for this one channel (so that it can usefully be logged by your<BR>
&gt; server), but that's pretty obscure.<BR>
&gt; <BR>
&gt; &gt; ofdT.Channel.Interfaces.Securable.EncryptionInterface(s)=&quot;OTR&quot; {PROPOSED}<BR>
&gt; <BR>
&gt; Shouldn't the value of this property be a D-Bus interface name, such as<BR>
&gt; ofdT.Channel.Interface.OTRAuthentication?<BR>

More information about the telepathy mailing list