요약

  • FTP는 접근 제어 식별자로USER,PASS,ACCT를 별도로 다루었습니다. 비밀번호 단계가 성공했다고 해서 로그인이 완료되거나 이후의 모든 파일 작업이 승인되는 것은 아니었습니다.
  • 332는 긍정적 중간 응답이었습니다. 파일 명령 뒤에 나왔다면 서버가 계정 정보를 기다리면서 해당 명령을 보존하고 있다는 뜻이고,532는 명령이 폐기되어ACCT이후 다시 보내야 한다는 뜻이었습니다.
  • 프로토콜은 계정을 돈, 두 번째 비밀번호 또는 전역 신원으로 정의하지 않았습니다. 로컬 자원·승인 정책을 담을 자리를 남겨 두었고, 서버가 호출자의 의도를 아직 보유하고 있는지에 대한 근거도 함께 전달했습니다.

비밀번호 다음의 응답이 비밀번호에 대한 판정은 아니었습니다

사용자 프로세스가USER를 보냈습니다. 서버가PASS를 요청했고, 클라이언트는 그 단계를 통과하는 비밀번호를 제공했습니다. 로그인에 그 이상의 요건이 없다면RFC 959는 서버가230 User logged in, proceed를 반환하도록 허용했습니다.

다른 사이트는332 Need account for login을 반환할 수 있었습니다.

선두 자릿수 덕분에 이 구분은 기계가 읽을 수 있었습니다. 3yz 응답은 긍정적이면서 중간 단계였습니다. 앞선 명령은 접수되었지만 요청된 동작은 추가 정보를 기다리며 보류된 상태였습니다. 비밀번호를 다시 보내는 것은 해결책이 아니었고, 다음 명령은ACCT였습니다.

이 분기는 두 필드짜리 로그인 폼이 쉽게 표현할 수 없는 사실을 드러냅니다. 시스템에는 누가 요청하는지에 대한 충분한 근거가 있으면서도, 그 작업이 자원을 소비하거나 권한을 받아야 할 로컬 맥락은 여전히 없을 수 있었습니다. 비밀번호 승인과 세션 준비 완료는 서로 다른 명제였습니다.

세 번째 식별자는 범용 신원 모델이 아니라 특정 호스트에서 나왔습니다

이 명령은 1972년 8월에 기록에 등장했습니다.RFC 385는 FTP 명세에ACCT를 추가했고, 사용자명과 비밀번호 외에 계정 명세를 요구하던 TENEX 같은 시스템을 예로 들었습니다.

그 메모는 계정 명령을 비밀번호와 구분했습니다. 반드시USER에 묶일 필요가 없었고, 언제든 도착할 수 있었으며, 같은 사용자의 파일 전송마다 달라질 수도 있었습니다. 어떤 서버는 사용자를 로그인 상태로 선언하기 전에 요구할 수 있고, 다른 서버는 파일 저장 같은 특정 접근이 대화 맨 앞에 올 때만 요구할 수 있었습니다.

이 설명 어디에도 그 문자열이 은행 계좌가 된다고 쓰여 있지 않습니다. 프로토콜은 Telnet 문자열만 규정했고, 제도적 의미는 원격 시스템에 맡겼습니다. 프로젝트, 자원 배분, 승인 분할, 비용 센터가 모두 이 메커니즘에 들어맞을 수 있습니다. 근거는 어느 하나를 선택하지 않으며, 이 식별자가 사이트 간에 이식 가능하다고 만들지도 않습니다.

FTP의 타협은 실용적이었습니다. 이기종 호스트들이 자신들의 로컬 계정 구조를 버리지 않아도 되었습니다. 대신 네트워크 대화는 클라이언트가 함부로 "비밀번호 오류"로 뭉개면 안 되는 세 번째 상태를 갖게 되었습니다.

332가 계정을 뜻하기 전에, 다른 번호가 먼저 같은 질문을 했습니다

RFC 542는 1973년에ACCT를 통합했습니다. 로그인에 필요한 계정과 특정 접근에만 필요한 계정을 이미 구분하고 있었습니다. 그러나 응답 어휘는 나중의 것과 달랐습니다.331 Enter account는 로그인 절차를 완료했고,433은 유효한 계정 없이는 전송이 진행될 수 없다고 말하며 사용자에게 계정을 입력하고 명령을 다시 보내라고 지시했습니다.

