프로필
Research
Research 프로필 인텔리전스는 BTW.MEDIA 보도의 주제를 비교하는 독자를 위해 인물, 기업, 기관 등 다양한 개체에 대한 취재를 하나로 연결합니다. 이 페이지는 공개 프로필, 관련 이벤트, 증거 패키지, 역할 변화, 운영 현황, 거버넌스 노출, 조직 간 연결, 시장 내 관련성을 비교하면서, 조직과 인물 기록을 일반적인 뉴스 연표와 구분하여 다룹니다. 독자는 헤드라인 뒤에 있는 주제, 그 프로필을 뒷받침하는 증거, 그리고 프로필을 중요하게 만드는 인프라 및 시장 관계를 이해할 수 있습니다. 또한 프로필이 누구 또는 무엇을 대표하는지, 어떤 공개 자료가 이를 뒷받침하는지, 기업·시장·거버넌스 기구·이벤트와 어떻게 연결되는지, 그리고 주제가 변화함에 따라 어떤 변화가 지속적인 관심을 필요로 하는지 확인할 수 있습니다.
역사
링크에 MAC 주소는 없었다. 그래도 호스트는 도달 가능성을 확인해야 했다: RFC 3316
GPRS나 UMTS 링크에서 IPv6 호스트는 라우터의 링크 계층 주소를 묻지 않아도 되었습니다. 풀어야 할 그런 주소가 없었기 때문입니다. 그러나 라우터에 도달할 수 있는지는 여전히 알아야 했고, 때로는 새 프로브보다 저렴하게 다른 프로토콜의 응답이 그 질문에 답할 수 있었습니다.
역사
더 빠른 Reply가 아무도 쓰지 않는 임대를 남길 수 있다: RFC 3315
2003년 DHCPv6는 빠른 경로를 단지 아낄 패킷 수가 아니라, 네트워크 자원을 언제 확정할지에 대한 선택으로 만들었습니다.
역사
AES는 하나가 아니라 12개의 선택으로 TLS에 들어왔다: RFC 3268
2002년 TLS는 새 핸드셰이크 없이 AES를 얻었습니다. 그러나 그 변경은 12개의 명명된 암호 스위트로 도착했고, 각 스위트는 AES 자체가 결정할 수 없는 암호화, 키 교환, 인증에 대한 선택을 담고 있었습니다.
역사
무작위 키는 복구용 키가 아니었다. 실패를 침묵시키는 방법이었다: RFC 3218
암호화된 메시지는 내용이 손대어지기도 전에 실패할 수 있었다. 그 차이는 유용한 진단적 정밀도처럼 보였지만, 그 차이가 공격자가 질의할 수 있는 서비스가 되면서 상황이 달라졌다. RFC 3218은 불편한 규율로 답했다. RSA 키 운반이 실패하면 새 무작위 콘텐츠 키를 만들어 계속 진행하라—메시지를 구하려는 것이 아니라, 실패 분기가 말을 하지 못하게 하기 위해서다.
역사
URL의 상자를 풀려던 RFC: RFC 3305
웹의 식별자는 한때 각각의 상자에 담겨 있는 것처럼 여겨졌습니다. URL은 어디로 가야 하는지, URN은 무엇인지를 알려 주었죠. 2002년 W3C/IETF 공동 기획 그룹의 보고서인 RFC 3305는 이 깔끔한 구분이 스킴 자체의 발전을 가로막고 있다고 주장했습니다.
역사
확인 응답은 NAK가 들렸다고 말했을 뿐, 복구 도착은 말하지 않았다: RFC 3208
PGM은 모든 수신자로부터 성공 영수증을 수집하는 것을 거부함으로써 신뢰성 멀티캐스트의 확장을 실현했다. 빠진 패킷은 부정 확인 응답(NAK)을 만들었고, 라우터가 그 요청을 홉 단위로 확인했으며, 복구 상태가 재전송을 받아야 할 지점을 선택했다. 그러나 확인 응답은 복구 그 자체가 아니었고, 소스는 그 침묵을 해석하고 싶은 유혹을 느끼게 되는 모든 멤버를 알지 못했다.
역사
10억 명의 사용자가 있어도 대다수는 여전히 배제되어 있었다: RFC 3271
2002년 Vint Cerf는 2005년 말까지 인터넷 사용자가 10억 명을 넘을 것으로 전망하면서도, 그 수치가 여전히 세계 인구의 약 16%에 불과하다는 점을 즉시 짚었다. 이 대비는 '인터넷은 모두를 위한 것'이라는 구호가 여러 개별 조건을 요구하는 시험 문제임을 보여준다.
역사
IPsec는 패킷마다 인증했지만 터널 안의 사용자까지는 증명하지 않았다: RFC 3193
RFC 3193은 불편한 사실에서 출발했습니다. 패킷이 암호학적으로 진본일 수 있어도 그 패킷을 보낸 사용자가 누구인지는 증명하지 못했습니다. IKE는 기기를, PPP는 세션 시작 시점의 사람을 검증했습니다. 두 증명 사이에서 L2TP와 IPsec은 포트, 주소, 필터, 종료 절차를 조율하면서 각 계층 고유의 신원을 지워서는 안 되었습니다.
역사
재사용 가능한 블록도 함께 실패할 수 있었다: RFC 3269
신뢰할 수 있는 멀티캐스트에는 재사용 가능한 구성 요소만으로는 부족했다. RFC 3269는 각 RMT 블록이 자신의 한계와 의존성을 선언하고, 완전한 프로토콜이 구성 요소들이 어떻게 결합되는지 설명하도록 요구했다.
역사
주소 계획은 87% 찼지만 대부분의 주소는 여전히 비어 있었다: RFC 3194
RFC 3194는 계층적 주소 지정의 고통에 백분율을 붙였습니다. 그 결과는 익숙해 보였지만 특이한 의미를 지녔습니다: IPv4 규모의 계획이 87% 호스트 밀도일 때 그것은 약 2억 4,000만 주체를 담았고, 43억 주소의 87%가 아니었습니다. 이 척도는 서로 다른 공간들 사이의 확장 압력을 비교했을 뿐, 문자 그대로의 공간이 얼마나 점유되었는지는 세지 않았습니다.
역사
게이트웨이가 오른쪽을 소유하기 전까지 전화번호는 이메일 주소가 아니었다: RFC 3191
골뱅이 왼쪽 문자열은 전화 지시처럼 보였습니다. 그렇다고 모든 메일 서버가 그 번호를 거는 권한을 갖는 것은 아니었습니다. RFC 3191은 오른쪽 도메인이 번호, 서비스, 한정자를 해석할 게이트웨이를 선택하도록 하고, 그 게이트웨이 너머의 전달은 별개의 사건으로 남겼습니다.
역사
최솟값 샘플은 네트워크에서는 오디오, 테이프에서는 오류였다: RFC 3190
파형의 바닥에 있던 그 숫자에는 서로 양립할 수 없는 두 가지 역할이 있었다. RTP는 이를 평범한 샘플로 취급했고, DV 장비는 샘플이 살아남지 못했다는 통지로 취급했다. RFC 3190은 브리지에게 어느 의미가 경계를 넘을지 선택하게 했다.
역사
국가 접두어는 리졸버를 찾아주었다. 아카이브가 객체를 보관했다는 증거가 아니었다: RFC 3188
`fi` 접두어는 클라이언트에게 핀란드의 NBN 분야가 어디서 시작되는지 알려줄 수 있었다. 그러나 수확된 웹 페이지를 살아남게 하거나, 오늘 응답하는 서비스를 인증하거나, 반환된 파일이 원본임을 증명할 수는 없었다. RFC 3188은 각 지역 도서관 번호의 연합체를 전 세계적으로 이름 지을 수 있게 만들었지만, 영속성은 여전히 기관, 아카이브, 운영 중인 리졸버 안에 있었다.
역사
HTTP 라이브러리는 상호운용성 계획이 아니었다: RFC 3205
2002년 프로토콜 설계자들은 설치된 기반 때문에 HTTP를 빌리려 했다. 브라우저, 서버 코드, 보안 기술, 기존 네트워크 경계를 통한 접근이 그 이유였다. RFC 3205는 그 거래를 거부하지 않았다. 대신 프록시, 캐시, 일반 HTTP 소프트웨어가 애플리케이션과 다른 의미를 만났을 때 무엇을 할지 등 그 거래에 딸려 오는 가정을 설계자가 책임지라고 요구했다.
역사
ISBN은 판(版)을 식별했다. 여러 부를 가리킬 수도, 잘못된 책을 가리킬 수도 있었다: RFC 3187
영속적인 이름은 위치가 바뀌어도 살아남아야 했다. RFC 3187은 그 거래를 구체적이면서도 애매하게 만들었다. 하나의 ISBN URN은 여러 URL로 이어질 수도, 디지털 객체 전혀 없이 끝날 수도, 출판사가 번호를 실수로 재사용해 두 개의 서지 기록으로 이어질 수도 있었다. 영속성은 식별자에 속했다. 단일성은 아니었다.
역사
RFC 1180은 TCP/IP를 설명한 뒤 독자를 표준으로 되돌려 보냈다
1991년 1월, T.J. Socolofsky와 C.J. Kale은 네트워크 전문가들에게 IP 데이터그램이 한 호스트에서 라우터를 거쳐 다른 호스트에 이르는 과정을 따라갈 수 있는 실용적 방법을 제시했다. 동시에 뚜렷한 선을 그었다. 이 메모는 TCP/IP를 설명했을 뿐, 정의하지는 않았다.
역사
고객은 전용 회선을 봤다. 운영자는 숨겨진 주소 쌍을 쥐고 있었다: RFC 3186
한쪽 끝에서 고객 장비는 평범한 PPP 프레임을 내보냈다. 반대쪽 끝에서 고객 장비는 그것을 받았다. 그 사이에서 스위치들은 프레임의 첫 옥텟들을 교체하고 공유 MAPOS 패브릭을 통해 전달한 뒤 원래 값을 복원하고 그 내부 장치를 시야에서 가렸다. RFC 3186은 그 결과를 투명하다고 불렀다. 그러나 더 오래 남는 교훈은, 단순한 인터페이스가 조밀한 제어 표면을 감추면서도 그 표면을 사라지게 하지는 않는다는 것이다.
역사
수신자 목록은 줄었지만 기존 키는 여전히 메시지를 열었다: RFC 3185
두 번째 암호화 메시지는 첫 번째보다 적은 수신자를 명시했습니다. 그러나 생략된 한 구성원은 여전히 그 메시지를 열 수 있었습니다. 아무것도 오작동한 것이 아니었습니다. RFC 3185는 이것이 이전 그룹에 이미 전달된 콘텐츠 키 자료에서 이후 키 암호화 키를 도출하는 예상된 결과라고 경고했습니다. 가시적 봉투는 좁아졌지만, 실제 복호화 권한은 그렇지 않았습니다.
역사
도메인이 메시지에 서명했다. 개인은 여전히 이름이 없었다: RFC 3183
받는 사람은 메시지가 인증된 조직 경계를 통과했음을 확인할 수 있었지만, 발신자 개인의 이름을 표시할 수는 없었다. RFC 3183은 이 구분을 유례없이 명확하게 만들었다. 이 도메인 보안 체계는 '서명'이라는 단일한 포괄적 행위를 제공하지 않았고, 기원·공개·검토·속성 바인딩·암호화·복호화에 서로 다른 권한을 부여하며, 수신자에게 각 암호화 계층이 실제로 담고 있는 주장이 무엇인지 알도록 요구했다.
역사
방화벽은 '아니오'라고 말할 수 있었다. 대화를 깨뜨리도록 허락된 것은 아니었다: RFC 2979
2000년 10월, 하나의 Informational RFC가 패킷 필터가 자주 혼동해 온 경계를 그었다. 사이트는 보안상의 이유로 트래픽을 거부할 수 있지만, 방화벽이 합법적이고 표준을 준수하는 통신을 우연히 실패하게 만들어서는 안 된다는 것이었다. 이 구분은 수리 책임을 모든 애플리케이션이 아닌 중개 장치에 배정했다.