본문으로 이동

RFC

위키백과, 우리 모두의 백과사전.
다른 뜻에 대해서는 RFC (동음이의) 문서를 참고하십시오.
스티브 크로커, 노트북을 앞에 두고 앉아 있는 모습
최초의 RFC를 포함하여 여러 건의 RFC 문서를 저술한 스티브 크로커.

RFC(Request for Comments)는 인터넷의 주요 기술 개발 및 표준 설정 기구, 특히 국제 인터넷 표준화 기구(IETF)에서 발행하는 일련의 출판물이다.[1][2] RFC는 인터넷 및 인터넷 연결 시스템의 작동에 적용되는 방법, 행동, 연구 또는 혁신을 설명하는 비망록 형태로 개별 엔지니어와 컴퓨터 과학자 그룹이 저술한다. 이는 동료 평가를 받거나 새로운 개념, 정보, 때로는 공학적 유머를 전달하기 위해 제출된다.[3]

IETF는 RFC로 게시된 제안 중 일부를 인터넷 표준으로 채택한다. 그러나 많은 RFC는 정보 제공이나 실험적 성격을 띠며 표준은 아니다.[4] RFC 시스템은 1969년 스티브 크로커가 아파넷 개발에 관한 비공식 메모를 기록하는 것을 돕기 위해 고안했다. 이후 RFC는 인터넷 사양, 통신 프로토콜, 절차 및 이벤트에 관한 공식 문서가 되었다.[5] 크로커에 따르면 이 문서들은 "인터넷의 내부 작동 방식을 형성하며 그 성공에 중요한 역할을 했지만", 커뮤니티 외부에서는 널리 알려져 있지 않다.[6]

인터넷 커뮤니티 외부에서도 미국 연방 정부의 업무, 예를 들어 미국 고속도로교통안전국과 같이 '의견 요청(requests for comments)'이라 불리는 다른 문서들이 발행되기도 한다.[7]

개요

[편집]

RFC 문서는 비평을 기다리는 문서라는 의미로, 컴퓨터 네트워크 공학 등에서 인터넷 기술에 적용 가능한 새로운 연구, 혁신, 기법 등을 아우르는 메모를 나타낸다.

인터넷 협회(Internet Society)에서 기술자 및 컴퓨터 과학자들은 RFC 메모의 형태로 생각을 출판하게 되며, 이러한 출판의 목적은 자신의 새로운 생각 및 정보에 대해 전문가 비평을 바라는 것, 혹은 그러한 생각을 단순히 전달하는 것이다. 때로는 공학적인 유머를 위해서이기도 하다(만우절 RFC 참조). 인터넷국제표준화기구(IETF)는 일부 RFC를 인터넷 표준으로 받아들이기도 한다.

RFC 편집자는 매 RFC 문서에 일련 번호를 부여한다. 일단 일련 번호를 부여 받고 출판되면, RFC는 절대 폐지되거나 수정되지 않는다. 만약 어떤 RFC 문서가 수정이 필요하다면, 저자는 수정된 문서를 다른 RFC 문서로 다시 출판해야 한다. 그러므로, 일부 RFC는 이전 버전의 RFC를 개선한 문서이며, 이전 버전의 RFC를 무효화하기도 한다. 이러한 덮어쓰는 방식을 통해, 번호 순으로 나열된 일련의 RFC는 인터넷 표준의 역사를 나타내기도 한다.

역사

[편집]

RFC 형식의 시작은 1969년 기념비적인 아파넷 프로젝트의 일부로 이루어졌다.[6] 오늘날 이는 국제 인터넷 표준화 기구(IETF), 인터넷 아키텍처 위원회(IAB), 그리고 어느 정도는 컴퓨터 망 연구자들의 전 세계 커뮤니티 전체를 위한 공식 출판 경로이다.

최초의 RFC 저자들은 자신의 작업물을 타자기로 작성하여 아파넷 연구자들 사이에 하드 카피로 유통했다. 현대의 RFC와 달리, 초기 RFC 중 다수는 실제 의견을 요청하는 내용이었으며, 너무 단정적으로 들리는 것을 피하고 토론을 장려하기 위해 그러한 제목이 붙었다.[8][9] RFC는 질문을 열어두며 덜 격식 있는 스타일로 작성된다. 이러한 덜 격식 있는 스타일은 현재 RFC로 승인되기 이전 단계인 인터넷 드래프트 문서의 특징이 되었다.

