요약

  • RFC 1440는 대상 호스트에 계정이 없는 발신자가 비(非)우편 파일을 데몬에 전송해, 데몬이 그 파일을 저장해 두었다가 수신자가 나중에 처리하도록 할 수 있게 했다.
  • NULL ACK는 명령 하나를 수락한다는 신호였고, EOF나 연결 종료는 전송을 끝냈다. 그러나 그 어느 것도 수신자가 파일을 수락했거나 열었거나 사용했다는 증거가 되지 않았다.
  • 이 설계는 발신자의 부담을 줄였지만, 수신 측 수용 정책, 스풀 용량, 보존 기간, 인증, 실행 가능한 유사 사용자를 각각 별개의 로컬 책임으로 남겼다.

소포가 수령실에 도착했다

파일 전송의 통상적인 이야기는 수신자에서 시작했다. 사용자는 원격 시스템에 접속해 계정을 확인하고, 파일 시스템 작업을 선택하고, 전송을 시작했다. RFC 1440는 첫 번째 동사를 뒤집었다. Sender-Initiated File Transfer, 즉 Unsolicited File Transfer라고도 불린 이 방식은 발신자가 먼저 시작할 수 있게 했다. 'Unsolicited(요청받지 않은)'라는 말은 좁은 기술적 의미를 지녔다. 수신자가 그 트랜잭션을 시작하지 않았다는 뜻일 뿐이다. 이 문서는 파일이 원치 않는 것이라는 더 강한 추론을 명시적으로 거부했다.

영감은 BITNET 같은 NJE 네트워크에서 왔다. 그곳에서는 전자 우편의 틀 밖에서 파일을 보낼 수 있었다. 저자는 이 빠진 서비스를 표면 우편이 아니라 소포를 보내는 것에 비유했다. 수신자는 네트워크 트랜잭션에 참석할 필요가 없었고, 발신자는 목적지 호스트에 계정이나 사전 등록이 필요 없었다.

이 거래가 중요한 이유는 작업의 위치를 옮겼기 때문이다. 발신자는 단순한 발신 행위를 얻었다. 목적지는 항상 열려 있는 수신기, 수용 정책, 임시 저장소, 수신자 이름 공간, 그리고 나중의 인계 절차를 떠안았다. 편의가 상태를 없애지는 않았다. 상태를 수신 측으로 옮겼을 뿐이다.

하나의 소켓이 서로 다른 두 객체를 실었다

제안된 데몬은 TCP 포트 608에서 수신 대기했다. 클라이언트는 텍스트 명령 나열과 그 뒤를 따르는 바이너리 데이터를 보냈다. RFC 1440는 이 작업 스트림을 두 파일의 연결로 묘사했다. 제어 파일과 데이터 파일이다. 두 파일은 하나의 소켓을 통해 이동했지만 같은 의미를 지니지는 않았다.

FILE은 발신자, 선택적 인증 토큰, 정확하거나 근사적인 크기를 선언했다. USER는 로컬 수신자 또는 서비스를 지정했다. TYPE은 표현 방식을 서술했다. 이 세 명령은 DATA보다 앞서 필요했다. NAME, DATE, 레코드 형식 매개변수는 부가 정보를 더할 수 있었다. EOF는 현재 파일을 끝내고, ABORT는 부분 파일의 폐기를 요청했으며, QUIT는 작업을 종료했다.

명령과 바이트를 함께 두면 전송 계층이 단순해졌지만, 수신자는 이를 별도로 저장할 수도 있었다. 덕분에 수신기는 외부 파일 형식을 일일이 해석하지 않아도 되었다. 그러나 이는 대응 관계 유지 의무를 만들었다. 호스트는 어떤 명령이 어떤 본문에 속했는지, 무엇이 수신되었는지, 나중에 어떤 처분이 적용되었는지를 보존해야 했다.

0바이트는 의도적으로 작은 주장만 했다

