요약

  • RFC 779은 Telnet 클라이언트가 사용자의 물리적 위치를 읽을 수 있는 문자열로 원격 호스트에 건네는 SEND-LOCATION 옵션을 정의했다.
  • 기본 상태는 전송 중지였다. 클라이언트의 제안, 서버의 동의, 문자열 전송, 사용자 목록에 표시하는 결정은 서로 다른 단계였다.

1981년에 동료를 찾는 일은 컴퓨터 앞에서 시작해 복도로 이어질 수 있었다. 공유 시스템에 누가 접속했는지 물으면 이름과 단말기가 있는 방, 운이 좋으면 근처 전화기를 알아낼 수 있었다. 그런데 그 동료가 다른 연구소에서 원격 로그인했다면 서버가 아는 것은 대개 연구소 이름뿐이었다. “옆 건물 어딘가”는 연락처가 아니다. Earl Killian은 RFC 779에서 사용자 쪽 Telnet 프로그램이 좀 더 쓸모 있는 위치 설명을 서버로 보낼 방법을 제안했다.

당시 사용자 명단은 사소한 장식이 아니었다. NAME/FINGER를 다룬 RFC 742는 현재 접속자의 목록에 전체 이름과, 알아낼 수 있는 경우 단말기의 물리적 위치를 싣도록 설명했다. 작업 이름이나 아무 입력 없이 지난 시간도 목록에 들어갈 수 있었다. 같은 건물 사람은 그 단말기 앞까지 걸어가거나 가까운 전화기로 걸면 됐다. 원격 로그인은 이 편리한 안내를 흐리게 했다. 서버가 본 것은 네트워크 연결의 출발 기관이지 그 기관 안의 책상 번호가 아니었다.

Killian이 붙인 이름은 SEND-LOCATION, Telnet 옵션 번호는 23이다. 처음 상태는 WON'T와 DON'T로, 위치 문자가 저절로 흐르지 않는다. 사용자 쪽 프로그램이 위치를 알고 있으면 WILL SEND-LOCATION을 제안할 수 있었다. 서버는 DO SEND-LOCATION으로 받아들이거나 DO로 먼저 요청할 수 있었다. 합의한 뒤 클라이언트는 출력 가능한 ASCII 문자를 IAC SB에서 IAC SE까지의 하위 협상 안에 넣어 보냈다. 방 이름 같은 설명은 사용자 쪽에서 온다. 멀리 있는 서버가 건물을 직접 살피는 이야기가 아니다.

Telnet의 짧은 동사들은 각자의 선택을 드러낸다. 보내는 쪽은 WON'T로 거절하고 받는 쪽은 DON'T로 그만 보내라고 할 수 있었다. 서버가 요청해도 클라이언트가 응하지 않을 수 있다. 합의가 끝난 직후가 아니라 세션 중 나중에 문자열을 보낼 수도 있었다. 따라서 “옵션이 있다”와 “서버가 글자를 받았다”는 다른 사건이다. 서버가 받은 글자를 접속자 명단에 어떻게 쓸지는 그다음 사건이다.

비슷한 발상은 더 일찍 있었다. SUPDUP 디스플레이 프로토콜 RFC 734는 콘솔의 위치 문자열을 원격 시스템에 보내는 명령을 설명했다. 원격 시스템은 보통 이를 저장했다가 who 명단에 사용했다. RFC 779은 같은 생활의 문제를 Telnet 옵션 협상으로 가져왔다. 사람 가까이에 있는 기계는 위치를 알고, 멀리 있는 기계는 사용자 목록을 갖고 있었다. 두 기계가 대화를 해야 한 줄의 안내문이 건너갔다.

NAME/FINGER는 누가 어디 있는지 보여 주는 목록을 다뤘고, SEND-LOCATION은 Telnet 세션에서 그 목록의 재료가 될 문장을 전달했다. RFC 779은 ITS를 그 정보를 활용할 수 있는 시스템으로 들었다. 전달된 문장을 어느 화면에 어떤 형태로 표시할지는 호스트의 프로그램이 맡았다. 받은 우편과 게시판에 붙은 쪽지는 같은 물건처럼 보여도 사이에 편집자의 손이 한 번 지나간다. 이때 편집자는 서버 코드였다.

이 작은 옵션이 다룬 거리는 네트워크의 거리가 아니라 복도의 거리였다. 기관 이름만으로는 전화를 어디에 걸지 알기 어렵다. 위치 문자열 한 줄이면 질문이 구체적이 된다. RFC 779은 클라이언트가 그 한 줄을 내놓고 서버가 사용 방식을 고르는 순서를 만들었다. 단말기 연결은 그 순간 책상 앞 사람에게 가는 길도 조금 알려 주기 시작했다.