> For the complete documentation index, see [llms.txt](https://hochan049.gitbook.io/cs-interview/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hochan049.gitbook.io/cs-interview/web/rfc-7320/8.-iana-considerations.md).
# 8. IANA Considerations
#### 8.1 Header Field Registrations
HTTP 헤더 필드는 <[http://www.iana.org/assignments/message-headers/>에서](http://www.iana.org/assignments/message-headers/>에서) 유지되는 “Message Headers” 레지스트리 내에 등록된다.
이 문서는 다음과 같은 HTTP 헤더 필드를 정의하므로, 그에 따라 “Permanent Message Header Field Names” 레지스트리가 업데이트되었다 (\[BCP90] 참조).
또한 HTTP 헤더 필드로 헤더 필드 이름 "Close"가 Connection 헤더 필드의 "close" 커넥션 옵션과 충돌할 수 있으므로 헤더 필드 이름 "Close"가 "reserved"로 등록되었다(Section 6.1)
#### 8.2 URI Scheme Registration
IANA는 URI schemes \[BCP115]의 레지스트리<[http://www.iana.org/assignments/uri-schemes/>에](http://www.iana.org/assignments/uri-schemes/>에) 유지하고 있다.
#### 8.3 Internet Media Type Registration
IANA는 Internet media types \[BCP13]의 레지스트리를 <
assignments/media-types>에 유지한다.
#### 8.3.1 Internet Media Type message/http
message/http 유형은 회선 길이 및 인코딩과 관련된 모든 "message" 유형에 대한 MIME 제한을 준수하는 경우 단일 HTTP 요청 또는 응답 메시지를 동봉하는데 사용할 수 있다.
#### 8.3.2 Internet Media Type application/http
application/http 유형은 하나 이상의 HTTP 요청 또는 응답 메시지(혼합되지 않음)의 파이프 라인을 동봉하는 데 사용할 수 있다.
#### 8.4 Transfer Coding Registy
"HTTP Transfer Coding Registry"는 코딩 이름을 전송하기 위한 네임스페이스를 정의한다. 《 유지되고 있다.
#### 8.4.1 Procedure
Registrations 반드시 아래의 필드를 포함해야 한다.
* Name
* Description
* Pointer to specification text
* Section 4.2에 정의된 압축 코딩의 경우와 같이 인코딩 변환이 동일하지 않는 한, transfer coding의 이름은 content coding의 이름과 중복되지 않아야 한다. (MUST NOT)
* 이 네임스페이스에 추가할 값은 IETF 검토 (\[RFC5226]의 Section 4.1 참조)가 필요하며, 반드시 이 규격에서 정의한 transfer coding의 목적에 부합해야 한다. (MUST)
#### 8.4.2 Registration
#### 8.5 Content Coding Registration
IANA는 "HTTP Content Coding Registry"를 <[http://www.iana.org/assignments/http-parameters>에서](http://www.iana.org/assignments/http-parameters>에서) 유지 관리한다.
#### 8.6 Upgrade Token Registry
"HTTP(Hypertext Transfer Protocol) Upgrade Token Registry"는 Upgrade 헤더 필드에서 프로토콜을 식별하는 데 사용되는 protocol-name 토큰의 네임스페이스를 정의한다. 레지스트리는 <[http://www.iana.org/assignments/http-upgrade-tokens>에서](http://www.iana.org/assignments/http-upgrade-tokens>에서) 유지되고 있다.
#### 8.6.1 Procedure
1. 한번 등록된 protocol-name 토큰은 영원히 등록된다.
2. 등록은 반드시 등록의 책임자를 기록해야 한다.(MUST)
3. 등록은 반드시 contect 지정해야 한다.
4. 등록은 해당 토큰과 관련된 명세 집합의 이름을 지정할 수 있다. 그러한 규격은 공개적으로 이용할 필요가 없다.(MAY)
5. 등록 시 등록은 해당 토큰과 관련된 예상 “protocol-version”토큰의 이름을 지정해야 한다.(SHOULD)
6. 책임 당사자는 언제든지 등기를 변경할 수 있다. IANA는 그러한 모든 변경사항을 기록하여 요청 시 이용할 수 있도록 할 것이다.(MAY)
7. IESG는 프로토콜 토큰에 대한 책임을 재할당할 수 있다. 이것은 일반적으로 책임 있는 당사자와 접촉할 수 없는 경우에만 사용된다.(MAY)
#### 8.6.2 Upgrade Token Registration
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://hochan049.gitbook.io/cs-interview/web/rfc-7320/8.-iana-considerations.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.