Re: [Standards] Disco conflict between 30 and 163

[Simon McVittie]

On 26/08/14 15:10, Kevin Smith wrote:
> 30 says not to reply with disco to entities not authorised for your presence.

Should the server follow this pseudocode for a disco instead?

if target JID is bare:
# any IQ to user@host is expected to be replied to by the server
reply to it on the user's behalf, describing features of the
server and the account (but nothing about the logged-in
resources on that account, if any)

else if peer is authorized to see user's presence:
# any IQ to user@host/resource is expected to be replied to
# by that resource
forward message to the named resource so it can respond

else:


Regards,
S

Re: [Standards] Proposed XMPP Extension: JSON Containers

[Simon McVittie]

On 09/10/13 16:20, XMPP Extensions Editor wrote:
> Abstract: This specification defines an element to be used for encapsulating 
> JSON data in XMPP.

I don't see how the example given,


  http://example.com/user-queries";>

  { "name": "romeo" }

  


has any advantage over using


  http://example.com/user-queries";>
{ "name": "romeo" }
  


and the namespace owner (in this case example.com) documenting that the
payload of a {http://example.com/user-queries}query element is JSON. If
the recipient understands the http://example.com/user-queries namespace,
then they know that its payload is JSON, and can perform whatever
validation is required. If the recipient doesn't understand it, they're
not going to be able to do anything useful with it anyway...

It would be useful for the text and/or examples to indicate how the
embedding in XML interacts with characters that are reserved/special in
XML. For instance, my interpretation is that this message:


  
{ "name": "romeo", "age": "421", "status": "I >3 Juliet" }
  


is expected to be interpreted as equivalent to receiving this
application/json from a web server or whatever:

{ "name": "romeo", "age": "421", "status": "I <3 Juliet" }

If I'm right, I think it'd be good to use an example like this that
illustrates that point. If I'm wrong, then I don't see how it could work
in a generic XML parser.

> The data MUST be encoded as UTF-8 (though officially unspecified,
> this is the de facto encoding for JSON today).

The JSON RFC, RFC 4627, does in fact say "The default encoding is
UTF-8", and could be interpreted as implying that the only valid
encodings are UTF-8, UTF-16 and UTF-32 - it states that the pattern of
nulls in the first 4 bytes is sufficient to detect the encoding, which
is only true if common single-byte encodings like Latin-1 are not allowed.

In any case, if the JSON is character data in an XMPP XML stream, then
it has to be UTF-8, whether this XEP says it is or not. Non-UTF-8 can
only appear in XMPP XML if it's encoded in Base64 or something; or if
you're less concerned with the wire protocol and more concerned with
semantics, you could say that XMPP is a transport for (XML containing)
Unicode text (encoded in UTF-8 for the wire protocol), not bytes.

S
h

Re: [Standards] Updated Yabasta Protocol (E2E-related)

[Simon McVittie]

On 26/06/13 19:16, Jon Kristensen wrote:
> The OTR-inspired and end-to-end secure Yabasta protocol has received a
> significant update today. You can see the updated protocol at
> .

Why should implementers prefer this protocol over end-to-end TLS, such
as the XTLS RFC-draft? Sell it to us :-)

(I do like this better than OTR, because the payload is specifically an
extensible XMPP stanza, rather than being constrained to be
human-readable text in UTF-8 "optionally with HTML markup", whatever
that means.)

Most client implementers haven't implemented XTLS, and the RFC-draft for
it wasn't finished, because end-to-end security is a lot of work to do
well (or at least, that's why nobody has had time to implement it in
Telepathy). Is Yabasta any easier, bearing in mind that unlike XTLS, it
doesn't appear to be possible to use existing TLS libraries like GNUTLS,
NSS or OpenSSL to do the cryptographic bits?

> a service discovery feature item of "yabasta-protocol:0"

That's not an IETF-registered URI scheme, and neither are the various
XMLNSs in your mapping into XMPP. If you own yabasta.com,
http://yabasta.com/xmpp/0 might be a more appropriate URI, for instance.
(If you don't, please don't it in your examples :-)

You probably only need one XMLNS for the whole specification: only the
tuple (namespace URI, element name) needs to be unique.

Regards,
S

Re: [Standards] Proposed XMPP Extension: Chat Markers

[Simon McVittie]

On 31/05/13 12:13, Matthew Wild wrote:
> On 31 May 2013 12:04, Simon McVittie  wrote:
>> telepathy-gabble sets AMP attributes [...]
>> in the hope that servers will not consider them to be
>> eligible for offline storage. I don't know whether any servers actually
>> implement that, though...
> 
> Is that the only part of AMP that gabble uses?

Looks like it. Here is the extent of our AMP usage (in Wocky's
domain-specific-language for writing less painful XML literals as C
varargs):

#define GABBLE_AMP_DO_NOT_STORE_SPEC \
  '(', "amp", \
':', NS_AMP, \
'(', "rule", \
  '@', "condition", "deliver-at", \
  '@', "value", "stored", \
  '@', "action", "error", \
')', \
'(', "rule", \
  '@', "condition", "match-resource", \
  '@', "value", "exact", \
  '@', "action", "error", \
')', \
  ')'

Using AMP for this does seem like using a sledgehammer (or a bomb?) to
crack a nut. If I had some time to redesign Tubes, I'd make them a
Jingle application (and hence use IQs, which would avoid needing this).

S

Re: [Standards] Proposed XMPP Extension: Chat Markers

[Simon McVittie]

On 30/05/13 18:16, Matthew Wild wrote:
> Forgetting archiving completely for the moment, offline messages might
> do enough already, no? XEP-0160 doesn't actually have any
> recommendations about what to store or what not to store. It seems
> that servers are expected to identify things like chat states already
> (XEP-0085 says that servers "SHOULD NOT store them offline"). This
> doesn't seem like a good model, but it's what we currently have.

telepathy-gabble sets AMP attributes
 on at least some of its