RFC 640은 1974년에 FTP 응답 체계를 다시 설계했습니다. 목표는 사용자 프로토콜 인터프리터가 서버마다 다른 문장을 해석하는 대신 자릿수만으로 결과와 다음 상태를 파악하도록 하는 것이었습니다. 3yz 응답은 긍정적 중간 단계가 되었고, 5yz 응답은 해당 요청에 대한 영구적 부정 완료가 되었습니다. 두 번째 자리가 3인 응답은 인증과 계정 관리를 담당했습니다.

수정된 목록은331 User name okay, need password,332 Need account for login,532 Need account for storing files를 배정했습니다. 프로토콜의 질문은 살아남았고, 숫자 문법만 옮겨 갔습니다. 따라서 331이 담긴 1973년 기록은 1985년의 사전으로 읽을 수 없습니다. 역사적 번호는 그 번호를 발행한 상태 기계 안에서만 근거가 됩니다.

문자열 하나의 부재가 서로 다른 두 가지 보유 결과를 낳았습니다

가장 깊은 구분은 로그인 이후에 나타났습니다. RFC 959가 유지한RFC 765는 로그인 후에 파일 명령을 내리고 그 뒤에 계정 요건을 만난 사용자를 다룹니다. 서버에는 두 가지 선택지가 있었습니다.

ACCT가 도착하기 전까지 명령을 보존하기로 했다면 서버는 332를 반환했습니다. 호출자의 의도는 서버에 남아 있었고, 빠진 계정 정보를 제공하면 보존된 작업이 계속 진행될 수 있었습니다.

명령을 폐기하기로 했다면 서버는 532를 반환했습니다. 나중의ACCT가 맥락을 성립시킬 수는 있었지만, 서버가 더 이상 보유하지 않은 작업을 되살릴 수는 없었습니다. 클라이언트는 파일 명령을 다시 보내야 했습니다.

두 응답 모두 "계정이 필요하다"고 표현될 수 있지만, 그런 문구는 운영 계약을 지워 버립니다. 332 이후 파일 명령을 무심코 재전송하면 이미 대기 중인 의도 외에 또 하나의 의도를 만들 위험이 있습니다. 532 이후 재전송하지 않으면 어떤 작업도 시작되지 않는 것이 보장됩니다. 응답 코드는 단순한 사유 코드가 아니라 요청의 보유 상태에 대한 영수증이었습니다.

"파일 저장을 위한"이라는 문구가 저장 공간 고갈을 뜻하는 것은 아니었습니다

532의 문구는 두 번째 혼동을 부릅니다. 파일 저장을 언급하기 때문에 대시보드가 이 코드를 디스크나 쿼터 오류로 묶을 수 있습니다. RFC 959는 그런 상황에 다른 코드를 배정했습니다. 시스템 저장 공간 부족에는452, 현재 디렉터리 또는 데이터셋의 저장 할당 초과에는552였습니다.

계정 맥락의 부재, 시스템 용량의 부족, 할당량의 소진은 각각 다른 주체를 둔 별개의 사실입니다. 첫째는 맥락 제공으로 해결될 수 있습니다. 둘째는 용량이 필요합니다. 셋째는 쿼터나 정책 변경이 필요할 수 있습니다. 셋을 모두 "저장 실패"로 부르면 이를 구분하는 데 필요한 근거가 사라집니다.

532는 계정이 제공된 이후 그 작업이 승인될 것이라고도 증명하지 않습니다. 이 코드는 바로 이 시도가 보존되지 않은 이유를 말할 뿐입니다. 경로명은 여전히 사용 불가능할 수 있고, 할당은 여전히 초과 상태일 수 있으며, 전송은 나중에 실패할 수 있습니다. 계정 승인은 하나의 상태 전이일 뿐, 파일에 대한 약속이 아닙니다.

제어 연결은 자신의 접근 제어 신원보다 오래 살아남을 수 있었습니다

RFC 959는 어느 시점에든 새USER명령을 허용했습니다. 이전에 제공된 사용자명, 비밀번호, 계정 정보를 지우고 로그인 절차를 다시 시작했습니다. 전송 매개변수는 그대로였고, 이미 진행 중이던 파일 전송은 이전 접근 제어 매개변수로 완료되었습니다.

