Протокол push-доступа - Push Access Protocol

Протокол push-доступа (или же PAP) - это протокол, определенный в WAP-164 Протокол беспроводного приложения (WAP) набор из Открытый мобильный альянс. PAP используется для связи с Push-прокси-шлюз, который обычно является частью WAP шлюз.

PAP предназначен для использования при доставке контента от инициаторов push-уведомлений на шлюзы Push-прокси для последующей доставки на узкополосные устройства, включая мобильные телефоны и пейджеры. Примеры сообщений включают новости, котировки акций, погоду, отчеты о дорожном движении и уведомления о событиях, таких как получение электронной почты. Благодаря функции push пользователи могут получать информацию, не запрашивая ее. Во многих случаях для пользователя важно получить информацию, как только она станет доступной.

Протокол push-доступа не предназначен для использования по воздуху.

PAP разработан, чтобы быть независимым от основного транспортного протокола. PAP определяет следующие возможные операции между инициатором push-уведомлений и шлюзом Push-прокси:

  • Отправить толчок
  • Отменить пуш
  • Запрос статуса push-уведомления
  • Запрос возможностей беспроводного устройства
  • Уведомление о результате

Взаимодействие между инициаторами push-уведомлений и шлюзами Push-прокси осуществляется в форме XML Сообщения.

Операции

Отправить отправку

Назначение Push-отправки - доставить Push-сообщение от Push-инициатора к PPG, который затем должен доставить сообщение пользовательскому агенту на устройстве в беспроводной сети. Push-сообщение содержит объект управления и объект содержимого, а также МОЖЕТ содержать объект возможностей. Управляющий объект - это XML-документ, содержащий управляющую информацию (push-сообщение), которую PPG может использовать при обработке сообщения для доставки. Сущность контента представляет контент, который будет отправлен на беспроводное устройство. Сущность возможностей содержит возможности клиента, принятые инициатором принудительной рассылки, и находится в формате RDF [RDF], как определено в профиле агента пользователя [UAPROF]. PPG МОЖЕТ использовать информацию о возможностях для проверки того, что сообщение подходит для клиента. Ответ на push-запрос - это XML-документ (push-ответ, раздел 9.3), который указывает первоначальное принятие или отказ. Как минимум, PPG ДОЛЖЕН проверить на соответствие DTD [XML] управляющий объект в сообщении и сообщить результат в ответе. PPG МОЖЕТ указать, используя примечание о ходе выполнения (если это запрошено инициатором push в атрибуте progress-notes-requested), что другие проверки были выполнены. Содержание и количество заметок о ходе выполнения зависят от реализации. Типичное ответное сообщение может содержать примечания о ходе выполнения каждого этапа внутренней обработки. Используемые этапы обработки зависят от реализации. В Push-сообщении есть условия для указания нескольких получателей. Ответное сообщение соответствует отправляемому сообщению, поэтому для одного push-сообщения существует одно ответное сообщение, независимо от количества указанных адресов. Если инициатору push требуется информация, относящаяся к окончательному результату доставки, он ДОЛЖЕН запросить информацию об уведомлении о результате в отправке push и предоставить адрес возврата (например, URL).

Уведомление о результате

Эта операция используется PPG для информирования инициатора об окончательном результате отправки push, если этого требует инициатор Push. Это уведомление (стрелка 5, ниже) сообщает инициатору push-уведомлений, что сообщение было отправлено (передано, как показано на стрелке 3), доставлено (получено подтверждение от беспроводного устройства, как показано на стрелке 4), истекло срок его действия, было отменено или было ошибка. Если произошла ошибка обработки, уведомление ДОЛЖНО быть отправлено немедленно после обнаружения ошибки инициатору push-уведомлений, и сообщение не должно отправляться клиенту. В противном случае уведомление ДОЛЖНО быть отправлено после завершения процесса доставки сообщения. Процесс доставки считается завершенным, когда сообщение больше не является кандидатом на доставку, например срок действия сообщения истек. Если push-отправка обозначена как отклоненная на втором шаге на рисунке 3, то уведомление о результате отправляться не будет. Инициатор принудительной отправки ДОЛЖЕН предоставить адрес возврата (например, URL-адрес) во время операции отправки, чтобы это уведомление было возможным.

