6.2. Narrative
Когда инициатор аутентифицирует получателя, используя SASL, процедура включает в себя следующие шаги:
Инициатор запрашивает аутентификацию SASL путем включения атрибута 'version' в открывающий заголовок XML потока, направленного получателю, со значением равным "1.0".
После посылки заголовка XML-потока в виде отклика, получатель анонсирует список доступных механизмов аутентификации SASL; каждый из этих элементов <mechanism/> включаются в качестве дочерних в контейнерный элемент <mechanisms/>, соотнесенный с пространством имен 'urn:ietf:params:xml:ns:xmpp-sasl', который в свою очередь является дочерним элементом <features/> в пространстве имен потока. Если TLS (раздел 5) нужно установить, прежде чем использовать какой-то конкретный механизм аутентификации, получатель не должен помещать этот механизм в список механизмов аутентификации SASL, до согласования TLS. Если инициатор предоставляет корректный сертификат при предварительном согласовании TLS, получатель при согласовании SASL должен предложить инициатору механизм SASL EXTERNAL (смотри [SASL]), хотя механизм EXTERNAL может быть предложен также и при других обстоятельствах.
Инициатор выбирает механизм путем посылки элемента <auth/>, соотнесенного с пространством имен 'urn:ietf:params:xml:ns:xmpp-sasl', получателю. Элемент содержит также значение атрибута 'mechanism'. Этот элемент может содержать символьные XML-данные (в терминологии SASL, "исходный отклик"), если механизм поддерживает или требует этого. Если инициатор должен послать исходный отклик нулевой длины, он должен передать отклик в виде одиночного символа равенства ("="), который указывает, что этот отклик не содержит данных.
Если необходимо, получатель направляет вызов инициатору путем посылки инициатору элемента <challenge/>, соотнесенного с пространством имен 'urn:ietf:params:xml:ns:xmpp-sasl'. Этот элемент может содержать символьные данные (которые должны быть обработаны в соответствии с определением механизма SASL, который выбрал инициатор).
Инициатор реагирует на вызов посылкой получателю элемента <response/>, соотнесенного с пространством имен 'urn:ietf:params:xml:ns:xmpp-sasl'. Этот элемент может содержать символьную XML-информацию (которая должна быть обработана в соответствии с определением механизма SASL, который выбрал инициатор).
Если необходимо, получатель посылает несколько вызовов, а инициатор отправляет несколько откликов.
Эти последовательности вызов/отклик продолжаются до тех пор пока не случится одно из трех событий:
Инициатор обрывает диалог посылкой получателю элемента <abort/>, соотносящегося с пространством имен 'urn:ietf:params:xml:ns:xmpp-sasl'. После получения элемента <abort/> получатель должен разрешить конфигурируемое но разумное число повторных попыток (по крайней мере 2), после которых он должен прервать TCP-соединение. Это позволяет инициатору (например, конечному пользователю — клиенту) перепроверить неверно выданные параметры авторизации (например, опечатку в пароле) без необходимости выполнения повторного соединения.
Получатель сообщает о неудаче диалога посылкой инициатору элемента <failure/>, соотносящегося пространству имен 'urn:ietf:params:xml:ns:xmpp-sasl', конкретная причина неудачи должна быть сообщена в соответствующем дочернем элементе элемента <failure/>, как это определено главе "Ошибки SASL" (раздел 6.4). В случае неудачи получатель должен разрешить конфигурируемое, но разумное число повторных попыток (по крайней мере 2), после которых он должен прервать TCP-соединение. Это позволяет инициатору (например, конечному пользователю — клиенту) перепроверить неверно выданные параметры авторизации (например, опечатку в пароле) без необходимости выполнения повторного соединения.
Получатель сообщает об успехе диалога посылкой инициатору элемента <success/>, соотносимого с пространством имен 'urn:ietf:params:xml:ns:xmpp-sasl'. Этот элемент может содержать символьную XML-информацию (в терминологии SASL "дополнительные данные при успехе"), если это требуется выбранным механизмом SASL. После получения элемента <success/> инициатор должен сформировать новый поток, путем посылки открывающего заголовка XML-потока получателю (посылать закрывающий тэг </stream> не нужно, так как приемник и инициатор должны рассматривать исходный поток закрытым после отправки или получения элемента <success/>). После получения заголовка нового потока от инициатора получатель должен реагировать посылкой инициатору нового заголовка потока и информировать партнера об имеющихся возможностях посредством элемента <features/>.