I've copied this issue summary to:
ftp://ftp.pwg.org/pub/pwg/ipp/Issues/IPP1.1-issue-status.docftp://ftp.pwg.org/pub/pwg/ipp/Issues/IPP1.1-issue-status.pdfftp://ftp.pwg.org/pub/pwg/ipp/Issues/IPP1.1-issue-status.txt
See the more complete issue discussion in:
ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off2.docftp://ftp.pwg.org/pub/pwg/ipp/Issues/issues-raised-at-bake-off2.pdfftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off2.txtftp://ftp.pwg.org/pub/pwg/ipp/Issues/issues-raised-at-bake-off2-rev.pdf
The purpose of this issue summary is to help us see which issues are closed
and which still need more discussion on the mailing list and telecons.
After we have general agreement on the closed issues, we will propose the
actual text to make the clarification or addition.
SUBJ: IPP/1.1 Issue Status - Issues Raised at Bake Off 2
FROM: Tom Hastings and Bob Herriot
DATE: 3/29/99
FILE: IPP1.1-issue-status.doc
This summary records the results at the first telecon, held 3/24/99, on
resolving the IPP/1.1 issues and any email on the issues before or after
the telecon. Please review this status and the detailed issues list
mailed out early on 3/23/99 to see if you agree or disagree with the
status so far. Silence will be interpreted as agreement.
Note: These are issues that are to be resolved in the IPP/1.1 documents
before forwarding them to the IESG for publication as proposed
standards. The IPP/1.0 documents have already been forwarded to the RFC
Editor after approval by the IESG for publication as Informational RFCs,
so these issues and their resolution will not affect the IPP/1.0
documents.
Status codes:
AGREED - agreement on the telecon on the suggested clarification,
suggested change, or suggested. Subsequence silence on the DL will
be interpreted as agreement. If you disagree, please indicate this
to the ipp at pwg.org DL with the subject line containing: "MOD -",
the Issue number, and brief description of the issue.
OPEN - still being discussed at future telecons and on the DL.
1) ISSUE: Is 'application/octet-stream REQUIRED?
Suggested change: AGREED - no, change 1.1 back to agree with 1.0.
2) ISSUE: How can client force identified (authenticated) mode?
Possible alternatives: OPEN - alternatives being discussed: new
operation, two URLs, its not a problem. Also relationship to SLP
template.
3) ISSUE: How reject down stream auto-sensed unsupported PDL?
Suggested addition (similar addition for "compression" in Issue 6):
AGREED - add 'unsupported-document-format' and 'document-format-error'
job state reasons.
4) ISSUE: Client closes slow channel
Suggested clarification (same as Issues 5 and 20): AGREED that client
MUST NOT close channel, unless user indicates or policy. RAISE on DL to
verify AGREEMENT.
5) ISSUE: Client closes stopped device
Suggested clarification (same as Issues 4 and 20): AGREED that client
MUST NOT close channel, unless user indicates or policy. RAISE on DL to
verify AGREEMENT.
6) ISSUE: What error if wrong compressed data supplied?
Suggested addition (similar addition for document-format in Issue 3; see
related Issue 28): AGREED - add 'client-error-compression-error' status
code and 'compression-error' job state reason.
7) ISSUE: Please implement Manufacturer make and model printer
attribute and send the .INF file model name of the printer.
Suggested clarification for the IIG: OPEN - Need a general syntax that
separates the vendor name from the model name. Propose to the DL.
8) ISSUE: In IPP/1.0 Model and semantics 3.2.6.1, the definition for
"limit", "which-jobs" and "my-jobs" is contradicting each other.
Suggested clarification: AGREED - clarify the "limit" limits the number
so that the other two don't have to return ALL.
9) ISSUE: Customers become very unhappy when they go to the printer to
pick up their job and a ream of PostScript source code is sitting in the
output bin.
Suggested clarification: AGREED - clarify that application/octet-stream
(auto-sense) can happen at submit time and/or processing time, depending
on implementation. If auto-sense detects an unsupported document format
at submit time, it returns the 'client-error-document-format-not-
supported' error status code and rejects the create request.
10) ISSUE: How distinguish between submit vs processing auto-sense?
Suggested clarification in [ipp-mod] and [ipp-iig]: AGREED - clarify in
[ipp-mod] that auto-sense MAY happen at either submit-time and/or
processing-time. In IIG explain that with compression, it is much
harder to auto-sense at submit time, since some compression methods
require processing the entire file.
11) ISSUE: Return what attributes with 'client-error-document-format-
not-supported'?
Suggested clarification (see also Issues 18 and 23): AGREED - MUST
return "document-format=xxx" in Unsupported Attribute Group even though
a special error status code, to make this error consistent with the
rules for unsupported attributes. Propose to DL, since not many
implementations did return the attribute.
12) ISSUE: length fields for the "UNSUPPORTED" tag
Suggested clarification (same as Issue 15): AGREED - clarify [ipp-mod]
to agree with [ipp-pro] that the length MUST be 0 and no value is
returned.
13) ISSUE: What job-state value should be returned in the Create-Job
response?
Suggested clarification: AGREED - can be 'pending-held', 'pending', or
'processing' (the latter for a non-spooling printer that doesn't
implement the 'pending' job state). Add 'job-data-insufficient' job-
state-reason for use in any of the three job states if actual marking
cannot begin until sufficient data has arrived.
14) ISSUE: Job-state for a forwarding server?
Suggested clarified and addition: AGREED - 'completed' is ok, but also
add 'queued-in-device' job state reason which MUST be supported. Bring
out on the DL for confirmation.
15) ISSUE: .unknown. and .unsupported. Out of band values.
Suggested clarification (same clarification as Issue 12): AGREED -
clarify [ipp-mod] to agree with [ipp-pro] that the length MUST be 0 and
no value is returned.
16) ISSUE: Get-Printer-Attributes Polling
Suggested clarification in the IIG: AGREED - Add to IIG that clients
SHOULD request only the attributes needed, rather than always asking for
all.
17) ISSUE: Client display of absolute time for job attributes?
Possible alternatives: OPEN - carry on discussion on DL to add three
new date/time jo attributes: ISSUE: Make them REQUIRED for IPP/1.1?
Any network printer can get time from NTP Time server.
18) ISSUE: Return all errors on Print-Job fidelity=true
Suggested clarification (same clarification as Issue 27): AGREED - all
unsupported attributes MUST be returned, not just the first, to agree
with June IPP/1.0 draft. (In the November draft this requirement was
moved to the IIG, which seems to have been a mistake).
19) ISSUE: User Performing the Send-Document Operation
Suggested clarification: AGREED - same user MUST do Send-Document as
did Create-Job.
20) ISSUE: Non-spooling printers accept/reject additional jobs
Suggested clarification (same as Issues 4 and 5): AGREED that IPP
object MAY accept implementation defined number of subsequent create
operations, including NONE. RAISE on DL to verify AGREEMENT.
21) ISSUE: Does 'none' "uri-security-supported" mean Basic/Digest?
Suggested clarification: AGREED - "uri-security-supported" does not
cover this kind of HTTP authentication. Also add a note to refer to
[ipp-pro] for authentication since some authentication is transport-
dependent.
22) ISSUE: Status code on variable-length attributes that are 'too
short'
Suggested clarification in the IIG: AGREED - clarify in IIG that no
special processing is needed if a client supplied a keyword with 0
length, since the keyword will not match any "xxx-supported" keywords.
23) ISSUE: There seems to be some misunderstanding about the
unsupported-attributes group.
Suggested clarification (related to Issues 11 and 18): AGREED - clarify
that the IPP object MUST return only requested attributes that are
unsupported.
24) ISSUE What status does Get-Jobs return when no jobs?
Suggested clarification: AGREED - MUST return 'successful-ok'.
25) ISSUE - MAY an IPP object return more Operation attributes?
Suggested clarification: AGREED - client MUST process or ignore
additional operation attributes returned.
26) ISSUE: MAY an IPP object return additional groups?
Suggested clarification: AGREED - client MUST process or ignore
additional attribute groups returned.
27) ISSUE: Return first or all unsupported attributes in Unsupported
Group?
Suggested clarification (same clarification as Issue 18): AGREED - all
unsupported attributes MUST be returned, not just the first, to agree
with June IPP/1.0 draft. (In the November draft this requirement was
moved to the IIG, which seems to have been a mistake).
28) ISSUE: What if compression is supplied but not supported?
Possible Alternatives (related to Issues 3 and 6): OPEN - propose to
the DL that "compression" is REQUIRED for IPP/1.1 (with at least the
'none' value), even though it is OPTIONAL for IPP/1.0.
29) ISSUE: Should "queued-job-count" be REQUIRED?
Suggested change: OPEN - propose to the DL that "queued-job-count" be
REQUIRED for IPP/1.1, even though it is a SHOULD for IPP/1.0.
30) ISSUE: Should "job-state-reasons" and "printer-state-reasons" be
MUST in IPP/1.1?
Suggested change: Considering that we tend to put more and more
information into the currently OPTIONAL 'job-state-reason' and 'printer-
state-reason' attributes, should we make them a MUST for the IPP/1.1
version? Raise on DL to see if there is agreement. (Discussion in
990324 phone conference).