1969년 12월, 연구자들은 새롭게 운영되기 시작한 아파넷을 통해 새로운 RFC를 배포하기 시작했다. "Host Software"라는 제목의 RFC 1는 캘리포니아 대학교 로스앤젤레스(UCLA)의 스티브 크로커가 작성하여 1969년 4월 7일에 게시되었다.[10] 스티브 크로커가 작성했지만, 이 RFC는 스티브 크로커, 스티브 카, 제프 룰리프슨 간의 초기 실무단 토론에서 탄생했다.

RFC 시리즈를 처음 정의한 RFC 3에서 크로커는 RFC 시리즈를 네트워크 실무 그룹(Network Working Group)의 공으로 돌리기 시작했다. 이는 공식 위원회라기보다는 아파넷 프로젝트에 관심이 있는 연구자들의 느슨한 결합체였다. 사실상 프로젝트에 관한 회의와 토론에 참여하고자 하는 사람은 누구든지 포함되었다.

1970년대 이후의 많은 RFC 역시 UCLA에서 나왔는데, UCLA가 아파넷에서 최초의 인터페이스 메시지 프로세서(IMP)를 보유한 곳 중 하나였기 때문이다. 더글러스 엥겔바트가 이끄는 스탠퍼드 연구소의 증강 연구 센터(ARC)는 아파넷의 처음 네 개 노드 중 하나였으며 초기 RFC의 원천이었다. ARC는 네트워크 정보 센터(InterNIC)가 되었고, 엘리자베스 J. 페인러가 이를 관리하며 다른 네트워크 정보와 함께 RFC를 배포했다.[11]

1978년 만우절에 RFC 748가 TCP/IP 문서 스타일을 패러디하여 게시되었다. 이는 1989년 텔넷 클라이언트가 서브리미널 메시지를 표시할 수 있는 옵션을 설명하는 RFC 1097의 게시와 함께 재개되었다. 이후 만우절 RFC는 매년 게시되었으며, 특히 하이퍼텍스트 커피 포트 제어 프로토콜을 설명하고 HTTP 418 "나는 찻주전자이다(I'm a teapot)" 상태 코드를 정의한 RFC 2324가 유명하다. 유머러스한 RFC는 1973년 1월에 게시된 RFC 439까지 거슬러 올라간다.

RFC 편집자 기능

[편집]

1969년부터 1998년까지 존 포스텔이 RFC 편집자로 활동했다. 1998년 그가 사망하자 그의 부고가 RFC 2468로 게시되었다.[12]

미국 연방 정부와의 원래 아파넷 계약이 만료된 후, 인터넷 협회는 IETF를 대신하여 서던캘리포니아 대학교(USC) 정보 과학 연구소(ISI)의 네트워킹 부서와 계약을 맺고 IAB의 지휘 아래 편집 및 출판 책임을 맡도록 했다. 샌디 기노자가 1999년 USC/ISI에 합류하여 RFC 편집 작업을 수행했고, 2005년에는 앨리스 헤이건스가 합류했다.[13] 밥 브레이든이 RFC 프로젝트 리드 역할을 맡았으며, 조이스 K. 레이놀즈는 2006년 10월 13일까지 팀의 일원으로 남았다.

2007년 7월, 편집 업무를 분담하기 위해 RFC 스트림이 정의되었다. IETF 문서는 IETF 실무단이나 인터넷 엔지니어링 운영 그룹의 IETF 영역 책임자가 후원하는 제출물에서 나왔다. IAB는 자체 문서를 게시할 수 있다. 문서의 연구 스트림은 인터넷 연구 태스크 포스(IRTF)에서 나오며, 독립적인 스트림은 다른 외부 출처에서 나온다.[14] 2008년에 새로운 모델이 제안 및 개선되어 2009년 8월에 게시되었으며, RFC 시리즈 자문 그룹(RSAG)을 포함하여 여러 역할로 업무를 분할했다.[15] 이 모델은 2012년[16] 및 2020년에 업데이트되었다.[17] 스트림은 2009년 12월에도 개선되었으며, 스타일 표준이 정의되었다.[18] 2010년 1월, RFC 편집자 기능은 계약업체인 Association Management Solutions로 이전되었으며, 글렌 코왁이 임시 시리즈 편집자를 맡았다.[19] 2011년 말, 헤더 플래너건이 상임 RFC 시리즈 편집자(RSE)로 고용되었다. 그 시기에 RFC 시리즈 감독 위원회(RSOC)도 구성되었다.[20]

