코멘트 요구

Request for Comments
Wikipedia 프로세스에 대해서는 Wikipedia를 참조하십시오.코멘트 요청

댓글 요구(RFC)는 인터넷 기술 개발 및 표준 제정 주요 기관, 특히 Internet Engineering Task Force(IETF; 인터넷 기술 특별 조사위원회)에서 제공하는 일련의 간행물입니다.RFC는 개인 또는 엔지니어 및 컴퓨터 과학자에 의해 인터넷 및 인터넷에 연결된 시스템의 작업에 적용되는 방법, 행동, 연구 또는 혁신을 기술하는 메모 형식으로 작성됩니다.이 문서는 동료 검토를 위해 제출되거나 새로운 개념, 정보 또는 때로는 엔지니어링 [1]유머를 전달하기 위해 제출됩니다.

IETF는 RFC로 발행된 제안 중 일부를 인터넷 표준으로 채택하고 있습니다.단, 많은 RFC는 정보성이 있거나 실험적인 것으로 [2]표준이 아닙니다.RFC 시스템은 1969년 스티브 크로커에 의해 발명되어 ARPANET의 개발에 관한 비공식적인 메모를 기록하는 것을 돕고 있다.RFC는 인터넷 사양, 통신 프로토콜, 절차 및 [3]이벤트의 공식 문서가 되었다.크로커에 따르면, 이 문서들은 "인터넷의 내부 기능을 형성하고 그 성공에 중요한 역할을 해왔다"고 하지만 커뮤니티 [4]밖에서는 널리 알려지지 않았다.

인터넷 커뮤니티 밖에서는 미국 연방정부 업무에서 코멘트 요청이라고도 불리는 미국 고속도로 교통안전국(National Highway Traffic Safety Administration)[5]과 같은 다른 문서들도 발행되고 있다.

역사

RFC 포맷의 시작은 1969년 ARPANET 프로젝트의 [4]일환으로 이루어졌다.현재는 Internet Engineering Task Force(IETF; 인터넷 기술 특별 조사위원회), Internet Architecture Board(IAB; 인터넷 아키텍처 위원회) 및 글로벌 네트워크 연구자 커뮤니티의 공식 출판 채널입니다.

첫 번째 RFC의 저자들은 그들의 작품을 타이핑하여 ARPA 연구자들에게 하드 카피를 배포했다.현대의 RFC와는 달리 초기 RFC의 대부분은 실제 코멘트의 요구로 너무 선언적으로 들리지 않도록 제목을 붙였습니다.[6][7]RFC는 질문을 보류한 채 형식적이지 않은 스타일로 기술되어 있습니다.이 형식적이지 않은 스타일은 인터넷 초안 문서의 일반적인 형태로, RFC로 승인되기 전의 전 단계입니다.

1969년 12월, 연구진은 새롭게 가동되는 ARPANET을 통해 새로운 RFC를 배포하기 시작했습니다.RFC 1은 캘리포니아 대학 로스앤젤레스(UCLA)의 스티브 크로커에 의해 작성되어 1969년 [8]4월 7일에 출판되었습니다.RFC는 Steve Crocker에 의해 작성되었지만 Steve Crocker, Steve Carr 및 Jeff Rulifson의 초기 작업 그룹 토론에서 나왔습니다.

RFC 시리즈를 최초로 정의한 RFC 3에서는 크로커는 RFC 시리즈를 Network Working Group에 귀속시키기 시작했습니다.정식 위원회라기보다는 ARPANET 프로젝트에 관심이 있는 연구자들의 느슨한 모임이었다.사실상, 그 프로젝트에 관한 회의와 토론에 참석하고 싶은 사람은 누구나 포함되었습니다.

UCLA는 ARPANET의 첫 번째 인터페이스 메시지 프로세서(IMP) 중 하나이기 때문에 1970년대 이후 많은 RFC도 UCLA에서 나왔습니다.스탠포드 연구소의 증강 연구 센터(ARC)는 더글라스 엔젤바트가 지휘하고 있으며, ARPANET 노드 및 초기 RFC의 소스 중 하나이며, 4개의 첫 번째 노드 중 하나입니다.ARC는 Elizabeth J. Feinler가 관리하는 최초의 Network Information Center(InterNIC; 네트워크 정보 센터)가 되었습니다.이 센터는 다른 네트워크 [9]정보와 함께 RFC를 배포하는 것입니다.1969년부터 1998년까지 Jon Postel은 RFC 편집장을 역임했습니다.1998년 그가 사망하자 그의 부고는 RFC 2468로 발행되었다.

