요약

  • RFC 3196은 원래 최종 Print-Job 응답 전에 문서 데이터 수신 시점을 구현이 선택하도록 남겨두었으나, 기술 정오표 2924는 이 재량을 폐지하고 모든 문서 데이터를 먼저 수신해야 한다고 요구하도록 바꾸었다.
  • 이 정정 사항은 최종 IPP 성공 또는 오류 응답에 관한 것이다. HTTP100 Continue, 초기 전송 오류, 작업 생성, 이후의 실제 인쇄 행위는 별개의 사건이며 별개의 근거이다.

너무 일찍 도착한 응답

인터넷 인쇄 프로토콜(IPP)은 인쇄가 한 대의 기기에 연결된 로컬 케이블이 아니라 네트워크 서비스처럼 동작하도록 설계되었다. 클라이언트는 HTTP를 통해 IPP 연산과, Print-Job의 경우 문서 자체를 실어 작업을 제출할 수 있었다. 그러면 응답은 IPP 상태와 작업 식별자를 돌려주었다. 겉보기에 평범한 이 교환에는 대용량 객체를 업로드해 본 사람이라면 누구에게나 익숙한 질문이 숨어 있었다. 서버는 언제 무슨 일이 일어났다고 말할 자격이 있는가?

2001년 11월 발행된 IPP/1.1 구현자 안내서인 RFC 3196은 처음에는 프린터가 최종 성공 또는 오류 응답을 반환하기 전에 문서 전체를 수신할지 여부를 스스로 결정할 여지를 두었다. 2011년 정오표 2924가 이 문장을 대체했다. 정오표는 프린터가 그 응답을 반환하기 전에 모든 문서 데이터를 수신해야 한다(MUST)고 규정한다. 변경 자체는 짧지만, 수신 경계를 연산의 관찰 가능한 의미의 일부로 만든다. 최종 응답이 제출된 객체보다 앞서 달려 나가 나머지 데이터가 소비되었는지 클라이언트가 추측하게 두어서는 안 된다.

이것이 유용한 역사적 균열이다. 새로운 프린터 기능이 아니라, 본문이 아직 전송 중일 수 있는 요청에 대해 최종 응답이 무엇을 의미해야 하는지 명확히 한 것이다. RFC 2910은 IPP의 HTTP 전송을, RFC 2911은 IPP의 연산과 작업 모델을 기술했다. RFC 3196은 새로운 표준 트랙 프로토콜이 아니라 안내서였다. 그 정오표는 안내서의 조언을 RFC 2616의 POST 및 Expect/Continue 규칙에서 이미 드러나 있던 HTTP 요청 본문 순서 문제와 정렬시켰다.

하나가 아니라 세 가지 확인

이 문구를 과대 해석해서는 안 된다. HTTP100 Continue는 임시 응답이다. 클라이언트에게 본문을 진행해도 된다고 알려줄 뿐이며, 최종 IPP 답변이 아니고 인쇄 연산이 성공했다고 말하지도 않는다. HTTP는 또한 메서드가 수행되지 않을 상황에서 초기 최종 오류를 보고할 수 있다. 연결과 본문 처리는 전송 계층의 문제다. 정오표 2924는 HTTP 연결에서 발생할 수 있는 모든 초기 신호가 아니라 IPP 요청에 대한 프린터의 최종 성공 또는 오류 응답을 다룬다.

마찬가지로 성공적인 Print-Job 응답이 종이가 나왔다는 뜻도 아니다. IPP 연산은job-id와job-uri를 반환할 수 있어 클라이언트가 이후 상태 질의에 사용할 핸들을 얻는다. RFC 8011의 작업 모델은 작업이 제출 후 여러 상태를 거칠 수 있도록 한다. 문서 데이터 수신, 작업 생성, 처리, 마킹, 전달은 서로 다른 단계다. 애플리케이션이 어느 단계에 대해 주장한다면 각 단계마다 자체적인 근거가 필요하다.

이 구분은 재시도와 회계 처리에서 중요하다. 소프트웨어가 요청 본문이 정의된 경계를 넘었는지 알기 전에 최종 응답을 보면, 재시도해야 하는지, 작업이 존재하는지, 중복이 생길 수 있는지 알지 못할 수 있다. 최종 응답을 전체 수신 이후로 옮기면 그 모호성이 좁아진다. 하지만 이는 정확히 한 번의 인쇄, 내구성 있는 저장, 성공적인 렌더링, 사람에게의 성공적 전달을 보장하지는 않는다.

정정 기록이지 배치 기록이 아니다

기록은 규칙에 대해서는 정확하고 채택에 대해서는 침묵한다. RFC Editor는 정오표 2924를 기술(Technical) 정오표로 기록하며, 2011년 8월 Michael Sweet가 보고하고 11월에 Peter Saint-Andre가 검증했다. 정오표도 RFC들도 어떤 제품이 이를 구현했는지, 현장에서 프린터가 실제로 어떻게 동작했는지, 특정 장애가 기존 문구 때문에 발생했는지를 확립하지 않는다. 안전한 주장은 프로토콜 안내에 관한 것이지 문서화되지 않은 업계 사건에 관한 것이 아니다.

2017년까지 RFC 8010과 RFC 8011이 RFC 2910과 RFC 2911을 갱신된 전송 및 모델 문서로 대체했다. 이후의 IPP 명세도 계층 구조를 유지한다. HTTP는application/ipp메시지 본문을 실어 나르고, IPP 연산은 자체적인 상태와 작업 의미를 가지며, 물리적 장치는 더 긴 수명 주기를 갖는다. 2011년의 정정을 이후 문서들과 나란히 읽으면 최종 응답에 정의된 경계가 왜 필요한지 알 수 있지만, 수신과 결과 사이의 구분이 사라지지는 않는다.

따라서 RFC 3196의 정오표는 규율 있는 확인 메커니즘을 통해 인프라가 판독 가능해지는 작은 사례다. 바이트가 움직이기 시작했다고 해서 그것이 곧 작업은 아니다. 서버가 식별자를 반환했다고 해서 작업이 곧 인쇄된 페이지는 아니다. 유용한 질문은 언제나 이것이다. 어느 계층이 무엇을 확인했고, 무엇이 아직 입증되지 않았는가?

출처

근거 경계

인용된 표준 문서들은 프로토콜 규칙과 편집 역사를 담고 있다. 제품 채택, 측정된 성능, 배치 규모, 특정 장애, 또는 어떤 성공 응답이 내구성 있는 저장이나 물리적 출력을 보장한다는 것을 확립하지 않는다.