각 명령 뒤에 서버는 그 명령을 수락하거나 거부했다. 긍정 신호는 NULL ACK였다. 0번 옥텟으로 시작하는 응답 패킷이다. 하나의 ACK는 하나의 명령을 커버했다. 그것이 트랜잭션 전체를 소급해 승인하지는 않았다.

이 범위는 운영상 중요하다. 서버는 선언된 크기가 들어맞아 보이므로 FILE을 수락했다가, 그런 로컬 수신자가 존재하지 않으므로 USER를 거부할 수 있다. 메타데이터를 수락한 뒤 데이터를 쓰면서 실패할 수도 있다. 크기 자체가 부정확할 수 있으므로 첫 용량 판단은 잠정적이었다. 긍정적 명령 응답의 연쇄는 일련의 로컬 판단이었지, 최종 객체에 대한 하나의 보장이 아니었다.

서버의 첫 인사말은 호스트명, UFT 프로토콜 버전, 서버 구현을 밝혔다. 이는 동기화와 버전 합의를 지원했다. 인증된 신원 진술은 아니었다. FILE의 선택적auth필드는 구현되지 않은 티켓이었고, 문서는 인증이 보장되지 않는다고 밝혔다.

스풀은 보관이지 동의가 아니었다

파일이 도착하면 설계는 그것을 공유 영역, 즉/usr/spool/uft로 그려진 곳에 두었다. 거기서 파일은 수신자가 수락하거나 거부할 때까지, 또는 시스템이 보존 기간 만료로 폐기할 때까지 기다렸다. RFC는 'public'이라는 단어에 신중했다. 공유 공간이 제한 없는 접근을 뜻하지는 않았다. 최대 크기와 보존 기간은 로컬 행정적 선택이었다.

여기서 최소 세 개의 시계가 만들어졌다. 전송 시계는 바이트가 프레임화되어 수신되면 멈췄다. 보관 시계는 호스트가 객체를 유지하는 동안 흘렀다. 수신자 시계는 사용자나 서비스가 행동할 때만 시작되었다. 파일은 성공적으로 전송되었고 스풀에도 여전히 존재하면서도 수락되지 않은 상태일 수 있었다.

기간 만료 삭제는 네 번째 결과였다. 수신자의 위장된 거부가 아니었다. 그것은 호스트의 보존 정책이 만료되었음을 뜻했다. 마찬가지로 정리 후 스풀 기록이 사라졌다고 해서 사용자가 파일을 소비했다는 증거가 되지 않는다. 처분 이벤트 없이는 소멸이 모호한 채로 남는다.

RFC 1440는 수신 호스트가 수락 전에 본문을 가능한 한 적게 처리하도록 권고했다. 알려지지 않은 표현은 파괴적으로 변환하지 말고 바이너리로 보존해야 했다. 이 절제는 수신자의 이후 선택을 보호했지만, 무결성이나 안전성, 유용성을 확립하지는 않았다.

버스트 경계는 멈출 자리를 확보했다

일반 모드에서 DATA는 버스트 크기를 포함했다. 수신자는 정확히 그만큼의 옥텟을 읽고 쓴 뒤 명령 해석으로 돌아갔다. 하나의 파일은 여러 버스트를 사용할 수 있었고, 하나의 연결은 여러 파일을 실을 수 있었다. 버스트가 끝난 뒤에도 ABORT는 의미를 유지했다. 프로토콜이 제어 경계를 되찾았기 때문이다.

문서는 '대담한 사람을 위한' 모드도 제공했다. DATA가 버스트 크기를 생략하면 수신자는 클라이언트가 연결을 닫을 때까지 읽었다. EOF나 QUIT는 뒤따르지 않았다. 소켓 닫기가 구분자가 되었고, 무한 스트림이 진행되는 동안 ABORT는 사용할 수 없었다.

