This mail message summarizes the changes from the IPP/1.0 Model and
Semantics, November 1998 and the IPP/1.0 Encoding and Transport, November
1998. (see yesterday's document posting message attached below).
The plan is to start IPP WG Last Call on these documents now and ending with
the Interoperability test March 9-12. The IETF meeting is the following
week so we hope to get IETF feedback as well then.
Model and Semantics
-------------------------------
But first here are the changes to the IPP/1.1 Model and Semantics agreed to
this week on the mailing list and the telecon, Wed 2/17/99, from the IPP/1.1
January 24 version. So this mail message serves as minutes of the telecon
as well. As always, comments on these agreements are solicited from the
mailing list.
1. Add 'image/tiff' and 'application/pdf' as additional example values to
the 'mimeMediaType' attribute syntax (section 4.1.9) for use in the
"document-format", "document-format-default", and
"document-format-supported" attributes. Both values with references only to
the IANA Registry.
2. Delete the 'text/plain, charset=iso-10646-ucs-2': A plain text document
in ISO 10646 represented in two octets (UCS-2) [ISO10646-1]. It is wrong.
Have to use the new wide-text for UCS-2 which still isn't approved.
3. Keep the Encoding and Transport title the same. Mention the URL Scheme
and compatibility with IPP/1.0 in the Abstract and the description of each
document on the second page.
4. Clarify that a Printer object MUST reject a create operation if the
client supplies a "compression" attribute and the Printer object doesn't
even support this OPTIONAL Operation attribute. Otherwise, it will not be
able to interpret the data stream correctly. (We should have made the
attribute REQUIRED with at least the 'none' value REQUIRED, but we agreed
not to change the conformance from IPP/1.0).
5. For Hold-Job, if the client supplies the OPTIONAL "hold-job-until"
Operation attribute and the Printer doesn't support that attribute or the
supplied value, ignore the attribute, accept the request and hold the job
(indefinitely until Release-Job), returning the
'successful-ok-ignored-attributes-or-values' status code, rather than
rejecting the request, since the results are not too different from what the
user requested.
6. For Restart-Job, if the client supplies the OPTIONAL "hold-job-until"
Operation attribute and the Printer doesn't support that attribute or the
supplied value, ignore the attribute, accept the request and restart the job
returning the 'successful-ok-ignored-attributes-or-values' status code,
rather than rejecting the request, since the results are not too different
from what the user requested.
7. Eliminate OPTION 1 in the Restart-Job operation so that Restart-Job is
like Hold-Job in that neither operation can be done when the job is in the
'processing' or 'processing-stopped' states. Add new operations for that
functionality if and when needed.
Need to update the IPP/1.0 Set 1 Extensions with agreements 5, 6, and 7,
since the agreement is that extensions to IPP/1.0 and those extensions added
to IPP/1.1 are the same.
8. Remove the mention of 40 bit TLS ciphers that meeting government export
restrictions, since the government just raised them to 56 bits in September.
Point to the TLS RFC for such a discussion.
9. Use the keyword value 'tls', not 'tls1', since future versions are
likely to be upwards compatible. The usual practice is to include the
version number only when not upwards compatible, such as SSL3 with SSL2.
Here is the summary of changes from the November IPP/1.0 to the current
IPP/1.1 Model and Semantics document that is in the end of the document:
18. APPENDIX F: Differences between the IPP/1.0 and IPP/1.1 "Model and
Semantics" Specifications
The following IPP/1.0 [IPP-MOD1.0] extensions and clarifications have
been incorporated into IPP/1.1:
1. Section 3.1.7 - clarified that only the version number parameter
will be carried forward into future major or minor versions of the
protocol.
2. Section 3.2.1.1 - clarified that the Printer object rejects a
Print-Job request if it does not support the "compression"
operation attribute and a client supplies it.
3. Sections 3.2.7, 3.2.8, and 3.2.9 - added the OPTIONAL Pause-
Printer, Resume-Printer, and Purge-Jobs operations
4. Sections 3.3.5, 3.3.6, and 3.3.7 - added the OPTIONAL Hold-Job,
Release-Job, and Restart-Job operations.
5. Section 4.1.9 - added 'image-tiff' and 'application/pdf' values.
6. Section 4.2.2 - added the 'indefinite' keyword value to the "job-
hold-until" attribute for use with the create operations and Hold-
Job and Restart-Job operations.
7. Section 4.2.6 - added more enum values to the "finishings" Job
Template attribute.
8. Section 4.3.7.1 - added the Partitioning of Job States section.
9. Section 4.3.8 - added the 'job-restartable' keyword value to the
"job-state-reasons" attribute for use with the Restart-Job
operation.
10. Section 4.4.2 - added the 'tls' keyword value to the "uri-
security-supported" attribute.
11. Section 4.4.11 - added the 'moving-to-paused' keyword value to
the "printer-state-reasons" attribute for use with the Pause-Job
operation.
12. Section 4.4.11 - replaced the duplicate 'marker-supply-low'
keyword with the missing 'toner-empty' keyword for the "printer-
state-reasons" attribute.
13. Section 4.4.13 - added the enum values to the "operations-
supported" attribute for the new operations. Clarified that the
values of this attribute are encoded as any enum, namely 32-bit
values.
14. Sections 4.4.33 and 4.4.34 - added the OPTIONAL "pages-per-
minute" and "pages-per-minute-color" Printer Description
attributes.
15. Section 8.5 - added the security discussion around the new
operator operations.
16. Section 17 - added the OPTIONAL "pages-per-minute" and "pages-
per-minute-color" Printer attributes to the Directory schema.
The following changes were made to IPP/1.0 [IPP-MOD1.0] to create this
IPP/1.1 document:
1. Section 3.1.7, 5.2.4, and 14.1.5.4 - IPP objects MUST support both
version 1.0 and 1.1. Clients MUST support version 1.1 and MAY
support version 1.0.
2. Section 4.1.9 - deleted 'text/plain; charset=iso-10646-ucs-2',
since binary is not legal with the 'text' type.
3. Section 5.4, 8.2, and 8.7 - changed the IPP object security
requirements from OPTIONAL non-standards track SSL3 to RECOMMENDED
standards track TLS. Changed the client security requirements from
RECOMMENDED non-standards track SSL3 to RECOMMENDED standards track
TLS
Encoding and Transport
--------------------------------
But first here are the changes to the IPP/1.1 Encoding and Transport agreed
to this week on the mailing list and the telecon, Wed 2/17/99, from the
IPP/1.1 previous version. So this mail message serves as minutes of the
telecon as well. As always, comments on these agreements are solicited from
the mailing list.
1. Require IPP servers to support chunking of POST method requests, in
spite of the some what less than full compliance of HTTP/1.1 implementations
to date. The IPP server implementations will have to improve or find
alternate HTTP/1.1 servers, or request their HTTP/1.1 server vendors to
comply with HTTP/1.1 requirements to chunk.
2. Require IPP client to support chunked responses.
3. Clarified which scheme (http, https, or ipp) is returned for a job as a
function of the security and scheme that was used when the job was created
and the security and scheme used in the target (printer or job) of the
Get-Job-Attributes or Get-Jobs operation or the job is not returned at all
(security violation). There are no implementation choices.
And the changes from the November 1998 IPP/1.0 Transport and Encoding
document to the IPP/1.1 version are:
14. Appendix E: Changes from IPP /1.0
IPP/1.1 is identical to IPP/1.0 with the follow changes:
1.Attributes values that identify a printer or job object use a new
'ipp' scheme. The 'http' and 'https' schemes are supported only for
backward compatibility.
2.TLS provides security. SSL3 is supported only for backward
compatibility.
Tom Hastings
(310) 333-6413
>-----Original Message-----
>From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
>Sent: Thursday, February 18, 1999 20:45
>To: ipp
>Cc: Keith Moore <
>Subject: IPP> MOD & PRO - IPP/1.1 Internet-Drafts posted and sent to
>IETF
>>>Carl-Uno has sent the Internet-Drafts for IPP/1.1 Model and
>Semantics, and
>IPP/1.1 Encoding and Transport to the IETF.
>>I have posted the usual files on the PWG server:
>ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11-990217.doc>ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11-990217.pdf>ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11-990217-rev.doc>ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11-990217-rev.pdf>ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11-990217.txt>ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/draft-ietf-ipp-model-v11-00.txt>ftp://ftp.pwg.org/pub/pwg/ipp/Internet-Drafts/draft-ietf-ipp-model-v11-00.txt
ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-990217.docftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-990217.pdfftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-990217-rev.docftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-990217-rev.pdfftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-990217.txtftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/draft-ietf-ipp-protocol-v11-00.txtftp://ftp.pwg.org/pub/pwg/ipp/Internet-Drafts/draft-ietf-ipp-protocol-v11-00
.txt
The -rev files show all the changes from the IPP/1.0 November
specifications.
Tom Hastings
(310) 333-6413