요약

  • Abhay Bhushan의 초기 FTP는 서로 호환되지 않는 호스트 간의 운영을 통일했으며, 파일 시스템 자체를 통일하지는 않았다.
  • 호스트 능력 조사와 1972년 워크숍을 통해 경로 이름과 접근 규약은 여전히 각 사이트의 관할 아래 있음이 드러났다.
  • 명확한 거절 응답도 상호운용성의 일부였다. 서버는 요청된 조합을 수용하지 않을 수 있지만, 이해한 것처럼 꾸며서는 안 되었다.

하나의 공통 작업, 아홉 가지 지역적 의미

“가져오기”라는 동사는 단순해 보인다. 그러나 그 동사의 대상은 단순하지 않았다. 어떤 호스트에서 파일 이름은 디렉터리를 담을 수 있었고, 다른 곳에서는 계정, 버전 또는 접근 패턴을 담았다. 생략된 부분에는 저마다 암묵적 기본값이 붙었다. 데이터가 이동하기 전에, 누군가는 목적지가 그 요청을 어떻게 해석하는지 알아야 했다.

바로 이 이분화 때문에 Abhay Bhushan의 작업은 잘 알려진 프로토콜의 단순한 기원 그 이상이다. 그는 서로 크게 다른 시스템 사이에서 작동할 만큼 작은 합의 표면을 찾았다. 프로토콜은 인식 가능한 동작을 제공하고 전송 방식을 협상할 수 있었다. 그러나 원격 컴퓨터의 이름 공간이나 접근 정책을 프로토콜 스스로 재작성할 수는 없었다.

Internet Hall of Fame은 Bhushan에게 1967년부터 1974년까지 MIT Project MAC에서 재직하며 작성한 최초의 FTP 사양과 20편이 넘는 RFC를 돌렸다. 기술 문서는 이 작업의 집합적이고 경험적인 성격을 보여준다. 그는 문서를 쓰는 데 그치지 않고 호스트 조사를 촉발했고, 워크숍을 소집했으며, 결정과 막힌 지점을 모두 기록했다.

첫 버전은 질문으로 끝났다

1971년 4월의RFC 114는 원격 호스트의 직접 사용과 함께 간접 모델도 기술했다. 이 모델에서 중간 프로세스는 사용자를 상대 시스템의 일부 명령과 관습에서 면제시킬 수 있었다. 균일한 인터페이스라는 약속은 이미 있었지만, Bhushan은 이 문서를 첫 번째 절취편으로 보고 네트워크상 호스트의 요구 사항과 능력을 조사해야 한다고 지적했다.

이 선택은 표준에서 자주 나타나는 실수, 즉 가장 익숙한 환경을 보편적 정의로 만드는 실수를 피한다. 효율성, 확장, 적응성, 장애 복구, 응용 독립성은 중요한 기준이었다. 그럼에도 이들은 모델의 우아함이 아니라 실제 존재하는 기계와 맞대야 했다.

RFC 180은 조사를 구체화했다. 소위원회는 그 시점에는 이름 규약과 접근 제어를 표준화하지 않겠다고 선언했다. 사용자는 여전히 원격 호스트의 규칙을 알아야 했다. Bhushan의 요청에 따라 Alex McKenzie는 대표자들에게 유효한 이름 형식, 암묵적 패턴, 디렉터리, 제약, 운영, 파일 표현에 관한 정보를 수집했다.

이 설문은 비교를 통한 아키텍처였다. 그것은 각 로컬 팀이 특별한 것임을 조차 인식하지 못할 수 있는 전제를 드러냈다. 차이가 종이에 나타나면 분류할 수 있었다. 공통 요구 사항, 협상 가능한 능력, 또는 서버가 거절해야 할 요청.

사양을 지킨 불일치

1972년,RFC 309는 관심 있는 이들에게 데이터 및 파일 전송 워크숍에 참여하도록 초청했고, 입장 문서를 요청했으며, 현재와 미래의 필요를 기준으로 프로토콜을 재검토하는 세션을 확보했다. 완성된 문서를 확인하는 의식이 아니었다. 서로 다른 응용과 호스트가 초안이 아직 담지 못한 것을 보여줄 여지가 생겼다.

