요약

  • RFC 1096은 Telnet 옵션 35를 정의하여, 한 피어가 X 표시 위치를 요청하고 받을 수 있도록 했다. WILL과 DO는 단지 이후 논의를 위한 허가를 부여했을 뿐이며, 로케이터는 통제된 SEND/IS 서브협상으로만 전달되었다.
  • 값은 Unix DISPLAY 형식<host>:<dispnum>[.<screennum>]을 따랐다. Telnet 클라이언트는:0같은 로컬 약식 표기를 원격 호스트에 의미 있는 형태로 바꿔야 했지만, 그 재작성은 호스트를 인증하거나 표시 장치가 도달 가능함을 증명하지 않았다.
  • X는 별도의 프로토콜 경로로 남았다. 원격 애플리케이션은 여전히 X 서버에 연결하여 X 측 접근 및 인가 검사를 통과해야 했다. 따라서 Telnet을 통해 받은 로케이터는 허가도, 창 생성도, 사용자에게 보이는 결과도 증명하지 않았다.

원격 명령에는 로컬 맥락 한 조각이 없었다

문제는 두 대의 기계와 한 사람에서 시작된다. 그 사람은 X Window System 아래에서 Telnet 클라이언트를 실행하고, 원격 호스트에 접속하여 X 애플리케이션을 시작하는 명령을 입력한다. 이제 그 프로세스는 원격 호스트에 존재하며, 표시 장치는 로컬 워크스테이션에 붙어 있다. 원격 프로세스는workstation.example:0.0같은 목적지를 필요로 하지만, Telnet을 통해 물려받은 셸은 그것을 알지 못할 수 있다.

RFC 1096이 그 빠진 좌표를 공급했다. 1989년 3월에 제안 표준(Proposed Standard)인 Telnet X Display Location Option으로 공표된 이 문서는 옵션 코드 35를 할당하고, Telnet 서버가 클라이언트에 X 표시 위치를 요청하는 방법을 기술했다. 현재IANA Telnet Options 레지스트리는 여전히 35를 X Display Location으로 기록하고 있다.

이 옵션이 역사적으로 흥미로운 이유는 X 그래픽을 Telnet 안으로 담으려 하지 않기 때문이다. 이는 이후의 연결이 시도될 수 있도록 충분한 정보를 운반한다. Telnet 세션은 맥락의 경계를 넘어 로케이터를 운반할 뿐, 프로토콜 사이의 경계를 지우지 않는다.

그 절제는 현대적 언어 속에서 쉽게 사라진다. “원격 애플리케이션이 로컬 표시 장치를 사용한다”는 말은 하나의 연속된 세션처럼 들린다. 그러나 전송 계층에는 적어도 두 개가 있다. 명령을 전달하는 기존 Telnet 연결과, 원격 애플리케이션이 나중에 열 수도 있는 X 클라이언트 연결이다. RFC 1096은 이 둘 사이의 인계(handoff)를 다룬다.

WILL과 DO는 대화를 열었지, 표시 장치를 열지 않았다

기본 상태는 거부이다. WON'T와 DON'T. Telnet 로그인이 자동으로 X 표시 장치를 알리지는 않는다. 피어들은 먼저RFC 854가 정의한 명령 어휘로 옵션 35를 협상해야 한다.

WILL X-DISPLAY-LOCATION은 피어가 이후 서브협상에서 위치를 보낼 의사가 있음을 말한다. DO는 다른 피어가 이를 받을 의사가 있음을 말한다. WON'T와 DON'T는 그 역할을 거절한다. RFC 1096은 경계를 이례적으로 명확하게 만든다. WILL과 DO는 미래의 논의를 위한 허가를 얻고 부여하는 데만 사용된다.

이 정식화는RFC 855의 일반 아키텍처를 따른다. Telnet 옵션 서브협상은 두 단계로 이루어진다. 먼저 당사자들이 옵션을 논의할 수 있음에 합의하고, 그다음 매개변수 자체가 SB와 SE 사이에서 오간다. 어느 쪽이든 나중에 WON'T나 DON'T로 허가를 끝낼 수 있다.

이 구분은 Telnet 용어를 넘어 중요하다. 긍정적 협상은 프로토콜 상태에 대한 증거이다. 한 피어가 역할을 제안했고 다른 피어가 그 역할을 수락했음을 보여준다. 그러나 표시 장치가 존재하고, 사용자에게 속하고, 연결을 받아들이고, 애플리케이션을 인가한다는 것은 보여주지 않는다. 주소를 물어볼 허가는 그 주소가 가리키는 자원을 사용할 허가가 아니다.

SEND와 IS는 일방적 요청 규율을 부과했다

협상 후에도 표시 값은 저절로 나타나지 않는다. RFC 1096은 주도권과 응답을 정확히 배정한다. DO를 보낸 피어만 SEND 서브커맨드를 발행할 수 있다. WILL을 보낸 피어만 IS로 응답할 수 있다. willing 공급자는 그 요청 없이 위치를 자발적으로 제공할 수 없다.

