맨위로가기

RFC

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

RFC는 1969년 ARPANET 프로젝트에서 시작된 문서 형식으로, 인터넷 엔지니어링 태스크 포스(IETF)와 같은 인터넷 관련 단체에서 공식적인 출판 채널로 사용된다. 초기에는 의견 교환을 위한 요청(Request for Comments)의 성격을 띠었으며, 현재는 인터넷 표준 및 기술 관련 정보를 제공한다. RFC는 IETF, IAB, IRTF 등 다양한 발행 흐름을 통해 제작되며, 표준화 과정, 정보 제공, 실험적, 현재 최선의 실례, 역사적 상태를 갖는다. RFC는 누구나 열람하고 획득할 수 있으며, 매년 만우절에는 유머러스한 내용의 농담 RFC가 공개되기도 한다.

광고

더 읽어볼만한 페이지

  • RFC - IETF 언어 태그
    IETF 언어 태그는 컴퓨터 시스템에서 언어 및 지역 정보를 표현하기 위해 인터넷 엔지니어링 태스크 포스(IETF)에서 정의한 식별자로, 하이픈으로 구분된 하위 태그들의 조합으로 구성되어 언어, 문자 체계, 지역, 변이형 등의 정보를 나타내며, 유니코드 로케일 확장을 통해 문화적 속성 또한 포함할 수 있다.
  • RFC - 다이제스트 인증
    다이제스트 인증은 HTTP 통신에서 클라이언트와 서버 간 사용자 인증 방식으로, 클라이언트가 사용자 이름, 비밀번호, nonce 등을 해싱한 응답 값을 서버에 전송하여 인증하며, RFC 2069의 취약점을 개선한 RFC 2617과 RFC 7616으로 강화되었으나, HTTPS 기본 인증에 비해 단점이 많아 사용이 줄고 있다.
  • 한국 인터넷 역사 프로젝트의 저작물을 인용한 문서 - 단군의 땅
  • 한국 인터넷 역사 프로젝트의 저작물을 인용한 문서 - 국가기간전산망
  • 인터넷 표준 - DNSSEC
    DNSSEC는 DNS의 보안 취약점을 개선하기 위해 도메인 정보에 디지털 서명을 추가하여 응답 레코드의 무결성을 보장하고 DNS 위장 공격을 막는 기술로, RRSIG, DNSKEY 등 다양한 리소스 레코드 유형을 사용하여 인증 체인을 구성하며 공개 키 암호 방식을 활용한다.
  • 인터넷 표준 - IPv6
    IPv6는 IPv4 주소 고갈 문제를 해결하고자 개발된 차세대 인터넷 프로토콜로, 128비트 주소 체계를 통해 사실상 무한대에 가까운 IP 주소를 제공하며, 주소 자동 설정, 패킷 처리 효율성 향상, 보안 기능 강화 등의 특징을 갖는다.

2. 역사

RFC 형식은 1969년 ARPANET 프로젝트의 일환으로 시작되었다.[5] 오늘날 RFC는 인터넷 엔지니어링 태스크 포스(IETF), 인터넷 아키텍처 위원회(IAB) 등 컴퓨터 네트워크 연구자 커뮤니티의 공식 출판 채널이다.

초기 RFC는 타자기로 작성되어 ARPA 연구자들에게 배포되었다. '의견 요청'(Requests for Comments)이라는 이름처럼 격식을 갖추지 않은 스타일로 작성되어 토론을 장려했다.[7][8] 1974년 RFC 675에서 inter-networking의 약어로 "Internet"이라는 단어가 처음 사용되었다. 1977년경에는 ARPANET 프로젝트와는 별도로 인터넷 프로젝트가 시작되면서, 인터넷 실험 노트(IEN) 등 RFC와 유사한 문서 시리즈가 발행되기 시작했다.

2. 1. 초기 RFC

초기 RFC는 말 그대로 의견을 요청하는 문서였으며, 토론을 장려하기 위해 비공식적인 스타일로 작성되었다.[40][41] 1969년 4월 7일 캘리포니아 대학교 로스앤젤레스 캠퍼스(UCLA)의 스티브 크로커가 작성한 RFC 1 "Host Software"가 최초의 RFC이다.[42] 이 RFC는 스티브 크로커, 스티브 카, 제프 룰리프슨 사이의 초기 작업 그룹 토론에서 나왔다.

초기 RFC는 타자기로 작성되어 고등연구계획국(ARPA, 이후 DARPA로 개명) 연구자들에게 배포되었다. 1969년 12월부터는 새로 가동된 ARPANET을 통해 배포되기 시작했다.[43]

RFC 3에서는 RFC 시리즈의 기원을 네트워크 작업 그룹으로 설명하고 있다.[5] 이 그룹은 공식적인 위원회가 아니라 ARPANET 프로젝트에 관심 있는 연구자들의 느슨한 모임이었다.

더글러스 엥겔바트가 이끄는 스탠포드 연구소의 증강 연구 센터(ARC)는 초기 RFC의 주요 발신지 중 하나였다. ARC는 최초의 네트워크 정보 센터(InterNIC) 역할을 담당했으며, 엘리자베스 J. 페인러가 RFC 배포를 관리했다.[44]