2020년, IAB는 RFC 편집자 모델에 대한 잠재적 변경 사항을 논의하기 위해 'RFC 편집자 미래 개발 프로그램'을 소집했다. 프로그램 결과는 2022년 6월에 게시된 RFC 9280에 정의된 RFC 편집자 모델(버전 3)에 포함되었다.[1] 일반적으로 새 모델은 RFC 시리즈 및 RFC 편집자 기능과 관련된 정책을 정의하고 구현하기 위한 책임과 프로세스를 명확히 하는 것을 목표로 한다. 새 모델의 변경 사항으로는 RFC 컨설팅 편집자, RFC 시리즈 실무 그룹(RSWG), RFC 시리즈 승인 위원회(RSAB) 직책 신설이 포함되었다. 또한 RFC 시리즈를 위한 새로운 편집 스트림을 구축하고 RSOC를 종료했다. RSE의 역할은 RFC 시리즈 컨설팅 편집자(RSCE)로 변경되었다. 2022년 9월, 알렉시스 로시가 해당 직책에 임명되었다.[21]

새로운 출판 형식

[편집]

RFC는 원래 재조판 불가능한 텍스트 형식으로 제작되었다. 2019년 8월, 다양한 화면 크기를 가진 장치에서 문서를 최적으로 볼 수 있도록 형식이 변경되었다.[22]

생산 및 버전 관리

[편집]

RFC 편집자는 각 RFC에 일련번호를 할당한다. 번호가 할당되고 게시되면 RFC는 폐기되거나 수정되지 않는다. 문서에 수정이 필요한 경우 저자는 개정된 문서를 게시한다. 따라서 일부 RFC는 다른 RFC를 대체하며, 대체된 RFC는 더 이상 사용되지 않거나(deprecated), 쓸모없게 되거나(obsolete), 대체 RFC에 의해 폐기된 것으로 간주된다. 직렬화된 RFC는 인터넷 표준과 관행의 진화에 대한 연속적인 역사적 기록을 구성한다. RFC 프로세스는 RFC 2026(인터넷 표준 프로세스, 개정 3)에 문서화되어 있다.[23]

RFC 생산 프로세스는 국제 표준화 기구(ISO)와 같은 공식 표준 기관의 표준화 프로세스와 다르다. 인터넷 기술 전문가는 외부 기관의 지원 없이 인터넷 드래프트를 제출할 수 있다. 표준 트랙 RFC는 IETF의 승인을 받아 게시되며, 일반적으로 인터넷 드래프트를 먼저 게시하는 IETF 실무단에 참여하는 전문가들이 제작한다. 이러한 접근 방식은 문서가 RFC로 성숙해지기 전에 초기 동료 평가 과정을 촉진한다.[24]

개인이나 소규모 실무단에 의해 수행되는 실용적이고 경험 중심적이며 사후적인 표준 저작이라는 RFC의 전통은 ISO나 국가 표준 기구에서 흔히 볼 수 있는 보다 형식적이고 위원회 중심적인 프로세스보다 중요한 이점을 가질 수 있다.[25]

대부분의 RFC는 RFC의 일관성을 유지하고 이해하기 쉽게 하기 위해 "MUST" 및 "NOT RECOMMENDED"와 같은 공통 용어 세트(RFC 2119 and 8174에 정의됨), 메타 언어로서의 확장 배커스-나우르 표기법(ABNF)(RFC 5234), 그리고 간단한 텍스트 기반 형식을 사용한다.[23]

하위 시리즈

[편집]

