요약

  • RFC 1073은 창 크기에 대한 권한을 클라이언트에 부여하고, 이후 변경 사항을 포함해 너비와 높이를 함께 보고하도록 했다. 이 보고는 명시적으로 참고용이었으며, 서버는 NAWS를 수락하면서도 값을 무시할 수 있었다.
  • DO/WILL은 옵션 사용 권한을 확립했고, 4바이트 서브협상은 클라이언트가 지정한 문자 기하 정보를 담았으며, 운영체제 갱신, 자식 프로세스 통지, 애플리케이션 재배치는 별개의 하류 이벤트였다. 어느 것도 픽셀, 신원 또는 사람이 실제로 무엇을 보았는지 증명하지 못했다.

Telnet 기본 사양은 프린터 폭과 페이지 길이가 정해지지 않은 가상의 네트워크 가상 터미널(Network Virtual Terminal)에서 출발했다. 이 소박한 기본값이 서로 다른 시스템들의 상호 운용을 가능하게 했지만, 화면 지향 애플리케이션에 몇 개의 문자 셀이 사용 가능한지 알려주지는 못했다. 1988년 무렵, Telnet 클라이언트는 고정된 물리적 터미널이 아니라 크기 조절이 가능한 그래픽 창 안에서 점점 더 흔해지고 있었다.

RFC 1073은 NAWS(Negotiate About Window Size, 옵션 31)로 이 불일치를 다루었다. 핵심 설계 선택은 단순히 더 큰 수치가 아니라, 그 사실을 누가 통제하는가를 바꾼 것이었다. 클라이언트가 자기 로컬 창을 완전히 통제하고 서버에 현재 기하 정보를 알렸다. 서버는 수락과 사용을 통제하는 권한을 유지했다.

보고보다 먼저 권한이 왔다

Telnet 옵션은 작은 대칭 어휘를 사용했다. 서버는DO NAWS를 보낼 수 있고, 기하 정보를 제공하려는 클라이언트는WILL NAWS로 답했다. 어느 쪽이든DON'T나WON'T로 거부할 수 있었다.옵션 프레임워크는 이 첫 교환을 더 풍부한 서브협상으로 들어가는 관문으로 취급했지, 그 풍부한 정보 자체로 취급하지 않았다.

이 구분은 흔한 증거적 지름길을 막는다.DO와WILL은 양측이 옵션 상태에 들어갔음을 증명한다. 너비와 높이가 이후 전송되었음을 증명하지는 않는다. 서버가 그 값을 저장했거나, 터미널 드라이버를 변경했거나, 프로세스에 통지했거나, 출력을 재배치했음을 증명할 일은 더 없다.

합의 후 클라이언트는IAC SB NAWS, 2바이트 너비, 2바이트 높이,IAC SE를 보낼 수 있었다. 두 차원 모두 인터넷 바이트·비트 순서를 사용했으며 픽셀이 아니라 문자를 기술했다. 값은 65,535까지 가능했다. Telnet이 옥텟 255를 IAC로 예약했기 때문에 그 네 개의 데이터 바이트 안에 나오는 255는 모두 두 번 써야 했다. 문법은 작았지만, 숫자가 존재하기 전까지는 올바른 프레이밍과 이스케이프 해제에 여전히 의존했다.

0은 크기가 0인 창이 아니었다. 해당 차원의 값이 제공되지 않고 있음을 뜻했다. 그러면 서버는 별도로 교환된 터미널 유형 정보를 참고할 수도 있는, 운영체제별 가정을 선택했다. 저장된 0은 따라서 명시적 불확실성을 담는다. 이를 “0열”로 바꾸면 프로토콜이 보존한 의미가 파괴된다.

창 크기 변경은 응답이 아니라 또 다른 진술을 만들었다