2. 2. 네트워크를 통한 배포

1969년 12월, 연구자들은 새로 가동된 ARPANET을 통해 RFC를 배포하기 시작했다.[9] 초기 RFC는 캘리포니아 대학교 로스앤젤레스 캠퍼스(UCLA)와 스탠퍼드 연구소의 오그멘테이션 연구 센터(ARC)에서 주로 작성되었다. UCLA에는 ARPANET의 최초 인터페이스 메시지 프로세서(IMP) 중 하나가 설치되어 있었고, ARC는 ARPANET 노드의 처음 네 곳 중 하나이자 초기 RFC의 주요 발신지였다. ARC에는 최초의 네트워크 정보 센터(InterNIC)가 설치되어 엘리자베스 J. 페인러가 관리하며 다른 네트워크 정보와 함께 RFC를 배포했다.[10]

2. 3. 인터넷 실험 노트 (IEN)

1977년경, ARPANET 프로젝트와는 별도로 인터넷 프로젝트가 시작되면서 RFC와 유사한 문서 시리즈인 인터넷 실험 노트(IEN)가 발행되었다.[45] IEN 외에도 여러 프로젝트에서 RFC를 모방한 문서 시리즈가 존재했으며, 이들은 나중에 RFC로 통합되었다.[45]

이러한 시리즈는 완전히 독립된 것은 아니었으며, 여러 프로젝트와 관련된 문서는 여러 시리즈에서 번호가 매겨지기도 했다. 예를 들어 RFC 675는 INWG 72이기도 하고, RFC 761은 IEN 129이기도 하다. 1983년 ARPANET이 TCP/IP로 전환하면서, 이러한 유사 문서 시리즈는 RFC에 통합되었다.[45]

2. 4. RFC 편집자의 역할

1969년부터 1998년까지 존 포스텔이 RFC 편집자로 활동했다.[11] 1998년 존 포스텔이 사망한 후, 그의 부고는 로 출판되었다.

미국 연방 정부와의 ARPANET 계약이 만료된 후, IETF를 대신하여 인터넷 소사이어티는 인터넷 아키텍처 위원회(IAB)의 지시에 따라 편집 및 출판 책임을 맡도록 남캘리포니아 대학교(USC) 정보 과학 연구소(ISI)와 계약을 체결했다.[46]

2007년 7월, RFC 발행 스트림(RFC stream영어)이 정의되어 편집 업무를 분담할 수 있게 되었다.[47]

2010년 1월, RFC 편집자 기능은 협회 관리 솔루션(Association Management Solutions)으로 이전되었으며, 글렌 코와크(Glenn Kowack)가 임시 시리즈 편집자로 활동했다.[48] 2011년 말, 헤더 플래너건(Heather Flanagan)이 정규 RFC 시리즈 편집자(RFC Series Editor영어, RSE)로 채용되었다. 또한, RFC 시리즈 감독 위원회(RFC Series Oversight Committee영어, RSOC)가 이때 만들어졌다.[49]

2020년, 인터넷 아키텍처 위원회(IAB)는 RFC 편집자 모델에 대한 잠재적 변경 사항을 논의하기 위해 RFC 편집자 미래 개발 프로그램을 소집했다. 이 프로그램의 결과는 2022년 6월에 출판된 에 정의된 RFC 편집자 모델 (버전 3)에 포함되었다.[24] 새로운 모델은 RFC 시리즈 및 RFC 편집자 기능과 관련된 정책을 정의하고 구현하기 위한 책임과 프로세스를 명확히 하는 것을 목표로 한다. 새로운 모델의 변경 사항에는 RFC 컨설팅 편집자(RFC Consulting Editor영어), RFC 시리즈 실무 그룹(RFC Series Working Group영어, RSWG), RFC 시리즈 승인 위원회(RFC Series Approval Board영어, RSAB)의 직책을 설정하는 것이 포함되었다. 또한 RFC 시리즈를 위한 새로운 편집 스트림을 설정하고 RSOC를 종료했다. RSE의 역할은 RFC 시리즈 컨설팅 편집자(RFC Series Consulting Editor영어, RSCE)로 변경되었다. 2022년 9월, 알렉시스 로시(Alexis Rossi)가 이 직책에 임명되었다.[50]

3. RFC 제작 및 버전 관리

RFC 편집자는 각 RFC에 일련 번호를 할당한다. 번호가 할당되고 게시된 RFC는 결코 철회되거나 수정되지 않는다. 문서에 수정 사항이 필요한 경우, 작성자는 수정된 문서를 게시한다. 따라서 일부 RFC는 다른 RFC를 대체하며, 대체된 RFC는 대체 RFC에 의해 ''폐지'' 또는 ''구식''이라고 한다. 일련 번호가 매겨진 RFC는 인터넷 표준 및 관행의 진화에 대한 지속적인 역사적 기록을 구성한다.[20] RFC 제작 프로세스는 RFC 2026 The Internet Standards Process, Revision 3영어에 정의되어 있다.

