주요 분야
인터넷 인프라
‘주요 분야’ 패싯에서 인터넷 인프라 인텔리전스는 보고 내용을 주 영역별로 묶어, 독자가 인터넷 인프라, 거버넌스, 연결성 시장 또는 디지털 자본 가운데 특정 영역을 집중적으로 따라갈 수 있도록 합니다. 이 페이지는 별도 카테고리 페이지에 나뉘어 있을 수 있는 관련 기사, 공개 증거, 기관, 기업, 인물, 지역적 노출, 운영 의존성, 시장 맥락을 한데 모읍니다. 아울러 해당 영역, 예상 행위자 유형, 시장 또는 거버넌스 맥락, 그리고 신호를 비교할 때 독자가 활용해야 할 출처 자료를 설명합니다. 운영자, 분석가, 거버넌스 분야 독자는 같은 영역이 이벤트, 프로필, 시장 변화, 공개 출처 증거, 지역 의존성, 보다 장기적인 주기의 인프라 의사결정 전반에서 시간에 따라 어떻게 나타나는지 살펴볼 수 있습니다.
역사
출력은 128비트로 유지됐다. 키 규칙은 바뀌었다.
2004년 RFC 3664는 IPsec의 MAC이 96비트로 축약한 전체 결과를 유지하며 AES-XCBC를 IKE에 맞춰 조정했습니다. 두 해 후 후속 문서가 바꾼 것은 다른 경계였습니다. 같은 PRF가 어떤 키 길이를, 어떤 IKEv2 용도에 대해 받아들일지였습니다.
역사
이름은 프로토콜을 넘었지만, 매개변수는 저절로 옮겨지지 않았다: RFC 3555
RFC 3555는 RTP 코덱에 다른 프로토콜에 인쇄할 수 있는 이름을 붙여 준 것에 그치지 않았습니다. 하나의 미디어 타입 표현의 조각마다 SDP 안에서 서로 다른 목적지가 지정되고, 그 조각들의 의미에 대한 권한은 레지스트리가 아닌 페이로드 명세가 지킨다는 일종의 관리 사슬을 규정했습니다.
역사
디렉터리 트리는 여섯 배로 컸지만, 클라이언트는 여전히 지도가 필요했다
RFC 3663의 Referral LDAP 실험은 원칙적으로 도메인 등록 데이터를 더 쉽게 조회할 수 있게 했습니다. 그러나 자체 공학 기록은 익숙한 프로토콜이 쓸 만한 서비스가 되기까지 얼마나 많은 작업이 데이터 배치, 레퍼럴, 클라이언트로 이동했는지 보여줍니다.
역사
이름이 영구적이었던 이유는 현재의 값을 담기를 거절했기 때문이다: RFC 3553
레지스트리가 옮겨간다고 해서 모든 프로토콜 문서와 구현이 그 의미를 다시 이름 지을 필요는 없습니다. RFC 3553은 이름에 사람들이 기대하려는 권한보다 적은 권한을 부여함으로써 그 연속성을 달성했습니다.
역사
같은 암호, 세 가지 파라미터 규칙: CMS의 Camellia
CMS는 암호 이름만으로 암호화를 식별하지 않습니다. RFC 3657은 Camellia에 대해 콘텐츠 보호, 콘텐츠 키 래핑, capability 공지에 서로 다른 알고리즘 식별자를 부여했고, 각 맥락은 파라미터를 다르게 다룹니다.
역사
예약된 이름, 준비되지 않은 메일박스: RFC 3656
분산 메일 서비스에서 두 서버가 하나의 메일박스 이름을 놓고 충돌하는 것을 막는 것은 일의 절반일 뿐이다. RFC 3656은 그 네임스페이스 점유와, 클라이언트가 실제로 메일박스를 사용할 수 있게 되는 이후 상태를 분리했다.
역사
TCP 카운터는 공용으로 유지되었다. 연결에는 다섯 번째 좌표가 필요했다: RFC 2452
IPv6 전환이 TCP 관리 모델 전체를 다시 시작하도록 강요하지는 않았다. RFC 2452는 대부분의 전송 계층 카운터를 공용으로 유지한 뒤, IPv6 연결 행이 모호해질 수 있는 곳에 인터페이스 좌표 하나를 추가했다.
역사
RFC 번호는 표준처럼 보였다. 그러나 IESG는 아니라고 밝혔다: RFC 3924
RFC 3924는 합법적 가로채기를 위한 벤더 아키텍처를 RFC 시리즈에 넣으면서, 그 위에 특히 노골적인 경고를 놓았습니다: Informational이며, 인터넷 표준이 아니고, 보안이나 프로토콜 상호작용에 대한 IETF 검토도 거치지 않았다는 것입니다.
역사
게이트웨이가 바꿀 수 있는 것은 래퍼지 메시지가 아니었다: RFC 3923
2004년, RFC 3923은 XMPP가 서명되거나 암호화된 메시지를 게이트웨이를 통해 다른 메시징 시스템으로 전달할 수 있는 방법을 제시했습니다. 이 표준에서 가장 영향력 있는 지침이자 동시에 가장 좁은 지침은 이렇습니다. 봉투는 번역하되 보호된 객체는 결코 바꾸지 말라.
역사
RMON은 MPLS의 이름을 붙일 수 있었지만, 그 하위에는 손대지 못했다: RFC 3919
RMON 프로브는 두 가지 MPLS 엔트리 유형을 구분할 수 있었지만, RFC 3919는 레이블 스택에 보편적인 프로토콜 패밀리 트리를 부여하기까지는 가지 못했다. IPv6와의 대비는 식별자가 어디까지 나아갈 수 있고 어디서 의미를 멈춰야 하는지 보여준다.
역사
태그 프레임 하나, 멀티캐스트 시계 여럿
멀티캐스트 테스트에서 한 패킷은 하나의 인그레스에서 나가 여러 이그레스에 도착합니다. RFC 3918의 핵심 측정 선택은 이 도착 시점들을 분리해 둔 것입니다. 헤드라인 지연 수치 하나만으로는 어느 경로가 지연을 감당했는지 운영자에게 알려줄 수 없습니다.
역사
DHCP는 벤더에게 별도 옵션 공간을 주었지, IANA가 정의한 의미를 준 것이 아니다
2004년 DHCPv4는 하나의 교환에서 여러 벤더의 구성 데이터를 담을 수 있는 방법을 얻었지만, 공유 패킷이 그들의 사설 옵션 어휘를 동일하게 만든 것은 아니었다. RFC 3925는 봉투를 넓혔을 뿐, 그 안의 모든 것을 표준화하지 않았다.
역사
TLS 세션은 서버에서 끝났다, CGI 스크립트가 아니라
CGI는 웹 서버가 애플리케이션 프로그램에 요청을 넘기는 절차를 구현 간에 이해할 수 있게 만들었다. 2004년 명세는 또한 놓치기 쉬운 경계를 그렸다. 인증된 네트워크 세션은 서버가 갖고 있었고, 스크립트는 그것을 물려받지 않았다.
역사
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는 그 자신의 메트릭 레지스트리가 일부 측정을 충분히 정확하게 식별하지 못한다고 밝혔다. 이 이야기의 핵심은 지표가 틀렸다는 것이 아니라, 유용한 연구 어휘를 상호운용 가능한 목록으로 만드는 일이 얼마나 어려웠는가이다.