미국 연방정부와의 원래 ARPANET 계약이 만료됨에 따라 IETF를 대신하여 Internet Society는 Southern California 대학(USC) 정보과학 연구소(ISI)의 네트워크 부문과 계약하여 편집 및 출판 책임을 맡았습니다.e IAB. Sandy Ginoza는 1999년에 USC/ISI에 입사하여 RFC 편집에 임했으며 2005년에는 [10]Alice Hagens에 입사했습니다.밥 브래든이 RFC 프로젝트 리더 역할을 맡았고, 조이스 K가 그 역할을 맡았다. 레이놀즈는 2006년 10월 13일까지 팀의 일원이었다.

2007년 7월에는 편집 업무를 분할할 수 있도록 RFC 스트림이 정의되었습니다.IETF 문서는 IETF 워킹그룹 또는 Internet Engineering Steering Group의 IETF 지역 디렉터가 후원하는 제출물입니다.IAB는 자체 문서를 게시할 수 있습니다.문서의 연구 스트림은 Internet Research Task Force(IRTF; 인터넷 조사 태스크포스)에서 제공되며,[11] 다른 외부 소스로부터 독립된 스트림으로 제공됩니다.새로운 모델은 2008년에 제안되어 2009년 8월에 개정되어 발표되었습니다.이러한 작업은 RFC 시리즈 어드바이저리 그룹(RSAG)을 포함한 여러 [12]역할로 분할됩니다.이 모델은 [13]2012년에 업데이트되었습니다.또한 2009년 12월 스트림은 [14]스타일에 맞게 규격이 정의되어 개량되었습니다.2010년 1월, RFC Editor 기능은 계약자인 Association Management Solutions로 옮겨졌으며, Glenn Kowack은 임시 시리즈 [15]에디터를 맡고 있습니다.2011년 말, Heather Flanagan은 RFC 시리즈의 상설 에디터로 채용되었습니다.또한 RFC 시리즈 감시 위원회([16]RSOC)가 창설되었습니다.

2020년에 IAB는 RFC Editor 모델의 변경 가능성을 논의하기 위해 RFC Editor Future Development 프로그램을 소집했습니다.프로그램의 결과에는 2022년 6월에 발행된 RFC 9280에 정의된 RFC Editor Model(버전 3)이 포함되어 있습니다.일반적으로 새로운 모델은 RFC 시리즈 및 RFC Editor 기능과 관련된 정책을 정의 및 구현하기 위한 책임과 프로세스를 명확히 하기 위한 것입니다.새로운 모델의 변경에는 RFC Consulting Editor, RFC Series Working Group(RSWG; RFC 시리즈 워킹 그룹) 및 RFC Series Approval Board(RSAB; RFC 시리즈 승인 위원회)의 포지션 확립이 포함됩니다.또, RFC 시리즈의 새로운 편집 스트림을 확립해, RSOC를 종료했습니다.

코멘트 요청은 원래 리플로우할 수 없는 텍스트 형식으로 작성되었습니다.2019년 8월 디스플레이 [17]크기가 다양한 기기에서 새로운 문서를 최적으로 볼 수 있도록 형식이 변경되었습니다.

실가동 및 버전 관리

RFC Editor는 각 RFC에 시리얼 번호를 할당합니다.번호를 할당하고 공개하면 RFC는 취소 또는 수정되지 않습니다.문서에 수정이 필요한 경우 작성자는 수정된 문서를 공개합니다.따라서 일부 RFC는 다른 RFC보다 우선합니다.대체된 RFC는 대체 RFC에 의해 폐지, 폐지 또는 폐지된 것으로 알려져 있습니다.시리얼화된 RFC는 함께 인터넷 표준과 관행의 진화에 대한 지속적인 역사적 기록을 구성합니다.RFC 프로세스는 RFC 2026(인터넷 표준 프로세스, 리비전 [18]3)에 기재되어 있습니다.

RFC의 작성 프로세스는 국제표준화기구(ISO)와 같은 정식 표준조직의 표준화 프로세스와는 다릅니다.인터넷 기술 전문가는 외부 기관의 지원 없이 인터넷 초안을 제출할 수 있습니다.표준 트랙 RFC는 IETF의 승인을 받아 발행되며, 보통 IETF 작업 그룹에 참여하는 전문가가 작성하며, 이 작업 그룹은 인터넷 초안을 최초로 발행합니다.이 어프로치를 사용하면 문서가 [citation needed]RFC로 성숙하기 전에 피어 리뷰의 초기 라운드가 쉬워집니다.