RFC 시리즈에는 국제 인터넷 표준화 기구(IETF) RFC를 위한 세 가지 하위 시리즈인 BCP, FYI, STD가 포함되어 있다. BCP(Best Current Practice)는 표준 트랙에 있지 않은 필수 IETF RFC의 하위 시리즈이다. FYI(For Your Information)는 RFC 1150(FYI 1)에 명시된 대로 IETF가 권장하는 정보 제공용 RFC의 하위 시리즈이다. 2011년 RFC 6360가 FYI 1을 쓸모없게 만들고 이 하위 시리즈를 종료했다. STD(Standard)는 RFC 2026(BCP 9)에 명시된 IETF 표준 트랙의 세 번째이자 가장 높은 성숙도 수준이었다. 2011년 RFC 6410(BCP 9의 새로운 부분)는 표준 트랙을 두 가지 성숙도 수준으로 축소했다.

스트림

[편집]

RFC에는 국제 인터넷 표준화 기구(IETF), 인터넷 연구 태스크 포스(IRTF), 인터넷 아키텍처 위원회(IAB), 독립 제출,[26] 그리고 편집이라는 다섯 가지 스트림이 있다. IETF만이 표준 트랙에서 BCP와 RFC를 생성한다. IAB는 정책이나 아키텍처와 관련된 정보 제공용 문서를 게시한다. IRTF는 연구 결과를 정보 제공용 문서나 실험으로 게시한다. 독립 제출물은 독립 제출 편집자의 재량에 따라 게시된다. 비 IETF 문서는 IETF 작업과의 충돌 여부를 IESG가 검토한다. IRTF 및 독립 RFC는 일반적으로 IETF 작업과 충돌하지 않는 전반적인 인터넷을 위한 관련 정보나 실험을 포함한다. RFC 4846, 5742 and 5744와 비교하라.[27][28] 편집 스트림은 RFC 시리즈 전반에 걸쳐 편집 정책 변경을 수행하는 데 사용된다(RFC 9280 참조).[1]

RFC 획득

[편집]
RFC 2046 미디어 타입 1996년 11월
 A. 수집된 문법 .................................... 43
1. 서론
 이 세트의 첫 번째 문서인 RFC 2045는 Content-Type을 포함한 여러 헤더 필드를 정의한다.
 Content-Type 필드는 미디어 타입과 서브타입 식별자를 제공하고,
 특정 미디어 타입에 필요할 수 있는 보조 정보를 제공함으로써,
 MIME 엔티티 본문에 있는 데이터의 성격을 지정하는 데 사용된다. 이후
MIME 타입인 text/plain을 정의하는 RFC 2046는 그 자체로 일반 텍스트이다.

월드 와이드 웹에서 RFC의 공식 소스는 RFC Datatracker이다. 거의 모든 게시된 RFC는 RFC 5000의 예시와 같이 https:​//datatracker​.ietf​.org​/doc​/html​/rfc5000 형태의 URL을 통해 검색할 수 있다.

모든 RFC는 일반 ASCII 텍스트로 제출되어 해당 형식으로 게시되지만, 다른 파일 형식으로도 제공될 수 있다.

초록, 키워드, 저자, 게시 날짜, 정오표, 상태, 그리고 특히 이후 업데이트를 포함한 RFC의 메타데이터에 쉽게 접근하기 위해 RFC 편집자 사이트는 많은 기능을 갖춘 검색 양식을 제공한다. 리디렉션은 rfc:5000과 같은 효율적인 매개변수를 설정한다.[4]

RFC 시리즈의 공식 국제 표준 일련 번호(ISSN)는 2070-1721이다.[18]

상태

[편집]

모든 RFC가 표준인 것은 아니다.[29] 각 RFC에는 인터넷 표준화 프로세스 내에서의 상태와 관련하여 지정 항목이 할당된다. 이 상태는 Informational(정보 제공용), Experimental(실험적), Best Current Practice(최선의 현재 관행), Standards Track(표준 트랙), Historic(역사적) 중 하나이다.[4]

일단 제출되고 수락되어 게시되면 RFC는 변경될 수 없다. 정오표는 별도로 게시될 수 있다. 더 중요한 변경 사항은 새로운 일련번호를 받는 새로운 제출이 필요하다.[30]

표준 트랙

[편집]

