For the IPP WG telecon, tomorrow, Monday, July 19, here is 2 or 2 input for
the agenda topic:
Since the font, highlighting, and indentation will be smashed when this mail
message is turned to plain text, I've attached a 63 KB .pdf which is much
more readable, complete with line numbers to make it easier to discuss at
the telecon. I've also down loaded v30 of JPS2 .doc and .pdf (without hot
links). If Pete Zehler can update the .pdf that would be good, but he may
be on vacation. So the following 6 documents are in the wd sub-folder for
the IPP WG telecon tomorrow, Monday, July 19:
ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v30-20100718.pdfftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v30-20100718.doc
and the following two documents that attempt to resolve Apple's IPP WG Last
Call comments (same as I attached to this and the previous email):
ftp://ftp.pwg.org/pub/pwg/ipp/wd/Toward-resolving-Apples-JPS2-comments-4-thr
u-7.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/wd/Toward-resolving-Apples-JPS2-comments-4-thr
u-7.doc
and:
ftp://ftp.pwg.org/pub/pwg/ipp/wd/Toward-resolving-Apples-JSP2-comment-on-uni
ts-for-font-size-requested.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/wd/Toward-resolving-Apples-JSP2-comment-on-uni
ts-for-font-size-requested.doc
(Yes, the S and P are switched in this last file name by mistake).
For the IPP WG telecon, tomorrow, Monday, July 19, here is 2 or 2 input for
the agenda topic:
> (5) Status of IPP WG Last Call on IPP JPS2 (Tom) - ends Monday 12 July
> -
>ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v28-20100606-cl
> ean.pdf
> (ended Monday 12 July 2010)
>
> (6) Next Steps
> - IPP WG - Monday 26 July
> - IPP JPS2 into PWG Last Call?
File: Toward-resolving-Apples-JPS2-comments-4-thru-7.doc
From: ipp-bounces at pwg.org on behalf of Michael Sweet [msweet at apple.com]
Sent: Monday, June 21, 2010 12:58
To: ipp at pwg.org
Subject: [IPP] Apple has reviewed the JPS2 specification and has comments
Attachments: ATT02705.txt
Comments:
1. The document date is wrong in the headers.
TH> Updated to today's date.
2. The "font-size-requested" attribute uses points as the units, however it
should probably use a higher-precision unit (at least decipoints, or 1/720th
of an inch) to avoid issues with getting common fixed-width font spacing
right (e.g. 17 characters per inch with a standard Courier font would need a
point size of 5.293...) [And apologies for the late notice on this - I
haven't read through the older material in a while...]
TH> See separate email thread and attached .pdf more readable version for
this issue and possible alternatives for resolution.
3. Question: do we need the PWG process reference at the beginning of
section 3? Do we need to explain why we organize our standards documents
this way?
TH> Need IPP WG input here.
4. On line 372 of the -rev document you say "these features are useful in
the "light production printing" environments, but we don't define what
"light production printing" is, just "production printing".
TH> Just remove the clause entirely, OK?
5. Line 427 - I think Close-Job is Owner + Operator, per RFC 2911's
description of Send-Document and the Close-Job references in JPS2:
Access Rights: The authenticated user (see section 8.3) performing
this operation must either be the job owner (as determined in the
Create-Job operation) or an operator or administrator of the Printer
object (see Sections 1 and 8.5). Otherwise, the IPP object MUST
reject the operation and return: 'client-error-forbidden', 'client-
error-not-authenticated', or 'client-error-not-authorized' as
appropriate.
TH> Added:
Access Rights: The authenticated user (see [RFC2911] section 8.3) performing
this operation must either be the job owner (as determined in the Create-Job
operation) or an operator or administrator of the Printer object (see
[RFC2911] Sections 1 and 8.5). Otherwise, the IPP object MUST reject the
operation and return: 'client-error-forbidden',
'client-error-not-authenticated', or 'client-error-not-authorized' as
appropriate.
6. Line 567-568: The definition says up to 255 characters for job-password
and job-password-supported, but here we say 127 octets.
TH> Fixed
7. a: Section 10.5 (job-spooling-supported) - shouldn't this be a 1setOf?
b: Also, lines 580-581 basically says that the values are
implementation-dependent regardless of whether the attribute is supported or
not. :)
c: Based on the current description I think we need to specify when the
value is 1setOf and when it is not (i.e. a Get-Printer-Attributes request
with a document-format would return the value for that format, otherwise
you'd get the value for the default format or a 1setOf if the answer can't
be made definitively without a format...)
d: This will also affect the registration info on line 1073.
TH> Apple's 4 suggestions (which I've labeled a thru d) are that a Printer
implementation MAY vary the spooling strategy based on the document format.
For example, a document format that might have backward references would
require the Printer to spool, while one that cannot, the Printer might
stream. Therefore, even though there is no way for the client to dictate to
the Printer which strategy to use, since there isn't a Job Template
attribute to recommend/require the spooling strategy (unless we want to add
one), the Printer could support more than one value of
"job-spooling-supported", depending on the document format(s) of the
document(s) in the submitted job.
I've taken a stab at clarifying that "job-spooling-supported" can depend on
the document format supplied in the job, as suggested by Apple comment #7:
10.5 job-spooling-supported (1setOf[th1] <> type2 keyword)[th2] <>
This attribute indicates whether or not jobs are spooled before the document
data is interpreted (RIPped). In other words, this attribute indicates when
jobs are processed by the Printer with respect to when the Printer receives
and returns responses to Job Creation requests (i.e., Print-Job, Print-URI),
receives and returns responses to Document Creation requests (i.e.,
Send-Document and Send-Uri requests) and "receives" or "fetches" such
document data.
The value of this attribute returned in a Get-Printer-Attributes response
MAY depend on the "document-format" [th3] <> attribute supplied in the
Get-Printer-Attributes request (see [RFC2911] Section 3.2.5.1 and 6.2).[th4]
<>
[th5] <> If the Printer supports this attribute, the value supported depend
on implementation. If the Printer does not support this attribute, then the
spooling behavior is implementation dependent.
The Get-Printer-Supported-Values operation (see description in [RFC3380])
returns a '1setOf type2 keyword' so that all possible values that the
implementation is capable of supporting are indicated.[th6] <>
The standard keyword values are:
Keyword
Description
'spool'
The Printer starts processing a job until the Printer has (1) accepted and
responded to the Job Creation request and all Document Creation requests
(for a multi-document job) and (2) has "received" or "fetched" all document
data for the job, i.e., spool rather than stream.
'stream'
The Printer starts processing a job (1) before the Printer has accepted all
Document Creation requests and (2) before the Printer has "received" or
"fetched" all document data, i.e., stream rather than spool
'automatic'
The Printer chooses whether to process a job before or after the Printer has
accepted all Document Creation requests and has "received" or "fetched" all
document data, i.e., the Printer MAY spool and/or stream depending on policy
and other factors, such as the size of the job, and the document format[th7]
<> , including a combination of spooling and streaming.
TH> However, I don't think we need to get into the details about
Get-Printer-Attributes vs. Get-Printer-Attributes-Supported, since it is now
clear that multiple values MAY be returned in either or both operations,
depending on implementation. [RFC2911] Section 3.2.5.1
Get-Printer-Attributes goes into gory detail about attributes whose values
are affected by "document-format" supplied in the Get-Printer-Attributes
requests:
"document-format" (mimeMediaType):
The client OPTIONALLY supplies this attribute. The Printer object MUST
support this attribute. This attribute is useful for a Printer object to
determine the set of supported attribute values that relate to the requested
document format. The Printer object MUST return the attributes and values
that it uses to validate a job on a create or Validate-Job operation in
which this document format is supplied. The Printer object SHOULD return
only (1) those attributes that are supported for the specified format and
(2) the attribute values that are supported for the specified document
format. By specifying the document format, the client can get the Printer
object to eliminate the attributes and values that are not supported for a
specific document format. For example, a Printer object might have multiple
interpreters to support both 'application/postscript' (for PostScript) and
'text/plain' (for text) documents. However, for only one of those
interpreters might the Printer object be able to support "number-up" with
values of '1', '2', and '4'. For the other interpreter it might be able to
only support "number-up" with a value of '1'. Thus a client can use the
Get-Printer-Attributes operation to obtain the attributes and values that
will be used to accept/reject a create job operation.
If the Printer object does not distinguish between different sets of
supported values for each different document format when validating jobs in
the create and Validate-Job operations, it MUST NOT distinguish between
different document formats in the Get-Printer-Attributes operation. If the
Printer object does distinguish between different sets of supported values
for each different document format specified by the client, this
specialization applies only to the following Printer object attributes:
- Printer attributes that are Job Template attributes ("xxx-default"
"xxx-supported", and "xxx-ready" in the Table in Section 4.2),
- "pdl-override-supported",
- "compression-supported",
- "job-k-octets-supported",
- "job-impressions-supported,
- "job-media-sheets-supported"
- "printer-driver-installer",
- "color-supported", and
- "reference-uri-schemes-supported"
The values of all other Printer object attributes (including
"document-format-supported") remain invariant with respect to the client
supplied document format (except for new Printer description attribute as
registered according to section 6.3).
If the client omits this "document-format" operation attribute, the Printer
object MUST respond as if the attribute had been supplied with the value of
the Printer object's "document-format-default" attribute. It is RECOMMENDED
that the client always supply a value for "document-format", since the
Printer object's "document-format-default" may be
'application/octet-stream', in which case the returned attributes and values
are for the union of the document formats that the Printer can automatically
sense. For more details, see the description of the 'mimeMediaType'
attribute syntax in section 4.1.9.
If the client supplies a value for the "document-format" Operation attribute
that is not supported by the Printer, i.e., is not among the values of the
Printer object's "document-format-supported" attribute, the Printer object
MUST reject the operation and return the
'client-error-document-format-not-supported' status code.
________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
This message has been scanned for viruses and
dangerous content by <http://www.mailscanner.info/> MailScanner, and is
believed to be clean.
_____
[th1] <> ISSUE: OK to add "1setOf" to "job-spooling-supported" as suggested
by Apple's IPP WG Last Call Comment #7a?
[th2] <> ISSUE: Comment made during the June 21 telecon:
Add: "job-spooling-configured" (type2 keyword).
But there is no mention in the minutes.
Also with the Apple's Comment #7 suggestion that the spooling strategy could
depend on the document-format in the submitted job, configuring for a single
strategy wouldn't work.
OK NOT to add "job-spooling-configured"?
[th3] <> ISSUE: OK to add that the spooling used MAY depend on the document
format as suggested by Apple's Comment #7 and allowed by [RFC2911] Section
3.2.5.1 as long as explicitly called out in the definition as indicated in
[RFC2911] Section 6.2?
[th4] <> ISSUE: OK to add that the spooling used MAY depend on the document
format as suggested by Apple's Comment #7c, but refer to RFC 2911 Section
3.2.5.1 for the details about what is returned in Get-Printer-Attributes
response depending on whether or not the client supplies "document-format:
in the request?
[th5] <> ISSUE: OK to remove this sentence as suggested by Apple's Comment
#7b?
[th6] <> ISSUE: OK to remove this paragraph as suggested by Apple's Comment
7c?
[th7] <> ISSUE: OK to add that "document-format" could be an example that
causes the Printer to vary the spooling strategy as suggested by Apple's
Comment #7c?
--
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/ipp/attachments/20100718/bbd933e6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Toward-resolving-Apples-JPS2-comments-4-thru-7.pdf
Type: application/pdf
Size: 64156 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20100718/bbd933e6/attachment.pdf>