이 명령 리듬은 X를 위해 고안된 것이 아니었다. RFC 1096은 그것이RFC 1079, 즉 Telnet 터미널 속도 옵션을 면밀히 따른다고 말한다. 그 앞선 옵션 역시 값의 논의 합의와 요청된 SEND/IS 교환을 구분한다. 패턴을 재사용함으로써 발명을 줄이고 구현자에게 상태 기계를 익숙하게 만들었다.

이 유추에는 한계가 있다. 터미널 속도는 상태 문자열이다. X 표시 로케이터는 자체 통제를 갖춘 또 다른 서비스를 가리킨다. 비슷한 봉투 기계장치가 봉투 안의 값에 동일한 권위를 부여하지는 않는다. 이 패턴은 누가 물을 수 있고 누가 응답할 수 있는지에 답할 뿐, 값이 신뢰할 수 있고 사용에 충분한지에는 답하지 않는다.

RFC 1096의 예시는 이 교환을 구체화한다. 서버가 SEND를 보내면, 클라이언트는 NVT ASCII 문자열SRI-NIC.ARPA:0.0으로 응답한다. 예시 서브커맨드는 22옥텟을 차지한다. IS가 도착하면 서버는 Telnet 피어가 정확히 그 형식의 주장을 공급했다는 증거를 갖는다. 그러나 아직 X 연결은 관찰하지 못했다.

:0을 원격 로케이터로 바꾸기

값은 Unix DISPLAY 관례를 따른다.<host>:<dispnum>[.<screennum>]이며, 공백이나 기타 여분 문자는 없다. 이 문법은 세 가지 서로 다른 선택을 결합한다. 호스트는 기계 또는 네트워크 목적지를 식별하고, 표시 번호는 X 서버 인스턴스를 식별하며, 선택적 화면 번호는 그 표시 내의 한 화면을 고른다.

로컬 약식 표기는 이 옵션의 가장 계몽적인 구현 의무를 만든다. 사용자의 워크스테이션에서:0이나unix:0.0은 충분할 수 있다. 로컬 프로그램에 로컬 전송과 0번 표시를 사용하라는 뜻이다. 그러나 그대로 원격 호스트에 보내면 “로컬”은 잘못된 기계를 가리킨다. 따라서 RFC 1096은 Telnet 클라이언트가 전송 전에 그런 값을 적절히 수정할 것을 요구한다.

클라이언트는 범위를 번역한다. 하나의 호스트 내에서만 의미 있는 로케이터를 받아 다른 호스트에서 의미 있도록 의도된 로케이터를 구성한다. 그 행위는 운영상 유용하면서도 여전히 인식적으로 겸손할 수 있다. 문서는 재작성이 호스트명을 인증하거나, DNS를 확인하거나, 경로를 검사하거나, 포트를 열거나, 사용자가 표시 장치를 소유함을 증명한다고 말하지 않는다.

올바른 형태의 문자열은 거짓이거나, 낡았거나, 도달 불가능할 수 있다. 정확한 로케이터조차 원격 애플리케이션을 거부하는 정책을 가진 서버를 가리킬 수 있다. 구문은 첫 번째 검증 계층이지 마지막이 아니다.

X 연결은 Telnet 옵션이 끝난 뒤에 시작되었다

RFC 1013, 즉 1987년 X Window System 프로토콜 버전 11 문서가 다음 경로를 기술한다. X 클라이언트는 X 서버에 자체 IPC 연결을 수립한다. TCP의 경우 표시 번호 N은 포트 6000+N과 연관된다. 따라서 Telnet을 통해 공급된 로케이터는 원격에서 시작된 프로세스가 호스트, 표시 및 엔드포인트를 고르는 데 도움을 줄 수 있다.

그러나 Telnet TCP 스트림은 그 X 연결로 변하지 않는다. 옵션 35는 X 요청도 창 내용도 운반하지 않는다. 터널, 프록시, 포워딩 채널이 아니다. 원격 애플리케이션은 X 클라이언트가 되어, 경로·전송·실패 양상이 서로 다른 또 다른 연결을 시도한다.

이 분리는 문제 해결을 명확하게 한다. IS의 수신은 로케이터가 Telnet 서버에 도달했음을 뜻한다. 이후의 TCP 실패는 주소 지정, 라우팅, 필터링, 수신 대기 상태 또는 다른 네트워크 조건에 속한다. X 설정 거절은 그보다 더 뒤에 속한다. 이 모든 것을 “Telnet 옵션 실패”로 묶으면 경계를 찾는 데 필요한 증거가 파괴된다.

이는 노출 면에서도 명확하게 한다.:0을 네트워크에서 보이는 호스트로 재작성하면 X 서버가 주소 지정되는 표면이 바뀔 수 있다. RFC 1096은 형식 전환을 기술할 뿐, 그런 원격 사용이 적절한지 판단하는 정책을 기술하지 않는다. 그 결정은 로컬 운영자와 X 서버에 남는다.