RFC 1073은 창이 바뀔 때마다 클라이언트가 서브협상을 다시 보낼 수 있도록 했다. 예시는 24행 80열에서 64행 80열로 이동했다. 새 DO/WILL 교환은 필요 없었다. 로컬 크기 변경이 새 증거를 만들었고, 클라이언트는 그 증거를 기존 Telnet 스트림에 넣을 수 있었다.

두 번째 보고는 첫 번째 보고에 대한 응답이 아니었다. 서버가 어느 값이든 가지고 행동했는지도 말해주지 않았다. 옵션은 자식 프로그램의 반응에 대한 성공 응답도 정의하지 않았다. 따라서 혼잡한 경로에서 관찰자는 세 개의 다른 시점을 볼 수 있었다: 로컬 창이 바뀐 시점, NAWS 바이트가 도착한 시점, 그리고 원격 애플리케이션이 이후 어떤 기하 정보로 렌더링한 시점. 세 가지를 모두 “창 크기 변경”이라고 부르면 지연과 실패가 가려진다.

이 문서는 서버의 자유에 관해 이례적으로 직접적이었다. 창 크기 정보는 참고용이었다. 서버는 NAWS를 수락하면서도 제출된 데이터를 사용하지 않을 수 있었다. 일부 운영체제는 세션이 시작된 뒤 터미널 크기를 갱신할 수 없었다. 그 경우 서버는 처음에 옵션을 수락한 뒤DON'T NAWS를 보내 이후 보고를 금지할 수 있었다. 클라이언트 창은 계속 바뀌는 동안 네트워크 대화는 의도적으로 그것을 기술하는 것을 멈출 수 있었다.

이는 모순이 아니라 통제권의 분할이었다. 클라이언트가 기술되는 대상을 통제했다. 서버는 보고를 원하는지, 그리고 자신의 로컬 스택이 그것을 활용할 수 있는지를 통제했다.

NAWS는 오해를 낳는 양방향 모델을 대체했다

이전 Telnet 옵션들은 출력 라인 폭과 출력 페이지 크기를 별도로 협상했다. RFC 1073은 NAOL과 NAOP가 그래픽 창에 대해 잘못된 의미론을 갖고 있다고 주장했다. 이 옵션들은 양방향이어서 서버가 클라이언트의 라인 폭이나 페이지 크기를 통제할 수 있다는 인상을 주었고, 각 축은 253자로 제한되었다. 또한 문서가 인용한 당시 기록에 따르면 실제로 널리 쓰이지도 않았다.

NAWS는 창 시스템들이 보통 너비와 높이를 함께 바꾸기 때문에 이 둘을 함께 보냈다. 더 중요한 것은, 클라이언트 기하 정보를 대등한 통제자들 간의 거래라고 부르는 것을 멈춘 점이다. 클라이언트는 로컬 상태를 보고했고, 서버는 반응 방식을 결정했다. 프로토콜은 흔히 힘을 더하는 것이 아니라 잘못된 행위자에게 힘을 부여하기를 거부함으로써 더 명확해진다.

이 구분은 해석도 보호한다. 서버는 옵션 사용을 요청할 수 있었지만 NAWS를 통해 로컬 그래픽 창의 크기를 바꿀 수는 없었다. 클라이언트의 보고는 문자 셀 용량을 기술했으며 물리적 모니터 크기를 기술하지 않았다. RFC 예시의 24행 300열이라는 값은 유효한 문자 배치이지 이례적으로 넓은 유리판의 증거가 아니었다.

유형, 속도, 기하는 별개의 사실로 남았다

주변 Telnet 옵션들이 유용한 이유는 정확히 하나의 “터미널 프로필”로 합쳐지지 않기 때문이다.RFC 930은 서버가 요청하는 터미널 유형 교환을 정의하며, 수신이 곧바로 처리 변경을 함축하지 않음을 명시했다.RFC 1091은 이후 클라이언트가 사용 가능한 에뮬레이션 모드를 순환하도록 하면서도 요청 권한은 서버에 유지했다.

