Subject: New Internet-Draft Request

From: "Scott A. Isaacson" <[email-masked]>
Date: Fri, 22 Nov 1996 18:13:59 -0700

A working group is in the process of being chartered in
the applications area to develop a protocol for Internet
printing.  We have a BOF scheduled for Dec 12th in San Jose.

We have a document in the form of an Internet-Draft that we would like
to make available for that BOF.  The document is a specification for the
Internet Printing Protocol (IPP).

The title of that document is:

"Internet Printing Protocol - IPP/1.0"

The abstract is:

--------------
This Internet-Draft specifies an Internet Printing Protocol (IPP). This
protocol is heavily influence by  the semantic operations and attributes
defined in ISO/IEC 10175 Document Printing Application (DPA) parts 1 and
3.  It also incorporates some of the implementation and interoperability
lessons learned from other printing related standards such as POSIX
System Administration - Part 4 (POSIX 1378.4) and X/Open A Printing
System Interoperability Specification(PSIS).IPP is defined as a set of
abstract data types and operations. The operations are implemented
using a simple request and response mechanism built on top of HTTP. 
The abstract data types are encoded as simple ASCII text strings.The IPP
protocol covers only end user operations on basic print service objects.
Authentication is realized by mechanisms outside the scope of the
protocol, but the protocol does introduce some access control
functionality so that only authorized end users are allowed to submit print
jobs to printers whose implementation and site policy support access
control.  Also, the Cancel Job operation requires some authentication so
that jobs can only be canceled by  the end user who submitted the job. 
Extended monitoring and management is possible through other protocols
such as the SNMP Printer MIB.  In the areas where there are no existing
standards, some proposed and emerging standards are being worked
(management, security, etc.).  As these services become more stable,
this document (and hence the protocol) can be updated to reflect the
integration and relationships with these other standards.
--------------

I would like a document name assigned so that we can make 
this draft available ASAP.  

The authors are:

Scott A. Isaacson
Novell, Inc.
122 E 1700 S
Provo, UT   84606

Phone: 801-861-7366
Fax:   801-861-4025
EMail: [email-masked]

   Tom Hastings
Xerox Corporation
701 S. Aviation Blvd.
El Segundo, CA   90245

Phone: 310-333-6413
Fax:   310-333-5514
EMail: [email-masked]

	Robert Herriot
	Sun Microsystems Inc.
	2550 Garcia Ave., MPK-17
	Mountain View, CA 94043

	Phone: 415-786-8995
	Fax:	 415-786-7077
	Email: [email-masked]

	Roger deBry
	HUC/003G
	IBM Corporation
	P.O. Box 1900
	Boulder, CO 80301-9191

	Phone: (303) 924-4080
	Fax: (303) 924-9889
	Email: [email-masked]

Scott A. Isaacson is the editor.

Your prompt response is requested.

Thanks!

Scott

************************************************************
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: [email-masked]
W: http://www.novell.com
************************************************************

---

From: [email-masked] (Robert Herriot)
Date: Fri, 22 Nov 1996 19:42:24 -0800

Great job Scott in pulling this all together. My comments are below
from reading the changes. I may have more comments after I read the
text that didn't have revision marks.

Lines number are with respect to ipp93rev.doc document in MS Word with Laser
Writer Plus Printer. I hope they align with your numbers.  

By the way mail servers will be down Sunday due to a planned power
outage. So if my mail bounces, please try again on Monday.

line 468:  I am not sure that I agree with your change to "zero or more Job
Template objects" associated with a Printer. I think that we should leave 
it as an issue as to whether a Printer accessible via the print operation 
can have no job template associated with it.  

line 527: Is 380 now a registered port with IANA for HTTP printing?

line 544: As someone suggested in email. The name service might have objective
values and the name search software might take either objective or subjective
values from a client.  Somewhere else there could be a mapping.  
The main point that I think should be added here that there are a wide 
range of possible solutions.  It may not be necessary for all name service 
entries to have both subjective and objective entries.

