IPP> Revised versions of IPP/1.1 Model & Semantics and IPP/1. 1 Encodin g and Transport I-Ds

IPP> Revised versions of IPP/1.1 Model & Semantics and IPP/1. 1 Encodin g and Transport I-Ds

Zehler, Peter Peter.Zehler at usa.xerox.com
Wed Mar 1 06:54:16 EST 2000


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 at 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 at cp10.es.xerox.com]
Sent: Tuesday, February 29, 2000 1:45 PM
To: IESG at ietf.org
Cc: iana at 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 at cp10.es.xerox.com 



More information about the Ipp mailing list