3. 1. 제작 과정

RFC 제작 과정은 국제 표준화 기구(ISO)와 같은 공식적인 표준 기구의 표준화 과정과 다르다. 인터넷 기술 전문가는 외부 기관의 지원 없이 인터넷 초안을 제출할 수 있다. 표준 트랙 RFC는 IETF의 승인을 받아 게시되며, 일반적으로 IETF 워킹 그룹에 참여하는 전문가가 제작한다. IETF 워킹 그룹은 먼저 인터넷 초안을 게시하는데, 이 방식은 문서가 RFC로 발전하기 전에 초기 동료 검토 단계를 용이하게 한다.[21]

개인 또는 소규모 워킹 그룹이 수행하는 실용적이고 경험 중심적인 사후 표준 저술의 RFC 전통은 ISO 및 국가 표준 기관의 전형적인 보다 공식적인 위원회 중심 과정보다 중요한 이점을 가질 수 있다.[22]

대부분의 RFC는 MUST영어, NOT RECOMMENDED영어와 같은 일반적인 용어 집합, 메타 언어인 확장된 바커스-나우르 표기법(ABNF), 그리고 일관성을 유지하고 이해하기 쉬운 간단한 텍스트 기반 형식을 사용한다.[20]

3. 2. 스타일 가이드

RFC 스타일 가이드는 에 정의되어 있다. 대부분의 RFC는 에 정의된 "MUST" 및 "NOT RECOMMENDED"와 같은 일반적인 용어 집합, 메타 언어인 확장된 바커스-나우르 표기법(ABNF) (), 그리고 일관성을 유지하고 이해하기 쉬운 간단한 텍스트 기반 형식을 사용한다.[20]

초기 RFC는 리플로우 불가능 텍스트 형식으로 제작되었다. 2019년 8월, RFC 문서는 다양한 화면 크기의 기기에서 최적으로 표시될 수 있도록 리플로우 가능한 형식으로 변경되었다.[19]

3. 3. 버전 관리

RFC 편집자는 각 RFC에 일련 번호를 할당한다. 번호가 할당된 RFC는 철회되거나 수정되지 않으며, 필요한 경우 새로운 RFC로 대체된다. 대체된 RFC는 "폐지(obsolete)"되었다고 표시된다.[20] 일부 수정의 경우, RFC의 일부를 업데이트할 수 있으며, 이 경우 "업데이트(update)"되었다고 표시된다.

공개된 RFC에 큰 수정이 필요한 경우, 새로운 RFC로 개정판을 발행한다. 따라서 일부 RFC는 다른 RFC를 대체할 수 있다. 다른 RFC를 대체한 RFC는 "대체할 RFC를 폐지했다(obsolete영어)"라고 하며, 대체된 RFC는 "대체할 RFC에 의해 폐지되었다(obsoleted by영어)"라고 한다. 예를 들어 RFC 5000은 RFC 7100에 의해 폐기되었으므로, RFC 인덱스 등에는 RFC 5000에 Obsoleted-By RFC 7100이라고 기재되어 있으며, RFC 7100에는 Obsoletes RFC 5000이라는 기재가 있다.

또한 RFC 문서 전체를 폐지하는 것이 아니라, 일부를 덮어쓰는 경우도 있다. 이 경우에는 다른 RFC를 덮어쓴 RFC는 "덮어쓸 RFC를 업데이트했다(update영어)"라고 하며, 덮어쓰인 RFC는 "덮어쓴 RFC에 의해 업데이트되었다(updated by영어)"라고 한다.

4. RFC 상태

모든 RFC가 인터넷 표준인 것은 아니다.[27][28] 각 RFC에는 표준화 프로세스에서의 상태가 지정된다. RFC의 상태는 "표준화 과정(Standards Track)", "정보(Informational)", "실험적(Experimental)", "현재 최선의 실례(Best Current Practice)", "역사적(Historic)", "불명(Unknown)" 중 하나이다.

RFC는 제출, 승인 및 게시된 후에는 변경될 수 없다. 정오표는 별도로 게시될 수 있으며, 더 중요한 변경 사항은 새로운 일련 번호를 받게 될 새로운 제출이 필요하다.[29]


  • '''표준화 과정(Standards Track)''' : 인터넷 엔지니어링 스티어링 그룹(IESG)에 의해 승인된 RFC에 지정되는 상태이다. "표준 제안(Proposed Standard, PS)", "표준 초안(Draft Standard, DS)", "인터넷 표준(Internet Standard, STD)"으로 나뉜다.
  • '''정보(Informational)''' : 만우절 농담 RFC나 DNS의 구조와 같이 널리 필수적인 것으로 인정된 RFC 등이 포함된다.
  • '''실험적(Experimental)''' : 인터넷에 관해 유용하다고 생각되는 연구 성과나 실험 결과를 널리 공개하기 위한 것이다. 실험적이라고는 하지만, 실제로는 구체적인 절차를 밟으려는 사람이 없기 때문에 표준화 과정으로 승격되지 않은 문서도 포함된다.
  • '''현재 최선의 실례(Best Current Practice)''' : 실제로 네트워크에서 사용되는 데이터에는 영향을 미치지 않는 인터넷상의 공식적인 규칙으로 간주되는 실무상 문서 등이다. 인터넷 표준을 실천하기 위한 기술적인 권장 사항도 포함된다.
  • '''역사적(Historic)''' : 표준화 과정에서 폐기된 문서나 표준화 이전에 공개되었던 쇠퇴한 RFC에 적용된다.
  • '''불명(Unknown)''' : 상태가 도입되기 이전( RFC 1128 이전)에 공개된 RFC에 지정되는 상태이다. 다만 일부 RFC에 대해서는 소급하여 "불명" 이외의 상태를 적용하기도 한다.[54]

