Push Access Protocol(푸시 액세스 프로토콜)
Push Access Protocol |
Push Access Protocol(PAP)은 Open Mobile Alliance의 Wireless Application Protocol(WAP) 스위트의 WAP-164에서 정의된 프로토콜입니다.PAP 는, 통상, WAP 게이트웨이의 일부인 푸시 프록시 게이트웨이와의 통신에 사용됩니다.
PAP은 Push Initiators에서 Push Proxy Gateways로 콘텐츠를 전송하고 이후 휴대 전화나 호출기 등의 협대역 디바이스에 전달하는 것을 목적으로 하고 있습니다.메시지 예로는 뉴스, 주가, 날씨, 교통 보고서, 이메일 도착 등의 이벤트 알림이 있습니다.푸시 기능을 통해 사용자는 요청하지 않고도 정보를 받을 수 있습니다.대부분의 경우 사용자가 정보를 입수하는 즉시 정보를 입수하는 것이 중요합니다.
Push Access Protocol(푸시 액세스 프로토콜)은 무선으로 사용할 수 없습니다.
PAP은 기본 전송 프로토콜로부터 독립하도록 설계되었습니다.PAP은 푸시 이니시에이터와 푸시 프록시 게이트웨이 간에 가능한 다음 작업을 지정합니다.
- 푸시 전송
- 푸시 취소
- 푸시 상태 쿼리
- 무선 디바이스 기능 쿼리
- 결과 통지
푸시 이니시에이터와 푸시 프록시 게이트웨이 간의 상호 작용은 XML 메시지 형식으로 이루어집니다.
운용
송신 푸시
Push Submission의 목적은 Push Initiator에서PPG로 Push 메시지를 전달하는 것입니다.PPG는 무선 네트워크상의 디바이스의 사용자 에이전트에게 메시지를 전달합니다.Push 메시지에는 제어 엔티티와 콘텐츠엔티티가 포함되어 있으며 MAY에는 기능 엔티티가 포함되어 있을 수 있습니다.제어 엔티티는 PPG가 메시지 전달 처리에 사용하는 제어 정보(푸시 메시지)를 포함하는 XML 문서입니다.콘텐츠 엔티티는 무선 디바이스로 전송되는 콘텐츠를 나타냅니다.기능 엔티티에는 푸시 이니시에이터가 가정한 클라이언트 기능이 포함되어 있으며 User Agent Profile [UAPROF]에 정의된 RDF [RDF]형식입니다.PPG MAY는 기능 정보를 사용하여 메시지가 클라이언트에 적합한지 검증합니다.푸시 요청에 대한 응답은 초기 승인 또는 실패를 나타내는 XML 문서(push-response, 섹션 9.3)입니다.최소한 PPG는 메시지 내의 제어 엔티티를 DTD [XML]에 대해 검증하고 결과를 응답으로 보고해야 합니다.PPG MAY는 Progress-Notes-Requested 속성의 Push Initiator가 요청한 경우 Progress-Notes-Requested 속성을 사용하여 다른 검증이 완료되었음을 나타낼 수 있습니다.프로그레스 노트의 내용과 수는 구현에 따라 다릅니다.일반적인 응답 메시지에는 내부 처리의 각 단계에 대한 진행률 메모가 포함될 수 있습니다.사용되는 처리 단계는 구현에 따라 다릅니다.Push 메시지에는 여러 수신인을 지정하는 조항이 있습니다.응답 메시지는 송신 메시지에 대응하므로 지정된 주소 수에 관계없이1개의 푸시 메시지에 대해1개의 응답 메시지가 있습니다.Push Initiator가 전달의 최종 결과와 관련된 정보를 원하는 경우, Push 제출 시 결과 알림 정보를 요청하고 반환 주소(예: URL)를 제공해야 합니다.
결과 통지
이 작업은 PPG가 Push Initiator가 요청할 경우 Push 제출의 최종 결과를 이니시에이터에 알리기 위해 사용합니다.이 알림(아래 화살표 5), 푸시 이니시에이터에 메시지가 발송(화살표 3과 같이 전송), 배달(화살표 4와 같이 무선 디바이스로부터 수신 확인), 만료, 취소 또는 오류 발생을 알립니다.처리 오류가 있는 경우 Push Initiator에 오류가 검출된 즉시 알림이 전송되어야 하며 메시지는 클라이언트에 전송되지 않아야 합니다.그렇지 않으면 메시지 전달 프로세스가 완료된 후에 알림을 전송해야 합니다.메시지가 더 이상 배달 대상이 아닌 경우(예: 메시지가 만료됨) 배달 프로세스는 완료된 것으로 간주됩니다.그림 3의 2단계에서 푸시 제출이 거부된 것으로 표시되면 결과 알림이 전송되지 않습니다.푸시 이니시에이터가 푸시 작업 중에 반환 주소(예: URL)를 제공해야 이 알림이 가능합니다.
푸시 취소
푸시 취소의 목적은 Push Initiator가 이전에 제출한 푸시 메시지를 취소할 수 있도록 하는 것입니다.푸시 이니시에이터가 이 작업을 시작합니다.PPG는 요구가 성공했는지 여부를 나타내는 응답으로 응답합니다.
상태 쿼리
상태 쿼리 작업을 통해 푸시 이니시에이터는 이전에 전송된 메시지의 현재 상태를 요청할 수 있습니다.여러 수신인에게 발송된 메시지에 대해 상태가 요청되면 PPG는 각 수신인에 대한 상태 쿼리 결과를 포함하는 단일 응답을 반환해야 합니다.
클라이언트 기능 쿼리
이 작업을 통해 푸시 이니시에이터는 PPG에 특정 장치의 기능을 쿼리할 수 있습니다.응답은 XML 문서의 ccq-response(섹션 9.11) 요소를 포함하는 멀티파트/관련 문서이며, 두 번째 엔티티에서는 User Agent Profile(UAPROF)에 정의된 대로 RDF[RDF]의 실제 클라이언트 기능 정보를 포함합니다.PPG가 클라이언트가 지원하는 형식으로 변환을 수행할 의향이 있는 경우 PPG는 보고되는 기능을 추가할 수 있습니다.예를 들어 클라이언트가 JPG를 지원하지만 GIF는 지원하지 않고 PPG가 GIF 파일을 JPG로 변환하려는 경우 PPG는 클라이언트가 JPG 및 GIF 파일을 지원할 수 있다고 보고할 수 있습니다.보고되는 기능은 PPG와 클라이언트의 기능을 조합한 것으로 세션 기능에서 파생되거나 CC/PP 서버에서 취득되었을 가능성이 있습니다.기능은 구현에 의존한 수단을 사용하여 도출할 수도 있습니다.
주소 지정
푸시 이니시에이터는 푸시 프록시 게이트웨이 주소, 무선 디바이스 주소 및 결과 알림 주소의 3가지 주소를 고려합니다.푸시 프록시 게이트웨이 주소는 푸시 이니시에이터가 알고 있어야 합니다.이 주소는 Push Access Protocol 아래의 계층에 필요합니다.푸시 프록시 게이트웨이는 기본 프로토콜에 따라 달라지는 고유한 주소를 사용하여 주소 지정됩니다.예를 들어 기본 프로토콜이 HTTP인 경우 URL [RFC1738]이 사용됩니다.디바이스 주소 지정 정보는 메시지콘텐츠(XML 태그 부착 콘텐츠)의 일부로 포함됩니다.RFC822 주소에서 허용되는 문자는 디바이스 주소 필드에 표시될 수 있습니다.또한 푸시 프록시 게이트웨이가 나중에 결과 알림으로 푸시 이니시에이터에 응답할 수 있도록 필요할 때 푸시 이니시에이터에 "notify-requested-to" 주소를 제공할 수 있습니다.
복수 수신자 주소 지정
푸시 이니시에이터가 여러 수신인에게 동일한 메시지를 보낼 수 있는 시나리오가 있습니다.Push Initiator는 동일한 푸시 메시지를 여러 수신자에게 1개씩 전송하는 대신 여러 수신자에게 발송되는 단일 푸시 메시지를 전송할 수 있습니다.이 섹션은 여러 수신자에 대한 작업과 관련된 동작을 명확히 하기 위한 것입니다.PPG가 푸시 응답 메시지를 반환할 때 여러 수신자에게 푸시 전송 후 응답은 푸시 전송으로 지정된 수신인 수에 관계없이 메시지에 대응합니다(푸시 전송마다 응답이1개).Push Initiator가 여러 주소를 지정하여 상태(섹션 9.8)를 요청하면 PPG는 개별 상태를 포함하는 단일 상태 쿼리-응답(섹션 9.9)으로 응답해야 합니다.여러 수신인 메시지의 상태에 대한 쿼리에서 push-id만 지정(주소 지정 없음)된 경우에도 마찬가지입니다.여러 수신자에게 메시지를 보내는 동안 Push Initiator가 결과 통지를 요청하는 경우, 결과 통지(9.6항)는 각 수신자에 대해 PPG에 의해 전송되어야 합니다.메시지가 여러 수신자에게 전송되고 나중에 이니시에이터에 의해 취소가 요청될 경우 PPG는 여러 수신자에게 개별 응답을 반환하거나 많은 수신자에게 또는 모든 수신자와 관련된 응답을 보낼 수 있습니다.PPG에서는 여러 주소의 지원은 옵션입니다.
멀티캐스트/브로드캐스트어드레스
PI에 의해 송신된 단일 주소가 PPG에 의해 복수의 주소로 확장되어 전달되는 시나리오가 있습니다.또, 무선 네트워크상에서 송신되는 단일의 주소를 복수의 디바이스(예를 들면 브로드캐스트)에 의해서 수신할 수 있다.이러한 유형의 서비스는 관심 있는 정보를 광범위한 인구(예: 뉴스, 날씨 및 교통)에 배포하기 위해 기대된다.이 섹션은 멀티캐스트주소와 브로드캐스트주소를 포함한 동작에 관한 동작을 명확히 하는 것을 목적으로 합니다.주소 확장은 PPG 또는 무선 네트워크에서 이루어지기 때문에 PI와 PPG 간의 동작은 주소가 확장되지 않은 경우와 동일합니다.응답에는 PI에 의해 제출된 개별 주소가 포함됩니다.
메시지 형식
푸시 액세스 프로토콜은 사용되는 전송과 독립적입니다.PAP 메시지는 제어 정보를 전달하며, 푸시 전송의 경우 내용 및 선택적으로 클라이언트 기능 정보를 전달합니다.제어정보는 PPG와 푸시 이니시에이터 간의 명령/응답 메시지 및 무선장치에 콘텐츠를 송신하기 위해 PPG에 전달되는 파라미터를 포함한다.이러한 종류의 정보의 예로는 무선 디바이스 주소, 메시지 전달 우선순위 등이 있습니다.이 정보는 보통 무선 디바이스에 전달되지 않습니다.콘텐츠는 무선 디바이스용 정보입니다.이 정보는 무선 디바이스(Push Initiator에 의해 암호화되거나 PPG에 의해 알려지지 않은 애플리케이션의 애플리케이션 데이터 등)에만 인식될 수 있습니다(HTML 또는 WML 등).PPG는 특정 무선 디바이스의 인식 가능한 콘텐츠(HTML에서 WML로 등)에 대해 일부 변환을 수행하도록 구성할 수 있습니다.다른 카테고리의 정보는 User Agent Profile [UAPROF]에서 지정된 클라이언트 기능 정보입니다.메시지로 여러 제어가 전송되는 경우 메시지 형식은 MIME 멀티파트/관련 [RFC2387] 복합 객체입니다.메시지 내에서 제어 정보(예를 들어 메시지 응답용)만 전송되는 경우 메시지 형식은 단순한 애플리케이션/xml 엔티티입니다.모든 정보는 단일 메시지 본문 내에서 전송됩니다.멀티파트 메시지에서 첫 번째 엔티티는 XML 문서 내의 모든 푸시 관련 제어 정보를 포함하고, 두 번째 엔티티는 무선 디바이스용 콘텐츠를 포함하고, 세 번째 엔티티는 존재하는 경우 UAPROF 클라이언트 기능을 포함한다.콘텐츠 엔티티의 형식은 [PushMsg]에 명시되어 있습니다.
제어 엔티티 형식
제어 엔티티는 섹션 9.1에 정의된 대로 하나의 pap 요소를 포함하는 XML 문서를 유지하는 MIME 본문 부분입니다.제어 엔티티는 모든 PAP 요청 및 응답에 포함되어야 합니다.컨트롤 엔티티는 MIME 멀티파트/관련 메시지의 첫 번째 엔티티여야 합니다.
콘텐츠 엔티티 형식
콘텐츠 엔티티는 무선 장치로 전송되는 콘텐츠를 포함하는 MIME 본문 부분입니다.콘텐츠 타입은 PAP에 의해 정의되지 않지만 MIME에 의해 설명되는 한 임의의 타입이 될 수 있습니다.콘텐츠 엔티티는 푸시 송신에만 포함되어 다른 조작 요구나 응답에는 포함되지 않습니다.콘텐츠 엔티티는 MIME 멀티파트/관련 메시지의 두 번째 엔티티여야 합니다.
기능 엔티티 형식
capabilities 엔티티는 푸시 이니시에이터가 상정하는 무선 디바이스/사용자 에이전트 기능의 서브셋을 포함하는 MIME 본문 부분입니다.기능 포맷은 User Agent Profile [UAPROF]에 지정되어 있습니다.기능 엔티티가 있는 경우 Push Submission MIME multipart/관련 메시지의 세 번째 엔티티여야 하며 클라이언트 기능 쿼리 응답의 두 번째 엔티티여야 합니다.
