ConnectionError would also let us emit a better error when we get the <hostname-unknown/> stream error. Currently, we emit AuthenticationFailed, because the most likely scenario is using a non-Google Talk JID with the connect server set to talk.google.com.

Here's some infrastructural work for this, which doesn't improve on the current error mappings much, but does at least implement ConnectionError.

The next step would be to extend the error mapping functions to cover all Wocky errors; we can also add any missing errors to tp-spec.

(In reply to comment #0)
> </query><error code='500' type='wait'><resource-constraint
> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/><text
> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>Users are not allowed to register
> accounts so quickly</text></error></iq>

Perhaps resource-constraint should even be Service_Busy? Gabble with this branch would map it like that if it's a WockyXmppError, or to something else if it's a WockyConnectorError.

(In reply to comment #1)
> ConnectionError would also let us emit a better error when we get the
> <hostname-unknown/> stream error. Currently, we emit AuthenticationFailed,
> because the most likely scenario is using a non-Google Talk JID with the
> connect server set to talk.google.com.

This is still Authentication_Failed at the moment; we could add a Wrong_Server or Hostname_Unknown error, perhaps?

Ideally, Wrong_Server would put extra keys in @details to indicate what's wrong, something like this:

ConnectionError(Wrong_Server, { "debug-message": "host unknown",
    "connected-to": "talk.google.com",
    "requested-hostname": "collabora.co.uk" })

In 34cda73:

+    case WOCKY_XMPP_STREAM_ERROR_CONFLICT:
+      /* Assume we got this while already signed-in, rather than while
+       * connecting (which would be ALREADY_CONNECTED). */
+      return set_conn_reason (conn_reason,
+          TP_CONNECTION_STATUS_REASON_NAME_IN_USE,
+          TP_ERROR_CONNECTION_REPLACED);
+

Why is this assumption safe?

Otherwise, looks fine.

(In reply to comment #3)
> In 34cda73:
> 
> +    case WOCKY_XMPP_STREAM_ERROR_CONFLICT:
> +      /* Assume we got this while already signed-in, rather than while
> +       * connecting (which would be ALREADY_CONNECTED). */
> +      return set_conn_reason (conn_reason,
> +          TP_CONNECTION_STATUS_REASON_NAME_IN_USE,
> +          TP_ERROR_CONNECTION_REPLACED);
> +
> 
> Why is this assumption safe?
> 
> Otherwise, looks fine.

I believe the while-connecting case comes out of Wocky as WOCKY_CONNECTOR_ERROR_BIND_CONFLICT instead. I should probably add it to connect/test-fail.py to make sure that's the case.

(In reply to comment #4)
> I believe the while-connecting case comes out of Wocky as
> WOCKY_CONNECTOR_ERROR_BIND_CONFLICT instead.

It doesn't. See updated branch, which expects ConnectionError every time the tests expect a non-REQUESTED DISCONNECTED.

                                  _|_|_
                                ^/ . ..\^
                            ___[=========]___
                 ___-==++""" .  /. . .  \ .  """++==-___
           __-+"" __\   .. . .  | ..  . |  . .  .   /__ ""+-__
          /\__+-""   `-----=====\_ <O> _/=====-----'   ""-+__/\
        _/_/                      ""=""                      \_\_
       /_/                          |                          \_\
      //                            |                            \\
     /")                          \ | /                          ("\
     \o\                           \*/                           /o/
      \_)                       --**O**--                       (_/
                                   /*\
                                  / | \
                                    |

*** Bug 23372 has been marked as a duplicate of this bug. ***

Merged for 0.9.16. Back to NEW, because we still need to cover all the Wocky errors, and perhaps add more errors to the spec; in particular, the case you first thought of isn't covered.

*** Bug 19785 has been marked as a duplicate of this bug. ***

WOCKY_TLS_CERT_ERROR
====================

Easy to map into Telepathy, particularly with the new errors from spec 0.19.11.  We currently don't distinguish between SIGNER_UNKNOWN and SIGNER_UNAUTHORISED (which are both Cert.Untrusted), but I think that's fine.

WOCKY_TLS_CERT_OK maps to Cert.OtherError, but it's an internal error in either Wocky or Gabble if we see that as an error code.

WOCKY_TLS_CERT_INTERNAL_ERROR maps to Cert.OtherError at the moment: we could introduce an InternalError, perhaps?

WOCKY_XMPP_STREAM_ERROR
=======================

This is the urn:ietf:params:xml:ns:xmpp-streams vocabulary from RFC 3920 (XMPP Core). We don't cover it very well at the moment.

We currently map <bad-format/> and all the other "your XML is bad" errors (<bad-namespace-prefix/>, <invalid-xml/>, <restricted-xml/>, <unsupported-encoding/>, and <xml-not-well-formed/>) to NetworkError. I think it's reasonable to conflate them all into one code, but we could perhaps introduce ServiceDenied or something for these "the server says we were wrong" errors?

<conflict/> is handled already.

<connection-timeout/> deserves a ServiceTimeout error ("dropped by the server for being idle"), I think.

<host-unknown/> is currently AuthenticationFailed (because in practice it probably means we're logging in to the wrong server), but it probably deserves an error code, HostUnknown or WrongServer or something. <host-gone/> could be the same or distinct.

<improper-addressing/> only affects s2s AFAICS, so we don't need to care.

<internal-server-error/> deserves a code, perhaps ServiceInternalError. <remote-connection-failed/> is probably the same (it's the server's problem, not ours).

<invalid-from/>, <invalid-id/>, <invalid-namespace/>, <not-authorized/>, <unsupported-stanza-type/>, <unsupported-version/> are all the same as <bad-format/> from our point of view. (Note that <not-authorized/> is *not* PermissionDenied - it's complaining about Gabble's behaviour, not about user behaviour.)

<policy-violation/> might deserve its own error or be PermissionDenied.

<resource-constraint/> isn't currently mapped, but should be ServiceBusy.

<see-other-host/> has special semantics - it has XML cdata which is the hostname or IP address. We need to get that into the ConnectionError details somehow, which probably means GabbleConnection handling it specially.

<system-shutdown/> deserves its own error code, perhaps ServiceShutdown.

<undefined-condition/> is anyone's guess. Perhaps we should follow D-Bus' example and introduce Failed, which explicitly means "we just don't know", or perhaps we should use NotAvailable.

WOCKY_CONNECTOR_ERROR (first half)
==================================

UNKNOWN currently secretly means internal error in Wocky.

IN_PROGRESS would indicate an internal error in Gabble, if reached.

BAD_JID shouldn't be possible if Gabble has validated the 'account' parameter correctly; it's not much of a stretch to use InvalidHandle (it's an invalid thing-that-will-be-a-handle).

NON_XMPP_V1_SERVER isn't relevant to Gabble, which enables legacy Jabber auth, but it could reasonably be NotImplemented ("your server isn't good enough").

BAD_FEATURES means the server got confused or something. ServiceConfused?

TLS_UNAVAILABLE and TLS_REFUSED should probably both be EncryptionNotAvailable?

TLS_SESSION_FAILED should be EncryptionError.

BIND_UNAVAILABLE is "your server isn't good enough" like NON_XMPP_V1_SERVER.

BIND_FAILED I have no idea; how can it fail?

BIND_INVALID is WOCKY_XMPP_ERROR_BAD_REQUEST in response to binding; see also.

BIND_DENIED is WOCKY_XMPP_ERROR_NOT_ALLOWED in response to binding; see also.

BIND_CONFLICT is handled already.

WOCKY_CONNECTOR_ERROR (second half)
===================================

BIND_REJECTED is any unrecognised WOCKY_XMPP_ERROR in reply to resource binding. In the regression tests, this is tested via the well-known <badger-badger-badger-mushroom/> error :-) This is a job for NotAvailable or a new Failed, perhaps.

SESSION_FAILED is a nonsensical reply or internal server error while establishing the session. NotAvailable? NetworkError? ServiceInternalError?

SESSION_DENIED is <forbidden/>. PermissionDenied? CSR_Authentication_Failed?

SESSION_CONFLICT is <conflict/> in reply to session establishment; it's not currently handled in Gabble, afaics, but should be mapped to AlreadyConnected.

The JABBER_AUTH sub-family of errors don't actually appear to be used anywhere.

INSECURE is an attempt to do XEP-0077 registration over an unencrypted connection when this was disallowed, so, EncryptionNotAvailable.

REGISTRATION_FAILED is a nonsensical reply, or any reply other than <service-unavailable>, to the registration form request, or any error stanza when submitting the form that doesn't have a more specific meaning. I don't think there's anything very useful we can do with this?

REGISTRATION_UNAVAILABLE is <service-unavailable> on the registration form request: clearly ServiceBusy.

REGISTRATION_CONFLICT is <conflict/> on the registration form submission, and is already mapped to RegistrationExists.

REGISTRATION_REJECTED is <not-acceptable/> on the registration form submission, or a registration form that requires email when we didn't supply one. We currently map this to PermissionDenied and CSR_Authentication_Failed, but that's a bit rubbish, perhaps?

REGISTRATION_UNSUPPORTED is a registration form that contains fields other than username, password and email. We currently use NotAvailable and CSR_Authentication_Failed.

REGISTRATION_EMPTY is a registration form with no fields, which makes no sense. We don't map this; it could be ServiceInternalError?

UNREGISTER_DENIED is <forbidden/> or <not-allowed/>. UNREGISTER_FAILED is any other failure to unregister. We don't support unregistration in Gabble anyway, so these don't really need mapping yet.

WOCKY_AUTH_ERROR
================

INIT_FAILED doesn't actually ever seem to happen.

NOT_SUPPORTED is <service-unavailable/> during Jabber auth, which means the server doesn't support Jabber auth; it can also mean there are no supported SASL mechanisms, in SASL auth. Should this be AuthenticationFailed, or NotImplemented?

NO_SUPPORTED_MECHANISMS is somewhat similar.

NETWORK is already NetworkError.

INVALID_REPLY is an internal server error or nonsensical reply; see other similar errors above.

NO_CREDENTIALS means we weren't given the username/password. Can this happen in Gabble? AuthenticationFailed seems a fair mapping.

FAILURE is a catch-all for misc failures, so it should probably be AuthenticationFailed.

CONNRESET is already ConnectionLost.

STREAM is any stream error (see above) during SASL or Jabber auth. We currently guess NetworkError; information is lost inside Wocky.

RESOURCE_CONFLICT is <conflict/> for Jabber auth, so it should be AlreadyConnected.

NOT_AUTHORIZED is <not-authorized/>, which normally means the server believes our code is wrong, but in Jabber auth it means incorrect credentials, so, AuthenticationFailed.

NO_CREDENTIALS is <not-acceptable/>, which means we failed to send some info the server requires; probably our fault? AuthenticationFailed seems fair.

> REGISTRATION_UNAVAILABLE is <service-unavailable> on the registration form
> request: clearly ServiceBusy.

... but that's not what <service-unavailable/> means. This should actually be NotImplemented.

WOCKY_XMPP_ERROR
================

These are RFC 3920 stanza errors.

bad-request and unexpected-request are probably internal problems in Gabble or Wocky? We currently map them to NotAvailable.

conflict is currently mapped to CSR_Name_In_Use, NotAvailable, which is the best we can do in general; bits of Gabble are expected to special-case it, and indeed they do.

feature-not-implemented and service-unavailable are NotImplemented, although NotCapable would also be a reasonable guess.

forbidden, payment-required and not-authorized are CSR_Authentication_Failed, PermissionDenied.

gone is DoesNotExist (a reasonable guess, I think).

internal-server-error needs a better mapping, as mentioned above.

item-not-found is DoesNotExist.

jid-malformed is Invalid[thing that would be a]Handle.

recipient-unavailable is Offline.

redirect needs extra info in ConnectionError anyway. We currently guess wildly and say DoesNotExist.

remote-server-not-found is currently DoesNotExist, with a FIXME comment suggesting that it should perhaps be NetworkError; I could go either way.

remote-server-timeout is currently NetworkError.

resource-constraint from the server is exactly ServiceBusy. We can't distinguish between this and the remote UI being busy without further context, unfortunately.

not-allowed, not-acceptable, registration-required and subscription-required are all currently mapped to CSR_Authentication_Failed, PermissionDenied.

undefined-condition is anyone's guess; we use NotAvailable.

(In reply to comment #14)
> WOCKY_AUTH_ERROR

Dealt with as part of redoing SASL support, since it's relevant there. The rest of this bug remains.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-gabble/issues/32.