인터넷 엔지니어링 태스크 포스(IETF) M. Thomson
Request for Comments: 8030 Mozilla
분류: 표준 트랙 E. Damaggio
ISSN: 2070-1721 B. Raymor, Ed.
Microsoft
2016년 12월
HTTP 푸시를 사용한 범용 이벤트 전달
초록
이 문서는 사용자 에이전트에 실시간 이벤트를 전달하기 위한
간단한 프로토콜을 설명한다. 이 방식은 HTTP/2 서버 푸시를 사용한다.
이 메모의 상태
이 문서는 인터넷 표준 트랙 문서이다.
이 문서는 인터넷 엔지니어링 태스크 포스(IETF)의 산출물이다.
이는 IETF 커뮤니티의 합의를 나타낸다. 공개 검토를 받았으며
인터넷 엔지니어링 운영 그룹(IESG)에 의해 게시가 승인되었다.
인터넷 표준에 대한 자세한 정보는
RFC 7841의 Section 2에서 확인할 수 있다.
이 문서의 현재 상태, 정오표 및 피드백 제공 방법에 대한 정보는
http://www.rfc-editor.org/info/rfc8030에서
확인할 수 있다.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Thomson 외 표준 트랙 [1페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
목차
1. 소개 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. 관례와 용어 . . . . . . . . . . . . . . . . . . . . . . 4
2. 개요 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. HTTP 리소스 . . . . . . . . . . . . . . . . . . . . . 7
3. 푸시 서비스에 연결하기 . . . . . . . . . . . . . . . . . 8
4. 푸시 메시지 구독하기 . . . . . . . . . . . . . . . . . . . 8
4.1. 구독을 집합으로 모으기 . . . . . . . . . . . . . . . 9
5. 푸시 메시지 전달 요청하기 . . . . . . . . . . . . . . . 10
5.1. 푸시 메시지 수신 확인 요청하기 . . . . . . . . . . . 10
5.2. 푸시 메시지 유효 기간 . . . . . . . . . . . . . . . . 11
5.3. 푸시 메시지 긴급도 . . . . . . . . . . . . . . . . . 13
5.4. 푸시 메시지 교체하기 . . . . . . . . . . . . . . . . . 14
6. 구독에 대한 푸시 메시지 수신하기 . . . . . . . . . . . . 15
6.1. 구독 집합에 대한 푸시 메시지 수신하기 . . . . . . . 17
6.2. 푸시 메시지 확인 응답하기 . . . . . . . . . . . . . . 18
6.3. 푸시 메시지 수신 확인 받기 . . . . . . . . . . . . . 19
7. 운영상 고려 사항 . . . . . . . . . . . . . . . . . . . . 20
7.1. 부하 관리 . . . . . . . . . . . . . . . . . . . . . . 20
7.2. 푸시 메시지 만료 . . . . . . . . . . . . . . . . . . 20
7.3. 구독 만료 . . . . . . . . . . . . . . . . . . . . . . 21
7.3.1. 구독 집합 만료 . . . . . . . . . . . . . . . . . 21
7.4. 애플리케이션 신뢰성에 대한 영향 . . . . . . . . . . 22
7.5. 구독 집합과 동시 HTTP/2 스트림 . . . . . . . . . . . 22
8. 보안 고려 사항 . . . . . . . . . . . . . . . . . . . . . 22
8.1. 푸시 서비스 접근으로부터의 기밀성 . . . . . . . . . 23
8.2. 개인정보 보호 고려 사항 . . . . . . . . . . . . . . 23
8.3. 권한 부여 . . . . . . . . . . . . . . . . . . . . . . 24
8.4. 서비스 거부 고려 사항 . . . . . . . . . . . . . . . 25
8.5. 로깅 위험 . . . . . . . . . . . . . . . . . . . . . 25
9. IANA 고려 사항 . . . . . . . . . . . . . . . . . . . . . 26
9.1. 헤더 필드 등록 . . . . . . . . . . . . . . . . . . . 26
9.2. 링크 관계 URN . . . . . . . . . . . . . . . . . . . 26
9.3. 서비스 이름과 포트 번호 등록 . . . . . . . . . . . . 28
10. 참고 문헌 . . . . . . . . . . . . . . . . . . . . . . . . 28
10.1. 규범적 참고 문헌 . . . . . . . . . . . . . . . . . . 28
10.2. 참고 정보 문헌 . . . . . . . . . . . . . . . . . . . 30
감사의 말 . . . . . . . . . . . . . . . . . . . . . . . . . . 31
저자 주소 . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Thomson 외 표준 트랙 [2페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
1. 소개
모바일 및 임베디드 장치의 많은 애플리케이션은 수신 전화나
메시지와 같은 실시간 이벤트가 적시에 전달(또는 "푸시")될 수
있도록 네트워크 통신에 대한 지속적인 접근이 필요하다. 이러한
장치는 일반적으로 전력 보유량이 제한되어 있으므로, 애플리케이션
요구 사항을 충족하는 더 효율적인 방법을 찾는 것은 애플리케이션
생태계에 큰 이익을 준다.
전력 사용량에 크게 기여하는 요소 중 하나는 무선 장치이다. 무선
통신은 무선 장치의 에너지 예산 중 상당 부분을 소비한다.
여러 애플리케이션이 지속 연결이나 세션을 조정 없이 사용하면,
각각의 독립 세션이 자체 오버헤드를 발생시킬 수 있으므로 장치의
무선 장치가 불필요하게 사용될 수 있다. 특히 미들박스가 세션을
너무 일찍 타임아웃하지 않도록 보장하기 위해 사용되는 keep-alive
트래픽은 상당한 낭비를 초래할 수 있다. 이벤트는 비교적 드물기
때문에 장기적으로는 유지 관리 트래픽이 지배적인 경향이 있다.
모든 실시간 이벤트를 단일 세션으로 통합하면 네트워크 및 무선
리소스를 더 효율적으로 사용할 수 있다. 하나의 서비스가 모든
이벤트를 통합하고, 해당 이벤트가 도착하는 대로 애플리케이션에
배포한다. 여기에는 하나의 세션만 필요하므로 중복 오버헤드
비용을 피할 수 있다.
W3C Push API [API]는 웹 애플리케이션에서 통합 푸시 서비스를
사용할 수 있게 하는 API를 설명한다. 이 문서는 다음에 사용할 수
있는 프로토콜을 설명함으로써 그 작업을 확장한다.
o 사용자 에이전트로 푸시 메시지 전달을 요청하기,
o 새로운 푸시 메시지 전달 구독 만들기, 그리고
o 새로운 푸시 메시지를 모니터링하기.
표준화된 이벤트 전달 방법은 W3C Push API에 특히 중요하다.
여기서는 애플리케이션 서버가 여러 푸시 서비스를 사용해야 할 수
있다. 구독, 관리 및 모니터링 기능은 현재 독점 프로토콜에 의해
수행되고 있다. 이러한 프로토콜도 충분하지만 표준화가 제공하는
이점은 제공하지 않는다.
이 문서는 의도적으로 푸시 서비스를 발견하는 방법을 설명하지
않는다. 푸시 서비스 발견은 그것이 필요하다고 판명될 경우 향후
작업으로 남겨 둔다. 사용자 에이전트는 푸시 서비스용 URL로
구성되어 있을 것으로 예상된다.
Thomson 외 표준 트랙 [3페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
1.1. 관례와 용어
이 문서에서 핵심 단어 "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
"OPTIONAL"은 [RFC2119]에 설명된 대로 해석되어야 한다.
이 문서는 다음 용어를 정의한다.
application: 푸시 메시지의 발신자이자 최종 소비자. 많은
애플리케이션에는 사용자 에이전트에서 실행되는 구성 요소와
서버에서 실행되는 다른 구성 요소가 있다.
application server: 일반적으로 서버에서 실행되며 푸시 메시지
전달을 요청하는 애플리케이션의 구성 요소.
push message subscription: 사용자 에이전트와 푸시 서비스
사이에 설정되고 애플리케이션 서버와 공유되는 메시지 전달
컨텍스트. 모든 푸시 메시지는 푸시 메시지 구독과 연결된다.
push message subscription set: 사용자 에이전트와 푸시 서비스
사이에 설정되어 여러 푸시 메시지 구독을 하나의 집합으로
모으는 메시지 전달 컨텍스트.
push message: 애플리케이션 서버에서 푸시 서비스를 통해 사용자
에이전트로 전송되는 메시지.
push message receipt: 푸시 서비스에서 애플리케이션 서버로
전송되는 메시지 전달 확인.
push service: 사용자 에이전트에 푸시 메시지를 전달하는 서비스.
user agent: 푸시 메시지를 받는 장치 및 소프트웨어.
이 문서의 예시는 HTTP/1.1 메시지 형식 [RFC7230]을 사용한다.
많은 교환은 HTTP/1.1을 사용하여 완료할 수 있다.
o 푸시 메시지 구독하기(Section 4)
o 푸시 메시지 전달 요청하기(Section 5)
o 푸시 메시지 교체하기(Section 5.4)
o 푸시 메시지 확인 응답하기(Section 6.2)
Thomson 외 표준 트랙 [4페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
예시가 HTTP/2 서버 푸시에 의존할 때에는 [RFC7540]의 더 상세한
프레임 형식이 사용된다.
o 구독에 대한 푸시 메시지 수신하기(Section 6)
o 구독 집합에 대한 푸시 메시지 수신하기(Section 6.1)
o 푸시 메시지 수신 확인 받기(Section 6.3)
모든 예시는 등록된 포트(1001)가 아니라 기본 포트(443)를 통한
HTTPS를 사용한다. 푸시 서비스 배포는 사용자 에이전트가 서비스에
도달할 가능성을 극대화하기 위해 이 구성을 선호할 수 있다. 푸시
서비스는 표준화된 HTTPS 포트의 이점을 얻으면서도 도달 가능성을
희생하지 않기 위해 HTTP 대체 서비스를 사용하여 사용자 에이전트를
등록된 포트(1001)로 리디렉션할 수 있다(Section 3 참조). 이는
사용자 에이전트에서 푸시 서비스로 보내는 요청에 Alt-Used 헤더
필드 [RFC7838]가 포함되는 것으로만 예시에 나타난다.
이 프로토콜은 필수 시스템을 정의하지 않기 때문에 예시에는 푸시
메시지 암호화나 애플리케이션 서버 인증을 위한 구체적인 방법이
포함되지 않는다. Voluntary Application Server Identification
[VAPID] 및 Message Encryption for WebPush [ENCRYPT]의 예시는 W3C
Push API [API]가 그 요구 사항을 위해 채택한 접근 방식을 보여준다.
Thomson 외 표준 트랙 [5페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
2. 개요
푸시 서비스의 일반 모델에는 세 가지 기본 행위자가 포함된다:
사용자 에이전트, 푸시 서비스, 애플리케이션(서버).
+-------+ +--------------+ +-------------+
| UA | | Push Service | | Application |
+-------+ +--------------+ | Server |
| | +-------------+
| Subscribe | |
|--------------------->| |
| Monitor | |
|<====================>| |
| | |
| Distribute Push Resource |
|-------------------------------------------->|
| | |
: : :
| | Push Message |
| Push Message |<---------------------|
|<---------------------| |
| | |
Figure 1: WebPush 아키텍처
프로세스의 맨 처음에는 사용자 에이전트가 새 메시지 구독을
생성한 다음 이를 자신의 애플리케이션 서버에 배포한다. 이 구독은
행위자들 사이의 모든 향후 상호 작용의 기반이다. 구독은
애플리케이션 서버가 사용자 에이전트에 전달하기 위해 푸시
서비스로 메시지를 보내는 데 사용된다. 사용자 에이전트는 이
구독을 사용하여 푸시 서비스에서 들어오는 메시지를 모니터링한다.
권한 부여에 대해 더 많은 제어를 제공하기 위해, 메시지 구독은
서로 다른 기능을 가진 두 리소스로 모델링된다.
o 구독 리소스는 구독에서 메시지를 수신하고 구독을 삭제하는 데
사용된다. 이는 사용자 에이전트에 비공개이다.
o 푸시 리소스는 구독으로 메시지를 보내는 데 사용된다. 이는
공개적이며 사용자 에이전트가 자신의 애플리케이션 서버와
공유한다.
각 애플리케이션에 고유한 구독이 배포될 것으로 예상된다. 그러나
프로토콜에는 본질적인 카디널리티 제약이 없다. 동일한
Thomson 외 표준 트랙 [6페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
애플리케이션에 대해 여러 구독이 생성될 수도 있고, 여러
애플리케이션이 동일한 구독을 사용할 수도 있다. 다만 구독을
공유하면 보안 및 개인정보 보호 영향이 있다는 점에 유의하라.
구독에는 제한된 수명이 있다. 또한 푸시 서비스나 사용자 에이전트
어느 쪽이든 언제든지 종료할 수 있다. 사용자 에이전트와
애플리케이션 서버는 구독 상태의 변화를 관리할 준비가 되어 있어야
한다.
2.1. HTTP 리소스
이 프로토콜은 HTTP 리소스 [RFC7230] 및 링크 관계 [RFC5988]를
사용한다. 다음 리소스가 정의된다.
push service: 이 리소스는 푸시 메시지 구독을 생성하는 데
사용된다(Section 4). 푸시 서비스용 URL은 사용자 에이전트에
구성된다.
push message subscription: 이 리소스는 메시지 구독에 대한
읽기 및 삭제 접근을 제공한다. 사용자 에이전트는 푸시 메시지
구독을 사용하여 푸시 메시지(Section 6)를 수신한다. 모든 푸시
메시지 구독에는 정확히 하나의 푸시 리소스가 연결되어 있다.
push message subscription set: 이 리소스는 푸시 메시지
구독의 컬렉션에 대한 읽기 및 삭제 접근을 제공한다. 사용자
에이전트는 이 집합의 모든 푸시 메시지 구독에 대해 푸시
메시지(Section 6.1)를 수신한다. 타입
"urn:ietf:params:push:set"의 링크 관계는 푸시 메시지 구독
집합을 식별한다.
push: 애플리케이션 서버는 푸시 리소스를 사용하여 푸시 메시지의
전달(Section 5)을 요청한다. 타입 "urn:ietf:params:push"의
링크 관계는 푸시 리소스를 식별한다.
push message: 푸시 서비스는 전달이 수락된 푸시 메시지를
식별하기 위해 푸시 메시지 리소스를 생성한다(Section 5).
푸시 메시지 리소스는 사용자 에이전트가 푸시 메시지의 수신
확인(Section 6.2)을 위해 삭제하기도 한다.
receipt subscription: 애플리케이션 서버는 수신 확인 구독을
사용하여 푸시 메시지의 전달 확인(Section 5.1)을 받는다.
타입 "urn:ietf:params:push:receipt"의 링크 관계는 수신 확인
구독을 식별한다.
Thomson 외 표준 트랙 [7페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
3. 푸시 서비스에 연결하기
푸시 서비스는 [RFC7525]의 권장 사항을 따르는 Transport Layer Security
(TLS) [RFC2818] 위의 HTTP를 사용해야 한다(MUST). 푸시 서비스는
HTTPS와 동일한 기본 포트 번호(443/TCP)를 공유하지만, HTTP 대체
서비스 [RFC7838]를 사용하여 IANA가 할당한 TCP 시스템 포트(1001)를
광고할 수도 있다(MAY).
기본 포트(443)는 넓은 도달 가능성 특성을 제공하지만,
미들박스에서 구성된 다른 포트보다 유휴 타임아웃이 짧은 웹
브라우징 시나리오에 가장 자주 사용된다. WebPush 시나리오에서는
이것이 배터리 구동 장치에서 연결을 유지하기 위한 불필요한 무선
통신에 기여하게 된다.
대체 포트(1001)를 광고하면, 데이터 교환이 드물 것이라는 전제
아래 미들박스가 푸시 시나리오에 특화된 연결의 유휴 타임아웃을
최적화할 수 있다.
미들박스는 [RFC5382]의 REQ-5를 준수하는 것이 좋다(SHOULD). 여기에는
"'established connection idle-timeout'의 값은 2시간 4분보다
작아서는 안 된다(MUST NOT)"고 명시되어 있다.
4. 푸시 메시지 구독하기
사용자 에이전트는 새 구독을 생성하기 위해 구성된 푸시 서비스
리소스로 POST 요청을 보낸다.
POST /subscribe HTTP/1.1
Host: push.example.net
201 (Created) 응답은 푸시 구독이 생성되었음을 나타낸다. 요청에
대한 응답으로 생성된 푸시 메시지 구독 리소스의 URI는 Location
헤더 필드에 반환되어야 한다(MUST).
푸시 서비스는 푸시 메시지 구독에 대응하는 푸시 리소스의 URI를
타입 "urn:ietf:params:push"의 링크 관계로 제공해야 한다(MUST).
푸시 URI를 애플리케이션 서버에 배포하기 위해 애플리케이션별
방법이 사용된다. 이 URI가 권한 없는 수신자에게 공개되지 않도록
기밀성 보호 및 애플리케이션 서버 인증을 사용해야 한다(MUST)
(Section 8.3).
Thomson 외 표준 트랙 [8페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
HTTP/1.1 201 Created
Date: Thu, 11 Dec 2014 23:56:52 GMT
Link: </push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV>;
rel="urn:ietf:params:push"
Link: </subscription-set/4UXwi2Rd7jGS7gp5cuutF8ZldnEuvbOy>;
rel="urn:ietf:params:push:set"
Location: https://push.example.net/subscription/LBhhw0OohO-Wl4Oi971UG
4.1. 구독을 집합으로 모으기
여러 푸시 메시지 구독을 구독 집합으로 모으는 것은 푸시 서비스와
사용자 에이전트에 상당한 효율 향상을 의미할 수 있다. 푸시 서비스는
타입 "urn:ietf:params:push:set"의 링크 관계로 구독 집합 리소스의
URI를 제공할 수 있다(MAY).
푸시 메시지 구독 응답에서 구독 집합이 반환되면, 사용자 에이전트는
이후 새 푸시 메시지 구독을 생성하는 요청에서 이 구독 집합을 타입
"urn:ietf:params:push:set"의 링크 관계로 포함하는 것이 좋다
(SHOULD).
사용자 에이전트가 구독의 수명 동안 집계된 방식으로 푸시 메시지를
수신할 수 없는 경우, 구독 집합을 생략할 수 있다(MAY). 이는 사용자
에이전트가 다른 푸시 메시지 수신자를 대신하여 구독을 모니터링하는
경우 필요할 수 있다.
POST /subscribe HTTP/1.1
Host: push.example.net
Link: </subscription-set/4UXwi2Rd7jGS7gp5cuutF8ZldnEuvbOy>;
rel="urn:ietf:params:push:set"
푸시 서비스는 응답에서 동일한 구독 집합을 반환하는 것이 좋지만
(SHOULD), 사용자 에이전트가 제공한 것을 재사용할 수 없는 경우에는
새 구독 집합을 반환할 수 있다(MAY).
HTTP/1.1 201 Created
Date: Thu, 11 Dec 2014 23:56:52 GMT
Link: </push/YBJNBIMwwA_Ag8EtD47J4A>;
rel="urn:ietf:params:push"
Link: </subscription-set/4UXwi2Rd7jGS7gp5cuutF8ZldnEuvbOy>;
rel="urn:ietf:params:push:set"
Location: https://push.example.net/subscription/i-nQ3A9Zm4kgSWg8_ZijV
푸시 서비스는 유효하지 않은 구독 집합을 포함하는 요청에 대해
400 (Bad Request) 상태 코드를 반환해야 한다(MUST). 푸시 서비스는
구독 집합을 생략한 요청을 거부하기 위해 429 (Too Many Requests)
상태 코드 [RFC6585]를 반환할 수 있다(MAY).
Thomson 외 표준 트랙 [9페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
요청이 동일한 사용자 에이전트에서 비롯되었음을 푸시 서비스가
감지하는 방법은 구현에 따라 다르지만, TLS 연결, 소스 IP 주소 및
포트와 같은 주변 정보를 고려할 수 있다. 구현자는 일부 휴리스틱이
오탐을 만들 수 있으며, 따라서 요청이 잘못 거부되게 할 수 있음을
유의해야 한다.
5. 푸시 메시지 전달 요청하기
애플리케이션 서버는 사용자 에이전트가 애플리케이션 서버에 배포한
푸시 리소스로 HTTP POST 요청을 보내 푸시 메시지의 전달을 요청한다.
푸시 메시지의 콘텐츠는 요청 본문에 포함된다.
POST /push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
Host: push.example.net
TTL: 15
Content-Type: text/plain;charset=utf8
Content-Length: 36
iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB
201 (Created) 응답은 푸시 메시지가 수락되었음을 나타낸다. 요청에
대한 응답으로 생성된 푸시 메시지 리소스의 URI는 Location 헤더
필드에 반환되어야 한다(MUST). 이것은 메시지가 사용자 에이전트에
전달되었음을 나타내지 않는다.
HTTP/1.1 201 Created
Date: Thu, 11 Dec 2014 23:56:55 GMT
Location: https://push.example.net/message/qDIYHNcfAIPP_5ITvURr-d6BGt
5.1. 푸시 메시지 수신 확인 요청하기
애플리케이션 서버는 푸시 메시지가 전달되고 나서 사용자 에이전트에
의해 확인 응답되었을 때 푸시 서비스로부터 확인을 요청하기 위해
Prefer 헤더 필드 [RFC7240]에 "respond-async" 선호를 포함할 수 있다.
푸시 서비스는 전달 확인을 지원해야 한다(MUST).
POST /push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
Host: push.example.net
Prefer: respond-async
TTL: 15
Content-Type: text/plain;charset=utf8
Content-Length: 36
iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB
Thomson 외 표준 트랙 [10페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
푸시 서비스가 확인과 함께 전달할 메시지를 수락하면, 202 (Accepted)
응답을 반환해야 한다(MUST). 요청에 대한 응답으로 생성된 푸시
메시지 리소스의 URI는 Location 헤더 필드에 반환되어야 한다(MUST).
또한 푸시 서비스는 수신 확인 구독 리소스의 URI를 타입
"urn:ietf:params:push:receipt"의 링크 관계로 제공해야 한다(MUST).
HTTP/1.1 202 Accepted
Date: Thu, 11 Dec 2014 23:56:55 GMT
Link: </receipt-subscription/3ZtI4YVNBnUUZhuoChl6omUvG4ZM>;
rel="urn:ietf:params:push:receipt"
Location: https://push.example.net/message/qDIYHNcfAIPP_5ITvURr-d6BGt
동일한 출처 [RFC6454]에 대한 이후 수신 확인 요청에서, 애플리케이션
서버는 반환된 수신 확인 구독을 타입 "urn:ietf:params:push:receipt"의
링크 관계로 포함하는 것이 좋다(SHOULD). 이를 통해 푸시 서비스는
수신 확인을 집계할 수 있는 선택권을 갖는다. 푸시 서비스는 응답에서
동일한 수신 확인 구독을 반환하는 것이 좋지만(SHOULD), 애플리케이션
서버가 제공한 것을 재사용할 수 없는 경우에는 새 수신 확인 구독을
반환할 수 있다(MAY).
애플리케이션 서버가 수신 확인 구독의 수명 동안 집계된 방식으로
수신 확인을 받을 수 없는 경우, 수신 확인 구독을 생략할 수 있다
(MAY). 이는 애플리케이션 서버가 다른 푸시 메시지 발신자를 대신하여
수신 확인 구독을 모니터링하는 경우 필요할 수 있다.
푸시 서비스는 유효하지 않은 수신 확인 구독을 포함하는 요청에 대해
400 (Bad Request) 상태 코드를 반환해야 한다(MUST). 푸시 서비스가
유지하는 수신 확인 구독의 수를 제한하려는 경우, 수신 확인 구독을
생략한 수신 확인 요청을 거부하기 위해 429 (Too Many Requests)
상태 코드 [RFC6585]를 반환할 수 있다(MAY).
5.2. 푸시 메시지 유효 기간
푸시 서비스는 일정 기간 동안 푸시 메시지를 저장함으로써 푸시
메시지 전달의 신뢰성을 상당히 향상시킬 수 있다. 사용자 에이전트는
종종 간헐적으로만 연결되어 있으므로, 푸시 서비스의 단기 메시지
저장에서 이익을 얻는다.
전달 지연은 사용자 에이전트와의 통신을 일괄 처리하여 무선
리소스를 절약하는 데에도 사용될 수 있다.
일부 푸시 메시지는 특정 시간이 지나면 더 이상 유용하지 않다.
관련성을 잃은 후 메시지를 전달하는 것은 낭비이다. 예를 들어
푸시 메시지에 전화 알림이 포함된 경우, 발신자가 전화를 포기한 후
Thomson 외 표준 트랙 [11페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
메시지를 받는 것은 아무 가치가 없다. 사용자 에이전트의
애플리케이션은 쓸모없는 알림이 생성되지 않도록 메시지를 억제해야
한다.
애플리케이션 서버는 푸시 메시지 전달 요청에 TTL (Time-To-Live)
헤더 필드를 포함해야 한다(MUST). TTL 헤더 필드에는 푸시 서비스가
푸시 메시지를 얼마나 오래 보존할지를 제안하는 초 단위 값이
포함된다.
TTL 규칙은 시간을 초 단위로 나타내는 음수가 아닌 정수를 지정한다.
TTL 값을 파싱하고 이진 형식으로 변환하는 수신자는 음수가 아닌 정수
범위가 최소 31비트인 산술 타입을 사용하는 것이 좋다(SHOULD).
수신자가 표현할 수 있는 최대 정수보다 큰 TTL 값을 받거나, 이후
계산 중 오버플로가 발생하면, 그 값을 2147483648 (2^31)로 간주해야
한다(MUST).
TTL = 1*DIGIT
푸시 서비스는 TTL 헤더 필드를 생략한 요청에 대한 응답으로
400 (Bad Request) 상태 코드를 반환해야 한다(MUST).
푸시 서비스는 요청된 기간보다 더 짧은 기간 동안 푸시 메시지를
보존할 수 있다(MAY). 이는 실제 TTL이 담긴 TTL 헤더 필드를 응답에
반환함으로써 표시한다. 이 TTL 값은 애플리케이션 서버가 제공한
값보다 작거나 같아야 한다(MUST).
TTL 기간이 지나면, 푸시 서비스는 사용자 에이전트에 푸시 메시지를
전달하려고 시도해서는 안 된다(MUST NOT). 푸시 서비스는 처리 중의
시간 계산 오류를 고려하여 TTL 값을 조정할 수 있다. 예를 들어
서버 클러스터 내에서 푸시 메시지를 배포하면 클록 스큐나 전파
지연으로 인해 오류가 누적될 수 있다.
푸시 서비스는 애플리케이션 서버가 푸시 메시지를 푸시 서비스로
보내는 데 걸린 시간이나, 푸시 메시지를 사용자 에이전트로 보내는
동안 발생한 지연을 고려할 의무가 없다. 애플리케이션 서버는 TTL
헤더 필드 값을 선택할 때 전송 지연을 고려해야 한다.
TTL이 0인 푸시 메시지는 사용자 에이전트가 메시지를 받을 수 있는
경우 즉시 전달된다. 전달 후 푸시 서비스는 TTL이 0인 푸시 메시지를
즉시 제거할 수 있다. 이는 사용자 에이전트가 푸시 메시지 리소스에
HTTP DELETE를 수행하여 메시지 수신을 확인 응답하기 전에 발생할 수
있다. 따라서 애플리케이션 서버는 TTL이 0인 푸시 메시지에 대해
확인 응답 수신 확인을 받을 것이라고 의존할 수 없다.
Thomson 외 표준 트랙 [12페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
사용자 에이전트가 사용할 수 없는 경우, TTL이 0인 푸시 메시지는
만료되며 결코 전달되지 않는다.
5.3. 푸시 메시지 긴급도
배터리로 구동되는 장치의 경우, 장치가 오랜 시간 동안 휴면 상태를
유지하는 것이 종종 중요하다. 특히 무선 통신은 상당한 전력을
소비하며 장치가 동작할 수 있는 시간을 제한한다.
사소한 메시지를 수신하는 데 리소스를 소비하지 않도록 하려면,
애플리케이션 서버가 메시지의 긴급도를 전달할 수 있고 사용자
에이전트가 푸시 서버에게 특정 긴급도의 메시지만 전달하도록 요청할
수 있으면 도움이 된다.
애플리케이션 서버는 푸시 메시지 전달 요청에 Urgency 헤더 필드를
포함할 수 있다(MAY). 이 헤더 필드는 메시지 긴급도를 나타낸다.
푸시 서비스는 Urgency 헤더 필드를 사용자 에이전트로 전달해서는 안
된다(MUST NOT). Urgency 헤더 필드가 없는 푸시 메시지는 기본값이
"normal"이다.
사용자 에이전트는 자신이 수신하려는 푸시 메시지의 최저 긴급도를
나타내기 위해 푸시 메시지를 모니터링할 때 Urgency 헤더 필드를
포함할 수 있다(MAY). 푸시 서비스는 모니터링 요청에서 사용자
에이전트가 표시한 값보다 낮은 긴급도의 푸시 메시지를 전달해서는
안 된다(MUST NOT). 메시지 모니터링 시 Urgency 헤더 필드를 포함하지
않는 사용자 에이전트에는 어떤 긴급도의 푸시 메시지도 전달된다.
Urgency 헤더 필드의 문법은 다음과 같다.
Urgency = urgency-option
urgency-option = ("very-low" / "low" / "normal" / "high")
긴급도가 증가하는 순서는 다음과 같다.
+----------+-----------------------------+--------------------------+
| Urgency | 장치 상태 | 예시 애플리케이션 |
| | | 시나리오 |
+----------+-----------------------------+--------------------------+
| very-low | 전원 및 Wi-Fi에 연결됨 | 광고 |
| low | 전원 또는 Wi-Fi 중 하나 | 주제 업데이트 |
| normal | 전원도 Wi-Fi도 아님 | 채팅 또는 캘린더 메시지 |
| high | 배터리 부족 | 수신 전화 또는 |
| | | 시간 민감 알림 |
+----------+-----------------------------+--------------------------+
Table 1: 예시적 긴급도 값
Thomson 외 표준 트랙 [13페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
Urgency 헤더 필드에는 여러 값이 요청에 포함되어서는 안 된다
(MUST NOT). 그렇지 않으면 푸시 서비스는 400 (Bad Request) 상태
코드를 반환해야 한다(MUST).
5.4. 푸시 메시지 교체하기
푸시 서비스에 저장된 푸시 메시지는 새 콘텐츠로 교체될 수 있다.
푸시 메시지가 전송되는 동안 사용자 에이전트가 오프라인이면, 푸시
메시지를 업데이트함으로써 오래되었거나 중복된 메시지가 사용자
에이전트에 전송되는 상황을 피할 수 있다.
주제가 할당된 푸시 메시지만 교체될 수 있다. 주제가 있는 푸시
메시지는 동일한 주제를 가진 미해결 푸시 메시지를 대체한다.
푸시 메시지 주제는 Topic 헤더 필드에 실리는 문자열이다. 주제는
동일한 구독으로 전송되는 푸시 메시지를 상호 연관시키는 데
사용되며 다른 의미를 전달하지 않는다.
Topic 헤더 필드의 문법은 [RFC7230]에 정의된 "token" 규칙을 사용한다.
Topic = token
이 프로토콜에서 사용하기 위해, Topic 헤더 필드는 URL 및 파일
이름에 안전한 Base64 알파벳 [RFC4648]의 문자 중 32자 이하로
제한되어야 한다(MUST). 이러한 제약 조건을 충족하지 않는 Topic
헤더 필드가 포함된 요청을 수신한 푸시 서비스는 애플리케이션
서버에 400 (Bad Request) 상태 코드를 반환해야 한다(MUST).
푸시 메시지 교체 요청은 새 푸시 메시지 리소스를 생성하는 동시에
일치하는 주제를 가진 기존 메시지 리소스를 삭제한다. 삭제된 푸시
메시지를 전달하려는 시도가 있었다면, 푸시 메시지가 교체된 후에
확인 응답이 푸시 서비스에 도착할 수 있다. 그러한 삭제된 메시지에
대한 전달 수신 확인은 억제하는 것이 좋다(SHOULD).
교체 요청은 일치하는 주제의 이전 메시지와 연결된 저장된 TTL,
Urgency 및 모든 수신 확인 구독도 교체한다.
동일한 구독에 대한 미해결 메시지와 주제를 공유하지 않는 푸시
메시지는 정상적으로 저장되거나 전달된다.
Thomson 외 표준 트랙 [14페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
예를 들어 다음 메시지는 기존 메시지를 교체하게 할 수 있다.
POST /push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
Host: push.example.net
TTL: 600
Topic: upd
Content-Type: text/plain;charset=utf8
Content-Length: 36
ZuHSZPKa2b1jtOKLGpWrcrn8cNqt0iVQyroF
푸시 서비스가 "upd"라는 주제를 가진 미해결 푸시 메시지를 식별하면,
해당 메시지 리소스는 삭제된다. 201 (Created) 응답은 푸시 메시지
교체가 수락되었음을 나타낸다. 요청에 대한 응답으로 생성된 새 푸시
메시지 리소스의 URI는 Location 헤더 필드에 포함된다.
HTTP/1.1 201 Created
Date: Thu, 11 Dec 2014 23:57:02 GMT
Location: https://push.example.net/message/qDIYHNcfAIPP_5ITvURr-d6BGt
Topic 헤더 필드의 값은 사용자 에이전트로 전달되어서는 안 된다
(MUST NOT). 그 값은 암호화되지도 인증되지도 않는다.
6. 구독에 대한 푸시 메시지 수신하기
사용자 에이전트는 푸시 메시지 구독 리소스에 GET 요청을 수행하여
새로운 푸시 메시지의 전달을 요청한다. 푸시 서비스는 이 요청에
응답하지 않는다. 대신 애플리케이션 서버가 푸시 메시지를 전송할
때, HTTP/2 서버 푸시 [RFC7540]를 사용하여 푸시 메시지의 콘텐츠를
전송한다.
사용자 에이전트는 요청에 Urgency 헤더 필드를 포함할 수 있다(MAY).
푸시 서비스는 Table 1 (Illustrative Urgency Values)에 정의된 헤더
필드의 값보다 낮은 긴급도의 메시지를 전달해서는 안 된다(MUST NOT).
각 푸시 메시지는 PUSH_PROMISE로 전송된 합성 GET 요청에 대한
응답으로 푸시된다. 이 GET 요청은 애플리케이션 서버가 메시지 전달을
요청했을 때 푸시 서비스가 생성한 푸시 메시지 리소스로 이루어진다.
응답 헤더는 푸시 메시지 구독에 대응하는 푸시 리소스의 URI를 타입
"urn:ietf:params:push"의 링크 관계로 제공하는 것이 좋다(SHOULD).
응답 본문은 애플리케이션 서버가 푸시 리소스에 보낸 가장 최근
요청의 엔터티 본문이다.
Thomson 외 표준 트랙 [15페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
다음 예시 요청은 HTTP/2를 통해 이루어진다.
HEADERS [stream 7] +END_STREAM +END_HEADERS
:method = GET
:path = /subscription/LBhhw0OohO-Wl4Oi971UG
:authority = push.example.net
푸시 서비스는 요청이 계속 미해결 상태로 남아 있도록 허용한다.
애플리케이션 서버가 푸시 메시지를 보내면, 초기 요청과 연결된 서버
푸시가 생성된다. 서버 푸시에 대한 응답에는 푸시 메시지가 포함된다.
PUSH_PROMISE [stream 7; promised stream 4] +END_HEADERS
:method = GET
:path = /message/qDIYHNcfAIPP_5ITvURr-d6BGt
:authority = push.example.net
HEADERS [stream 4] +END_HEADERS
:status = 200
date = Thu, 11 Dec 2014 23:56:56 GMT
last-modified = Thu, 11 Dec 2014 23:56:55 GMT
cache-control = private
link = </push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV>;
rel="urn:ietf:params:push"
content-type = text/plain;charset=utf8
content-length = 36
DATA [stream 4] +END_STREAM
iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB
HEADERS [stream 7] +END_STREAM +END_HEADERS
:status = 200
사용자 에이전트는 "wait" 선호가 "0"으로 설정된 Prefer 헤더 필드
[RFC7240]를 포함하여 푸시 메시지 구독 리소스의 콘텐츠를 즉시
요청할 수도 있다. 이 요청에 대한 응답으로, 푸시 서비스는 아직
전달되지 않은 모든 푸시 메시지에 대해 서버 푸시를 생성해야 한다
(MUST).
관련 서버 푸시가 없는 204 (No Content) 상태 코드는 현재 사용
가능한 메시지가 없음을 나타낸다. 이는 푸시 메시지가 만료되었기
때문일 수 있다.
Thomson 외 표준 트랙 [16페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
6.1. 구독 집합에 대한 푸시 메시지 수신하기
구독에 대해 푸시 메시지를 수신하는 것과 구독 집합에 대해 수신하는
것 사이에는 사소한 차이가 있다. 구독 집합을 사용할 수 있으면,
사용자 에이전트는 개별 푸시 메시지 구독보다는 구독 집합을 사용하여
푸시 메시지를 모니터링하는 것이 좋다(SHOULD).
사용자 에이전트는 푸시 메시지 구독 집합 리소스에 GET 요청을
수행하여 푸시 메시지 구독 컬렉션에 대한 새로운 푸시 메시지 전달을
요청한다. 푸시 서비스는 이 요청에 응답하지 않는다. 대신
애플리케이션 서버가 푸시 메시지를 보낼 때 HTTP/2 서버 푸시
[RFC7540]를 사용하여 푸시 메시지의 콘텐츠를 전송한다.
사용자 에이전트는 요청에 Urgency 헤더 필드를 포함할 수 있다(MAY).
푸시 서비스는 Table 1 (Illustrative Urgency Values)에 정의된 헤더
필드의 값보다 낮은 긴급도의 메시지를 전달해서는 안 된다(MUST NOT).
각 푸시 메시지는 PUSH_PROMISE로 전송된 합성 GET 요청에 대한
응답으로 푸시된다. 이 GET 요청은 애플리케이션 서버가 메시지 전달을
요청했을 때 푸시 서비스가 생성한 푸시 메시지 리소스로 이루어진다.
합성 요청은 푸시 메시지 구독에 대응하는 푸시 리소스의 URI를 타입
"urn:ietf:params:push"의 링크 관계로 제공해야 한다(MUST). 이를
통해 사용자 에이전트는 메시지의 출처를 구분할 수 있다. 응답
본문은 애플리케이션 서버가 푸시 리소스에 보낸 가장 최근 요청의
엔터티 본문이다.
다음 예시 요청은 HTTP/2를 통해 이루어진다.
HEADERS [stream 7] +END_STREAM +END_HEADERS
:method = GET
:path = /subscription-set/4UXwi2Rd7jGS7gp5cuutF8ZldnEuvbOy
:authority = push.example.net
푸시 서비스는 요청이 계속 미해결 상태로 남아 있도록 허용한다.
애플리케이션 서버가 푸시 메시지를 보내면, 초기 요청과 연결된 서버
푸시가 생성된다. 서버 푸시의 응답에는 푸시 메시지가 포함된다.
PUSH_PROMISE [stream 7; promised stream 4] +END_HEADERS
:method = GET
:path = /message/qDIYHNcfAIPP_5ITvURr-d6BGt
:authority = push.example.net
Thomson 외 표준 트랙 [17페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
HEADERS [stream 4] +END_HEADERS
:status = 200
date = Thu, 11 Dec 2014 23:56:56 GMT
last-modified = Thu, 11 Dec 2014 23:56:55 GMT
link = </push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV>;
rel="urn:ietf:params:push"
cache-control = private
content-type = text/plain;charset=utf8
content-length = 36
DATA [stream 4] +END_STREAM
iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB
HEADERS [stream 7] +END_STREAM +END_HEADERS
:status = 200
사용자 에이전트는 "wait" 선호가 "0"으로 설정된 Prefer 헤더 필드
[RFC7240]를 포함하여 푸시 메시지 구독 집합 리소스의 콘텐츠를
즉시 요청할 수 있다. 이 요청에 대한 응답으로, 푸시 서비스는 아직
전달되지 않은 모든 푸시 메시지에 대해 서버 푸시를 생성해야 한다
(MUST).
관련 서버 푸시가 없는 204 (No Content) 상태 코드는 현재 사용
가능한 메시지가 없음을 나타낸다. 이는 푸시 메시지가 만료되었기
때문일 수 있다.
6.2. 푸시 메시지 확인 응답하기
푸시 메시지가 사용자 에이전트에 최소 한 번 제대로 전달되도록
보장하기 위해, 사용자 에이전트는 푸시 메시지 리소스에 HTTP
DELETE를 수행하여 메시지 수신을 확인 응답해야 한다(MUST).
DELETE /message/qDIYHNcfAIPP_5ITvURr-d6BGt HTTP/1.1
Host: push.example.net
푸시 서비스가 확인 응답을 받고 애플리케이션이 전달 수신 확인을
요청한 경우, 푸시 서비스는 수신 확인 구독을 모니터링하는
애플리케이션 서버에 204 (No Content) 응답을 반환해야 한다(MUST).
푸시 서비스가 합리적인 시간 내에 확인 응답을 받지 못하면, 해당
메시지는 아직 전달되지 않은 것으로 간주된다. 푸시 서비스는 광고된
만료 시점까지 메시지 전달을 계속 재시도하는 것이 좋다(SHOULD).
푸시 서비스는 응답하지 않는 사용자 에이전트 또는 운영상 제약과
같은 시나리오 때문에 광고된 만료 시점 전에 메시지 전달 재시도를
중단할 수 있다(MAY). 애플리케이션이
Thomson 외 표준 트랙 [18페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
전달 수신 확인을 요청한 경우, 푸시 서비스는 수신 확인 구독을
모니터링하는 애플리케이션 서버에 410 (Gone) 응답을 반환해야 한다
(MUST).
6.3. 푸시 메시지 수신 확인 받기
애플리케이션 서버는 수신 확인 구독 리소스에 HTTP GET 요청을
수행하여 푸시 서비스로부터 수신 확인 전달을 요청한다. 푸시
서비스는 이 요청에 응답하지 않는다. 대신 사용자 에이전트가 메시지
확인 응답(Section 6.2)을 할 때 HTTP/2 서버 푸시 [RFC7540]를
사용하여 푸시 수신 확인을 보낸다.
각 수신 확인은 PUSH_PROMISE로 전송된 합성 GET 요청에 대한 응답으로
푸시된다. 이 GET 요청은 애플리케이션 서버가 메시지 전달을 요청했을
때 푸시 서비스가 생성한 것과 동일한 푸시 메시지 리소스로 이루어진다.
응답은 메시지 전달의 결과를 나타내는 상태 코드를 포함하며 데이터를
담지 않는다.
다음 예시 요청은 HTTP/2를 통해 이루어진다.
HEADERS [stream 13] +END_STREAM +END_HEADERS
:method = GET
:path = /receipt-subscription/3ZtI4YVNBnUUZhuoChl6omUvG4ZM
:authority = push.example.net
푸시 서비스는 요청이 계속 미해결 상태로 남아 있도록 허용한다. 사용자
에이전트가 메시지에 확인 응답하면, 푸시 서비스는 애플리케이션
서버로 전달 수신 확인을 푸시한다. 204 (No Content) 상태 코드는
메시지가 전달되고 확인 응답되었음을 확인한다.
PUSH_PROMISE [stream 13; promised stream 82] +END_HEADERS
:method = GET
:path = /message/qDIYHNcfAIPP_5ITvURr-d6BGt
:authority = push.example.net
HEADERS [stream 82] +END_STREAM
+END_HEADERS
:status = 204
date = Thu, 11 Dec 2014 23:56:56 GMT
사용자 에이전트가 푸시 메시지 수신을 확인 응답하지 못하고 푸시
서비스가 광고된 만료 시점 전에 메시지 전달 재시도를 중단하면,
푸시 서비스는 410 (Gone) 상태 코드가 있는 실패 응답을 푸시해야
한다(MUST).
Thomson 외 표준 트랙 [19페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
7. 운영상 고려 사항
7.1. 부하 관리
푸시 서비스는 매우 많은 수의 열린 TCP 연결을 유지해야 할 가능성이
높다. 이러한 연결을 효과적으로 관리하려면 서버 인스턴스 사이에서
연결을 이동할 수 있는 능력에 의존할 수 있다.
사용자 에이전트는 307 (Temporary Redirect) 상태 코드 [RFC7231]를
지원해야 한다(MUST). 이 코드는 새 구독이 요청되는 시점에 푸시
서비스가 부하를 재분배하는 데 사용할 수 있다.
부하를 재분배하려는 서버는 HTTP 대체 서비스 [RFC7838]를 사용하여
그렇게 할 수 있다. HTTP 대체 서비스는 다양한 리소스에 대해 동일한
URI를 유지하면서 부하를 재분배할 수 있게 한다. 사용자 에이전트는
대체 연결을 설정한 후 GOAWAY 프레임을 사용하여 원활한 전환을
보장할 수 있다.
7.2. 푸시 메시지 만료
TTL 헤더 필드에 기반한 푸시 메시지 저장은 푸시 서비스에 상당한
저장 공간을 필요로 할 수 있다. 푸시 서비스는 메시지를 무기한
저장할 의무가 없다. 푸시 서비스는 TTL 헤더 필드(Section 5.2)를
사용하여 메시지를 얼마나 오래 보존하려는지 애플리케이션 서버에
나타낼 수 있다.
푸시 메시지를 능동적으로 모니터링하지 않는 사용자 에이전트는 그
기간 동안 만료되는 메시지를 수신하지 못한다.
저장되어 있고 사용자 에이전트에 아직 전달되지 않은 푸시 메시지는
사용자 에이전트가 모니터링을 재개할 때 전달된다. 저장된 푸시
메시지는 애플리케이션 서버가 전달을 요청한 시점을 나타내는
Last-Modified 헤더 필드([RFC7232]의 Section 2.2)를 포함하는 것이
좋다(SHOULD).
만료된 메시지만 있는 푸시 메시지 구독 리소스에 대한 GET 요청은
푸시 메시지가 전혀 전송되지 않은 것처럼 응답된다.
푸시 서비스는 과부하를 피하기 위해 저장된 푸시 메시지의 크기와
수를 제한해야 할 수 있다. 메시지의 크기를 제한하기 위해 푸시
서비스는 너무 큰 엔터티 본문을 포함하는 요청에 대해 413 (Payload
Too Large) 상태 코드 [RFC7231]를 반환할 수 있다(MAY). 푸시 서비스는
크기가 4096바이트 이하인 엔터티 본문에 대한 응답으로 413 상태
코드를 반환해서는 안 된다(MUST NOT).
Thomson 외 표준 트랙 [20페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
저장된 푸시 메시지의 수를 제한하기 위해, 푸시 서비스는 애플리케이션
서버가 푸시 메시지 전달 요청에서 제안한 것보다 더 짧은
Time-To-Live로 응답할 수 있다(MAY)(Section 5.2). 메시지가 일단
수락되면, 푸시 서비스는 나중에 광고된 Time-To-Live 이전에 메시지를
만료시킬 수 있다(MAY). 애플리케이션 서버가 전달 수신 확인을 요청한
경우, 푸시 서비스는 실패 응답(Section 6.2)을 반환해야 한다(MUST).
7.3. 구독 만료
어떤 경우에는 구독을 갱신할 수 있도록 구독을 종료해야 할 수 있다.
이는 푸시 메시지 구독과 수신 확인 구독 모두에 적용된다.
푸시 서비스는 언제든지 구독을 만료시킬 수 있다(MAY). 사용자
에이전트로부터 만료된 푸시 메시지 구독 리소스(Section 6)에 대한
미해결 요청이 있거나, 애플리케이션 서버로부터 만료된 수신 확인
구독 리소스(Section 6.3)에 대한 미해결 요청이 있는 경우, 이는
404 (Not Found) 상태 코드를 반환하여 신호되어야 한다(MUST).
애플리케이션 서버가 만료된 푸시 메시지 구독으로 푸시 메시지를
보내려고 시도하는 경우, 푸시 서비스는 404 (Not Found) 상태 코드를
반환해야 한다(MUST).
사용자 에이전트는 해당 URI로 DELETE 요청을 보내 자신의 푸시
메시지 구독을 제거할 수 있다. 애플리케이션 서버는 해당 URI로
DELETE 요청을 보내 자신의 수신 확인 구독을 제거할 수 있다.
7.3.1. 구독 집합 만료
푸시 서비스는 언제든지 구독 집합을 만료시킬 수 있으며(MAY), 그
집합의 모든 푸시 메시지 구독도 만료시켜야 한다(MUST). 사용자
에이전트가 푸시 구독 집합(Section 6.1)에 대한 미해결 요청을 가지고
있는 경우, 이는 404 (Not Found) 상태 코드를 반환하여 신호되어야
한다(MUST).
사용자 에이전트는 구독 집합 URI로 DELETE 요청을 보내 구독 집합이
제거되도록 요청할 수 있다. 이는 집합의 모든 푸시 메시지 구독도
제거해야 한다(MUST).
구독 집합의 구성원인 특정 푸시 메시지 구독이 만료되거나 제거되면,
그 구독은 자신의 구독 집합에서도 제거되어야 한다(MUST).
Thomson 외 표준 트랙 [21페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
7.4. 애플리케이션 신뢰성에 대한 영향
간헐적인 네트워크 연결이나 장치의 애플리케이션 실패 상황에서
신뢰성 있는 전달을 지원하지 않는 푸시 서비스는 장치가
애플리케이션 서버에 직접 수신을 확인 응답하도록 강제하며, 이로
인해 개별 애플리케이션 서버에 대해 (보통 보안) 연결을 설정하고
유지하기 위한 추가 전력 소모가 발생한다.
푸시 메시지에 애플리케이션 상태에 중요한 정보가 포함되어 있으면
푸시 메시지 신뢰성이 중요할 수 있다. 특히 통신 용량이 제한된
장치에서는 상태를 복구하는 데 비용이 많이 들 수 있다. 푸시
메시지가 올바르게 수신되었음을 알면 재전송, 폴링 및 상태 재동기화를
피할 수 있다.
푸시 메시지 전달 수신 확인이 제공되면, 애플리케이션 개발자가 푸시
서비스가 중요한 메시지를 전달하지 못할 경우에 대비하여 대체 메시지
전달 메커니즘을 만들고 싶은 유혹을 받지 않게 된다. 이러한 결점을
보완하기 위해 폴링 메커니즘이나 백업 메시징 채널을 설정하면 푸시
서비스가 제공하는 이점의 거의 전부가 무효화된다.
그러나 일시적인 메시지(예: 수신 전화)나 빠르게 대체되는 메시지
(예: 현재 읽지 않은 이메일 수)에는 신뢰성이 필요하지 않을 수 있다.
7.5. 구독 집합과 동시 HTTP/2 스트림
푸시 서비스가 사용자 에이전트에게 푸시 메시지 구독 집합을 사용하도록
요구하는 경우, HTTP/2 SETTINGS 프레임 [RFC7540] 내의
SETTINGS_MAX_CONCURRENT_STREAMS 매개변수를 통해 동시에 활성화되는
스트림 수를 제한할 수 있다(MAY). 사용자 에이전트는 푸시 메시지
구독을 관리하기 위한 하나의 동시 스트림과 푸시 서비스가 반환한 각
구독 집합에 대한 하나의 동시 스트림으로 제한될 수 있다(MAY). 이는
사용자 에이전트가 푸시 서비스에 대한 구독 요청을 직렬화하도록
강제할 수 있다.
8. 보안 고려 사항
이 프로토콜은 [RFC7525]의 권장 사항을 따르는 HTTP over TLS [RFC2818]를
사용해야 한다(MUST). 여기에는 사용자 에이전트와 푸시 서비스 사이의
모든 통신 및 애플리케이션 서버와 푸시 서비스 사이의 통신이
포함된다. 따라서 모든 URI는 "https" 스킴을 사용한다. 이는 외부
당사자로부터 구독과 푸시 메시지에 대한 기밀성 및 무결성 보호를
제공한다.
Thomson 외 표준 트랙 [22페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
8.1. 푸시 서비스 접근으로부터의 기밀성
TLS가 제공하는 보호는 푸시 서비스로부터 콘텐츠를 보호하지 않는다.
추가 보호 장치가 없으면 푸시 서비스는 메시지 콘텐츠를 검사하고
수정할 수 있다.
이 프로토콜을 사용하는 애플리케이션은 종단 간 기밀성, 무결성 및
데이터 출처 인증을 제공하는 메커니즘을 사용해야 한다(MUST). 푸시
메시지를 보내는 애플리케이션 서버와 이를 받는 사용자 에이전트의
애플리케이션은 흔히 동일한 애플리케이션의 서로 다른 인스턴스일
뿐이므로, 적절한 보안 컨텍스트를 설정하기 위한 표준화된 프로토콜은
필요하지 않다. 사용자 에이전트에서 자신의 애플리케이션 서버로 구독
정보를 배포하는 것도 키 합의에 편리한 매개체를 제공한다.
이 요구 사항을 위해, W3C Push API [API]는 푸시 서비스로부터
메시지 콘텐츠를 보호하기 위해 Message Encryption for WebPush
[ENCRYPT]를 채택했다. 다른 시나리오는 유사한 정책으로 처리할 수
있다.
Topic 헤더 필드는 동일한 주제에 대한 푸시 메시지를 더 세밀하게
상호 연관시킬 수 있는 정보를 노출한다. 이는 푸시 서비스가 푸시
메시지의 트래픽 분석을 돕는 데 사용될 수 있다.
8.2. 개인정보 보호 고려 사항
푸시 메시지 기밀성이 누가 언제 통신하는지에 대한 신원이 보호됨을
보장하지는 않는다. 그러나 노출되는 정보의 양은 제한할 수 있다.
푸시 리소스에 제공되는 URI는 특정 사용자 에이전트의 통신을 상호
연관시킬 근거를 제공해서는 안 된다(MUST NOT). 두 푸시 리소스 URI를
그 내용만으로 상호 연관시키는 것이 가능해서는 안 된다(MUST NOT).
이를 통해 사용자 에이전트는 서로 다른 애플리케이션 간 또는 시간에
따른 상관관계를 제어할 수 있다. 물론 이것이 사용자 에이전트가
노출할 수 있는 다른 정보를 사용한 상관관계를 막지는 않는다.
마찬가지로, 푸시 서비스가 푸시 메시지를 식별하기 위해 제공하는
URI는 구독 간 상관관계를 가능하게 하는 정보를 제공해서는 안 된다
(MUST NOT). 동일한 구독에 대한 푸시 메시지 URI는 해당 구독 또는 그
구독의 다른 푸시 메시지와 상호 연관될 수 있는 정보를 포함할 수
있다(MAY).
사용자 및 장치 정보는 푸시 또는 푸시 메시지 URI를 통해 노출되어서는
안 된다(MUST NOT).
Thomson 외 표준 트랙 [23페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
또한 동일한 사용자 에이전트가 설정한 푸시 URI 또는 동일한 구독에
대한 푸시 메시지 URI는 이를 사용자 에이전트와 상호 연관시킬 수
있는 어떤 정보도 포함해서는 안 된다(MUST NOT).
Note: 결과 익명성 집합([RFC6973], Section 6.1.1)이 충분히 크다면
이것이 완벽할 필요는 없다. 푸시 URI는 필연적으로 푸시 서비스나
단일 서버 인스턴스를 식별한다. 또한 트래픽 분석을 사용하여
구독을 상호 연관시키는 것도 가능할 수 있다.
사용자 에이전트는 언제든지 새 식별자로 새 구독을 생성할 수 있어야
한다(MUST).
8.3. 권한 부여
이 프로토콜은 푸시 서비스가 사용자 에이전트가 구독을 생성할 수
있는지, 또는 푸시 메시지가 사용자 에이전트에 전달될 수 있는지를
어떻게 설정하는지 정의하지 않는다. 푸시 서비스는 사용 가능한
HTTP 호환 권한 부여 방법 중 어느 것이든 기반으로 요청을 권한
부여할 수 있으며(MAY), 여기에는 보안 수준이 다양한 여러 옵션
(실험적 옵션 포함)이 있다. 권한 부여 프로세스와 관련 자격 증명은
푸시 서비스의 URI와 함께 사용자 에이전트에 구성될 것으로 예상된다.
권한 부여는 푸시 메시지 구독, 푸시 및 수신 확인 구독 리소스에 대한
capability URL을 사용하여 관리된다([CAP-URI]). capability URL은 URL을
알고 있다는 사실만으로 리소스에 대한 접근을 부여한다.
capability URL은 그 "easy onward sharing" 및 "easy client API"
속성 때문에 사용된다. 이러한 속성은 푸시 서비스와 애플리케이션
서버 사이에 사전 조율된 관계나 추가 프로토콜에 의존하지 않을 수
있게 한다.
capability URL은 bearer token처럼 작동한다. 푸시 메시지 구독 URI를
알고 있으면 푸시 메시지를 수신하거나 구독을 삭제할 권한이 있음을
의미한다. 푸시 URI를 알고 있으면 푸시 메시지를 보낼 권한이 있음을
의미한다. 푸시 메시지 URI를 알고 있으면 해당 특정 메시지를 읽고
확인 응답할 수 있다. 수신 확인 구독 URI를 알고 있으면 푸시 수신
확인을 받을 권한이 있음을 의미한다.
경로 구성 요소에 대량의 무작위 엔트로피(최소 120비트)를 인코딩하면
유효한 capability URL을 성공적으로 추측하기 어렵게 된다.
Thomson 외 표준 트랙 [24페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
8.4. 서비스 거부 고려 사항
사용자 에이전트는 푸시 URI의 배포를 권한 있는 애플리케이션 서버로
제한함으로써 유효한 푸시 메시지가 어디에서 비롯될 수 있는지 제어할
수 있다. 푸시 URI를 추측하기 어렵게 보장하면, 푸시 URI를 받은
애플리케이션 서버만 이를 사용할 수 있도록 보장된다.
사용자 에이전트가 성공적으로 인증하지 못한 푸시 메시지는 전달되지
않지만, 이는 서비스 거부 위험을 나타낼 수 있다. 비교적 적은 양의
푸시 메시지만으로도 배터리 구동 장치의 전력 보유량을 소진시킬 수
있다.
이 경우를 처리하기 위해, W3C Push API [API]는 사용자 에이전트가
구독을 특정 애플리케이션 서버로 제한할 수 있게 하는 Voluntary
Application Server Identification [VAPID]를 채택했다. 그러면 푸시
서비스는 사용자 에이전트에 연락하지 않고 원치 않는 메시지를
식별하고 거부할 수 있다.
유효한 푸시 URI를 가진 악성 애플리케이션은 푸시 서비스의 더 큰
리소스를 사용하여 사용자 에이전트에 서비스 거부 공격을 가할 수
있다. 푸시 서비스는 개별 사용자 에이전트에 푸시 메시지가 전송되는
속도를 제한하는 것이 좋다(SHOULD).
애플리케이션 서버가 푸시 리소스에 대한 푸시 메시지 전달의 속도
제한을 초과한 경우, 푸시 서비스는 429 (Too Many Requests) 상태
코드 [RFC6585]를 반환할 수 있다(MAY). 또한 푸시 서비스는 애플리케이션
서버가 푸시 리소스에 또 다른 요청을 하기 전에 얼마나 기다릴 것을
요청받는지 나타내기 위해 Retry-After 헤더 [RFC7231]를 포함하는 것이
좋다(SHOULD).
푸시 서비스 또는 사용자 에이전트는 너무 많은 푸시 메시지를 받는
구독(Section 7.3)을 종료할 수도 있다(MAY).
푸시 서비스도 사용자 에이전트에 서비스를 거부할 수 있다. 의도적인
메시지 전달 실패는 일시적인 네트워크 오류, 사용자 에이전트
가용성의 중단 또는 실제 서비스 장애로 인해 발생할 수 있는 결함과
구분하기 어렵다.
8.5. 로깅 위험
서버 요청 로그는 구독 관련 URI 또는 동일한 사용자 에이전트에 대한
구독 관련 URI 사이의 관계를 드러낼 수 있다. 로그 보존에 대한 제한
및 강력한 접근 제어 메커니즘은 URI가 권한 없는 엔터티에 노출되지
않도록 보장할 수 있다.
Thomson 외 표준 트랙 [25페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
9. IANA 고려 사항
이 프로토콜은 Section 9.1에서 새로운 HTTP 헤더 필드를 정의한다.
새로운 링크 관계 타입은 Section 9.2에 정의된 URN을 사용하여
식별된다. 포트 등록은 Section 9.3에 정의되어 있다.
9.1. 헤더 필드 등록
HTTP 헤더 필드는 <https://www.iana.org/assignments/message-
headers/>에서 유지되는 "Message Headers" 레지스트리에 등록된다.
이 문서는 다음 HTTP 헤더 필드를 정의하며, 다음 항목이
"Permanent Message Header Field Names" 레지스트리([RFC3864])에
추가되었다.
+-------------------+----------+----------+--------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+--------------+
| TTL | http | standard | Section 5.2 |
| Urgency | http | standard | Section 5.3 |
| Topic | http | standard | Section 5.4 |
+-------------------+----------+----------+--------------+
변경 관리자는 "IETF (iesg@ietf.org) - Internet Engineering Task
Force"이다.
9.2. 링크 관계 URN
이 문서는 링크 관계 타입을 식별하는 데 사용할 URN을 등록한다.
이들은 [RFC3553]의 Section 4 절차에 따라 새로운 "Web Push
Identifiers" 레지스트리에 추가되었으며, 대응하는 "push" 하위
네임스페이스는 "IETF URN Sub-namespace for Registered Protocol
Parameter Identifiers" 레지스트리에 입력되었다.
"Web Push Identifiers" 레지스트리는 IETF Review 정책 [RFC5226]에
따라 운영된다.
레지스트리 이름: Web Push Identifiers
URN 접두사: urn:ietf:params:push
명세: RFC 8030 (이 문서)
저장소: http://www.iana.org/assignments/webpush-parameters/
Thomson 외 표준 트랙 [26페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
색인 값: 이 레지스트리의 값은 "urn:ietf:params:push" 접두사로
시작하는 URN 또는 URN 접두사이다. 각각은 독립적으로 등록된다.
"Web Push Identifiers" 레지스트리의 등록에는 다음 정보가 포함된다.
URN: 완전한 URN 또는 URN 접두사.
설명: 요약 설명.
연락처: 등록을 수행하는 사람 또는 그룹의 이메일.
색인 값: [RFC3553]에 설명된 대로.
참조: URN 또는 URN 접두사의 의미를 설명하는 명세에 대한 참조.
등록된 URN 접두사에는 URN이 구성되는 방법에 대한 설명이
포함된다. 이는 특정 URN에는 적용되지 않는다.
이러한 값은 "Web Push Identifiers" 레지스트리의 초기 콘텐츠로
입력된다.
URN: urn:ietf:params:push
설명: 이 링크 관계 타입은 푸시 메시지를 보내기 위한 리소스를
식별하는 데 사용된다.
연락처: IETF의 WEBPUSH WG (webpush@ietf.org)
참조: RFC 8030 (이 문서)
URN: urn:ietf:params:push:set
설명: 이 링크 관계 타입은 푸시 메시지 구독의 컬렉션을 식별하는
데 사용된다.
연락처: IETF의 WEBPUSH WG (webpush@ietf.org)
참조: RFC 8030 (이 문서)
URN: urn:ietf:params:push:receipt
설명: 이 링크 관계 타입은 푸시 메시지에 대한 전달 확인을 받기
위한 리소스를 식별하는 데 사용된다.
연락처: IETF의 WEBPUSH WG (webpush@ietf.org)
Thomson 외 표준 트랙 [27페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
참조: RFC 8030 (이 문서)
9.3. 서비스 이름과 포트 번호 등록
서비스 이름과 포트 번호는 <https://www.iana.org/assignments/service-names-port-numbers/>에서
유지되는 "Service Name and Transport Protocol Port Number Registry"에
등록된다.
[RFC6335]에 따라, IANA는 시스템 포트 번호 1001과 서비스 이름
"webpush"를 할당했다.
서비스 이름:
webpush
포트 번호:
1001
전송 프로토콜:
tcp
설명:
HTTP Web Push
피할당자:
IESG (iesg@ietf.org)
연락처:
IETF 의장 (chair@ietf.org)
참조:
RFC 8030 (이 문서)
10. 참고 문헌
10.1. 규범적 참고 문헌
[CAP-URI] Tennison, J., "Good Practices for Capability URLs", W3C
First Public Working Draft capability-urls, 2014년 2월,
<http://www.w3.org/TR/capability-urls/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, 1997년 3월,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, 2000년 5월,
<http://www.rfc-editor.org/info/rfc2818>.
Thomson 외 표준 트랙 [28페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, 2003년
6월, <http://www.rfc-editor.org/info/rfc3553>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
DOI 10.17487/RFC3864, 2004년 9월,
<http://www.rfc-editor.org/info/rfc3864>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, 2006년 10월,
<http://www.rfc-editor.org/info/rfc4648>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, 2008년 5월,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, DOI 10.17487/RFC5382, 2008년 10월,
<http://www.rfc-editor.org/info/rfc5382>.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988,
DOI 10.17487/RFC5988, 2010년 10월,
<http://www.rfc-editor.org/info/rfc5988>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, 2011년 8월,
<http://www.rfc-editor.org/info/rfc6335>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, 2011년 12월,
<http://www.rfc-editor.org/info/rfc6454>.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
Codes", RFC 6585, DOI 10.17487/RFC6585, 2012년 4월,
<http://www.rfc-editor.org/info/rfc6585>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, 2014년 6월,
<http://www.rfc-editor.org/info/rfc7230>.
Thomson 외 표준 트랙 [29페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, 2014년 6월,
<http://www.rfc-editor.org/info/rfc7231>.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
DOI 10.17487/RFC7232, 2014년 6월,
<http://www.rfc-editor.org/info/rfc7232>.
[RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240,
DOI 10.17487/RFC7240, 2014년 6월,
<http://www.rfc-editor.org/info/rfc7240>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, 2015년
5월, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, 2015년 5월,
<http://www.rfc-editor.org/info/rfc7540>.
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
2016년 4월, <http://www.rfc-editor.org/info/rfc7838>.
10.2. 참고 정보 문헌
[API] Beverloo, P., Thomson, M., van Ouwerkerk, M., Sullivan,
B., and E. Fullea, "Push API", W3C Editor's Draft push-
api, 2016년 11월, <https://w3c.github.io/push-api/>.
[ENCRYPT] Thomson, M., "Message Encryption for Web Push", 진행 중인
작업, draft-ietf-webpush-encryption-06, 2016년 10월.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, 2013년 7월,
<http://www.rfc-editor.org/info/rfc6973>.
[VAPID] Thomson, M. and P. Beverloo, "Voluntary Application Server
Identification for Web Push", 진행 중인 작업,
draft-ietf-webpush-vapid-01, 2016년 6월.
Thomson 외 표준 트랙 [30페이지]
RFC 8030 HTTP 웹 푸시 2016년 12월
감사의 말
Ben Bangert, Peter Beverloo, Kit Cambridge, JR Conlin, Lucas Jenss,
Matthew Kaufman, Costin Manolache, Mark Nottingham, Idel Pivnitskiy,
Robert Sparks, Darshak Thakore 및 다른 많은 이들이 이 문서에 중요한
기술적 의견을 제공했다.
저자 주소
Martin Thomson
Mozilla
331 E Evelyn Street
Mountain View, CA 94041
United States of America
Email: martin.thomson@gmail.com
Elio Damaggio
Microsoft
One Microsoft Way
Redmond, WA 98052
United States of America
Email: elioda@microsoft.com
Brian Raymor (editor)
Microsoft
One Microsoft Way
Redmond, WA 98052
United States of America
Email: brian.raymor@microsoft.com
Thomson 외 표준 트랙 [31페이지]