Mike & Glen,
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.
I had originally thought that DocumentPassword would be handled the same as JobPassword. I just copied the definition. Since the DocumentPassword is not encrypted there is no associated DocumentPasswordEncryption. I do need to add the same length limitation to JobPassword except the length would be 340 for 255 octets.
DocumentPassword
No
Base64Binary
1:1366
1
[JPS3] §5.1.2
Specifies the unencrypted passphrase to be used to access the document content. (DocumentPassword length maximum is 1024 octets before encoding)
JobPassword
No
Base64Binary
1:340
2
[PWG5100.11] §6.1
Password supplied by the client, encrypted according to method specified by the client in the JobPasswordEncryption Element. (JobPassword length maximum is 255 octets before encoding)
Peter Zehler
Xerox Research Center Webster
Email: Peter.Zehler at Xerox.com <mailto:Peter.Zehler at Xerox.com>
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701
From: mfd-bounces at pwg.org [mailto:mfd-bounces at pwg.org] On Behalf Of Michael Sweet
Sent: Wednesday, January 18, 2012 7:31 PM
To: Petrie, Glen
Cc: mfd at pwg.org
Subject: Re: [MFD] Concerns with new PJT spec
Glen/Pete,
Note that document-password is an operation attribute in IPP and is specifically omitted from the job ticket for security reasons, so we probably *don't* want it in PJT or the semantic model (at least as a <service>DocumentProcessing element).
On Jan 18, 2012, at 2:59 PM, Petrie, Glen wrote:
Pete,
(I already sent these to Pete, but thought I should put on list for everyone.)
DocumentPassword in PJT is defined as Base64Binary and constraint = unlimited. But JPS3 state is it an octetString of length (max) of 1024.
I also read the description in JPS3 and it states that the document password in "unencrypted". I think it would be very important to add the pharse 'unencrypted' in the PJT document.
Appendix A is not complete sorted. I think there was a cut/paste error DocumentMessage to DocumentNatural Language is repeat in the table. Once on page 43 and again on 44.
Title for Figure 5 should be CoverCol DataType instead of Cover DataType
Glen
--
This message has been scanned for viruses and
dangerous content by MailScanner <http://www.mailscanner.info/> , and is
believed to be clean. _______________________________________________
mfd mailing list
mfd at pwg.org <mailto:mfd at pwg.org>
https://www.pwg.org/mailman/listinfo/mfd <https://www.pwg.org/mailman/listinfo/mfd>
__________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
This message has been scanned for viruses and
dangerous content by MailScanner <http://www.mailscanner.info/> , and is
believed to be clean.
--
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/0feb3307/attachment-0002.html>