요약

  • 성숙기의 FTP는 전송 바이트를 8비트로 고정했지만,TYPE L은 그 경계가 옥텟을 가로지를 수 있는 별도의 필수 논리 바이트 크기를 선언했다.
  • 수신 시스템은 자신의 워드 크기에 맞게 논리 단위를 배치할 수 있는데, 그 방법은 가역적이며 공개된 변환이어야만 했다. 저장과 검색이 같은 매개변수를 사용할 때는 동일성이 보장되었다.
  • Image는 연속된 비트를 보존했고, Local은 그에 더해 단위를 선언했다. 명령 성공은 응용 의미, 물리적 할당, 영구 저장, 또는 요청한 폭에 대한 보편적 지원을 증명하지 못했다.

성공 응답이 정착한 것은 겉보기보다 적었다

TYPE L 36을 수락한 서버는 이어지는 파일을 36비트 논리 단위의 열로 다루기로 합의한 것이다. 36비트 메모리를 사용하기로, 그 값을 숫자로 이해하기로, 특정 크기의 디스크를 예약하기로 합의한 것은 아니다. 이 명령은 표현 상태를 선택할 뿐이며, 다른 결과는 여전히 다른 메커니즘에 속한다.

간단한 계산이 이 소박한 계약을 드러낸다. 논리 단위 2개는 72비트다. 성숙기 FTP의 데이터 연결은 8비트 전송 바이트를 운반하므로 이 쌍은 그중 9개를 차지한다. 첫 4개 옥텟은 첫 번째 단위의 32비트를 담고, 다섯 번째 옥텟의 앞 절반이 그것을 완성한다. 뒤 절반은 이미 다음 단위를 시작하고 있다.

그 중간점에는 네트워크상의 구분자가 없다. TCP는 파일을 바꾸지 않고 그 지점 앞이나 뒤에서 스트림을 나눌 수 있다. 모든 옥텟이나 세그먼트 경계를 논리 경계로 다루는 게이트웨이는 운반된 모든 비트를 보존하면서도 표현을 훼손할 수 있다.

이것이TYPE L의 역사적 관심사다. 이 프로토콜은 모든 참여자가 내부적으로 운반 계층의 단위를 채택하도록 강요하는 방식으로 이질성에 답하지 않았다. 공통 문법을 좁히고 해석은 필요한 맥락이 살아 있는 가장자리에 남겨 두었다.

최초의 목록은 기계들의 차이를 이름 붙이려 했다

1971년 4월에 발표된RFC 114는 훗날의 텍스트·바이너리 선택보다 훨씬 넓은 타입 표면을 드러냈다. 그 잠정적 기술자들에는 여러 ASCII 형식, EBCDIC, SIXBIT, 10진·8진·16진 인코딩, 부호가 다른 정수들, 그리고 IBM 360과 PDP-10용 기계 고유의 부동소수점 형식이 포함되어 있었다. 일부 정수 기술자는 1비트에서 255비트까지의 명시적 크기를 가지고 있었다.

이 정보는 해석적인 것이었다. 타입을 수락하는 호스트는 받은 값을 그 기계에 맞는 내부 형식으로 변환할 수 있었다. 36비트 워드 컴퓨터는 7비트 ASCII 문자 5개를 한 워드에 압축할 수도 있고, 8비트나 9비트 문자 4개를 다른 방식으로, SIXBIT 문자 6개를 또 다른 방식으로 담을 수도 있었다.

그러나 그 1971년 표는 RFC 959의TYPE명령 문법이 아니다. 그렇게 다루면 역사적 전환을 하나로 접어 버리게 된다. 다만 그 표는 최초의 위탁 문제를 보여 준다. ARPANET 호스트들은 문자 코드, 수 표현, 저장 워드, 관습적으로 '바이트'라 불리는 단위에 대해 합의하지 못했다.

따라서 신뢰할 수 있는 비트 경로는 일을 미완으로 남겼다. 수신자는 정확한 열을 갖고 있으면서도 어떤 묶음을 함께 다루도록 의도했는지 알지 못할 수 있었다. 초기의 응답은 많은 기계적 차이를 공유 목록에 넣는 것이었다.

한때는 연결 바이트마저 가변적이었다

1972년 7월자RFC 354는 표현 타입, 구조, 전송 모드를 분리했지만, 그 데이터 연결은 여전히 선택된 바이트 크기를 사용할 수 있었다. ASCII와 인쇄 표현은 8비트를 사용했다. Image와 Local Byte는 연결에 선택된 크기를 사용할 수 있었다.