RFC 1079는 옵션 32를 터미널 속도에 할당했다. 권한 확립 후 요청자는 ASCII 송수신 속도 쌍을 물었고, 상대방이 자발적으로 속도를 보내지는 않았다. 구현은 지원하지 않는 속도를 안전한 방향으로 반올림할 수 있었다. NAWS는 다른 방식으로 작동했다: 권한 확립 후 클라이언트는 다시 물어지지 않아도 매 로컬 크기 변경을 보고할 수 있었고, 값은 속도 문자열이 아니라 이진 축이었다.

터미널 유형은 NAWS가 한 축에 0을 제공할 때 서버가 대체값을 고르는 데 도움을 줄 수 있었다. 그렇다고 유형이 기하 측정이 되는 것은 아니다. 속도는 패딩이나 인터페이스 선택을 안내할 수 있었다. 그렇다고 속도가 창 차원이 되는 것은 아니다. 이 프로토콜 계열은 각 주장을 충분히 좁게 유지해서 수신자가 어떤 로컬 정책을 적용 중인지 알 수 있게 했다.

IANA Telnet Options 레지스트리는 여전히 NAWS를 31에, TERMINAL-SPEED를 32에 배치한다. 이 레지스트리는 코드 할당과 문서 출처를 증명한다. 현재 어떤 서비스가 두 옵션 중 하나를 구현하는지, 어떤 구현이 RFC를 따르는지, 특정 세션이 이를 사용했는지는 증명하지 않는다.

4바이트 보고 하나가 여러 로컬 권한을 거쳤다

RFC 1073의 구현 개요는 수신이 왜 결과가 아니었는지를 보여준다. 그래픽 환경이 먼저 Telnet 클라이언트에 창이 바뀌었음을 알렸다. 4.3BSD에서 클라이언트는SIGWINCH를 잡을 수 있었다. 클라이언트는 이후 NAWS를 보냈다. 서버는ioctl로 터미널 상태를 바꾸고, 아마도 셸인 자식 프로세스에 시그널을 보낼 수 있었다.

이 체인의 모든 동사는 조건적이었다. 창 관리자, Telnet 클라이언트, 네트워크 파서, 서버 터미널 계층, 자식 애플리케이션이 서로 다른 전이를 소유했다. 한 경계의 추적이 다음 경계를 인증할 수 없었다. 시그널을 받은 자식조차 캐시된 레이아웃 상태를 유지하거나 처리 전에 출력을 포맷할 수 있었다. 올바르게 포맷된 바이트는 사람이 그것을 보았음을 여전히 증명할 수 없었다.

이 계층적 서술은 성공 플래그보다 내구성이 강하다. 원격 화면이 잘못 줄바꿈될 때 운영자가 어디를 볼지 알려준다. 옵션 상태, 원시 보고, 이스케이프 처리, 저장된 기하 정보, 자식 통지, 애플리케이션 동작은 각각 독립적으로 검증 가능하다.

출처와 한계

RFC 1073은 1988년의 제안 옵션과 당시 구현 예시를 문서화한다. 보편적 채택, 현재 배포, 제품 준수성, 또는 SSH 의사 터미널, 반응형 웹 디자인, 원격 데스크톱 시스템으로의 직접적 계승을 확립하지 않는다. RFC 854와 855는 주변 Telnet 문법을 설명하고, RFC 930, 1079, 1091은 인접한 상태 교환을 확립할 뿐 NAWS가 적용되었다는 증거가 아니다.

역사적 교훈은 더 좁다. 보고는 수신자에게 명령하지 않고도 가치를 가질 수 있다. NAWS는 누가 창을 소유하는지, 누가 대화를 거부할 수 있는지, 0이 무엇을 뜻하는지, 증거가 어디서 멈추는지를 말함으로써 기하 정보 변경을 이식 가능하게 만들었다. 4바이트는 클라이언트 상태를 기술했다. 반응은 여전히 로컬에 남았다.