4. 1. 표준화 과정 (Standards Track)

인터넷 엔지니어링 스티어링 그룹(IESG)에 의해 대표되는 IETF만이 표준 트랙 RFC를 승인할 수 있다.[30]

표준 트랙 문서는 ''제안 표준'' 문서와 ''인터넷 표준'' 문서로 더 나뉜다.[30] RFC가 인터넷 표준(STD)이 되면 STD 번호가 할당되지만 RFC 번호는 유지된다. 인터넷 표준의 최종 목록은 공식 인터넷 프로토콜 표준이다.

인터넷 표준이 업데이트되면 STD 번호는 동일하게 유지되며, 이제 새로운 RFC 또는 RFC 세트를 나타낸다. 예를 들어, 2007년에 RFC 3700은 인터넷 표준—STD 1—이었고 2008년 5월에 RFC 5000으로 대체되었으며, RFC 3700은 ''역사적''으로 변경되었고, RFC 5000은 인터넷 표준이 되었다.

"표준화 과정"은 성숙도에 따라 "표준 제안(Proposed Standard, PS)", "인터넷 표준(Internet Standard, STD)"으로 나뉜다. 이전의 RFC 2026에서는 "표준 제안", "표준 초안(Draft Standard, DS)", "인터넷 표준"의 3단계였지만, RFC 6410에 의해 2단계로 변경되었다. 다만, 그 이전에 "표준 초안"이 된 것이 계속 존재하기 때문에, 표준화 과정의 RFC가 모두 2단계 중 하나가 되는 것은 아니다. 최신 상태는 RFC 편집자 사이트에서 확인할 수 있다.[57]

4. 2. 정보 (Informational)

만우절 농담부터 도메인 이름 시스템 구조 및 위임과 같이 널리 알려진 필수 RFC에 이르기까지 거의 모든 내용을 담을 수 있다.[55][56] 일부 정보 제공 RFC는 FYI 하위 시리즈를 형성하기도 한다.

정보 RFC의 예시는 다음과 같다.

  • 조류 캐리어에 의한 IP
  • 세탁 집게-DHCP에 의한 IP 주소 관리
  • 하이퍼 텍스트 커피 포트 제어 프로토콜
  • 차 유출 장치를 위한 하이퍼 텍스트 커피 포트 제어 프로토콜
  • 악의 비트
  • 서기 10000년 문제
  • 수기 신호 시스템에 의한 IP 전송
  • 사망 플래그
  • 음향 전송 미디어를 이용한 IP 전송
  • 대기 링크 계층을 사용한 지역적 브로드캐스트


또한, 인터넷에 지대한 공헌을 한 사람에 대한 추모 RFC도 공개된 적이 있다.

  • ''"I Remember IANA"'' (1998년 10월)
  • ''"Working with Jon"'' (1998년 11월)

4. 3. 실험적 (Experimental)

실험적 RFC는 IETF 문서이거나 RFC 편집자에게 제출된 개인 제출 문서일 수 있다. 제안이 의도한 대로 작동할지 불확실하거나, 제안이 널리 채택될지 불확실한 경우 초안은 실험적으로 지정된다. 실험적 RFC는 인기를 얻고 잘 작동하면 표준 트랙으로 승격될 수 있다.[55][56]

실험적 RFC는 인터넷에 관해 유용하다고 생각되는 연구 성과나 실험 결과를 널리 공개하기 위한 것이다. 실험적이라고는 하지만, 실제로는 구체적인 절차를 밟으려는 사람이 없기 때문에 표준화 과정으로 승격되지 않은 문서도 포함된다.

4. 4. 현재 최선의 실례 (Best Current Practice)

최신 권장 사항 (BCP, Best Current Practice) 하위 시리즈는 공식 규칙으로 간주되며, 단순히 "정보 제공"뿐만 아니라 "데이터 전송"에 영향을 미치지 않는 관리 문서 및 기타 텍스트를 수집한다. 표준 트랙과 BCP의 경계는 종종 불분명하다. BCP 9,[33] 또는 IETF 관리를 예로 들어, 문서가 인터넷 표준 프로세스에만 영향을 미치는 경우 이는 명확한 BCP이다. 인터넷 할당 번호 기관(IANA) 레지스트리에 대한 규칙 및 규정만 정의하는 경우는 명확하지 않다. 이러한 문서의 대부분은 BCP이지만 일부는 표준 트랙에 있다.

