위키원
"RFC"의 두 판 사이의 차이
juju0990304 (토론 | 기여) |
juju0990304 (토론 | 기여) (→특징) |
||
| 8번째 줄: | 8번째 줄: | ||
== 특징 == | == 특징 == | ||
| − | + | RFC는 ARPANET 프로젝트 수행 시 작성하는 일련의 문서들에 그 기원을 두고 있으며, 사실상 인터넷 기술과 관련된 공식 문서의 성격을 띠고 있다. 모든 인터넷 표준은 항상 RFC로 문서화되고 있으며, 명칭 자체로는 RFC를 표준 규격이라고 말하기에는 이상하지만, 사실상, TCP/IP 프로토콜 사양서(표준서)의 기능을 다 하고 있다. [[IETF]]에서 RFC를 작성하고 있으며, [[인터넷]](Internet)을 통해서 입수가 가능하다.<ref name="차재복">차재복, 〈[http://www.ktword.co.kr/abbr_view.php?m_temp1=177 RFC]〉, 《정보통신기술용어해설》, 2019-03-05</ref> | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
=== 표준화 과정 === | === 표준화 과정 === | ||
| 73번째 줄: | 62번째 줄: | ||
: 최신 규격의 등장으로 사용하지 않거나, 그 밖의 다른 이유로 인해 쓸모없어진 규격은 히스토릭 단계가 된다. 히스토릭으로의 요청은 워킹그룹, 분야책임자 그 밖의 이해집단에서 할 수 있다. IESG는 히스토릭 상태로의 변경을 승인하며 이에 대해 전체 공지한다. 만약 새로운 RFC가 이전 RFC를 대체할 경우에는 신규 RFC에 "Obsoletes : (이전 RFC 번호)"를 표시하여 대체함을 나타낸다. 이때 이전 RFC는 히스토릭으로의 별도 신청이 없는 이상 "unknown" 상태로 전환된다.<ref name="진수경"></ref> | : 최신 규격의 등장으로 사용하지 않거나, 그 밖의 다른 이유로 인해 쓸모없어진 규격은 히스토릭 단계가 된다. 히스토릭으로의 요청은 워킹그룹, 분야책임자 그 밖의 이해집단에서 할 수 있다. IESG는 히스토릭 상태로의 변경을 승인하며 이에 대해 전체 공지한다. 만약 새로운 RFC가 이전 RFC를 대체할 경우에는 신규 RFC에 "Obsoletes : (이전 RFC 번호)"를 표시하여 대체함을 나타낸다. 이때 이전 RFC는 히스토릭으로의 별도 신청이 없는 이상 "unknown" 상태로 전환된다.<ref name="진수경"></ref> | ||
| + | === 종류 === | ||
| + | * '''인포메이셔널'''(Informational) : 일반적인 정보 전달을 목적으로 한다. | ||
| + | * '''익스페리멘탈'''(Experimental) : 진행 중인 연구 또는 개발과 관련되있다. | ||
| + | * '''히스토릭'''(Historic) : 역사적인 면에서 중요한 의미가 있음. 인터넷 표준이 되기 위한 필요한 단계를 통과하지 못한 것이다. | ||
| + | * '''프로포지드 스탠다드'''(Proposed Standard) : 현재 시험 중이어서 계속된 개정이 필요하며, 완전한 표준의 틀은 갖추고 있다. | ||
| + | * '''드래프트 스탠다드'''(Draft Standard) : 적어도 2개 이상의 다른 코드로 구현, 상호운용에 대한 충분한 필드 테스트가 되었으나, 더 많은 필드 경험 필요하다 | ||
| + | * '''인터넷 스탠다드'''(Internet Standard) : 성공적으로 구현 사용되고 있다.<ref name="차재복"></ref> | ||
{{각주}} | {{각주}} | ||
2020년 8월 3일 (월) 11:17 기준 최신판
RFC(Request for Comments)는 IETF(Internet Engineering Task Force)에서, 인터넷에서 기술을 구현하는 데에 필요한 절차 등을 제공하는 공문서 간행물이다. 알에프씨라고 읽는다.
목차
개요[편집]
RFC(Request for Comments)는 인터넷 연구와 개발 공동체의 작업 문서이다. 이 문서 내용의 대부분은 인터넷상에서 기술을 구현함에 있어서 요구되는 상세한 절차와 기본 틀을 제공하는 기술 관련 내용이다. 필요하면 전자우편을 통하거나 직접 특정 호스트에 접속하여 FTP로 다운로드할 수 있다. 한 문서에 RFC 문서 번호가 부여되고 출판되면, 수정되거나 같은 번호가 부여되는 일은 없다. RFC를 쉽게 구하기 위해서는 RFC 색인을 참조하면 된다. 색인은 어떤 RFC가 유일한 것인지 아니면 또 다른 RFC에 의해 갱신된 것인지를 나타내주고 있다. RFC가 발표될 때마다 이 색인은 온라인으로 갱신된다. RFC 색인은 익명(anonymous) FTP를 이용해 가져올 수 있는데, 파일명은 RFC 디렉터리 아래의 rfc-index.txt이다. 사용자는 키워드, 제목, 작성자, 발표 기관, 날짜 등의 임의의 필드를 지정해 모든 RFC의 목록을 요청할 수 있다. 이 서비스를 사용하려면 원하는 요구 사항을 써 RFC-INFO@ISI.EDU에 전자우편을 보내야 한다.[1]
역사[편집]
RFC 형식의 시작은 프로젝트의 일부로 발생했다. 1969년 미국 국방부에서는 원거리에 분리되어 있던 값비싼 컴퓨터의 정보를 효율적으로 이용하는 한편, 전쟁이나 자연재해와 같은 비상사태 발생 시 고급 정보 유실의 문제를 해결할 목적의 일환으로 미국 주요 대학의 연구 기관과 국방 사업체의 컴퓨터 시스템을 연결하여 네트워크를 구성하려는 프로젝트(ARPA: Advanced Research Projects Agency)를 가동한다. 그리고 그 작업을 위한 첫 번째 단계로 IMP(Interface Message Processor)라는 일종의 ‘메시지 중계기를 통한 통신 규칙(호스트-IMP-호스트 프로토콜)’에 대한 구상을 밝히는데, 그것이 1969년 4월에 작성된 ARPA의 최초의 문서인 RFC1이다. 그리고 같은 해 말, 4대의 컴퓨터를 연결하는 데 성공함으로써 오늘날 인터넷의 전신인 ‘아르파넷(ARPANET)’의 서막을 열게 된다. 이 RFC1 문서의 제목은 처음부터 자연스럽게 호스트(host)란 용어를 사용하고 있는 ‘Host Software’였다. 의심할 여지 없이 실험에 참여하는 기관의 컴퓨터를 의미하고 각기 다른 운영체제의 호스트 컴퓨터들을 연결하기 위한 IMP를 지칭한다.[2]
특징[편집]
RFC는 ARPANET 프로젝트 수행 시 작성하는 일련의 문서들에 그 기원을 두고 있으며, 사실상 인터넷 기술과 관련된 공식 문서의 성격을 띠고 있다. 모든 인터넷 표준은 항상 RFC로 문서화되고 있으며, 명칭 자체로는 RFC를 표준 규격이라고 말하기에는 이상하지만, 사실상, TCP/IP 프로토콜 사양서(표준서)의 기능을 다 하고 있다. IETF에서 RFC를 작성하고 있으며, 인터넷(Internet)을 통해서 입수가 가능하다.[3]
표준화 과정[편집]
RFC의 표준화는 1996년 설립된 국제적인 사실 표준화 기구 IETF(Internet Engineering Task Force)와 인터넷 기술 관리 그룹 IESG(Internet Engineering Steering Group)에서 이루어진다. IETF에서는 인터넷 기술과 이들의 개발 및 구현에 대한 문서를 작성하고, IESG에서는 IETF에서 작성하는 문서들을 검토하여 정식 RFC(Request For Comment) 문서로서 등록하는 표준화 트랙을 담당한다.[4]
일반적으로 IETF의 규격은 인터넷 드래프트(Internet Draft)로 시작하여 인터넷 표준트랙(Internet Standards Track)을 거쳐 완성되는데, 여기에는 인터넷 표준(Internet Standard)으로 진행하는 표준트랙(Standards Track)과 그렇지 않은 비표준트랙(Non-Standards Track)이 있다. 실제로 대부분의 RFC는 표준트랙보다는 비표준트랙상의 규격인 경우가 많다. 이 두 종류의 문서는 공통으로 다음과 같은 과정을 거쳐 RFC로 발간된다.[5]
- 인터넷 드래프트 문서 작성 (개인 또는 워킹그룹)
- 인터넷 드래프트에 대한 의견 수렴
- 의견에 따라 문서 수정
- 1)~3)의 단계를 반복
- 개인 기고일 경우 분야책임자에게 IESG 검토를 요청, 워킹그룹에서 작성한 문서일 경우 워킹그룹 의장이 분야책임자에게 IESG 검토를 요청
- IESG의 요청에 따른 수정
- RFC Editor에 의한 발간
유의할 점은 백서, 협력문서, 절차, 요구사항, 시험 기록, 정책뿐만 아니라, 시, 만우절 농담 등도 RFC로 발간되므로, 모든 RFC를 IETF의 표준이라고 볼 수는 없다.[5]
트랙 진입 전: 인터넷 드래프트[편집]
- 인터넷 드래프트 작성
- 인터넷 드래프트는 개인 또는 워킹그룹에서 작성할 수 있으며, 매월 약 300여 개의 인터넷 드래프트들이 신규 또는 수정되어 등록되고 있다. 드래프트는“Internet-Drafts”디렉토리에 저장되어 누구나 볼 수 있으며, ”ID Tracker”라는 메뉴를 통해 웹상에서 상태 추이를 검색할 수 있도록 하고 있다.
- 인터넷 드래프트는 RFC와 같은 양식으로 작성하여 드래프트 편집자(internet-draft@ietf.org)에게 제출한다. 워킹그룹에서 작성한 경우, 파일명은“draft-ietf-(워킹그룹명 약어)”로 시작하고,“00.txt”로 끝난다. 예를 들어 SMIME 워킹그룹에서 작성한 경우“draft-ietf-smine-keying-00.txt”라는 파일명을 정할 수 있다. 만약 Smith라는 개인의 기고일 경우에는“draft-smith-keying-00.txt”와 같이 작성자의 이름을 넣을수도 있고, 특정 워킹그룹과 관련 있다면“draft-smith-smime-keying-00.txt”와 같이 작성자의 이름과 함께 워킹그룹명을 넣기도 한다. 문서를 수정했을 경우에는“draft-ietf-smine-keying-01.txt”와 같이 파일명의 숫자를 증가시킨다.
- 최종검토요청
- Internet-Drafts 디렉터리의 문서들은 외부의 의견을 수렴하면서 수시로 수정할 수 있다. 만약 어느 정도 의견수렴이 마무리되었다고 판단되면, 워킹그룹 의장은 워킹그룹 내에서 최종의견수렴을 거친 후 해당 분야책임자에게 제출하여 IESG 승인을 요청한다. 개인이 작성한 경우에는 작성자가 해당 분야책임자에게 제출하여 IESG의 승인을 요청하게 된다. 만약 IESG의 승인을 받지 못하고 6개월 동안 수정 없이 남아있을 경우에는 디렉터리에서 삭제된다. IESG는 제출된 문서에 대해 전체공지 메일링리스트(IETF Announce)를 통해 최종검토요청(Last Call)을 알린다. 이는 해당 문서를 모르고 있던 사람들에게 알려주고, 또 필요하다면 수정할 수 있도록 하기 위해서이다. 최종검토요청(Last Call) 기간은 워킹그룹 문서인 경우 2주이며, 개인 기고인 경우에는 4주이다. 최종검토요청을 마치고 IESG에서 승인하면 RFC Editor는 편집 후 RFC 번호를 부여하여 발간한다.[5]
표준트랙[편집]
표준트랙(Standards Track)은 제안 표준(Proposed Standard), 드래프트 표준(Draft Standard), 인터넷 표준(Internet Standard)과 같은 3단계의 완성단계로 이루어져 있다. 표준트랙 상의 모든 단계의 규격을 표준(Standard)으로 통칭한다.
IESG는 단계마다 수정되는 범위와 중요성을 판단해야 한다. 만약 해당 규격에 중요한 변화가 있었다면, IESG는 이를 새로운 문서로 보고, 표준트랙을 처음부터 다시 진행할 수도 있다. 만약 표준트랙 상의 규격이 최종단계인 인터넷 표준까지 진행하지 않고 같은 단계에서 24개월간 또는 상태가 변경된 후 12개월간 머물러 있을 경우, IESG는 해당 규격에 대한 표준화 의지, 실용성 등을 검토한다. 이를 통해 해당 규격을 그대로 둘지 또는 Historic 상태로 옮길지 결정하며, 이러한 결정은 전체공지를 통해 협의된다.[5]
- 제안 표준
- IESG에서 인터넷 드래프트에 대해 인터넷 표준(Internet Standard) 단계로의 진행을 결정하면, RFC Editor는 해당 문서를 제안 표준(Proposed Standard)로 발간한다. 제안 표준의 규격은 일반적으로 안정적이면서 유용성을 인정받은 상태로서 알려진 기술적 오류가 없어야 한다. 제안 표준 상태로 최소 6개월간 있고 난 뒤 작성자 또는 해당 워킹그룹 의장은 드래프트 표준(Draft Standard)으로의 승인을 요청할 수 있다. 이때 분야 책임자는 최소 2건의 개별적인 상호운용성 구현이 있었음을 요청한다. 대개 제안 표준에서 드래프트 표준으로의 진행은 많지 않은 편이며 대부분 제안 표준 상태로 사용되고 있다.
- 드래프트 표준
- 최소한 2건의 서로 다른 코드로 개발된 독립적이고 상호운용성 있는 구현물들이 원활히 작동되면 드래프트 표준(Draft Standard) 단계로 진행할 수 있다. 드래프트 표준은 일반적으로 최종 규격으로 받아들여지며, 특정 문제를 해결하기 위해서만 수정이 가능하다. 업체들의 경우 드래프트 표준을 이용하여 구현하는 것이 바람직하다.
- 인터넷 표준
- 드래프트 표준 상태로 몇 년간 지나면 인터넷 표준(Internet Standard)이 될 수 있다. 이는 아주 드문 경우로서, 인터넷이 작동하는데 절대적으로 필요한 프로토콜만이 인터넷 표준이 될 수 있다. 'Full Standard'라고도 하며, RFC 번호 외에도 STD 일련번호를 받게 된다.[5]
비표준트랙[편집]
모든 규격이 표준트랙을 거치는 것은 아니다. 인터넷 표준으로의 진행을 원하지 않거나, 표준트랙에 진입하기에는 준비가 안 된 규격, 새로운 인터넷 표준의 등장으로 폐지되거나 사용되지 않는 규격도 있다. 이런 규격을 비표준트랙(Non-Standards Track)이라 한다. 이와 같이 표준트랙에서 벗어난 규격들은 익스페리멘탈, 인포메이셔널, Historic의 세 가지 중 하나로 분류된다.[5]
- 익스페리멘탈(Experimental)
- 익스페리멘탈 RFC는 관심은 있지만 구현될 경우 어느 정도 이익이 있을지 확실하지 않은 규격들이다. 즉, 특정 문제를 해결할 수는 있으나 많은 사람들이 그 문제를 중요하게 여기는지 확실하지 않다면 익스페리멘탈 RFC로 분류된다. 만약 다음에 해당 규격이 대중적으로 확산하면 표준트랙으로 전환할 수 있다.
- 인포메이셔널(Informational)
- 인포메이셔널 규격은 인터넷 사용자들을 위한 일반적인 정보로서, IETF에서 합의가 되었거나 권고함을 의미하지 않는다. 특히 외부에서 개발되어 IETF의 표준절차에 따르지 않는 규격들은 작성자의 허가를 받아 RFC Editor의 협조로 인포메이셔널 RFC로 발간되기도 한다. 인포메이셔널 RFC는 IETF 내에서 자주 논란이 되는 사항이다. 많은 사람들이 외부에서 개발된 규격을 IETF 문서에서 참조하고 있지만, 인포메이셔널 RFC를 IETF 표준으로 간주하는 사람들이 있어서 논란의 여지가 있다.
- 익스페리멘탈과 인포메이셔널 RFC 과정
- 워킹그룹의 작업 결과가 아닌 경우, 익스페리멘탈 또는 인포메이셔널 발간을 원하는 문서는 RFC Editor에 직접 제출한다. RFC Editor는 다른 인터넷 드래프트문서와 마찬가지로 Internet-Drafts 디렉터리에 게재하여 2주간 의견을 받는다. 비표준트랙의 익스페리멘탈 또는 인포메이셔널이 인터넷 표준 절차를 앞지르기 위해 오용되는 것을 방지하기 위해, RFC Editor는 제출된 문서와 관련하여 IETF 내에서 이미 진행되었거나 혹은 진행될 작업이 있는지 IESG의 검토를 받는다. 만약 워킹그룹에서 익스페리멘탈 또는 인포메이셔널 RFC 문서를 제안한 경우에는 IESG에 제출되어 검토를 받는다.
- 히스토릭(Historic)
- 최신 규격의 등장으로 사용하지 않거나, 그 밖의 다른 이유로 인해 쓸모없어진 규격은 히스토릭 단계가 된다. 히스토릭으로의 요청은 워킹그룹, 분야책임자 그 밖의 이해집단에서 할 수 있다. IESG는 히스토릭 상태로의 변경을 승인하며 이에 대해 전체 공지한다. 만약 새로운 RFC가 이전 RFC를 대체할 경우에는 신규 RFC에 "Obsoletes : (이전 RFC 번호)"를 표시하여 대체함을 나타낸다. 이때 이전 RFC는 히스토릭으로의 별도 신청이 없는 이상 "unknown" 상태로 전환된다.[5]
종류[편집]
- 인포메이셔널(Informational) : 일반적인 정보 전달을 목적으로 한다.
- 익스페리멘탈(Experimental) : 진행 중인 연구 또는 개발과 관련되있다.
- 히스토릭(Historic) : 역사적인 면에서 중요한 의미가 있음. 인터넷 표준이 되기 위한 필요한 단계를 통과하지 못한 것이다.
- 프로포지드 스탠다드(Proposed Standard) : 현재 시험 중이어서 계속된 개정이 필요하며, 완전한 표준의 틀은 갖추고 있다.
- 드래프트 스탠다드(Draft Standard) : 적어도 2개 이상의 다른 코드로 구현, 상호운용에 대한 충분한 필드 테스트가 되었으나, 더 많은 필드 경험 필요하다
- 인터넷 스탠다드(Internet Standard) : 성공적으로 구현 사용되고 있다.[3]
각주[편집]
참고자료[편집]
- RFC 두산백과 - hhttps://terms.naver.com/entry.nhn?docId=1180285&cid=40942&categoryId=32828 RFC
- 〈인터넷 발전사로 알아보는 DNS – ① 최초의 연결〉, 《가비아》
- 김진출, 〈IETF 표준화 동향〉, 《한국정보통신기술협회》
- 진수경, 〈IETF〉, 《한국정보통신기술협회》
- 차재복, 〈RFC〉, 《정보통신기술용어해설》, 2019-03-05
같이 보기[편집]