서버가 모든 가능한 크기를 수락할 필요는 없었다. 자신의 전송 장치가 효율적인 크기를 구현하면 되었고, 8비트 지원은 권고사항이었다. 표현 가능성은 프로토콜의 초기 형태에서조차 배치의 증명서가 아니었다.

Local Byte 변환은 전송 크기와 개별 호스트에 의존했다. 그 방법은 충분히 공개되고 가역적이어야 했다. 어떤 표현과 바이트 크기로 파일을 저장했다면, 같은 조합으로 검색할 때 동일한 파일이 재현되어야 했다. 그 매개변수를 기억하는 책임은 사용자에게 있었다.

이 배치는 서로 다른 기계들에게 자기 형식을 보존할 여지를 주었지만, 상호운용성 행렬을 키웠다. 어떤 호스트는 메모리 안의 36비트 값을 이해하면서도 36비트 데이터 연결 바이트는 거부할 수 있었다. 의미와 운반 폭이 모두 협상 표면에 나타난 것이다.

8비트는 헌법이 아니라 운반 수단이 되었다

1980년의RFC 765는 전송 바이트를 8비트로 고정하여 모델을 단순화했다.RFC 959는 그 결정을 유지하며 구분을 명시했다. FTP에는 파일 구조를 해석하기 위한 논리 바이트 크기와 데이터를 옮기기 위한 전송 바이트 크기가 있었다. 어느 쪽도 시스템이 결과를 저장하는 단위일 필요는 없었다.

TYPE L은 10진수 둘째 매개변수를 요구하며 기본값이 없다. 그 수가 없으면 수신자는 도착하는 컨테이너의 폭은 알지만, 그것으로부터 재구성할 단위의 폭은 알 수 없다.

두 폭이 다를 때 논리 바이트는 전송 바이트 경계를 무시하고 연속적으로 압축된다. 이 변경은 9비트, 18비트, 36비트 객체를 금지한 것이 아니라, 그들의 압축을 끝단으로 옮기고 그 기하구조를 데이터 연결 자체에서 제거한 것이다.

이것은 공통 권한의 통제된 축소였다. 모든 구현은 8비트 운반을 신뢰할 수 있었다. 그러나 어떤 구현도 그 공통 운반 계층만으로 파일, CPU, 저장 장치가 모두 8비트 네이티브 객체를 쓴다고 추론할 수는 없었다.

다섯 번째 옥텟은 두 워드에 모두 속했다

명세서의TYPE L 36예는 시각적 습관을 깨뜨리기 때문에 특히 유용하다. 옥텟 4개가 36비트 워드는 아니다. 옥텟 5개는 너무 많다. 경계는 다섯 번째 옥텟 내부에 놓여 있어, 그 하나의 전송 단위가 인접한 두 논리 단위에 각각 부분적으로 귀속된다.

따라서 규격에 맞는 압축기는 스트림을 별도로 알려진 보폭(stride)을 가진 비트로 다룬다. 옥텟 경계, IP 패킷, TCP 세그먼트, 저장 블록에서 보폭을 다시 시작하지 않는다. 그것들은 컨테이너 또는 운영적 구분일 뿐, 파일 의미의 선언이 아니다.

그러나 그 폭조차 완전한 수 형식을 정의하지는 않는다. 36비트에는 부동소수점 값, 명령, 이미지 요소, 그 밖의 무엇이든 들어갈 수 있다.L 36은 부호, 지수, 내부 순서, 응용 의미를 지정하지 않는다. 다른 권위 있는 설명이 작동할 수 있는 경계를 보존할 뿐이다.

이 한계는 양방향에서 중요하다. Local 타입을 수락했다고 수신자의 응용이 내용을 이해한다는 증명은 되지 않는다. 36비트 형식을 이해하는 응용이 있다고 해서 FTP 서비스가L 36을 수락한다는 증명도 되지 않는다. 표현 지원과 응용 사용은 별개의 관찰이다.

패딩은 마지막 나머지만을 처리할 수 있었다

논리적 내용 총량이 마지막 전송 옥텟을 채우지 못할 때, RFC 765와 RFC 959는 끝에서 필요한 패딩을 허용한다. 그러나 수신자나 중개자가 편의를 위해 모든 논리 단위를 다음 8비트 경계로 올림하는 것은 허용하지 않는다.

패딩을 복구 가능하게 하는 것은 위치다. 단위 사이에 삽입된 0은 원래 데이터와 구별되지 않을 수 있다. 파일이나 레코드의 끝에서는, 끝단이 종료 지점과 선언된 논리 폭을 결합하여 나머지를 식별할 수 있다.

따라서 패킷 캡처에서 한 줄의 0은 약한 증거다. 그것은 내용일 수 있다. 그것을 패딩이라고 부르려면 조사자는 활성 타입과 폭, 해당 파일이나 레코드 구조, 신뢰할 수 있는 끝 경계가 필요하다. 전송 바이트만으로는 그 판정을 담을 수 없다.