BCP 시리즈는 인터넷 표준을 실천하기 위한 기술 권장 사항도 다룬다. 예를 들어, DoS 공격을 더 어렵게 만들기 위해 소스 필터링을 사용할 것을 권장하는 사항인 BCP 38(네트워크 인그레스 필터링: IP 소스 주소 스푸핑을 사용하는 서비스 거부 공격 방지)이 있다.

4. 5. 역사적 (Historic)

RFC라는 개념은 1969년 ARPANET 프로젝트에서 탄생했다.[39] 초기 RFC는 타자기로 작성되었고, 고등연구계획국(ARPA, 나중에 DARPA로 개명)의 연구자들에게 복사된 종이가 배포되었다. 현재의 RFC와는 달리, 초기 RFC의 대부분은 문자 그대로 코멘트를 구하는 것이었고, 선언과 같은 울림을 피하고, 논의를 촉진하기 위해 "Request for comments"라는 이름이 붙었다.[40][41] 초기 RFC는 그다지 형식을 갖추지 않은 스타일로 작성되었다.

UCLA의 스티브 크로커가 집필한 은 1969년 4월 7일에 발행된 "호스트 소프트웨어"이다.[42] 이 RFC는 크로커가 집필했지만, 크로커와 스티브 카, 제프 루리프슨에 의한 초기 워킹 그룹에서의 논의로 탄생했다.

크로커가 집필한 에서 "RFC란 무엇인가"를 처음 정의했고, RFC는 ARPA의 네트워크 워킹 그룹에 귀속되는 것으로 했다. 하지만, 이것은 정식 위원회가 아니라, ARPANET 프로젝트에 관심이 있는 연구자들의 느슨한 모임이었고, 누구든지 참가할 수 있었다.

ARPANET이 1969년 12월에 가동되기 시작하자, RFC의 배포는 ARPANET 상에서 이루어지게 되었다. 최초로 네트워크에서 배포된 RFC는 였다.[43] UCLA에는 ARPANET의 최초 IMP(Interface Message Processor) 중 하나가 설치되어 있었기 때문에, 1970년대 RFC의 대부분도 UCLA에서 발신되었다. 더글러스 엥겔바트가 소장을 맡은 스탠퍼드 연구소의 오그멘테이션 연구 센터(ARC)는 ARPANET의 최초 4개의 노드 중 하나였고, 초기 RFC도 여기서 발신되었다. ARC에는 최초의 NIC(이후의 InterNIC)가 설치되었고, 엘리자베스 J. 페인러가 관리하여 다른 네트워크 정보와 함께 RFC를 배포했다.[44]

1974년에 발행된 에서 inter-networking의 약어로 처음 "Internet"이라는 단어가 사용되었다.

1977년경, ARPANET 프로젝트와는 별도로 Internet 프로젝트가 발족했을 때, ARPANET 프로젝트의 RFC라는 컨셉을 모방하여, 인터넷 실험 노트(Internet Experiment Note영어, IEN)라는 유사한 문서 시리즈를 발행하기로 했다. RFC의 컨셉을 모방한 문서 시리즈는 IEN뿐만 아니라, INWG Note나, PRNET Notes, ARPA Satellite System Notes 등 많은 프로젝트에서 RFC를 모방한 유사한 문서 시리즈가 존재했다.[45]

이러한 시리즈는 완전히 독립된 것은 아니며, 복수의 프로젝트에 관계된 문서는 복수의 시리즈에서 넘버링이 되어 있는 것도 존재한다. 예를 들어 전술한 는 INWG 72이기도 하며, 또한 은 IEN 129이기도 하다.

1983년 ARPANET은 지금까지의 Network Control Program(NCP) 프로토콜을, Internet 프로젝트의 성과물인 TCP/IP로 이행했다. 이를 계기로, 또는 그 전후로, 이러한 유사한 문서 시리즈는 RFC에 통합되어 갔다.[45]

1988년, IAB에 인터넷 드래프트(Internet Draft영어) 시리즈의 작성이 승인되었다.[43] 이로 인해 최초의 "코멘트 모집"이라는 위치와 형식을 갖추지 않은 스타일이 RFC로 승인되기 전 단계인 인터넷 드래프트에 계승되었다.

RFC의 역사에 대해서는 다음 RFC에 정리되어 있다.

RFC발행일내용
1987년 8월The Request for Comments Reference Guide
1999년 4월30 Years of RFCs
2009년 4월40 Years of RFCs
2019년 12월Fifty Years of RFCs



"'''역사적'''" RFC는 RFC에서 정의된 기술이 더 이상 사용하지 않도록 권장되는 경우를 의미하며, 이는 대체 RFC의 "Obsoletes" 헤더와는 다르다. 예를 들어, (SMTP)는 다양한 최신 RFC에 의해 폐지되었지만, SMTP 자체는 여전히 "현재 기술"이므로 "역사적" 상태에 있지 않다.[34] 그러나 BGP 버전 4가 이전 BGP 버전을 완전히 대체했으므로, 와 같이 이전 버전을 설명하는 RFC는 역사적으로 지정되었다.