Нажмите Отмена

Цель отмены push-уведомления - позволить инициатору push-уведомлений попытаться отменить ранее отправленное push-сообщение. Инициатор push инициирует эту операцию. PPG отвечает, указывая, был ли запрос успешным.

Запрос статуса

Операция запроса состояния позволяет инициатору принудительной отправки запрашивать текущий статус сообщения, которое было отправлено ранее. Если запрашивается статус для сообщения, адресованного нескольким получателям, PPG ДОЛЖЕН отправить обратно один ответ, содержащий результаты запроса статуса для каждого из получателей.

Запрос возможностей клиента

Эта операция позволяет инициатору push-уведомлений запрашивать PPG о возможностях конкретного устройства. Ответ представляет собой составной / связанный документ, содержащий элемент ccq-response (раздел 9.11) в документе XML и, во втором объекте, информацию о фактических возможностях клиента в RDF [RDF], как определено в профиле агента пользователя [UAPROF]. PPG МОЖЕТ добавить к сообщаемым возможностям, если PPG желает выполнять преобразования в форматы, поддерживаемые клиентом. Например, если у клиента есть поддержка JPG, но нет GIF, а PPG желает преобразовать файлы GIF в JPG, то PPG может сообщить, что клиент может поддерживать файлы JPG и GIF. Сообщаемые возможности могут быть объединенными возможностями PPG и клиента, и они могут быть получены из возможностей сеанса или получены с сервера CC / PP. Возможности также могут быть получены с использованием средств, зависящих от реализации.

Обращение

Инициатор push-уведомлений должен учитывать три адреса: адрес шлюза push-прокси, адрес беспроводного устройства и адрес уведомления о результате. Адрес шлюза прокси-сервера push должен быть известен инициатору push-уведомлений. Этот адрес необходим на уровне ниже протокола push-доступа. Шлюз push-прокси адресуется с использованием уникального адреса, который зависит от базового протокола. Например, если основным протоколом является HTTP, используется URL [RFC1738]. Информация об адресации устройства включена как часть содержимого сообщения (содержимое с тегами XML). Любой символ, разрешенный в адресе RFC822, может появиться в поле адреса устройства. Кроме того, при необходимости инициатором push-рассылки может быть предоставлен адрес «уведомить-запрашиваемый», чтобы шлюз-прокси-сервер push мог позже ответить инициатору push-уведомлений с уведомлением о результате.

Адресация множественных получателей

Существуют сценарии, в которых инициатор push может захотеть отправить идентичные сообщения нескольким получателям. Вместо того чтобы отправлять несколько идентичных push-сообщений, по одному каждому получателю, инициатор push-уведомлений может отправить одно push-сообщение, адресованное нескольким получателям. Этот раздел предназначен для пояснения поведения, связанного с операциями с несколькими получателями. Когда PPG возвращает сообщение push-ответа, после отправки push нескольким получателям ответ соответствует сообщению, независимо от количества получателей, указанного в отправке push (для каждой отправки push есть один ответ). Когда инициатор принудительной отправки запрашивает статус (раздел 9.8) с указанием нескольких адресов, PPG ДОЛЖЕН ответить одним ответом на запрос статуса (раздел 9.9), содержащим отдельные статусы. То же самое верно, когда в запросе состояния сообщения с несколькими получателями указан только push-id (адрес не указан). Уведомления о результатах (раздел 9.6) ДОЛЖНЫ быть отправлены PPG для каждого отдельного получателя, если уведомление о результате запрашивается инициатором push во время отправки сообщения нескольким получателям. В случаях, когда сообщение отправляется нескольким получателям, а затем инициатор запрашивает отмену, PPG МОЖЕТ отправить обратно отдельные ответы, относящиеся к каждому из нескольких получателей, или МОЖЕТ отправлять ответы, относящиеся ко многим или всем получателям. Поддержка нескольких адресов является ДОПОЛНИТЕЛЬНОЙ в PPG.