모든 36비트 단위 뒤에 4개의 0비트를 삽입하는 중개자는 단순히 정렬을 최적화한 것이 아니다. 승인된 해석자가 원본을 소비하기 전에 또 다른 인코딩을 발명한 것이다. 그 0들을 나중에 제거하려면 FTP 선언 밖의 새 규칙이 필요할 것이다.

수신자는 더 큰 서랍을 선택할 수 있었다

RFC 959는 36비트 부동소수점 단위가 32비트 워드 호스트에 도착하는 상황을 상정한다. 그 호스트는 각 논리 단위를 다루기 쉽게 유지하기 위해 64비트 더블 워드에 저장할 수 있다. 남는 28비트는 FTP가 운반하는 파일이 아니라 로컬 서랍에 속한다.

그 서랍을 선택할 자유는 가역성에 의해 제약된다. 변환은 같은 매개변수를 사용할 때 서버가 동일한 파일을 돌려줄 수 있어야 하며, 구현자는 그 변환이 어떻게 작동하는지 공개해야 한다.

"같은 매개변수"라는 말은 안심이 아니라 조건이다.TYPE L 36으로 저장된 파일이TYPE L 8로 요청할 때 동일하게 나온다는 일반적 보장은 없다. 원래 폭과 변환 규칙을 버리고 패딩된 64비트 저장 형식만 보존한 아카이브는 나중에 내용과 로컬 공간을 구별하지 못할 수 있다.

따라서 영속적인 객체는 블롭보다 크다. 그것은 비트 열, 표현 매개변수, 로컬 매핑의 출처를 포함한다. 서랍 위의 체크섬은 서랍이 살아남았다는 것을 증명할 수 있지만, 어느 36비트가 의미했는지 알려 주던 잃어버린 지시를 재구성할 수는 없다.

Image와 Local은 같은 말을 하지 않고도 일치할 수 있었다

Image 타입은 파일을 8비트 전송 바이트에 압축된 연속 비트로 다룬다. 수신 사이트는 그 연속성을 보존해야 한다. 저장 시스템이 바이트, 워드 또는 블록 경계에 정렬이 필요하다면, 0 패딩은 파일이나 레코드의 끝에만 나타날 수 있고 검색 시 제거 가능하도록 식별되어야 한다.

Local 역시 연속 비트 스트림을 옮기지만, 논리 단위를 선언한다. 그 선언은 수신자에게 각 단위를 호스트에 맞는 가역적 형식으로 배치할 권한을 준다. 두 타입은 특정 기계 배치에서 같은 비트를 낼 수 있으면서도 같은 근거를 운반하지 않는다.

RFC 1123은 8비트 바이트 기계에서TYPE L 8이 Image와 동등하다고 설명한다. 두 m비트 워드 기계 사이에서는TYPE L m이 Image와 같은 효과를 가져야 한다. 그 동등성은 알려진 조직 방식에 조건부이며, 송신자가 Image만 선택했을 때 수신자가 m비트 경계를 발명하는 것을 허용하지 않는다.

이것은 결과와 권한 사이의 유용한 구분이다. 두 절차가 우연히 동일한 출력을 낼 수 있다. 그러나 호스트 고유의 변환을 정당화한 매개변수를 담고 있는 쪽은 하나일 수 있다.

필수 하한선은 의도적으로 좁았다

RFC 1123은 FTP 프로그램에TYPE I와TYPE L 8의 지원을 요구한다. 메모리가 m비트 워드로 조직되어 있고 m이 8의 배수가 아닌 기계는TYPE L m도 지원할 수 있다.

이 규칙은 8비트 상호운용성 하한을 확립하고 네이티브 워드 확장의 여지를 남긴다. 모든 서버가L뒤의 모든 10진 정수를 수락하도록 요구하지는 않는다. 정의된 문법, 구현된 능력, 세션 수락은 서로 다른 세 가지 사실이다.

TYPE L 36의 거부는 요청된 표현이 그 세션에서 수락되지 않았다는 것을 증명할 뿐이다. 끊긴 경로, 부족한 저장 공간, 손상된 콘텐츠를 증명하지 않는다. 클라이언트는 Image를 선택하거나, 전송 전에 외부 공유 형식으로 변환하거나, 중단할 수 있다.

L 8을 조용히 대체하는 것은 당장의 명령을 충족하기 쉽게 만들면서, 송신자가 하려던 선언을 지운다. 요청된 단위를 바꿔서 얻은 호환성은 원래 표현이 살아남았다는 근거가 아니다.