4. 6. 불명 (Unknown)

상태가 도입되기 이전의 RFC(RFC 1128 이전)는 대부분 "불명(Unknown)"으로 간주된다.[54] "불명" 상태는 오늘날 발행된다면 어떤 상태를 부여받을지 불분명한 매우 오래된 RFC에 사용된다. 이러한 RFC 중 일부는 오늘날에는 전혀 발행되지 않을 것이다. 초기 RFC는 종종 그 자체로 단순한 의견 요청(Request for Comments)이었으며, 오늘날 RFC 시리즈가 사용되는 프로토콜, 행정 절차 또는 기타 어떤 것도 명시하기 위한 것이 아니었다.[35] 다만 일부 RFC에 대해서는 소급하여 "불명" 이외의 상태를 적용하기도 한다.[54]

5. RFC 하위 시리즈

IETF RFC의 하위 시리즈에는 BCP, STD가 있으며, 과거에는 FYI 하위 시리즈도 존재했다. RFC가 각 하위 시리즈에 할당되면 하위 시리즈 번호가 할당되지만, RFC 번호는 유지된다. 하위 시리즈를 구성하는 RFC가 대체되어도 하위 시리즈 번호는 변함없이 새로운 RFC를 참조하게 된다.

5. 1. BCP (Best Current Practice)

BCP (Best Current Practice)는 표준화 과정은 아니지만, 실무상의 규칙 등 필수 정보를 정리한 IETF RFC의 하위 시리즈이다. 상태가 "현재 최상의 관행"인 RFC가 이 하위 시리즈를 구성한다.[54] RFC가 하위 시리즈에 할당되면 하위 시리즈 번호가 할당되지만, RFC 번호는 유지된다. 하위 시리즈를 구성하는 RFC가 대체되어도 하위 시리즈 번호는 변함없이 새로운 RFC를 참조하게 된다.

5. 2. STD (Standard)

STD 하위 시리즈(Standard영어)는 표준화 과정의 최종 단계인 "인터넷 표준" RFC로 구성된다.[55][56]

RFC가 각 하위 시리즈에 할당되면, 하위 시리즈 번호가 할당된다(예: STD 1 등). 하위 시리즈 번호가 할당되어도 RFC 번호는 유지된다.

하위 시리즈를 구성하는 RFC가 대체된 경우에도, 하위 시리즈 번호는 변함없이 새로운 RFC를 참조하게 된다(참조 대상 RFC는 한 개인 경우도 있고, 여러 개인 경우도 있다). 예를 들어, 2007년 시점에서는 RFC 3700이 인터넷 표준 STD 1이었지만, 그 후 RFC 5000으로 대체되었기 때문에, 2008년 5월 시점의 STD 1은 RFC 5000이 되었다. 또한 2013년 12월에 RFC 7100로 대체되어, STD 1은 사용되지 않게 되었다.

5. 3. FYI (For Your Information)

FYI (For Your Information)는 IETF에서 추진한 정보성 RFC의 하위 시리즈였다. 2011년에 FYI 1이 폐지되어 이 하위 시리즈는 종료되었다.[45]

6. RFC 발행 흐름

RFC 발행 절차에는 IETF, IRTF, IAB, 독립 제출, 그리고 성명(Editorial)의 5가지 패턴이 있다.[58] IETF, IRTF, IAB, 독립 제출은 각각 역할에 따라 RFC를 발행하며, IETF가 아닌 문서들은 IESG에서 IETF 작업과의 충돌 여부를 검토한다.[25][26] 성명은 RFC 시리즈 전반의 편집 정책 변경에 사용된다.[24]

각 RFC는 표준화 과정에서의 상태를 가지며, "표준화 과정", "정보", "실험적", "현재 최선의 실례", "역사적", "불명" 중 하나이다.


  • '''"표준화 과정"'''은 "표준 제안", "인터넷 표준"으로 나뉜다.
  • '''"정보"'''는 만우절 농담 RFC, 독점 프로토콜, DNS 구조와 권한 위임 관련 RFC 등을 포함한다.
  • '''"실험적"'''은 인터넷 관련 연구 성과나 실험 결과를 공개한다.
  • '''"현재 최선의 실례"'''는 네트워크에서 사용되는 데이터에 영향을 미치지 않는 실무상 문서 등이다.
  • '''"역사적"'''은 폐기되거나 쇠퇴한 RFC에 적용된다.
  • '''"불명"'''은 상태 도입 이전에 공개된 RFC에 적용된다.

6. 1. IETF

IETF는 "현재 최선의 관행"과 "표준화 과정"의 RFC를 작성한다.[58] IETF와 성명을 제외한 문서는 IETF 작업과 충돌하는지 IESG에서 검토한다.[25][26]

6. 2. IAB

IAB는 정책 및 아키텍처와 관련된 "정보" 문서를 공개한다.[23]