이 범위는 의도적으로 비대칭입니다. 새 신원은 거슬러 올라가 이미 이동 중인 바이트에 권한을 행사하지 않았고, 이전 계정이 다음 로그인으로 새어 나가지도 않았습니다. 전송 계층의 연속성과 접근 제어의 연속성은 서로 다른 표면이었습니다.

REIN은 또 하나의 경계를 제공했습니다. 사용자와 계정 상태를 지우고 다른 매개변수를 기본값으로 되돌리되 제어 연결은 열어 두었습니다. 따라서 연결 식별자만으로는 작업을 귀속시킬 수 없습니다. 감사는 지배하는 맥락을 명명하기 전에 가장 최근의USER,ACCT,REIN또는 재연결을 찾아내야 합니다.

이는 성공한ACCT가 증명하는 바도 제한합니다. 성공한ACCT는 그 시점에 대기 중이던 상태에 대해 서버가 계정 정보를 받아들였음을 성립시킵니다. 같은 맥락이 이후의 리셋을 살아남았는지, 이미 진행 중이던 전송을 지배했는지, 이어진 모든 명령을 승인했는지는 증명하지 않습니다.

명령을 지원하는 것과 계정을 요구하는 것은 같지 않았습니다

RFC 1123은ACCT를 서버 FTP와 사용자 FTP 구현이 지원해야 하는 명령 집합에 넣었습니다. 다만 하부 파일 시스템이나 운영체제가 특정 명령을 허용하지 않는 경우의 예외를 두었습니다. 상호운용성 의무가 중요한 이유는, 세 번째 단계를 표현할 수 없는 클라이언트는 이를 요구하는 규격 사이트를 이용할 수 없기 때문입니다.

이 요구 사항이 모든 사이트에 비어 있지 않은 계정을 강제하지는 않았습니다. FTP의 응답 문법은 특정 시스템과 무관하게 인식된 명령에 불필요(superfluous) 취급으로 긍정적인202응답을 줄 수 있게 했습니다. 프로토콜 상태를 이해하는 것과 모든 세션에서 그 상태를 활성화하는 것은 별개의 약속입니다.

현재IANA FTP Commands and Extensions 레지스트리는 여전히ACCT를 접근 제어 클래스의 기본 Account 명령으로 기록하며, 참조로 RFC 959를 둡니다. 이 행은 등록된 문법과 문서적 권위를 성립시킵니다. 배포 현황을 세거나, 로컬 의미를 공개하거나, 현재의 서버가 명령을 수용한다고 증명하지는 않습니다.

프로토콜은 옳은 종류의 불완전성을 보존했습니다

FTP는 서로 다른 컴퓨터들 사이의 계정이라는 제도적 문제를 해결하지 못했습니다. 더 작고 더 오래 지속되는 일을 했습니다. 사용자명은 알고 있고 비밀번호 단계는 성공했으나 별개의 로컬 맥락이 아직 미해결이라고 서버가 말할 수 있게 한 것입니다. 그 필요가 작업 이후에 드러난다면, 서버가 여전히 요청을 보유하고 있는지를 선언할 수도 있게 했습니다.

이 설계는 좁은 성공 하나가 넓은 권한을 얻는 것을 막았습니다.PASS는 만능 승인이 되지 않았습니다.ACCT는 작업 영수증이 되지 않았습니다.230은 모든 경로명을 승인하지 않았습니다.332는 결국 실행을 약속하지 않았습니다.532는 디스크 용량을 진단하지 않았습니다.

옛 세 번째 필드 자체가 권고 사항은 아닙니다. 권고는 주체 증명, 자원 맥락 선택, 작업 수용을 별개의 상태로 유지하는 것입니다. 현대의 API가 셋을 하나의 인증 불리언으로 압축하는 순간, 사라진 구분은 공유 자격 증명, 사이트별 어댑터, 올바른 복구 방법을 더 이상 추론할 수 없는 실패의 형태로 되돌아옵니다.

출처와 근거의 한계

닫힌 근거 기록은RFC 385,RFC 542,RFC 640,RFC 765, RFC 959, RFC 1123 및 IANA 레지스트리입니다. 이 출처들은 명령의 의미론과 문서 역사를 성립시킵니다. 현재의 보급 현황, 어떤 구현의 동작, 계정 문자열이 비밀이었는지 여부, 돈이 청구되었는지 여부, 특정 파일 작업이 완료되었는지 여부는 성립시키지 않습니다.