line 593: In addition to four color (CMYK), there is 3 color (CMY).  The 
names CMYK and CMY should probably be in the name in case some "printer" uses 
RGB for color.

line 616: Change "Is is" to "It is", and change "recommended" to "required";
Otherwise, the syntax is very useful.

line 692: Delete "binding" from "long-binding-edge"

lines 750 and 757 should be indented further.

line 793: There is no mention of what the HTTP method should be for the four
operations presented in this section. We have talked about POST for Print and
CancelJob and GET for GetAttributes and GetJobs.

lines 850: Although I think most of this HTTP structure is right, I think
that we need to discuss it further. In particular I wonder whether
documents should be formal HTTP Entity-Bodies and have Content-types,
such as Application/PostScript or text/plain. We just need to recognize
that this area needs further discussion even whether it is flagged as an
issue in the document.

line 878 and 887: the syntax can be shorter as:
        Attribute Value = #Value

line 904: does the last item of the table imply that URL is an attribute
  and not a document-content.

line 918: There should be some mention about authorization required for 
   Cancel Job.

line 934: "Ignored by the Server" is this in the context of null attributes.
  If so, what is there to ignore. When the client supplies no attributes,
  what does the server return?

line 941: Isn't the Printer or Job URL implicit in the HTTP operation?	

line 951: we may want a few more default attributes to be return, such
   as the job-identifer and the position in the queue if not implicit.

line 957: the semantics in the above paragraph suggest that the client
   can specify attributes, but the table entry does have this parameter.

line 963: same as line 951. Job identifier seem especially important because
  this operation may be the only way a user can figure out the name to
  use to cancel a job.

line 1225: correct the definition of "#" syntax to be that of rfc 822
  per email discussions, i.e. zero or more item separated by a ",".

line 1370: missing header and header runs into paragraph. There 
   should be an issue as to whether this should be a boolean value.

line 1469: Tom raised the issue of deleting retention time and then
  reversed himself after I and Sato objected. This may not be an issue
  any longer.

line 1541: I am not sure than these words on embellish are what we
   all agree to. Perhaps, we should leave some alternatives as
   issues. At the end of the discussion this afternoon, Tom and I
   agreed that 'none' mean no number-up and '1' might be 1 page/impression
   with default number-up embellishment.  But let's leave this as
   an issue.

lines 1555, 1556: remove "binding" from "binding-edge".

---

From: [email-masked] (JK Martin)
Date: Fri, 22 Nov 96 23:36 EST

> line 527: Is 380 now a registered port with IANA for HTTP printing?

As I mentioned during the last IPP con-call, one can not simply declare
the assignment of a "privileged" port number (ie, a number between 1-1023).
The assignment of these port numbers is within the exclusive domain of IANA,
and we'll have to register for such a port.

For the sake of global sanity, IANA also registers ports above 1023, as
I recall.  So, it's probably best we eventually coordinate through them
if we are dealing on the Internet.

As far as the draft goes, let's just put a "XXX" in place of "380" and
note the eventual registration through IANA in the text.

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03015-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: [email-masked] (Robert Herriot)
Date: Fri, 22 Nov 1996 23:07:20 -0800

I have another minor typo in Ipp93rev.doc:

line 828: Content-Header should be Document-Content-Header as is the name of section 5.3.3.

line 829: Maybe I missed it, but I cannot find where you defined "content". 

    Also, as I mentioned in the previous email, it isn't clear where a document-URL goes, in
    the content or elsewhere.

Bob Herriot

---

From: [email-masked] (Robert Herriot)
Date: Fri, 22 Nov 1996 23:54:26 -0800

More comments on Ipp93rev.doc

line 1347: the syntax for job state reasons should be (#type2Enum) because there can be 0 reasons.

line 2252: "Print-Job-Object Header". Am I correct in assuming that this line is not
   really part of the protocol, but rather stands for lines of Content-type and Content-length?
   If so, then so them instead or make it clear that they are meta-lines.  This problem exists 
   in all of the examples in this appendix.

line 2260: does this line represent the document data?