Subject: [IPP] {Disarmed} Toward resolving Apple's IPP WG Last Call JPS2 comments 4 thru 7 - for Mon, Jul 19, IPP WG telecon

From: "Tom Hastings" <[email-masked]>
Date: Sun, 18 Jul 2010 17:36:19 -0700

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.pdf

ftp://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: [email-masked] on behalf of Michael Sweet [[email-masked]]
Sent: Monday, June 21, 2010 12:58
To: [email-masked]
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.

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: "Tom Hastings" <[email-masked]>
Date: Sun, 18 Jul 2010 18:56:35 -0700

Since email with attachments is blocked by the IPP reflector (even small
ones), the attachment that I refer to below is also posted at:

This is RESEND 2 or 2 for tomorrow's IPP WG telecon, July 19.

Tom

  _____  

From: Tom Hastings [mailto:[email-masked]] 
Sent: Sunday, July 18, 2010 17:36
To: [email-masked]; 'Michael R Sweet'; 'Paul Tykodi'; 'Ira McDonald'
Cc: 'Tom Hastings'
Subject: Toward resolving Apple's IPP WG Last Call JPS2 comments 4 thru 7 -
for Mon, Jul 19, IPP WG telecon

and:

 

Comments:

   appropriate.

TH> Added:

TH> Fixed

[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.

Keyword

Description

'spool'

'stream'

'automatic'

 

- "color-supported", and

 

 

 

  _____  

 ISSUE: OK to add "1setOf" to "job-spooling-supported" as suggested by
Apple's IPP WG Last Call Comment #7a?

 ISSUE: Comment made during the June 21 telecon:

 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?

 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?

 ISSUE: OK to remove this sentence as suggested by Apple's Comment #7b? 

 ISSUE: OK to remove this paragraph as suggested by Apple's Comment 7c?

 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?