요약

  • 1983년 12월의 RFC 884는 Telnet TERMINAL-TYPE에 옵션 번호 24를 부여했다. DO와 WILL이 교환을 허락하고, SEND가 이름을 물으며, IS가 답한다.
  • 단말기는 구체적인 이름부터 좀 더 포괄적인 이름까지 차례로 제시할 수 있었다. 마지막 이름을 반복하면 목록이 끝난다. 1985년 RFC 930는 질문과 자발적인 답변이 엇갈리는 혼선을 고쳐, IS를 SEND의 답변으로 제한했다.

옛 컴퓨터의 화면 메뉴에는 작은 함정이 있었다. 개발자 책상에서는 칸이 딱 맞는데, 원격 사용자의 화면에서는 문자가 엉뚱한 자리에 찍힌다. 네트워크가 문자를 잃어버린 것은 아니다. 한 단말기의 커서 이동 명령을 다른 단말기가 알아듣지 못한 것이다. 종이에 글자를 찍는 텔레타이프 앞에서 색깔 메뉴를 펼치려는 시도라면 더 난처하다. 멀리 있는 서버는 먼저 상대 화면이 누구인지 알아야 했다.

Telnet 기본 규격은 네트워크 가상 단말기라는 공통 출발점을 만들었다. 양쪽은 실제 기종을 모르는 상태에서도 이 가상의 장치로 대화를 시작할 수 있었다. 커서 위치나 색상처럼 더 풍부한 표현이 필요해지면 이야기가 달라진다. Marvin Solomon과 Edward Wimmers는 RFC 884에 단말기의 자기소개 방법을 적었다.

이 옵션의 번호는 24였다. 처음 상태인 DON'T와 WON'T에서는 기종 정보를 주고받지 않는다. 서버가 DO를 보내고 상대가 WILL로 응하면 비로소 이름을 물을 자격이 생긴다. 허락만으로 이름이 전송되지는 않는다. 서버는 하위 명령 SEND(코드 1)를 보내고, 단말기 쪽은 IS(코드 0) 뒤에 NVT ASCII 문자열을 싣는다. 문서의 예시는 IBM-3278-2다. 대문자와 소문자는 같은 이름으로 취급한다.

RFC 884에 실린 이름 목록은 당시 전산실을 둘러보는 기분을 준다. IBM 디스플레이, TOPS20 환경의 기계, Unix에서 쓰던 단말기가 함께 나온다. DEC-VT100과 TELETYPE-33도 있다. 같은 Telnet 연결로 만날 수 있는 장비들이지만 화면을 다루는 능력은 제각각이었다. 서버가 이름을 알아보면 로컬 단말기 드라이버에 넘겨 커서나 색상에 맞는 출력을 선택할 수 있었다. 규격은 BINARY 옵션을 함께 쓰는 경우도 언급했다.

그런데 이름은 종종 사람을 곤란하게 한다. 저자들은 IBM3278-2와 IBM-3278/2처럼 서로 다른 표기를 예로 들었다. 상대가 이름을 모를 때 보내는 특별한 거부 응답은 없었다. 대신 특정 모델명과 더 일반적인 명칭을 모두 가진 단말기는 SEND가 반복될 때마다 구체적인 것에서 일반적인 것으로 바꿔 답할 수 있었다. 내놓을 이름이 떨어지면 마지막 이름을 다시 보낸다. 같은 답이 두 번 연속 나오면 서버는 질문을 멈춘다. 기계 사이의 대화에 “혹시 다른 이름으로도 불리나요?”라는 한마디가 숨어 있었다.

알아들을 만한 이름이 없으면 UNKNOWN도 쓸 수 있었다. 이름을 받은 서버는 그 정보를 프로그램에 건네고, 프로그램이 실제 표시 방법을 결정한다. 잘 아는 단말기라면 가상 단말기의 기본 표현을 넘어서는 기능을 쓸 수 있다. 이름과 화면 동작 사이에는 이렇게 호스트의 판단이 자리했다.

첫 규격에는 말을 가로채는 상황이 남아 있었다. DO와 WILL이 끝나면 단말기 쪽은 질문을 기다리지 않고 IS를 보내도 됐다. 저자들은 동시에 SEND가 오더라도 같은 정보가 한 번 더 전달되는 정도로 생각했다. 1985년 RFC 930는 더 까다로운 경우를 지적했다. 먼저 보낸 답과 질문이 길에서 엇갈리면, 다음 답이 질문에 대한 답인지 두 번째 이름인지 헷갈린다. 수정된 규칙은 SEND가 온 뒤에만 IS를 보내도록 했다.

1989년 RFC 1091은 여러 단말기 에뮬레이션 모드를 차례로 소개하고, 서버의 요청에 따라 모드를 바꾸는 기능까지 더했다. 1983년의 이야기는 그보다 소박하다. 원격 컴퓨터가 사람의 화면에 제대로 그리려면 그 화면의 이름을 알아야 했다. 첫 이름이 통하지 않으면, 조금 덜 까다로운 별명으로 다시 소개하면 됐다.