6. 3. IRTF

IRTF는 연구 결과를 "정보" 또는 "실험적"으로 공개한다.[25] IRTF RFC는 일반적으로 IETF 작업과 충돌하지 않는 인터넷 관련 정보 또는 실험을 포함한다.[25]

6. 4. 독립 제출 (Independent Submission)

IESG는 IETF 작업과 충돌하는지 여부를 IETF가 아닌 문서를 검토한다. IRTF 및 ''독립'' RFC는 일반적으로 IETF 작업과 충돌하지 않는 인터넷 관련 정보 또는 실험을 포함한다.[25][26] 독립 제출은 독립 제출 편집자의 재량에 따라 게시된다.[23]

6. 5. 성명 (Editorial)

RFC 시리즈 전체의 편집 정책 변경은 성명(Editorial영어) 스트림을 통해 적용된다. 성명 스트림은 RFC 시리즈 전반에 걸쳐 편집 정책 변경을 적용하는 데 사용된다.[24]

7. RFC와 한국 인터넷

RFC는 한국 인터넷의 발전과 표준화에 중요한 역할을 해왔다. 한국 인터넷 커뮤니티는 RFC를 통해 국제 표준을 습득하고, 자체적인 기술 개발에 기여해왔다. 특히, 한국어 문자 인코딩(RFC 1468)과 같은 RFC는 한국 인터넷 환경에 맞춘 기술 표준을 제시하는 데 기여했다.

8. 저작권

일반적으로 RFC의 저작권은 원 저작자(또는 고용 조건에 따라 고용주)가 명시적으로 권리를 이전하지 않는 한 보유한다.[36]

IETF 트러스트는 일부 RFC에 대한 저작권을 보유하며, 다른 모든 RFC에 대해서는 저작자가 RFC를 복제할 수 있도록 허가한다.[37] 인터넷 협회(Internet Society)는 RFC4714 이전의 많은 RFC에서 저작권 소유자로 언급되었지만, 권리를 IETF 트러스트로 이전했다.[38]

9. 획득 방법

모든 RFC는 인터넷 상에서 공개되어 있으며, 누구나 열람하고 획득할 수 있다.[62][63][64] RFC는 다음 두 웹사이트에서 획득할 수 있다.



IETF는 RFC의 공식 제공 URI는 www.rfc-editor.org 도메인의 것이며, datatracker.ietf.org 도메인의 것은 작업용 저장소라고 밝히고 있다.[62][63][64] 단, 관련된 인터넷 드래프트 등은 datatracker.ietf.org 에만 있으므로 주의가 필요하다.

10. 특이한 RFC

매년 만우절에는 유머러스한 내용의 RFC, 통칭 농담 RFC가 공개되는 경우가 있다.[45]


  • 조류 캐리어에 의한 IP (RFC 1149, RFC 2549, RFC 6214)
  • 세탁 집게-DHCP에 의한 IP 주소 관리 (RFC 2322)
  • 하이퍼 텍스트 커피 포트 제어 프로토콜 (RFC 2324)
  • 차 유출 장치를 위한 하이퍼 텍스트 커피 포트 제어 프로토콜 (RFC 7168)
  • 악의 비트 (RFC 3514)
  • 서기 10000년 문제 (RFC 2550)
  • 수기 신호 시스템에 의한 IP 전송 (RFC 4824)
  • 사망 플래그 (RFC 9401)
  • 음향 전송 미디어를 이용한 IP 전송 (RFC 1926)
  • 대기 링크 계층을 사용한 지역적 브로드캐스트 (RFC 6217)


또한, 인터넷에 지대한 공헌을 한 사람에 대한 추모 RFC가 공개된 적도 있다.

  • RFC 2468 ''"I Remember IANA"'' (1998년 10월)
  • RFC 2441 ''"Working with Jon"'' (1998년 11월)

참조