non-chat messages (for instance those exchanged by its "Tubes" RPC
protocol), in the hope that servers will not consider them to be
eligible for offline storage. I don't know whether any servers actually
implement that, though...

S

Re: [Standards] TLS over OpenPGP

[Simon McVittie]

On 23/04/13 14:21, Daniele Ricci wrote:
> Clients will be using their OpenPGP keys to sign messages for one
> another

I hope you don't mean context-free signatures on individual IMs similar
to those in XEP-0027 ?

yeah I agree

In typical IM usage ("conversational" and without context, unlike email
which typically quotes relevant context), this makes you vulnerable to
replay attacks (e.g. an attacker can send a previously-signed "yeah I
agree" in response to something you didn't want to agree with) and
message-dropping (an attacker can drop intermediate messages, and the
recipient will never know that there was meant to be a message there).

XTLS 
and OTR both address this, by authenticating on a per-conversation
rather than per-message basis.

I suggest thinking about your threat model - who is the attacker and
what can they do? - before designing cryptographic protocols: otherwise,
it's easy to end up with a system that has gained more complexity than
actual security.

> I thought it could be useful to use the same keys to
> authenticate too - thus avoiding having two different keypairs (one
> for authentication, one for encryption/signing).

Conventional OpenPGP best-practice is to have one top-level keypair
(public + private) for certification (signing keys) and optionally
signing messages, a separate "subkey" for encryption, and optionally
additional subkeys that can sign messages but cannot certify (sign
keys). I'm led to believe that there are significant cryptographic
advantages in doing this, although I don't understand the finer details.

The "key ID" and "key fingerprint" that you see when doing keysigning
are the ID of the certification keypair, which is the one that ties
together the rest of the subkeys (by making a signed assertion that they
belong to the same person).

If you want identity based on OpenPGP, but authentication using X.509
(to take advantage of existing code), one way to do it is to have a
machine-readable OpenPGP-signed assertion of the form "please assume
that only I have access to the corresponding private key for the
following self-signed X.509 cert: [...]". Something like that, or a
subkey-based approach, would also have the advantage that an exploitable
bug in your XMPP software would only result in disclosure of XMPP
messages, and not a compromise of the OpenPGP key (and hence everything
else it had been used for).

S

Re: [Standards] FMUC master/slave

[Simon McVittie]

On 01/03/13 18:47, Mark Rejhon wrote:
> - A collection of laptops gets close to each other (WiFi, Bluetooth)
> - They all automatically join the same MUC

FWIW, telepathy-salut extends XEP-0174 (iChat-style link-local XMPP with
mDNS/DNS-SD) to support MUC-style chatrooms, using a UDP-multicast-based
protocol called "Clique" designed by Sjoerd Simons. It provides
consensus-based chatrooms (there is no "owner" without whom the room
cannot operate), causal ordering, and reliable message delivery
(inability to deliver a message to all participants within a reasonable
time causes a detectable error condition similar to an IRC netsplit).

The Sugar environment originating from One Laptop per Child used this
for serverless multi-user chatrooms, at least in early deployments (I
don't know whether they still use it).

The reference (only?) implementation of the protocol is open-source
(LGPL 2.1+). Unfortunately, the protocol documentation[1] is woefully
incomplete, and only describes the XMPP and mDNS bits, not the actual
Clique datagrams. If this protocol is suitable for your use case, we'd
welcome a second implementation, and any documentation you can
contribute - the canonical source for [1] is docs/clique.xml in the
telepathy-salut git repository[2].

Regards,
S

[1] http://telepathy.freedesktop.org/xmpp/clique.html
[2] http://cgit.freedesktop.org/telepathy/telepathy-salut/

Re: [Standards] OTR-like protocols in XMPP (was: Self Introduction)

[Simon McVittie]

On 26/02/13 14:50, Jon Kristensen wrote:
> In the process of prototyping Yabasta, I have "designed" an OTR-like
> protocol[3] that, while based on OTR, differs from OTR in a number of
> ways. [...] any XML payloads can
> be protected (not just message bodies).

That seems a lot more XMPP-ish than "plain OTR", and addresses a concern
I've always had about OTR (that it's defined in terms of a stream of
plain-text messages, making it protocol-agnostic but unable to interact
with individual protocols' features).

However, if this is not wire-protocol-compatible with "real OTR", does
it have any particular advantages over previous XMPP work on end-to-end
TLS, with X.509 certificates that are typically self-signed and used
mainly as a vehicle for key material?

My understanding had been that the main advantage of OTR over TLS is
that it gets some "network effect" from the OTR Pidgin plugin being
somewhat widely-deployed; if that advantage isn't present, would it be
better for security to reuse widely-tested TLS libraries (OpenSSL,
GNUTLS etc.) rather than trying to get all the subtleties of crypto
right in domain-specific code?

Which of the security properties desired by
 does
this OTR-like protocol have, and does it have any more that are
desirable but not specified in that document? (For that matter, which
does OTR have?)

It seems to me as though many of OTR's frequently-stated advantages
(such as perfect forward secrecy and repudiability) are advantages over
older techniques like individually PGP-signing messages (XEP-0027, which
has many other flaws), but are not advantages over TLS, which shares
those properties. Is this the case?

Last time I looked at supporting OTR and/or XTLS in the Telepathy
framework, I wrote

and

to try to articulate what our goals for end-to-end encryption might be,
and which of those goals are satisfied by each of XTLS and OTR.

As far as I could work out in message 006135, XTLS offers just as much
deniability as OTR (anyone who can understand a message stream enough to
cite it as evidence of a conversation could also have faked the entire
conversation). Is this the case, or was I missing something important?

Regards,
S

Re: [Standards] disco identity for "client/smartphone"?

[Simon McVittie]

On 29/11/12 23:39, Peter Saint-Andre wrote:
> Looking at http://xmpp.org/registrar/disco-categories.html I
> notice that we have disco identities for "client/handheld" (e.g.,
> PDA) and "client/phone" (e.g., mobile phone), but I think those are
> a bit old-fashioned by now. We might want to add an identity for 
> "client/smartphone" (i.e., a phone that can do a lot more than the 
> old-style phones we had in mind when we defined "client/phone").

-1 from me; the differences between feature-phones and smartphones
seem like a matter for capability discovery (and in any case, it's a
continuum, not a dichotomy).

The Telepathy framework supports the complete set of disco identities,
but as far as I know, the only one that has ever appeared in UIs is
client/phone, which (in our flagship UI, Empathy) puts a phone icon
next to the contact's name. The users who requested this feature
phrased their requests in terms of "so I can tell why they're ignoring
my messages", having observed that contacts connected via phones
rarely noticed incoming messages until much later. I don't see that
smartphones would differ much from featurephones in that respect.

There's also a bit of backwards-compat/"installed base" principle to
be considered here. The Telepathy installation in the Nokia N9's OS
identifies itself on XMPP as client/phone. I'm pretty sure the N9
counts as a smartphone, so I would prefer this not to be retroactively
declared to be a bug. I'm sure other vendors' existing smartphone apps
are also client/phone, if they use disco-categories at all
(unfortunately, Google's Android app doesn't, for instance).

S

Re: [Standards] UPDATED: XEP-0276 (Presence Decloaking)

[Simon McVittie]

On 17/07/12 00:26, Lance Stout wrote:
> The reason value is really just a hint or suggestion

Yes, that was my intention when I wrote the XEP. It seems a bit more
user-friendly if you can hint at the reason for requesting de-cloaking:

/---\
| Alice  is asking   |
| whether you are currently online, but |
| is not on your contact list.  |
| [ Reveal presence ] [ Ignore ]|
\---/

("what do I do about that?!") vs.

/-\
| Alice  wants to  |
| call you, but is not on your contact list.  |
| Allowing the call to be started will reveal |
| that you are currently online.  |
| [ Reveal presence ] [ Ignore ]  |
\-/

("oh, this is just an incoming call from someone I don't know, I know
what to think about that").

The implementation in Telepathy supports either decloaking automatically
(a boolean option, off by default) or decloaking on-request (we signal
the UI to tell it about the decloak request, including the reason
attribute, and the UI can respond by sending directed presence if
desired). I don't think we actually have UI for it in either mode, though.

If I remember correctly, the original motivation was a SIP-to-XMPP
gateway, in which the gateway's virtual XMPP users always responded to
decloak requests, so that you could call arbitrary SIP addresses via
their corresponding XMPP address without adding it to your roster first;
in this case there was no meaningful presence to leak, because the
virtual users behaved as if they were always online anyway (we didn't
implement SIMPLE on the SIP side).

Part of the motivation for decloaking was that in 2010, it wasn't
obvious which of the incompatible dialects of Jingle and ICE-UDP
(Google/various expired XEP drafts/current XEP) would be supported by an
unknown client (perhaps one that pre-dated the then-current XEP, like an
older version of Telepathy). To perform a high-level, user-visible
action ("call Bob") we had to look at disco results and perform one of
several similar protocol actions, depending on the capabilities of Bob's
client.

Now that the Jingle and ICE-UDP XEPs are more widely-implemented, it
might be possible to define a way to initiate a call with a bare JID
using those XEPs (i.e. assume that if Bob's client supports calls at
all, then it supports modern XEP Jingle), and redirect to one particular
resource if Bob answers.

S

Re: [Standards] Accessibility (including XEP-0301)

[Simon McVittie]

On 28/06/12 13:44, Edward Tie wrote:
> Op 28/06/2012 14:18, Simon McVittie schreef:
>> RTT and audio/video do have a significant technical difference: RTT is
>> in-band, and audio/video (at least as implemented in Jingle) are
>> out-of-band.
> 
> I has disagree. RTT works already with SIP. See more info: Supported
> real-time text codec is t.140.
> RTT  must be convert to codec t.140 in SIP.

OK, let me rephrase that: XEP-0301 and XEP-0167 have the significant
technical difference that XEP-0301 is in-band, and XEP-0167 is out-of-band.

It's certainly possible to implement the general concept of RTT
out-of-band (as in T.140), and possible (although not very useful due to
performance problems) to implement audio/video in-band, but those aren't
the proposed standards we have for RTT and audio/video in XMPP.

I do agree with the author of XEP-0301 that sending RTT in-band has some
important advantages over out-of-band.

S

Re: [Standards] Accessibility (including XEP-0301)

[Simon McVittie]

On 28/06/12 05:22, Kurt Zeilenga wrote:
> I guess bandwidth-challedged XMPP networks should be fair and, if they
> want to block one real-tine conversation method, block them all.

RTT and audio/video do have a significant technical difference: RTT is
in-band, and audio/video (at least as implemented in Jingle) are
out-of-band.

For in-band protocols the extra traffic (stream of partial messages)
goes through the server, whereas in out-of-band protocols, the vast
majority of the extra traffic is out-of-band, and the XMPP server only
sees some relatively lightweight signalling, which is O(number of calls)
rather than O(total length of calls). If Alice and Bob communicate via
(say) jabber.org, the Jingle traffic is a cost for Alice, Bob and their
respective ISPs, whereas the in-band XMPP traffic is a cost for Alice,
Bob and their ISPs, but also for jabber.org.

RTT over Jingle + ICE-TCP would be a closer equivalent, if there was a
finished XEP for Jingle + ICE-TCP; or in principle, RTT could even go
over ICE-UDP like audio and video do, if it can survive packet
loss/re-ordering.

Now, RTT is considerably "lighter" than audio/video, so it's not
necessarily a *significant* bandwidth cost for jabber.org (or whatever
server Alice and Bob are using) - but it is extra bandwidth that
jabber.org would not otherwise be using.

S

Re: [Standards] RTT, take 2

[Simon McVittie]

On Fri, 24 Jun 2011 at 11:24:50 +0200, Remko Tronçon wrote:
> > So I'd say that we should refer to characters in a string, and deal with
> > Unicode code-points in the abstract.
> 
> I'm wondering whether 'code points' are any better than UTF-8 based
> positioning. Isn't it possible that a codepoint position also points
> inside a character/glyph/...?

A codepoint is the fundamental thing defined by Unicode, but there is a
related concept which could be called a character (or grapheme?), consisting
of one or more codepoints (a codepoint representing a non-combining character,
followed by zero or more codepoints representing combining characters).

(A glyph is something different, and as far as I can tell is only interesting
if you make fonts or font-rendering algorithms.)

In UTF-8 a codepoint is one or more bytes, in UTF-16 a codepoint is either
one or two 16-bit words, and in UCS-4 a codepoint is one 32-bit word.

Here are some codepoints:

* U+0041 LATIN CAPITAL LETTER A
* U+00C1 LATIN CAPITAL LETTER A WITH ACUTE
* U+0301 COMBINING ACUTE ACCENT

The grapheme Á could either be written as U+0041 U+0301 (decomposed form),
or U+00C1 (composed form). Not all graphemes have a composed form.

> For example, in Qt, this would most likely be
> implemented using a QTextCursor (
> http://doc.trolltech.com/4.7/qtextcursor.html ). However, the text
> talks about 'positioning at character X', and it doesn't seem to be
> defined what this means.

That might either be counting graphemes or codepoints, depending...

S

Re: [Standards] RTT, take 2

[Simon McVittie]

On Wed, 22 Jun 2011 at 13:05:48 -0400, Mark Rejhon wrote:
> UTF16 and UTF16LE, and even UCS2 has same behaviour in my RTT spec, so I
> just say "16-bit Unicode".  Java, C#, ObjectiveC stores strings in 16-bit,
> and the various flavours of Unicode C++ STL and stdlib++ also store strings
> in 16-bit as well. Extensive research and testing shows they all process in
> flat mode like an array of 16-bit integers

IMO you should either count Unicode codepoints (the underlying data model),
or bytes of UTF-8 (the XMPP wire protocol). Counting in units of what a
particular implementation uses internally, if it isn't one of those two,
seems attractive if you use that particular implementation, but complicates
things further for everyone who isn't.

Yes, Windows, Java etc. store UTF-16 and have their APIs in terms of 16-bit
units instead of in terms of codepoints, but that's an accident of history -
early Unicode developers thought 16 bits would be enough for everybody (UCS-2),
and when they realised that wasn't true, UTF-16 was invented as a way to not
change their 16-bit wchar_t.

wchar_t is 32 bits (enough for any Unicode codepoint) on some platforms,
notably Linux, and probably most other Unix systems.

As an implementation detail, within a UTF-16 string viewed as an array of
16-bit units, I believe it's possible to tell whether a unit is part of a
surrogate pair or not by just looking at its value without further context;
so it's relatively easy to advance a "cursor" by one Unicode codepoint
(which either means one or two 16-bit units).

S

Re: [Standards] Proposed XMPP Extension: JSON Content Type support

[Simon McVittie]

On Wed, 20 Apr 2011 at 15:35:55 +, XMPP Extensions Editor wrote:
> Abstract: This specification defines JavaScript Object Notation (JSON) use in 
> XMPP service.

This XEP uses an unassigned MIME type in the IANA namespace, which I don't
think is appropriate for Standards Track. "application/jsonrequest" is not an
IANA-assigned MIME type although (RFC 4627 registered "application/json").

This abuse of the MIME type as an "evil bit" seems to come from a proposal
 from the author of RFC 4627, last
updated in 2009. I can't find any evidence that browsers actually implement
this API, apart from a proof-of-concept Firefox addon; Firefox implements
 and 
instead of JSONRequest.

It seems to me as though using new HTTP headers would be far more appropriate
than inventing a spurious MIME type for this sort of thing (and indeed CORS
and XMLHttpRequest2 do exactly that), and if a new MIME type has technical
or social advantages that I'm not seeing, it should at least be registered
with IANA.

S

Re: [Standards] Checking hostname in XMPP server when using TLS

[Simon McVittie]

On Wed, 03 Nov 2010 at 08:42:02 -0400, zhong ming wu wrote:
> You made good points. But there are cases where user can get the server that
> host xmpp service not necessarily from DNS; they choose not to publish it
> for whatever reason. Imagine an organization wanting to use xmpp service
> using example.org domain and have it hosted at xmpp.provider.com and they
> made the user enters the hostname in the client; pidgin and alike have the
> option for a reason.

Arguably it would be reasonable to accept either example.org or
xmpp.provider.com here, but only accepting the domain from the JID
(example.org) is consistent with the SRV-record case, and fixes the flaw
you point out below.

> Someone (possibly an unauthorized adim from example.org who can get
> example.org certificate) could take over DNS of provider.com and set up
> xmpp.provider.com and intercept the xmpp communications of example.org

If you're trusting example.org to handle your XMPP traffic, there's nothing
you can do to defend against example.org's sysadmin wanting to intercept
your communication, except revoking the certificates and getting a
better sysadmin :-)

If you do trust example.org, this sounds like a reason to *not* accept a
certificate purporting to be xmpp.provider.com in this case.

> Or in the old way www.cnn.com points to multiple ips and the browser
> randomly choose one; https thus merely checks that www.cnn.com and the
> server it connects matches.

The server presents a certificate with CN=www.cnn.com, the browser will reject
any certificate that doesn't have that name. Once again, the certificate has
to match the service that the user wanted to connect to.

(Notably, the browser wouldn't accept a certificate whose CN was one of the
IP addresses that www.cnn.com happens to point to today.)

> I think SMTP might be a slightly better example although with that TLS is
> not supposed to be mandatory. MTA looks up MX record and connects to the mx
> server and can/is supposed to verify that the mx server presents the
> certificate with matching mx hostname which is not necessarily the same
> email domain that MTA is delivering.
> MX record is not supplied by the sending user but MTA looks it up.

SMTP is unusual in that there's no expectation that the connection will be
secured at all, for historical reasons. The mechanism you describe is wrong
from a maximum-security point of view, but SMTP is normally not even
encrypted, so it's (slightly) better than nothing...

If email was invented now, and had mandatory TLS, MTAs would refuse to deliver
mail for (say) simon.mcvit...@collabora.co.uk unless the destination
mailserver could present a certificate indicating that it is, or is
authorized to act on behalf of, collabora.co.uk. Getting there
from here is basically impossible for email due to the number of existing
deployments it'd break, but at least we can avoid this design flaw for XMPP...

Simon

Re: [Standards] Checking hostname in XMPP server when using TLS

[Simon McVittie]

On Tue, 02 Nov 2010 at 18:11:18 -0400, zhong ming wu wrote:
> Moreover assuming DNS is safe (big assumption in the past & some will
> say now) should client not do DNS look up and then use server cert to
> verify authenticity of it

DNS can't be assumed to be safe; anything we're told via a SRV lookup is
suspect. The thing we're trying to verify is:

* the user told us to connect as j...@example.com, therefore they wanted to
  talk to the example.com server
* we got a connection to a server claiming to serve example.com
* is it really authorized to act on behalf of example.com?

If there's a SRV record telling us we should actually connect to
jabber.services.example.net (or whatever), accepting a certificate for
jabber.services.example.net would be unsafe, because that's not what the
user asked for.

> TLS implementation of HTTP/SMTP/IMAP/POP do not work like XMPP in this regard

HTTPS doesn't do SRV lookups, but when you use a CNAME it behaves just like
XMPP. If I connect to https://www.google.com/ I get this:

s...@reptile% dig www.google.com
...
;; QUESTION SECTION:
;www.google.com.IN  A
...
;; ANSWER SECTION:
www.google.com. 348 IN  CNAME   www.l.google.com.
www.l.google.com.   156 IN  A   209.85.227.103
... (and more geolocated addresses for www.l.google.com)

and when I connect to 209.85.227.103 (or whatever), it presents a certificate
for www.google.com (not for www.l.google.com or 209.85.227.103).

S

Re: [Standards] Date time values in XEP54, vcard?

[Simon McVittie]

On Tue, 12 Oct 2010 at 21:35:51 +0200, Peter Flindt wrote:
> The format 1966-08-06 is US specific

-MM-DD is another form of ISO-8601 date; in the USA dates are
conventionally MM/DD/ (particularly confusing if you're from the UK,
where dates are conventionally DD/MM/).

It'd be good if the example in the XEP had a day number higher than 12
(1966-08-16 or something) to make it obvious which bit is meant to be the day,
though.

> I guess the phone numbers in the vCard have a standard too and I not
> trust the example 303-555-1212.

In principle, refer to ITU-T E.123 (see ).
In practice, you can't really assume anything about the format of a phone
number: just treat it as an opaque blob of text until/unless you need to
dial it.

S

Re: [Standards] Addition of client types

[Simon McVittie]

For the sake of XEP-0053 formality, the requests we're making are:


  client
  
game
A client running on a games console
N/A
  


and


  client
  
sms
A client who is not actually using instant messaging client but 
messages sent to this contact will be delivered as SMSs
N/A
  


For your convenience, Jonny attached them as a patch in the mail that started
this thread.

S

Re: [Standards] Addition of client types

[Simon McVittie]

On Fri, 30 Jul 2010 at 13:33:42 +0100, Jonny Lamb wrote:
>  1. game: MSN has an Xbox client type. I don't think it is too unlikely
> for your favourite console to grow an XMPP client, do you? I
> certainly wouldn't want to rule it out!

Would it be possible to add this? We'd like to keep our API's list of client
types aligned with XMPP's if at all possible, so we'd like to know whether we
can safely use 'game', or whether we need to use 'x-game' or something.

(The main reason we suggested this one is that a developer glancing at
the list of client types might easily believe that 'console' is used in
the sense of "games console" rather than "/dev/console".)

>  2. sms: at least MSN and Yahoo also have a feature which means that
> you can add phone numbers to your contact list. They appear as
> contacts in your contact list but are not actually running IM
> clients, and any messages sent to these contacts will be sent via
> SMS.

This one is pretty important for us, so we'd like to know whether we can safely
use 'sms', or whether we need to fall back to 'x-sms' or something.
Bernard Peek indicated that this would be useful to the RNID too,
which is hopefully a significant argument in its favour.

Regards,
Simon

Re: [Standards] Addition of client types

[Simon McVittie]

On Mon, 02 Aug 2010 at 11:44:58 +0200, Peter Saint-Andre wrote:
> In service discovery, how would I communicate via XMPP with an SMS client?

The idea here is that you'd send a perfectly normal , which some
gateway will translate into SMS and send onwards.

Some reasons why it's significant to know that a contact will receive SMS
(more so than general gatewaying), even if the mechanics of sending a message
are identical:

* it's likely to interrupt them more, replying is likely to cost them money,
  and (in the USA or while roaming) just receiving the message might also cost
  them money, so you might refrain from sending an unimportant message at all,
  or send fewer, larger messages
* if you know they'll receive the message via SMS, a character counter in the
  UI is likely to be useful; in normal XMPP, it isn't

We're mainly interested in XEP-0115 entity capabilities (and its equivalents
in other protocols), rather than the more general XEP-0030 service discovery -
we're looking at the identity of an individual client, rather than the
identity of their service.

The main case for which we want 'sms' in Telepathy (which is multi-protocol) is
for protocols like MSN and Yahoo where you can add phone numbers to your
protocol-level contact list, and normal protocol messages to those
pseudo-contacts will arrive via SMS. The most analogous situation in XMPP
would be that you use MSN or Yahoo via a gateway, and some of your MSN/Yahoo
contacts are themselves actually SMS contacts - so in general, the gateway is
to MSN/Yahoo (i.e. gateway/msn or gateway/yahoo, not gateway/sms), but these
specific contacts aren't really MSN/Yahoo users.

(The draft D-Bus API in which we're re-using XMPP client categories is here:
)

Regards,
Simon

Re: [Standards] Decloaking and Temporary Subscriptions

[Simon McVittie]

On Thu, 21 Jan 2010 at 08:03:24 -0700, Peter Saint-Andre wrote:
> So let's look at the pros and cons...

I generally agree with psa's assessment here. One more note:

> - session-specific presence sharing isn't really a presence
> subscription, which in XMPP is and has always been a long-lived trust
> relationship between two entities; overloading that trust relationship
> seems like a bad idea

A genuine subscription request, if accepted, gives the requester access to your
full presence ( and , not just "available"), and any pubsub
nodes that have the "normal" PEP access control level (geolocation, etc.).
None of those were actually necessary for the session they wanted to establish
with you (e.g. a Jingle call).

S

Re: [Standards] Enabling Jingle calls to non-subscribed JIDs with directed presence

[Simon McVittie]

On Tue, 05 Jan 2010 at 17:28:15 +, Simon McVittie wrote:
> I'm trying to pick up some earlier work on making Jingle calls work for JIDs
> to which the caller isn't subscribed.

I've written up the proposed API as a proto-XEP and submitted it to the
registrar:

http://people.collabora.co.uk/~smcv/decloak.html

XML is available here (click "raw" for raw XML):

http://git.collabora.co.uk/?p=user/smcv/telepathy-gabble-smcv.git;a=blob;f=docs/decloak.xml;h=656c11cd67b728914df4d82319e438f8842a9729;hb=b04a05234d8569c9852611142bfb3ecb6c1a5822

> > 
> >>hash='sha-1'
> >node='http://psi-im.org'
> >ver='q07IKJEyjvHSyhy//CH0CxmKi8w='/>
> >   
> > 

This is essentially what I've done. For the moment my proto-XEP uses a
vendor-specific XML namespace, because I developed it alongside a test
implementation (telepathy-gabble).

> > 
> >>  hash='sha-1'
> >  node='http://www.chatopus.com'
> >  ver='zHyEOgxTrkpSdGcQKH8EFPLsriY='/>
> >   
> > 

To avoid infinite loops (or having to do complex state-tracking to prevent
them), the reply is just directed presence - it omits the  element.

> However, it was pointed out in August 2008 that GTalk (at the time) would only
> let  packets through to its users, so the de-cloak
> request might have to look more like this[3]:
> 
> > 
> > 
> > 

I haven't done this; discussing with my colleagues, we decided that if GTalk
explicitly wants to suppress communication from unapproved entities to its
users, we should respect that.

> * After asking for directed presence, how do we tell whether there'll ever be
>   a response? An arbitrary timeout seems like the only useful answer...

My test implementation just waits 5 seconds.

> * If Bob has configured his client to make this work "silently", then Alice
>   can determine that Bob has a client logged in, which client it is, and its
>   resource name (but not whether it is available/away/dnd/..., and no
>   "rich presence" like geolocation, avatar, etc.) - a (user-configurable)
>   presence leak

My test implementation signals to the UI that Alice has done this. I'm not
sure what a UI would usefully do with this information, but it's there.

Another potential pitfall is highlighted by the proto-XEP: suppose Tybalt
has two resources, /library (dnd, 'researching') and /garden
(xa, 'gone to the library'). If Juliet tries to call Tybalt and sends a
successful decloak request, Tybalt's two resources will reply in an arbitrary
order, and Juliet will probbaly call whichever one answered first; even if she
waits for an arbitrary time, say 5 seconds, in the hope of getting more
replies, gets the second presence, *then* calls, she can't know which of
/garden and /library is "more available".

Any thoughts on this protocol?

Regards,
Simon


signature.asc
Description: Digital signature

[Standards] Enabling Jingle calls to non-subscribed JIDs with directed presence

[Simon McVittie]

Hi,
I'm trying to pick up some earlier work on making Jingle calls work for JIDs
to which the caller isn't subscribed. The use case I'm particularly interested
in is calling arbitrary SIP addresses via a Jingle-to-SIP gateway component
(telepathy-fargo, under development).

Previous discussions on XMPP lists[1] have several proposals. The most
concrete that I can find is that in December 2008, after discussion with Rob
McQueen, psa suggested a protocol he referred to as "decloaking" or "smoking
out" presence[2]:

> If you don't share presence, the smoke-out stuff would enable you to
> learn all this good information on an opt-in basis. So something like
> this (here I call it "decloak" instead of "smoke-out"):
> 
> 
>   hash='sha-1'
>node='http://psi-im.org'
>ver='q07IKJEyjvHSyhy//CH0CxmKi8w='/>
>   
> 
> 
> This directed presence is then broadcast to all your resources, which
> then know that I want to decloak and share capabilities with you for the
> purpose of further communication.
> 
> If you approve, your client then also decloaks:
> 
> 
> hash='sha-1'
>  node='http://www.chatopus.com'
>  ver='zHyEOgxTrkpSdGcQKH8EFPLsriY='/>
>   
> 
> 
> Now I know the capabilities of your "bar" resource, which we hope
> include support for Jingle. So I can send a Jingle invite from my "foo"
> resource to your "bar" resource and we can have a voice and video chat
> (or whatever).

However, it was pointed out in August 2008 that GTalk (at the time) would only
let  packets through to its users, so the de-cloak
request might have to look more like this[3]:

> 
> 
> 

Has there been further discussion that I've missed while reading through the
archives?

The goal I'm trying to achieve is:

* xmpp:al...@example.com wants to call sip:12...@example.org (perhaps she just
  typed 12345 into a dial-pad). She has previously registered on a gateway
  sip.example.com, so it will log in as sip:al...@example.org on her behalf.
* Alice sends some indication to 12345%example@sip.example.com that she
  would like it to respond with its presence, because she is about to call it
* 12345%example@sip.example.com sends back directed presence, containing
  only  (no , avatar etc.)
* Alice now knows 12345's resource (or, more likely, she knows that this
  particular gateway should be called using a bare JID)
* Alice performs service discovery to interpret 12345's caps hash
* Alice now knows that the gateway JID can accept Jingle calls with certain
  dialects etc., and can call it

or more generally:

* XMPP users Alice and Bob have no subscription in either direction
* Alice wants to call Bob, perhaps by typing his JID into a UI, without
  necessarily setting up a subscription
* Alice sends some indication to Bob that she would like him to respond with
  presence so that he can be called
* Optionally, Alice includes her own presence/caps in that indication
* According to client configuration, Bob's client either ignores Alice,
  sends back directed presence containing only 
  (no , avatar etc.), or asks Bob what to do
* Alice now knows Bob's resource
* Alice performs service discovery to interpret Bob's caps hash
* Alice now knows that Bob can accept Jingle calls with certain
  dialects etc., and can call him
* Bob can optionally send Alice an unavailable presence after a reasonable time
  without receiving a call, or after the call ends; Alice can behave similarly

Potential pitfalls:

* After asking for directed presence, how do we tell whether there'll ever be
  a response? An arbitrary timeout seems like the only useful answer...

Problems with the general case, which are, however, not a problem for the
gateway case:

* If we want to support calling unsubscribed GTalk users, then the temporary
  pseudo-subscription request needs to be a modified subscription request,
  which all existing clients will display like a genuine subscription request
  (OTOH, that's what you have to do anyway to be able to call anyone at the
  moment...); the business rules for a temporary pseudo-subscription request
  are unclear (should you accept it and revoke acceptance, or send directed
  presence and never actually subscribe them, or what?)

* If Bob has configured his client to make this work "silently", then Alice
  can determine that Bob has a client logged in, which client it is, and its
  resource name (but not whether it is available/away/dnd/..., and no
  "rich presence" like geolocation, avatar, etc.) - a (user-configurable)
  presence leak

* If Bob wants to be prompted whether to allow this, he could see poor UI
  (potentially, one popup for "let Alice see you're online so she can call
  you?", followed by either another popup for accepting/rejecting the call,
  or nothing if Alice turns out not to have any dialects in common with Bob...)
  although this is not necessarily a problem with more elaborate UI design

Thoughts? I'm going to try writing this up as a pseudo-XEP and implementing it
in a telepathy-

Re: [Standards] MUC and data forms

[Simon McVittie]

I've put some proposed clarifications online:
http://git.collabora.co.uk/?p=user/smcv/xmpp.git;a=shortlog;h=refs/heads/muc-data-forms

On Wed, 18 Nov 2009 at 15:36:52 -0700, Peter Saint-Andre wrote:
> On 11/17/09 5:11 AM, Simon McVittie wrote:
> > An alternative solution would be to declare that one of the implementations
> > is right and the other is wrong. I'd be inclined to say that the 
> > interpretation
> > used in Openfire, Tigase and ejabberd seems appropriate.
> 
> The intent behind changesubject is to either allow any participant to
> change the subject, or to lock it down to anyone above participant level
> (which typically means moderator or above in a moderated room or admin
> in an unmoderated room).

It looks as though you're agreeing with the Openfire/Tigase/ejabberd
interpretation here, I think, since users with affiliation >= owner default
to gaining moderator role whenever they join, and can gain moderator role
whenever they want to.

By "any participant" I assume you mean "anyone with role >= participant",
which is Openfire/etc.'s interpretation. Would you accept a patch for XEP-0045
that recommended that interpretation?

> > XEP-0045 suggests that muc#roomconfig_changesubject could (should?) be in 
> > the
> > room's disco#info. According to my tests on various public servers, nobody
> > actually does that yet, but including selected roomconfig_ fields in the
> > disco#info seems a good approach for the future.
> 
> Hmm, this might open up attacks ("disco for rooms that allow anyone to
> change the subject so that I can cause trouble there").

By "in the disco#info" I mean when querying for room information on a
specific room, as the user SHOULD do before joining (XEP-0045 §6.3), not
as something searchable-for. Yes, it would be possible to list all rooms
and disco them all (n+1 round trips for n rooms), but a user contemplating
joining rooms and spamming the subject could equally well join those rooms
and spam the content (with messages), and will likely get banned either
way :-)

Some context: when we join a room, our XMPP implementation (telepathy-gabble)
wants to tell the API user whether they can change the subject. We can't
query the roomconfig because we're probably not an admin, but we can easily
check the disco#info.

> > Example 8 "Room Returns Extended Disco Info Results" contains
> > muc#roominfo_pubsub, which does not appear in the roominfo registry 
> > submission.
> > I haven't checked whether any implementations support this field, but I
> > suspect that it's a typo for muc#roomconfig_pubsub; I propose amending the
> > example.
> 
> That's for an associated pubsub node:
> 
>   
> xmpp:pubsub.shakespeare.lit?;node=the-darkcave-node
>   
> 
> Whether anyone uses that is another question...

I can understand the purpose; my point was that the version with *roominfo*
in the name only exists in an example and not in the registry submission,
whereas the version with *roomconfig* is in the normative specification.
If nobody actually implements this yet anyway, I'd prefer to limit the
duplication between roominfo and roomconfig.

Regards,
Simon


signature.asc
Description: Digital signature

[Standards] MUC and data forms (was: MUC, MUC, glorious MUC)

[Simon McVittie]

Various data-forms-related things from XEP-0045 that I'd like to see clarified,
while on the subject of MUCs:

--

I've recently been trying to implement a check for muc#roomconfig_changesubject 
in telepathy-gabble, so we can close a long-standing bug (when Telepathy UIs
ask an XMPP MUC whether they can change the subject, we can't give a
meaningful answer).

However, the spec for this parameter in XEP-0045 seems rather vague. Having
consulted the code of some open-source implementations:

* in Openfire, Tigase and ejabberd, muc#roomconfig_changesubject = false
  means that role == moderator can change the subject, while true means that
  role >= participant (i.e. participants and moderators) can change the subject

* in mu-conference, false means that affiliation >= admin (i.e. admins and
  owners) can change the subject, while true means that anyone in the room
  (role >= visitor) can change the subject

* in Prosody, anyone in the room can change the subject

One possible solution would be to deprecate muc#roomconfig_changesubject as
being too vague, and either define a new field muc#roomconfig_subjectrole of
type list-single, which is the minimum role to set the subject, or follow
muc#roomconfig_getmemberlist by defining a new field of type list-multi
containing roles and affiliations which can change the subject (I think the
latter would be overkill).

An alternative solution would be to declare that one of the implementations
is right and the other is wrong. I'd be inclined to say that the interpretation
used in Openfire, Tigase and ejabberd seems appropriate.

--

XEP-0045 suggests that muc#roomconfig_changesubject could (should?) be in the
room's disco#info. According to my tests on various public servers, nobody
actually does that yet, but including selected roomconfig_ fields in the
disco#info seems a good approach for the future.

Example 8 "Room Returns Extended Disco Info Results" of XEP-0045 contains
both muc#roominfo_changesubject and muc#roomconfig_changesubject, with
different labels ("Whether Occupants May Change the Subject" and "Subject
can be modified" respectively). muc#roominfo_changesubject is not included
in the muc#roominfo FORM_TYPE registry submission, and I haven't found an
implementation of it; I suggest deleting the reference to this field altogether.

The muc#roominfo FORM_TYPE registry submission does include
muc#roominfo_subjectmod, labelled "The room subject can be modified by
participants". I haven't found an implementation of this either, and I suggest
deleting it. Its label could be treated as evidence in favour of
using participant as the threshold role for subject modification with
muc#roominfo_changesubject, i.e. agreeing with Openfire, Tigase and ejabberd;
however, it seems almost equally likely that "participant" is used here in
its non-jargon sense.

--

The muc#roominfo FORM_TYPE registry submission does not appear in
, presumably a registry oversight?

In the muc#register FORM_TYPE, the registry submission mentions
muc#register_allow, but that registry page does not.

muc#roomconfig_getmemberlist and muc#roomconfig_pubsub do not appear in that
registry page either.

The muc#register FORM_TYPE registry defines muc#register_first and
muc#register_last to be first name and last name, but the XEP defines
them to be given name and family name. I propose that these be changed to
given name and family name consistently, in the same way that XEP-0055 Contact
Search was clarified in version 1.3.

--

Example 8 "Room Returns Extended Disco Info Results" contains
muc#roominfo_pubsub, which does not appear in the roominfo registry submission.
I haven't checked whether any implementations support this field, but I
suspect that it's a typo for muc#roomconfig_pubsub; I propose amending the
example.

--

Some other clarifications which I think would be worthwhile (I haven't checked
whether these are actually true in XMPP server implementations, though):

* What muc#roomconfig_allowinvites = true means by "Allow Occupants..." -
  either "allow roles >= visitor to invite others" or "allow roles >=
  participant to invite others", presumably, whereas
  muc#roomconfig_allowinvites = false means "allow only moderators to invite
  others"?

* muc#roominfo_description and muc#roomconfig_roomdesc are the same attribute,
  so disco#info SHOULD NOT include muc#roomconfig_roomdesc, and changing
  muc#roomconfig_roomdesc SHOULD change muc#roominfo_description.

* Similarly, muc#roominfo_lang and muc#roomconfig_lang are the same attribute.

* muc_nonanonymous and muc_semianonymous are mutually exclusive; if neither
  feature is present, the room is anonymous.

* muc_open and muc_membersonly are opposites; each room should have exactly
  one of these features. muc#roomconfig_membersonly selects which one is
  active.

* Similarly, muc_unmoderated and muc_moderated are o

[Standards] XEP-0055 Jabber Search: first/last or given/family names?

[Simon McVittie]

While implementing XEP-0055 Jabber Search in Telepathy, we've hit an ambiguity
in the spec between first/last names, and given/family names.

It's clear that to find a person with a Western name in a Jabber directory,
you would use something like this:

Gordon
Brown

or this:

Gordon
Brown

However, names in many Asian cultures (e.g. Chinese names) don't work like
Western names: for example, in the name "Hu Jintao", Jintao is the given name
and Hu is the family. To search for the Chinese leader, should one use

Hu
Jintao

(i.e. the field semantics are as suggested by the markup, and are really
first name and last name), or

Jintao
Hu

(i.e. the markup is by historical accident, and what was really meant is
"family name" and "given name")?

Similarly, in the historical version, the fields are called  and
, although I realise this doesn't necessarily mean anything about
their semantics.

vCard explicitly specifies that the first component of the "N"
(structured name) type-name (field) contains the family name, and the
second contains the given name, like so:

FN:Hu Jintao
N:Hu;Jintao

FN:Gordon Brown
N:Brown;Gordon

In Telepathy, we want to propagate correct information through the framework
to UIs: this means that in protocols that use given name/family name, we want
to use fields x-n-given and x-n-family (in our notation), and for
protocols that use first/last name, we want to use x-first and x-last.
Which of these categories does XMPP fall into, in practice?

Unhelpfully, the spec and examples in XEP-0055 v1.2 seem to be evenly
distributed between the two models:

* XMPP Registrar Considerations: 
* XMPP Registrar Considerations: 
* Example 7: 
* Example 7: 
* Example 9: 
* Example 9: 

In particular, the XMPP Registrar registration is not even internally
consistent!

It would be helpful if one of these could be chosen:

* Accept Example 7 (family/given) as the canonical interpretation:
  - change Example 9 and the Registrar registration for 'first' to match it
  - explain that the "first" and "last" naming is a historical accident, and
that's not really what the fields mean

* Accept Example 9 (first/last) as the canonical interpretation:
  - change Example 7 and the Registrar registration for 'last' to match it

It would also be very useful to include a family-name-first (e.g. Chinese)
name in at least one example to illustrate how that works, although
unfortunately that breaks the convention of using examples from Shakespeare :-)

Regards,
Simon


signature.asc
Description: Digital signature