요약

  • RFC 3380은 지원되는Set-Job-Attributes요청을 프린터가 부분적으로 수용할 수 있는 필드 목록이 아니라 하나의 제안된 상태로 취급했습니다.
  • 지원되지 않는 값이나 충돌하는 값이 있으면 요청 전체가 거부되고 작업(Job)은 변경되지 않습니다. 인쇄 작업이 취소되는 것도 아니고 실제 출력에 대한 증거도 아닙니다.

2002년 9월, 인터넷 인쇄는 더 명시적인 관리적 측면을 갖추어 가고 있었습니다. IPP 1.1은 작업을 생성하고 검사할 수 있었지만, 최종 사용자나 운영자는 제출 후에 마무리 지침이 누락되었음을 발견할 수 있었습니다. RFC 3380은 취소 후 재제출이라는 대안 외에 기존 Job 객체의 속성을 변경하는 선택적 방법을 제시했습니다.

이 편의 기능에는 명확한 경계가 있었습니다. 프린터는 제안된 속성을 클라이언트가 변경하지 않고 남겨둔 작업 속성과 함께 평가했습니다. RFC 3380은 반사실적 질문을 던졌습니다. 이 완전한 결과 속성 집합으로 새 작업을 생성했다면ipp-attribute-fidelity=true조건에서 수용되었을까? 그렇다면 집합 연산은 수용되어야 했습니다. 그렇지 않다면 프린터는 이를 거부하고 기존 Job을 변경되지 않은 상태로 두어야 했습니다. 지원되지 않는 속성, 구현이 설정할 수 없는 값, 또는 다른 속성과의 충돌은 쉬운 필드만 적용하는 방식으로 조용히 구제될 수 없었습니다. 요청은 전부 아니면 전무였습니다.

이것은 단순히 편리한 오류 응답 그 이상이었습니다. 클라이언트가 부분적으로만 변경된 작업을 요청한 상태로 오해하는 일을 막았습니다. 또한 이 경계를 관찰 가능하게 만들었습니다. 응답은 검증에 실패한 속성을 식별할 수 있으며, Job 자체는 이전 상태를 유지합니다. 권한 부여는 별도의 검사였습니다. 인증된 요청자는 Job 소유자이거나 운영자 또는 관리자여야 했고, 질문할 권한이 있다고 해서 유효하지 않은 조합이 유효해지지는 않았습니다.

같은 문서는 프린터 구성 변경을 원자적으로 만들고, 특정 설정 가능 속성에 대해 프린터가 수용할 값을 발견하기 위한Get-Printer-Supported-Values를 추가했습니다. 또한printer-xri-supported가 관련 URI, 인증 및 보안 설명을 함께 갱신하도록 허용했습니다. 그러나 RFC 3380은 Set 연산을 선택 사항으로 표시했습니다. 안전한 전환을 기술하는 표준 문서가 특정 프린터가 이를 구현했거나, 클라이언트가 사용했거나, 물리적 작업이 용지에 도달했다는 증거가 되지는 않습니다.

이 구분은 RFC 3196과 나란히 둘 때 중요합니다. 그 안내서의 이후 검증된 정오표는 프린터가 문서 데이터를 수신한 후 최종 응답을 언제 반환할 수 있는지 다룹니다. RFC 3380은 Job의 속성 변경에 관한 것입니다. 수용된 속성 업데이트든 거부된 업데이트든, 문서가 완전히 수신되거나 처리되거나 인쇄되었다는 뜻은 아닙니다. 프로토콜 이벤트는 상태 변경에 대한 접수이지 장비실에서 오는 접수가 아닙니다.

1차 원문을 읽어 보십시오:RFC 3380,IPP/1.1 모델 및 의미론, RFC 2911,RFC 3196. RFC 3380은 선택적 확장이었으며, 이러한 사양들은 배포나 상호운용성이 아니라 계약을 확립합니다.

출처