표준 트랙 문서는 추가로 Proposed Standard(제안된 표준)와 Internet Standard(인터넷 표준) 문서로 나뉜다.[31]

인터넷 엔지니어링 운영 그룹(IESG)이 대표하는 IETF만이 표준 트랙 RFC를 승인할 수 있다.

RFC가 인터넷 표준(STD)이 되면 STD 번호가 할당되지만 RFC 번호는 유지된다. 인터넷 표준의 최종 목록은 공식 인터넷 프로토콜 표준이다. 이전에는 STD 1이 해당 목록의 스냅샷을 유지했었다.[32]

인터넷 표준이 업데이트되면 STD 번호는 그대로 유지되면서 새로운 RFC 또는 RFC 세트를 참조하게 된다. 특정 시점에 인터넷 표준 STD n은 RFC x와 y일 수 있지만, 나중에 동일한 표준이 RFC z로 업데이트될 수 있다. 예를 들어, 2007년에 RFC 3700는 인터넷 표준(STD 1)이었으나 2008년 5월에 RFC 5000로 대체되었고, 이에 따라 RFC 3700는 Historic으로 변경되고 RFC 5000가 인터넷 표준이 되었으며, 2008년 05월 기준 STD 1은 RFC 5000가 되었다. 2013년 12월 기준 RFC 5000는 RFC 7100로 대체되어 RFC 2026가 더 이상 STD 1을 사용하지 않도록 업데이트되었다.

(Best Current Practice도 유사하게 작동한다. BCP n은 특정 RFC 또는 RFC 세트를 참조하지만, 어떤 RFC가 해당되는지는 시간이 지남에 따라 변경될 수 있다.)

정보 제공용

[편집]

정보 제공용 RFC는 만우절 RFC부터 도메인 네임 시스템 구조 및 위임(RFC 1591)과 같이 널리 인정되는 필수 RFC에 이르기까지 거의 모든 것이 될 수 있다. 일부 정보 제공용 RFC는 FYI 하위 시리즈를 구성했다.

실험적

[편집]

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

최선의 현재 관행

[편집]

최선의 현재 관행(Best Current Practice, BCP) 하위 시리즈는 공식적인 규칙으로 간주되는 행정 문서 및 기타 텍스트를 수집하며, 이는 단순히 정보 제공용일 뿐만 아니라 데이터 전송에는 영향을 주지 않는다. 표준 트랙과 BCP 사이의 경계는 종종 불분명하다. BCP 9[34]나 IETF 행정과 같이 인터넷 표준 프로세스에만 영향을 미치는 문서는 분명히 BCP이다. IANA 레지스트리에 대한 규칙과 규정만 정의하는 경우에는 덜 명확하며, 이러한 문서의 대부분은 BCP이지만 일부는 표준 트랙에 있다.

BCP 시리즈는 또한 인터넷 표준을 실천하는 방법에 대한 기술적 권장 사항을 다룬다. 예를 들어, DoS 공격을 어렵게 만들기 위해 소스 필터링을 사용하라는 권장 사항(RFC 2827: "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing")은 BCP 38이다.

역사적

[편집]

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

알 수 없음

[편집]

'알 수 없음' 상태는 오늘날 게시된다면 어떤 상태를 가질지 불분명한 매우 오래된 일부 RFC에 사용된다. 이러한 RFC 중 일부는 오늘날에는 전혀 게시되지 않을 것이다. 초기 RFC는 종종 그 이름 그대로, 프로토콜이나 행정 절차, 또는 오늘날 RFC 시리즈가 사용되는 어떤 것을 명시하기 위한 의도가 아닌 단순한 의견 요청(Request for Comments)이었다.[36]

저작권

[편집]

일반적인 규칙은 원저자(또는 고용 조건에 명시된 경우 고용주)가 명시적인 권리 이전을 하지 않는 한 저작권을 보유한다는 것이다.[37]

독립 기관인 IETF Trust는 일부 RFC에 대한 저작권을 보유하며, 다른 모든 RFC에 대해서는 저자로부터 RFC를 복제할 수 있는 라이선스를 부여받는다.[38] 인터넷 협회는 RFC4714 이전의 많은 RFC에서 저작권 소유자로 언급되어 있지만, 권리를 IETF Trust로 이전했다.[39]