Многоадресные / широковещательные адреса

Существуют сценарии, в которых один адрес, представленный PI, может быть расширен PPG на несколько адресов для доставки. Кроме того, один адрес, передаваемый по беспроводной сети, может быть получен несколькими устройствами (например, широковещательная передача). Предполагается, что этот тип услуг предназначен для распространения интересующей информации среди широких слоев населения (например, новостей, погоды и трафика). Этот раздел предназначен для пояснения поведения, связанного с операциями, включающими многоадресная передача и широковещательные адреса. Поскольку расширение адреса выполняется в PPG или в беспроводной сети, поведение между PI и PPG идентично поведению, как если бы адрес не был расширен. Ответ содержит индивидуальный адрес, представленный ИП.

Формат сообщения

Протокол push-доступа не зависит от используемого транспорта. Сообщения PAP несут управляющую информацию, а в случае push-отправки также контент и, необязательно, информацию о возможностях клиента. Управляющая информация включает в себя сообщения команды / ответа между PPG и инициатором push, а также параметры, передаваемые PPG для использования при отправке контента на беспроводное устройство. Примеры такого типа информации включают адрес беспроводного устройства, приоритет доставки сообщения и т. Д. Обычно эта информация не доставляется на беспроводное устройство. Контент - это информация, предназначенная для беспроводного устройства. Эта информация может быть понятна только беспроводному устройству (например, может быть зашифрована инициатором принудительной отправки или может быть данными приложения для приложения, неизвестного PPG), или она может быть распознана PPG (например, HTML или WML). PPG может быть настроен на выполнение некоторого преобразования распознаваемого контента (например, HTML в WML) для определенных беспроводных устройств. Другая категория информации - это информация о возможностях клиента, как указано в профиле агента пользователя [UAPROF]. Когда в сообщении передается больше, чем просто управление, формат сообщения является составным объектом MIME multipart / related [RFC2387]. Когда в сообщении передается только управляющая информация (например, для ответов на сообщения), формат сообщения представляет собой простой объект application / xml. Вся информация передается в одном теле сообщения. В составных сообщениях первый объект содержит всю управляющую информацию, связанную с принудительной отправкой, в XML-документе, второй объект содержит контент для беспроводного устройства, третий объект, если он присутствует, содержит возможности клиента UAPROF. Формат объекта содержимого указывается в [PushMsg].

Формат объекта управления

Управляющий объект - это часть тела MIME, которая содержит XML-документ, содержащий один элемент pap, как определено в разделе 9.1. Управляющий объект ДОЛЖЕН быть включен в каждый запрос и ответ PAP. Управляющий объект ДОЛЖЕН быть первым объектом в сообщении MIME multipart / related.

Формат сущности содержимого

Сущность контента - это часть тела MIME, содержащая контент, который должен быть отправлен на беспроводное устройство. Тип содержимого не определяется PAP, но может быть любым, если он описывается MIME. Сущность содержимого включается только в push-отправку и не включается ни в какие другие запросы или ответы операции. Объект содержимого ДОЛЖЕН быть вторым объектом в сообщении MIME multipart / related.

Формат сущности возможностей

Сущность возможностей - это часть тела MIME, содержащая предполагаемое подмножество возможностей беспроводного устройства / пользовательского агента инициатором push-уведомлений. Формат возможностей указан в профиле агента пользователя [UAPROF]. Объект возможностей, если он присутствует, ДОЛЖЕН быть третьим объектом в многочастном / связанном сообщении MIME Push Submission и ДОЛЖЕН быть вторым объектом в ответе на запрос возможностей клиента.

внешняя ссылка