타입은 구조, 모드, 재시작 상태를 삼키지 않았다

FTP는 표현 타입, 파일 구조, 전송 모드를 별개의 매개변수로 유지했다. 논리 단위가 36비트라는 지식은 레코드 경계, 페이지 인덱스, Stream·Block·Compressed 동작을 정의하지 않는다. 완료 응답이 현대적 영구 저장을 의미한다고 말하지도 않는다.

FTP 재시작 마커에 관한 공개된 역사는 마커가 반드시 바이트 번호는 아니었던 이유를 검토했다. 변환을 수행하는 수신자는 그것을 재개하기에 충분한 로컬 상태를 인코딩해야 할 수 있었다.TYPE L은 그 변환에 입력 단위를 공급하고, 마커는 재시작 지점을 공급한다. 하나를 보존한다고 다른 하나가 재현되지는 않는다.

이 구분이 단 한 건의 우연한 검색 일치가 중복 위탁이 아닌 이유이기도 하다. 재시작 기사는 수신자 소유의 체크포인트를 설명하기 위해 이질적 워드 크기를 언급했다. 이 기사는 논리 단위 자체가 고정된 운반 계층을 어떻게 가로지르고 가역적 저장을 어떻게 제약하는지를 다룬다.

ALLO는 다른 곳에서 정의된 단위를 셈했다

FTP의ALLO명령은 예상 저장량을 논리 바이트로 표현할 수 있었다. 그 단위를 공급한 것은 활성 표현이었다. 할당 명령은 36비트 경계를 만들지 않았고, 그 긍정 응답이 물리적 공간이 예약되었다는 증명이었던 것도 아니다.

최근 발표된 ALLO 기사는 예비 수량이 서버 자원을 바꾸었는지를 묻는다.TYPE L은 그 수량이 무엇을 세는지, 그 경계가 데이터 연결을 어떻게 살아남는지를 묻는다. 충분한 공간은 잘못 압축된 논리 스트림을 수리할 수 없고, 올바른 압축은 예약을 증명할 수 없다.

두 메커니즘은 권한을 다르게 배분한다.TYPE은 송신자가 서버 수락을 전제로 표현을 선언하게 한다.ALLO는 송신자가 필요량을 추정하게 하되 선할당이 중요한지는 서버가 판단하게 한다. 둘을 하나의 일반적인 바이너리 전송 성공으로 다루면 각자의 제어 표면이 지워진다.

레지스트리 항목은 호스트 메모리의 지도가 아니다

IANA FTP Commands and Extensions 레지스트리는TYPE을 표현 타입 명령으로 기록하고 그 명세를 가리킨다. 이것은 이름과 문서 참조를 확립한다.

그러나 그것은 서버가 수락하는 모든 Local 크기, 파일시스템에서 사용되는 매핑, 명령의 현재 보급률을 나열하지 않는다. 그 주장에는 구현 증거, 해당 세션 응답, 같은 매개변수의 왕복, 그리고 유용성을 위해서는 복원된 단위를 이해하는 응용이 필요하다.

등록, 수락, 올바른 변환, 응용 해석은 증거의 사다리를 이룬다. 그 어느 것도 아래 단계에서 자동으로 추론될 수 없다.

전송 계층의 소박함이 출처 보존을 끝단의 의무로 만들었다

FTP는 기계 표현의 광대한 목록에서, 가변 연결 바이트 크기를 거쳐, 고정 8비트 운반과 별도 논리 폭으로 이동했다. 공통 계층은 그에 연결된 기계들이 동질적이라고 선언하지 않으면서 단순해졌다.

이 소박함은 끝단이 전송 계층이 의도적으로 해석하지 않기로 한 것을 보존할 때만 작동한다. 타입, 논리 크기, 구조, 모드, 변환 출처는 "바이너리" 같은 레이블로 안전하게 축소될 수 없다. 아홉 개의 온전한 옥텟은 여전히 두 개의 36비트 워드에 대한 불완전한 기록일 수 있다.

역사적 교훈은 현대 시스템이 옛 FTP 모드를 전부 되살려야 한다는 것이 아니다. 공유 계층을 단순화하는 것이 그 계층에서 배제된 맥락을 폐지하지는 않으며, 그 맥락을 보존할 의무를 옮겨 놓는다는 것이다.

출처와 근거 경계

근거는RFC 114,RFC 354, RFC 765, RFC 959, RFC 1123 및 IANA 레지스트리로 구성된다. 이 출처들은 설계와 요구사항을 확립한다. 그것들은 현재 배치, 제품이 수락하는 폭, 디스크 배치, 36비트 값의 응용 의미, 영구 저장의 보장을 확립하지 않는다.