요약

  • RFC 1205는 IBM 5250 워크스테이션 데이터 스트림을 Telnet으로 주고받는 인터페이스를 기록했다. 양쪽은 Binary, End-of-Record, Terminal-Type에 합의하고 IBM의 기존 패스스루 방식에서 가져온 레코드 형식을 처리해야 했다.
  • 호스트가 Cancel Invite를 보내면 클라이언트는 같은 명령으로 응답하고 새 읽기 명령 전까지 일반 이용자 데이터를 멈춘다. System Request 예시는 화면 저장, 메뉴 입력, 화면 복원, 입력 재개의 흐름을 보여 준다.

키보드가 있어도 발언 순서는 따로 있었다

RFC 1205에서 가장 선명한 문장은 속도나 화면 색에 관한 설명이 아니다. 서버가 Cancel Invite를 보낼 때 클라이언트는 이를 되돌려 확인하고, 서버가 다시 워크스테이션을 초대할 때까지 이용자 데이터를 보내지 않는다. 여기서 초대란 호스트가 읽기 명령을 내렸다는 뜻이다. 사용자는 계속 키보드 앞에 앉아 있어도 그 세션의 입력 경로는 호스트의 명령에 따라 열린다.

System Request의 긴 예시는 이 규칙이 실제 사용 흐름에서 어떤 일을 하는지 보여 준다. 사용자가 대응하는 키를 누르면 클라이언트가 플래그를 보낸다. 호스트는 현재 입력을 취소하고 화면을 저장하게 한 뒤 시스템 메뉴를 내놓는다. 메뉴에 대한 답은 호스트의 Put/Get 단계에서 받아들인다. 작업이 끝나면 저장한 화면을 복원하고 마지막 읽기 명령으로 이전 상태를 다시 초대한다. 유선 연결을 끊고 새로 여는 과정이 아니라, 연결 안에서 단말의 차례를 바꾸는 과정이다.

이 구분이 있어야 옛 단말을 단순한 복고풍 화면으로 보지 않게 된다. 네트워크는 바이트를 전달하지만 그 바이트가 입력 필드의 값인지, 시스템 요청인지, 화면 저장 명령인지는 5250의 규칙이 판단한다. 텔넷으로 목적지에 도착했다는 사실과 사용자가 제대로 입력할 수 있다는 사실 사이에 여러 약속이 놓여 있었다.

세 가지 합의가 5250 모드를 받쳤다

IBM은 여기서 새로운 Telnet 옵션을 만들지 않았다. 문서는 기존 Binary, End-of-Record, Terminal-Type 세 가지를 클라이언트와 서버가 최소한 지원해야 한다고 적었다. 협상 예시에서는 서버가 단말 종류를 묻고 클라이언트가 IBM-5251-11이라고 답한다. 이어 두 방향 모두 레코드 끝 표시와 바이너리 전송에 동의한다. 접속만 성공한 상태에서 화면 명령을 읽는 방식을 서로 다르게 생각하면, 같은 바이트도 다른 결과를 낳는다.

5250 단말도 하나의 녹색 화면으로 뭉뚱그릴 수 없다. RFC에는 24×80과 27×132 화면, 흑백과 컬러, 이중 바이트 문자 집합을 지원하는 모델이 함께 실렸다. 호스트가 단말 종류를 확인하는 이유는 화면의 크기와 문자 능력이 달랐기 때문이다. 별도 Query Device 예시에서는 호스트가 속성을 묻고 클라이언트가 응답한다. IP 주소만으로 장치의 화면 구조를 알 수는 없다.

Telnet 협상 뒤에는 5250 고유의 레코드가 이어진다. 먼저 여섯 옥텟의 고정 헤더, 그때는 네 옥텟인 가변 헤더가 나오고, 그 다음에 워크스테이션 데이터가 놓인다. 논리 레코드 길이는 헤더를 포함하지만 끝의 IAC EOR 표시는 포함하지 않는다. Telnet이 IAC 바이트를 두 번 쓰기 전의 길이를 센다는 점도 중요하다. 길이를 잘못 계산하면 다음 화면 명령이 시작되는 위치를 양쪽이 다르게 잡는다. TCP 조각의 경계로 이를 수습할 수 없다.

인터넷으로 옮겨 온 옛 호스트의 문법

이 헤더의 출발점은 IBM의 5250 Display Station Pass-Through였다. RFC는 이를 SNA 망에서 AS/400, System/36, System/38이 사용하던 방식이라고 설명한다. General Data Stream 레코드 종류도 그대로 담았다. 호스트는 익숙한 단말 방식을 보존하고 Telnet을 운반 수단으로 삼았다. 다른 회사나 개발자가 클라이언트를 만들려면 그 오래된 방식까지 배워야 했다.

문서는 5250의 모든 명령을 담지 않고 IBM 5250 Functions Reference Manual을 참조하도록 한다. 5장에서는 당시 매뉴얼의 오류를 바로잡고 아직 적히지 않은 기능을 설명한다. Insert Cursor 명령의 잘못 인쇄된 16진 값을 고치는 대목이나 행·열 제한을 명확히 하는 대목은 사소한 주석이 아니다. 옵션 세 가지를 완벽히 협상해도 명령 값이나 좌표를 틀리게 구현하면 화면이 엉키고 입력 위치가 달라진다.

인터넷 쪽의 접속 방법은 공개 문서로 설명됐다. 단말 화면 언어의 완전한 내용은 IBM의 매뉴얼까지 읽어야 한다. 호스트가 언제 입력을 받을지도 여전히 애플리케이션 명령에 달렸다. 전송 경로가 익숙한 Telnet이라고 해서 5250 단말이 일반적인 문자 창으로 바뀌는 것은 아니었다.

취소된 초대와 다시 열린 입력

4.2장의 단순한 예시는 서버가 0A 명령을 보내고 클라이언트가 확인한 뒤 평상시 입력을 멈추는 모습을 보여 준다. 4.3장의 긴 예시는 그 사이에 호스트가 Put/Get으로 메뉴 답을 받고 저장된 화면을 복원한 다음 Invite로 이전 상태를 다시 여는 과정을 보여 준다. 사용자에게 중요한 것은 이런 명령의 철자보다 그 순서다. 화면이 보이는데도 타자를 받지 않는 순간과 다시 받는 순간이 바로 여기서 갈린다.

RFC 1205에는 인터페이스와 교환 예시가 있고, 실제 사업장의 배치 건수나 날짜가 붙은 세션 기록은 없다. 실제 동작을 알려면 호스트와 클라이언트의 레코드 및 화면 상태를 함께 남긴 자료가 필요하다. 문서가 보여 주는 설계는 이미 충분히 구체적이다. 1991년 Telnet은 IBM 단말의 바이트를 실을 수 있었지만, 그 단말의 다음 입력 차례는 호스트의 초대가 결정했다.

출처