RFC 327의 노트는 합의의 부재를 숨기지 않는다. 네트워크 차원의 가상 파일 이미지가 더 많은 공통 구조를 운반하는 방법으로 논의되었지만 합의에 이르지 못했고, 그 제안은 당분간 보류되었다. 점진적 목표는 남았다. 데이터 무결성 유지, 문자 표현과 해석의 명확화, 가능한 경우 구조 보존, 그리고 더 먼 지평선으로서의 가상 시스템.

워크숍은 즉각적인 선택도 산출했다. 명령은 인쇄 가능해야 했다. 제어와 데이터는 별도의 연결을 사용했다. 특정 기본 유형은 필수였다. 서버가 요청된 구조를 수용할 수 없을 때는 요청을 거절하고 사용자에게 알려야 했다. Bhushan은 노트와 다음 초안을 담당했다.

포기된 프로젝트에는 가치가 있었다. 어떤 야망이 합의로 기록되는 것을 막았기 때문이다. 파일의 완전한 존재론을 약속하는 대신, 이 그룹은 더 작고 검증 가능하며 진화에 열려 있는 핵심을 제출했다.

경로 이름이라는 관할권

RFC 171은 일반 전송 메커니즘을 응용별 기능에서 분리해 중복된 해법의 집합을 피하려 했다.RFC 172는 호스트 간 변동에 대한 보호를 실용적인 수준으로 한정하고, 부분 구현과 합의된 확장을 수용하며, 경로를 쓰는 방식은 사이트의 결정으로 남겼다.

이 구조는 모든 명사를 보편화하지 않으면서 공통 동사를 만들었다. 검색, 저장, 나열. 표현, 구조, 모드는 제어 대화에서 선언될 수 있었다. 반면 파일 식별자는 목적지의 운영 언어로 왔다. 그 해석과 대응되는 권한 부여는 여전히 로컬 통제 아래 있었다.

RFC 354는 이 한계를 관찰 가능한 동작으로 만들었다. 서버는 모든 표현, 유형, 모드 또는 바이트 크기를 수용할 필요는 없었다. 그러나 요청된 조합을 수용하지 않는다는 사실은 알려야 했다. 잘 구성된 거절은 클라이언트가 다른 옵션을 고르거나 오류를 설명할 수 있게 했다.

묵묵히 수용하는 편이 덜 상호운용적이었다. 공표되지 않은 변환은 구조를 제거하거나 내용의 의미를 바꿀 수 있고, 피해의 발견은 한참 뒤로 미뤄진다. 거절을 정보로 다룸으로써, 이 프로토콜은 보편성의 외관을 더 겸손하고 실제적인 신뢰성과 맞바꿨다.

추상이 끝나는 정확한 지점

1985년의RFC 959는 수년간의 진화 결과를 보여준다. 그것을 1971년과 1972년에 소급해서 투영해서는 안 된다. 초기 문서들은 다른 것을 기록한다. 초기 제안, 조사, 열린 토론, 범위 축소, 그리고 개정. 설계가 성숙했던 이유는 아직 해결하지 못한 것을 인정할 수 있었기 때문이다.

이 한정된 인터페이스 덕분에 호스트들이 보편적인 파일 시스템에 합의하기 전에 배포가 가능했다. 대가는 클라이언트에 나타났는데, 클라이언트는 원격 규약을 알아야 했고, 능력과 확장의 행렬은 계속 늘어났다. 그러나 완전한 해법은 더 큰 두 위험을 감수했을 것이다. 결코 사용에 이르지 못하거나, 가장 강력한 호스트들의 관습을 어떤 가정상의 중립성으로 변환하는 것.

경로 이름은 관할권을 표시한다. 네트워크는 동사를 전달하고, 목적지는 대상을 정의하고, 그 이름을 해석하며, 접근을 결정한다. Abhay Bhushan은 이 이분화를 없애지 않았다. 호환되지 않는 기계들이 협력하기 시작할 수 있을 만큼 충분히 명시적으로 만들었을 뿐이다. 지속 가능한 표준은 모든 것을 포괄하겠다고 약속하는 것이 아니라, 어디까지인지 선언할 줄 아는 것이다.

출처