[1] 웹사이트 RFCs https://www.ietf.org[...] 2023-11-05
[2] IETF A Standard for the Transmission of IP Datagrams on Avian Carriers IETF 1990-04-01
[3] IETF Not All RFCs are Standards IETF 1995-04
[4] 웹사이트 RFC's, Internet Request For Comments http://www.livingint[...] Livinginternet.com 2012-04-03
[5] 뉴스 Stephen D. Crocker, ''How the Internet Got Its Rules'', The New York Times, 6 April 2009 https://www.nytimes.[...] 2009-04-07
[6] 웹사이트 Notice and Request for Comments https://www.federalr[...] 2018-01-16
[7] 서적 Where Wizards Stay Up Late: The Origins of the Internet Simon & Schuster
[8] 간행물 Meet the man who invented the instructions for the Internet https://www.wired.co[...] 2012-05-18
[9] IETF RFC 1 1969-04-07
[10] 학술 The Network Information Center and its Archives 2010-07-09
[11] 뉴스 RFC Editor in Transition: Past, Present, and Future http://www.cisco.com[...] Cisco Systems 2010-03
[12] IETF The RFC Series and RFC Editor IETF 2007-07
[13] IETF RFC Editor Model (Version 1) IETF 2009-08
[14] IETF RFC Editor Model (Version 2) IETF 2012-06
[15] IETF RFC Streams, Headers, and Boilerplates IETF 2009-12
[16] 웹사이트 RFC Editor Transition Announcement http://www.ietf.org/[...] 2010-01-07
[17] 웹사이트 The RFC Series Editor and the Series Reorganization https://www.rfc-edit[...] 2013-04-05
[18] 웹사이트 Alexis Rossi appointed as RFC Series Consulting Editor https://www.ietf.org[...]
[19] 웹사이트 RFC Format Change FAQ https://www.rfc-edit[...]
[20] 웹사이트 "RFC Index" "//www.rfc-editor.or[...] RFC Editor 2008-05-25
[21] IETF IETF Working Group Guidelines and Procedures
[22] 문서 Request for Comments
[23] 웹사이트 Independent Submissions https://www.rfc-edit[...] RFC Editor
[24] IETF RFC Editor Model (Version 3) IETF 2022-06
[25] IETF Independent Submissions to the RFC Editor Internet Architecture Board 2007-07
[26] IETF IESG Procedures for Handling of Independent and IRTF Stream Submissions IETF 2009-12
[27] 웹사이트 Are all RFCs Internet standards documents? https://www.rfc-edit[...] RFC Editor
[28] IETF Not All RFCs are Standards IETF 1995-04
[29] 웹사이트 How to Read an RFC https://www.mnot.net[...] 2018-07-31
[30] IETF Reducing the Standards Track to Two Maturity Levels IETF 2011-10
[31] IETF Retirement of the "Internet Official Protocol Standards" Summary Document
[32] 서적 The Tao of IETF "//www.ietf.org/tao.[...]
[33] IETF The Internet Standards Process – Revision 3 IETF 1996-10
[34] 웹사이트 IESG Statement on Designating RFCs as Historic https://www.ietf.org[...] IETF 2014-07-20
[35] 웹사이트 IETF Standards Written by ISC Contributors https://www.isc.org/[...] Internet Systems Consortium 2021-09-10
[36] 웹사이트 Reproducing RFCs https://trustee.ietf[...] IETF Trust 2021-08-12
[37] 간행물 Rights Contributors Provide to the IETF Trust IETF 2008-11
[38] 웹사이트 Reproducing RFCs https://trustee.ietf[...] IETF Trust 2021-08-13
[39] 뉴스 Stephen D. Crocker, ''How the Internet Got Its Rules'', The New York Times, 6 April 2009 https://www.nytimes.[...] 2009-04-07
[40] 서적 Where Wizards Stay Up Late: The Origins of the Internet 1996
[41] 간행물 Meet the man who invented the instructions for the Internet https://www.wired.co[...] 2012-05-18
[42] 간행물 Host Software 1969-04-07
[43] 간행물 Fifty Years of RFCs 2019-12
[44] 논문 The Network Information Center and its Archives 2010-07
[45] 간행물 30 Years of RFCs 1999-04-07
[46] 뉴스 RFC Editor in Transition: Past, Present, and Future http://www.cisco.com[...] Cisco Systems 2010-03
[47] 간행물 The RFC Series and RFC Editor 2007-07
[48] 웹사이트 RFC Editor Transition Announcement https://web.archive.[...] 2011-06-29
[49] 웹사이트 The RFC Series Editor and the Series Reorganization https://web.archive.[...] 2013-03-13
[50] 웹사이트 Alexis Rossi appointed as RFC Series Consulting Editor https://www.ietf.org[...] 2022-09-01
[51] 간행물 IETF Working Group Guidelines and Procedures 1998-09
[52] 웹사이트 Style Guide https://www.rfc-edit[...] RFC Editor
[53] 웹사이트 RFC Format Change FAQ https://www.rfc-edit[...]
[54] 웹사이트 About RFCs https://www.ietf.org[...] IETF
[55] 웹사이트 Frequently Asked Questions - Are all RFCs Internet standards documents? https://www.rfc-edit[...]
[56] 간행물 Not All RFCs are Standards 1995-04
[57] 웹사이트 Official Internet Protocol Standards https://www.rfc-edit[...] RFC Editor
[58] 간행물 RFC Editor Model (Version 3) 2022-06
[59] 웹사이트 Frequently Asked Questions - Reproducing RFCs https://trustee.ietf[...]
[60] 간행물 Rights Contributors Provide to the IETF Trust 2008-11
[61] 웹사이트 Frequently Asked Questions - Copyright and IETF Copyright Policies https://trustee.ietf[...]
[62] 웹사이트 References in RFCXML https://authors.ietf[...]
[63] 웹사이트 What is the difference between datatracker.ietf.org & www.rfc-editor.org and which is Official URL for RFC ? https://github.com/i[...]
[64] 웹사이트 Links to HTML versions of RFC's need to move from "tools" to "datatracker" https://meta.stackex[...]
[65] 웹사이트 RFC Index https://www.rfc-edit[...] RFC Editor


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com