INTERNET-DRAFT QUALDOCS protocol 17 December 1999 Paul Moore Internet-Draft Peerless Systems Networking Expires June 2000 QUALDOCS Protocol Specification Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This document specifies the QUALDOCS (QD) protocol. The QD requirements are derived from the requirements for Internet Fax [1]. In summary QD is used to provide a synchronous, reliable exchange of image documents between clients and servers. The primary use envisaged of this protocol is to provide a synchronous image transmission service for the Internet. Contrast this with the store and forward fax-like protocol specified in [2] and [3]. This document proposes that the QD protocol should use an extended version of IPP1.1 [4], [5]. Moore QUALDOCS working group [Page 1] INTERNET-DRAFT QUALDOCS protocol 17 December 1999 1 INTRODUCTION......................................................3 1.1 NAMESPACE USED.................................................3 1.2 MODEL..........................................................3 1.3 TYPICAL EXCHANGE...............................................3 1.4 GATEWAYS.......................................................4 2 QD DETECTION......................................................4 2.1 DEGRADED MODE..................................................4 3 DATA FORMATS......................................................5 3.1 FORMAT NEGOTIATION.............................................5 3.2 TIFF-FX........................................................5 4 IDENTITY EXCHANGE.................................................6 4.1 SENDING USER...................................................6 4.2 RECEIVING USER.................................................6 4.3 SENDER.........................................................6 4.4 RECEIVER.......................................................6 5 DATA EXCHANGE.....................................................6 5.1 ADDRESSING.....................................................6 5.2 TRANSMISSION...................................................6 5.3 CONFIRMATION...................................................7 5.4 COVER PAGES....................................................7 5.5 IDENTITY STAMPING..............................................7 5.6 COMBINED DEVICES...............................................7 6 IPP IMPLEMENTATION................................................7 6.1 CANCELING JOBS.................................................8 6.2 QUERYING JOBS..................................................8 6.3 JOB SUBMISSION.................................................8 6.4 OTHER OPERATIONS...............................................9 7 SECURITY CONSIDERATIONS...........................................9 7.1 PRIVACY........................................................9 7.2 SPOOF-PROOFING.................................................9 7.3 ACCESS CONTROL.................................................9 7.4 REDUCED FEATURE SET............................................9 8 GATEWAYS TO OTHER SYSTEMS.........................................9 8.1 ON-RAMPS......................................................10 8.2 OFF-RAMPS.....................................................10 9 FORMAL ATTRIBUTE DEFINITION......................................10 9.1 QD-SENDING-USER-IDENTITY......................................10 9.2 QD-RECEIVING-USER-IDENTITY....................................10 9.3 QD-SENDER-IDENTITY............................................11 9.4 QD-RECEIVER-IDENTITY..........................................11 9.5 QD-DESTINATION-SCHEME-SUPPORTED...............................11 9.6 QD-DESTINATION-URI............................................11 9.7 QD-RECEIVER...................................................12 Moore QUALDOCS working group [Page 2] INTERNET-DRAFT QUALDOCS protocol 17 December 1999 9.8 QD-RETURN-ADDRESS.............................................12 9.9 QD-TIFF-CAPABILITIES..........................................12 10 ADDENDA.........................................................13 10.1 REFERENCES..................................................13 10.2 ACKNOWLEDGEMENTS............................................13 10.3 FULL COPYRIGHT STATEMENT....................................14 1 Introduction. Note - It is assumed that the reader is familiar with IPP. QD is primarily intended as a method of supporting a secure, high quality document distribution protocol over the Internet. It therefore discusses paper, pages, scanning and printing, etc. There is however no requirement that the input documents come from actual paper nor is there a requirement that the output of the process be printed paper. The only conformance requirements are those associated with the exchange of data over the network. 1.1 Namespace used The extension specified in this document uses the prefix 'QD-' for all new IPP elements created. 1.2 Model This proposal defines a logical model of a QD interchange. The following terms are introduced: - 'Sender'. This is the agent (software, hardware or some combination) that is used to transmit a document to a receiver. 'Receiver'. This is the agent that receives the document sent by the sender. 'Document'. A document is a set of one or more pages that the sender sends to the receiver. 'Sending user'. The person interacting with the sender. 'Receiving user'. The intended human recipient of the document being sent. 'QD Job'. An IPP job submitted by a sender. 'Combined Device'. This is a software / hardware combination that is both a sender and a receiver. This is expected to be a common configuration. There are specific requirements for this type of device . see 'Combined Devices'. 1.3 Typical exchange The sending user determines the address of the receiver . see 'Addressing'. This document does not specify how the sending user does this. Possible methods include directory lookup, search engines, business cards, network enumeration protocols such as SLP, etc. Moore QUALDOCS working group [Page 3] INTERNET-DRAFT QUALDOCS protocol 17 December 1999 The sending user loads the document into the sender, indicates the receiver's address and starts the exchange. The sender determines whether or not the receiver is a QD capable device . see 'QD detection' The following identities are determined and exchanged: sender, sending user, receiver and receiving user . see 'Identity exchange' The sender scans the documents and converts them into an acceptable data format . see 'data formats' This data is transmitted to the receiver . see 'Data Transmission'. The sending user receives a confirmation that the receiver received the document . see 'Confirmation' If the sender is unable to initiate or complete the exchange then it is assumed that it will perform some form of retry. The mechanisms used and the user-visible behavior in this case is an implementer's choice beyond the scope of this document. 1.4 Gateways The QD protocol may be used as a gateway protocol to or from other image transmission systems. See 'Gateways to other systems' later. 2 QD detection A sender needs to determine whether or not the destination URL it has represents:- a) A valid IPP destination b) A QD receiver (not all IPP destinations are QD receivers) This document does not specify how to perform the first validation. Refer to the IPP implementer's guide [6]. To perform the second validation a sender SHOULD execute an IPP 'get- printer-attributes' operation to retrieve the 'QD-receiver' attribute. If the IPP printer supports this attribute then sender can be sure that it is a QD receiver. If not then the sender may choose to abandon the exchange or to enter degraded mode. 2.1 Degraded Mode QD describes a variation of IPP . it is perfectly possible for a complete QD-like exchange to take place between a QD client and an IPP printer. From the viewpoint of QD this is a degraded mode of operation. The main features that will be missing are:- Guaranteed exchange: Since IPP does not mandate any data formats it is possible that the sender may not be able to discover a common data format that both it and the printer support. Identity exchange: IPP does not provide the definitive identity exchange that QD does. In many cases however this is acceptable Moore QUALDOCS working group [Page 4] INTERNET-DRAFT QUALDOCS protocol 17 December 1999 3 Data formats In order to usefully exchange documents between arbitrary QD end points there must be some agreement on what formats are used to represent the data. This document therefore defines two things:- . A mechanism for negotiating data formats . A minimal set of document formats that all senders and receivers need to implement 3.1 Format negotiation The format negotiation is very simple. The sender SHOULD use the IPP 'get-printer-attributes' operation to read the 'document-format- supported' attribute of the receiver. The sender then either selects the most appropriate format or decides that it cannot interact with the receiver. Note that this document does not specify the sender behavior in the latter case. Additional format negotiation may take place depending on the gross format selected (see TIFF-FX below). The additional negotiation is performed by the sender reading one or more format specific IPP printer attributes. Note that a sender MAY use any means it chooses to determine what format to send. It may have a-priori knowledge of the receiver or determine that it can support other data formats using some other mechanism (for example it can read the receiver's manufacturer and model and therefore determine the formats supported). The sender SHOULD NOT send any data format that the receiver does not support. If it does so the receiver will reject it (IPP conformance). The sender MAY send any supported format to the receiver. It is the sender's choice; the receiver has no way of indicating preferred formats The sender MUST specify the data format being sent by including the (optional in IPP) job attribute 'document-format' 3.2 TIFF-FX A receiver MUST support TIFF-FX format [8]. This means that the 'document-format-supported' printer attribute MUST contain "application/tiff". The conformance requirements are those laid out in [8], this specifies what profiles are required and what profiles are optional. For example a B&W receiver MUST support profile S (MH) and may choose to support profile J (JBIG). To enable the sender to determine what 'flavor' of TIFF-FX to use the receiver MUST support the 'QD-TIFF-capabilities' attribute. [NOTE: There is some debate about what profiles, resolution, etc., of FX should be mandated. It seems to me that the right thing to do is to mandate conformance with 2301. If 2301 does not specify the right conformance levels then it should be changed (given that it was designed specifically for this application). Moore QUALDOCS working group [Page 5] INTERNET-DRAFT QUALDOCS protocol 17 December 1999 I also think that we do not need to mandate a lot. Given that I have defined a flavor detection mechanism a sender can tell if a receiver support JBIG or not, supported resolutions, etc. The important point is that by mandating FX we all get into the same ball park- s smart client can do the rest] 4 Identity exchange 4.1 Sending user The sending user identity SHOULD be sent to the receiver. The identity is specified in a new IPP job attribute . 'QD-sending-user-identity'. This is in mime vcard [12] format. 4.2 Receiving User The identity of the intended receiving user SHOULD be included in a request. The identity is specified in a new IPP job attribute, 'QD- receiving-user-identity'. This is in mime vcard format[12]. 4.3 Sender The sender MUST have an identity in the same way that a fax machine has a sending station ID. The sender's identity MUST be sent to the receiver using a new IPP job attribute, 'QD-sender-identity'. The value of this identity is not specified but SHOULD be a value that can reasonably be expected to uniquely identify the device. A value derived from the MAC address would be a reasonable starting point. 4.4 Receiver The receiver MUST have an identity that the sender MAY read. The receiver MUST make this available via a new IPP printer attribute, 'QD- receiver-identity'. The same rules apply as for the sender identity. 5 Data Exchange 5.1 Addressing The receiver's address MUST be an IPP1.1 URL using the 'ipp' scheme. Example: 5.2 Transmission Documents MUST be sent using the IPP print-job operation. There is no requirement for the receiver to support any other IPP job submission operations. The sender MAY include any valid job description or job template attributes. Moore QUALDOCS working group [Page 6] INTERNET-DRAFT QUALDOCS protocol 17 December 1999 5.3 Confirmation The sender knows when the receiver has successfully received the entire document, the sender can then inform the sending user. The sender SHOULD use the successful end of the print-job operation as an indication that the receiver has received the document. 5.4 Cover Pages A receiver MAY create a cover page to be placed at the beginning of the received document. This mechanism replaces (and uses the same attributes) the IPP job sheet system. The format of the cover page is not specified by this document but SHOULD include:- . The sending users details . from 'QD-sending-user-identity' . The receiving user details . from 'QD-receiving-user-identity' . The sender's identity . from 'QD-sender-identity' . The receiver's identity . from 'QD-receiver-identity' . The local date and time . The subject . from job-description . The page count . from job-media-sheets if it was supplied In some cases a client may not want a cover page to be automatically generated (there might already be a cover page included in the document). It MAY therefore set the job-sheets job attribute to 'none' to indicate that it does not want a cover page. 5.5 Identity Stamping The receiver SHOULD place the receiver identity on the first page of the received document. 5.6 Combined Devices If a device implements both a sender and a receiver then there are certain things it is required to do. The 'QD-sender-identity' MUST be the same as the 'QD-receiver- identity'. That means that they match byte for byte. The sender MUST include the address of its receiver component in every request. It does this with a new IPP job attribute, 'QD-return- address'. A non-combined device MAY include a 'QD-return-address' in a request. 6 IPP Implementation The receiver MUST implement a fully conformant IPP1.1 printer object. There is no requirement for the receiver to implement any of the optional features of IPP unless explicitly stated elsewhere in this document. Moore QUALDOCS working group [Page 7] INTERNET-DRAFT QUALDOCS protocol 17 December 1999 QD restricts the use of IPP in certain cases. One aim is to make attaching a receiver to the Internet a safe option . see 'security considerations' 6.1 Canceling jobs It is inappropriate for a sender to transmit a document, receive confirmation of its arrival and then cancel it. Therefore: - The sender SHOULD NOT attempt to cancel the print job once it has been sent to the receiver. The receiver MUST reject cancel job operations targeted at QD jobs. (The receiver can determine that this is a QD job by the presence of the mandatory 'QD-sender-identity' job attribute). The 'cancel-job' operation therefore becomes a privileged operation on all QD-jobs. This is a change to the IPP behavior. 6.2 Querying jobs The public nature of QD interactions make it inappropriate for a sender to be able to query a receiver for information about jobs that it did not send. The MUST restrict the job attributes that any sender can request for any QD job in a 'get-jobs' or 'get-job-attributes' operation to: - . job-id, job-URI . job-k-octets, job-k-octets-completed . job-media-sheets, job-media-sheets-completed, . time-at-creation, time-at-processing . job-state, job-state-reasons . number-of-intervening-jobs This attribute set allows a sender to determine the load on a receiver (and perhaps choose an alternative destination or warn the sending user). See the discussion in section 8.4 of [4] for a description of how a receiver must behave if it receives a request for an attribute outside this set. An IPP administrator may read all attributes. 6.3 Job submission A receiver MUST NOT support any of the optional job submission operations. What this means is that the IPP printer object must not allow 'QD-sender-identity' on any operation other than 'print-job'. A receiver MUST reject an operation (other than 'print-job') that contains a 'QD-sender-identity' job attribute. It does this by returning a '401 not authorized' error Moore QUALDOCS working group [Page 8] INTERNET-DRAFT QUALDOCS protocol 17 December 1999 6.4 Other Operations All other IPP operations MUST be treated as administrative by the receiver even in the case where IPP would normally permit them. For example the hold-job operation cannot be used by a sender except in the case where the sending user is identified as an IPP administrator. 7 Security considerations QD presents an interesting challenge of balancing security and openness. Many of the envisaged uses of QD require confidentiality of the data . at the same time the receiver typically has no prior knowledge of the sender or the sending user. This last point will normally rule out all user-based authentication and access control. This is the reason for the restriction placed on querying and canceling QD jobs. 7.1 Privacy Any exchange between a sender and a receiver MAY be carried using the privacy mechanism specified in IPP1.1 namely TLS [9]. In some cases this will also result in mutual authentication of the sender and receiver (in the case where both sides have certificates). 7.2 Spoof-proofing It is unlikely that large numbers of QD devices will have certificates that will allow for mutual trusted authentication. This presents the problem of how one can guarantee that the QD identities that are exchanged are valid. The best solution to this would be to use digital signatures . this is beyond the scope of this document. 7.3 Access control It is expected that the majority of QD receivers will operate in a public mode. However a receiver MAY protect itself using any method specified in [4] (digest authentication [11] for example) to restrict access to any or all of its functionality. 7.4 Reduced feature set An administrator or device implementer may choose to setup up a device so that it only works as a QD receiver (i.e., offers no 'native' IPP features). In this mode it offers a restricted set of features and may be more safely connected to the Internet. A receiver that is operating in this mode SHOULD do so by rejecting any non-QD request with a '401 not authorized' error code. 8 Gateways to other systems A common scenario will be where QD acts as an on-ramp or off-ramp to other document transmission systems. Moore QUALDOCS working group [Page 9] INTERNET-DRAFT QUALDOCS protocol 17 December 1999 8.1 On-Ramps 'On-ramp' means that the user with a document to send uses a QD sender to transmit a document to a QD receiver that in turn transmits it to some other destination. In order that the intermediate gateway should know where to send the document the sender needs to tell the gateway where to send the document. The sender uses the 'QD-destination-URI' job description attribute for this purpose. Note that this is only useful in the on- ramp case. The on-ramping receiver SHOULD indicate to the sender the addressing schemes it supports for 'QD-destination-URI'. It does this with the 'QD-destination-schemes-supported' attribute. 8.2 Off-ramps 'Off-ramp' means that the user originally sends the document using some other mechanism. The intermediate agent then uses QD to transmit the document to its final destination. QD has no specific support for off- ramps. 9 Formal Attribute Definition 9.1 QD-sending-user-identity Format: octetString(1023) Type: job description Description: This attribute is used by the sender to indicate the sending user's identity to the receiver. It is in vcard format. Note that a valid vcard identity block could exceed 1023 octets in length. The sender implementation must ensure that the actual value is 1023 or less I length. Conformance: A QD receiver MUST support this attribute. A sender SHOULD send this attribute Example: BEGIN:VCARD VERSION:2.1 N:Moore;Paul FN:Paul Moore ORG:Peerless Systems Networking TEL;CELL;VOICE:(206) 251-7008 ADR;WORK:;;10900 NE 8th St;Bellvue;WA;98004;United States of America EMAIL;PREF;INTERNET:pmoore@peerless.com REV:19991207T215341Z END:VCARD 9.2 QD-receiving-user-identity Format: octetString(1023) Moore QUALDOCS working group [Page 10] INTERNET-DRAFT QUALDOCS protocol 17 December 1999 Type: Job description Description: This attribute is used by the sender to indicate the identity of the intended human recipient. Refer to the description of QD-sending-user-identity for a discussion of the length of this attribute. Conformance: A QD receiver MUST support this attribute. A sender SHOULD send this attribute 9.3 QD-sender-identity Format: name Type: Job description Description: This attribute is used by the sender to identify itself. The presence of this job description attribute also marks the job as a QD job. Conformance: A receiver MUST support this attribute. A sender MUST send this attribute 9.4 QD-receiver-identity Format: name Type: Printer description Description: This attribute uniquely identifies the receiver. Conformance: A receiver MUST implement this attribute. 9.5 QD-destination-scheme-supported Format: 1setOf type2 keyword Type: Printer Description Description: This attribute is used by the receiver to indicate what formats it supports for the 'QD-destination-URI' attribute. The values in this list are URI scheme names without their trailing ':' . i.e. 'ipp', 'mailto', . Conformance: A receiver SHOULD implement this attribute if it is acting as an on-ramp. 9.6 QD-destination-URI Format: URI Type: Job description Description: A sender SHOULD include this attribute in a job in the case where it knows that the receiver is not the final destination. The scheme of this URI MUST be one of those specified by 'QD-destination- scheme-supported'. Conformance: An on-ramping receiver MUST support this attribute. Moore QUALDOCS working group [Page 11] INTERNET-DRAFT QUALDOCS protocol 17 December 1999 9.7 QD-receiver Format: Boolean Type: Printer description Description: A receiver uses this attribute to indicate that it is a QD receiver. Conformance: A QD receiver must support this value and it must have the value TRUE. 9.8 QD-return-address Format: URI Type: Job description Description: A combined device uses this attribute to indicate the address of its receiver when sending a job. Conformance: A receiver MUST support this attribute (note that this does not mean it necessarily does anything useful with it). A combined device SHOULD send this attribute. 9.9 QD-TIFF-capabilities Format: octetString(1023) Type: Printer description Description: The receiver uses this attribute to indicate the TIFF-FX feature set it supports. It is encoded as per RFC 2531 [7]. Conformance: A receiver MUST implement this attribute. Example: This is taken directly from [7]. (& (| (& (color=Binary) (image-file-structure=[TIFF-S,TIFF-F,TIFF-J]) (| (image-coding=[MH,MR,MMR]) (& (image-coding=JBIG) (image-coding-constraint=JBIG-T85) (JBIG-stripe-size=128) ) ) (| (& (dpi=200) (dpi-xyratio=200/100) ) (& (dpi=200) (dpi-xyratio=1) ) (& (dpi=204) (dpi-xyratio=204/391) ) (& (dpi=300) (dpi-xyratio=1) ) ) ) (& (| (& (color=Grey) (color-levels<=256) ) (& (color=Full) (color-levels<=65536) (color-subsampling=["1:1:1","4:1:1"]) ) ) (image-file-structure=[TIFF-C,TIFF-L]) (color-space=CIELAB) (| (& (image-coding=JPEG) (image-coding-constraint=JPEG-T4E) ) (& (image-coding=JBIG) (image-coding-constraint=JBIG-T43) Moore QUALDOCS working group [Page 12] INTERNET-DRAFT QUALDOCS protocol 17 December 1999 (JBIG-stripe-size=128) (image-interleave=stripe) ) ) (dpi=[100,200,300]) (dpi-xyratio=1) ) ) (MRC-mode=0) (paper-size=[A4,B4]) ) [Issue: The size of any attribute is limited to 1024 by IPP . the above example is around 600. This could cause some problems with receivers that support a lot of features. Either we cross our fingers and hope . or use an array] 10 Addenda 10.1 references [1] Masinter , "Terminology and Goals for Internet Fax", RFC2542 [2] Toyoda, Ohno, Murai, Wing "A Simple Mode of Facsimile Using Internet Mail" RFC2305 [3] Masinter, Wing, "Extended Facsimile Using Internet Mail", RFC2532 [4] deBry, Hastings, Herriot, Isaacson, Powell, "Internet Printing Protocol/1.1: Model and Semantics", draft-ietf-ipp-model-v11- 04.txt [5] Herriot, Butler , Moore, Turner, Wenn. "Internet Printing Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol- v11-03.txt [6] Hastings, Manros, ,Kugler, Holst, "Internet Printing Protocol/1.1: Implementer's Guide", draft-ietf-ipp-implementers- guide-v11-00.txt [7] Klyne, McIntyre. "Content Feature Schema for Internet Fax", RFC2531. [8] McIntyre, Zilles, Buckley, Venable, Parsons, Rafferty "File Format for Internet Fax", RFC2301 [9] Dierks, Allen "The TLS Protocol Version 1.0",RFC 2246 [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", RFC2119 [11] Franks, Hallam-Baker, Hostetler, Leach, Luotonen,, Sink, Stewart, "An Extension to HTTP: Digest Access Authentication", RFC2069 [12] Dawson, Howes, "vCard MIME Directory Profile", RFC 2426 10.2 Acknowledgements The author would like to thank the following for their contributions: Nick Webb, Richard Shockey, Tom Hastings, Carl-Uno Manros. Moore QUALDOCS working group [Page 13] INTERNET-DRAFT QUALDOCS protocol 17 December 1999 10.3 Authors Address Paul Moore pmoore@peerless.com 10.4 Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Moore QUALDOCS working group [Page 14]