Протокол доступа
 |
Протокол доступа Push (или PAP )-это протокол, определенный в WAP-164 набора протокола беспроводного приложения (WAP) из открытого мобильного альянса . PAP используется для общения с Push Proxy Gateway , который обычно является частью шлюза WAP .
PAP предназначен для использования при доставке контента из Push -инициаторов для продвижения прокси -шлюзов для последующей доставки к узким полосовым устройствам, включая мобильные телефоны и пейджеры . Примеры сообщений включают новости, котировки акций, погоду, отчеты о трафике и уведомление о таких событиях, как прибытие электронной почты. Благодаря функциональности push пользователи могут получать информацию без необходимости ее запросить. Во многих случаях пользователь важно получить информацию, как только она будет доступна.
Протокол доступа Push не предназначен для использования по воздуху.
PAP разработан, чтобы быть независимым от базового транспортного протокола. PAP указывает следующие возможные операции между инициатором Push и шлюзом Push Proxy:
- Отправить толчок
- Отменить толчок
- Запрос на статус толчка
- Запрос на возможности беспроводных устройств
- Уведомление результата
Взаимодействие между инициаторами Push и шлюзами Push Proxy находится в форме XML -сообщений.
Операции
[ редактировать ]Подчиняться
[ редактировать ]Цель подчинения Push - доставить push -сообщение от Push инициатора в PPG, который затем должен доставить сообщение пользовательскому агенту в устройстве в беспроводной сети. Push -сообщение содержит контрольную сущность и контент -объект и может содержать объект возможностей. Управляющий объект-это документ XML, который содержит управляющую информацию (push-message) для использования PPG для обработки сообщения для доставки. Контент объект представляет контент, который будет отправлен на беспроводное устройство. Сущность возможностей содержит возможности клиента, предполагаемые инициатором Push, и находится в формате RDF [RDF], как определено в профиле пользовательского агента [Uaprof]. PPG может использовать Информация о возможностях, чтобы подтвердить, что сообщение подходит для клиента. Ответ на запрос push-это документ XML (отклик, раздел 9.3), который указывает на начальное признание или сбой. Минимум, PPG должна проверять DTD [XML] контрольного объекта в сообщении и сообщить о результате в ответе. PPG может указать, используя Note Progress-Note (если запрошен инициатором PUSH в атрибуте, заправленном по прогрессу), что другие проверки были завершены. Содержимое и количество нот прогресса являются специфичными для реализации. Типичное ответное сообщение может содержать примечания к прогрессу для каждого этапа внутренней обработки. Используемые этапы обработки являются специфичными для реализации. В сообщении Push есть положения для указания нескольких получателей. Сообщение ответа соответствует сообщению отправки, поэтому есть одно сообщение ответа для одного Push Message, независимо от количества указанных адресов. Если Push -инициатор желает информации, связанной с окончательным результатом доставки, он должен запросить информацию об уведомлении результата в представлении Push и предоставить адрес возврата (например, URL).
Уведомление результата
[ редактировать ]Эта операция используется PPG для информирования инициатора об окончательном результате подчинения Push, если запрошен инициатором Push. Это уведомление (стрелка 5 ниже) сообщает инициатору push, что сообщение было отправлено (передаваемое, как и в стрелке 3), доставлено (подтверждение, полученное от беспроводного устройства, как и в стрелке 4) было отменено, или было отменено или было отменено или было ошибка. Если была ошибка обработки, уведомление должно быть отправлено сразу после обнаружения ошибки в инициатор Push, и сообщение не должно быть отправлено клиенту. В противном случае уведомление должно быть отправлено после завершения процесса доставки сообщений. Процесс доставки считается завершенным, когда сообщение больше не является кандидатом на доставку, например, сообщение истек. Если подчинение Push обозначено как отклоненное на втором этапе на рисунке 3, то уведомление о результатах не будет отправлено. Инициатор Push должен был предоставить обратный адрес (например, URL) во время операции толчка для этого уведомления.
Отмену отталкивания
[ редактировать ]Цель отмены толчка состоит в том, чтобы позволить инициатору Push попытаться отменить ранее отправленное сообщение Push. Push инициатор инициирует эту операцию. PPG отвечает с указанием того, был ли запрос успешным или нет.
Статусный запрос
[ редактировать ]Операция запроса статуса позволяет инициатору Push запрашивать текущее состояние сообщения, которое было ранее представлено. Если запрашивается статус для сообщения, которое адресовано нескольким получателям, PPG должен отправить один ответ, содержащий результаты запроса статуса для каждого из получателей.
Клиентские возможности запроса
[ редактировать ]Эта операция позволяет инициатору Push запрашивать PPG для возможностей определенного устройства. Ответ представляет собой многочисленное/связанное документ, содержащий элемент CCQ-Reponse (раздел 9.11) в документе XML и в Вторая организация, фактическая информация о возможностях клиента в RDF [RDF], как определено в профиле пользовательского агента [Uaprof]. PPG может добавить к сообщаемым возможностям, если PPG готова выполнить преобразования в форматы, поддерживаемые клиентом. Например, если у клиента есть поддержка JPG, но не GIF, а PPG готова конвертировать файлы GIF в JPG, то PPG может сообщить, что клиент может поддерживать файлы JPG и GIF. Сообщаемые возможности могут быть комбинированными возможностями PPG и клиента, и они могут быть получены из возможностей сеанса или извлечены с сервера CC/PP. Возможности также могут быть получены с использованием средств в зависимости от реализации.
Адресация
[ редактировать ]Существует три адреса, которые следует рассмотреть инициатором Push: адрес шлюза Push Proxy Gateway, адрес беспроводного устройства и адрес уведомления результатов. Адрес прокси -шлюза Push должен быть известен инициатором Push. Этот адрес необходим на слое под протоколом доступа. Прокси -шлюз push рассматривается с использованием уникального адреса, который зависит от базового протокола. Например, когда базовый протокол является HTTP, используется URL [RFC1738]. Информация о адресации устройства включена как часть содержимого сообщества (контент с тегом XML). Любой символ, разрешенный в адресе RFC822, может отображаться в поле адреса устройства. Кроме того, инициатор PUSH может быть предоставлен адрес «уведомления о запросе», чтобы инициатор PUSH, чтобы впоследствии Push Proxy Gateway мог впоследствии реагировать на Push-инициатор с уведомлением о результатах.
Многочисленное обращение к получателю
[ редактировать ]Существуют сценарии, в которых инициатор push может захотеть отправлять идентичные сообщения нескольким получателям. Вместо того, чтобы отправлять несколько идентичных push -сообщений, по одному на каждого получателя, Push Push инициатор может отправить одно push -сообщение, адресованное нескольким получателям. Этот раздел предназначен для уточнения поведения, связанного с операциями на нескольких получателей. Когда PPG возвращает сообщение с толканием ответа, после подчинения толчка нескольким получателям ответ соответствует сообщению, независимо от количества получателей, указанных в подчинении Push (есть один ответ для каждого подчинения push). Когда Push-инициатор запрашивает статус (раздел 9.8) с указанными несколькими адресами, PPG должен ответить одним из статусов-ответов (раздел 9.9), содержащей отдельные статусы. То же самое верно, когда указывается только push-id (не указан адрес) в запросе для статуса сообщения с несколькими получателями. Уведомления о результатах (раздел 9.6) должны быть отправлены PPG для каждого отдельного получателя, если уведомление о результате требуется инициатором PUSH во время представления сообщения нескольким получателям. В тех случаях, когда инициатор отправляется несколько получателей, а затем инициатор запрашивается отмена отмена, PPG может отправить отдельные ответы, связанные с каждым из нескольких получателей, или он может отправлять ответы, связанные со многими или всеми получателями. Поддержка нескольких адресов является необязательной в PPG.
Многоадресные/трансляционные адреса
[ редактировать ]Существуют сценарии, в которых один адрес, представленный PI, может быть расширен с помощью PPG на несколько адресов для доставки. Кроме того, один адрес, передаваемый в беспроводной сети, может быть получен несколькими устройствами (например, трансляция). Этот тип обслуживания ожидается для распределения информации, представляющей интерес для широкого населения (например, новости, погода и трафик). Этот раздел предназначен для прояснения поведения, связанного с операциями, связанными с многоадресными и вещательными адресами. Поскольку расширение адреса осуществляется в PPG или в беспроводной сети, поведение между PI и PPG идентично поведению, как если бы адрес не был расширен. Ответ содержит индивидуальный адрес, как представлен PI.
Формат сообщения
[ редактировать ]Протокол доступа Push не зависит от используемого транспорта. Сообщения PAP несут информацию о управлении, а в случае подчинения Push, а также информации о возможностях клиента, необязательно. Информация управления включает в себя командные/ответные сообщения между PPG и инициатором Push, а также параметры, передаваемые в PPG для использования при отправке контента на беспроводное устройство. Примеры этого типа информации включают адрес беспроводного устройства, приоритет доставки сообщения и т. Д. Эта информация обычно не доставляется в беспроводное устройство. Контент - это информация, которая предназначена для беспроводного устройства. Эта информация может быть понятна только для беспроводного устройства (например, может быть зашифрована инициатором Push или может быть данными приложения для приложения, неизвестного PPG), или она может быть распознавана PPG (например, HTML или WML). PPG может быть настроен для выполнения некоторого преобразования в узнаваемом контенте (например, HTML в WML) для определенных беспроводных устройств. Другая категория информации - это информация о возможностях клиента, как указано в профиле пользовательского агента [UAPROF]. Когда в сообщении проводятся больше, чем контроль, формат сообщения представляет собой сложный объект MIME Multipart/Multipr/связанный [RFC2387]. Когда контрольная информация (например, для ответов на сообщения) переносится в сообщении, формат Сообщение - это простое приложение/XML. Вся информация транспортируется в одном теле сообщений. В сообщении Multipart первая объект содержит всю информацию о управлении, связанную с PUSH, в документе XML, вторая сущность содержит содержимое для беспроводного устройства, третья объект, если он присутствует, содержит возможности клиента Uaprof. Формат контентного объекта указан в [pushmsg].
Формат контрольного сущности
[ редактировать ]Контрольная сущность представляет собой часть тела MIME, которая содержит XML -документ, содержащий один элемент PAP, как определено в разделе 9.1. Контрольная сущность должна быть включена в каждый запрос PAP и ответ. Управляющая сущность должна быть первой сущностью в MIME Multipart/Связанном сообщении.
Контент -объект формат
[ редактировать ]Контент -объект - это часть тела MIME, содержащую контент, который будет отправлен на беспроводное устройство. Тип контента не определяется PAP, но может быть любым типом, если он описывается MIME. Контент объект включен только в подчинение Push и не включена в какой -либо другой запрос на операцию или ответ. Контент -сущность должна быть второй сущностью в MIME Multipart/Связанном сообщении.
Возможности объекта формат
[ редактировать ]Сущность возможностей - это часть тела MIME, содержащую предполагаемое подмножество возможностей инициатора Push. Формат возможностей указан в профиле пользовательского агента [UAPROF]. Сущность возможностей, если она присутствует, должна быть третьей организацией в сообщении MIME MIME MIME MIME MUMIME и должна быть вторым объектом в ответе на запрос клиентских возможностей.