같이 보기

[편집]

각주

[편집]
  1. 1 2 3 P. Saint-Andre, ed. (June 2022). RFC Editor Model (Version 3). Internet Architecture Board. ISSN 2070-1721. RFC 9280. https://tools.ietf.org/html/rfc9280. Informational. Obsoleted by RFC 9920. Updated by RFC 9720. Obsoletes RFC 8728. Updates RFC 7841, 8729 and 8730.
  2. ↑ “RFCs” (영어). 《IETF》. 2023년 11월 5일에 확인함.
  3. ↑ Waitzman, David (April 1, 1990). A Standard for the Transmission of IP Datagrams on Avian Carriers. 국제 인터넷 표준화 기구. RFC 1149. https://tools.ietf.org/html/rfc1149. Retrieved March 29, 2017.
  4. 1 2 3 C. Huitema; J. Postel; S. Crocker (April 1995). Not All RFCs are Standards. Network Working Group. RFC 1796. https://tools.ietf.org/html/rfc1796. Informational.
  5. ↑ “RFC's, Internet Request For Comments”. Livinginternet.com. 2012년 4월 3일에 확인함.
  6. 1 2 “Stephen D. Crocker, How the Internet Got Its Rules, The New York Times, 6 April 2009”. 《뉴욕 타임스》. 2009년 4월 7일. 2012년 4월 3일에 확인함.
  7. ↑ “Notice and Request for Comments”. 《연방 관보》. 2018년 1월 16일.
  8. ↑ Hafner, Katie; Lyon, Matthew (1996). 《Where Wizards Stay Up Late: The Origins of the Internet》. A Touchstone book. Simon & Schuster. ISBN 978-0-684-81201-4.
  9. ↑ Metz, Cade (2012년 5월 18일). “Meet the man who invented the instructions for the Internet”. 《Wired》. 2018년 12월 18일에 확인함.
  10. ↑ S. Crocker, ed. (7 April 1969). Host Software. Network Working Group. RFC 1. https://tools.ietf.org/html/rfc1. Status Unknown.
  11. ↑ Elizabeth J. Feinler (July–September 2010). “The Network Information Center and its Archives”. 《Annals of the History of Computing》 32 (3): 83–89. doi:10.1109/MAHC.2010.54. S2CID 206443021.
  12. ↑ V. Cerf (October 17, 1998). I Remember IANA. Network Working Group. RFC 2468. https://tools.ietf.org/html/rfc2468. Informational.
  13. ↑ Leslie Daigle (March 2010). “RFC Editor in Transition: Past, Present, and Future”. 《The Internet Protocol Journal》 13 (1) (Cisco Systems). 2010년 9월 20일에 원본 문서에서 보존된 문서. 2011년 8월 17일에 확인함.
  14. ↑ L. Daigle, ed. (April 2007). The RFC Series and RFC Editor. Network Working Group. RFC 4844. https://tools.ietf.org/html/rfc4844. Obsolete. Obsoleted by RFC 8729. Updated by RFC 5741.
  15. ↑ O. Kolkman, ed. (August 2009). RFC Editor Model (Version 1). Internet Architecture Board. RFC 5620. https://tools.ietf.org/html/rfc5620. Obsolete. Obsoleted by RFC 6635 and 6548.
  16. ↑ O. Kolkman; J. Halpern, eds. (June 2012). RFC Editor Model (Version 2). Internet Architecture Board. RFC 6635. https://tools.ietf.org/html/rfc6635. Obsolete. Obsoleted by RFC 8728. Obsoletes RFC 5620.
  17. ↑ O. Kolkman; J. Halpern; R. Hinden, eds. (February 2020). RFC Editor Model (Version 2). Internet Architecture Board. RFC 8728. https://tools.ietf.org/html/rfc8728. Informational. Obsoleted by RFC 9280. Obsoletes RFC 6635.
  18. 1 2 A. Falk (December 2009). RFC Streams, Headers, and Boilerplates. Internet Research Task Force. ISSN 2070-1721. RFC 5741. https://tools.ietf.org/html/rfc5741. Obsolete. Obsoleted by RFC 7841. Updates RFC 2223, 4844.
  19. ↑ Glenn Kowack (2010년 1월 7일). “RFC Editor Transition Announcement”. 2011년 6월 29일에 원본 문서에서 보존된 문서.
  20. ↑ “The RFC Series Editor and the Series Reorganization”. 2013년 4월 5일에 원본 문서에서 보존된 문서. 2013년 4월 5일에 확인함.
  21. ↑ “Alexis Rossi appointed as RFC Series Consulting Editor”. 2022년 9월 1일. 2023년 8월 19일에 확인함.
  22. ↑ “RFC Format Change FAQ”. 《RFC Editor》. 2021년 1월 27일. 2026년 5월 11일에 원본 문서에서 보존된 문서.
  23. 1 2 “RFC Index”. RFC Editor. 2008년 5월 25일. 2008년 5월 26일에 확인함.
  24. ↑ IETF Working Group Guidelines and Procedures. RFC 2418. https://tools.ietf.org/html/rfc2418.
  25. ↑
    이 문서에는 GFDL 라이선스로 배포된 자유 온라인 컴퓨팅 사전(FOLDOC)의 내용을 기초로 작성된 내용이 포함되어 있습니다.
  26. ↑ “Independent Submissions”. RFC Editor. 2018년 1월 5일에 확인함.
  27. ↑ Klensin, John; Thaler, David (July 2007). Independent Submissions to the RFC Editor. IAB. RFC 4846. https://tools.ietf.org/html/rfc4846.>
  28. ↑ Alvestrand, Harald; Housley, Russ (December 2009). IESG Procedures for Handling of Independent and IRTF Stream Submissions. 국제 인터넷 표준화 기구. RFC 5742. https://tools.ietf.org/html/rfc5742.
  29. ↑ “Are all RFCs Internet standards documents?”. RFC Editor. 2018년 3월 16일에 확인함.
  30. ↑ Nottingham, Mark (2018년 7월 31일). “How to Read an RFC”. 2023년 9월 18일에 확인함. RFCs are an archival series of documents; they can't change[.]
  31. ↑ Housley, Russell; Crocker, Dave; Burger, Eric (October 2011). Reducing the Standards Track to Two Maturity Levels. 국제 인터넷 표준화 기구. RFC 6410. https://tools.ietf.org/html/rfc6410.
  32. ↑ Retirement of the "Internet Official Protocol Standards" Summary Document. RFC 7100. https://tools.ietf.org/html/rfc7100.
  33. ↑ 〈7.5. Informational and Experimental RFCs〉. 《The Tao of IETF》. 2017년 11월 26일에 확인함.
  34. ↑ Bradner, Scott O. (October 1996). The Internet Standards Process – Revision 3. 국제 인터넷 표준화 기구. BCP 9. https://tools.ietf.org/html/bcp9. Retrieved October 25, 2017.
  35. ↑ “IESG Statement on Designating RFCs as Historic”. 국제 인터넷 표준화 기구. 2014년 7월 20일. 2016년 4월 14일에 확인함.
  36. ↑ “IETF Standards Written by ISC Contributors”. 인터넷 시스템 컨소시엄. 2021년 9월 10일. 2022년 4월 5일에 원본 문서에서 보존된 문서. 2022년 4월 11일에 확인함. Many of the early RFC documents have status "unknown" because they come from the long-gone era when an RFC really was just a request for comments.
  37. ↑ “Reproducing RFCs”. IETF Trust. 2021년 8월 12일에 확인함.
  38. ↑ Bradner, Scott; Contreras, Jorge (November 2008). Rights Contributors Provide to the IETF Trust. 국제 인터넷 표준화 기구. RFC 5378. https://tools.ietf.org/html/rfc5378.
  39. ↑ “Copyright and IETF Copyright Policies”. IETF Trust. 2021년 8월 13일에 확인함.

외부 링크

[편집]
이 문서에는 한국 인터넷 역사 프로젝트에서 CC-BY 2.0 라이선스로 배포한 "한국 인터넷의 역사 - 되돌아보는 20세기 -"의 내용을 기초로 작성된 글이 포함되어 있습니다. (정보)
원본 주소 "https://ko.wikipedia.org/w/index.php?title=RFC&oldid=42320722"