Протокол push-доступа
 |
Протокол push-доступа (или PAP ) — это протокол, определенный в WAP-164 пакета протоколов беспроводных приложений (WAP) от Open Mobile Alliance . PAP используется для связи с шлюзом Push Proxy , который обычно является частью шлюза WAP .
PAP предназначен для использования при доставке контента от push-инициаторов к push-прокси-шлюзам для последующей доставки на узкополосные устройства, включая мобильные телефоны и пейджеры . Примеры сообщений включают новости, котировки акций, погоду, отчеты о дорожном движении и уведомления о таких событиях, как получение электронной почты. Благодаря функции Push пользователи могут получать информацию, не запрашивая ее. Во многих случаях пользователю важно получить информацию, как только она станет доступна.
Протокол push-доступа не предназначен для использования по беспроводной сети.
PAP разработан таким образом, чтобы быть независимым от базового транспортного протокола. PAP определяет следующие возможные операции между инициатором push-уведомлений и шлюзом push-прокси:
- Отправить запрос
- Отменить push-уведомление
- Запрос статуса push-уведомления
- Запрос возможностей беспроводного устройства
- Уведомление о результате
Взаимодействие между инициаторами push-уведомлений и шлюзами push-прокси осуществляется в форме XML- сообщений.
Операции
[ редактировать ]Push-отправка
[ редактировать ]Целью push-отправки является доставка push-сообщения от инициатора push-уведомлений в PPG, который затем должен доставить сообщение пользовательскому агенту на устройстве в беспроводной сети. Сообщение Push содержит объект управления и объект контента и МОЖЕТ содержать объект возможностей. Объект управления — это XML-документ, содержащий управляющую информацию (push-сообщение), которую PPG может использовать при обработке сообщения для доставки. Объект контента представляет контент, который должен быть отправлен на беспроводное устройство. Объект возможностей содержит возможности клиента, предполагаемые инициатором push-уведомлений, и имеет формат 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, уведомление о результате отправлено не будет. Инициатор push-уведомлений ДОЛЖЕН предоставить обратный адрес (например, URL-адрес) во время операции push-уведомления, чтобы это уведомление было возможным.
Нажмите Отмена
[ редактировать ]Цель отмены push-уведомлений — позволить инициатору push-уведомлений попытаться отменить ранее отправленное push-сообщение. Инициатор Push инициирует эту операцию. PPG отвечает, указывая, был ли запрос успешным или нет.
Запрос статуса
[ редактировать ]Операция запроса статуса позволяет инициатору push-уведомлений запрашивать текущий статус сообщения, которое было отправлено ранее. Если статус запрашивается для сообщения, адресованного нескольким получателям, 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-прокси адресуется с использованием уникального адреса, который зависит от базового протокола. Например, если базовым протоколом является HTTP, используется URL-адрес [RFC1738]. Информация об адресации устройства включается как часть содержимого сообщения (содержимое с тегами XML). В поле адреса устройства может присутствовать любой символ, разрешенный в адресе RFC822. Кроме того, адрес «запрошенного уведомления» может быть предоставлен инициатором push-уведомлений, когда это необходимо, чтобы шлюз push-прокси мог позже ответить инициатору push-уведомлений уведомлением о результате.
Адресация нескольких получателей
[ редактировать ]Существуют сценарии, в которых инициатор push-уведомлений может захотеть отправить одинаковые сообщения нескольким получателям. Вместо отправки нескольких идентичных push-сообщений, по одному каждому получателю, инициатор push-уведомлений может отправить одно push-сообщение, адресованное нескольким получателям. Этот раздел предназначен для разъяснения поведения, связанного с операциями с несколькими получателями. Когда PPG возвращает ответное сообщение, после отправки push нескольким получателям ответ соответствует сообщению, независимо от количества получателей, указанных в push-отправке (для каждой push-отправки существует один ответ). Когда инициатор push-уведомлений запрашивает статус (раздел 9.8) с указанием нескольких адресов, PPG ДОЛЖЕН ответить одним статусным ответом (раздел 9.9), содержащим отдельные статусы. То же самое верно, когда в запросе статуса сообщения с несколькими получателями указан только идентификатор push-уведомления (адрес не указан). Уведомления о результатах (раздел 9.6) ДОЛЖНЫ отправляться PPG для каждого отдельного получателя, если уведомление о результате запрашивается инициатором push-уведомлений во время отправки сообщения нескольким получателям. В случаях, когда сообщение отправляется нескольким получателям, а затем инициатор запрашивает отмену, PPG МОЖЕТ отправлять обратно отдельные ответы, относящиеся к каждому из нескольких получателей, или МОЖЕТ отправлять ответы, относящиеся ко многим или всем получателям. Поддержка нескольких адресов в PPG НЕОБЯЗАТЕЛЬНА.
Адреса групповой/широковещательной рассылки
[ редактировать ]Существуют сценарии, в которых один адрес, предоставленный PI, может быть расширен PPG на несколько адресов для доставки. Кроме того, один адрес, передаваемый по беспроводной сети, может быть принят несколькими устройствами (например, широковещательно). Ожидается, что этот тип службы будет использоваться для распространения информации, представляющей интерес для широких слоев населения (например, новостей, погоды и дорожного движения). Этот раздел предназначен для разъяснения поведения, связанного с операциями, включающими многоадресные и широковещательные адреса. Поскольку расширение адреса выполняется в PPG или в беспроводной сети, поведение между PI и PPG идентично поведению, как если бы адрес не был расширен. Ответ содержит индивидуальный адрес, предоставленный PI.
Формат сообщения
[ редактировать ]Протокол push-доступа не зависит от используемого транспорта. Сообщения PAP содержат управляющую информацию, а в случае принудительной отправки также информацию о контенте и, возможно, возможностях клиента. Управляющая информация включает в себя сообщения команд/ответов между PPG и инициатором push-уведомлений, а также параметры, передаваемые в PPG для использования при отправке контента на беспроводное устройство. Примеры информации этого типа включают адрес беспроводного устройства, приоритет доставки сообщения и т. д. Обычно эта информация не доставляется на беспроводное устройство. Контент — это информация, предназначенная для беспроводного устройства. Эта информация может быть понятна только беспроводному устройству (например, может быть зашифрована инициатором push-уведомлений или может представлять собой данные приложения для приложения, неизвестного PPG) или может быть распознаваема PPG (например, HTML или WML). PPG может быть сконфигурирован для выполнения некоторого преобразования распознаваемого контента (например, HTML в WML) для определенных беспроводных устройств. Другая категория информации — это информация о возможностях клиента, как указано в профиле пользовательского агента [UAPROF]. Если в сообщении содержится не только управление, формат сообщения представляет собой составной объект MIME, состоящий из нескольких частей/связанный [RFC2387]. Когда в сообщении передается только управляющая информация (например, для ответов на сообщения), формат message — это простой объект application/xml. Вся информация передается в одном теле сообщения. В составных сообщениях первый объект содержит всю управляющую информацию, связанную с отправкой сообщений, в документе XML, второй объект содержит контент для беспроводного устройства, третий объект, если он присутствует, содержит возможности клиента UAPROF. Формат объекта контента указан в [PushMsg].
Формат объекта управления
[ редактировать ]Объект управления — это часть тела MIME, содержащая XML-документ, содержащий один элемент pap, как определено в разделе 9.1. Объект управления ДОЛЖЕН быть включен в каждый запрос и ответ PAP. Объект управления ДОЛЖЕН быть первым объектом в составном/связанном сообщении MIME.
Формат объекта контента
[ редактировать ]Объект контента — это часть тела MIME, содержащая контент, который должен быть отправлен на беспроводное устройство. Тип контента не определяется PAP, но может быть любым типом, если он описан MIME. Объект контента включается только в push-отправку и не включается ни в какой другой запрос или ответ операции. Объект контента ДОЛЖЕН быть вторым объектом в составном/связанном сообщении MIME.
Формат сущности возможностей
[ редактировать ]Объект возможностей представляет собой часть тела MIME, содержащую предполагаемое подмножество возможностей беспроводного устройства/пользовательского агента инициатора push-уведомлений. Формат возможностей указан в профиле пользовательского агента [UAPROF]. Объект возможностей, если он присутствует, ДОЛЖЕН быть третьим объектом в многочастном/связанном сообщении MIME принудительной отправки и ДОЛЖЕН быть вторым объектом в ответе на запрос возможностей клиента.