개인 또는 소규모 작업 그룹에 의해 달성되는 실용적이고 경험 중심적인 사후 표준 작성자의 RFC 전통은 ISO 및 국가 표준 기구의 [citation needed]전형적인 보다 공식적이고 위원회 중심적인 프로세스보다 중요한 이점을[clarification needed] 가질 수 있습니다.

대부분의 RFC에서는 RFC의 일관성을 [18]유지하고 이해하기 쉽게 하기 위해 MUST 및 NOT Recommended(RFC 2119 및 RFC 8174에서 정의), 증강 Backus-Naur 형식(ABNF)(RFC 5234) 등의 공통 용어를 사용합니다.

서브시리즈

RFC 시리즈에는 IETF RFC의 3개의 서브 시리즈(BCP, FYI 및 STD)가 있습니다.Best Current Practice(BCP)는 표준 트랙에 없는 필수 IETF RFC 서브시리즈입니다.For Your Information(FYI)은 RFC 1150(FYI 1)에 규정되어 있듯이 IETF에 의해 추진되는 정보 RFC의 서브시리즈입니다.2011년에 RFC 6360은 FYI 1을 폐지하고 이 서브 시리즈를 종료했습니다.Standard(STD; 표준)는 RFC 2026(BCP 9)에 규정되어 있는IETF 표준 트랙의 세 번째 및 가장 높은 성숙도 수준이었습니다.2011년 RFC 6410(BCP 9의 새로운 부분)에서는 표준 트랙을 2개의 성숙도로 [citation needed]줄였습니다.

스트림

RFC에는 IETF, IRTF, IAB 및 독립 [19]전송의 4가지 스트림이 있습니다.표준 트랙에 BCP 및 RFC를 작성하는 것은 IETF뿐입니다.IESG는 IETF 작업과의 충돌 여부를 독립 제출물에 의해 체크하고, 품질은 독립 제출물 편집위원회에 의해 평가된다.즉, IRTF 및 독립 RFC에는 IETF 작업과 경합하지 않고 인터넷에 관한 관련 정보 또는 실험이 포함되어 있어야 합니다.RFC 4846, RFC 5742 및 RFC 5744를 [citation needed]비교합니다.

RFC 취득

RFC 2046 미디어 유형 1996년 11월A.문법 수집 .............................................. 43 1.개요 이 세트의 첫 번째 문서인 RFC 2045에서는 Content-Type을 포함한 다수의 헤더필드가 정의되어 있습니다.[ Content - Type ]필드는 미디어 유형과 서브타입 식별자를 지정하고 특정 미디어 유형에 필요한 보조 정보를 제공함으로써 MIME 엔티티 본체의 데이터 특성을 지정하기 위해 사용합니다.그 후
 텍스트/플레인 MIME 유형을 정의하는 RFC2046은 그 자체로 플레인텍스트입니다

World Wide Web 상의 RFC 공식 소스는 RFC Editor 입니다.공개된 거의 모든 RFC는 RFC 5000에 표시된 http://www.rfc-editor.org/rfc/rfc5000.txt, 형식의 URL을 통해 취득할 수 있습니다.

모든 RFC는 플레인 ASCII 텍스트로 전송되며 해당 형식으로 공개되지만 다른 형식으로도 사용할 수 있습니다.

추상, 키워드, 작성자, 발행일, 에라타, 상태, 특히 그 후의 갱신 등 RFC의 메타데이터에 간단하게 액세스 할 수 있도록, RFC Editor 사이트에는 다양한 기능을 갖춘 검색 폼이 준비되어 있습니다.리다이렉션은 rfc:5000 [citation needed]등의 효율적인 파라미터를 설정합니다.

RFC 시리즈의 공식 International Standard Serial Number(ISSN; 국제표준 시리얼 번호)는 2070 ~1721 입니다.[14]

상황

모든 RFC가 [20][21]표준인 것은 아닙니다.각 RFC에는 인터넷 표준화 프로세스 내의 상태에 관한 지정이 할당되어 있습니다.이 상태는 다음 중 하나입니다.정보, 실험, 현재 베스트 프랙티스, 표준 트랙 또는 이력.

각 RFC는 스태틱합니다.문서가 변경되면 문서가 다시 전송되고 새로운 RFC [citation needed]번호가 할당됩니다.

표준 트랙

주요 기사:인터넷 표준 » 인터넷 표준

표준 트랙 문서는 제안된 표준 [22]문서와 인터넷 표준 문서로 더 세분화됩니다.

Internet Engineering Steering Group(IESG; 인터넷엔지니어링 스티어링 그룹)으로 대표되는 IETF만이 표준 트랙 RFC를 승인할 수 있습니다.