X는 자체 인가 질문을 던졌다

X 프로토콜의 연결 설정에는 바이트 순서, 프로토콜 버전, 인가 프로토콜 이름, 인가 데이터가 포함된다. 서버는 설정을 거부하고 이유를 반환하거나, 수용하고 벤더·형식·화면·자원 식별자에 대한 정보를 반환할 수 있다. 핵심 문서는 유효한 인가 메커니즘의 선택을 핵심 프로토콜 밖에 두고 있다.

RFC 1013은 또한 호스트 접근 통제 목록을 기술한다. 이 목록은 로컬 호스트와 구성된 호스트로 시작하며, 권한 있는 클라이언트가 변경할 수 있고, 서버가 연결을 거절하게 만들 수 있다. 따라서 호스트 수용과 설정 인가는 Telnet 협상에서 조용히 물려받는 허가가 아니라 X 측 통제이다.

현재의 IANA 레지스트리는 역사를 다시 쓰지 않으면서 분류를 더 정밀하게 한다. X Display Location은 옵션 35이고, Telnet Authentication은 별도로 옵션 37로 등록되어 있다. 이 현재 레지스트리의 분리는 옵션 35가 인가 메커니즘으로 오해되는 것을 막는 데 도움이 된다. 그러나 1989년의 어떤 배포가 이후의 옵션을 사용했거나 특정 보안 조합을 썼음을 입증하지는 않는다.

운영자는 증거의 순서를 지켜야 한다. DO/WILL은 옵션 교환을 수행할 허가를 보여준다. SEND/IS는 피어가 로케이터를 공급했음을 보여준다. 도달 가능한 TCP 엔드포인트는 네트워크 경로와 수신 응답을 보여준다. 수용된 X 설정은 X 서버가 자신이 적용한 통제 아래 연결을 수용했음을 보여준다. 이들은 누적된 관찰이지 서로 교환 가능한 판정이 아니다.

수용된 X 설정조차 결과에는 미치지 못했다

모든 앞선 단계가 성공했다고 가정하자. 원격 프로세스는 그럴듯한 로케이터를 받고, 6000+표시 번호 포트에 도달하며, X 설정을 통과한다. 더 많은 관문을 넘었지만, 사용자가 의도한 결과는 아직 입증되지 않았다.

애플리케이션은 자원을 만들고 요청을 발행해야 한다. X 서버가 그것을 처리해야 한다. 창이 맵핑되고, 계속 이용 가능하며, 의도한 출력을 담고 있어야 할 수 있다. 사용자는 관련 화면을 보고 있고 그것과 상호작용할 수 있어야 한다. 수용된 설정은 연결에 대한 강한 증거이지, 최종 인간 결과의 관찰이 아니다.

이는 pedantry가 아니다. 자동화는 종종 가장 먼저 얻은 성공을 자신이 원하는 결론으로 승격시킨다. 명령이 0을 반환했으니 서비스가 건전해야 한다. 로케이터가 반환되었으니 자원이 사용 가능해야 한다. 연결이 수용되었으니 사용자가 창을 봤어야 한다. RFC 1096은 왜 그런 승격에 새 증거가 필요한지에 대한 간결한 사례 연구이다.

문서의 겸손은 그 설계 품질의 일부이다. 이 문서는 주소의 진실, 라우팅, 인증, 인가, 애플리케이션 정확성, 지각을 해결한다고 주장하지 않으면서 하나의 조정 문제를 해결한다. 좁은 계약 덕분에 각 후속 실패를 귀속시킬 수 있다.

레지스트리는 결과가 아니라 메커니즘을 보존한다

옵션 35는 여전히 IANA 표에 있지만, 레지스트리 항목은 배포 인구조사가 아니다. 할당된 코드와 그 정의 참조를 알려줄 뿐이다. 옵션이 얼마나 널리 구현되었는지, 특정 시스템이 얼마나 오래 사용했는지, 또는 특정 사용자가 이를 통해 실제로 창을 얻었는지는 보여주지 않는다.

소스 패킷은 정밀한 역사적 서술을 지지한다. Telnet에는 요청된 X 표시 로케이터 전달을 위한 옵션이 있었고, 그 옵션은 익숙한 SEND/IS 패턴을 물려받았으며, 로컬 전용 값은 재작성되어야 했고, X는 이후 별도의 연결과 별도의 통제를 사용했다. 그러나 사건, 특정 호스트의 정책, 보편적 보안 자세에 대한 이야기는 지지하지 않는다.

따라서 RFC 1096의 지속 가능한 교훈은 통합의 주장보다 더 작고 더 유용하다. 시스템은 경계를 넘어 권위를 이전하지 않으면서 맥락을 전달할 수 있다. 로케이터는 Telnet을 건너갔다. 접근은 여전히 X에 속했다.

출처