이 거래는 단순히 빠르기와 느리기의 문제가 아니었다. 경계가 있는 버스트는 수신자가 확인, 거부 또는 폐기할 수 있는 검사점을 만들었다. 닫기 구분 모드는 교환을 줄였지만 프레임화와 연결 수명을 하나의 이벤트로 접었다. 예상치 못한 네트워크 단절과 의도된 종료는 같은 물리적 신호로 도착하며, 구별하려면 다른 증거가 필요했다.

수신자 이름은 기계를 가리킬 수도 있었다

USER는 반드시 인간을 지명할 필요가 없었다. 유사 사용자로 노출된 작업 접수 큐를 포함해 소프트웨어 서비스 엔진을 지정할 수 있었다. 이는 SIFT/UFT를 단순 수동 저장소 이상으로 만들었다. 수신된 객체가 자동화의 입력이 될 수 있었다.

그러나 프로토콜 토큰은 실행을 승인하지 않았다. 구문상 유효한 USER를 수락한 수신기는 현재 정책 하에 로컬 이름 공간이 그 대상을 인식한다는 것만 증명했다. 안전한 디스패치는 여전히 발신자 신원, 수신자 권한, 격리, 형식 검증, 자원 한도, 실행, 출력, 롤백 각각에 대한 별개의 증거를 요구했다. RFC 1440는 이 단계들에 대한 일반적 보안 해결책을 제공하지 않았다.

이 부재는 명시적이었다. 보안 문제는 논의되지 않았고, 인증 티켓은 미래 작업으로 미뤄졌다. 발신자 계정의 필요를 없앤 것은 하나의 마찰 지점을 제거했지만 완전한 신뢰 모델로 대체하지는 않았다.

우편은 그 판사가 되지 않으면서 객체를 실을 수 있었다

모든 호스트가 직접 IP 연결을 갖거나, 또 하나의 데몬을 원하거나, 포트 608을 허용하는 방화벽 안에 있는 것은 아니었다. 그래서 RFC 1440는 UFT가 MIME 안을 탈 수 있게 허용했다. 명령은application/octet-stream의 매개변수가 되었고, 데이터는 Base64 인코딩된 우편 본문이 되었다.

MIME은 표현과 운반의 문제를 해결했다. 그것이 UFT 수신자가 파일을 수락했다는 증명은 아니었다. 증거 사슬도 바뀌었다. 직접 TCP 경로는 인사말, 명령 ACK, 버스트, 연결 종료를 관찰할 수 있었다. 우편 경로는 저장 후 전달 상태들과 우편 시스템이 제공하는 어떤 인증이든 상속했다. RFC는 우편이 UFT를 실을 때 인증을 그 시스템에 맡긴다고 명시했다.

프로토콜은 Experimental 상태로 남았다. 이후 RFC 요약도 그 지위를 유지했고, 오늘날 IANA 레지스트리는 여전히 포트 608에 SIFT/UFT 서비스명을 나열한다. 이 기록들은 공개와 등록을 증명한다. 구현이 배치되었거나, 이용 가능하게 남았거나, 보편화되었다는 증명은 아니다.

마지막 동사는 수신자의 것이었다

RFC 1440의 지속적 흥미는 이 실험이 승리했다는 주장이 아니다. 완성되지 않은 전달의 정밀성이다. 발신자는 시작할 수 있었다. 데몬은 명령을 수용할 수 있었다. 호스트는 바이트를 받을 수 있었다. 스풀은 객체를 보관할 수 있었다. 그러나 그 어느 행위자도 수신자의 수락을 만들어 낼 수 없었다.

그러므로 방어 가능한 기록은 인사말과 전송 피어, 모든 명령 응답, 선언 및 수신된 크기, 표현 방식, 본문 체크섬, 스풀 기록과 확정, 보존 기한, 수신자 조회, 처분 이벤트, 그리고 이후의 애플리케이션 결과를 보존한다. 이를 '전달됨' 하나로 압축하면 가장 싼 신호가 결코 가진 적 없는 권위를 얻게 된다.

출처