¿Cuál es la respuesta correcta del cliente XMPP a un < presencia type = unsubsigned & # 8230; > ¿estrofa?

Question

Esto es lo que me envía el servidor (openfire) cuando elimino manualmente un contacto de la lista en el servidor:

'<iq type="set" id="183-87" to="foo@edmund.local/hydra"><query xmlns="jabber:iq:roster"><item jid="bar@yahoo.edmund.local" name="baz" ask="unsubscribe" subscription="none"><group>Buddies</group></item></query></iq>'
'<iq type="set" id="187-88" to="foo@edmund.local/hydra"><query xmlns="jabber:iq:roster"><item jid="bar@yahoo.edmund.local" name="baz" subscription="none"><group>Buddies</group></item></query></iq>'
'<presence type="unsubscribed" to="foo@edmund.local" from="bar@yahoo.edmund.local"/>'

Si respondo con una estrofa de presencia 'cancelar suscripción' (que creo que es correcta de acuerdo con RFC 3921), el servidor sigue enviándome correo no deseado con más presencias 'no suscritas'.

De cualquier manera, la próxima vez que mi cliente inicie sesión, nada ha cambiado en la lista. ¿Estoy haciendo algo mal?

Answer 1

Depende de qué cliente esté hablando, ya sea el suscriptor o el suscriptor.

.

Si el cliente es el suscriptor, entonces nada:

Según la sección 9.4 , si el suscriptor envía un < code> unsubscribe , o algo más hace que el cliente sea dado de baja, el servidor debe acusar recibo de la solicitud / informar el cambio de estado con una respuesta unsubscribe . Ese es el final de la interacción.

Si el suscriptor envía otra solicitud unsubscribe cada vez que se le informa que recibe un estado unsubscribe del servidor que le informa que se ha eliminado una suscripción anterior, entonces lo hará nunca termina.

.

Si el cliente es el nodo suscrito, entonces se le puede enviar una cancelar suscripción para confirmar que se permite eliminar la suscripción, pero si eso sigue vigente cuando cambia la lista fuera de lo normal mecanismo no estoy seguro.

Mi lectura de la tabla en 9.4 es para los mensajes entre el suscriptor y el servidor durante la cancelación de la suscripción es:

subscriber            server             subscribee
    | -- unsubscribe --> |                    |
    |                    | -- unsubscribe --> |
    |                    | <- unsubscribed -- | (optional)
    |                    | -- unsubscribed -> |
    | <- unsubscribed -- |                    |

Mi lectura de sección 8.6 , la eliminación de la lista es la siguiente:

subscriber            server             subscribee
    | ----- remove ----> |                    |
    |                    | -- unsubscribe --> |
    |                    | -- unsubscribed -> |
    |                    | -- unavailable --> |
    | <- unsubscribed -- |                    |
    | <-- unavailable -- |                    |

Sin el reconocimiento requerido por ninguno de los clientes.

Answer 2

Estoy demasiado oxidado para poder darte una respuesta directa, pero como han pasado algunas horas sin respuestas, déjame hacerte una sugerencia ...

Cargue pidgin o algún otro cliente que pueda registrar el flujo xml, envíe la cancelación de la suscripción desde ese cliente y luego copie el código que ve en el registro.

Eso lo ayudará a obtener las estrofas correctas o identificará una incompatibilidad en fuego abierto (poco probable, pero quién sabe).