Carl-Uno,
At the New Orleans meeting we addressed a number of implementation issues.
Two of the resolution for those issue's required updates to the text of the
model document. Did the updates included the two updates? The resolutions
follow below.
Pete
____________________________
Here is what the RFC has to say about the "Resume-Printer Operation",
"This operation allows a client to resume the Printer object scheduling jobs
on all its devices. The Printer object MUST remove the 'paused' and
'moving-to-paused' values from the Printer object's "printer-state-reasons"
attribute, if present. If there are no other reasons to keep a device
paused (such as media-jam), the IPP Printer transitions itself to the
'processing' or 'idle' states, depending on whether there are jobs to be
processed or not, respectively, and the device(s) resume processing jobs."
What this means is, according to the RFC description, the "Resume-printer"
operation must change the 'printer-state-reason' to some thing other than
'Paused' and 'moving-to-paused' and it may or may not result in the Printer
transitioning itself to the 'processing' or 'idle' states, depending on the
actual physical device status (and offcourse depending on whether any jobs
are queued-up for the printer or not !)
RESOLUTION 1a)
Edit the IPP/1.1 Model and Semantics document containing the above content
to
"3.2.8 Resume-Printer Operation
This operation allows a client to resume the Printer object scheduling
jobs on all its devices. The Printer object MUST remove the 'paused'
and 'moving-to-paused' values from the Printer object's "printer-state-
reasons" attribute, if present. If there are no other reasons to keep a
device paused (such as media-jam), the IPP Printer is free to transition
itself to
the 'processing' or 'idle' states, depending on whether there are jobs
to be processed or not, respectively, and the device(s) resume
processing jobs."
____________________________
Q4) Assume a client has performed a Print-URI operation with a reference to
a large document .The request is processed checking for the uri-scheme and
the accessibility of the document, and the client is sent a response with a
valid job-id. While the IPP server is downloading the document mid way ,the
client does a get-job-attributes. We would return the job-state as
pending-held , but what the job-state-reasons say. There is a
job-state-reason 'job-incoming' , but is limited to create-job.
RESOLUTION 4) (Note: checking accessibility is optional)
Use 'job-incoming'. I assume your implementation requires that the entire
job stream be transferred to your printer prior to processing. If you could
begin before transfer is complete then the 'job-state' would be 'processing'
and the 'job-state-reasons' could also include 'job-interpreting',
'job-transforming' and/or 'job-printing'. Assuming your implementation can
not process until the entire document data has been retrieved I agree with
your 'job-state'.
Update IPP/1.1 Model and Semantics: 4.3.8 job-state-reasons (1setOf type2
keyword)
Change
"'job-incoming': The Create-Job operation has been accepted by the
Printer, but the Printer is expecting additional Send-Document
and/or Send-URI operations and/or is accessing/accepting document
data."
To
"'job-incoming': A job creation operation has been accepted by the
Printer, but the Printer is expecting additional Send-Document
and/or Send-URI operations and/or is accessing/accepting/retrieving
document
data.
____________________________
Peter Zehler
XEROX
Xerox Architecture Center
Email: Peter.Zehler@usa.xerox.com
Voice: (716) 265-8755
FAX: (716) 265-8792
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 139-05A
Webster NY, 14580-9701
-----Original Message-----
From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com]
Sent: Tuesday, February 29, 2000 1:45 PM
To: IESG@ietf.org
Cc: iana@iana.org; "Faltstrom, Patrik"; Freed, Ned; Moore, Keith;
IETF-IPP
Subject: IPP> Revised versions of IPP/1.1 Model & Semantics and IPP/1.1
Encodin g and Transport I-Ds
Gentlemen,
I was alerted early this year that IANA had questioned why there wasn't an
IANA section in the IPP/1.1 Encoding & Transport draft. The original reason
was that all the relevant text on IANA registrations was defined in the
IPP/1.1 Model & Semantics draft. However, we decided to add an IANA section
in the IPP/1.1 Encoding & Transport draft and also decided to improve a bit
on the IANA section in the IPP/1.1 Model & Semantics document to make sure
that we had a complete and watertight description. In essence, the rules now
state that there are certain code ranges reserved for future standards track
extensions. In some cases there are also code ranges for vendor extensions.
Both kinds need to be registered by IANA. For completeness, we also added a
new section on I18N in the IPP/1.1 Encoding & Transport draft, which
basically references back to the IPP/1.1 Model & Semantics draft, where
these details are described.
While updating the IPP/1.1 Model & Semantics draft (sections 6 and 11), we
also folded in the revised version of Appendix C, which was earlier sent to
the IESG as a separate draft (draft-ietf-ipp-media-engineering-00.txt)
asking it to replace the old Appendix C before publishing as RFC. A few
minor editorial fixes were also made, but absolutely no changes were made to
the technical content, which would cause a new technical review of the
drafts. It is our hope that these revisions will help IESG and IANA in the
continued review process.
Here are the details:
Replacing <draft-ietf-ipp-protocol-v11-03.txt> is:
Title : Internet Printing Protocol/1.1: Encoding and
Transport
Author(s) : R. Herriot, S. Butler, P. Moore, R. Turner, J.
Wenn
Filename : draft-ietf-ipp-protocol-v11-04.txt
Pages : 42
Date : 28-Feb-00
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipp-protocol-v11-04.txt
Replacing <draft-ietf-ipp-model-v11-04.txt> and
<draft-ietf-ipp-media-engineering-00.txt> is:
Title : Internet Printing Protocol/1.1: Model and
Semantics
Author(s) : R. de Bry, T. Hastings, R. Herriot,
S. Isaacson, P. Powell
Filename : draft-ietf-ipp-model-v11-05.txt
Pages : 184
Date : 28-Feb-00
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipp-model-v11-05.txt
Hope to hear some news about these drafts soon considering that a number of
implementations are already under way.
Regards,
Carl-Uno Manros
Chair of IETF IPP WG
Principal Engineer - Xerox Architecture Center - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros@cp10.es.xerox.com
This archive was generated by hypermail 2b29 : Wed Mar 01 2000 - 07:00:29 EST