RFC가 Internet Standard(STD; 인터넷표준)가 되면 STD 번호는 할당되지만 RFC 번호는 유지됩니다.인터넷 표준의 최종 목록은 공식 인터넷 프로토콜 표준입니다.이전에는 [23]목록의 스냅샷을 유지하기 위해 STD 1이 사용되었습니다.

인터넷 표준이 갱신되면 그 STD 번호는 그대로 유지되며 새로운 RFC 또는 RFC 세트를 참조합니다.특정 인터넷 표준(STD n)은 특정 시간에 RFC x 및 y가 될 수 있지만 나중에 같은 표준이 RFC z로 업데이트될 수 있습니다.예를 들어 2007년에는 RFC 3700이 인터넷 표준이었습니다.2008년 5월에 RFC 5000으로 대체되었기 때문에 RFC 3700은 Historic으로 변경되어 RFC 5000은 Internet Standard로 변경되었으며 2008년 5월부터는 RFC 5000이 RFC 7100으로 대체되어 RFC 2026은 STD 1을 사용하지 않게 되었습니다.

(현재의 베스트프랙티스도 같은 방법으로 동작합니다.BCP n은 특정 RFC 또는 RFC 세트를 가리킵니다만, 시간이 지남에 따라 RFC 또는 RFC가 변경될 가능성이 있습니다).

정보

정보 RFC는 4월1일 농담부터 Domain Name System Structure and Delegation(RFC 1591) 등 널리 알려진 필수 RFC까지 거의 모든 것이 될 수 있습니다.일부 정보 RFC가 서브 시리즈를 형성하고 있습니다.

실험적인

실험 RFC는 IETF 문서 또는 RFC Editor에 대한 개별 제출입니다.초안은 제안이 의도한 대로 작동할 것인지 또는 제안이 널리 채택될 것인지 불분명한 경우 실험적으로 지정된다.실험용 RFC가 널리 보급되고 [24]잘 작동하면 표준 트랙으로 승격될 수 있습니다.

현재의 베스트 프랙티스

Best Current Practice 하위 시리즈는 공식 규칙으로 간주되며 정보뿐만 아니라 유선 데이터에도 영향을 미치지 않는 관리 문서 및 기타 텍스트를 수집합니다.표준 트랙과 BCP 사이의 경계는 종종 불분명합니다.BCP [25]9 또는 IETF 관리 등 Internet Standards Process에만 영향을 주는 문서는 분명히 BCP입니다.Internet Assigned Numbers Authority(IANA; 인터넷 할당 번호 기관) 레지스트리에 대한 규칙 및 규정만 정의하면 명확성이 떨어집니다.이러한 문서의 대부분은 BCP이지만 표준 트랙에 있는 것도 있습니다.

