주요 분야
인터넷 인프라
‘주요 분야’ 패싯에서 인터넷 인프라 인텔리전스는 보고 내용을 주 영역별로 묶어, 독자가 인터넷 인프라, 거버넌스, 연결성 시장 또는 디지털 자본 가운데 특정 영역을 집중적으로 따라갈 수 있도록 합니다. 이 페이지는 별도 카테고리 페이지에 나뉘어 있을 수 있는 관련 기사, 공개 증거, 기관, 기업, 인물, 지역적 노출, 운영 의존성, 시장 맥락을 한데 모읍니다. 아울러 해당 영역, 예상 행위자 유형, 시장 또는 거버넌스 맥락, 그리고 신호를 비교할 때 독자가 활용해야 할 출처 자료를 설명합니다. 운영자, 분석가, 거버넌스 분야 독자는 같은 영역이 이벤트, 프로필, 시장 변화, 공개 출처 증거, 지역 의존성, 보다 장기적인 주기의 인프라 의사결정 전반에서 시간에 따라 어떻게 나타나는지 살펴볼 수 있습니다.
역사
IAB가 요청한 것은 연구 자금 지원이지, 예산 관장 역할이 아니었다
2004년 인터넷 아키텍처 위원회(IAB)는 인터넷의 공통 기반을 위한 지속적인 연구 자금이 필요하다고 주장했다. 마지막에 남긴 설명도 중요했다. IAB, IETF, IRTF는 그 자금을 직접 관리할 역할을 요청하지 않았다는 점이다.
역사
마감 시간은 만료됐다. SCTP 스택은 나중에 확인해도 됐다.
RFC 3758은 부분 신뢰성을 정책 경계로 만들었습니다. 애플리케이션이 SCTP에 전송 시도 중단을 요구할 수 있었지만, 프로토콜은 정확한 마감 시각에 타이머가 울린다고 약속하지 않았습니다. 범용 와이어 신호는 수신자를 폐기된 시퀀스 번호 너머로 이동시킬 수 있었고, 그 신호가 언제 생성되는지는 송신자 측 서비스 결정이었습니다.
역사
빠름, 부드러움, 원활함: RFC 3753이 구분해 둔 세 가지 핸드오버 라벨
엔지니어들이 모바일 핸드오버를 비교하려면 먼저 어떤 종류의 핸드오버를 말하는지 명확히 해야 했다. 2004년 6월, IETF 용어집은 대체로 독립적인 다섯 가지 제어 질문을 구분하고 지연, 패킷 손실, 애플리케이션이 감지하는 연속성을 각각 따로 정의했다. 모빌리티 프로토콜을 지정하지도, 자신의 용어 체계가 보편적이라고 주장하지도 않았다.
역사
검색 결과는 신원이 아니었다: RFC 3744의 정식 주체 URL
WebDAV 접근 제어 설계는 표시 이름이 가릴 수 있는 문제를 풀어야 했습니다. 한 사람 또는 소프트웨어 에이전트가 여러 URL로 접근 가능할 수 있지만, 접근 제어 항목(ACE)에는 모호하지 않은 주체 참조가 필요했습니다. RFC 3744는 사람 지향의 제한된 검색 기능을 정식 주체 URL과 짝지었고, 두 가지 모두 인증 및 권한 부여와 분리해 두었습니다.
역사
등록 한 건이 라벨이 아니라 패키지를 예약했다: RFC 3743
레지스트리가 CJK 도메인 라벨을 수용할 때 보이는 문자열은 더 큰 행정적 가족의 한 구성원일 수 있습니다. RFC 3743의 공동 엔지니어링 팀은 선정된 문자 이형을 하나의 예약 패키지로 다루자고 제안하면서, 실제로 DNS에 들어갈 형태는 각 존이 결정하도록 남겨 두었습니다.
역사
하나의 데이터그램은 경로를 바꿨다. 다른 소켓 기본값은 살아남았어야 했다: RFC 3542
가장 시사적인 API 변경은 때로 예외가 미치는 영향 반경의 변화다. RFC 3542는 하나의 IPv6 데이터그램이 소켓 기본값 하나에서 벗어나는 것을 허용하면서도, 그 패킷이 애플리케이션이 이미 내린 다른 모든 선택을 지워버리는 핑계가 되지 않도록 했다.
역사
지표에는 이름이 있었다. 그러나 측정은 여전히 달랐다: RFC 3393
RFC 3393는 패킷 지연 변동에 공식 명칭과 유연한 수학적 정의를 부여했다. 10년 뒤 IETF는 그 자신의 메트릭 레지스트리가 일부 측정을 충분히 정확하게 식별하지 못한다고 밝혔다. 이 이야기의 핵심은 지표가 틀렸다는 것이 아니라, 유용한 연구 어휘를 상호운용 가능한 목록으로 만드는 일이 얼마나 어려웠는가이다.
역사
836 RTT 회복은 하한이었다: RFC 3742의 슬로우 스타트 에러타텀
2004년 TCP 슬로우 스타트의 문제는 단순히 빠르게 커진다는 점만이 아니었다. 매우 큰 혼잡 윈도우를 가진 연결에서는 왕복 시간 한 번에 수천 개의 세그먼트가 추가될 수 있었고, 한 번의 과잉은 송신자와 그 병목을 공유하는 트래픽 모두에게 대가를 물었다. RFC 3742는 그 성장에 상한을 두자고 제안했다. 이후 검증된 에러타텀은 그 상한이 어느 정도 높이까지, 얼마나 오래 걸릴 수 있는지에 대한 서술을 바꿔 놓았다.
역사
서명은 이동에서 살아남았다. 의미는 그렇지 않을 수 있다: RFC 3741
서명된 XML을 메시지 봉투 사이에서 옮기는 일은 어색한 선택을 만든다. 상속된 모든 네임스페이스와 속성을 서명된 바이트에 넣거나, 서명의 안정성을 유지하되 남겨진 컨텍스트를 애플리케이션이 책임지게 하는 것 중 하나다. RFC 3741은 선택적 상속을 택했다. 그 절약은 유용하지만, 조각을 의미적으로 자기완결적으로 만들어 주지는 않는다.
역사
적격 인증서는 선언을 담을 수는 있어도 법적 판단은 아닌 것: RFC 3739
유효한 X.509 인증서 체인에서 ‘적격(qualified)’이라는 단어는 올바른 자리에 나타날 수 있지만, 결정적인 질문에는 답하지 않습니다. 어떤 규칙에 대해, 어떤 행위를 위한 적격인가. 2004년에 발표된 RFC 3739는 자연인용 인증서가 이용 목적 선언, 신원 속성, 정책 참조를 담을 수 있는 방식을 표준화했습니다. 그러나 그 적격성에 관한 법적 기준이나 효과를 판단하지는 않았습니다.
역사
보고서는 발신자에게 가지 않았다. 수신자는 여전히 자신의 수신 속도를 통제했다: RFC 3738
2004년 WEBRC는 각 수신자가 자신의 상태를 발신자에게 보고하지 않는 멀티캐스트 혼잡 제어 루프를 제안했다. 측정과 속도 결정을 수신자에게 옮기고, 그 결정을 멀티캐스트 채널 가입·탈퇴로 표현한 것으로, 이는 제어가 없어진 것이 아니라 제어의 위치가 바뀐 변화였다.
역사
기존 OID 트리는 그대로, IANA가 이어받은 다음 RMON 루트: RFC 3737
IANA가 RMON 모듈 루트 할당을 넘겨받기 전에는 워킹 그룹이 자체 목록을 관리했습니다. RFC 3737은 이미 사용 중인 식별자를 재정렬하지 않으면서 다음 할당 결정을 공개 레지스트리로 옮겼습니다.
역사
주소는 이미 있었다. 그래도 DHCPv6에는 할 일이 남아 있었다: RFC 3736
IPv6 호스트는 DHCPv6에 주소를 요청하지 않고도 주소를 만들 수 있었지만, 여전히 네트워크의 DNS나 서비스 매개변수가 필요했다. RFC 3736은 이 두 번째 작업을 작고 독립적인 교환으로 분리했고, 빠진 갱신 시계가 다음 설계 과제로 남았다.
역사
중복은 도착했지만, 손실 판정은 아니다: RFC 3708
수신자는 한 세그먼트가 두 번 도착했다고 보고할 수 있다. 2004년 RFC 3708은 송신자가 이 단일 관찰을 복구 윈도우 전체가 손실 없이 도착했다는 판정으로 확대하지 않도록 요구했다.
역사
Base64는 단순한 Base64가 아니었다: RFC 3548과 인코딩 프로필
같은 바이트를 담아도 인코딩은 경계에서 다르게 동작할 수 있습니다. 2003년, RFC 3548은 한 프로토콜의 메일 시대 습관이 다른 프로토콜의 가정이 되기 전에 그 경계를 명확히 하려 했습니다.
역사
레지스트리는 문턱을 낮췄지만 질문은 그대로였다: RFC 3546과 TLS 확장
2년에 걸쳐 TLS 확장 등록 절차는 표준 트랙 문턱에서 공개 명세에 대한 전문가 검토로 이동했습니다. 이 변경으로 코드 포인트 요청은 쉬워졌지만, 레지스트리 등재가 보안·구현·사용에 대한 판정이 되지는 않았습니다.
역사
체크섬이 한 필드를 놓쳤다: RFC 3545와 RTP 복구
16비트 헤더 체크섬은 압축 해제기가 재구성된 CRTP 헤더를 검증하는 데 도움을 줄 수 있었지만 IPv4 식별 필드는 커버하지 않았다. RFC 3545는 패킷 손실이 복구 예산을 넘어서는 순간 이 맹점을 결정적으로 만들었다.
역사
0은 이미 1이었다: RFC 3544와 PPP 압축 협상
PPP에 TCP 헤더 압축은 유지하면서 다른 트래픽은 그대로 두도록 요청할 수 있었다. 직관적인 지시, 즉 non-TCP 컨텍스트 공간을 0으로 설정하는 방법은 '없음'을 의미하지 않았다. RFC 3544는 기존 필드가 표현할 수 없던 값을 위한 작고 명시적인 재정의 메커니즘을 추가했다.
역사
브리지는 100%에 도달했다. 그러나 결제·배송을 입증하지 않았다: RFC 3538
결제 인터페이스가 설계된 모든 메시지를 마무리했더라도 가장 중요한 상거래 질문은 여전히 열려 있을 수 있다. RFC 3538은 다섯 단계 진행률 계량기의 마지막 표식이 전체 트랜잭션이 아니라 프로토콜 브리지에 속한다는 한계를 보여 주었다.
역사
봉투는 키의 길이는 알았지만 키의 용도는 몰랐다: RFC 3537
CMS 패키지는 HMAC 키를 다른 시스템이 바이트 단위로 복구할 수 있는 형태로 운반할 수 있습니다. 그것은 유용한 전송 영수증입니다. 그러나 그 바이트가 어떤 다이제스트, 어떤 서비스, 어떤 주체, 어떤 결정을 위해 승인되었는지는 아직 기록되지 않았습니다.