[MFD] Concerns with new PJT spec

[MFD] Concerns with new PJT spec

[MFD] Concerns with new PJT spec

Michael Sweet msweet at apple.com
Thu Jan 19 23:19:13 UTC 2012


On Jan 19, 2012, at 5:27 AM, Zehler, Peter wrote:
> ... 
> I disagree.  I think the mapping to XML would put the DocumentPassword in the DocumentProcessing group.  It is clearly an element that must be applied during the processing of a document in order to print it.  It will also be applicable to other services such as Scan.  DocumentPassword needs to be kept around from job submission until job processing.  The DocumentPassword and its value would be passed and stored in the Job Ticket.  Since the password is not encrypted the protocol binding would require that a ticket containing DocumentPassword MUST be rejected unless that request is sent over a secure channel.  Furthermore once at the printer the DocumentPassword would be a protected element and MUST NOT be returned in any response.  I used thebase64 data type for DocumentPassword to keep it XML safe.  This is the same data type mapping I used for other elements with a data type of OctetStrings.  The length, in XML, should be 1366 and a note included stating that a length of 1366 in Base64 is equivalent to 1024 unencoded octets.

In IPP we treat both job-password and document-password as operation attributes specifically to address the security concerns - there is no precedent for making some Job Template or Document Template attributes "write only" for clients, and we didn't want to "accidentally" import them into the job or document object where they would be exposed to clients.

Michael Sweet, Senior Printing System Engineer, PWG Chair

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/mfd/attachments/20120119/365548bf/attachment-0002.html>

More information about the mfd mailing list