BCP 시리즈에서는, 인터넷 표준의 실천 방법에 관한 기술적인 권장 사항도 다루고 있습니다.예를 들면, 소스 필터링을 사용해 DoS 공격을 보다 어렵게 하는 권장 사항(RFC 2827: 「네트워크 입력 필터링: 「IP 송신원주소 스푸핑」을 채용한 서비스 거부 공격을 물리치는 것은 BCP 38입니다.

이력

이력 RFC란 RFC에 의해 정의되어 있는 테크놀로지의 사용을 권장하지 않는 것으로, 치환 RFC의 「Obsoletes」헤더와는 다릅니다.예를 들어 RFC 821(SMTP) 자체는 다양한 새로운 RFC에 의해 폐지되지만 SMTP 자체는 여전히 "현재 기술"이기 때문에 "이력" [26]상태가 아닙니다.단, BGP 버전4는 이전 BGP 버전을 완전히 대체하고 있기 때문에 RFC 1267 등 이전 버전을 기술하는 RFC는 이력이라고 지정되어 있습니다.

알 수 없는

상태가 불명확한 것은 매우 오래된 RFC에 사용되고 있습니다.이 RFC에서는 문서가 오늘 공개되었을 때 어떤 상태가 될지가 불명확합니다.이러한 RFC의 일부는 현재 전혀 공개되지 않았습니다.이전 RFC는 단순한 코멘트의 요구였을 뿐, 현재 [27]RFC 시리즈가 사용되고 있는 프로토콜, 관리 절차 또는 그 외의 것을 지정하는 것을 목적으로 하고 있지 않습니다.

저작권

일반적으로 원저작자(또는 고용조건에 따라 고용주가 규정하는 경우)는 권리를 [28]명시적으로 이전하지 않는 한 저작권을 보유한다.

독립기구인 IETF Trust는 일부 RFC에 대한 저작권을 보유하고 있으며, 그 외의 모든 RFC에 대해서는 RFC를 [29]복제할 수 있는 라이선스를 저자에 의해 부여받고 있습니다.Internet Society는 RFC 4714보다 이전의 많은 RFC에서 저작권 소유자로 참조되고 있지만 IETF [30]Trust에 권한을 양도했습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Waitzman, David (April 1, 1990). A Standard for the Transmission of IP Datagrams on Avian Carriers. IETF. doi:10.17487/RFC1149. RFC 1149. Retrieved March 29, 2017.
  2. ^ Huitema, Christian; Postel, Jon; Crocker, Steve (April 1995). Not All RFCs are Standards. IETF. doi:10.17487/RFC1796. RFC 1796. Retrieved May 15, 2018.
  3. ^ "RFC's, Internet Request For Comments". Livinginternet.com. Retrieved April 3, 2012.
  4. ^ a b "Stephen D. Crocker, How the Internet Got Its Rules, The New York Times, 6 April 2009". The New York Times. April 7, 2009. Retrieved April 3, 2012.
  5. ^ 통지 및 코멘트 요구, 인연방관보(2018년 1월 16일).
  6. ^ 하프너, 케이티, 라이온, 매튜(1996년).마법사가 늦게까지 깨어 있는 곳:인터넷의 기원
  7. ^ Metz, Cade (May 18, 2012). "Meet the man who invented the instructions for the Internet". Wired. Retrieved December 18, 2018.
  8. ^ Crocker, Steve (April 7, 1969). "RFC 1". {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  9. ^ 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.
  10. ^ Leslie Daigle (March 2010). "RFC Editor in Transition: Past, Present, and Future". The Internet Protocol Journal. Vol. 13, no. 1. Cisco Systems. Retrieved August 17, 2011.
  11. ^ Daigle, Leslie (July 2007). The RFC Series and RFC Editor. IETF. doi:10.17487/RFC4844. RFC 4844.
  12. ^ Kolkman, Olaf (August 2009). RFC Editor Model (Version 1). IETF. doi:10.17487/RFC5620. RFC 5620.
  13. ^ Kolkman, Olaf; Halpern, Joel (June 2012). RFC Editor Model (Version 2). IETF. doi:10.17487/RFC6635. RFC 6635.
  14. ^ a b Daigle, Leslie; Kolkman, Olaf (December 2009). RFC Streams, Headers, and Boilerplates. IETF. doi:10.17487/RFC5741. RFC 5741.
  15. ^ Glenn Kowack (January 7, 2010). "RFC Editor Transition Announcement". Archived from the original on June 29, 2011.
  16. ^ "The RFC Series Editor and the Series Reorganization". Retrieved April 5, 2013.
  17. ^ "RFC Format Change FAQ".
  18. ^ a b "RFC Index". RFC Editor. May 25, 2008. Retrieved May 26, 2008.
  19. ^ "Independent Submissions". RFC Editor. Retrieved January 5, 2018.
  20. ^ "Are all RFCs Internet standards documents?". RFC Editor. Retrieved March 16, 2018.
  21. ^ Huitema, Christian; Postel, Jon; Crocker, Steve (April 1995). Not All RFCs are Standards. IETF. doi:10.17487/RFC1796. RFC 1796. ... each RFC has a status…: Informational, Experimental, or Standards Track (Proposed Standard, Draft Standard, Internet Standard), or Historic.
  22. ^ Housley, Russell; Crocker, Dave; Burger, Eric (October 2011). Reducing the Standards Track to Two Maturity Levels. IETF. doi:10.17487/RFC6410. RFC 6410.
  23. ^ RFC 7100 "Internet Official Protocol Standards" 요약 문서 폐기
  24. ^ "7.5. Informational and Experimental RFCs", The Tao of IETF, retrieved November 26, 2017
  25. ^ Bradner, Scott O. (October 1996). The Internet Standards Process – Revision 3. IETF. BCP 9. Retrieved October 25, 2017.
  26. ^ "IESG Statement on Designating RFCs as Historic". IETF. July 20, 2014. Retrieved April 14, 2016.
  27. ^ IETF Standards Written by ISC Contributors, Internet Systems Consortium, September 10, 2021, archived from the original on April 5, 2022, retrieved April 11, 2022, 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.
  28. ^ "Reproducing RFCs". IETF Trust. Retrieved August 12, 2021.
  29. ^ Bradner, Scott; Contreras, Jorge (November 2008). Rights Contributors Provide to the IETF Trust. IETF. doi:10.17487/RFC5378. RFC 5378.
  30. ^ "Reproducing RFCs". IETF Trust. Retrieved August 13, 2021.

외부 링크