From ipp-archive Sat Feb 1 02:41:18 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA10972 for ipp-outgoing; Sat, 1 Feb 1997 02:37:02 -0500 (EST) Message-ID: <32F2EB23.4361@underscore.com> Date: Sat, 01 Feb 1997 02:05:07 -0500 From: JK Martin Organization: Underscore, Inc. X-Mailer: Mozilla 3.0 (Win95; U) MIME-Version: 1.0 To: "Harry Lewis " CC: PWG Internet Printing Project Subject: Re: IPP> Re: REQ - Last minute scenario comments References: <199701312025.PAA08024@lists.underscore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Harry, I agree entirely with your arguments countering Larry Masinter's original message. Larry had some excellent ideas, but your statements make the issue (and the attendant problems) much clearer, IMHO. Your final statment, though, compels me to respond with a comment, particulary since we have tossed this subject around quite a bit between you and I over the last year or two: > Last year, before IPP was even a gleam in the PWG's eye, I proposed > an encapsulation scheme - at that point - to associate information > that would be needed for the Job MIB along with the Job during > submission. The idea got a very cool reception. I thought, perhaps > due to the fact that members who manage PDLs would rather extend > their own. Perhaps my proposal appeared too much like an extension > of "my" PDL (IPDS), or perhaps we just weren't ready for consensus on > the need for a STANDARD means of associating Job information with the > job? My argument then is the same as it is now: Print Data is Print Data, and Job Control is Job Control (protocol and parameters), and the two should be separate in the requisite protocol transactions. Munging the two together just causes all kinds of parsing problems that usually end up impacting future extensions. A Client should be able to say "Here's some print data, please print it this way for such-and-such a person", and the Server should operate on that data, often in a relatively opaque manner (assuming the "Server" is architecturally separate from the RIP or similar imager). Sure, both PostScript and PCL embed all kinds of stuff in the print data stream...but I believe that's because there has never been a STANDARD PRINTING PROTOCOL in the world that everyone could play to. Sheesh, that's all I really want. A standard printing protocol. It just doesn't seem like that's too much to strive for, given the large body of experience in the Tower of Babel that has existed up to now. Ah, I feel better now. Thanks for letting me get that off my chest. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03015-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-archive Sat Feb 1 14:21:23 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA12046 for ipp-outgoing; Sat, 1 Feb 1997 14:19:13 -0500 (EST) To: harryl@vnet.ibm.com CC: ipp@pwg.org In-reply-to: <199701312025.PAA08024@lists.underscore.com> (harryl@vnet.ibm.com) Subject: Re: IPP> Re: REQ - Last minute scenario comments From: Larry Masinter Message-Id: <97Feb1.111943pdt."135"@palimpsest.parc.xerox.com> Date: Sat, 1 Feb 1997 10:19:43 PST Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I think I might have left out the context of my argument. I'm not arguing for always embedding job control information into PDLs. I'm arguing that the STANDARD PROTOCOL should have a clear definition of what is job control and what is print data. I was arguing AGAINST the situtation where a gateway would like to say "don't send this information in the job control, only send it in the print data, because I'm a gateway to a device that only knows about print data". I see how my analysis taken outside of that context might have been seen as an argument for putting EVERYTHING inside the print data, but that's not what I meant at all. Larry From ipp-archive Mon Feb 3 13:51:54 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA16154 for ipp-outgoing; Mon, 3 Feb 1997 13:42:32 -0500 (EST) Message-ID: <32F6311F.41C67EA6@sharplabs.com> Date: Mon, 03 Feb 1997 10:40:31 -0800 From: Randy Turner Organization: Sharp Labs of America X-Mailer: Mozilla 3.01 (X11; I; SunOS 4.1.4 sun4m) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> Re: REQ - Last minute scenario comments References: <199701312025.PAA08024@lists.underscore.com> <32F2EB23.4361@underscore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO JK Martin wrote: > > Harry, > > I agree entirely with your arguments countering Larry Masinter's > original message. Larry had some excellent ideas, but your statements > make the issue (and the attendant problems) much clearer, IMHO. > > Your final statment, though, compels me to respond with a comment, > particulary since we have tossed this subject around quite a bit > between you and I over the last year or two: > > > Last year, before IPP was even a gleam in the PWG's eye, I proposed > > an encapsulation scheme - at that point - to associate information > > that would be needed for the Job MIB along with the Job during > > submission. The idea got a very cool reception. I thought, perhaps > > due to the fact that members who manage PDLs would rather extend > > their own. Perhaps my proposal appeared too much like an extension > > of "my" PDL (IPDS), or perhaps we just weren't ready for consensus on > > the need for a STANDARD means of associating Job information with the > > job? I think some of the solutions we are coming up with do munge the world of job control and PDL. This is because alot of the PDLs we deal with (lets use Postscript as an example) have job control built into them as well. I remember when I was reading the DPA specifications, the standard states that the user can use the DPA job submission attributes to override what is specified in the PDL. I don't know how many people on the list have actually spent time inside the architecture of a postscript interpreter, but the above DPA requirement forces some major architectural changes in most PDL implementations I am aware of. There are some aspects of the job that are PDL-independent, like do I want this on standard paper stock or transparency. But once the final form PDL is generated (either directly from an application, or through a device-specific print driver) I would hope that we would not be attempting to override the PDL with our IPP-specific job control. Some parameters, like the paper/ transparency decision would be ok, but I think we should stay away from any job control that attempts to change the imaging characteristics (aspect ratio, fonts, media size, etc.) that might conflict with parameters that were used to generate the PDL. I guess I'm basically a purist and agree with Jay that we need to keep job control and PDL separate; with job control specifying more "macro" types of job characteristics like "Does this printer support Postscript?" or "I would like this printed on transparency", etc. Also, its very hard to do directory lookups on anything more job-specific than this without doing parsing of the PDL to determine the actual job requirements, so I think the directory service attributes need to reflect the parameters and printer characteristics that are easy to obtain, similar to the "macro" type of job characteristics I have described. Since we agreed in an earlier teleconference to utilize existing device specific print drivers and just insert IPP as a "redirector", we have basically agreed to be PDL-independent, so we can't parse the job stream, nor do we have a mechanism for transmitting print job metadata from the device-specific driver through some other "channel". Boy, you're right Jay, it does feel better to unload all this baggage. Randy > > My argument then is the same as it is now: Print Data is Print Data, > and Job Control is Job Control (protocol and parameters), and the > two should be separate in the requisite protocol transactions. > > Munging the two together just causes all kinds of parsing problems > that usually end up impacting future extensions. A Client should be > able to say "Here's some print data, please print it this way for > such-and-such a person", and the Server should operate on that data, > often in a relatively opaque manner (assuming the "Server" is > architecturally separate from the RIP or similar imager). > > Sure, both PostScript and PCL embed all kinds of stuff in the print > data stream...but I believe that's because there has never been a > STANDARD PRINTING PROTOCOL in the world that everyone could play to. > > Sheesh, that's all I really want. A standard printing protocol. > It just doesn't seem like that's too much to strive for, given the > large body of experience in the Tower of Babel that has existed up > to now. > > Ah, I feel better now. Thanks for letting me get that off my chest. > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03015-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- -- Randy Turner From ipp-archive Mon Feb 3 18:06:57 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA17140 for ipp-outgoing; Mon, 3 Feb 1997 18:06:16 -0500 (EST) From: Harald.T.Alvestrand@uninett.no X-Authentication-Warning: tyholt.uninett.no: Host munken.uninett.no [129.241.131.10] didn't use HELO protocol X-Mailer: exmh version 1.6.7 5/3/96 To: Raymond Lutz cc: ipp@pwg.org Subject: Re: IPP> I-D ACTION:draft-lutz-print-types-00.txt In-reply-to: Your message of "Mon, 27 Jan 1997 15:17:31 PST." <3.0.32.19970127110008.0070d904@crash.cts.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Feb 1997 00:06:54 +0100 Message-ID: <10321.855011214@munken.uninett.no> Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Late response: you should probably reformat this document to deal with the new registry routines in RFC 2048 - MIME registration procedures. The common segmentation done in that document is application/vnd.hp.pcl - but you might want to think more about that; there is no strict rule. Better be careful when using existing types, too; for instance, the line langCCITT 26 image/g3fax may get you in deep trouble, since the encapsulation for fax is specified in a certain way in the defining document for image/g3fax, and may be quite different elsewhere. The registration for the other non-vnd types should probably be fleshed out with enough info that people can tell what it's about; this concerns text/iso6429 (this is just a control character set, I think!) application/iso10180 (application/vnd.iso.spdl? :-) application/dec-ln03 (did you just forget vnd.?) Security sections are also Real Fun Stuff; if vnd.ibm-modca is the one I vaguely remember (IBM Modifiable content for Document Content Architecture), it was quite capable of doing really strange stuff, including grabbing pieces out of its environment and mangling them before printing (even though I *think* it wasn't supposed to execute them) Have fun! Harald A From ipp-archive Mon Feb 3 19:56:59 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA17870 for ipp-outgoing; Mon, 3 Feb 1997 19:55:54 -0500 (EST) Date: Mon, 3 Feb 1997 16:54:35 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199702040054.QAA03548@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP> MOD - Directions for IPP Model Meeting on Wed afternoon 2/5 at Sun X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO The following people have RSVPed for the meeting on Wednesday at Sun. Harry Lewis Lee Farrell Carl-Uno Manros Larry Masinter Don Wright Tom Hastings Peter_Zehler Keith Carter Robert Herriot Maybe: Jim Walker Scott Issaacson (perhaps by telephone) The admin still has not gotten a room for the meeting, but she assured me it would be on the Menlo Park campus. I have put a PostScript map at ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/Sunmap.ps It shows the Sun's location within the SF Bay Area and it shows the individual buildings on the campus. The simple directions are to take 101 (South from San Francisco Airport or North form San Jose Airport) about 15 miles (from either airport) to the exit marked "Willow Rd East, Hwy 84, Fremont" It may also say Dumbarton Bridge. If you continue straight (East) on Willow road you will end up in the Sun parking lot. When I know the location of the conference room, I will send out more email. Bob Herriot From ipp-archive Tue Feb 4 01:27:03 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA18453 for ipp-outgoing; Tue, 4 Feb 1997 01:24:38 -0500 (EST) Date: Mon, 3 Feb 1997 22:23:31 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199702040623.WAA03885@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP> MOD - Two documents downloaded X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have just finished downloading two new documents to the usual place. They are both somewhat rough, but I wanted those of you who are coming to the Wednesday meeting at Sun to have a full day to read it. ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD The documents are: attrtabl-1.1.doc attrtabl-1.1.ps ipp-model-1.1-rev.doc ipp-model-1.1-rev.ps The attrtable is a short document showing all the attributes organized into a table. It helped me group things. It is close to what is in the document, but not quite. The ipp-model-1.1-rev.doc is the update to ipp-model-1.0-rev.doc. It has the proposed changes to unify the treatment of many attributes in job and printer objects. We need to discuss the changes to this document on Wednesday and deal with other loose ends, such as fan-in/fan-out ramifications. Bob Herriot From ipp-archive Tue Feb 4 01:27:03 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA18401 for ipp-outgoing; Tue, 4 Feb 1997 01:23:32 -0500 (EST) Date: Mon, 3 Feb 1997 22:22:27 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199702040622.WAA03883@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP> MOD - meeting location at Sun X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I now have the location of the Sun meeting on Wednesday. MPK17, Nob Hill, #3351 Wednesday, February 5 1:00 pm to 6:00 pm telphone in the room is 415-786-5697 Please go to the lobby of building 17 in Menlo Park (MPK17) and have the receptionist call 786-5697 (the conference room) or my office (786-8995) if no one is in the lobby to take you up. I have put a PostScript map at ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/Sunmap.ps It shows the Sun's location within the SF Bay Area and it shows the individual buildings on the campus. The simple directions are to take 101 (South from San Francisco Airport or North form San Jose Airport) about 15 miles (from either airport) to the exit marked "Willow Rd East, Hwy 84, Fremont" It may also say Dumbarton Bridge. If you continue straight (East) on Willow road you will end up in the Sun parking lot. When I know the location of the conference room, I will send out more email. From ipp-archive Tue Feb 4 02:57:02 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA19207 for ipp-outgoing; Tue, 4 Feb 1997 02:54:53 -0500 (EST) Message-ID: <32F6EBBC.F24@underscore.com> Date: Tue, 04 Feb 1997 02:56:45 -0500 From: JK Martin Organization: Underscore, Inc. X-Mailer: Mozilla 3.0 (Win95; U) MIME-Version: 1.0 To: PWG Internet Printing Project Subject: Re: IPP> MOD - Two documents downloaded References: <199702040623.WAA03885@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO An Acrobat version of Bob's new attribute table is now available on the PWG server: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/attrtabl-1.1.PDF ...jay From ipp-archive Tue Feb 4 08:37:05 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA20121 for ipp-outgoing; Tue, 4 Feb 1997 08:35:51 -0500 (EST) From: Harald.T.Alvestrand@uninett.no X-Authentication-Warning: tyholt.uninett.no: Host munken.uninett.no [129.241.131.10] didn't use HELO protocol X-Mailer: exmh version 1.6.7 5/3/96 To: JK Martin cc: Larry Masinter , PWG Internet Printing Project Subject: Re: IPP> transaction-based HTTP In-reply-to: Your message of "Fri, 31 Jan 1997 10:39:54 EST." <32F2124A.6753@underscore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Feb 1997 14:36:05 +0100 Message-ID: <15210.855063365@munken.uninett.no> Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Butting in as usual: jkm@underscore.com said: > A more likely scenario is "100 simultaneous requests for printer and/ > or job status". If the world persists in assuming that the printer > itself is the place for every individual to seek the status of the > printer, then printer manufacturers will always have to worry about > these kinds of scaling issues. If answering each request takes < 0.1 seconds, and the average rate of arrival is < 5 requests per second, this is Not A Problem, because you can do these one at a time with no significant performance loss. TCP retransmission will even queue requests for you for a while. The "50 simultaneous print job attempts on a printer than can't buffer?" scenario seems to me to be more damaging; either you impose a near-infinite wait on the "latest" client, or you have to do an error return from the "please print" operation. Harald A From ipp-archive Tue Feb 4 17:07:11 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA21511 for ipp-outgoing; Tue, 4 Feb 1997 17:04:30 -0500 (EST) Date: Tue, 4 Feb 1997 14:03:17 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199702042203.OAA04307@woden.eng.sun.com> To: ipp@pwg.org, Robert.Herriot@Eng.Sun.COM Subject: Re: IPP> MOD - Two documents downloaded -- additional information X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I forgot to mention that the ipp-model-1.1-rev.doc document that I downloaded contains revision marks. Because a lot of the editing process involved merging text from the similar attributes, I I turned off revision control whenever I moved text. I turned on revision control whenever I was changing text. Bob Herriot From ipp-archive Tue Feb 4 19:07:11 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA22008 for ipp-outgoing; Tue, 4 Feb 1997 19:04:33 -0500 (EST) Message-Id: <3.0.32.19970204160621.00932c60@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 4 Feb 1997 16:06:25 PST To: agenda@ietf.org, moore@cs.utk.edu, Harald.T.Alvestrand@uninett.no From: Carl-Uno Manros Subject: IPP> ADM - Request for a slot for Internet Printing Protocol (IPP) Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Dear IETF agenda planners, as proposed chair for the IPP WG in creation, I would like to request a slot (2 hours) in the next IETF meeting. The PWG which is a main contributor to the IPP project will meet late in the previous week in Austin, TX. As I assume that some people may want to combine the two trips, and that another Web related meeting will be held by the W3C during the later part of the IETF meeting, it would be preferable to get a slot early in the week. Regards, Carl-Uno Manros (for the IPP project) Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Wed Feb 5 11:47:20 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA23563 for ipp-outgoing; Wed, 5 Feb 1997 11:44:27 -0500 (EST) Message-Id: <199702051645.AA21232@interlock.lexmark.com> To: "ipp%pwg.org" From: Don Wright Date: 5 Feb 97 11:39:32 EST Subject: IPP> PEP now an ID Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Here's the ID on PEP (which I mentioned a couple of weeks ago.) Don To: ; @ interlock.lexmark.com @ ETF-Announce @ SMTP cc: http-wg%cuckoo.hpl.hp.com @ interlock.lexmark.com @ SMTP (bcc: Don Wright) From: Internet-Drafts%ietf.org @ interlock.lexmark.com @ SMTP Date: 02/04/97 09:42:22 AM Subject: I-D ACTION:draft-ietf-http-pep-01.txt A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the HyperText Transfer Protocol Working Group of the IETF. Title : PEP: an Extension Mechanism for HTTP Author(s) : D. Connolly Filename : draft-ietf-http-pep-01.txt Pages : 14 Date : 01/03/1997 HTTP is an extensible protocol. PEP is an extension mechanism designed to address the tension between private agreement and public specification and to accomodate extension of HTTP clients and servers by software components. The mechanism is to associate each extension with a URL, and use a few new header fields to carry the extension identifier and related information from HTTP clients, thru proxies and intermediaries, to servers, and back again. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-http-pep-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-http-pep-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-http-pep-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ---- next item ---- Content-Type:Text/Plain; Name="ATT01" Content-Type: text/plain Content-ID: <19970203101110.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-http-pep-01.txt ---- next item ---- Content-Type:Text/Plain; Name="draft-ietf-http-pep-01.txt" Content-Type: text/plain Content-ID: <19970203101110.I-D@ietf.org> ---- next item ------ From ipp-archive Thu Feb 6 22:17:42 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA25857 for ipp-outgoing; Thu, 6 Feb 1997 22:15:59 -0500 (EST) Message-Id: <199702070316.AA24064@interlock.lexmark.com> To: "ipp%pwg.org" From: Don Wright Date: 6 Feb 97 22:07:32 EST Subject: IPP> Microsoft Presentation Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have uploaded a PDF version of the Internet Printing presentation Babak made at today's IPP meeting. It can be found at ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ms_internet.pdf Happy hunting! Don ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From ipp-archive Fri Feb 7 12:52:50 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA27120 for ipp-outgoing; Fri, 7 Feb 1997 12:52:49 -0500 (EST) From: davidm@truespectra.com (David McMaster) To: ipp@pwg.org Cc: szilles@adobe.com, rdebry@us.ibm.com, hastings@cp10.es.xerox.com, manros@cp10.es.xerox.com, lfarrel@cisoc.canon.com, walker@dazel.com, don@lexmark.com Message-ID: <1997Feb07.112535.1896.21317@bricklin.lan.truespectra.com> X-Conversion-ID: X-Mailer: Lotus Notes via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Organization: TrueSpectra Inc. Date: Fri, 07 Feb 1997 12:37:00 -0500 Subject: IPP> Possible scenarios that reflect discussion of 2/7/97 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO This is a forward of some scenario suggestions sent to Roger after the = discussions at Adobe on Thursday. Please cc robk@truespectra.com on your = comments. = Thanks David McMaster davidm@truespectra.com ---------------------- Forwarded by David McMaster/TrueSpectra on 02/07/97 = = 12:06 PM --------------------------- David McMaster 02/07/97 02:18 AM To: rdebry @ us.ibm.com @ internet cc: = Subject: Possible scenarios that reflect discussion of 2/7/97 Hello Roger, Here are a couple scenarios that may cover the situations that we talked ab= out = in today's meetings with regard to slim clients wanting to print with = references to high resolution images not available on the client that was = submitting the print job. The ColorWave file referred to in the first Scenario is a document that = contains proxies for the high resolution FlashPix images as well as vector = art and text elements. = David McMaster - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - = - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = 7.0 Declared Internet Resources Scenario #7.1 A photography buff using an Internet Appliance wants to print a high = resolution graphic consisting of a collage of photographic images and vector= = clipart at a service bureau on a dye sublimation printer. His Internet = Appliance does not have enough RAM to collage the images and clipart at a hi= gh = resolution, nor does he have a fast enough Internet uplink to transfer a = 300dpi 24bit color composite of 24MB (he is using a cable modem with slow = uplink capability). The individual photographic images were originally = scanned into multi-resolution Flashpix format by his photo retailer and host= ed = on the retailers' web site. = The graphic composition was created on the Internet Appliance with a ColorW= ave = compatible application supporting low resolution image proxies pulled from = Internet hosted Flashpix files. = The End User connects to a local print shop through the Web and submits = compact ColorWave print job (approx 20K) with Declared Internet Resources = specified (url's pointing to the original Flashpix images). Server at local= = print shop receives ColorWave job and then resolves and caches Declared = Internet Resources before passing the print request to ColorWave Rip. Rip i= s = then able to quickly render a high resolution graphic composition from cache= d = Resources. = Note that the server knew only to cache Declared Internet Resources and nee= ded = no knowledge of their content or intended use. If the server was unable to = = resolve any Declared Internet Resources, the print job would have been = canceled (and an error returned to End User) and never forwarded to the Rip.= Scenario #7.2 A large Quark Express document is submitted for printing with a list of = Declared Internet Resources. In this case, we are assuming that Postscript = = has been modified to use higher resolution bitmaps in place of proxies used = by = Quark and to recognize url identified fonts. = The server caches the Declared Internet Resources and then passes the job to a = Postscript Rip. = Note that here, the size of the transmitted Quark file will only be a fract= ion = of what it would have been had it included the high resolution image files a= nd = all the fonts necessary for print -- thus the overall transfer time is = significantly reduced. Further, the spool space on the server is reduced as= = Declared Internet Resources would only be cached prior to printing -- not = sitting in the queue from the initial time of submission until queue purge. From ipp-archive Fri Feb 7 13:12:52 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA27460 for ipp-outgoing; Fri, 7 Feb 1997 13:08:48 -0500 (EST) From: davidm@truespectra.com (David McMaster) To: ipp@pwg.org Cc: szilles@adobe.com, rdebry@us.ibm.com, hastings@cp10.es.xerox.com, manros@cp10.es.xerox.com, lfarrel@cisoc.canon.com, walker@dazel.com, don@lexmark.com Message-ID: <1997Feb07.112535.1896.21331@bricklin.lan.truespectra.com> X-Conversion-ID: X-Mailer: Lotus Notes via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Organization: TrueSpectra Inc. Date: Fri, 07 Feb 1997 13:10:52 -0500 Subject: IPP> Possible scenarios that reflect discussion of 2/7/97 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO This is a forward of some scenario suggestions sent to Roger after the = discussions at Adobe on Thursday. Please cc robk@truespectra.com on your = comments. = Thanks David McMaster davidm@truespectra.com ---------------------- Forwarded by David McMaster/TrueSpectra on 02/07/97 = = 12:06 PM --------------------------- David McMaster 02/07/97 02:18 AM To: rdebry @ us.ibm.com @ internet cc: = Subject: Possible scenarios that reflect discussion of 2/7/97 Hello Roger, Here are a couple scenarios that may cover the situations that we talked ab= out = in today's meetings with regard to slim clients wanting to print with = references to high resolution images not available on the client that was = submitting the print job. The ColorWave file referred to in the first Scenario is a document that = contains proxies for the high resolution FlashPix images as well as vector = art and text elements. = David McMaster - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - = - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = 7.0 Declared Internet Resources Scenario #7.1 A photography buff using an Internet Appliance wants to print a high = resolution graphic consisting of a collage of photographic images and vector= = clipart at a service bureau on a dye sublimation printer. His Internet = Appliance does not have enough RAM to collage the images and clipart at a hi= gh = resolution, nor does he have a fast enough Internet uplink to transfer a = 300dpi 24bit color composite of 24MB (he is using a cable modem with slow = uplink capability). The individual photographic images were originally = scanned into multi-resolution Flashpix format by his photo retailer and host= ed = on the retailers' web site. = The graphic composition was created on the Internet Appliance with a ColorW= ave = compatible application supporting low resolution image proxies pulled from = Internet hosted Flashpix files. = The End User connects to a local print shop through the Web and submits = compact ColorWave print job (approx 20K) with Declared Internet Resources = specified (url's pointing to the original Flashpix images). Server at local= = print shop receives ColorWave job and then resolves and caches Declared = Internet Resources before passing the print request to ColorWave Rip. Rip i= s = then able to quickly render a high resolution graphic composition from cache= d = Resources. = Note that the server knew only to cache Declared Internet Resources and nee= ded = no knowledge of their content or intended use. If the server was unable to = = resolve any Declared Internet Resources, the print job would have been = canceled (and an error returned to End User) and never forwarded to the Rip.= Scenario #7.2 A large Quark Express document is submitted for printing with a list of = Declared Internet Resources. In this case, we are assuming that Postscript = = has been modified to use higher resolution bitmaps in place of proxies used = by = Quark and to recognize url identified fonts. = The server caches the Declared Internet Resources and then passes the job to a = Postscript Rip. = Note that here, the size of the transmitted Quark file will only be a fract= ion = of what it would have been had it included the high resolution image files a= nd = all the fonts necessary for print -- thus the overall transfer time is = significantly reduced. Further, the spool space on the server is reduced as= = Declared Internet Resources would only be cached prior to printing -- not = sitting in the queue from the initial time of submission until queue purge. From ipp-archive Fri Feb 7 13:52:52 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA27902 for ipp-outgoing; Fri, 7 Feb 1997 13:51:06 -0500 (EST) From: davidm@truespectra.com (David McMaster) To: ipp@pwg.org Cc: szilles@adobe.com, rdebry@us.ibm.com, hastings@cp10.es.xerox.com, manros@cp10.es.xerox.com, lfarrel@cisoc.canon.com, walker@dazel.com, don@lexmark.com Message-ID: <1997Feb07.112535.1896.21338@bricklin.lan.truespectra.com> X-Conversion-ID: X-Mailer: Lotus Notes via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Organization: TrueSpectra Inc. Date: Fri, 07 Feb 1997 13:53:11 -0500 Subject: IPP> Possible scenarios that reflect discussion of 2/7/97 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO This is a forward of some scenario suggestions sent to Roger after the = discussions at Adobe on Thursday. Please cc robk@truespectra.com on your = comments. = Thanks David McMaster davidm@truespectra.com ---------------------- Forwarded by David McMaster/TrueSpectra on 02/07/97 = = 12:06 PM --------------------------- David McMaster 02/07/97 02:18 AM To: rdebry @ us.ibm.com @ internet cc: = Subject: Possible scenarios that reflect discussion of 2/7/97 Hello Roger, Here are a couple scenarios that may cover the situations that we talked ab= out = in today's meetings with regard to slim clients wanting to print with = references to high resolution images not available on the client that was = submitting the print job. The ColorWave file referred to in the first Scenario is a document that = contains proxies for the high resolution FlashPix images as well as vector = art and text elements. = David McMaster - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - = - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = 7.0 Declared Internet Resources Scenario #7.1 A photography buff using an Internet Appliance wants to print a high = resolution graphic consisting of a collage of photographic images and vector= = clipart at a service bureau on a dye sublimation printer. His Internet = Appliance does not have enough RAM to collage the images and clipart at a hi= gh = resolution, nor does he have a fast enough Internet uplink to transfer a = 300dpi 24bit color composite of 24MB (he is using a cable modem with slow = uplink capability). The individual photographic images were originally = scanned into multi-resolution Flashpix format by his photo retailer and host= ed = on the retailers' web site. = The graphic composition was created on the Internet Appliance with a ColorW= ave = compatible application supporting low resolution image proxies pulled from = Internet hosted Flashpix files. = The End User connects to a local print shop through the Web and submits = compact ColorWave print job (approx 20K) with Declared Internet Resources = specified (url's pointing to the original Flashpix images). Server at local= = print shop receives ColorWave job and then resolves and caches Declared = Internet Resources before passing the print request to ColorWave Rip. Rip i= s = then able to quickly render a high resolution graphic composition from cache= d = Resources. = Note that the server knew only to cache Declared Internet Resources and nee= ded = no knowledge of their content or intended use. If the server was unable to = = resolve any Declared Internet Resources, the print job would have been = canceled (and an error returned to End User) and never forwarded to the Rip.= Scenario #7.2 A large Quark Express document is submitted for printing with a list of = Declared Internet Resources. In this case, we are assuming that Postscript = = has been modified to use higher resolution bitmaps in place of proxies used = by = Quark and to recognize url identified fonts. = The server caches the Declared Internet Resources and then passes the job to a = Postscript Rip. = Note that here, the size of the transmitted Quark file will only be a fract= ion = of what it would have been had it included the high resolution image files a= nd = all the fonts necessary for print -- thus the overall transfer time is = significantly reduced. Further, the spool space on the server is reduced as= = Declared Internet Resources would only be cached prior to printing -- not = sitting in the queue from the initial time of submission until queue purge. From ipp-archive Fri Feb 7 14:22:51 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA28295 for ipp-outgoing; Fri, 7 Feb 1997 14:22:45 -0500 (EST) From: davidm@truespectra.com (David McMaster) To: ipp@pwg.org Cc: szilles@adobe.com, rdebry@us.ibm.com, hastings@cp10.es.xerox.com, manros@cp10.es.xerox.com, lfarrel@cisoc.canon.com, walker@dazel.com, don@lexmark.com Message-ID: <1997Feb07.112535.1896.21349@bricklin.lan.truespectra.com> X-Conversion-ID: X-Mailer: Lotus Notes via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Organization: TrueSpectra Inc. Date: Fri, 07 Feb 1997 14:24:47 -0500 Subject: IPP> Possible scenarios that reflect discussion of 2/7/97 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO This is a forward of some scenario suggestions sent to Roger after the = discussions at Adobe on Thursday. Please cc robk@truespectra.com on your = comments. = Thanks David McMaster davidm@truespectra.com ---------------------- Forwarded by David McMaster/TrueSpectra on 02/07/97 = = 12:06 PM --------------------------- David McMaster 02/07/97 02:18 AM To: rdebry @ us.ibm.com @ internet cc: = Subject: Possible scenarios that reflect discussion of 2/7/97 Hello Roger, Here are a couple scenarios that may cover the situations that we talked ab= out = in today's meetings with regard to slim clients wanting to print with = references to high resolution images not available on the client that was = submitting the print job. The ColorWave file referred to in the first Scenario is a document that = contains proxies for the high resolution FlashPix images as well as vector = art and text elements. = David McMaster - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - = - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = 7.0 Declared Internet Resources Scenario #7.1 A photography buff using an Internet Appliance wants to print a high = resolution graphic consisting of a collage of photographic images and vector= = clipart at a service bureau on a dye sublimation printer. His Internet = Appliance does not have enough RAM to collage the images and clipart at a hi= gh = resolution, nor does he have a fast enough Internet uplink to transfer a = 300dpi 24bit color composite of 24MB (he is using a cable modem with slow = uplink capability). The individual photographic images were originally = scanned into multi-resolution Flashpix format by his photo retailer and host= ed = on the retailers' web site. = The graphic composition was created on the Internet Appliance with a ColorW= ave = compatible application supporting low resolution image proxies pulled from = Internet hosted Flashpix files. = The End User connects to a local print shop through the Web and submits = compact ColorWave print job (approx 20K) with Declared Internet Resources = specified (url's pointing to the original Flashpix images). Server at local= = print shop receives ColorWave job and then resolves and caches Declared = Internet Resources before passing the print request to ColorWave Rip. Rip i= s = then able to quickly render a high resolution graphic composition from cache= d = Resources. = Note that the server knew only to cache Declared Internet Resources and nee= ded = no knowledge of their content or intended use. If the server was unable to = = resolve any Declared Internet Resources, the print job would have been = canceled (and an error returned to End User) and never forwarded to the Rip.= Scenario #7.2 A large Quark Express document is submitted for printing with a list of = Declared Internet Resources. In this case, we are assuming that Postscript = = has been modified to use higher resolution bitmaps in place of proxies used = by = Quark and to recognize url identified fonts. = The server caches the Declared Internet Resources and then passes the job to a = Postscript Rip. = Note that here, the size of the transmitted Quark file will only be a fract= ion = of what it would have been had it included the high resolution image files a= nd = all the fonts necessary for print -- thus the overall transfer time is = significantly reduced. Further, the spool space on the server is reduced as= = Declared Internet Resources would only be cached prior to printing -- not = sitting in the queue from the initial time of submission until queue purge. From ipp-archive Fri Feb 7 14:57:53 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA28749 for ipp-outgoing; Fri, 7 Feb 1997 14:53:27 -0500 (EST) From: davidm@truespectra.com (David McMaster) To: ipp@pwg.org Cc: szilles@adobe.com, rdebry@us.ibm.com, hastings@cp10.es.xerox.com, manros@cp10.es.xerox.com, lfarrel@cisoc.canon.com, walker@dazel.com, don@lexmark.com Message-ID: <1997Feb07.112535.1896.21355@bricklin.lan.truespectra.com> X-Conversion-ID: X-Mailer: Lotus Notes via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Organization: TrueSpectra Inc. Date: Fri, 07 Feb 1997 14:55:27 -0500 Subject: IPP> Possible scenarios that reflect discussion of 2/7/97 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO This is a forward of some scenario suggestions sent to Roger after the = discussions at Adobe on Thursday. Please cc robk@truespectra.com on your = comments. = Thanks David McMaster davidm@truespectra.com ---------------------- Forwarded by David McMaster/TrueSpectra on 02/07/97 = = 12:06 PM --------------------------- David McMaster 02/07/97 02:18 AM To: rdebry @ us.ibm.com @ internet cc: = Subject: Possible scenarios that reflect discussion of 2/7/97 Hello Roger, Here are a couple scenarios that may cover the situations that we talked ab= out = in today's meetings with regard to slim clients wanting to print with = references to high resolution images not available on the client that was = submitting the print job. The ColorWave file referred to in the first Scenario is a document that = contains proxies for the high resolution FlashPix images as well as vector = art and text elements. = David McMaster - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - = - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = 7.0 Declared Internet Resources Scenario #7.1 A photography buff using an Internet Appliance wants to print a high = resolution graphic consisting of a collage of photographic images and vector= = clipart at a service bureau on a dye sublimation printer. His Internet = Appliance does not have enough RAM to collage the images and clipart at a hi= gh = resolution, nor does he have a fast enough Internet uplink to transfer a = 300dpi 24bit color composite of 24MB (he is using a cable modem with slow = uplink capability). The individual photographic images were originally = scanned into multi-resolution Flashpix format by his photo retailer and host= ed = on the retailers' web site. = The graphic composition was created on the Internet Appliance with a ColorW= ave = compatible application supporting low resolution image proxies pulled from = Internet hosted Flashpix files. = The End User connects to a local print shop through the Web and submits = compact ColorWave print job (approx 20K) with Declared Internet Resources = specified (url's pointing to the original Flashpix images). Server at local= = print shop receives ColorWave job and then resolves and caches Declared = Internet Resources before passing the print request to ColorWave Rip. Rip i= s = then able to quickly render a high resolution graphic composition from cache= d = Resources. = Note that the server knew only to cache Declared Internet Resources and nee= ded = no knowledge of their content or intended use. If the server was unable to = = resolve any Declared Internet Resources, the print job would have been = canceled (and an error returned to End User) and never forwarded to the Rip.= Scenario #7.2 A large Quark Express document is submitted for printing with a list of = Declared Internet Resources. In this case, we are assuming that Postscript = = has been modified to use higher resolution bitmaps in place of proxies used = by = Quark and to recognize url identified fonts. = The server caches the Declared Internet Resources and then passes the job to a = Postscript Rip. = Note that here, the size of the transmitted Quark file will only be a fract= ion = of what it would have been had it included the high resolution image files a= nd = all the fonts necessary for print -- thus the overall transfer time is = significantly reduced. Further, the spool space on the server is reduced as= = Declared Internet Resources would only be cached prior to printing -- not = sitting in the queue from the initial time of submission until queue purge. From ipp-archive Fri Feb 7 15:27:56 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA29189 for ipp-outgoing; Fri, 7 Feb 1997 15:25:12 -0500 (EST) From: davidm@truespectra.com (David McMaster) To: ipp@pwg.org Cc: szilles@adobe.com, rdebry@us.ibm.com, hastings@cp10.es.xerox.com, manros@cp10.es.xerox.com, lfarrel@cisoc.canon.com, walker@dazel.com, don@lexmark.com Message-ID: <1997Feb07.112535.1896.21358@bricklin.lan.truespectra.com> X-Conversion-ID: X-Mailer: Lotus Notes via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Organization: TrueSpectra Inc. Date: Fri, 07 Feb 1997 15:27:12 -0500 Subject: IPP> Possible scenarios that reflect discussion of 2/7/97 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO This is a forward of some scenario suggestions sent to Roger after the = discussions at Adobe on Thursday. Please cc robk@truespectra.com on your = comments. = Thanks David McMaster davidm@truespectra.com ---------------------- Forwarded by David McMaster/TrueSpectra on 02/07/97 = = 12:06 PM --------------------------- David McMaster 02/07/97 02:18 AM To: rdebry @ us.ibm.com @ internet cc: = Subject: Possible scenarios that reflect discussion of 2/7/97 Hello Roger, Here are a couple scenarios that may cover the situations that we talked ab= out = in today's meetings with regard to slim clients wanting to print with = references to high resolution images not available on the client that was = submitting the print job. The ColorWave file referred to in the first Scenario is a document that = contains proxies for the high resolution FlashPix images as well as vector = art and text elements. = David McMaster - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - = - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = 7.0 Declared Internet Resources Scenario #7.1 A photography buff using an Internet Appliance wants to print a high = resolution graphic consisting of a collage of photographic images and vector= = clipart at a service bureau on a dye sublimation printer. His Internet = Appliance does not have enough RAM to collage the images and clipart at a hi= gh = resolution, nor does he have a fast enough Internet uplink to transfer a = 300dpi 24bit color composite of 24MB (he is using a cable modem with slow = uplink capability). The individual photographic images were originally = scanned into multi-resolution Flashpix format by his photo retailer and host= ed = on the retailers' web site. = The graphic composition was created on the Internet Appliance with a ColorW= ave = compatible application supporting low resolution image proxies pulled from = Internet hosted Flashpix files. = The End User connects to a local print shop through the Web and submits = compact ColorWave print job (approx 20K) with Declared Internet Resources = specified (url's pointing to the original Flashpix images). Server at local= = print shop receives ColorWave job and then resolves and caches Declared = Internet Resources before passing the print request to ColorWave Rip. Rip i= s = then able to quickly render a high resolution graphic composition from cache= d = Resources. = Note that the server knew only to cache Declared Internet Resources and nee= ded = no knowledge of their content or intended use. If the server was unable to = = resolve any Declared Internet Resources, the print job would have been = canceled (and an error returned to End User) and never forwarded to the Rip.= Scenario #7.2 A large Quark Express document is submitted for printing with a list of = Declared Internet Resources. In this case, we are assuming that Postscript = = has been modified to use higher resolution bitmaps in place of proxies used = by = Quark and to recognize url identified fonts. = The server caches the Declared Internet Resources and then passes the job to a = Postscript Rip. = Note that here, the size of the transmitted Quark file will only be a fract= ion = of what it would have been had it included the high resolution image files a= nd = all the fonts necessary for print -- thus the overall transfer time is = significantly reduced. Further, the spool space on the server is reduced as= = Declared Internet Resources would only be cached prior to printing -- not = sitting in the queue from the initial time of submission until queue purge. From ipp-archive Fri Feb 7 21:52:57 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA02225 for ipp-outgoing; Fri, 7 Feb 1997 21:52:32 -0500 (EST) Message-Id: <199702080253.AA17764@interlock.lexmark.com> To: "ipp%pwg.org" From: Don Wright Date: 7 Feb 97 12:40:21 EST Subject: IPP> New HTTP Methods vs POST Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO One of the issues we discussed yesterday was if we decided to use HTTP, should we use POST or create some new methods. There were several issues discussed about this but one of the most significant was if we start with POST and move to new methods in order to get into the market faster, why would the server developers add support for the new methods? Additionally yesterday, we saw a presentation from Microsoft about their directions in Internet printing for NT 5.0. While their directions were "simpler" than some of the work we are doing with DPA-light, etc. there is still a very solid set of functions planned. So.... what if we were to take the Microsoft approach and map that to HTTP POST, standardize what they are doing and call it SIPP (Simple Internet Printing Protocol). Meanwhile, we can continue working on the DPA-light oriented approach, create new HTTP methods, and call that IPP. If we do a good job with it, we can minimize the differences where possible but then have a real reason for the new methods and reasons to get the server folks to implement this higher functionality. This also could really help us get something usable to market very quickly while providing a migration path to the full function print server solution. Am I all wet? All this assumes an HTTP based protocol so don't hit me with the TCP stream argument again. Would this concept work IF we use HTTP? Don ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From ipp-archive Fri Feb 7 21:52:58 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA02220 for ipp-outgoing; Fri, 7 Feb 1997 21:52:28 -0500 (EST) Message-Id: <199702080253.AA17762@interlock.lexmark.com> To: "ipp%pwg.org" From: Don Wright Date: 7 Feb 97 12:45:27 EST Subject: IPP> Meeting Minutes Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have posted the minutes for the 2/6 meeting on the ftp server. As per our discussion, I have only posted the minutes in .TXT and .PDF format. These files are located in: ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-0297.txt ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-0297.pdf Additionally, for the computationally impaired, I have attached the ugly, hard to read .txt format at the bottom of this note. Don ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Internet Printing Project Meeting Minutes February 6, 1997 San Jose,California The meeting started on February 6th, 1997 at 8:30AM led by Carl-Uno Manro. The attendees were: Ron Bergman - Data Products Mike Timperman - Lexmark Lee Farrell - Canon Don Wright - Lexmark David Kellerman - Northlake Software Scott Isaacson - Novell Mabry Dozier - QMS Jeff Copeland - QMS Bob Pentecost - HP Tom Hastings - Xerox Harry Lewis - IBM Roger Debry - IBM William Wagner - Digital Products Atsushi Yuki - Kyocera Robert Herriot - Sun Carl-Uno Manros - Xerox Keith Carter - IBM Jim Walker - Dazel Chuck Adams - Tektronix Stuart Rowley - Kyocera Peter Zehler - Xerox Robert Kline - TrueSpectra David McMaster - TrueSpectra Robert Chansler - Adobe Sylvan Butler - HP Shivaun Albright - HP Paul Riechmann - IBM Steve Adobe - Adobe Shinji Mochizuki - Kyocera Noim Jacobs - Sun Wendy Phillips - Sun Tony Collins - Sun Prashant Sheekla - Novell Asad Faizi - Netscape Weing Gan - Intel Hirofumi Nishiwaki - Ricoh Gary Roberts - Ricoh Yuji Yamashita - IBM Nobuhiro Asai - IBM J.K. Martin - Underscore Shige Kanemitsu - Kyocera Babak Jahromi - Microsoft Greg LeClair - Epson Randy Turner - Sharp The following proposed agenda was reviewed and approved: 1) Agenda Check 2) Microsoft 3) Scenario Discussion 4) Requirements Discussion 5) Lunch 6) Model & Semantics 7) Protocol 8) Directory 9) Security 10) Prototyping 11) Planning discussion Introductions Microsoft Presentation - Babak Jahromi The charts of this presentation are available on the ftp server as: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ms_internet.pdf Internet Printing n Print to URL n HTML queue status from URL n WEB point and print n Install driver from URL "Seamless integration with printing architecture" How do we get a printer URL? n Have IIS or Peer Web Server n Share the printer n URL = "http://ServerName/PrinterShareName" Technology n HTTP/HTML based n Any browse on any client views the printer or job information n Server components implemented as an IIS ISAPI DLL Printing to URL n NT 5 clients print to Win NT 5 server via an HTTP print provider supporting OpenPrinter (UTL) n Prints across firewalls to Internet Architecture Charts - Print client and server HTTP Print Provider n Base on Win32 Internet APIs n Win32 Internet APIs available for Win9x and WinNT OpenPrinter code samples HTML Printer Status n HTML view of printer or job information generated automatically by the server n Customize HTML view by providing HTML templates n Add-on components embedded in HTML tags providing vendor-specific views Architecture - HTML view of printers Tag Processor, tag Entry points, Action Commands, etc. Variety of Views n Printer Properties n Job Properties n Queue View n Security Views n etc. Web Point and Printer n Hot Link in HTML View n Driver automatically downloaded off the print server Discussion on several items of Babak's presentation n Number of POSTS to send a print job n Using URLs and how they relate to commands n Microsoft's proposal would allow a new type of "printer" that expected ATTRIBUTES to be pre-pended to the JOB STREAM n Nothing in the proposal at this time to deal with changing job attributes while the job is waiting to be printed (e.g. number of copies, etc.) SCENARIOS - Roger Debry Roger Debry of IBM presented the IPP Scenarios document. The document is available from the PWG ftp server. Detailed issues on this presentation were collected by Peter Zehler. Comments and issues raised include: n What capabilities should be enumerated via the directory or some other means? n How will users access this information - should this be in the scenarios? n Issue of what to do when the user requested something that the printer can't do - what should the printer do? n How does a printer print HTML? What about collections of pages? n How are commerce transactions handled in 1.0? n How should previously printed jobs be reported? How many? Time based? n Discussion on what is meant by a capability being available - n On hand n Can be ordered n Other possible scenarios to be added n Distributed Document Content Don Wright, Roger Debry and Peter Zehler will have a phone conference next week (week of 2/10) to determine how to integrate the scenarios into the requirements document. MODELING GROUP - Bob Herriott (See the 2/5 modeling sub-group meeting minutes for details.) n Report from meeting 2/5/97 n Multiple documents per job needed n Document attributes needed n Document attributes like Job attributes except they only apply to document n A document is not an object n Conformance -- multiple documents per job support not required n Adornments to attributes n "Best Efforts" n PDL specific adornments PROTOCOL - Roger Debry Roger gave a presentation of "IPP Protocol White Paper Discussion" and "IPP Protocol White Paper" documents (which are available from the PWG FTP server.) n ISSUE: Should the protocol allow multiple PDLs per document? n ISSUE: The current proposal doesn't return the JOBid until the end. What happens with multiple clients all sending jobs at the same time - how does the server know where the data is coming from? n Discussion on the need for transport to be REQUEST-RESPONSE n should we duplicate the function in the underlying transport? n what cases can't be handled? n If we use HTTP should we overload POST or create new methods? n Could 1.0 use POST and define a migration path using new methods? n Asad Faizi of Netscape asked why would the protocol overload the use of POST to send data using HTTP. He suggested that new methods could be created that would provide a cleaner interface and higher performance. Netscape servers could be "patched" to add new methods? Roger Debry proposed to produce a set of technical papers to cover the material being done by the printer working group. There was some interest in doing these papers; however the issue of schedule and availability of time to write these papers was an issue. It would be ideal if this series could be an entire issue of some technical journal. No decision was made; however, there did seem to be a lack of time to do this work. PLANNING DISCUSSION - Carl-Uno Manros Carl-Uno reminded the group that we are suppose to produce 4 Internet Drafts by mid- March: 1) Requirements 2) Protocol 3) Model and Semantics 4) Directory Discussion on using MIME occurred again. Should we define our own MIME type (application/ipp) or use one of the existing multi-part MIME types. No decision. DIRECTORY - Carl-Uno Not much progress has been made in this area at this time. We have a draft which was created from the directory pieces of the original IPP ID. No work has been done on this document since then. This document will be a generic schema, another document will map that schema to LDAP or some other directory services. SECURITY - Carl-Uno The security sub-group will be meeting tomorrow (2/7) in El Segundo to talk about security. At this time Carl-Uno, Roger Debry and several other Xerox security people plan to be in attendance. PROTOTYPING - Carl-Uno Separate sub-group on prototyping. Several groups have prototyping efforts underway or soon will be: n Xerox n IBM n Novell WEEKLY CONFERENCE CALL - Carl-Uno Discussion items for the Wednesday conference call: 1) Report on security meeting 2) Discussion on the Model document 3) Report and discussion on results of requirements/scenarios plan After the conclusion of the planned agenda items, Babak asked for: FEEDBACK ON MICROSOFT PRESENTATION 1) Is there a programmatic interface to the Microsoft system n You can use Win32 APIs 2) How do you get to these printers n Open and WEB open off the printer icon n You know the server and share name or use Directory services 3) Notification n Could we use pushing to get notification? n Could we use the META tag for refresh to see status updates? 4) Question: Is the current plan for IPP too heavy? Is the Microsoft solution too light? OPEN FLOOR DISCUSSIONS A philosophical discussion occurred on the overlap of IPP versus Job Monitoring MIB versus the Printer MIB. Can IPP be a subset of the MIBs or vice versa or should it just overlap. Bottom line: Where there is an intersection of objects between MIBs a nd IPP, the semantics should be the same. The group felt that the overhead of the protocol that overlapped some transports in the draft by Roger Debry was probably worth it perhaps with the exception of the Content- Response-Required-Flag. Carl-Uno announced that the WEB page for the IPP group was making good progress and should be readily available in the next week or so. The meeting adjourned at 5:25 PM ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From ipp-archive Sat Feb 8 10:28:06 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA05886 for ipp-outgoing; Sat, 8 Feb 1997 10:24:56 -0500 (EST) Message-ID: <32FC9AD7.2155@sharplabs.com> Date: Sat, 08 Feb 1997 07:25:11 -0800 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Laboratories of America X-Sender: Randy Turner X-Mailer: Mozilla 4.0b1 (Win95; I) MIME-Version: 1.0 To: Don Wright CC: "ipp%pwg.org" Subject: Re: IPP> New HTTP Methods vs POST X-Priority: Normal References: <199702080253.AA17764@interlock.lexmark.com> Content-Type: multipart/alternative; boundary="----------14F92C081EDA0" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO ------------14F92C081EDA0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Don Wright wrote: > > One of the issues we discussed yesterday was if we decided > to use HTTP, should we use POST or create some new methods. > There were several issues discussed about this but one of > the most significant was if we start with POST and move to > new methods in order to get into the market faster, why > would the server developers add support for the new methods? > > Additionally yesterday, we saw a presentation from Microsoft > about their directions in Internet printing for NT 5.0. > While their directions were "simpler" than some of the work > we are doing with DPA-light, etc. there is still a very > solid set of functions planned. > > So.... what if we were to take the Microsoft approach and map > that to HTTP POST, standardize what they are doing and > call it SIPP (Simple Internet Printing Protocol). Meanwhile, > we can continue working on the DPA-light oriented approach, > create new HTTP methods, and call that IPP. If we do a > good job with it, we can minimize the differences where > possible but then have a real reason for the new methods > and reasons to get the server folks to implement this > higher functionality. This also could really help us get > something usable to market very quickly while providing > a migration path to the full function print server > solution. > > Am I all wet? Well, I don't think Microsoft needs the IETF to "rubber-stamp" an internet printing standard. Its like Jeff Case said, "Microsoft is the world's largest and most successful standards organization". I am hoping that Microsoft (and others) are still open to technical contributions from the PWG I think with a few slight modifications to their design, we could say that it might approach a minimally conforming implementation of IPP; I personally don't see any reason to create two standards, and there are aspects of their command structure which impose Microsoft's spooling model on systems that would consider such a design unnecessary. I would prefer a more leaner approach that would lend itself to better performance on HTTP 0.9 and HTTP 1.0 environments and would allow easier implementation (essentially fewer POST operations). Above all, I think we need to stay on track with our requirements and scenarios. Also, we will need to define levels of conformance so that IPP eventually can scale across the widest possible scope of printing environments (low end to high end). One of these conformance levels might encompass a simpler style of printing and status collecting similar to what Microsoft is doing. These levels of conformance should be negotiated for proper interoperation between low-end clients and high-end servers, or vice-versa. As an aside, I think a priority should be to make IPP transport independent, with separate documents describing individual transport mappings. The IPP and transport mapping work can be accomplished (somehwat) in parallel to achieve timely completion of the work. Randy > All this assumes an HTTP based protocol so > don't hit me with the TCP stream argument again. Would > this concept work IF we use HTTP? > > Don > > ************************************************************* > * Don Wright (don@lexmark.com) Lexmark International * > * Manager Strategic Alliances * > * 740 New Circle Rd Phone: 606-232-4808 * > * Lexington, KY 40511 Fax: 606-232-6740 * > ************************************************************* ------------14F92C081EDA0 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
 Don Wright wrote:

> One of the issues we discussed yesterday was if we decided
> to use HTTP, should we use POST or create some new methods.
> There were several issues discussed about this but one of
> the most significant was if we start with POST and move to
> new methods in order to get into the market faster, why
> would the server developers add support for the new methods?

> Additionally yesterday, we saw a presentation from Microsoft
> about their directions in Internet printing for NT 5.0.
> While their directions were "simpler" than some of the work
> we are doing with DPA-light, etc. there is still a very
> solid set of functions planned.

> So.... what if we were to take the Microsoft approach and map
> that to HTTP POST, standardize what they are doing and
> call it SIPP (Simple Internet Printing Protocol).  Meanwhile,
> we can continue working on the DPA-light oriented approach,
> create new HTTP methods, and call that IPP.  If we do a
> good job with it, we can minimize the differences where
> possible but then have a real reason for the new methods
> and reasons to get the server folks to implement this
> higher functionality.  This also could really help us get
> something usable to market very quickly while providing
> a migration path to the full function print server
> solution.

> Am I all wet?  
 
Well, I don't think Microsoft needs the IETF to "rubber-stamp" an
internet printing standard.  Its like Jeff Case said, "Microsoft is the world's
largest and most successful standards organization". I am hoping that
Microsoft (and others) are still open to technical contributions from the
PWG
 
I think with a few slight modifications to their design, we could say that it might
approach a minimally conforming implementation of IPP; I personally don't
see any reason to create two standards, and there are aspects of their command
structure which impose Microsoft's spooling model on systems that would
consider such a design unnecessary. I would prefer a more leaner approach
that would lend itself to better performance on HTTP 0.9 and HTTP 1.0
environments and would allow easier implementation (essentially fewer POST
operations). 
 
Above all, I think we need to stay on track with our requirements and
scenarios. Also, we will need to define levels of conformance so that IPP
eventually can scale across the widest possible scope of printing environments
(low end to high end). One of these conformance levels might encompass a
simpler style of printing and status collecting similar to what Microsoft is
doing. These levels of conformance should be negotiated for proper
interoperation between low-end clients and high-end servers, or vice-versa.
 
As an aside, I think a priority should be to make IPP transport independent,
with separate documents describing individual transport mappings. The IPP
and transport mapping work can be accomplished (somehwat) in parallel
to achieve timely completion of the work.
 
Randy
 
 
> All this assumes an HTTP based protocol so
> don't hit me with the TCP stream argument again.  Would
> this concept work IF we use HTTP?

> Don

> *************************************************************
> * Don Wright (don@lexmark.com)        Lexmark International *
> * Manager                               Strategic Alliances *
> * 740 New Circle Rd                     Phone: 606-232-4808 *
> * Lexington, KY  40511                    Fax: 606-232-6740 *
> *************************************************************

------------14F92C081EDA0-- From ipp-archive Sun Feb 9 04:43:13 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA07549 for ipp-outgoing; Sun, 9 Feb 1997 04:42:22 -0500 (EST) Message-Id: <9702090940.AA06061@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen (Unverified) X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 9 Feb 1997 01:38:46 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Comments on Model V1.1, dated 2/3/97 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I've posted some high level comments on the attributes in the Model V1.1 paper in: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ -rw-r--r-- 1 pwg pwg 35328 Feb 9 09:32 mod11tnh.doc -rw-r--r-- 1 pwg pwg 27359 Feb 9 09:33 mod11tnh.pdf -rw-r--r-- 1 pwg pwg 27915 Feb 9 09:33 mod11tnh.pdr Tom From ipp-archive Sun Feb 9 23:03:25 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA08414 for ipp-outgoing; Sun, 9 Feb 1997 22:59:00 -0500 (EST) Message-ID: From: Babak Jahromi To: "'rturner@sharplabs.com'" , "'Don Wright'" Cc: "'ipp%pwg.org'" Subject: RE: IPP> New HTTP Methods vs POST Date: Sun, 9 Feb 1997 20:00:30 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 100 TEXT Sender: ipp-owner@pwg.org Precedence: first-class Status: RO My comments marked with MS>>> below. Babak >-----Original Message----- >From: Randy Turner [SMTP:rturner@sharplabs.com] >Sent: Saturday, February 08, 1997 7:25 AM >To: Don Wright >Cc: ipp%pwg.org >Subject: Re: IPP> New HTTP Methods vs POST > > Don Wright wrote: >> >> One of the issues we discussed yesterday was if we decided >> to use HTTP, should we use POST or create some new methods. >> There were several issues discussed about this but one of >> the most significant was if we start with POST and move to >> new methods in order to get into the market faster, why >> would the server developers add support for the new methods? >> >> Additionally yesterday, we saw a presentation from Microsoft >> about their directions in Internet printing for NT 5.0. >> While their directions were "simpler" than some of the work >> we are doing with DPA-light, etc. there is still a very >> solid set of functions planned. >> >> So.... what if we were to take the Microsoft approach and map >> that to HTTP POST, standardize what they are doing and >> call it SIPP (Simple Internet Printing Protocol). Meanwhile, >> we can continue working on the DPA-light oriented approach, >> create new HTTP methods, and call that IPP. If we do a >> good job with it, we can minimize the differences where >> possible but then have a real reason for the new methods >> and reasons to get the server folks to implement this >> higher functionality. This also could really help us get >> something usable to market very quickly while providing >> a migration path to the full function print server >> solution. >> >> Am I all wet? > >Well, I don't think Microsoft needs the IETF to "rubber-stamp" an >internet printing standard. Its like Jeff Case said, "Microsoft is the >world's >largest and most successful standards organization". I am hoping that >Microsoft (and others) are still open to technical contributions from >the PWG >MS>>> Not really the case. We (MS) do want to be compatible with IPP, and it >would be costly for us not to. For example consider today's scenario: Every >vendor installs its own networking solution on Windows machines to support >their network printers (plain TCP code, SNMP code, DPA stuff, etc.). This >makes Windows clients bloated and complex. Our customers who buy Windows >family of OSes suffer from it. So we definitely see value to have a built-in >support in the OS for a protocol that most printers understand. > >I think with a few slight modifications to their design, we could say >that it might >approach a minimally conforming implementation of IPP; I personally >don't >see any reason to create two standards, and there are aspects of their >command >structure which impose Microsoft's spooling model on systems that would >consider such a design unnecessary. I would prefer a more leaner >approach >that would lend itself to better performance on HTTP 0.9 and HTTP 1.0 >environments and would allow easier implementation (essentially fewer >POST >operations). > >MS>>> One clarification: The number of POSTs needed in MS's approach to ship >the job data to the server is arbitrary. In our today's implementation, it is >equal to the number of times Spooler calls print provider's WritePrinter(), >but this is not inherent in the protocol. You could choose to ship the whole >job data in a single POST, and the server would be happy with it (even though >the client's firewall may not be). I could easily modify our Print Provider >to collect all the data and ship it in a single or larger POST(s) at the >EndDoc time (and I might actually do that if the performance tests show the >need). But there is nothing in the protocol that imposes the number of the >POSTs. The protocol I presented in the meeting had really little to do with >our Spooler architecture. It might have appeared that way beacause I chose to >define it by describing how it could be implemented on top of Win32 Internet >APIs and how it maps to Windows Print Provider calls. > >Above all, I think we need to stay on track with our requirements and >scenarios. Also, we will need to define levels of conformance so that >IPP >eventually can scale across the widest possible scope of printing >environments >(low end to high end). One of these conformance levels might encompass a >simpler style of printing and status collecting similar to what >Microsoft is >doing. These levels of conformance should be negotiated for proper >interoperation between low-end clients and high-end servers, or >vice-versa. >MS>>> The simplicity it the key. If you want to see the support in the OS, >you need to keep it simple. An overly complete DPA-like protocol won't get >implemented any time soon simply because few people have the time to do it. >Remember we are running with the Internet clock now... > From ipp-archive Mon Feb 10 08:53:30 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA09425 for ipp-outgoing; Mon, 10 Feb 1997 08:48:35 -0500 (EST) Message-Id: <199702101349.AA03835@interlock.lexmark.com> To: "ipp%pwg.org" Cc: "rturner%sharplabs.com" From: Don Wright Date: 10 Feb 97 8:49:55 EST Subject: Re: IPP> New HTTP Methods vs POST Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Randy Turner said: >Well, I don't think Microsoft needs the IETF to "rubber-stamp" an >internet printing standard. Its like Jeff Case said, "Microsoft is the >world's largest and most successful standards organization". I am >hoping that Microsoft (and others) are still open to technical >contributions from the PWG It is not my intention to "rubber-stamp" Microsoft's current implementation; however, I think we can learn a lot by examining their much simpler approach and creating an OS independent standard on par with their proposal. >I think with a few slight modifications to their design, we could say >that it might approach a minimally conforming implementation of IPP; I >personally don't see any reason to create two standards, and there >are aspects of their command structure which impose Microsoft's >spooling model on systems that would consider such a design >unnecessary. I would prefer a more leaner approach that would >lend itself to better performance on HTTP 0.9 and HTTP 1.0 >environments and would allow easier implementation (essentially >fewer POST operations). I think we are in basic agreement here. My major difference is to use the simple POST implementation for the minimally conforming implementations and us the new methods (should we map to HTTP) for the more robust implementations. >As an aside, I think a priority should be to make IPP >transport independent, with separate documents describing >individual transport mappings. The IPP and transport mapping >work can be accomplished (somehwat) in parallel to achieve >timely completion of the work. I have agreed with this plan all along. ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From ipp-archive Mon Feb 10 10:23:31 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA09869 for ipp-outgoing; Mon, 10 Feb 1997 10:21:00 -0500 (EST) Message-Id: <199702101521.AA07844@interlock.lexmark.com> To: "ipp%pwg.org" From: Don Wright Date: 10 Feb 97 10:23:15 EST Subject: IPP> Conference Calls 2/12 & 2/19 Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have set up conference calls for 2/12 and 2/19. The numbers are the same as before but here they are.... Call-in: 1-423-673-6712 Access Code: 190148 Date: 2/12 and 2/19 Time: 4PM Eastern Duration: 2.5 hrs Don ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From ipp-archive Mon Feb 10 12:08:31 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA10423 for ipp-outgoing; Mon, 10 Feb 1997 12:08:23 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 10 Feb 1997 10:03:51 -0700 From: "Scott A. Isaacson" To: ipp@pwg.org Subject: IPP> New HTTP Methods vs POST -Reply Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Don, ************************************************************ 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: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ >>> Don Wright 02/07/97 10:40am >>> > So.... what if we were to take the Microsoft approach and map > that to HTTP POST, standardize what they are doing and > call it SIPP (Simple Internet Printing Protocol). Meanwhile, > we can continue working on the DPA-light oriented approach, > create new HTTP methods, and call that IPP. I think that we should keep with the name IPP and keep it as simple as possible. The print protocol (semantics and operations) should basically be the same across all mappings on transports. In other words there could be a mapping of IPP on: 1. HTTP 1.0 POST 2. HTTP 1.1 POST (taking advantage of new 1.1 underlying features) 3. HTTP 1.x extended methods 4. Raw TCP 5. Internet RPCs 6. IIOP 7. etc, etc. In other words, lets not create two things, but one thing. Call it IPP. Then as Randy and you have pointed out in later (than this) emails, propose multiple "mapping documents". I am still in favor of #1 above (HTTP 1.0 POST) or protoptyping and reasonable first step deployment. Maybe we will learn more as we go through the first step which will make additional choices more clear. Scott From ipp-archive Mon Feb 10 12:08:32 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA10432 for ipp-outgoing; Mon, 10 Feb 1997 12:08:29 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 10 Feb 1997 10:05:11 -0700 From: "Scott A. Isaacson" To: ipp@pwg.org Subject: IPP> New HTTP Methods vs POST -Reply Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Don, >>> Don Wright 02/07/97 10:40am >>> > So.... what if we were to take the Microsoft approach and map > that to HTTP POST, standardize what they are doing and > call it SIPP (Simple Internet Printing Protocol). Meanwhile, > we can continue working on the DPA-light oriented approach, > create new HTTP methods, and call that IPP. I think that we should keep with the name IPP and keep it as simple as possible. The print protocol (semantics and operations) should basically be the same across all mappings on any transport(s). In other words there could be a mapping of IPP on: 1. HTTP 1.0 POST 2. HTTP 1.1 POST (taking advantage of new 1.1 underlying features) 3. HTTP 1.x extended methods 4. Raw TCP 5. Internet RPCs 6. IIOP 7. etc, etc. In other words, lets not create two things, but one thing. Call it IPP. Then as Randy and you have pointed out in later (than this) emails, propose multiple "mapping documents". I am still in favor of #1 above (HTTP 1.0 POST) or protoptyping and reasonable first step deployment. Maybe we will learn more as we go through the first step which will make additional choices more clear. 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: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Mon Feb 10 12:23:35 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA11077 for ipp-outgoing; Mon, 10 Feb 1997 12:20:32 -0500 (EST) Message-Id: <3.0.32.19970210091410.013da440@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 10 Feb 1997 09:14:47 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC - Minutes from SEC meeting in El Segundo, February 7 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Meeting notes from IPP Security meeting held at Xerox on February 7, 1997 I. Attendees A. IBM 1. Roger DeBry Architecture & Tech., full time on IPP, Boulder CO 2. Jerry Hadsell, IBM Internet Division, Security Expert, jhadsell@vnet.ibm.com, New York B. Xerox: Carl-Uno Manros, Gopal Panchanathan, Steve Okamoto, Xavier Riley, Rick Yardumian, all from Xerox Corporate Research & Technology II. General Notes A. What scenarios are most important? Roger said Corporate Intranet first, corporate global Internet next, end user to commercial printer (e.g Kinkos) last. B. General agreement that IPP should use standard security methods and not invent anything new. C. Additional security standards not in the Steve Okamoto presentation. 1. SHTTP: Gopal felt SSL is so much better than SHTTP that SHTTP shouldn’t be considered. 2. SPK: Light weight certificate mechanism. Might replace X.509 someday. 3. General agreement that LDAP would beat out X.500. D. Gopal felt payment schemes were very important since he felt IPP would be of most use to the internet, i.e. commercial printers, not corporate intranets. Continuing this discussion, later, Gopal stated that if IPP did not enable new functionality i.e. if IPP does not go beyond LPR, why would users move to it? Gopal feels strongly that IPP should enable electronic commerce. III. Scenario discussion: A. Scenarios: (Rick’s interpretation of Roger’s slides) 1. No security: no user name, server will accept any job that it can handle. 2. Document data is encrypted. 3. Discovery: Example of getting a printer’s public key. 4. Authentication: User ID required. 5. Authentication: User ID and password required. 6. Mutual authentication 7. Mutual authentication and exchange of secret keys. 8. Payment B. Threats listed by connection scenario: 1. Client and IPP printer are both within the same organizational firewall. a) Misuse of printer resources by employee, e.g. sending large B/W jobs to expensive color devices. b) Confidential data on public printers. Jerry mentioned sub topic of how data is routed after printing. 2. Client and IPP printer are outside firewalls. a) Printer perspective: (1) Misuse of resources by unknown clients, e.g. wasting paper, etc. (2) Junk mail (3) Denial of service, "spamming" (4) Legal liability of printer based on content. (5) Provability of service. (6) Defeating payment system. b) User perspective: (1) Incorrect destination (2) Content integrity: (a) Correct rendering/formatting (i) security marks (watermarks, banners, etc.) illegible (b) Correct content, i.e. transmission errors, malicious content change (3) Confidentiality (a) As data flows across network (b) As it resides in the printer (c) Needed resource corruption 3. The client is inside the firewall, IPP printer is outside a firewall. a) Will the firewall allow print data to flow outside? b) Legal liability of user’s employer for printed content. 4. The client is outside the firewall, IPP printer is inside a firewall. a) Printer (1) Unauthorized use. (a) Do we rely on firewall for authentication of user and capabilities or must the printer participate in authentication? b) Client (1) Incorrect destination. c) The client is outside the firewall, IPP printer is inside the firewall, but client is employee. (Variation) 5. The client is inside the firewall, IPP printer is inside a different firewall. a) Liability against client Corp. to printer Corp. policies. C. Real World Scenarios (lead by Jerry Hadsell) 1. Client a) Printer Discovery (client talking to directory service) (1) printer lookup (based on required attributes) (2) printer certification (3) location (URL?) b) Client to Printer 2. Security Notes a) (Microsoft moved to Kerberos for NT 5) (Kerberos is secret key based versus SSL which is public key based and SSL is tied to TCP/IP) b) LDAP (aka lightweight X.500) (1) supports different security schemes such as SSL and Kerberos c) SSL basics (1) Security fixed once session/channel is established. SHTTP differed in that it allowed security levels to be changed on the "field" level. (2) HTTP that uses SSL is bound to a particular SSL based "port". (3) HTTP, FTP, etc. sit "on top" of SSL which sits on top of TCP/IP. (4) Mutual authentication based on "certificates" which contain your public key. (5) Confidentiality by encrypting the data stream on the network. (6) Reliable session. (7) What parameters does IPP need to be aware of to use SSL? (8) Does IPP require mutual authentication? (9) Less complex than GSS. (10) Does not address threats that lie on the client and server since it only addresses the communication link. IV. Commerce A. Pay for print 1. Payment models a) When (1) Pay before (debit) (2) Pay during (3) Pay after b) Account holder vs. Non-account holder (e.g. walkin) c) Payment method (1) Negotiation (2) Online (a) credit card (b) digital check (c) digital cash (3) Offline - both electronic and non-electronic d) Pricing (1) Negotiation (2) Estimation e) Accounting f) Non-repudiation (1) audit trail (2) cryptographic methods V. Issues: A. Single/multiple levels of security: 1. Should client and server negotiate what protocols to use? B. Intranet versus Internet concerns: 1. Strong/weak authentication 2. Access control 3. Payment: Very important to commercial internet but also important to many intranets for cost control. 4. Usage rights C. Assumptions: 1. Firewalls will be able to identify IPP traffic (even if HTTP is used?). 2. All IPP operations will be initiated from the IPP client. Notifications from the IPP printer to the user is not part of IPP. 3. Status reports are requested by the IPP printer is not part of the IPP. 4. One or more documents can be submitted with a single IPP job submission. 5. Print documents must be contained (by explicit content or URL reference) in the IPP client request. a) "Pushing" documents asynchronously (e.g. separate ftp from any source) from an IPP client to an IPP server is not part of the IPP. b) IPP does not specify the method of a server "pulling" a URL referenced document. D. SSL 1. What parameters would IPP need to be aware of to use SSL? 2. Does IPP require mutual authentication? 3. Carl-Uno wants the client or the printer to have the ability to control the amount of security they need. Jerry said this is worked out during the "negotiation". The resulting URL from the discovery process should indicate if security is required. VI. Next Phone Conference, Thursday, 13th, 1pm PST. Xerox to set up a phone number. VII. Action items: A. Jerry Hadsell to create a diagram showing HTTP/SSL security mechanisms. B. Steve O. to incorporate his IPP environment diagram into the meeting notes and put into the IPP web site. --- Rick Yardumian --- Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Mon Feb 10 12:33:32 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA11412 for ipp-outgoing; Mon, 10 Feb 1997 12:31:08 -0500 (EST) From: davidm@truespectra.com (David McMaster) To: Ipp@pwg.org Message-ID: <1997Feb10.112848.1896.21495@bricklin.lan.truespectra.com> X-Conversion-ID: X-Mailer: Lotus Notes via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Organization: TrueSpectra Inc. Date: Mon, 10 Feb 1997 12:33:18 -0500 Subject: Re: IPP> Possible scenarios that reflect discussion of 2/7/97 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO My apologies to all for the flood of scenarios messages on Friday. = For some reason our mail server logged a delivery failure even though the = message had gone out, and it kept trying for the remainder of the afternoon.= We are looking into the cause presently to avoid this in the future. Once again my apologies. David McMaster davidm@truespectra.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - = - - - - - - - - - - - - - - - - - - - - - - - - - -- -- - - - - - - - - - -= - = - - - David, I don't know what went wrong, but this same message has now gone out 6 time= s to our IPP DL. Suggest you check your email software. Carl-Uno From ipp-archive Mon Feb 10 13:03:32 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA11822 for ipp-outgoing; Mon, 10 Feb 1997 13:02:43 -0500 (EST) Message-Id: <3.0.32.19970210100318.01401d88@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 10 Feb 1997 10:03:22 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> PRO - Re: New HTTP Methods vs POST -Reply Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO At 09:05 AM 2/10/97 PST, Scott A. Isaacson wrote: >Don, > >>>> Don Wright 02/07/97 10:40am >>> >> So.... what if we were to take the Microsoft approach and map >> that to HTTP POST, standardize what they are doing and >> call it SIPP (Simple Internet Printing Protocol). Meanwhile, >> we can continue working on the DPA-light oriented approach, >> create new HTTP methods, and call that IPP. > >I think that we should keep with the name IPP and keep it as simple as >possible. The print protocol (semantics and operations) should basically >be the same across all mappings on any transport(s). In other words >there could be a mapping of IPP on: > >1. HTTP 1.0 POST >2. HTTP 1.1 POST (taking advantage of new 1.1 underlying features) >3. HTTP 1.x extended methods >4. Raw TCP >5. Internet RPCs >6. IIOP >7. etc, etc. > >In other words, lets not create two things, but one thing. Call it IPP. Then >as Randy and you have pointed out in later (than this) emails, propose >multiple "mapping documents". > >I am still in favor of #1 above (HTTP 1.0 POST) or protoptyping and >reasonable first step deployment. Maybe we will learn more as we go >through the first step which will make additional choices more clear. > I agree fully with Scott here. I definately do NOT want us to start discussing a light-lightweight protocol, which would only lead to confusion and distract us from completing IPP in time. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Mon Feb 10 17:48:38 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA13283 for ipp-outgoing; Mon, 10 Feb 1997 17:44:12 -0500 (EST) From: rdebry@us.ibm.com X400-Originator: rdebry@us.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100004467132000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100004467132000002*@MHS> To: <"ipp@PWG.ORG"@??.ibm.com> Subject: Re: Re[2]: IPP> PRO,MOD> User model for clients Date: Mon, 10 Feb 1997 17:42:53 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 Sure browsers parse html, but you would have to define very concrete html syntax for IPP attributes and values if the client were going to do anything pther than simply display the information. ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/10/97 09:39 AM --------------------------- ipp-owner @ pwg.org 01/30/97 07:04 PM To: Roger K Debry/Boulder/IBM, ipp @ pwg.org@internet cc: Subject: Re: Re[2]: IPP> PRO,MOD> User model for clients Roger, What did you mean by your comment below? HTML certainly is parseable programmatically for displaying. Web browsers do it all the time. Is there something more that you expect the client to do with HTML? Bob Herriot > 3. It was my understanding that HTTP was transaction based, and > therefore the scenario outlined below, if HTTP were the transport, > would require two connections. There would also, presumably, be a > response to delivery of the job. If therefore, the query for > capabilities and job delivery are different connections, why the > constraints on the HTTP used for capabilities query? Indeed, there > appears to be no need to require that the same transport be used. > > RKD> The reason I don't think the flow doesn't work is that the > RKD> HTML is meant to be human readable, not parsable > RKD> programmatically. Therefore the client cannot use > RKD> the information that comes back on subsequent > RKD tranactions. > From ipp-archive Mon Feb 10 17:48:39 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA13561 for ipp-outgoing; Mon, 10 Feb 1997 17:47:32 -0500 (EST) From: rdebry@us.ibm.com X400-Originator: rdebry@us.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100004467331000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100004467331000002*@MHS> To: Subject: IPP> New HTTP Methods vs POST -Reply Date: Mon, 10 Feb 1997 17:46:06 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 I support Scott's view. Let's keep moving down the path we are on -- get the protocol right, then do whatever mappings we think are appropriate as a second step. I don;t think that we could standardize on the Microsoft approach because they are passing Microsoft internal data structures around. ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/10/97 12:12 PM --------------------------- ipp-owner @ pwg.org 02/10/97 10:11 AM To: ipp @ pwg.org@internet cc: Subject: IPP> New HTTP Methods vs POST -Reply Don, ************************************************************ 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: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ >>> Don Wright 02/07/97 10:40am >>> > So.... what if we were to take the Microsoft approach and map > that to HTTP POST, standardize what they are doing and > call it SIPP (Simple Internet Printing Protocol). Meanwhile, > we can continue working on the DPA-light oriented approach, > create new HTTP methods, and call that IPP. I think that we should keep with the name IPP and keep it as simple as possible. The print protocol (semantics and operations) should basically be the same across all mappings on transports. In other words there could be a mapping of IPP on: 1. HTTP 1.0 POST 2. HTTP 1.1 POST (taking advantage of new 1.1 underlying features) 3. HTTP 1.x extended methods 4. Raw TCP 5. Internet RPCs 6. IIOP 7. etc, etc. In other words, lets not create two things, but one thing. Call it IPP. Then as Randy and you have pointed out in later (than this) emails, propose multiple "mapping documents". I am still in favor of #1 above (HTTP 1.0 POST) or protoptyping and reasonable first step deployment. Maybe we will learn more as we go through the first step which will make additional choices more clear. Scott From ipp-archive Mon Feb 10 18:13:37 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA13928 for ipp-outgoing; Mon, 10 Feb 1997 18:12:24 -0500 (EST) Message-ID: From: Babak Jahromi To: "'rdebry@us.ibm.com'" , "'ipp@pwg.org'" Subject: RE: IPP> New HTTP Methods vs POST -Reply Date: Mon, 10 Feb 1997 15:13:20 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 16 TEXT Sender: ipp-owner@pwg.org Precedence: first-class Status: RO > >I support Scott's view. Let's keep moving down the path we are on -- get the >protocol right, >then do whatever mappings we think are appropriate as a second step. I don;t >think that we >could standardize on the Microsoft approach because they are passing >Microsoft >internal >data structures around. > > >Yes. but that's happenig only in one case, and it only contains user id and a >couple of other basic job properties. It would take me at most 15 minutes of >coding to change that structure to its IPP equivalent. > >Babak From ipp-archive Tue Feb 11 10:23:45 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA15503 for ipp-outgoing; Tue, 11 Feb 1997 10:20:44 -0500 (EST) Message-Id: <3300928E.7547@dazel.com> Date: Tue, 11 Feb 1997 09:38:54 -0600 From: Jim Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 3.0 (WinNT; I) Mime-Version: 1.0 To: ipp@pwg.org Subject: IPP> MOD - Minutes from Meeting at Sun on February 5 Content-Type: multipart/mixed; boundary="------------2389178E21CA" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO This is a multi-part message in MIME format. --------------2389178E21CA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Attached are the minutes from the Model Group meeting at Sun on February 5. Thanks to Lee Farrell for providing his notes to me to help fill in those gaps that I missed. I have also uploaded the files to: ftp://ftp.pwg.org/pub/pwg/ipp/minutes/970205-ipp-mod-meeting.doc ftp://ftp.pwg.org/pub/pwg/ipp/minutes/970205-ipp-mod-meeting.txt If someone could do the PDF, I would appreciate it. enjoy... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX --------------2389178E21CA Content-Type: text/plain; charset=iso-8859-1; name="970205-ipp-mod-meeting.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="970205-ipp-mod-meeting.txt" IPP Model Group Meeting Minutes February 5, 1997 San Jose, California The meeting started on February 5 at 1:00PM. The attendees were: Jim Walker -- DAZEL Keith Carter -- IBM Lee Farrell -- Canon Tom Hastings -- Xerox Carl-Uno Manros -- Xerox Don Wright -- Lexmark Bob Herriot -- Sun Larry Masinter -- Xerox Greg Mavroudis -- TrueSpectra Steve Sutherland -- TrueSpectra Scott Isaacson -- Novell (by phone) The following agenda was suggested by Bob Herriot: 1) Attributes 2) Queues / fan-in and fan-out – what does the user see? 3) GetJobs printer information 4) Conformance 5) Scenarios (and conformance thereof) Ultimately, the meeting focused on attributes only, touching upon the other issues at various times. Bob Herriot had distributed a new version of the IPP Model draft, which combined and simplified the attributes. In general, the participants were happy with the idea of job attributes being represented in the printer object, obviating the need for the job template object, and the xxx-supported attributes. During this discussion of attributes, it was questioned if they are beneficial, useful, or just nice; for example, Microsoft's approach does not have any attributes. Most felt that the attributes were necessary. The following is a summary of the more important issues that were discussed. o Production attributes and resource attributes There are cases in the job attributes where an attribute is both production and resource attributes. For example, the xxx-margin attributes could be production instructions in the case of a text document (i.e., these margins should be used when translating this document to a format suitable for printing), or a resource attribute in the case of a PostScript document (i.e., these are the margins that were used in formatting this output). The current proposal in the document (as added by Bob Herriot) is that the attributes have an optional "embedded" tag to indicate that the attribute is a resource. So, in the example above, the xxx-margin attributes would have no tag in the case of a text document, but would have the "embedded" tag for the PostScript document. The conversation then degenerated into a discussion of whether the length and width (and the xxx-margin problems, for that matter), are really useful for text processing; for example, if I specify a width for a text document, is it really going to be able to break and format lines like I wanted. The group admitted that these might just be solutions for the 5% case, but there was no motion to remove the attributes. o File type tag Another new tag, or adornment, that was added to the Model document was a tag to indicate an attribute or value that may be appropriate for only a particular document format. For example, a printer may only support number-up=4 for PostScript documents, so the attribute value could be adorned so that the client could decide which attributes and values are appropriate based upon the input document format. Discussion of this tag led to some interesting questions. For example, what if the client does not know the file type yet? Also, what if a job has multiple documents of varying formats (e.g., 1 PostScript document and 1 PCL document). There was no real decisions made as to whether this tag was appropriate or not, because we immediately jumped into... o Multiple document jobs We had a long discussion on multi-document jobs; we say that we will support multiple documents, but we do not allow all attributes to be different for each document. We already have at least two attributes, document-format and document- content, that can vary across documents. On a practical basis, people are going to want to have other characteristics that are different for each document in a multi- document job. The scenario that we referred to in justifying generalizing the per-document attributes is the common case of printing the first page of a letter on company letterhead, and the rest of the letter on plain stock, except for the last page which is printed on some third stock. This scenario could be viewed as three documents being printed on three different media. (Alternatively, this could be handled by submitting the letter as a single document, and having special attributes for first-page-medium and last-page-medium, but that is another discussion :-). The question was raised about how important it is to really support multiple documents per job. It was pointed out that Microsoft breaks down a multi-document print request into separate jobs. However, it was also pointed out that LPR does support multi-document print jobs. (Everyone feels that IPP needs to do at least what LPR can do.) This led to a discussion about what the concept of a "print job" should be, with little consensus reached. Bob suggested a compromise: we want to have multiple documents per job, and have per-document attributes which override job-level attributes. However, we should not address the syntax of this capability at this time; let's attempt to ensure that our syntax does not preclude future support of this feature. We have not yet decided whether we do or do not need a separate document object, but the general feeling seemed to be to keep it simple. The discussion of multi-document jobs then led to the question of what should be the behavior of a printer (or server) that is sent a multi-document job, but can only support single-document jobs. This led to the issue of... o Compulsory/Non-compulsory attributes We had first discussed the print-regardless attribute that had been added in the latest version of the IPP Model document. We had decided to remove this attribute, and have print-regardless be the default. This would imply that a job would print in spite of errors in the job specification; the server would simply make its "best effort" to print the job. In addition, we discussed the idea of having a "compulsory" adornment for attributes, which the user could use to indicate particular attributes that the server is required to comply with, or else reject the job. However, it was decided to table the idea of this adornment for now. As we discussed multi-document jobs, we got back into the discussion of best effort versus compulsory behavior. Several people felt that the previous decision of best effort being the default would result in clients not being able to reliably print; IPP would end up with the reputation that the client does not get what it asks for. Tom Hastings also added that compulsory behavior as a default would be better for standards compliance (i.e., strictest is best for interoperability). So, we decided that the previous decision was backwards; instead, we felt that the default should be that any attributes that are specified with a job shall be assumed to be compulsory, unless the attribute (or attribute value) is explicitly adorned otherwise. Also, we will not define what a best effort is; we will simply define the conforming behavior. Furthermore, we suggested that there may even be some attributes that may not be adorned as non-compulsory, or best effort. For example, the number of documents in a job is not really a characteristic of the job that the client explicitly sets; rather, it is a characteristic of the job that is implied from the number of documents included in the submission. Consequently, if a client submits a multi-document job, and the server does not support multi-document jobs, then the server shall reject the job. o Multi-valued attributes We currently have one job submission attribute (notification-events) that can be multi-valued; its syntax is setOfType2Enum. We discussed whether to have distinguished values for this syntax. Originally the discussion focused on a special value, "none", which would be used to indicate the empty set. Tom Hastings suggested this distinguished value so that a client could specify none (and override an explicit default), and an administrator could set none as a default value, or exclude it as a supported value. Bob Herriot noted that this distinguished value would have to be treated specially (if none was specified, then no other values could be specified for that multi-valued attribute), and Larry Massinter reminded us that existing standards (HTTP and SMTP) already use an empty string to represent the empty set, or none. No decision was made, but it was suggested that there might be other useful distinguished values, such as "all" and "default". o External references Steve Sutherland suggested that a job should specify any external references that are present in a document. The examples given were a ColorWave (?) format used by his company (TrueSpectra), PDL's that reference external fonts, and HTML files. Larry pointed out that a problem with referencing Internet resources is that there needs to be an agreed naming convention of these resources, because they may be named differently by different clients. Also, the group was very wary of treading into the problem of printing a tree of HTML references. Ultimately, the decision was to add a new attribute for external references that are (or will be) needed to process a document. This attribute, if specified, will presumably list (by URL) resources that, if retrieved ahead of time, can cause the document to be processed more quickly. o Several other interesting side discussions occurred: - Larry suggested that we should have the capability in the protocol to return multiple jobs as the result of a single print request. Although this suggestion was made during the discussion of trying to define the "best-effort" of printing a multi-document job at a server that only supports single document jobs, it still might be of use in other areas. - Tom suggested that we should have conformance requirements on the client as well as the server. The example sited was that a conformant client verify that a server supports multi-document jobs before submitting a multi-document job. - Do we need a new attribute that specifies that all of the documents in the job (and all of the copies) should be kept together? - Once we have the capability of non-compulsory, there seem to be 4 different cases for (some) attributes: What can the printer do ? What is the client requesting ? What does the server say it is going to do ? What did the server actually do ? We could use adornments for this (e.g., as-submitted, as-printed, etc.). - Larry suggested that we make the request syntax separate from the response syntax. For example, I could ask for courier font or fixedwidth font, so the request might be able to ask for A or B. However, the response might include the values requested, the default values, and the values used. The meeting adjourned at 6:00 PM. --------------2389178E21CA-- From ipp-archive Tue Feb 11 10:33:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA15949 for ipp-outgoing; Tue, 11 Feb 1997 10:33:00 -0500 (EST) From: rdebry@us.ibm.com X400-Originator: rdebry@us.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100004494773000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100004494773000002*@MHS> To: Subject: RE: IPP> New HTTP Methods vs POST -Reply Date: Tue, 11 Feb 1997 10:31:38 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 Babek, sounds encouraging. I was going to make a few changes to the white paper anyway to reflect your notion of getting the job handle before sending the data. I thought that everyone liked this scheme. ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/11/97 07:53 AM --------------------------- ipp-owner @ pwg.org 02/10/97 04:14 PM To: ipp @ pwg.org@internet, Roger K Debry/Boulder/IBM cc: Subject: RE: IPP> New HTTP Methods vs POST -Reply > >I support Scott's view. Let's keep moving down the path we are on -- get the >protocol right, >then do whatever mappings we think are appropriate as a second step. I don;t >think that we >could standardize on the Microsoft approach because they are passing >Microsoft >internal >data structures around. > > >Yes. but that's happenig only in one case, and it only contains user id and a >couple of other basic job properties. It would take me at most 15 minutes of >coding to change that structure to its IPP equivalent. > >Babak From ipp-archive Tue Feb 11 12:18:45 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA16584 for ipp-outgoing; Tue, 11 Feb 1997 12:15:17 -0500 (EST) Message-Id: <1.5.4.32.19970211171606.00664180@pop.mindspring.com> X-Sender: manros@pop.mindspring.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 11 Feb 1997 09:16:06 -0800 To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Agenda for 970212 Telephone Conference Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Agenda for IPP Conference Call on February 12, 1997 - Update on Scenario and Requirements (Peter and Ron) - Update on Model and Semantics (Scott and Bob) - Report from the first SEC meeting (Carl-Uno andRoger) - Any other news to report --- Call-in: 1-423-673-6712 Access Code: 190148 Date: 2/12 Time: 4PM Eastern Duration: 2.5 hrs ---- arl-Uno From ipp-archive Tue Feb 11 12:28:47 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA16915 for ipp-outgoing; Tue, 11 Feb 1997 12:26:20 -0500 (EST) Message-Id: <1.5.4.32.19970211172626.006715a0@pop.mindspring.com> X-Sender: manros@pop.mindspring.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 11 Feb 1997 09:26:26 -0800 To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC - Minutes and Presentation from 970207 now in PWG server Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have now stored copies of the minutes and a few presentation slides from the February 7 SEC meeting on the server in the new_SEC directory. Carl-Uno From ipp-archive Tue Feb 11 15:18:51 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA18119 for ipp-outgoing; Tue, 11 Feb 1997 15:17:36 -0500 (EST) From: rdebry@us.ibm.com X400-Originator: rdebry@us.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100004509353000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100004509353000002*@MHS> To: Subject: RE: IPP> New HTTP Methods vs POST -Reply Date: Tue, 11 Feb 1997 15:16:05 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 Yes, I like this too. I'll add it. ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/11/97 01:16 PM --------------------------- IINUS1.SMTP2 @ D03AU017 02/11/97 01:09 PM Please respond to IINUS1.SMTP2 @ VM To: Roger K Debry/Boulder/IBM cc: Subject: RE: IPP> New HTTP Methods vs POST -Reply Received: from alpha.xerox.com by vnet.IBM.COM (IBM VM SMTP V2R3) with TCP; Tue, 11 Feb 97 15:07:19 EST Received: from mailhost.cp10.es.xerox.com (*13.240.124.12*) by alpha.xerox.com with SMTP id <14980(3)>; Tue, 11 Feb 1997 12:07:19 PST Received: from garfield (garfield.cp10.es.xerox.com) by mailhost.cp10.es.xerox.com (4.1/SMI-4.1) *id AA29619; Tue, 11 Feb 97 12:08:07 PST Received: from cpq5100-26 by garfield (SMI-8.6/SMI-SVR4) *id MAA06514; Tue, 11 Feb 1997 12:05:16 -0800 Message-Id: <3.0.32.19970211120752.008ee6f8@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 11 Feb 1997 12:07:53 PST To: debry@vnet.ibm.com From: Carl-Uno Manros Subject: RE: IPP> New HTTP Methods vs POST -Reply Cc: hastings@cp10.es.xerox.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 07:31 AM 2/11/97 PST, rdebry@us.ibm.com wrote: >Classification: >Prologue: >Epilogue: Roger K deBry >Senior Techncial Staff Member >Architecture and Technology >IBM Printing Systems >email: rdebry@us.ibm.com >phone: 1-303-924-4080 > >Babek, sounds encouraging. I was going to make a few changes to the >white paper anyway to reflect your notion of getting the job handle before >sending >the data. I thought that everyone liked this scheme. Roger, another part that I liked was that the attribute stuff gets sent before the actual document. This would allow validation of the print request parameters, and hence a possible refusal if the job cannot be done, before the actual document data are sent, which would benefit both the user and the print service. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Tue Feb 11 15:18:52 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA17809 for ipp-outgoing; Tue, 11 Feb 1997 15:13:23 -0500 (EST) Message-Id: <9702112013.AA06735@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 11 Feb 1997 12:11:37 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Comments on IPP Model V1.1, printer-state attribute Sender: ipp-owner@pwg.org Precedence: first-class Status: RO We've agreed to subset ISO DPA printer states to the bare minimum and to add a printer-state-reasons attribute which is multivalued and printer-state-message which is a text string to augment the printer-state attribute. I believe that we also agreed (but its not yet in the draft) to add the ISO DPA Boolean printer attribute of enabled to indicate that the current policy of the Printer is to accept Print operations or not. The value of the enabled attribute is orthogonal to the printer-state attribute, since the printer can be not accepting jobs while finishing the currents jobs that it has, i.e., be in any of the printer-state states. Perhaps, make the name clearer as: "enabled-to-accept-jobs", instead of just "enabled". I have the following comments on the current text of printer-state which is: 5.5.5 printer-state (type1Enum) This attribute identifies the current state of the printer and shall be set by the Printer. The protocol support all values for printer states, however a Printer shall only generate the printer states which are appropriate for the particular implementation. The following standard values are defined: unknown The printer state is not known, or is indeterminate, or is not returned by the operation idle The printer is ready to accept jobs, but none have been scheduled on it. printing The printer is currently printing a job needs-attention The printer needs human attention (no special skills required). This state typically includes adding paper, clearing a jam, changing the medium, etc. Comments: 1. Add "s" to support. 2. "idle" should not indicate whether the Printer is accepting jobs or not, that is what the enabled attribute is for. So change the definition of idle to: idle The Printer is not processing any jobs. 3. Change the name of the "printing" state to "processing", so that the state may be used by Printers when interpreting, and by non-Printer output devices, like CD-ROM writers and fax-out. So change the definition to: processing The Printer is currently processing a job. 4. "needs-attention" may now need special training, since needs-attention is for any reason that the Printer needs human attention. Also the operator may have paused the printer or the job may contain instructions to stop the printer and wait for human interaction. So change the definition of needs-attention to: needs-attention The Printer needs human attention. This state typically includes adding paper, clearing a jam, changing the medium, etc. It also includes when a system operator has paused the printer or the job contains special instructions to stop the printer at a particular point in the job to wait for operator or end-user interaction, such as installing special forms or entering a password. The printer-state-reasons and printer-state-messsage printer attributes give further information about why the output device needs attentions. 5. I also belive that we need the ISO DPA "shutdown" state, which indicates that the Printer has been shutdown. It seems too surprising to end-users to indicate a shutdown condition as a printer-state-reason when the printer is in the needs-attention or idle states. So bring back "shutdown": shutdown The Printer has been taken out of service, (for a long time), whether for repairs or others reasons. The Printer's printer-state message attribute may be used to record a reason and estimated time for return to service. 6. Here is the suggested text for "enabled-to-accept-jobs" Boolean printer attribute: enabled-to-accept-jobs (boolean) Indicates whether the Printer is accepting job submission Print operations or not. A Printer shall reject Print operations when the value of the Printer enabled attribute indicates false (no, n, false, or f). NOTE - The enabled-to-accept-jobs printer attribute is set by the operator using means outside the scope of IPP V1.0. 7. The printer-state-reasons should include the following deleted ISO DPA printer states as values: paused The operator has (temporarily) paused the Printer, by means outside the scope of IPP V1.0. needs-key-operator The output device needs the attention of a key operator. Key operator functions require special training and are device-specific, but typically include adding toner or developer, or attending to a hardware fault. connecting-to-printer The server has scheduled a job on the Printer and is in the process of connecting to a shared network output device (and may not be able to actually start printing the job for an arbitrarily long time depending on the usage of the output device by other servers on the network). timed-out The server was able to connect to the output device (or is always connected), but was unable to get a response from the output device in the time specified by the printer's printer-timeout-period attribute. The following ISO DPA deleted printer states do not need to be added as printer-state-reasons, since IPP does not have the job attributes that go with them: job-start-wait The currently processing job was started with the job-start-wait attribute set, and is awaiting operator intervention or time-out. job-end-wait The currently processing job was started with the job-end-wait attribute set, and is awaiting operator intervention or time-out. job-password-wait The currently processing job was started with the job-password attribute set, and is awaiting the operator or user to enter the password supplied by the job-password attribute. By the way, the OMG Print Facility standards project is on the same schedule as IPP and is trying to align with IPP, so this above discussion on printer states relates to work they are currently doing. So I hope we can get closure on these printer attributes soon in order to keep the two developing standards aligned. Thanks, Tom From ipp-archive Tue Feb 11 16:33:48 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA19273 for ipp-outgoing; Tue, 11 Feb 1997 16:33:36 -0500 (EST) Message-ID: <3300E3C1.7E45@sharplabs.com> Date: Tue, 11 Feb 1997 13:25:21 -0800 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: rdebry@us.ibm.com CC: ipp@pwg.org Subject: Re: IPP> New HTTP Methods vs POST -Reply References: <5030100004509353000002*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I also basically agree with the current POST operational ideas: POST for start-job POST print job data POST end-job for the start-job POST, I would like to see the IPP server return preformatted URLs for subsequent operations to this particular server job, such as status requests, cancel request, etc. The IPP "standard" part of this specification would only specify the order that these URLs are transmitted by the server, but not the format of the individual URL components. i.e., POST start-job From ipp-archive Tue Feb 11 16:43:50 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA19616 for ipp-outgoing; Tue, 11 Feb 1997 16:40:43 -0500 (EST) Message-ID: <3300E581.5464@sharplabs.com> Date: Tue, 11 Feb 1997 13:32:49 -0800 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> HTTP POST design Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Sorry for the truncated previous message.... I also basically agree with the current POST operational ideas: POST for start-job POST print job data POST end-job for the start-job POST, I would like to see the IPP server return preformatted URLs for subsequent operations to this particular server job, such as status requests, cancel request, etc. The IPP "standard" part of this specification would only specify the order that these URLs are transmitted by the server, but not the format of the individual URL components. i.e., POST start-job . . (Response from IPP server) HTTP 200 OK (URL target for subsequent operations on this server print job) (Any other URLs that are operation-specific) Randy -- Randy Turner Network Architect Sharp Laboratories of America rturner@sharplabs.com From ipp-archive Tue Feb 11 19:38:52 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA20169 for ipp-outgoing; Tue, 11 Feb 1997 19:37:29 -0500 (EST) Message-Id: <3.0.32.19970211162743.00e6abd0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 11 Feb 1997 16:27:44 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC - Phone conference on 970214 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO As agreed in our SEC meeting on February 7, we will hold a phone conference for the SEC subgroup on Thursday, February 14, at 1pm Pacific time. The conference number is: 1-800-857 5607 with passcode: cmanros We will follow up on our previous discussions, and probably move on to discuss more about commercial transactions, which we never got to talk about in detail in the previous meeting. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Tue Feb 11 20:38:37 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA20616 for ipp-outgoing; Tue, 11 Feb 1997 20:29:01 -0500 (EST) Message-Id: <3.0.32.19970211172843.00de6a50@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 11 Feb 1997 17:28:43 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC - Telephone conference 970213 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Ooops, wrong date, Thursday is the 13th. ---- As agreed in our SEC meeting on February 7, we will hold a phone conference for the SEC subgroup on Thursday, February 13, at 1pm Pacific time. The conference number is: 1-800-857 5607 with passcode: cmanros We will follow up on our previous discussions, and probably move on to discuss more about commercial transactions, which we never got to talk about in detail in the previous meeting. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Tue Feb 11 20:53:52 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA21040 for ipp-outgoing; Tue, 11 Feb 1997 20:52:11 -0500 (EST) Message-Id: <3.0.32.19970211175323.00de2e68@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 11 Feb 1997 17:53:26 PST To: Harald.T.Alvestrand@uninett.no, moore@cs.utk.edu From: Carl-Uno Manros Subject: IPP> ADM - What happened to our IPP Charter? Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Harald and Keith, I start getting eager to learn if we will be chartered as a WG soon. Our plan, according to the draft charter, is to have a set of pretty good Internet-Drafts ready for discussion and review in the next IETF meeting. Assuming that the documents have to be in by mid-March, I will need to go through the proper process of checking for consensus pretty soon. I have held back on this waiting the WG status to become active, but I cannot do that much longer... Best regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Tue Feb 11 23:03:53 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA21496 for ipp-outgoing; Tue, 11 Feb 1997 23:03:10 -0500 (EST) Message-ID: <3301410F.4819@parc.xerox.com> Date: Tue, 11 Feb 1997 20:03:27 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: "Scott A. Isaacson" CC: ipp@pwg.org Subject: Re: IPP> New HTTP Methods vs POST -Reply References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Scott A. Isaacson wrote: > I think that we should keep with the name IPP and keep it as simple as > possible. The print protocol (semantics and operations) should basically > be the same across all mappings on any transport(s). In other words > there could be a mapping of IPP on: > > 1. HTTP 1.0 POST > 2. HTTP 1.1 POST (taking advantage of new 1.1 underlying features) > 3. HTTP 1.x extended methods > 4. Raw TCP > 5. Internet RPCs > 6. IIOP > 7. etc, etc. > > In other words, lets not create two things, but one thing. Call it IPP. Then > as Randy and you have pointed out in later (than this) emails, propose > multiple "mapping documents". > > I am still in favor of #1 above (HTTP 1.0 POST) or protoptyping and > reasonable first step deployment. Maybe we will learn more as we go > through the first step which will make additional choices more clear. 1 vs 2: If you're going to use HTTP, use HTTP/1.1. POST in HTTP/1.0 had a problem because of the requirement for content-length: you'd have to spool the entire print job locally in order to submit it reliably. 2 vs 3: Do what makes sense. There's no value in "first 2, then 3". So if 2 works, keep it, and if it doesn't work, don't try to do it first. 4: I think people were seriously suggesting that IPP be an option on top of LPR. 5 & 6: IIOP is a kind of Internet RPC. Actually, HTTP is a kind of Internet RPC too, so it's the same. From ipp-archive Tue Feb 11 23:08:58 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA21736 for ipp-outgoing; Tue, 11 Feb 1997 23:06:35 -0500 (EST) Message-ID: <330141D9.532A@parc.xerox.com> Date: Tue, 11 Feb 1997 20:06:49 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: Carl-Uno Manros CC: ipp@pwg.org Subject: Re: IPP> SEC - Minutes from SEC meeting in El Segundo, February 7 References: <3.0.32.19970210091410.013da440@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO The most important NEW security issues (where you don't just have to pick which thing to do) are: how to accomplish third-party credentials when doing print-by-reference, and secondly, how to establish credentials for job control after job submission even when there isn't authentication. I didn't see those in your security list, but maybe I missed them. From ipp-archive Wed Feb 12 04:53:58 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA22437 for ipp-outgoing; Wed, 12 Feb 1997 04:49:17 -0500 (EST) X-Mailer: exmh version 1.6.9 8/22/96 From: Harald.T.Alvestrand@uninett.no To: Carl-Uno Manros cc: moore@cs.utk.edu, ipp@pwg.org Subject: Re: IPP> ADM - What happened to our IPP Charter? In-reply-to: Your message of "Tue, 11 Feb 1997 17:53:26 PST." <3.0.32.19970211175323.00de2e68@garfield> Date: Wed, 12 Feb 1997 10:49:22 +0100 Message-ID: <13479.855740962@dale.uninett.no> MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: first-class Status: RO We're working on some details. The main thrust of the charter seems good now; it will in fact be easier for the IESG to evaluate the charter if it's backed up by some fairly recent and reasonable drafts, so there's every reason to go on working on the drafts. (Those of you who were present in San Jose will remember my opinion on the batch presented there....) Harald A From ipp-archive Wed Feb 12 10:34:01 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA23001 for ipp-outgoing; Wed, 12 Feb 1997 10:32:43 -0500 (EST) From: rdebry@us.ibm.com X400-Originator: rdebry@us.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100004548261000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100004548261000002*@MHS> To: Subject: Re: IPP> New HTTP Methods vs POST -Reply Date: Wed, 12 Feb 1997 10:31:11 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 1 vs 2: If you're going to use HTTP, use HTTP/1.1. POST in HTTP/1.0 had a problem because of the requirement for content-length: you'd have to spool the entire print job locally in order to submit it reliably. The protocol proposal that I made at the PWG meeting would work with either HTTP/1.0 or 1.1 since it provides for sending chunks of data in a way that is independent of the underlying protocol. 2 vs 3: Do what makes sense. There's no value in "first 2, then 3". So if 2 works, keep it, and if it doesn't work, don't try to do it first. I personally favor using HTTP Post, just because we know that the print server can be written on top of existing HTTP Servers using CGI or Server side APIs. However, I'd like to see someone provide some help with this by helping us to understand performance and load issues. If there is significant performance or load advantage to new HTTP methods, then I'd propose we look seriously at that option. 4: I think people were seriously suggesting that IPP be an option on top of LPR. I did not hear this proposal. What I heard was a proposal to put IPP directly on top of TCP/IP. From ipp-archive Wed Feb 12 12:49:04 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA23602 for ipp-outgoing; Wed, 12 Feb 1997 12:46:28 -0500 (EST) Message-Id: <3.0.32.19970212093325.00e544a0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 12 Feb 1997 09:33:27 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC - Re: Minutes from SEC meeting in El Segundo, February 7 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO At 08:06 PM 2/11/97 PST, Larry Masinter wrote: >The most important NEW security issues (where you don't just >have to pick which thing to do) are: how to accomplish >third-party credentials when doing print-by-reference, and >secondly, how to establish credentials for job control >after job submission even when there isn't authentication. > >I didn't see those in your security list, but maybe I missed >them. > Larry, in answer to your first concern, we did discuss that briefly, but decided that the retrieval of the file is not part of the actual Internet Printing Protocol, it is determined by the URL of the reference. We therefore left that out of the initial discussion, but even so, it would be nice to find a solution to the problem in general. Do you have any proposal on where we might find one? I am not quite sure I understand quite what you mean with your second comment. Users typically only have access to their own jobs, and they will be given a job-id from the "printer" for each job they submit. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Wed Feb 12 13:19:03 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA23960 for ipp-outgoing; Wed, 12 Feb 1997 13:18:18 -0500 (EST) From: rdebry@us.ibm.com X400-Originator: rdebry@us.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100004559348000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100004559348000002*@MHS> To: Subject: IPP>MOD - job attributes for public printers Date: Wed, 12 Feb 1997 13:16:46 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 At last weeks security meeting in El Segundo, we discussed several possible configurations for printing, one which was a client behind one firewall and the printer behind another, different firewall. For example, I want to send a copy of an internet draft to a public printer at Xerox and have Carl-Uno pick it up. It seems that this kind of operation requires some additional job attributes, like o who the output is for o what that person's address is o how to deliver it o instructions to notify the intended recipient when print is complete o etc ... any thoughts??? From ipp-archive Wed Feb 12 13:34:05 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA24303 for ipp-outgoing; Wed, 12 Feb 1997 13:32:13 -0500 (EST) Message-Id: <3.0.32.19970212103309.017e2e20@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 12 Feb 1997 10:33:10 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> PRO - Transaction protocol anyone? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO FYI, A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transaction Internet Protocol Author(s) : J. Lyon, K. Evans, J. Klein Filename : draft-lyon-itp-nodes-01.txt Pages : 17 Date : 02/10/1997 In many applications where different nodes cooperate on some work, there is a need to guarantee that the work happens atomically. That is, each node must reach the same conclusion as to whether the work is to be completed, even in the face of failures. This document proposes a simple, easily-implemented protocol for achieving this end. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lyon-itp-nodes-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-lyon-itp-nodes-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-lyon-itp-nodes-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --- Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Wed Feb 12 13:54:04 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA24671 for ipp-outgoing; Wed, 12 Feb 1997 13:53:03 -0500 (EST) Message-ID: <3302104D.C86@parc.xerox.com> Date: Wed, 12 Feb 1997 10:47:41 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Macintosh; I; 68K) MIME-Version: 1.0 To: rdebry@us.ibm.com CC: ipp@pwg.org Subject: Re: IPP>MOD - job attributes for public printers References: <5030100004559348000002*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO rdebry@us.ibm.com wrote: > At last weeks security meeting in El Segundo, we discussed several possible > configurations for printing, one which was a client behind one firewall and the > printer behind another, different firewall. For example, I want to send a copy > of an internet draft to a public printer at Xerox and have Carl-Uno pick it up. > > It seems that this kind of operation requires some additional job attributes, > like > o who the output is for > o what that person's address is > o how to deliver it > o instructions to notify the intended recipient when print is complete > o etc ... > > any thoughts??? Yes. We're calling this "Internet Far Access Xerox", or just "Internet FAX" for short. From ipp-archive Wed Feb 12 15:39:07 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA25233 for ipp-outgoing; Wed, 12 Feb 1997 15:36:00 -0500 (EST) Message-Id: <3.0.32.19970212123655.00e329d8@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 12 Feb 1997 12:36:55 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> MOD - Re: job attributes for public printers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO At 10:16 AM 2/12/97 PST, you wrote: >Classification: >Prologue: >Epilogue: Roger K deBry >Senior Techncial Staff Member >Architecture and Technology >IBM Printing Systems >email: rdebry@us.ibm.com >phone: 1-303-924-4080 > >At last weeks security meeting in El Segundo, we discussed several possible >configurations for printing, one which was a client behind one firewall and the >printer behind another, different firewall. For example, I want to send a copy >of >an internet draft to a public printer at Xerox and have Carl-Uno pick it up. > >It seems that this kind of operation requires some additional job attributes, >like >o who the output is for >o what that person's address is >o how to deliver it >o instructions to notify the intended recipient when print is complete >o etc ... > >any thoughts??? > Roger, let us not get carried away with a whole new set of attributes to solve this scenario. I suggest that the following two IPP features would cover it: 1) Have an attribute which contains a text to be displayed on the banner page (which most network printers already have). 2) Allow for multiple addresses in a "send notifications to" attribute, which would allow not only the owner of the job, but also others to be notified, of success or failure events. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Wed Feb 12 15:49:05 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA25685 for ipp-outgoing; Wed, 12 Feb 1997 15:48:40 -0500 (EST) Message-Id: <3.0.32.19970212124946.00de4668@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 12 Feb 1997 12:49:47 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> MOD - Reminder about I18N Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO This is a reminder to the Model & Semantics subgroup not to forget about the international aspects of the specification. We need to make sure that the semantics allow for international use (the default character set in IETF is ISO 10646). I suggest that all text fields, that are meant to be read by humans, should allow for transparent use of 10646 characters. My assumption is that we would not require every implementation of client and server side of the protocol to support all the language variants that 10646 contains, but it should at least be possible for a client that can produce a Japanese text to send operations to a server that supports Japanese without restrictions. We may also want to include multi-valued job and printer attributes, which contains information about which 10646 subsets the server supports. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Wed Feb 12 15:59:06 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA26027 for ipp-outgoing; Wed, 12 Feb 1997 15:57:49 -0500 (EST) Message-Id: <3.0.32.19970212125844.008ed358@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 12 Feb 1997 12:58:45 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> PRO & MOD - Need to synchronize thought on operations Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Some of the discussion lately has been about the possibility to split up the Print operation into several steps (inspired by the MS approach presented last week). I just want us to be clear that if we want to do this, it has consequences on the operations that the Model group will define (we will need more operations). As a sideline, it will probably make the solution less workable over SMTP (for those of you who still think that that is a good idea). It will also influence any further discussion on the use of MIME types (we will need separate MIME types for what goes into each of the "smaller" operations). Therefore, I think that this decision is urgent, as it will influence a number of other text parts in other documents, and we should aim to get closure on this pretty soon. Comments? Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Wed Feb 12 16:34:09 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA26448 for ipp-outgoing; Wed, 12 Feb 1997 16:30:38 -0500 (EST) Message-ID: <3302349D.58FF@sharplabs.com> Date: Wed, 12 Feb 1997 13:22:37 -0800 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> ftp://ietf.org/internet...t-goldsmith-utf7-01.txt Content-Type: multipart/mixed; boundary="------------392878394C74" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO This is a multi-part message in MIME format. --------------392878394C74 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ftp://ietf.org/internet-drafts/draft-goldsmith-utf7-01.txt -- Randy Turner Network Architect Sharp Laboratories of America rturner@sharplabs.com --------------392878394C74 Content-Type: text/plain; charset=us-ascii; name="draft-goldsmith-utf7-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-goldsmith-utf7-01.txt" Network Working Group D. Goldsmith Internet Draft Apple Computer, Inc. Expires: 3 August 1997 M. Davis Will obsolete: RFC 1642 Taligent, Inc. 3 February 1997 UTF-7 A Mail-Safe Transformation Format of Unicode Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this document is unlimited. Please send comments to the author at . This document is intended to become an experimental RFC. Abstract The Unicode Standard, version 2.0, and ISO/IEC 10646-1:1993(E) (as amended) jointly define a character set (hereafter referred to as Unicode) which encompasses most of the world's writing systems. However, Internet mail (STD 11, RFC 822) currently supports only 7- bit US ASCII as a character set. MIME (RFC 1521 and RFC 1522) extends Internet mail to support different media types and character sets, and thus could support Unicode in mail messages. MIME neither defines Unicode as a permitted character set nor specifies how it would be encoded, although it does provide for the registration of additional character sets over time. This document describes a transformation format of Unicode that contains only 7-bit ASCII characters and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire. It also specifies how this transformation format is used in the context of MIME and RFC 1641, "Using Unicode with MIME". Motivation Although other transformation formats of Unicode exist and could conceivably be used in this context (most notably UTF-8, also known as UTF-2 or UTF-FSS), they suffer the disadvantage that they use octets in the range decimal 128 through 255 to encode Unicode characters outside the US-ASCII range. Thus, in the context of mail, those octets must themselves be encoded. This requires putting text through two successive encoding processes, and leads to a significant expansion of characters outside the US-ASCII range, putting non- English speakers at a disadvantage. For example, using UTF-8 together with the Quoted-Printable content transfer encoding of MIME represents US-ASCII characters in one octet, but other characters may require up to nine octets. Overview UTF-7 encodes Unicode characters as US-ASCII, together with shift sequences to encode characters outside that range. For this purpose, one of the characters in the US-ASCII repertoire is reserved for use as a shift character. Many mail gateways and systems cannot handle the entire US-ASCII character set (those based on EBCDIC, for example), and so UTF-7 contains provisions for encoding characters within US-ASCII in a way that all mail systems can accomodate. UTF-7 should normally be used only in the context of 7 bit transports, such as mail and news. In other contexts, straight Unicode or UTF-8 is preferred. See RFC 1641, "Using Unicode with MIME" for the overall specification on usage of Unicode transformation formats with MIME. Definitions First, the definition of Unicode: The 16 bit character set Unicode is defined by "The Unicode Standard, Version 2.0". This character set is identical with the character repertoire and coding of the international standard ISO/IEC 10646-1:1993(E); Coded Representation Form=UCS-2; Subset=300; Implementation Level=3, including the first 7 amendments to 10646 plus editorial corrections. Note. Unicode 2.0 further specifies the use and interaction of these character codes beyond the ISO standard. However, any valid 10646 sequence is a valid Unicode sequence, and vice versa; Unicode supplies interpretations of sequences on which the ISO standard is silent as to interpretation. Next, some handy definitions of US-ASCII character subsets: Set D (directly encoded characters) consists of the following characters (derived from RFC 1521, Appendix B): the upper and lower case letters A through Z and a through z, the 10 digits 0-9, and the following nine special characters (note that "+" and "=" are omitted): Character ASCII & Unicode Value (decimal) ' 39 ( 40 ) 41 , 44 - 45 . 46 / 47 : 58 ? 63 Set O (optional direct characters) consists of the following characters (note that "\" and "~" are omitted): Character ASCII & Unicode Value (decimal) ! 33 " 34 # 35 $ 36 % 37 & 38 * 42 ; 59 < 60 = 61 > 62 @ 64 [ 91 ] 93 ^ 94 _ 95 ' 96 { 123 | 124 } 125 Rationale. The characters "\" and "~" are omitted because they are often redefined in variants of ASCII. Set B (Modified Base 64) is the set of characters in the Base64 alphabet defined in RFC 1521, excluding the pad character "=" (decimal value 61). Rationale. The pad character = is excluded because UTF-7 is designed for use within header fields as set forth in RFC 1522. Since the only readable encoding in RFC 1522 is "Q" (based on RFC 1521's Quoted- Printable), the "=" character is not available for use (without a lot of escape sequences). This was very unfortunate but unavoidable. The "=" character could otherwise have been used as the UTF-7 escape character as well (rather than using "+"). Note that all characters in US-ASCII have the same value in Unicode when zero-extended to 16 bits. UTF-7 Definition A UTF-7 stream represents 16-bit Unicode characters in 7-bit US-ASCII as follows: Rule 1: (direct encoding) Unicode characters in set D above may be encoded directly as their ASCII equivalents. Unicode characters in Set O may optionally be encoded directly as their ASCII equivalents, bearing in mind that many of these characters are illegal in header fields, or may not pass correctly through some mail gateways. Rule 2: (Unicode shifted encoding) Any Unicode character sequence may be encoded using a sequence of characters in set B, when preceded by the shift character "+" (US-ASCII character value decimal 43). The "+" signals that subsequent octets are to be interpreted as elements of the Modified Base64 alphabet until a character not in that alphabet is encountered. Such characters include control characters such as carriage returns and line feeds; thus, a Unicode shifted sequence always terminates at the end of a line. As a special case, if the sequence terminates with the character "-" (US-ASCII decimal 45) then that character is absorbed; other terminating characters are not absorbed and are processed normally. Note that if the first character after the shifted sequence is "-" then an extra "-" must be present to terminate the shifted sequence so that the actual "-" is not itself absorbed. Rationale. A terminating character is necessary for cases where the next character after the Modified Base64 sequence is part of character set B or is itself the terminating character. It can also enhance readability by delimiting encoded sequences. Also as a special case, the sequence "+-" may be used to encode the character "+". A "+" character followed immediately by any character other than members of set B or "-" is an ill-formed sequence. Unicode is encoded using Modified Base64 by first converting Unicode 16-bit quantities to an octet stream (with the most significant octet first). Surrogate pairs (UTF-16) are converted by treating each half of the pair as a separate 16 bit quantity (i.e., no special treatment). Text with an odd number of octets is ill-formed. Rationale. ISO/IEC 10646-1:1993(E) specifies that when characters in the UCS-2 form are serialized as octets, that the most significant octet appear first. This is also in keeping with common network practice of choosing a canonical format for transmission. Next, the octet stream is encoded by applying the Base64 content transfer encoding algorithm as defined in RFC 1521, modified to omit the "=" pad character. Instead, when encoding, zero bits are added to pad to a Base64 character boundary. When decoding, any bits at the end of the Modified Base64 sequence that do not constitute a complete 16-bit Unicode character are discarded. If such discarded bits are non-zero the sequence is ill-formed. Rationale. The pad character "=" is not used when encoding Modified Base64 because of the conflict with its use as an escape character for the Q content transfer encoding in RFC 1522 header fields, as mentioned above. Rule 3: The space (decimal 32), tab (decimal 9), carriage return (decimal 13), and line feed (decimal 10) characters may be directly represented by their ASCII equivalents. However, note that MIME content transfer encodings have rules concerning the use of such characters. Usage that does not conform to the restrictions of RFC 822, for example, would have to be encoded using MIME content transfer encodings other than 7bit or 8bit, such as quoted-printable, binary, or base64. Given this set of rules, Unicode characters which may be encoded via rules 1 or 3 take one octet per character, and other Unicode characters are encoded on average with 2 2/3 octets per character plus one octet to switch into Modified Base64 and an optional octet to switch out. Example. The Unicode sequence "A." (hexadecimal 0041,2262,0391,002E) may be encoded as follows: A+ImIDkQ. Example. The Unicode sequence "Hi Mom --!" (hexadecimal 0048, 0069, 0020, 004D, 006F, 006D, 0020, 002D, 263A, 002D, 0021) may be encoded as follows: Hi Mom -+Jjo--! Example. The Unicode sequence representing the Han characters for the Japanese word "nihongo" (hexadecimal 65E5,672C,8A9E) may be encoded as follows: +ZeVnLIqe- Use of Character Set UTF-7 Within MIME Character set UTF-7 is safe for mail transmission and therefore may be used with any content transfer encoding in MIME (except where line length and line break restrictions are violated). Specifically, the 7 bit encoding for bodies and the Q encoding for headers are both acceptable. The MIME character set tag is UTF-7. This signifies any version of Unicode equal to or greater than 2.0. Example. Here is a text portion of a MIME message containing the Unicode sequence "Hi Mom !" (hexadecimal 0048, 0069, 0020, 004D, 006F, 006D, 0020, 263A, 0021). Content-Type: text/plain; charset=UTF-7 Hi Mom +Jjo-! Example. Here is a text portion of a MIME message containing the Unicode sequence representing the Han characters for the Japanese word "nihongo" (hexadecimal 65E5,672C,8A9E). Content-Type: text/plain; charset=UTF-7 +ZeVnLIqe- Example. Here is a text portion of a MIME message containing the Unicode sequence "A." (hexadecimal 0041,2262,0391,002E). Content-Type: text/plain; charset=utf-7 A+ImIDkQ. Example. Here is a text portion of a MIME message containing the Unicode sequence "Item 3 is 1." (hexadecimal 0049, 0074, 0065, 006D, 0020, 0033, 0020, 0069, 0073, 0020, 00A3, 0031, 002E). Content-Type: text/plain; charset=UTF-7 Item 3 is +AKM-1. Note that to achieve the best interoperability with systems that may not support Unicode or MIME, when preparing text for mail transmission line breaks should follow Internet conventions. This means that lines should be short and terminated with the proper SMTP CRLF sequence. Unicode LINE SEPARATOR (hexadecimal 2028) and PARAGRAPH SEPARATOR (hexadecimal 2029) should be converted to SMTP line breaks. Ideally, this would be handled transparently by a Unicode-aware user agent. This preparation is not absolutely necessary, since UTF-7 and the appropriate MIME content transfer encoding can handle text that does not follow Internet conventions, but readability by systems without Unicode or MIME will be impaired. See RFC 1521 for an in-depth discussion of mail interoperability issues. Lines should never be broken in the middle of a UTF-7 shifted sequence, since such sequences may not cross line breaks. Therefore, UTF-7 encoding should take place after line breaking. If a line containing a shifted sequence is too long after encoding, a MIME content transfer encoding such as Quoted Printable can be used to encode the text. Another possibility is to perform line breaking and UTF-7 encoding at the same time, so that lines containing shifted sequences already conform to length restrictions. Discussion In this section we will motivate the introduction of UTF-7 as opposed to the alternative of using the existing transformation formats of Unicode (e.g., UTF-8) with MIME's content transfer encodings. Before discussing this, it will be useful to list some assumptions about character frequency within typical natural language text strings that we use to estimate typical storage requirements: 1. Most Western European languages use roughly 7/8 of their letters from US-ASCII and 1/8 from Latin 1 (ISO-8859-1). 2. Most non-European alphabet-based languages (e.g., Greek) use about 1/6 of their letters from ASCII (since white space is in the 7-bit area) and the rest from their alphabets. 3. East Asian ideographic-based languages (including Japanese) use essentially all of their characters from the Han or CJK syllabary area. 4. Non-directly encoded punctuation characters do not occur frequently enough to affect the results. Notice that current 8 bit standards, such as ISO-8859-x, require use of a content transfer encoding. For comparison with the subsequent discussion, the costs break down as follows (note that many of these figures are approximate since they depend on the exact composition of the text): 8859-x in Base64 Text type Average octets/character All 1.33 8859-x in Quoted Printable Text type Average octets/character US-ASCII 1 Western European 1.25 Other 2.67 Note also that Unicode encoded in Base64 takes a constant 2.67 octets per character. For purposes of comparison, we will look at UTF-8 in Base64 and Quoted Printable, and UTF-7. Also note that fixed overhead for long strings is relative to 1/n, where n is the encoded string length in octets. UTF-8 in Base64 Text type Average octets/character US-ASCII 1.33 Western European 1.5 Some Alphabetics 2.44 All others 4 UTF-8 in Quoted Printable Text type Average octets/character US-ASCII 1 Western European 1.63 Some Alphabetics 5.17 All others 7-9 UTF-7 Text type Average octets/character Most US-ASCII 1 Western European 1.5 All others 2.67+2/n We feel that the UTF-8 in Quoted Printable option is not viable due to the very large expansion of all text except Western European. This would only be viable in texts consisting of large expanses of US- ASCII or Latin characters with occasional other characters interspersed. We would prefer to introduce one encoding that works reasonably well for all users. We also feel that UTF-8 in Base64 has high expansion for non- Western-European users, and is less desirable because it cannot be read directly, even when the content is largely US-ASCII. The base encoding of UTF-7 gives competitive results and is readable for ASCII text. UTF-7 gives results competitive with ISO-8859-x, with access to all of the Unicode character set. We believe this justifies the introduction of a new transformation format of Unicode. As an alternative to use of UTF-7, it is possible to intermix Unicode characters with other character sets using an existing MIME mechanism, the multipart/mixed content type (thanks to Nathaniel Borenstein for pointing this out). For instance (repeating an earlier example): Content-type: multipart/mixed; boundary=foo --foo Content-type: text/plain; charset=us-ascii Hi Mom --foo Content-type: text/plain; charset=UNICODE-2-0 Content-transfer-encoding: base64 Jjo= --foo Content-type: text/plain; charset=us-ascii ! --foo-- Theoretically, this removes the need for UTF-7 in message bodies (multipart may not be used in header fields). However, we feel that as use of the Unicode character set becomes more widespread, intermittent use of specialized Unicode characters (such as dingbats and mathematical symbols) will occur, and that text will also typically include small snippets from other scripts, such as Cyrillic, Greek, or East Asian languages (anything in the Roman script is already handled adequately by existing MIME character sets). Although the multipart technique works well for large chunks of text in alternating character sets, we feel it does not adequately support the kinds of uses just discussed, and so we still believe the introduction of UTF-7 is justified. Summary The UTF-7 encoding allows Unicode characters to be encoded within the US-ASCII 7 bit character set. It is most effective for Unicode sequences which contain relatively long strings of US-ASCII characters interspersed with either single Unicode characters or strings of Unicode characters, as it allows the US-ASCII portions to be read on systems without direct Unicode support. UTF-7 should only be used with 7 bit transports such as mail and news. In other contexts, use of straight Unicode or UTF-8 is preferred. Acknowledgements Many thanks to the following people for their contributions, comments, and suggestions. If we have omitted anyone it was through oversight and not intentionally. Glenn Adams Harald T. Alvestrand Nathaniel Borenstein Lee Collins Jim Conklin Dave Crocker Steve Dorner Dana S. Emery Ned Freed Kari E. Hurtta John H. Jenkins John C. Klensin Valdis Kletnieks Keith Moore Masataka Ohta Einar Stefferud Erik M. van der Poel Appendix A -- Examples Here is a longer example, taken from a document originally in Big5 code. It has been condensed for brevity. There are two versions: the first uses optional characters from set O (and so may not pass through some mail gateways), and the second does not. Content-type: text/plain; charset=utf-7 Below is the full Chinese text of the Analects (+itaKng-). The sources for the text are: "The sayings of Confucius," James R. Ware, trans. +U/BTFw-: +ZYeB9FH6ckh5Pg-, 1980. (Chinese text with English translation) +Vttm+E6UfZM-, +W4tRQ066bOg-, +UxdOrA-: +Ti1XC2b4Xpc-, 1990. "The Chinese Classics with a Translation, Critical and Exegetical Notes, Prolegomena, and Copius Indexes," James Legge, trans., Taipei: Southern Materials Center Publishing, Inc., 1991. (Chinese text with English translation) Big Five and GB versions of the text are being made available separately. Neither the Big Five nor GB contain all the characters used in this text. Missing characters have been indicated using their Unicode/ISO 10646 code points. "U+-" followed by four hexadecimal digits indicates a Unicode/10646 code (e.g., U+-9F08). There is no good solution to the problem of the small size of the Big Five/GB character sets; this represents the solution I find personally most satisfactory. (omitted...) I have tried to minimize this problem by using variant characters where they were available and the character actually in the text was not. Only variants listed as such in the +XrdxmVtXUXg- were used. (omitted...) John H. Jenkins +TpVPXGBG- jenkins@apple.com 5 January 1993 (omitted...) Content-type: text/plain; charset=utf-7 Below is the full Chinese text of the Analects (+itaKng-). The sources for the text are: +ACI-The sayings of Confucius,+ACI- James R. Ware, trans. +U/BTFw-: +ZYeB9FH6ckh5Pg-, 1980. (Chinese text with English translation) +Vttm+E6UfZM-, +W4tRQ066bOg-, +UxdOrA-: +Ti1XC2b4Xpc-, 1990. +ACI-The Chinese Classics with a Translation, Critical and Exegetical Notes, Prolegomena, and Copius Indexes,+ACI- James Legge, trans., Taipei: Southern Materials Center Publishing, Inc., 1991. (Chinese text with English translation) Big Five and GB versions of the text are being made available separately. Neither the Big Five nor GB contain all the characters used in this text. Missing characters have been indicated using their Unicode/ISO 10646 code points. +ACI-U+-+ACI- followed by four hexadecimal digits indicates a Unicode/10646 code (e.g., U+-9F08). There is no good solution to the problem of the small size of the Big Five/GB character sets+ADs- this represents the solution I find personally most satisfactory. (omitted...) I have tried to minimize this problem by using variant characters where they were available and the character actually in the text was not. Only variants listed as such in the +XrdxmVtXUXg- were used. (omitted...) John H. Jenkins +TpVPXGBG- jenkins+AEA-apple.com 5 January 1993 (omitted...) Security Considerations Security issues are not discussed in this memo. References [UNICODE 2.0] "The Unicode Standard, Version 2.0", The Unicode Consortium, Addison-Wesley, 1996. ISBN 0-201-48345-9. [ISO 10646] ISO/IEC 10646-1:1993(E) Information Technology--Universal Multiple-octet Coded Character Set (UCS). See also amendments 1 through 7, plus editorial corrections. [RFC-1641] Goldsmith, D., and M. Davis, "Using Unicode with MIME", RFC 1641, Taligent, Inc., July 1994. [US-ASCII] Coded Character Set--7-bit American Standard Code for Information Interchange, ANSI X3.4-1986. [ISO-8859] Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987. Part 2: Latin alphabet No. 2, ISO 8859-2, 1987. Part 3: Latin alphabet No. 3, ISO 8859-3, 1988. Part 4: Latin alphabet No. 4, ISO 8859-4, 1988. Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988. Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987. Part 7: Latin/Greek alphabet, ISO 8859-7, 1987. Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988. Part 9: Latin alphabet No. 5, ISO 8859-9, 1990. [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982. [RFC-1521] Borenstein N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September 1993. [RFC-1522] Moore, K., "Representation of Non-Ascii Text in Internet Message Headers" RFC 1522, University of Tennessee, September 1993. Authors' Addresses David Goldsmith Apple Computer, Inc. 2 Infinite Loop, MS: 302-2IS Cupertino, CA 95014 Phone: 408-974-1957 Fax: 408-862-4566 EMail: goldsmith@apple.com Mark Davis Taligent, Inc. 10201 N. DeAnza Blvd. Cupertino, CA 95014-2233 Phone: 408-777-5116 Fax: 408-777-5081 EMail: mark_davis@taligent.com --------------392878394C74-- From ipp-archive Wed Feb 12 17:39:08 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA26882 for ipp-outgoing; Wed, 12 Feb 1997 17:36:52 -0500 (EST) From: rdebry@us.ibm.com X400-Originator: rdebry@us.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100004574618000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100004574618000002*@MHS> To: Subject: IPP> PRO & MOD - Need to synchronize thought on operations Date: Wed, 12 Feb 1997 17:35:18 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 Carl-Uno wrote: Some of the discussion lately has been about the possibility to split up the Print operation into several steps (inspired by the MS approach presented last week). I just want us to be clear that if we want to do this, it has consequences on the operations that the Model group will define (we will need more operations). As a sideline, it will probably make the solution less workable over SMTP (for those of you who still think that that is a good idea). It will also influence any further discussion on the use of MIME types (we will need separate MIME types for what goes into each of the "smaller" operations). Therefore, I think that this decision is urgent, as it will influence a number of other text parts in other documents, and we should aim to get closure on this pretty soon. I've never been much a fan of MIME types or using SMTP, so I don't have any problems with this change. I think it can be done with minimal impact to the proposal presented last week in San Jose, and will not require any additional operations. From ipp-archive Wed Feb 12 19:29:07 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA27576 for ipp-outgoing; Wed, 12 Feb 1997 19:24:06 -0500 (EST) X-Sender: chansler@mail-303 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Feb 1997 16:26:40 -0800 To: ipp@pwg.org From: Robert Chansler Subject: Re: IPP> PRO & MOD - Need to synchronize thought on operations Sender: ipp-owner@pwg.org Precedence: first-class Status: RO It is easy to understand how the Windows printing API lead to an implementation like that informatively presented by Babak last week. But even within the Windows environment, I do not understand how the extra protocol complexity is either necessary for the implementation or substantially advantageous for the implementation. My own prejudice would favor a protocol based upon a single client request and server response, without requiring either the server or client to maintain persistent state about an ongoing transaction. Not only would such a protocol facilitate embedding in alternate transport methods (such as mail, as mentioned previously), a simple protocol would facilitate implementations where servers dispatched client requests to peers or other surrogates for processing. Also I might suppose that the simpler protocol would be more robust in practice. Before moving in the direction of a more complex transaction-oriented protocol, some champion needs to assume the responsibility for making the convincing argument for inclusion in the protocol rationale. -------------------------- Robert J. Chansler chansler@adobe.com Adobe Systems Incorporated Mailstop P 8 303 Almaden Blvd. San Jose, CA 95110-2702 408 536.2295 Fax 408 537.8037 From ipp-archive Wed Feb 12 22:49:09 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA28281 for ipp-outgoing; Wed, 12 Feb 1997 22:44:14 -0500 (EST) Message-ID: <33028E12.2F1D@parc.xerox.com> Date: Wed, 12 Feb 1997 19:44:18 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: Carl-Uno Manros CC: ipp@pwg.org Subject: Re: IPP> SEC - Re: Minutes from SEC meeting in El Segundo, February 7 References: <3.0.32.19970212093325.00e544a0@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I was imagining that you could come up with a security paradigm that the authorization to modify a job once submitted might be independent of the authorization and authentication necessary to submit the job in the first place. That is, the submission process itself might return some credentials for subsequent job manipulation operations. I'm worried that unless we make progress on authorization, we'll either have a free-for-all (no security) or else a lack of interoperability (there is no global authentication domain that works across the Internet). Larry From ipp-archive Wed Feb 12 23:14:09 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA28650 for ipp-outgoing; Wed, 12 Feb 1997 23:12:26 -0500 (EST) Message-ID: <330294B6.5683@parc.xerox.com> Date: Wed, 12 Feb 1997 20:12:38 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: rdebry@us.ibm.com, ipp@pwg.org Subject: Re: IPP>MOD - job attributes for public printers References: <5030100004559348000002*@MHS> <3302104D.C86@parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Larry Masinter wrote: > Yes. We're calling this "Internet Far Access Xerox", or just "Internet > FAX" for short. This was an answer in jest, but the problem of through-the-firewall delivery of print jobs is exactly what the internet fax group is trying to deal with. http://www.imc.org/ietf-fax/ From ipp-archive Thu Feb 13 10:49:15 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA29972 for ipp-outgoing; Thu, 13 Feb 1997 10:48:34 -0500 (EST) Message-Id: <199702131549.AA12423@interlock.lexmark.com> To: "ipp%pwg.org" From: Don Wright Date: 13 Feb 97 10:42:29 EST Subject: IPP> IPP Conference Call Minutes for 2/12/97 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="-- next item ----" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO This is the preamble of an RFC-1341 encoded, mixed message. ---- next item ---- Content-Type: Text/Plain I have placed the ipp conference call minutes for 2/12/97 on the ftp server as follow in: ftp://ftp.pwg.org/pub/pwg/ipp/minutes The files are: 970212-ipp-conference-call.pdf 970212-ipp-conference-call.txt Attached, for the computationally moribund, is the old, ugly text version...... ----- ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* ---- next item ---- Content-Type: Application/X-Lotus-Notes; Name="970212~1.TXT" Content-Transfer-Encoding: UUEncode begin 644 970212~1.TXT M26YT97)N970@4')I;G1I;F<@4')O:F5C=`T*0V]N9F5R96YC92!#86QL("T@ M1F5B2!$ M;WII97(@+2!135,-"E1O;2!(87-T:6YG2!!9&0@:&EG:"UL979E;"!S8V5N87)I M;W,@=&\@;6%I;B!D;V-U;65N="!B971W965N(&5X:7-T:6YG(#,@)B`T(`T* M("!!9&0@9&5T86EL960@F%T:6]N(&EN(%)%42!D;V-U;65N="!/2RP@36]D96P@ M9&]C=6UE;G1S(&YE961S(&UO6]U('-P M;&ET('1H92!P71E(&-O=6YT M#0H@($]N92!O9B!T:&4@8V]N2!T;R!C86YC96P@82!J;V(L(&5T8RX-"B`@5V]U;&0@1&EG:71A M;"!#97)T:69I8V%T92!B92!N96-E'0@8V]N9F5R96YC92!C86QL M#0H-"@T*365E=&EN9R!A9&IO=7)N960@870@-3HS,"!032!%4U0N#0H-"@T* M"4EN=&5R;F5T(%!R:6YT:6YG(%!R;VIE8W0-"@T*,#(O,3(O.3<@0V]N9F5R :96YC92!#86QL("!-:6YU=&5S"3(-"@T*#0IE ` end ---- next item ------ From ipp-archive Thu Feb 13 12:44:18 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA00570 for ipp-outgoing; Thu, 13 Feb 1997 12:39:43 -0500 (EST) Message-Id: <3.0.32.19970213093948.00e11c30@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 13 Feb 1997 09:39:49 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC - Re: Minutes from SEC meeting in El Segundo, February 7 Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO At 07:44 PM 2/12/97 PST, Larry Masinter wrote: >I was imagining that you could come up with a security >paradigm that the authorization to modify a job once >submitted might be independent of the authorization and >authentication necessary to submit the job in the first place. >That is, the submission process itself might return some >credentials for subsequent job manipulation operations. > >I'm worried that unless we make progress on authorization, >we'll either have a free-for-all (no security) or else a lack >of interoperability (there is no global authentication domain >that works across the Internet). > >Larry > Larry, can I just point out that the IPP project has no intension to try to solve the overall security problems on the Internet, that should be left to the numerous groups, in the IETF and elsewhere, already working on security. What are trying to do is to evaluate which of the existing or emerging security solutions could be used in combination with IPP. Authentication schemes are likely to work in intranet environments now, and might work over the global Internernet whenever the security groups have found a solution. I am also not in favour of inventing any specific security paradigm for IPP. Hopefully the IPP will inspire some of the security folks to concentrate on better security features to support it. For now, I think we should limit ourselves to express requirements, in areas where there are no suitable security solutions at hand. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Thu Feb 13 14:44:17 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA01443 for ipp-outgoing; Thu, 13 Feb 1997 14:44:14 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 13 Feb 1997 12:36:59 -0700 From: "Scott A. Isaacson" To: ipp@pwg.org Subject: IPP> MOD - 2/14 Telecon Sender: ipp-owner@pwg.org Precedence: first-class Status: RO We will have a Model group teleconference on Friday 2/14. We need to go over Bob's new doc and issues Scott Confirmation number: 313181 Call in Toll-Free number: 800-967-7147 Friday, 2/14/97 2:00 - 4:00 Mountain Time 15 People Title: Scott Isaacson ************************************************************ 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: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Thu Feb 13 21:59:22 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA03170 for ipp-outgoing; Thu, 13 Feb 1997 21:57:01 -0500 (EST) Date: Thu, 13 Feb 1997 18:55:40 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199702140255.SAA11479@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP> MOD - new version 1.2 X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have just downloaded the new version. The documents are ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-1.2-rev.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-1.2-rev.ps The revision are against 1.0, though the ones since 1.1 are in a different color. If you have MS Word you can uses the revision tool to produce a diff of the two files. The main things to look for: the table of contents reflects the document, so it is a good place to see the attribute organization. some changes in the operations area. a few new comments on adornments. attributes rearranged and grouped according to previous discussions. I forgot to put in an issue for printer-state which Tom and I discussed but did not reach resolution. Bob Herriot From ipp-archive Fri Feb 14 09:49:28 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA04331 for ipp-outgoing; Fri, 14 Feb 1997 09:45:46 -0500 (EST) From: rdebry@us.ibm.com X400-Originator: rdebry@us.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100004715767000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100004715767000002*@MHS> To: Subject: IPP>REQ Scenarios posted Date: Fri, 14 Feb 1997 09:43:55 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 I just posted an updated version of the scenarios. This is the .doc file that I sent to Don Wright for inclusion in the requirements document. You should note that it is not a one to one translation of the previous charts. I have updated some of the scenarios and renumbered them for the formal requirements document. It is at ftp.pwg.org/pub.pwg/ipp/new_REQ/scenario-text-format.doc From ipp-archive Fri Feb 14 13:24:32 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA05158 for ipp-outgoing; Fri, 14 Feb 1997 13:19:33 -0500 (EST) Message-Id: <3.0.32.19970214094345.017f9e38@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 14 Feb 1997 09:43:46 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC - Minutes from telephone conference 970213 Cc: asad@netscape.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO SEC subgroup - Minutes of phone call 2/13/97 on call were: Roger deBry (notetaker) Carl-Uno Manros Xavier Riley Steve Okamoto Daniel Manchala Jerry Hadsell Notes on e-mail: Larry Masinter has suggested that we should look at the case where we retrieve something based on reference. We swept this under the rug in previous discussion because we were not sure that pulling would be part of IPP. Larry wanted to see some type of credentials to use in this case. He also suggested that we use similar credentials for subsequent print operations such as looking at print queues. Another example would be sending notification to a third party. Requirements We discussed how to get to a succinct statement of requirements. Jerry Hadsell will be talking about IPP at IBM's security architecture board next week and wanted a clear set of requirements to talk about. We will assume the picture that was produced last week in El Segundo describes all of the combinations we need to consider for inside and outside of firewalls. Roger deBry will post the latest scenarios to the ftp site, they contain updates which reflect many of the security discussion we talked about last week. Jerry asked several clarification questions which were discussed. Is Printer admin part of current activity? Answer - in IPP phase two. Can we distribute to multiple printers? . Answer - no Can we pass additional attributes not defined in IPP? Answer - yes, but protocol will define how What about charging for printing - is it in current scope? Answer - maybe, have yet to define, many aspects Would be possible to use X.509 certificates to handle many payment schemes. Is control of content outside scope of work, e.g. copyright and integrity issues? Answer - need integrity Does SSL provide integrity - yes but at message level not content level. If a client can get to a printer, can he print anything he wants? Answer - yes at this point. Where is a good source of information on SET? Carl-Uno referred to an article on smart cards and SET (PC Week February 10). It contains references. Quite a bit of this is being discussed in W3C. Xavier will mail out further pointers to SET. Jerry said that the industry is headed toward a framework that handles many different payment types, including e-cash, e-cheque, etc. Don't want to be dependent upon browsers, so if there is technology that we need, e.g. SSL v3, that we can only find in browsers, then we ought to be cautious about using them right away. Same applies to payment schemes. May want to consider the ability to carry along some credentials in IPP that is independent of the outer security or payment protocol. Xavier will mail out information about available SSL v3 software. Next call will be Thursday February the 20th. Xerox will arrange. Jerry will try to have feedback from Security architecture board by then. Need to think about what security stuff will be available on the platforms we implement IPP on, since implementations will want to use existing security frameworks. Don't want to have to write security from scratch. Need especially to identify what's available for prototyping. Homework assignments: Identify tools we think we need? What platforms are they on? HTTP 1.1 might provide what we need for a first version. Xerox will look at RFCs 2068 and 2069 and draft a white paper on what security HTTP 1.1 will provide. Would it meet initial needs? Jerry will report back on results of IBM security architecture board meeting. Carl-Uno will try to get Asad from Netscape involved in this discussion. --- Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Fri Feb 14 16:39:32 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA05740 for ipp-outgoing; Fri, 14 Feb 1997 16:39:27 -0500 (EST) From: rdebry@us.ibm.com X400-Originator: rdebry@us.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100004738076000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100004738076000002*@MHS> To: Subject: IPP>MOD - adornments to specify display strings Date: Fri, 14 Feb 1997 16:37:29 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 I have been reading Bob's latest version of the model document. As I read the sections on job priority, it struck me that a display string adornment might be useful. For example, simply define the JobHoldUntil attribute values as A, B, C, etc. The administrator can then associate, via a display string adornment, what actually gets displayed to the end-user when these options are presented. I might choose A to be "Print after midnight", B to be "Print on week-ends", etc. On the server side, it would not be difficult to map A, B, C, etc to actual scheduling alogorithms. I think you could do the same for priority. I don't think that the current high, medium, low is granular enough or perhaps meaningful to many users. For example, if I put in IPP interface on top of the MVS system, I'd like to have existing MVS users see the MVS CLASS keyword that they are used to. So, for an MVS printer I'd adorn the A attribute with CLASS=X. From ipp-archive Fri Feb 14 19:09:35 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA06365 for ipp-outgoing; Fri, 14 Feb 1997 19:05:17 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 14 Feb 1997 16:57:35 -0700 From: "Scott A. Isaacson" To: ipp@pwg.org Subject: IPP> MOD - 2/14 minutes Sender: ipp-owner@pwg.org Precedence: first-class Status: RO There was a: IPP Model Teleconference 2/14/97 2:00 - 4:00 PM MST I have uploaded the minutes files to ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/970214-minutes.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/970214-minutes.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/970214-minutes.txt Below is a copy. 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: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ IPP Model Teleconference 2/14/97 2:00 - 4:00 PM MST Attendees: Scott Isaacson Randy Turner Carl-Uno Manros Bob Herriot Jim Walker Item 1: Internationalization. At the model and semantics level, we should just identify all attributes as having some generic syntax (such as "url", "type1Enum", "string", etc.) All attributes of type string could be in most any character set with any encoding. We have to be at least as rich as what 10646 defines. There are 2 attributes which are already defined in the model that help clients and "printers" interoperate using the IPP operations "user-locale" and "printer-locale" The "encoding" of these strings in the give protocol mapping will be defined in each mapping document. For example, an HTTP/1.1 mapping might allow for these strings to be encoded differently (more capable) than HTTP/1.0. At this level we put in the attributes that are necessary to allow for localization and for negotiation, but we don't worry about encoding. We also discussed UTF-8 and UTF-7. Bob pointed out UTF 7 needs about 1.5 bytes (on average) for Engish characters where as UTF-8 needs about 1.13 bytes per character. Also, UTF-7 can be as high as 2.5 for other language sets. Item 2: Each Printer object and each Job object has the following: An identifier which will be a URL A name which is just as string (see item 1 above). The URL is unique and conforms to the rules for URLs. A name need not be unique and is just a string. A Printer Name is probably in the directory for lookup based on Name and then the URL is retrieved. These attributes (URL and Name) are attributes of the object iteself and can be returned in Get Attribute operations. The same attributes (URL and Name) will be used for both Job objects and Printer objects; that is there will not be different Name attributes for Jobs and Printers as in a "job-name" attribute AND a "printer-name" attribute. They are more like "common" attributes for Jobs and Printers. Documents will have neither URL nor Name attributes. Item 3. The Print Response will only have Job URL coming back, NO printer status or job status. We need to keep each operation semantically simple - no overloading of separate semantic operations onto one IPP operation. So we will remove Job Status and Printer Status from the Print Response. Also, on the Print Request, we will remove the "Requested Attributes". If a real status operation is needed, it can be performed separately. Item 4: We discussed the need for more operations given the new talk of a model that allows for submitting attributes "before" submitting document content. At this high level of Model and Semantics we assume the following rules: A Print Request consists of : Job Attributes (possibly empty) Document 1 Attributes (possibly empty) Document 1 Content (URL, octet string, etc) Document 2 Attributes (possibly empty) Document 2 Content (URL, octet string, etc) * Document Last Attributes (possibly empty) Document Last Attributes (possibly empty) All Job attributes come BEFORE Documents All Document attributes come BEFORE document content However, we could issue one lower level protocol operation with just Job Attributes and get back a Job URL. Then issue additional protocol operations to get more document attributes and document contents to the Printer. This is very close to what Roger outlined in his proposal for the lower level protocol operations. If the Printer does not support Long Jobs or Jobs spread out over multiple protocol operations then it could return a fail error code on the first protocol operation with the more bit set to true; it might require the whole thing in one protocol operation. Item 5: Take out the Job Status from the Cancel-Job return (see simplifying goals in item 3). Item 6: In this version of the document List Jobs has been merged in with Get Attributes. As in item number 3 above, separate this back out. Also, we still need to look at whether or not "Get Attributes: Job Templates" needs to be a separate operation also. Maybe this will be more clear as we map this model (and operations) to the scenarios. Note: There is a typo on allJobsLong and Short. Two of those should say allMyJobsLong and Short. Item 7. Since Job-Hold-After and Job-Print-After etc are not extremely critical features for IPP/1.0 and since they are taking a lot of time and energy away from more productive work, we will drop these from IPP/1.0 If there are scenarios that need them, lets go back and look at the scnearios and change the scenarios. Item 8: The same (see Item 7) is true for page-select. Remove it from IPP/1.0. Item 9: An attribute called "unspecified-production-attributes" was added to this version. The recommendation is that we take out the attribute, but leave the text in a general area to describe better the semantics of the model and what end users and admins might expect if there are NO production attributes. Item 10: Bob H. will continue editing the doc to make one more pass based on today's discussion and hopefully have it ready by 2/19 IPP telecon. Item 11: Scott will start to look at model vs scenarios Item 12: A reminder to Tom H that he took the action item at the 2/6 IPP meeting at Adobe to look at IPP attributes vs Printer MIB and Job Monitoring MIB objects. From ipp-archive Fri Feb 14 19:44:34 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA06776 for ipp-outgoing; Fri, 14 Feb 1997 19:43:53 -0500 (EST) Message-Id: <3.0.32.19970214160949.00ead350@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 14 Feb 1997 16:09:51 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC - SET/SSL Information Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO >The following is information on SET and SSL per the last >IPP-SEC telephone conference meeting on 970213. > >SSL V3 Specification > > >SSL Developer Toolkits Information (nonexhaustive) > Consensus Development Corporation > Phaos Technology Corporation > >SET Specification > > >SET Developer Toolkits Information (nonexhaustive) > RSA Data Security > > > >______________________________________________________________________ >Xavier Riley >Xerox Corp. Voice: 310-333-8329 / 8*823-8329 >Corp. Research & Tech. / ADSS Fax: 310-333-6618 / 8*823-6618 >701 S. Aviation Blvd ESAE-231 Email: xriley@cp10.es.xerox.com >El Segundo, California 90245 http://www.cp10.es.xerox.com/~xriley >______________________________________________________________________ > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Fri Feb 14 20:09:34 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA07182 for ipp-outgoing; Fri, 14 Feb 1997 20:07:43 -0500 (EST) Message-Id: <3.0.32.19970214170826.00e1be30@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 14 Feb 1997 17:08:27 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Co-chair for IPP WG in IETF Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO In some correspondence that I have had with Harald as Area Director, he has indicated that he would like to get one more person as co-chair for the EITF WG on IPP, before making his final recommendation about our WG status. After looking at some possible candidates, Harald indicated that he would be happy to see Steve Zilles from Adobe in the co-chair role, as Steve has already made a number of friends in the IETF over the last few years. After some discussion with Steve, he has now offered to step into the role. I would personally feel very comfortable with Steve at my side, as he is an experienced expert on printing as well as on standardization, but to ensure that we are all agreed on this, I would like to hear if anybody has any objections to Steve taking on the co-chair position. Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Mon Feb 17 09:50:09 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA10514 for ipp-outgoing; Mon, 17 Feb 1997 09:45:40 -0500 (EST) From: rdebry@us.ibm.com X400-Originator: rdebry@us.ibm.com X400-Recipients: Ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100004812093000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100004812093000002*@MHS> To: Subject: IPP> ADM - Co-chair for IPP WG in IETF Date: Mon, 17 Feb 1997 09:44:21 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 I have no objection, I've known Steve for many years and I think he would do a great job. ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/17/97 07:53 AM --------------------------- ipp-owner @ pwg.org 02/14/97 06:09 PM To: ipp @ pwg.org@internet cc: Subject: IPP> ADM - Co-chair for IPP WG in IETF In some correspondence that I have had with Harald as Area Director, he has indicated that he would like to get one more person as co-chair for the EITF WG on IPP, before making his final recommendation about our WG status. After looking at some possible candidates, Harald indicated that he would be happy to see Steve Zilles from Adobe in the co-chair role, as Steve has already made a number of friends in the IETF over the last few years. After some discussion with Steve, he has now offered to step into the role. I would personally feel very comfortable with Steve at my side, as he is an experienced expert on printing as well as on standardization, but to ensure that we are all agreed on this, I would like to hear if anybody has any objections to Steve taking on the co-chair position. Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Mon Feb 17 13:35:10 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA11021 for ipp-outgoing; Mon, 17 Feb 1997 13:33:57 -0500 (EST) From: rdebry@us.ibm.com X400-Originator: rdebry@us.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100004821729000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100004821729000002*@MHS> To: Subject: IPP>MOD - comments on latest model document Date: Mon, 17 Feb 1997 13:08:40 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 Comments on Model and Semantics paper, V1.2 Abstract: Should the abstract of each of our internet drafts list each of the papers in the set, so that a reader of any one knows about the others? Section 2.2, IPP Components: we need to update the references in this section (and others) to reclect the changes in the document (or remove them). Printers (section 3.1) Print Jobs (section 3.2) Take Job Templates out of the first bulleted list (line #219 in my copy).C Section 4.1.1 Print Operation: Change the second paragraph to read " ...When the print operation is invoked, the body of the IPP request includes an IPP print job. The concrete syntax of the Print Job is defined in the Internet draft "Internet Printing Protocol/1.2: Protocol Definition. Section 4.1.1.1 Print Request Update the reference to "A set of Job object and Document attributes as defined in section 5." Section 4.1.1.2 Print Response: If the response to a print request always includes Job Status and Printer State, then I would propose not including other requested attributes in the print request. In the requirements scenarios, job status and printer state were the only two attrinbutes I ever specified in the request. This section says that the response includes an Optional message and Optional eror information. I prefer the response style suggested in the protocol white paper. It includes a mandatory response code and a mandatory text string which provides human readable information about the response. Response codes are not just binary (ok or error), they carry significant additional infomation. The next to last sentence in this section suggests that the printer status and job status are optional. I'd like to see them mandatory, its not much to send back. Section 4.1.3.1 Get-Attributes Request Rather than using the query string in the URL (which is a syntax issue anyway), why not request named groups of attributes just like individual attributes. That is, treat the names of attribute groups just like the names of individual attributes in the Get-Attributes request. Thus, the abstract data type Requested Attributes would read: "A list of attributes or named attribute groups in whose values the requester is interested. This seems much simpler to me. Would Requested Attributes be optional then? Job Template seems an awfully large grouping of attributes. allJobs Long attribute group - does this include everything in sections 5.2 and 5.3, or is it meant just to be the job attributes set by the printer? The latter makes more sense to me. allJobsShort and allJobsLong appear twice in the definitions of attribute groups, but with different descriptions. Do these need different names when referring only to the owners jobs? Should all jobs be included when we are not allowing administrative operations in this the protocol? Section 4.1.3.2 Get Attributes Response Maybe this is just a clarification, but would the otional error response ever be sent when Result attributes are sent? That is, would the response be one or the other, never both? Section 5.1 The bulleted list describing the cases for accepting attributes, the last bullet, says that the job attribute is accepted when the job and printer both do not specify an attribute? This wording is confusing. What does it mean to say that the attribute is accepted? Why not say "when the job and the printer both do not specify an attribute a default is prescibed. Bulleted list on attribute tags, what is file type for? It is not clear at all from the description. Can an example be provided? The sentence "When a client displays a default value, it chooses the first visible value that is tagged with default. This could be interpreted to say that attributes can have multiple values tagged as defaults, and I pick the first one of these. I don't expect that this is what is meant. I understand the intent of the imbedded tag, but wonder how effectively it will be used in practice. Best-effort tag - it seems that to guarantee that my job will print, I would have to specify this tag for every attribute! Could the need for best-effort be eliminated by the following flow? client Printer +---------------------------------> I want to start a print job <---------------------------------+ Job URL Attributes in Job Template group +---------------------------------> print job Availability Tag - I don't understand ready-with-operator. Why isn't this not-ready-with-operator? Do we need a not-ready-no-operator? Section 5.2, third paragraph: What does it mean "Each attribute which can be applied independently on a page-by-page basis may ...? Does this refer to attributes specified within the PDL? If not how are attributes applied on a page-by-page basis? You probably should list these to make it clear which attributes are in this category. Section 5.2.2.1 Job-sheets Where ever we have type3enums, would it be worth mentioning in the text that additional attribute values may be defined for those of us who can never remember what a type3enum means? Section 5.2.3.1 notification-events: Why would this ever contain the empty set? Why would a client specify an attribute type with no value? By the way, I don't recall reading anywhere what "the empty set" is. Is it defined someplace. Why not use the value "none" to override an administrator specified default to notify? Based on the scenario's work, I'd like to see a notify-short and notify-long request. Notify short just says "job is complete". Notify-long would include pages/copies printed, time completed, where job is to be picked up, accounting information, etc. 5.2.4.1 job-priority I'd like to see more values here. I can't map IPP to existing operating system, like MVS, which allow more priorities. MVS users would like to see the same service on the web that they see in today's operation. Section 5.2.5 Second paragraph - won't the way that conflicts between PDL attribute and production attributes get resolved by PDL dependent? If so, then we need a Printer attribute that indicates how they are resolved. I think we need a major section which describes how we see future PDLs, printers and device drivers being written to properly use and exploit IPP. Section 5.2.5.2 copie need to update this section to reflect multiple-files-are attribute. Section 5.2.5.3 finishing Should the first sentence in this section read "This job attribute identifies the finishing operations that the Printer should apply to each copy of each printed document in the job"? Other places where "the document" is mentioned should be similarly updated. Section 5.2.6.1 unspecified-production-attributes I don't understand leave-as-is value! Section 5.7 Conformance I think we need more discussion on conformance. See the chart I did several months ago on attribute support. Attributes that I've identified in the scenarios that do not appear in the model and semantics document: Driver url attended/unattended cost per page Printer supports: compression authentication payment any administratively set limits (e.g. max copies) printer's public key printer can pull jobs printer can pull resources From ipp-archive Mon Feb 17 15:00:11 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA11422 for ipp-outgoing; Mon, 17 Feb 1997 14:58:29 -0500 (EST) Date: Mon, 17 Feb 97 12:59:10 MST From: jeff@boulder.qms.com (Jeff Copeland) Message-Id: <9702171959.AA09915@boulder.qms.com> To: ipp@pwg.org Subject: IPP> ADM -- web pages Sender: ipp-owner@pwg.org Precedence: first-class Status: RO For those of you who haven't noticed, the IPP web pages are now available at http://www.pwg.org/ipp/index.html, and are in good enough shape the we can begin advertising them to the outside world. To this end, let me know who else we should ask to point at our pages. Meanwhile, if there are missing documents or other deficiencies, let me know. Jeff Copeland From ipp-archive Mon Feb 17 16:15:13 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA11784 for ipp-outgoing; Mon, 17 Feb 1997 16:13:38 -0500 (EST) X-Nvlenv-01Date-Transferred: 17-Feb-1997 15:43:26 -0500; at X-WB-AREA-HUB.XEROX X-Nvlenv-01Date-Transferred: 17-Feb-1997 15:41:50 -0500; at X-WB-NGM-MIME.XEROX X-Nvlenv-01Date-Posted: 17-Feb-1997 15:37:04 -0500; at X-WB-0311-MS3.XEROX Date: Mon, 17 Feb 1997 12:40:30 PST From: Peter_Zehler@wb.xerox.com (Zehler,Peter) To: IPP@pwg.org (IPP redirector) Subject: IPP> REQ: Updated issues list and closed issues Message-Id: <"<55C0083381E2667C>55C0083381E2667C@X-WB-0311-MS3.XEROX"@-SMF-> Sender: ipp-owner@pwg.org Precedence: first-class Status: RO All, I have updated the issues.doc and closed.doc in the new_REQ directory on the IPP ftp site. (could some kind sole generate the pdf version?) The new issues contains 22 issues. Out of the 22, 8 have recommended solutions. The closed list contains 15 issues that have been passed on to the whips of the MOD, SEC, DIR and PRO groups. Pete From ipp-archive Mon Feb 17 20:35:15 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA12414 for ipp-outgoing; Mon, 17 Feb 1997 20:30:22 -0500 (EST) Message-Id: <3.0.32.19970217173133.00ea3810@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 17 Feb 1997 17:31:34 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Agenda for IPP Phone Conference on 970219 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Suggested Agenda for IPP Phone Conference 970219 - 1 - 3:30 pm Pacific Time Review the latest versions of and comments on: - Scenario/Requirements document (Peter Zehler) - Model and Semantics document (Bob Herriot/Scott Isaacson) Comments on latest thinking on Protocol (Roger deBry) Report from Security subgroup (Roger deBry) Check consensus of getting Steve Zilles as co-chair for the IEF WG As previously announced, it looks like I will be unable to attend the conference this week, so it will be led by Scott Isaacson. Call-in: 1-423-673-6712 Access Code: 190148 Date: 2/19 Time: 4PM Eastern Duration: 2.5 hrs Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Mon Feb 17 20:50:17 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA12748 for ipp-outgoing; Mon, 17 Feb 1997 20:47:27 -0500 (EST) Message-Id: <3.0.32.19970217174842.00ea3810@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 17 Feb 1997 17:48:43 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Subjects for IPP Meeting on April 3 in Austin, TX Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Subjects for IPP Meeting on April 3 in Austin, TX Although the final agenda probably will not be determined until later, here are the subjects that I now estimate will be covered in our April meeting: - Comments on our four (or five) new Internet-Drafts (which are due mid-March) - Completeness and adherence to the IETF editing rules - Consistency between the documents - Any remaining work to be done to the documents before proposed as RFC texts - Discussion about IPP prototyping (should be a hot subject by then) - Start discussion about scope and plans for IPP version 2 (preparation for extended charter) Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Tue Feb 18 12:37:00 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA14356 for ipp-outgoing; Tue, 18 Feb 1997 12:30:49 -0500 (EST) Message-Id: <9702181730.AA08245@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Feb 1997 09:28:17 PST To: walker@dazel.com From: Tom Hastings Subject: Re: IPP> MOD - Minutes from Meeting at Sun on February 5 - .pdf file posted Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I posted the .pdf file of the minutes: -rw-r--r-- 1 pwg pwg 13824 Feb 11 15:11= 970205-ipp-mod-meeting.doc -rw-r--r-- 1 pwg pwg 16714 Feb 18 17:28= 970205-ipp-mod-meeting.pdf -rw-r--r-- 1 pwg pwg 11351 Feb 11 15:12= 970205-ipp-mod-meeting.txt Tom At 07:38 02/11/97 PST, Jim Walker wrote: >Attached are the minutes from the Model Group meeting at Sun on >February 5. Thanks to Lee Farrell for providing his notes to me >to help fill in those gaps that I missed. > >I have also uploaded the files to: > > ftp://ftp.pwg.org/pub/pwg/ipp/minutes/970205-ipp-mod-meeting.doc > ftp://ftp.pwg.org/pub/pwg/ipp/minutes/970205-ipp-mod-meeting.txt > >If someone could do the PDF, I would appreciate it. > >enjoy... >...walker > >-- >Jim Walker >System Architect/DAZEL Wizard >DAZEL Corporation, Austin, TX > IPP Model Group Meeting Minutes > February 5, 1997 > San Jose, California > > >The meeting started on February 5 at 1:00PM. The attendees were: > >Jim Walker -- DAZEL >Keith Carter -- IBM >Lee Farrell -- Canon >Tom Hastings -- Xerox >Carl-Uno Manros -- Xerox >Don Wright -- Lexmark >Bob Herriot -- Sun >Larry Masinter -- Xerox >Greg Mavroudis -- TrueSpectra >Steve Sutherland -- TrueSpectra >Scott Isaacson -- Novell (by phone) > >The following agenda was suggested by Bob Herriot: > > 1) Attributes > 2) Queues / fan-in and fan-out =96 what does the user see? > 3) GetJobs printer information > 4) Conformance > 5) Scenarios (and conformance thereof) > >Ultimately, the meeting focused on attributes only, touching upon the >other issues at various times. Bob Herriot had distributed a new >version of the IPP Model draft, which combined and simplified the >attributes. In general, the participants were happy with the idea of >job attributes being represented in the printer object, obviating the >need for the job template object, and the xxx-supported attributes. >During this discussion of attributes, it was questioned if they are >beneficial, useful, or just nice; for example, Microsoft's approach >does not have any attributes. Most felt that the attributes were >necessary. > >The following is a summary of the more important issues that were >discussed. > >o Production attributes and resource attributes > > There are cases in the job attributes where an attribute is both > production and resource attributes. For example, the xxx-margin > attributes could be production instructions in the case of a text > document (i.e., these margins should be used when translating this > document to a format suitable for printing), or a resource attribute > in the case of a PostScript document (i.e., these are the margins that > were used in formatting this output). The current proposal in the > document (as added by Bob Herriot) is that the attributes have an > optional "embedded" tag to indicate that the attribute is a resource. > So, in the example above, the xxx-margin attributes would have no tag > in the case of a text document, but would have the "embedded" tag for > the PostScript document. > > The conversation then degenerated into a discussion of whether the > length and width (and the xxx-margin problems, for that matter), are > really useful for text processing; for example, if I specify a width > for a text document, is it really going to be able to break and format > lines like I wanted. The group admitted that these might just be > solutions for the 5% case, but there was no motion to remove the > attributes. > >o File type tag > > Another new tag, or adornment, that was added to the Model document > was a tag to indicate an attribute or value that may be appropriate > for only a particular document format. For example, a printer may > only support number-up=3D4 for PostScript documents, so the attribute > value could be adorned so that the client could decide which > attributes and values are appropriate based upon the input document > format. > > Discussion of this tag led to some interesting questions. For > example, what if the client does not know the file type yet? Also, > what if a job has multiple documents of varying formats (e.g., 1 > PostScript document and 1 PCL document). There was no real decisions > made as to whether this tag was appropriate or not, because we > immediately jumped into... > >o Multiple document jobs > > We had a long discussion on multi-document jobs; we say that we will > support multiple documents, but we do not allow all attributes to be > different for each document. We already have at least two attributes, > document-format and document- content, that can vary across documents. > On a practical basis, people are going to want to have other > characteristics that are different for each document in a multi- > document job. The scenario that we referred to in justifying > generalizing the per-document attributes is the common case of > printing the first page of a letter on company letterhead, and the > rest of the letter on plain stock, except for the last page which is > printed on some third stock. This scenario could be viewed as three > documents being printed on three different media. (Alternatively, > this could be handled by submitting the letter as a single document, > and having special attributes for first-page-medium and > last-page-medium, but that is another discussion :-). > > The question was raised about how important it is to really support > multiple documents per job. It was pointed out that Microsoft breaks > down a multi-document print request into separate jobs. However, it > was also pointed out that LPR does support multi-document print > jobs. (Everyone feels that IPP needs to do at least what LPR can do.) > This led to a discussion about what the concept of a "print job" > should be, with little consensus reached. > > Bob suggested a compromise: we want to have multiple documents per > job, and have per-document attributes which override job-level > attributes. However, we should not address the syntax of this > capability at this time; let's attempt to ensure that our syntax does > not preclude future support of this feature. We have not yet decided > whether we do or do not need a separate document object, but the > general feeling seemed to be to keep it simple. > > The discussion of multi-document jobs then led to the question of what > should be the behavior of a printer (or server) that is sent a > multi-document job, but can only support single-document jobs. This > led to the issue of... > >o Compulsory/Non-compulsory attributes > > We had first discussed the print-regardless attribute that had been > added in the latest version of the IPP Model document. We had decided > to remove this attribute, and have print-regardless be the default. > This would imply that a job would print in spite of errors in the job > specification; the server would simply make its "best effort" to print > the job. In addition, we discussed the idea of having a "compulsory" > adornment for attributes, which the user could use to indicate > particular attributes that the server is required to comply with, or > else reject the job. However, it was decided to table the idea of > this adornment for now. > > As we discussed multi-document jobs, we got back into the discussion > of best effort versus compulsory behavior. Several people felt that > the previous decision of best effort being the default would result in > clients not being able to reliably print; IPP would end up with the > reputation that the client does not get what it asks for. Tom > Hastings also added that compulsory behavior as a default would be > better for standards compliance (i.e., strictest is best for > interoperability). > > So, we decided that the previous decision was backwards; instead, we > felt that the default should be that any attributes that are specified > with a job shall be assumed to be compulsory, unless the attribute (or > attribute value) is explicitly adorned otherwise. Also, we will not > define what a best effort is; we will simply define the conforming > behavior. > > Furthermore, we suggested that there may even be some attributes that > may not be adorned as non-compulsory, or best effort. For example, > the number of documents in a job is not really a characteristic of the > job that the client explicitly sets; rather, it is a characteristic of > the job that is implied from the number of documents included in the > submission. Consequently, if a client submits a multi-document job, > and the server does not support multi-document jobs, then the server > shall reject the job. > >o Multi-valued attributes > > We currently have one job submission attribute (notification-events) > that can be multi-valued; its syntax is setOfType2Enum. We discussed > whether to have distinguished values for this syntax. Originally the > discussion focused on a special value, "none", which would be used to > indicate the empty set. Tom Hastings suggested this distinguished > value so that a client could specify none (and override an explicit > default), and an administrator could set none as a default value, or > exclude it as a supported value. Bob Herriot noted that this > distinguished value would have to be treated specially (if none was > specified, then no other values could be specified for that > multi-valued attribute), and Larry Massinter reminded us that existing > standards (HTTP and SMTP) already use an empty string to represent the > empty set, or none. No decision was made, but it was suggested that > there might be other useful distinguished values, such as "all" and > "default". > >o External references > > Steve Sutherland suggested that a job should specify any external > references that are present in a document. The examples given were a > ColorWave (?) format used by his company (TrueSpectra), PDL's that > reference external fonts, and HTML files. Larry pointed out that a > problem with referencing Internet resources is that there needs to be > an agreed naming convention of these resources, because they may be > named differently by different clients. Also, the group was very wary > of treading into the problem of printing a tree of HTML references. > > Ultimately, the decision was to add a new attribute for external > references that are (or will be) needed to process a document. This > attribute, if specified, will presumably list (by URL) resources that, > if retrieved ahead of time, can cause the document to be processed > more quickly. > >o Several other interesting side discussions occurred: > > - Larry suggested that we should have the capability in the protocol > to return multiple jobs as the result of a single print request. > Although this suggestion was made during the discussion of trying to > define the "best-effort" of printing a multi-document job at a server > that only supports single document jobs, it still might be of use in > other areas. > > - Tom suggested that we should have conformance requirements on the > client as well as the server. The example sited was that a conformant > client verify that a server supports multi-document jobs before > submitting a multi-document job. > > - Do we need a new attribute that specifies that all of the documents > in the job (and all of the copies) should be kept together? > > - Once we have the capability of non-compulsory, there seem to be 4 > different cases for (some) attributes: > > What can the printer do ? > What is the client requesting ? > What does the server say it is going to do ? > What did the server actually do ? > > We could use adornments for this (e.g., as-submitted, as-printed, > etc.). > > - Larry suggested that we make the request syntax separate from the > response syntax. For example, I could ask for courier font or > fixedwidth font, so the request might be able to ask for A or B. > However, the response might include the values requested, the default > values, and the values used. > > >The meeting adjourned at 6:00 PM. > From ipp-archive Tue Feb 18 12:40:59 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA14528 for ipp-outgoing; Tue, 18 Feb 1997 12:36:50 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 18 Feb 1997 10:32:39 -0700 From: "Scott A. Isaacson" To: ipp@pwg.org Subject: IPP> DIR - New Directory issues list Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have posted a new Directory subgroup issues list. See: ftp://ftp.pwg.org/pub/pwg/ipp/new_DIR/ directory-issues.PDF 5 Kb Sun Feb 18 17:25:00 1996 directory-issues.doc 12 Kb Sun Feb 18 17:25:00 1996 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: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Tue Feb 18 12:41:00 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA14509 for ipp-outgoing; Tue, 18 Feb 1997 12:36:33 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 18 Feb 1997 10:30:47 -0700 From: "Scott A. Isaacson" To: ipp@pwg.org Subject: IPP> MOD - New Model Issues list Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have posted a new Model Subgroup issues list. I will try to track issues formally on this list. ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ model-issues.PDF 10 Kb Sun Feb 18 17:23:00 1996 model-issues.doc 27 Kb Sun Feb 18 17:23:00 1996 Does anyone know why the dates get all messed up? Sunday 2/18?? 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: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Tue Feb 18 20:40:30 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA16156 for ipp-outgoing; Tue, 18 Feb 1997 20:35:41 -0500 (EST) Message-Id: <3.0.32.19970218173638.00e85470@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 18 Feb 1997 17:36:40 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC - Phone conference 970220 Cc: asad@netscape.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO As planned we will hold the next phone conference for the SEC subgroup on Thursday, February 20, at 1pm Pacific time (duration up to two hours). Agenda items: - Report from Jerry on IBM security architecture board meeting and their input for IPP - Requirements list (from a security perspective) Jerry - Report from Xavier and Daniel on HTTP 1.1 vs. SSL v.3 security features. - Further tries to agree scope of security needed for IPP v 1.0. All The conference number is: 1-800-857 5607 with passcode: cmanros New participants are always welcome! Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Wed Feb 19 02:30:34 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA17218 for ipp-outgoing; Wed, 19 Feb 1997 02:26:11 -0500 (EST) Message-Id: <9702190726.AA08440@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen (Unverified) X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Feb 1997 23:24:21 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Push back on simplifying Print operation response Sender: ipp-owner@pwg.org Precedence: first-class Status: RO The minutes of the Model telecon, 2/14/97 say: Item 3. The Print Response will only have Job URL coming back, NO printer status or job status. We need to keep each operation semantically simple - no overloading of separate semantic operations onto one IPP operation. So we will remove Job Status and Printer Status from the Print Response. Also, on the Print Request, we will remove the "Requested Attributes". If a real status operation is needed, it can be performed separately. My concern is that either: 1. User friendly implmentations will make additional protocol calls to get job and printer status. That means that each Print operation will require three calls, not one. If we layer on HTTP that means a new session startup/teardown for each of the three calls. IPP will be another Internet burner (or at least perceived as one). 2. Client mplementors won't bother getting any status of the job or printer either in the name of efficiency on the Internet or making their implementation easier. IPP will just be another "black hole" print protocol that doesn't give any user feedback. I've used a system (VMS) for 15 years that told you in its Print operation whether your job was queued or started printing. With so many desktop printers that have a low duty cycle, whether your job started printing because the printer was idle or has to wait is very useful. If we elminate the status return on Print and client implementors don't make the two additional protocol calls, the following very unfriendly situatoin will happen: If the printer to which you submitted your job was printing another job and the printer needs attention, you will NOT get a notification of this problem, even if you specify the notification-events=printer-problem, because the printer problem event happened BEFORE you submitted your job. So your job will sit there until someone else fixes the problem and you won't know about it even though you asked to be notified of any printer problems!!! Its so simple to have the Print operation return the job and printer state and state-reasons in the response. Lets reconsider this decision (and get others involved in this discussion, especially the people who hate and those who love HTTP). Tom P.S. I can probably live with elminiating the requested-attributes on the grounds that such clients can make another call or probably won't bother, since GUI clients will probably have shown the user the interesting job attributes anyway. From ipp-archive Wed Feb 19 02:40:34 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA17546 for ipp-outgoing; Wed, 19 Feb 1997 02:38:11 -0500 (EST) Message-Id: <9702190738.AA08449@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen (Unverified) X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Feb 1997 23:36:22 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Pushback on removing job-hold-until/job-print-after and page-select Sender: ipp-owner@pwg.org Precedence: first-class Status: RO The minutes contained these two proposals to remove attibutes from IPP V1.0: Item 7. Since Job-Hold-After and Job-Print-After etc are not extremely critical features for IPP/1.0 and since they are taking a lot of time and energy away from more productive work, we will drop these from IPP/1.0 If there are scenarios that need them, lets go back and look at the scnearios and change the scenarios. TH> Did you consider dropping the relative form of time. I see no value in specifying that a job be held for a relative amount of time. But an absolute time or a time period seems simple enough. How about just those? What were the problems with them? If not, lets keep it in. If there are, I agree that this attribute isn't as critical as others. Item 8: The same (see Item 7) is true for page-select. Remove it from IPP/1.0. TH> I feel much more strongly about keeping page-select, since it is something that you can do on every Windows and MAC today (and for many years). How can IPP V1.0 not support what is done by 100M clients today? From ipp-archive Wed Feb 19 09:20:42 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA18462 for ipp-outgoing; Wed, 19 Feb 1997 09:17:46 -0500 (EST) Message-Id: Date: Wed, 19 Feb 97 09:18 EST From: jkm@underscore.com (JK Martin) To: pmp@pwg.org, jmp@pwg.org, ipp@pwg.org Subject: IPP> We need to improve our publication announcements Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Sorry for the cross-posting here, but this message is long overdue. Folks, PLEASE take the 2.5 seconds to type in the complete URL to the documents you announce to the mailing lists. It only takes a very short time to be complete and accurate...and for those folks with decent mail agents, this makes it very, very easy for them to quickly reference your hard work. (After all, you DO want people to read your work, no? And the sooner the better, right?) This message was prompted by the attached message. Note that at this writing (just after the attached message was posted), the contents of the referenced server directory is: -rw-r--r-- 1 pwg pwg 7704 Feb 19 13:05 err1.PDF -rw-r--r-- 1 pwg pwg 29696 Feb 19 13:05 err1.doc -rw-r--r-- 1 pwg pwg 13824 Feb 13 00:29 inputsw.doc -rw-r--r-- 1 pwg pwg 15360 Feb 13 23:40 inputsw2.doc Let's not make undue work for each other, ok? Thanks for your cooperation. ...jay ----- Begin Included Message ----- >From pwg.org!pmp-owner Wed Feb 19 08:49:09 1997 To: "pmp%pwg.org" From: Lloyd Young Date: 19 Feb 97 8:09:55 EST Subject: PMP> A Top 20 Chart Mime-Version: 1.0 I have placed a copy of Chuck's file in Word and PDF formats in the /pub/pwg/contributions directory. Lloyd Young --------------------------- Original e-mail --------------------------- To: pmp%pwg.org @ interlock.lexmark.com @ SMTP cc: (bcc: Lloyd Young) From: adamsc%pogo.WV.TEK.COM @ interlock.lexmark.com (Chuck Adams) @ SMTP Date: 02/18/97 07:50:58 AM Subject: PMP> A Top 20 Chart Folks, Attached is a first draft of a chart presenting my personal top 20 events list. I hope this will help us in our "attempt to standardize the alert table entries, sub-unit status, hrDeviceStatus, hrPrinterStatus and hrPrtDetectedErrorState for a subset of the most likely printer events." I'll get this out now without a couple of events since I believe they can be inferred from what is presented here. But if you want to add more events be my guest and have at it. Chuck Adams Tektronix, Inc. P.S. If someone would be so kind as to put this in the ftp://pwg.org/pub/pwg/pmp/contributions/ site I would appreciate it. ----- End Included Message ----- From ipp-archive Wed Feb 19 09:25:39 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA18783 for ipp-outgoing; Wed, 19 Feb 1997 09:20:44 -0500 (EST) Message-Id: <199702191421.XAA13580@gloria.rdc.ricoh.co.jp> To: hastings@cp10.es.xerox.com Cc: ipp@pwg.org Subject: Re: IPP> MOD - Comments on IPP Model V1.1, printer-state attribute In-Reply-To: Your message of "Tue, 11 Feb 1997 12:11:37 PST" References: <9702112013.AA06735@zazen.cp10.es.xerox.com> X-Mailer: Mew version 1.00 on Emacs 19.31.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Wed, 19 Feb 1997 23:21:04 +0900 From: Tetsuya Morita Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Tom, We have considered how we could align our OMG Printing Facility model with your comments on 5.5.5 printer-state. You might know that our model and attributes are also strongly affected by DPA, so your DPA oriented approach is easy to accept to our model. > Comments: > > 2. "idle" should not indicate whether the Printer is accepting jobs or not, > that is what the enabled attribute is for. So change the definition of > idle to: > > idle The Printer is not processing any jobs. > > 3. Change the name of the "printing" state to "processing", so that > the state may be used by Printers when interpreting, and by non-Printer > output devices, like CD-ROM writers and fax-out. So change the definition > to: > > processing The Printer is currently processing a job. > > 4. "needs-attention" may now need special training, since needs-attention > is for any reason that the Printer needs human attention. Also the operator > may have paused the printer or the job may contain instructions to stop > the printer and wait for human interaction. So change the definition of > needs-attention to: > > needs-attention The Printer needs human attention. This state typically > includes adding paper, clearing a jam, changing the medium, etc. It also > includes when a system operator has paused the printer or the job contains > special instructions to stop the printer at a particular point in the job > to wait for operator or end-user interaction, such as installing special > forms or entering a password. The printer-state-reasons and > printer-state-message printer attributes give further information about why > the output device needs attentions. > > 5. I also believe that we need the ISO DPA "shutdown" state, which indicates > that the Printer has been shutdown. It seems too surprising to end-users > to indicate a shutdown condition as a printer-state-reason when the printer > is in the needs-attention or idle states. So bring back "shutdown": > > shutdown The Printer has been taken out of service, (for a long time), > whether for repairs or others reasons. The Printer's printer-state message > attribute may be used to record a reason and estimated time for return to > service. Most of the differences between our previous state model and your's are on the name descriptions. Tom's States Ricoh's States Comments ============================================================================ shutdown power-off Same meaning processing executing Same meaning needs-attention error needs-attention and needs-key-operator included unknown unknown Same meaning idle idle Same meaning Assuming IPP may be one of the candidates for implementation of OMG Printing Facility, we slightly changed our Device STD to be a superset of IPP printer states as follows, /----------\ /----------\ | shutdown | | unknown | \----------/ \----------/ | ^ | | /------+------------- active -------------------\ | | | | V | | /------------\ /-- needs-attention --\ | | | initialize |<-+ | | | | \------------/ | | /-- error --------\| | | | +--+->| || | | | | | (needs-key-op) || | | /----+-----------\ | | || | | | V | | | (connect-to-p) || | | | /----------\ |<--+->| || | | | | idle | | | | (timeout) || | | | \----------/ | | | || | | | | ^ | | \-----------------/| | | | | | | | | | | | V | | | | | | | /------------\ | | /----------\ | | | | | processing | |<--+->| paused | | | | | \------------/ | | \----------/ | | | | | | | | | \--operational---/ \---------------------/ | | | \-----------------------------------------------/ Device State Transition Diagram (in OMG Printing Facility submission by Ricoh) Although we know the 'initialize' state is not defined by DPA, we added it because print client might select other 'operational' device and start printing quickly. Today's almost available printers have some warm-up time. I suppose the 'initialize' could be included in 'idle' state in IPP model, right? > By the way, the OMG Print Facility standards project is on the same > schedule as IPP and is trying to align with IPP, so this above discussion > on printer states relates to work they are currently doing. So I hope we > can get closure on these printer attributes soon in order to keep the two > developing standards aligned. We would be so happy to make liaison with IPP Working Group. I hope our new Device STD is well aligned to IPP printer-state attributes. Thanks, -- Tetsuya Morita Ricoh Company Ltd. Printer Business Center From ipp-archive Wed Feb 19 09:30:37 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA19318 for ipp-outgoing; Wed, 19 Feb 1997 09:28:34 -0500 (EST) Mime-Version: 1.0 Date: Wed, 19 Feb 1997 09:32:02 -0500 Message-ID: <000099C8.1337@digprod.com> From: bwagner@digprod.com (Bill Wagner) Subject: Re: IPP> MOD - Push back on simplifying Print operation resp To: ipp@pwg.org, Tom Hastings Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I think Tom has made some valid points. I would request more information on why "We need to keep each operation semantically simple -no overloading of separate semantic operations onto one IPP operation." Without indicating the operational requirements for this dictate, it seems more like a religious statement than a clear requirement. On the other hand, the returning of status information which would be requested anyway seems quite reasonable. Bill Wagner, DPI ______________________________ Reply Separator _________________________________ Subject: IPP> MOD - Push back on simplifying Print operation response Author: Tom Hastings at Internet Date: 2/18/97 11:24 PM The minutes of the Model telecon, 2/14/97 say: Item 3. The Print Response will only have Job URL coming back, NO printer status or job status. We need to keep each operation semantically simple - no overloading of separate semantic operations onto one IPP operation. So we will remove Job Status and Printer Status from the Print Response. Also, on the Print Request, we will remove the "Requested Attributes". If a real status operation is needed, it can be performed separately. My concern is that either: 1. User friendly implmentations will make additional protocol calls to get job and printer status. That means that each Print operation will require three calls, not one. If we layer on HTTP that means a new session startup/teardown for each of the three calls. IPP will be another Internet burner (or at least perceived as one). 2. Client mplementors won't bother getting any status of the job or printer either in the name of efficiency on the Internet or making their implementation easier. IPP will just be another "black hole" print protocol that doesn't give any user feedback. I've used a system (VMS) for 15 years that told you in its Print operation whether your job was queued or started printing. With so many desktop printers that have a low duty cycle, whether your job started printing because the printer was idle or has to wait is very useful. If we elminate the status return on Print and client implementors don't make the two additional protocol calls, the following very unfriendly situatoin will happen: If the printer to which you submitted your job was printing another job and the printer needs attention, you will NOT get a notification of this problem, even if you specify the notification-events=printer-problem, because the printer problem event happened BEFORE you submitted your job. So your job will sit there until someone else fixes the problem and you won't know about it even though you asked to be notified of any printer problems!!! Its so simple to have the Print operation return the job and printer state and state-reasons in the response. Lets reconsider this decision (and get others involved in this discussion, especially the people who hate and those who love HTTP). Tom P.S. I can probably live with elminiating the requested-attributes on the grounds that such clients can make another call or probably won't bother, since GUI clients will probably have shown the user the interesting job attributes anyway. From ipp-archive Wed Feb 19 10:00:38 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA19701 for ipp-outgoing; Wed, 19 Feb 1997 09:56:10 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 19 Feb 1997 07:56:15 -0700 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> ADM - 2/19 Teleconference Agenda Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Thanks to Don Wright for setting up the telecon - a reminder: Wed, 2/19 Call-in: 1-423-673-6712 Access Code: 190148 Date: 2/12 and 2/19 Time: 4PM Eastern Duration: 2.5 hrs Neither Carl-Uno nor Don will be available for the call. I volunteered to run the meeting, but I will be looking for a note taker .... Agenda: 1. Discussion on Area director's recommendation of a co-chair for IPP. Steve Zilles has agreed to take on the role. See Carl-Uno's email message. 2. Review IPP ftp server directory structure - where do things go? Do minutes from Model subgroup go under minutes or new_MOD? 3. Review Requirements and Scenarios - New I-D posted on 2/17 - New scenarios posted on 2/17 - New Issues and Closed posted on 2/17 4. Review Model and Semantics - New I-D (1.2) posted on 2/14 - review 2-14 meeting notes - Review new document posted 2/19 ?? - Review decision to not include printer status and job status in print response - Review new issues lists posted 2/18 5. Security - review any new items - note call on Thursday, February 20, at 1pm Pacific time (duration up to two hours). 1-800-857 5607 passcode=cmanros New participants are always welcome! 6. Protocol Spec - Have we started a doc? - Do we have a plan? 7. Directory - Let's pick a time for the Directory subgroup - Prior to the telecon, review 1. The I-D 2. Scenarios dealing with finding and installing 3. Roger's comments: Attributes that I've identified in the scenarios that do not appear in the model and semantics document: Driver url attended/unattended cost per page Printer supports: compression authentication payment any administratively set limits (e.g. max copies) printer's public key printer can pull jobs printer can pull resources 4. Directory Issues lists? - Review issues list posted 2/18 7 Other - new business - new issues Action Item Requests: - We need somebody to check our Model & Semantics content vs. RFC 1179, to verify our claim that IPP can replace RFC 1179 functionally. - We have spoken about the need to document why we do not want to build IPP on RFC 1179. Is anybody prepared to write a separate little Internet-Draft document to explain this to the world? Not a popular task - I know! Talk to you soon: ************************************************************ 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: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Wed Feb 19 10:40:41 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA20150 for ipp-outgoing; Wed, 19 Feb 1997 10:37:46 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 19 Feb 1997 08:37:51 -0700 From: Scott Isaacson To: ipp@pwg.org, rdebry@us.ibm.com Subject: IPP>MOD - comments on latest model document -Reply Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Roger, Thanks for the complete review of the doc. Some of my comments: >>> 02/17/97 11:08am >>> > Section 4.1.1.2 Print Response: > If the response to a print request always includes Job Status and > Printer State, then I would propose not including other requested > attributes in the print request. In the requirements scenarios, job status > and printer state were the only two attrinbutes I ever specified in the > request. Sounds like we all agree that we can do without "requested attributes". I have created a new issue on the Model issues list for the notion of Job and Printer state and state reasons being returned in the print response. >>> 02/17/97 11:08am >>> > Section 5.2.2.1 Job-sheets > Where ever we have type3enums, would it be worth mentioning in the > text that additional attribute values may be defined for those of us who > can never remember what a type3enum means? I can never remember either, but we do define it clearly right at the begining of 5.1. I am sure we do not want to define it over an over again. >>> 02/17/97 11:08am >>> > 5.2.4.1 job-priority > I'd like to see more values here. I can't map IPP to existing operating > system, like MVS, which allow more priorities. MVS users would like to > see the same service on the web that they see in today's operation. You can always have a mapping - might not be very good, but you can always do it. Supposing one system A, has some priorities. IPP has 3. If A has less than 3, just map to some set of IPP values. If A has more than 3, map multiple values from A to one value in IPP. If: Set A {none} Set IPP {low, med, high} Mapping 1: none -> low Mapping 2: none -> high If: Set A {1, 2} Set IPP {low, med, high} Mapping 1: 1 -> low, 2 -> high Mapping 2: 1 -> med, 2 -> high If: Set A {1, 2, 3, ..., 100} Set IPP {low, med, high} Mapping 1: 1,2,..., 33 -> low, 34-67 -> med, 68-100 -> high I do not want the IPP Model to turn into a smallest common subset or union of all printing systems. I want it to be a "reasonable" view for all printing subsystems. I don't even think the right words are greatest common subset (since one trivial printing system brings the whole thing down into the mud). We, as participating companies, all have different markets with different types of customers, however, from the Novell perspective, we have found that 100 different values are TOO many. I am sure that we can satisfy over 95% of electronic distributed printing with only 3 values. Scott Isaacson From ipp-archive Wed Feb 19 10:45:40 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA20472 for ipp-outgoing; Wed, 19 Feb 1997 10:43:17 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 19 Feb 1997 08:43:01 -0700 From: "Scott A. Isaacson (Scott Isaacson)" To: ipp@pwg.org Subject: IPP> MOD - 2/19 Model Issues list Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have posted yet another new Model Subgroup issues list. I hope to review this at the Wed telecon instead of the 2/17 one? ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/model-issues.PDF ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/model-issues.doc How's that Jay? 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: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Wed Feb 19 11:05:39 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA20813 for ipp-outgoing; Wed, 19 Feb 1997 11:02:09 -0500 (EST) Message-Id: Date: Wed, 19 Feb 97 11:02 EST From: jkm@underscore.com (JK Martin) To: ipp@pwg.org Subject: IPP> MOD - Exactly what is a reasonable subset? Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Scott Isaacson recently wrote this little gem, but since it was near the end of a comprehensive reply message, it might have gone unnoticed by some: > I do not want the IPP Model to turn into a smallest common subset or > union of all printing systems. I want it to be a "reasonable" view for all > printing subsystems. I don't even think the right words are greatest > common subset (since one trivial printing system brings the whole thing > down into the mud). We, as participating companies, all have different > markets with different types of customers, however, from the Novell > perspective, we have found that 100 different values are TOO many. I > am sure that we can satisfy over 95% of electronic distributed printing > with only 3 values. Scott, I agree with you entirely here on this critical top-level position. How many others agree or disagree to this basic premise as proposed by Scott? We can cut out all kinds of issue-beating if we all first agree that we MUST have something simple...or at least simpler than what is currently proposed. ...jay From ipp-archive Wed Feb 19 21:15:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA23476 for ipp-outgoing; Wed, 19 Feb 1997 21:12:10 -0500 (EST) Message-ID: <330BB0FB.7947@sharplabs.com> Date: Wed, 19 Feb 1997 18:03:39 -0800 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> Minutes from IPP teleconference 2/19/97 Content-Type: multipart/mixed; boundary="------------236148FD635" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO This is a multi-part message in MIME format. --------------236148FD635 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The following are meeting minutes from the IPP teleconference on Wed. 2/19/97 Meeting duration 1:00 PM PST to 3:10 PST Since I got to the meeting 10 minutes late, Scott may want to add any comments to these minutes that happened during the first few minutes of the teleconference. The bulk of the meeting covered open issues with the Scenarios/ Requirements subgroup, as well as the Model subgroup. The issues covered in each subgroup and the new status of each issue (if any) are outlined in the enclosed attachment: Randy -- Randy Turner Network Architect Sharp Laboratories of America rturner@sharplabs.com --------------236148FD635 Content-Type: text/plain; charset=us-ascii; name="ipp021997.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ipp021997.txt" Meeting Minutes - IPP 2/19/97 Teleconference Steve Zilles Jim Walker Lee Farrell Peter Zehler Roger DeBry Scott Isaacson Jeff Copeland Mabry Dozier Bob Herriott Stan McConnell What is the process for closing open issues? The chair of the working group will declare status of issues once he/she determines rough concensus has been reached. Requirements Issues were reviewed. Item #4 Should print-file be changed to send-file? or is there something else going on here? #12 HTTP request to retrieve the appropriate driver installer - recommended outside IPP scope (closed) #13 Do we define some standard for cost of a page? (Outside scope of initial IPP effort) (closed) #37 Still open - objective attributes vs. subjective attributes #45 Has been changed (closed) #48 Fan-in issue (Tom will write up something, open) #49 closed #50 Need to look at translating user requests/desires to directory service attributes (Yes we need to do this, closed) #51 Add user-attended/operator-attended operation (passed to model group) #54 Boolean operation supported in DS query #56 Scenarios might be more clear if identified as intranet or internet (already covered in document, closed) #57 closed #59 Scenario 3.8 is user required to know what PDL is used in his/her job (changed in document so user doesn't need to know, closed) #60 How does HTML printing handle links? (outside scope of initial IPP work, closed) #61 #62 All queued jobs visible? (no, but the position of the clients' jobs will be visible, but the protocol does allow full disclosure. closed?) #63 Does ListJob include completed jobs? What does ListJob return? (Bob H. will define ListJob modifiers, closed) #64 Scenario 4.2, change "getting status" to "get capabilities" (done, closed) #65 Is there a scenario for "presubmitting" jobs? (closed, out of scope) #66 Should resource references (summary) be part of the metadata instead of the print job? (in the model document, closed) #67 Add scenario for multiple-document jobs (already done, closed) ---------------------------------------------------------------------------------------------------------- Model subgroup issues review: #2 What is the URL format for a job identifier? (Use what is returned by the server, with the exception of what is defined by the IETF with regards to URL format, the remainder of the URL is opaque to clients) -- closed? #3 Add an attribute to the printer that will indicate URI for driver installer? (open #4 Is "Media ready" part of the directory service entry (work to be done, open) #7 Specify which attributes are mandatory and what is optional (work to be done, open) #11 Information about security details and payments will be part of the printer information and not directory service (open) #13 For a "print" operation, should other attributes and status associated with the job be returned, along with the new job URL/URI? (open) #14 Should IPP document abstracts list all associated documents so reader knows to retrieve other necessary documents? (sure, why not, closed) #16 Version 1.2 states there is an optional message and optional error information in the operation responses - this needs to be cleaned up. (open) #17 Bob H. will review wording (open) #18 The term "Best-effort" will be elaborated (clarified in several contexts) in the documents (open) #19 Clarify adornment to this status (closed) #20 (Not covered during conference call) #21 (Not covered during conference call) --------------236148FD635-- From ipp-archive Thu Feb 20 01:30:49 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA25006 for ipp-outgoing; Thu, 20 Feb 1997 01:27:53 -0500 (EST) Message-Id: <9702200534.AA08750@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Feb 1997 21:33:01 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Comments on printer-state, printer-state-reasons viz a viz Printer MIB Cc: pmp@pwg.org Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I've posted some comments on the printer-state, printer-state-reasons, and printer-state-as-text IPP attributes: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ -rw-r--r-- 1 pwg pwg 20992 Feb 20 05:17 printer-state-comments-tnh.doc -rw-r--r-- 1 pwg pwg 19424 Feb 20 05:18 printer-state-comments-tnh.pdf Bob and I are proposing a drastically reduced set of printer states: unknown, idle, processing (Bob prefers: printing), and mixed. The printer-state-reasons attribute indicates: (1) orthogonical states, such as printer disabled from accepting Print operations and printer paused (by operator) so maps cleanly to ISO DPA (2) printer conditions (binary change events from the Printer MIB). I've copied the pmp list as well, to see if they agree with the idea of how to represent all of the Printer MIB binary change events, both critical and warning as values of the Printer's printer-state-reasons attribute. Please send comments to the ipp list with "MOD -" as the first 5 characters of the subject line. Thanks, Tom From ipp-archive Thu Feb 20 02:05:48 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA25563 for ipp-outgoing; Thu, 20 Feb 1997 02:02:24 -0500 (EST) Message-Id: <9702200701.AA08795@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Feb 1997 22:59:50 PST To: ipp@pwg.org From: Tom Hastings Subject: Re: IPP> MOD - Push back on simplifying Print operation response Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Larry, HTTP convenor, points out that HTTP 1.1 has concept of connections, so that a client could perform a Print Operation followed by two Get-Attributes operations, one to the Job using the URL returned in the Print operation and one to the Printer using the same URL that the requester supplied in the Print operation, as a single connection rather than the 3 complete set up/tear down connections that HTTP 1.0 requires. However, if the real Printer state of interest is not the Printer to which the client submitted the Print operation to, but is some downstream Printer or output device that the submitter couldn't even know about, then the requester doesn't know what Printer URL to pass in the second Get-Attributes operation to get the Printer state, if the original Printer object fans out to several other Printer objects or to more than one output device or forwards the jobs to another Printer. Currently there is no job status attribute that returns a URL of the Printer to which the job has been assigned, only output-device-assigned which returns the text string name, not a URL. If a Printer fans out to several output devices or forwards the job to another Printer, there isn't a way in the current IPP Model to get the status of the particular output device that the job is using or will be using. That is why in ISO DPA, we have a job-status *job* attribute called printer-state-of-printers-assigned, so that a client could determine the state of the printer(s) that a job was using or was going to use simply by specifying the job-identifier as the input parameter in a Get-Attributes operation. The client doesn't have to know anything about fan-out and does not have to know anything about the printer configuration. Also the ISO DPA Printer operation returns the value of the job's printer-state-of-printers-assigned attribute in the Print result, so the client doesn't need to make another query of the server to get the Printer state and the client gets the proper printer state, independent of the configuraion of the printers. So even though the efficiency argument is no longer valid, assuming that HTTP 1.1 will be being used when heavy traffic use of IPP is a reality, the simplicity to the client of requiring the return of the printer-state, and printer-state-reasons, in the Print operation response is still compelling to me. Getting the printer status right after the Print submission is something we want to have work with all Printer implementations and all Printer configurations; we do not want to require the client to do different tricky additional operations depending on the Printer implementaton and the Printer configuration. Now that IPP has both a simple printer-state and a printer-state-reasons, both need to be returned in the Print operation. The most recent proposal that I just sent out on printer-state and printer-state-reasons proposes that the needs-attention is not a printer-state, but a printer-state-reasons condition, since an idle and a processing printer can need attention (usually, its a processing Printer that needs attention, but an idle printer could get too hot, or a user could remove an input tray from an idle printer, or open a door). On the other hand, we could have the Print operation return two URLs (instead of any Job and Printer status and reasons): one for the job and one for the Printer to be used to get printer status for this job (and add a corresponding printers-assigned-urls job status attribute to the job object, so that a client could determine what Printer URL to use later). Then the client could make two subsequent Get-Attribute calls in the same HTTP 1.1 connection after getting the response from the Print operation. A third alternative would be for Print to return only the Job URL, but the client could request any job attributes in the first Get-Attributes operation on the job, including the new job attribute: printers-assigned-urls. The client would use the value(s) returned from the printers-assigned-urls to get the status of the printers that were assigned to the job. Comments? Tom >Return-Path: >Sender: masinter@parc.xerox.com >Date: Tue, 18 Feb 1997 23:00:42 PST >From: Larry Masinter >Organization: Xerox PARC >To: Tom Hastings >Subject: Re: IPP> MOD - Push back on simplifying Print operation response >References: <9702190726.AA08440@zazen.cp10.es.xerox.com> > >http/1.1 doesn't set up & tear down connectiosn for every >call any more. > > From ipp-archive Thu Feb 20 03:30:48 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA26271 for ipp-outgoing; Thu, 20 Feb 1997 03:29:32 -0500 (EST) Message-ID: <330C0B89.118D@parc.xerox.com> Date: Wed, 19 Feb 1997 23:30:01 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Tom Hastings CC: ipp@pwg.org Subject: Re: IPP> MOD - Push back on simplifying Print operation response References: <9702200701.AA08795@zazen.cp10.es.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO There's a good architectural principle in web applications that anything you want to name you should name with a UR*. So, if you're really thinking of doing this using the web (whether HTTP or some other future web protocol), then it's probably a good idea for each job (once submitted) to have its own URL, rather than its own job-id. (Of course, the URL will probably be http://printer.name/job/job-id or some such, but the architecture doesn't have to know that.) It does make sense to return the status of both the job and of the printer to which the job has been assigned in a single get status request, but it also makes sense to be able to ask a job the URL of the printer it was assigned to, e.g., if the job failed for printer reasons, to query the printer more carefully. I just think you probably will do fine if you worry about the semantics of the operations rather than the performance of setup and teardown for operations that occur as infrequently as print requests. Larry From ipp-archive Thu Feb 20 03:55:47 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA26686 for ipp-outgoing; Thu, 20 Feb 1997 03:55:43 -0500 (EST) Date: Thu, 20 Feb 1997 00:54:16 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199702200854.AAA15456@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP> IPP >MOD: new model document Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have downloaded the newest versions of the model document to ftp://pwg/pub/ipp/new_MOD/ipp-model-1.3-rev.doc and ftp://pwg/pub/ipp/new_MOD/ipp-model-1.3-rev.ps The changes are all marked with revision marks and are primarily in sections 4 and 5. Section 5.1 still needs work. Bob Herriot   From ipp-archive Thu Feb 20 07:40:50 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA28119 for ipp-outgoing; Thu, 20 Feb 1997 07:39:26 -0500 (EST) Message-Id: <9702201239.AA08890@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen (Unverified) X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Feb 1997 04:37:31 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Comments on printer-state, printer-state-reasons viz a viz Printer MIB Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I'd like to discuss this issue on printer-state this Friday, 2/21 at the 1:00pm PST (4:00 pm EST) IPP Model telecon. Thanks, Tom >Date: Wed, 19 Feb 1997 21:33:01 -0800 >To: ipp >From: Tom Hastings >Subject: MOD - Comments on printer-state, printer-state-reasons viz a viz Printer MIB >Cc: pmp > >I've posted some comments on the printer-state, printer-state-reasons, and >printer-state-as-text IPP attributes: > >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ > >-rw-r--r-- 1 pwg pwg 20992 Feb 20 05:17 printer-state-comments-tnh.doc >-rw-r--r-- 1 pwg pwg 19424 Feb 20 05:18 printer-state-comments-tnh.pdf > >Bob and I are proposing a drastically reduced set of printer states: unknown, idle, processing (Bob prefers: printing), and mixed. > >The printer-state-reasons attribute indicates: > > (1) orthogonical states, such as printer disabled from accepting Print operations > and printer paused (by operator) so maps cleanly to ISO DPA > (2) printer conditions (binary change events from the Printer MIB). > >I've copied the pmp list as well, to see if they agree with the idea >of how to represent all of the Printer MIB binary change events, both >critical and warning as values of the Printer's printer-state-reasons attribute. > >Please send comments to the ipp list with "MOD -" as the first 5 characters of the >subject line. > >Thanks, >Tom > From ipp-archive Thu Feb 20 10:20:51 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA29351 for ipp-outgoing; Thu, 20 Feb 1997 10:18:54 -0500 (EST) Message-Id: <1.5.4.32.19970220151945.0069c4a0@pop.mindspring.com> X-Sender: manros@pop.mindspring.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Feb 1997 07:19:45 -0800 To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> IPP >MOD: new model document Sender: ipp-owner@pwg.org Precedence: first-class Status: RO At 12:54 AM 2/20/97 -0800, you wrote: >I have downloaded the newest versions of the model document to > >ftp://pwg/pub/ipp/new_MOD/ipp-model-1.3-rev.doc and >ftp://pwg/pub/ipp/new_MOD/ipp-model-1.3-rev.ps > >The changes are all marked with revision marks and are primarily in >sections 4 and 5. Section 5.1 still needs work. > >Bob Herriot > > > > > Bob, I have just put up a PDF version of your document (with the revision marks removed) on the server. the reference is: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-1.3.PDF The references above are missing a few components... Carl-Uno From ipp-archive Thu Feb 20 10:50:52 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA29874 for ipp-outgoing; Thu, 20 Feb 1997 10:47:04 -0500 (EST) Message-Id: <199702201547.AAA13875@gloria.rdc.ricoh.co.jp> To: ipp@pwg.org Subject: IPP> MOD - Comments on printer-state, printer-state-reasons viz aviz Printer MIB In-Reply-To: Your message of "Thu, 20 Feb 1997 04:37:31 PST" References: <9702201239.AA08890@zazen.cp10.es.xerox.com> X-Mailer: Mew version 1.00 on Emacs 19.31.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Fri, 21 Feb 1997 00:47:32 +0900 From: Tetsuya Morita Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Tom, Some comments on your "printer-state-comments-tnh.doc". > >Bob and I are proposing a drastically reduced set of printer states: > unknown, idle, processing (Bob prefers: printing), and mixed. If you delete 'needs-attention' and move it to 'printer-state-reasons', you should change the definition of role of 'printer-state-reasons'. They were defined as the reasons in the state of 'needs-attention'. It is noted in 5.6.1.2 printer-state-reasons on model-1.3. What is the actual definitions and the difference in client's usage of 'printer-state' and 'printer-state-reasons'? Now I am confused on that point. > > Tom's States Ricoh's States Comments > > ============================================================================ > > shutdown power-off Same meaning > now proposed to be a printer-state-reason, ok? > > > processing executing Same meaning > > needs-attention error needs-attention and needs-key-operator > included > now proposed to be a printer-state-reason, ok? > > unknown unknown Same meaning > > idle idle Same meaning I would like to answer your question after the both definitions are cleared. Thanks, --- Tetsuya Morita Ricoh Company Ltd. Printer Business Center From ipp-archive Thu Feb 20 11:30:51 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA00439 for ipp-outgoing; Thu, 20 Feb 1997 11:30:19 -0500 (EST) From: Keith_Carter@aussmtp.austin.ibm.com X-Lotus-FromDomain: AUSNOTES To: ipp@pwg.org Message-ID: <86256444:0059A585.00@aussmtp3.austin.ibm.com> Date: Thu, 20 Feb 1997 10:21:29 -0500 Subject: IPP> MOD - Next conference call Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Model and Semantics Team, I've been out. When is the next conference call for the Model and Semantics group? What is the phone number/password? Today, I'll provide my comments on the 1.3 spec and Tom's document on printer states/reasons. Thanks, Keith From ipp-archive Thu Feb 20 16:40:55 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA02533 for ipp-outgoing; Thu, 20 Feb 1997 16:40:10 -0500 (EST) From: Keith_Carter@aussmtp.austin.ibm.com X-Lotus-FromDomain: AUSNOTES To: ipp@pwg.org Message-ID: <86256444:00766C6A.00@aussmtp3.austin.ibm.com> Date: Thu, 20 Feb 1997 15:37:46 -0500 Subject: IPP> MOD - Comments on version 1.3 of Model and Semantics spec Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Model and Semantics Team, Here are my comments on version 1.3 of the IPP 1.0: Model and Semantics spec. I'll comment on Tom's document on printer status on 2/21. Enjoy! Keith 1. Section 3.2. Job. Page 8. Line 302. Remove "This list needs updating:" from list. 2. Section 4.1.3.1. Get-Attributes Request. Page 12. Line 419. In my opinion, we should list the special attribute groups referred to in the subsequent sections of the spec so it is clear to the reader that an IPP application may specify these groups in a Get-Attributes request. These attributes groups include: - identification (5.2.1) - jobClient (5.3) - jobTemplate (5.3) - jobNotification (5.3.2) - jobScheduling (5.3.3) - jobProduction (5.3.4) - documentProduction (5.3.5) - textFormatting (5.3.7) - jobSize (5.3.8) - numberOfDocuments (5.3.9) - jobSetByPrinter (5.4) - jobOwner (5.4.1) - jobStatus (5.4.2) - documentData (5.4.3) - printerDescription (5.5) - printerStatus (5.6) - printerBehavior (5.7) 3. Section 5.1. User privilege level. Page 17. Line 530. The security model implied by the "User privilege level" tag is not clear to me. I believe a Printer should know the role (i.e. end-user, operator, admin) of the user making a print request and should only return attributes that apply to a person with that role for that Printer. I do not believe a Printer should rely on a client to sort through which attributes apply to a user based on the client's understanding of the user's role. See my notes for section 6, Security Considerations for more information. 4. Section 5.1. File type. Page 17. Line 536. In my opinion, the "File type" tag is too complex for IPP 1.0. I believe the "File type" tag implies (1) an IPP application must first determine the datatype of a document to be printed (2) the application must then parse through attributes returned by the Printer to pick out those that apply to that datatype (3) a Printer implementation must tag these attributes in the first place. Typically, I see administrators setup a separate Printer for each datatype supported by a physical device. For example, for a device that supports PCL and Postscript, there will be 2 Printers. Each Printer has its own printer driver (i.e. a PCL or Postscript printer driver) with default job properties (i.e. job template) supported by the driver. 5. Section 5.1. Scheduling. Page 18. Line 547. What specific attributes can have the "Scheduling" tag? What is a scenario that shows how this tag will be used? 6. Section 5.1. no tag. Page 18. Line 572. "... this value and schedule it ..." should be "... this value and schedule the job when ...". 7. Section 5.3.2.1. notification-events. Page 22. Line 690. This section needs to specify the events for which an end-user will implicitly receive notification. Line 709-710 implies that an end-user will always receive a notification if their job is cancelled. So, that explains why there is not a notification event called "job-cancelled". This statement also implies a required behavior of a Printer. This information might be more clear to the reader if it is stated in the notification-events section. Here is a proposed paragraph: A Printer must notify an end-user when their job is cancelled and therefore will not be printed by the Printer. Or, we can decide to add a "job-cancelled" value. 8. Section 5.3.2.1. notification-events. Page 22. Line 690. Here is an idea. It is possible that an end-user's job might be held or resubmitted outside the context of IPP 1.0. The spec could add support for "job-held" and "job-resubmitted" notification events or else indicate that these are implicit ala "job-cancelled". Opinions? 9. Section 5.3.3.1. job-priority. Page 23. Line 722. Please change job-priority to a positiveInteger with values 0-100 because: (1) this matches the Job MIB (2) this supports ISO DPA (3) this supports PC platforms. 10. Section 5.3.3.2. job-retention-period. Page 24. Line 774-775. Add to the NOTE: "The requester may also specify this job attribute using the input parameter to the Print operation." Correct? 11. Section 5.3.4.2. copies. Page 26. Line 844-845. Remove this note because files-are-one-document and files-are-interleaved are not defined in the spec. 12. Section 5.3.5.2. medium. Page 30. Line 896. I recommend an additional input-tray of "automatic" since some printers automatically select the input tray based on the media requested by the end-user. 13. Section 5.3.6.1. document-format. Page 34. Line 975. The list of document-formats should be referenced in this section. Possibly include the formats in an appendix or reference another spec. 14. Section 5.3.7. Text Formatting. Page 34. Line 981. Please consider adding the following attributes: * Font Style (normal, bold, italic, bold-italic) * Line Numbers (print line numbers in the left margin) * Text Border (print a border around the text) * Word Wrap (wrap or don't wrap long lines) * Number of Columns (single or multi-column text) * File Name (print file name per page) * File Time (print time of file per page) * File Date (print date of file per page) 15. Section 5.3.7 Text Formatting. Page 34. Line 981. Can Document Production Attributes, such as sides, apply to printing Text and HTML files? I believe so. If so, then the spec should state this. 16. Section 5.3.7.14. content-orientation. Page 36. Line 1046. In my opinion, content-orientation should be a Document Production attribute. This attribute may apply to all types of print jobs - not just text jobs - including jobs that are converted by an IPP print driver from a graphics API (e.g. Gpi or GDI) to a device datastream such as Postscript or PCL. 17. Section 5.3.9. Number of Documents. Page 37. Line 1079. Nit. How does a Printer specify there is no limit on the number of documents per job? By using an "*" (asterisk) as the upper number of the range? A large number? 18. Section 5.4. Job Attributes. Page 38. Line 1093-1099. The second paragraph indicates that an IPP application can get the URLs of a Printer's Job Templates and references attribute "printer-job-templates" neither of which is supported in IPP 1.0. Here is proposed text for that paragraph with revisions noted as <>: A client may use a job template associated with the selected

rinter to initialize the job. To do so, the client uses the Get-Attributes operation Then the client may get the default attributes, However, a client need not access the ob emplate to issue a Print operation; the client can depend on the Printer to supply the default job attribute values as part of the Print operation. 19. Section 5.4.1.1. job-originating-user. Page 38. Line 1110. The spec should state that job-originating-user is acquired by the Printer from the protocol used for the Print operation. For HTTP 1.0, this would imply use of the Authorization request header field on a Print operation so the Printer can obtain the user id of the end-user who submits the print request. A proposal is to change the word "client" at the end of the second sentence to "protocol". 20. Section 5.4.1.3. user-locale. Page 38. Line 1114. The spec should reference the source of the valid locale values. The reference could be a URL or to an appendix in this spec. 21. Section 5.4.2.2. job-state. Page 40. Line 1137. In my opinion, the "Printing" job-state should only be set if a job is actually being printed by a device. This way, an IPP application can clearly show an end-user when their job is being printed. I propose we use "pending" if the job is being spooled or has been queued for a device and use a job-state-reason to specify why the job is pending. See comment #23 for more information. 22. Section 5.4.2.2. job-state. Page 40. Line 1137. In "Completed" remove "(2) job-discard-time has arrived." since job-discard-time is not supported. 23. Section 5.4.2.2. job-state-reasons. Page 40. Line 1137. Please confirm/correct the following table. An asterisk "*" indicates a combination I don't see in the spec. job state job state reason condition unknown n/a n/a * pending job-spooling job spooling * pending sending-job-to-printer job being sent from client or server to device * pending job-queued job queued pending job-processing job in printer pending required-resources-not-ready paper out etc. pending logfile-pending ? pending logfile-transferring ? * pending job-held job held in queue or device printing n/a job printing terminating cancelled-by-user job ending terminating cancelled-by-operator " terminating aborted-by-system " retained successful-completion job stacked and retained retained completed-with-warnings " retained completed-with-errors " retained cancelled-by-user job cancelled and retained retained cancelled-by-operator " retained aborted-by-system " completed successful-completion job stacked completed completed-with-warnings " completed completed-with-errors " completed cancelled-by-user job cancelled completed cancelled-by-operator " completed aborted-by-system " In my opinion, we should replace "job-incomplete" with "job-spooling", "sending-job-to-printer" and "job-queued" so an IPP application can show the end-user the state of their job throughout the printing process. 24. Section 5.4.2.5. submission-time. Page 41. Line 1149. In the first sentence, specify that submission-time indicates date in addition to time. 25. Section 5.4.2.6. number-of-intervening-jobs. Page 42. Line 1154. Please change "if performed" to "is performed". 26. Section 5.5.1. printer-name. Page 43. Line 1215. In my opinion, the spec should keep the "printer-name" attribute so an Administrator can provide a meaningful name to the Printer. 27. Section 5.5.2.2. printer-type. Page 44. Line 1221. Is printer-type necessary in IPP 1.0? How does this help the end-user? 28. Section 5.5.2.3. maximum-printer-speed. Page 44. Line 1229. "characters per minute" should be "characters per second" to match "cps" in standard units. What is the syntax for 10 ipm? 29. Section 5.6. Printer Status. Page 44-46. I will comment on Printer Status in a separate note. 30. Section 5.7.1.1. printer-locale. Page 47. Line 1286. There is no "job-locale" attribute in the spec plus the locale values are not defined in the spec. Change "job-locale" to "user-locale" and use the reference in "user-locale" as a reference to the valid locale values. 31. Section 5.7.1.4. end-user-acl. Page 47. Line 1289. How is "end-user-acl" used? I believe a Printer should know its acl (i.e. end-user, operator, admin) for the end-user who makes a print operation and, based on this acl, determine if an operation is valid. I do not believe a Printer should return acls to a client and then rely on a client to determine if an end-user is authorized to use a Printer. Besides, I'm not sure we want acl information flowing across the network. I propose we remove this attribute. 32. Section 5.7.1.4. scheduling-algorithm. Page 47. Line 1297. How does this attribute help the end-user? I propose we remove this attribute from IPP 1.0. I believe we removed a similar attribute from the Job MIB. 33. Section 5.7.1. Printer Behavior. Page 47. Line 1283. Please keep "document-formats-supported". This attribute will help an IPP printer driver determine the valid formats for a Printer so that the printer driver can send the most efficient format possible to the Printer. For example, OS/2 supports a metafile format as well as device formats such as PCL and Postscript. It is more efficient to send a metafile across the network if a Printer supports this format in addition to a device format. 34. Section 6. Security Considerations. Page 48. Line 1319-1320. Remove sentence "The authentication mechanism built into HTTP ..." since the spec does not specify a protocol and therefore should not specify HTTP. 35. Section 6. Security Considerations. Page 48. Line 1319-1320. How is an end-user's identity known by the Printer for operations such as CancelJob and GetAttributes? Does IPP assert that the underlying protocol provides the identity of the end-user on print operations? If so, the spec should state so. For HTTP 1.0, this would imply use of the Authorization request header field on such requests (hopefully after the initial logon, the client will cache the user id and password so as not to prompt the end-user to logon for every subsequent print operation). Here is proposed text for this section with revisions noted as <>: This does not identify any new authentication mechanisms. From ipp-archive Thu Feb 20 17:30:57 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA03002 for ipp-outgoing; Thu, 20 Feb 1997 17:27:24 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 20 Feb 1997 15:27:17 -0700 From: Julie-t McCabe To: ipp@pwg.org Cc: Scott_Isaacson@novell.com Subject: IPP> MOD - 2/21 Teleconference Sender: ipp-owner@pwg.org Precedence: first-class Status: RO We will have a Model group teleconference on Friday, 2/21. We need to go over the new Model Doc (version 1.3) and issues. I'll see if I can get a new issues document posted by then. Thanks, Scott Isaacson Confirmation number: 315227 Call in Toll-Free number: 800-937-3082 Friday, 2/21/97 2:00 - 4:00 Mountain Time 15 People Title: Scott Isaacson --Julie McCabe, Admin to Scott From ipp-archive Thu Feb 20 18:30:56 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA03611 for ipp-outgoing; Thu, 20 Feb 1997 18:28:36 -0500 (EST) Date: Thu, 20 Feb 1997 15:26:57 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199702202326.PAA15895@woden.eng.sun.com> To: ipp@pwg.org, hastings@cp10.es.xerox.com Subject: Re: IPP> MOD - Push back on simplifying Print operation response X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO > > My concern is that either: > > 1. User friendly implmentations will make additional protocol calls > to get job and printer status. That means that each Print operation > will require three calls, not one. If we layer on HTTP that means > a new session startup/teardown for each of the three calls. My assumption is that the GUI from which the Print submission is made is a different process from the one showing status in most cases. In such an environment, the Print submission GUI would probably not inform the job status GUI about the changes. The primary issue is whether a print submission GUI (or command) would inform the user of the special case you site below where the printer is stopped and needs attention before it will resume printing. You suggest that there would 3 calls, but I have optimized the Get Jobs operation so that it can request printer status and jobs lists in the same response. > > > If the printer to which you submitted your job was printing > another job and the printer needs attention, you will NOT get a > notification of this problem, even if you specify the > notification-events=printer-problem, because the printer problem > event happened BEFORE you submitted your job. So your job > will sit there until someone else fixes the problem and you > won't know about it even though you asked to be notified of > any printer problems!!! There seem to be two possible solutions to the above problem: 1) If a Printer receives a job with notification-events=printer-problem and the printer is currently stopped, it sends the most recent critical event to the job's notification-address. This actually raises the issue of whether a user's Print Status GUI should be able to indicate interest in the Printer Status, even when the user has no job's in the queue. In such a case, the GUI is up to date and doesn't need this new mechanism. 2) The print request returns a special status, though for HTTP there is no reasonable special status value, so there would have to be some other way, such as via a printer-state value, as you suggest. We should probably discuss this at tomorrow's meeting. > From ipp-archive Thu Feb 20 18:41:03 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA03935 for ipp-outgoing; Thu, 20 Feb 1997 18:37:12 -0500 (EST) Message-ID: From: Babak Jahromi To: "'Robert.Herriot@Eng.Sun.COM'" , "'ipp@pwg.org'" , "'hastings@cp10.es.xerox.com'" Subject: RE: IPP> MOD - Push back on simplifying Print operation response Date: Thu, 20 Feb 1997 15:36:48 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 31 TEXT Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Isn't what you call "print submission GUI" the everyday applications people use? like Word, Excel, Corel, Quicken. etc. etc.? So I wouldn't plan on changing any of it! Babak >-----Original Message----- >From: Robert.Herriot@Eng.Sun.COM [SMTP:Robert.Herriot@Eng.Sun.COM] >Sent: Thursday, February 20, 1997 3:27 PM >To: ipp@pwg.org; hastings@cp10.es.xerox.com >Subject: Re: IPP> MOD - Push back on simplifying Print operation response > > >> >> My concern is that either: >> >> 1. User friendly implmentations will make additional protocol calls >> to get job and printer status. That means that each Print operation >> will require three calls, not one. If we layer on HTTP that means >> a new session startup/teardown for each of the three calls. > >My assumption is that the GUI from which the Print submission is made is >a different process from the one showing status in most cases. In such an >environment, the Print submission GUI would probably not inform the >job status GUI about the changes. The primary issue is whether a print >submission GUI (or command) would inform the user of the special case >you site below where the printer is stopped and needs attention before it >will resume printing. > From ipp-archive Thu Feb 20 18:41:05 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA03919 for ipp-outgoing; Thu, 20 Feb 1997 18:36:24 -0500 (EST) Date: Thu, 20 Feb 1997 15:34:51 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199702202334.PAA15902@woden.eng.sun.com> To: ipp@pwg.org, hastings@cp10.es.xerox.com Subject: Re: IPP> MOD - Pushback on removing job-hold-until/job-print-after and page-select X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO > From hastings@cp10.es.xerox.com Tue Feb 18 23:38:40 1997 > > Since Job-Hold-After and Job-Print-After etc are not extremely critical ... > > TH> Did you consider dropping the relative form of time. I see no value > in specifying that a job be held for a relative amount of time. > But an absolute time or a time period seems simple enough. How > about just those? What were the problems with them? If not, lets > keep it in. If there are, I agree that this attribute isn't as > critical as others. The problem with absolute time is that it doesn't work in the job template, either for supported values for the default value, unless and an administrator changes the Printer's values frequently. The concept was getting more and more difficult to make work and it seemed to be of marginal value. > > > Item 8: > > The same (see Item 7) is true for page-select. Remove it from IPP/1.0. > > > TH> I feel much more strongly about keeping page-select, since > it is something that you can do on every Windows and MAC today > (and for many years). How can IPP V1.0 not support what is > done by 100M clients today? We used the same reasoning here. The syntax of the value was complex and the feature didn't seem to be very important in the IPP context. You are right that a user can select pages in Windows and MACs today, but the selection does not stay as an attribute, the driver makes the selections and produces a PostScript/PCL with fewer pages. What this IPP attribute allows is for someone to print a subset of pages of a text or PostScript file. Is that important? From ipp-archive Thu Feb 20 19:10:57 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA04695 for ipp-outgoing; Thu, 20 Feb 1997 19:06:47 -0500 (EST) Message-Id: <199702210007.AA12967@interlock.lexmark.com> To: "ipp%pwg.org" From: Don Wright Date: 20 Feb 97 17:29:33 EST Subject: IPP> 2/19/97 IPP Conference Call Minutes Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="-- next item ----" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO This is the preamble of an RFC-1341 encoded, mixed message. ---- next item ---- Content-Type: Text/Plain I have incorporated some additional notes from Scott Isaacson into Randy's notes and posted the minutes from yesterday's conferece call on the server: ftp://www.pwg.org/pub/pwg/ipp/minutes/970219-ipp-conference-call.doc ftp://www.pwg.org/pub/pwg/ipp/minutes/970219-ipp-conference-call.ps ftp://www.pwg.org/pub/pwg/ipp/minutes/970219-ipp-conference-call.pdf ftp://www.pwg.org/pub/pwg/ipp/minutes/970219-ipp-conference-call.txt Additionally, for the computationally impaired, I have attached the text version to this note. Thanks Randy and Scott! Don ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* ---- next item ---- Content-Type:Text/Plain; Name="970219~1.TXT" Internet Printing Project Conference Call - February 19, 1997 Attendees: Steve Zilles - Adobe Jim Walker - Dazel Lee Farrell - Canon Peter Zehler - Xerox Roger DeBry - IBM Scott Isaacson - Novell Jeff Copeland - QMS Mabry Dozier - QMS Bob Herriott - SUN Stan McConnell - Xerox Randy Turner - Sharp In the absence of Carl-Uno Manros, the conference call was run by Scott Isaacson. Minutes were taken by Randy Turner 1. Co-Chair There was an open discussion about the proposal that Steve Zilles from Adobe be named co-chair for the IPP IETF working group. The only comment was a question to Steve about how much he was going to be participating. He responded say that he would be mainly responsible for publicizing IPP within the IETF and IESG. He would also participate in all of the meetings and the teleconferences. 2. FTP Structure All minutes and issues lists from each sub group should go under each new_ directory, not in the general minutes and actions directories. 3. Requirements I-D Comments on the new I-D posted by Don are due 3/5. 4. IETF The deadline for I-D submission to IETF is 3/26 5:00 pm Eastern 5. Model Sub-Group Model telecon Friday 2/21 2-4 MST 6. Open Issues Process What is the process for closing open issues? The chair of the working group will declare status of issues once he/she determines rough concensus has been reached. 7. Requirements Issues were reviewed. Item #4 Should print-file be changed to send-file? or is there something else going on here? #12 HTTP request to retrieve the appropriate driver installer - recommended outside IPP scope (closed) #13 Do we define some standard for cost of a page? (Outside scope of initial IPP effort) (closed) #37 Still open - objective attributes vs. subjective attributes #45 Has been changed (closed) #48 Fan-in issue (Tom will write up something, open) #49 closed #50 Need to look at translating user requests/desires to directory service attributes (Yes we need to do this, closed) #51 Add user-attended/operator-attended operation (passed to model group) #54 Boolean operation supported in DS query #56 Scenarios might be more clear if identified as intranet or internet (already covered in document, closed) #57 closed #59 Scenario 3.8 is user required to know what PDL is used in his/her job (changed in document so user doesn't need to know, closed) #60 How does HTML printing handle links? (outside scope of initial IPP work, closed) #61 #62 All queued jobs visible? (no, but the position of the clients' jobs will be visible, but the protocol does allow full disclosure. closed?) #63 Does ListJob include completed jobs? What does ListJob return? (Bob H. will define ListJob modifiers, closed) #64 Scenario 4.2, change "getting status" to "get capabilities" (done, closed) #65 Is there a scenario for "presubmitting" jobs? (closed, out of scope) #66 Should resource references (summary) be part of the metadata instead of the print job? (in the model document, closed) #67 Add scenario for multiple-document jobs (already done, closed) 8. Model subgroup issues review: #2 What is the URL format for a job identifier? (Use what is returned by the server, with the exception of what is defined by the IETF with regards to URL format, the remainder of the URL is opaque to clients) -- closed? #3 Add an attribute to the printer that will indicate URI for driver installer? (open #4 Is "Media ready" part of the directory service entry (work to be done, open) #7 Specify which attributes are mandatory and what is optional (work to be done, open) #11 Information about security details and payments will be part of the printer information and not directory service (open) #13 For a "print" operation, should other attributes and status associated with the job be returned, along with the new job URL/URI? (open) #14 Should IPP document abstracts list all associated documents so reader knows to retrieve other necessary documents? (sure, why not, closed) #16 Version 1.2 states there is an optional message and optional error information in the operation responses - this needs to be cleaned up. (open) #17 Bob H. will review wording (open) #18 The term "Best-effort" will be elaborated (clarified in several contexts) in the documents (open) #19 Clarify adornment to this status (closed) #20 (Not covered during conference call) #21 (Not covered during conference call) The meeting was concluded. Internet Printing Project 02/19/97 Conference Call Minutes 1 ---- next item ------ From ipp-archive Thu Feb 20 21:21:01 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA05362 for ipp-outgoing; Thu, 20 Feb 1997 21:18:34 -0500 (EST) Date: Thu, 20 Feb 1997 18:17:04 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199702210217.SAA16024@woden.eng.sun.com> To: ipp@pwg.org, Keith_Carter@aussmtp.austin.ibm.com Subject: Re: IPP> MOD - Comments on version 1.3 of Model and Semantics spec X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have incorporate most of your comments, as well as those from Roger and Tom. I will put a new version 1.31 out on the Web tonight. But here are comments for ones I didn't put in the new version. > From Keith_Carter@aussmtp.austin.ibm.com Thu Feb 20 13:41:02 1997 > > 8. Section 5.3.2.1. notification-events. Page 22. Line > 690. > > Here is an idea. It is possible that an end-user's job > might be held or resubmitted outside the context of IPP > 1.0. The spec could add support for "job-held" and > "job-resubmitted" notification events or else indicate > that these are implicit ala "job-cancelled". Opinions? I see job-held as a job-state-reasons and not a job-state value. It is not currently in the document because there is no way to change its value. We have not specified whether there is a job-held attribute or a hold/release operation. We have not addressed whether such events are covered under an existing event, such as job-problems, or some new event. > > 10. Section 5.3.3.2. job-retention-period. Page 24. Line > 774-775. > > Add to the NOTE: "The requester may also specify this > job attribute using the input parameter to the Print > operation." Correct? No, the job-retention-period is an attribute that accompanies a job in the Job and Document Attributes parameter. > > > 12. Section 5.3.5.2. medium. Page 30. Line 896. > > I recommend an additional input-tray of "automatic" > since some printers automatically select the input tray > based on the media requested by the end-user. I think that "automatic" is the same as "as-is", in that it says to use whatever is in the document data which may be nothing. So the issue is whether to call the value "automatic" or "as is" > > 13. Section 5.3.6.1. document-format. Page 34. Line 975. > > The list of document-formats should be referenced in > this section. Possibly include the formats in an > appendix or reference another spec. > > > > 16. Section 5.3.7.14. content-orientation. Page 36. Line > 1046. > > In my opinion, content-orientation should be a Document > Production attribute. This attribute may apply to all > types of print jobs - not just text jobs - including > jobs that are converted by an IPP print driver from a > graphics API (e.g. Gpi or GDI) to a device datastream > such as Postscript or PCL. Please say more. I have assume that a graphics API (e.g. GDI) includes the content orientation and for that matter the page layout, so it doesn't make sense to specify content-orientation, which in my view specifies the first level of page layout. > > 17. Section 5.3.9. Number of Documents. Page 37. Line > 1079. > > Nit. How does a Printer specify there is no limit on > the number of documents per job? By using an "*" > (asterisk) as the upper number of the range? A large > number? We haven't yet specified how one end of a range is open. But if the syntax is 'a:b', then either 'a:' or 'a:*' could mean that the range has no upper bound. > > 26. Section 5.5.1. printer-name. Page 43. Line 1215. > > In my opinion, the spec should keep the "printer-name" > attribute so an Administrator can provide a meaningful > name to the Printer. > The printer-name attribute was renamed 'name' and moved to the common attributes section which also contains URL. > 27. Section 5.5.2.2. printer-type. Page 44. Line 1221. > > Is printer-type necessary in IPP 1.0? How does this > help the end-user? I agree. > From ipp-archive Thu Feb 20 21:26:00 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA05667 for ipp-outgoing; Thu, 20 Feb 1997 21:24:05 -0500 (EST) Message-Id: <3.0.32.19970220182427.00e2e050@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 20 Feb 1997 18:24:28 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> MOD - Some comments on content Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have a few comments for our MOD conference tomorrow: 1) Scope We start having a considerable amount of detail about Semantics, but the Model part is still fairly thin. I had expected to see a little more about the total IPP environment under Model e.g. containing some descriptions on how IPP relates to other services that it will use such as Directory and Security (the SEC group will try to contribute some material on the latter). I also think that the Model part should explain some of our design principles, such as "best effort", "late binding" of parameters etc. We have had extensive discussions on these subjects, but I feel that they are not yet properly reflected in the right places in the document. Are still talking about HTTP in a couple of places (we did in 1.2). These need to be replaced with some transport independent formulations. 2) There seem to be a number of attributes that were discussed as scenario or directory attributes, which I cannot find in the Model document. Were they just ignored by the Model subgroup? What happened to I18N? 3) Several of the attribute semantics in 5.4.3 seem to indicate that there is only one document per job. This needs to be fixed. We need to describe the text so it is obvious that one document can be included, and another one referenced in the same job, which I assume we still want to allow? 4) I still think that we should talk about documents as objects (even if we do not have any operations on them in ths version). DPA waffled about objects - do we really want to produce yet another standard that is only quasi-object-oriented? 5) The number and granularity of the operations still needs discussion. My suggestion is to split up the Print operation into several steps (at leat separating the attributes from the actual document data into two operations. Roger might have suggested even more of a split. You can more easily combine operations when you map them to transport, but you cannot start splitting them up (or you will violate the Model). Any comments about HTTP efficiency seem totally irrelevant, what is relevant is that several operations over e-mail might be akward, but they could be packaged together in a MIME type to solve that problem :-> 6) Don't forget the cross-check against RFC 1179. All in all, I do not think we are quite as far on this document as some tend to think. See you on the phone tomorrow. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Thu Feb 20 23:16:01 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA06059 for ipp-outgoing; Thu, 20 Feb 1997 23:13:49 -0500 (EST) Date: Thu, 20 Feb 1997 20:12:19 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199702210412.UAA16120@woden.eng.sun.com> To: ipp@pwg.org Subject: Re: IPP> MOD - new model document version 1.3.1 X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have now put another version of the model document on the pwg server. It is a small upgrade from yesterday's version 1.3. They are: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-1.3.1-rev.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-1.3.1-rev.ps Changes since 1.3: All changes are marked with revision marks since 1.2. The changes from 1.3 to 1.3.1 are in a different color from those from 1.2 to 1.3. Section 5.1, Attribute Syntax (lines 491 to 541) has been extensively revised to clean it up. I have incorporated many short fixes suggested by Tom, Roger and Keith, though some are just marked as ISSUES. Please scan these changes for tomorrow's meeting. Except for section 5.1, the changes are mostly minor. Bob Herriot From ipp-archive Fri Feb 21 04:31:04 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA06854 for ipp-outgoing; Fri, 21 Feb 1997 04:26:43 -0500 (EST) Message-Id: <9702210926.AA09209@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen (Unverified) X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Feb 1997 01:24:49 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Issues with the Model V1.2 (and V1.3) Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I've posted a list of additional issues with the Model V1.2 (and V1.3) model spec which I'd like to cover at the Friday, 1:00pm telecon (after considering the proposal for printer-state). ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/isstnh02.PDF ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/isstnh02.doc -rw-r--r-- 1 pwg pwg 17920 Feb 21 09:08 isstnh02.doc -rw-r--r-- 1 pwg pwg 19169 Feb 21 09:08 isstnh02.pdf I've put them in the same format as Scott's issues list so he can more easily append it. I've also started numbering my issues at 22 where his list ended on Wednesday. My issues go from 22 to 64. I used numbered lists so its easy to change all of them. Thanks, Tom From ipp-archive Fri Feb 21 10:06:06 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA07693 for ipp-outgoing; Fri, 21 Feb 1997 10:05:45 -0500 (EST) Message-Id: <199702211505.KAA07688@lists.underscore.com> Date: Fri, 21 Feb 97 08:04:41 MST From: "Harry Lewis " To: ipp@pwg.org Subject: IPP> RE: MOD - Push back on simplifying Print operation response Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Sorry for the multitude of embeds, but this thread touches on something that has been bothering me about IPP. I'm not judging which is the right or wrong approach, but either we're building IPP for the scenario where standard desktop applications (i.e. Babak's response), run on a traditional desktop OS but the WEB underlies communications and print submission *OR* we're building IPP for the NC (thin-client) world where the WEB *IS* the OS and applications or applets, which have been modified to run in this environment, now use print services based on IPP. Or both, inevitably staged, based on Microsoft's NT5.0 direction. Where is the real focus of IPP? >Isn't what you call "print submission GUI" the everyday applications >people use? like Word, Excel, Corel, Quicken. etc. etc.? > >So I wouldn't plan on changing any of it! > >Babak > >>-----Original Message----- >>From: Robert.Herriot@Eng.Sun.COM [SMTP:Robert.Herriot@Eng.Sun.COM] >>Sent: Thursday, February 20, 1997 3:27 PM >>To: ipp@pwg.org; hastings@cp10.es.xerox.com >>Subject: Re: IPP> MOD - Push back on simplifying Print operation response >> >> >>> >>> My concern is that either: >>> >>> 1. User friendly implmentations will make additional protocol calls >>> to get job and printer status. That means that each Print operation >>> will require three calls, not one. If we layer on HTTP that means >>> a new session startup/teardown for each of the three calls. >> >>My assumption is that the GUI from which the Print submission is made is >>a different process from the one showing status in most cases. In such an >>environment, the Print submission GUI would probably not inform the >>job status GUI about the changes. The primary issue is whether a print >>submission GUI (or command) would inform the user of the special case >>you site below where the printer is stopped and needs attention before it >>will resume printing. From ipp-archive Fri Feb 21 10:06:07 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA07554 for ipp-outgoing; Fri, 21 Feb 1997 10:02:16 -0500 (EST) From: Keith_Carter@aussmtp.austin.ibm.com X-Lotus-FromDomain: AUSNOTES To: ipp@pwg.org Message-ID: <86256445:00494FF7.00@aussmtp3.austin.ibm.com> Date: Fri, 21 Feb 1997 09:01:21 -0500 Subject: RE: IPP> MOD - COMMENTS ON VERSION 1.3 OF MODEL AND SEMANTICS SPE Mime-Version: 1.0 Content-type: text/plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Bob, Thanks for editing the IPP model and semantics spec and your response. My response noted inline as KC>> Keith To: Keith Carter cc: From: DELEGATE @ AUSVMR Date: 02-20-97 08:23:52 PM Subject: RE: IPP> MOD - COMMENTS ON VERSION 1.3 OF MODEL AND SEMANTICS SPE To: KCARTER --AUSNOTES From: DELEGATE Subject: RE: IPP> MOD - COMMENTS ON VERSION 1.3 OF MODEL AND SEMANTICS SPE +--------------------------------------------------------------------------+ H The following note is being forwarded from KCARTER at AUSVMR. H H DO NOT USE the F6 REPLY function to reply to this note. You must H H contact the sender directly if you wish to reply, and not DELEGATE. H +--------------------------------------------------------------------------+ ---------------------------- Note: ------------------------------------- Received: from lists.underscore.com by vnet.IBM.COM (IBM VM SMTP V2R3) with Thu, 20 Feb 97 21:21:04 EST Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7 Received: by pwg.org (bulk_mailer v1.5); Thu, 20 Feb 1997 21:19:34 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA Date: Thu, 20 Feb 1997 18:17:04 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199702210217.SAA16024@woden.eng.sun.com> To: ipp@pwg.org, Keith_Carter@aussmtp.austin.ibm.com Subject: Re: IPP> MOD - Comments on version 1.3 of Model and Semantics spec X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I have incorporate most of your comments, as well as those from Roger and Tom. I will put a new version 1.31 out on the Web tonight. But here are comments for ones I didn't put in the new version. > From Keith_Carter@aussmtp.austin.ibm.com Thu Feb 20 13:41:02 1997 > > 8. Section 5.3.2.1. notification-events. Page 22. Line > 690. > > Here is an idea. It is possible that an end-user's job > might be held or resubmitted outside the context of IPP > 1.0. The spec could add support for "job-held" and > "job-resubmitted" notification events or else indicate > that these are implicit ala "job-cancelled". Opinions? I see job-held as a job-state-reasons and not a job-state value. It is not currently in the document because there is no way to change its value. We have not specified whether there is a job-held attribute or a hold/release operation. We have not addressed whether such events are covered under an existing event, such as job-problems, or some new event. KC>> It sounds like we should postpone this until IPP 2.0. KC>> There are LAN printing solutions that post events KC>> to end-users when their job is held or resubmitted because KC>> the end-user might not always have a Printer icon open on KC> their desktop to view their job's status. > > 10. Section 5.3.3.2. job-retention-period. Page 24. Line > 774-775. > > Add to the NOTE: "The requester may also specify this > job attribute using the input parameter to the Print > operation." Correct? No, the job-retention-period is an attribute that accompanies a job in the Job and Document Attributes parameter. KC>> I understand and agree. > > 12. Section 5.3.5.2. medium. Page 30. Line 896. > > I recommend an additional input-tray of "automatic" > since some printers automatically select the input tray > based on the media requested by the end-user. I think that "automatic" is the same as "as-is", in that it says to use whatever is in the document data which may be nothing. So the issue is whether to call the value "automatic" or "as is" KC>> Agreed. I think "automatic" is clearer but "as-is" is fine if KC>> we state its meaning in the spec. I didn't see "as-is" nor KC>> "automatic" in version 1.3.1 of the spec. > > 13. Section 5.3.6.1. document-format. Page 34. Line 975. > > The list of document-formats should be referenced in > this section. Possibly include the formats in an > appendix or reference another spec. > > > > 16. Section 5.3.7.14. content-orientation. Page 36. Line > 1046. > > In my opinion, content-orientation should be a Document > Production attribute. This attribute may apply to all > types of print jobs - not just text jobs - including > jobs that are converted by an IPP print driver from a > graphics API (e.g. Gpi or GDI) to a device datastream > such as Postscript or PCL. Please say more. I have assume that a graphics API (e.g. GDI) includes the content orientation and for that matter the page layout, so it doesn't make sense to specify content-orientation, which in my view specifies the first level of page layout. KC>> You're correct. My mistake - too many margaritas. KC>> Let's leave content-orientation asis. > > 17. Section 5.3.9. Number of Documents. Page 37. Line > 1079. > > Nit. How does a Printer specify there is no limit on > the number of documents per job? By using an "*" > (asterisk) as the upper number of the range? A large > number? We haven't yet specified how one end of a range is open. But if the syntax is 'a:b', then either 'a:' or 'a:*' could mean that the range has no upper bound. KC>> Ok. The spec should specify the syntax. We should decide this KC>> very quickly at our telecon today. I vote for 'a:*'. > > 26. Section 5.5.1. printer-name. Page 43. Line 1215. > > In my opinion, the spec should keep the "printer-name" > attribute so an Administrator can provide a meaningful > name to the Printer. > The printer-name attribute was renamed 'name' and moved to the common attributes section which also contains URL. KC>> I understand and agree. Thanks. > 27. Section 5.5.2.2. printer-type. Page 44. Line 1221. > > Is printer-type necessary in IPP 1.0? How does this > help the end-user? I agree. KC>> Sounds like we both tend to agree this isn't necessary for KC>> IPP 1.0. Let's discuss at the telecon today. > >>>> DO NOT REPLY TO THIS NOTE <<<< From ipp-archive Fri Feb 21 14:26:08 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA08504 for ipp-outgoing; Fri, 21 Feb 1997 14:24:16 -0500 (EST) To: ipp@pwg.org Subject: IPP>SEC Message-ID: <19970221.122138.3582.0.rdebry@juno.com> X-Mailer: Juno 1.15 X-Juno-Line-Breaks: 3-7,12-13,23-25,28-29,36,44,49,51,55,57,60-65,70,78, 82,88-89,92,97-114,116-125 From: rdebry@juno.com (Roger K deBry) Date: Fri, 21 Feb 1997 14:21:25 EST Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Following is a proposal for text on security to go into the requirements document, as discussed in yesterday's (2/19) security phone call. Please forward your comments to me as soon as possible. (for the time being copy me at rdebry@juno.com). Thanks IPP Security Requirements Introduction It is required that the Internet Printing Protocol provide the means to print in secure environments. Wherever possible, IPP ought to make use of existing security protocols and features as implemented on current systems. IPP will not invent new security features when the requirements described here can be met by existing protocols. Since we cannot anticipate the levels of security or the specific threats that any given IPP print administrator may be concerned with, IPP implementations must provide a great deal of flexibility in associating security mechanisms with IPP operations. One IPP installation might require no security at all, while another similar installation might require a very secure environment. IPP implementations must allow different security mechanisms (e.g. SSL) as required by the installation. This places a requirement on the IPP directory schema to describe the security mechanisms required to perform IPP operations on a given Printer. Environments The following unique operating environments have been identified as targets for the Internet Printing Protocol. Each has differing security requirements for the protocol. * Client and IPP Printer are both within the same organizational firewall. This would be the normal case for shared office printers in an Intranet environment. It is assumed that outside attacks are minimized by the firewall, or that the internal network is not connected to the Internet. Depending upon company policies, security could range from none to very secure. The printing of paychecks, for example, would have very different security requirements from printing office documents. * Client and IPP printer are both outside firewalls. IPP Printers in this environment are truly public and available to anyone on the internet. However, users would probably have to be authenticated and pay for print services. This might be the case, for example, for a print kiosk in an airport, for student printing in a University environment, or for a commercial print shop on the Internet. Support for E-commerce, mutual authentication, encryption and message integrity would be a requirement of this environment. * The client is inside the firewall and the IPP Printer is outside of a firewall. This is a variation of the previous case, where the Printer is public, but the user is inside of an organizational firewall. Unique security considerations here would include controls on the print data that is allowed to flow outside of the organizational firewall. * The client is outside of the firewall and the IPP Printer is inside of a firewall. * The first case is where the client is an employee of the organization that owns the Printer. This might be the case, for example, when an employee is working at home and submits a print job through the Internet to a Printer at work. * The second case is where the client is not an employee of the company. This case is not thought to be very likely. * The client is inside of the firewall and the IPP Printer is inside of a different firewall. This might occur in the case of an organization who wants to print a document on a Printer on a business partners network. Levels of Security Several levels of security should be considered. 1) No security: Anyone can submit jobs to the printer. No user ID or password is required. All data transmissions are in the clear. This is the cheapest solution and might well fit into environments not connected to the external Internet where anyone within the environment can freely access any printer. Data is most likely always sent in the clear. 2) Access controlled: The Printer object has an associated Access Control List (ACL). Identification is required, but authentication (other than perhaps a password) is not. Data is most likely always sent in the clear. Again this is probably most suited for environments where Printers are not accessible from outside of an organization's firewall. However certain printers may be usable only by certain groups within an organization. This scheme also allows for accounting to be applied to printing based on user or group identity. 3) Authenticated Access Control: The Printer object has an associated ACL. Users identify themselves and are authenticated through the use of public key certificates. Data may be sent in the clear or may be encrypted. 4) Mutually Authenticated Access: Any communication with the printer is done only after the end user and the Printer have been authenticated to one another. Public key certificates are required for both users and Printers. This method would be most likely where a Printer is made visible outside of the organizational firewall. Data may be sent in the clear or encrypted. Message integrity is checked for each transmission. 5) E-Commerce Printing: Two cases exist which affect security. * Pay-for-print: When printing is performed, the end user is required to pay for the printing services. A secure payment scheme must be provided, based on existing or planned e-commerce schemes, such as SET. * Pay-for-content: When printing content that has been purchased, an IPP Printer must be provided that understands and conforms to digital property rights management instructions. This is probably outside of the scope of IPP V1.0, but ought to be considered as a placeholder for the future. Threats Several different kinds of threats have been identified. * Unauthorized or misuse of printer resources * supplies, printer use * junk printing * Denial of service (spamming) * Liability * for printed content * for services performed/not performed * Provability of service * Defeating payment or accounting system * Incorrect destination * Content integrity * correct rendering of data * guarantee security marks (watermarking, fingerprinting, security banners) * malicious content changes * Confidentiality * on the wire * on the printer * corruption of required resources * Passing organizational data outside a firewall * Legal liability of user's employer for printed content From ipp-archive Fri Feb 21 14:56:09 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA08845 for ipp-outgoing; Fri, 21 Feb 1997 14:51:57 -0500 (EST) Message-Id: <3.0.32.19970221102839.00e360b0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 21 Feb 1997 10:28:40 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC - Minutes from phone conference 970220 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO SEC subgroup - Minutes of phone call 2/20/97 on call were: Roger deBry Carl-Uno Manros (notetaker) Steve Okamoto Daniel Manchala Bob Setterbo This call was made shorter than earlier planned, as it turned out that Jerry Hadsell was not in on the call. Bob Setterbo joined in for the first time. Comparison of HTTP 1.1 vs. SSL3 features Daniel gave a short report on the new security features in HTTP 1.1. They are documented in RFC 2069, as extension to the HTTP 1.1 specification RFC 2068. RFC 2069 contains a few variations on how to compose a certificate. The bottom line is that it only allows authentication of the client (while SSL 3 has the option to authenticate both client and server) and it does not provide any mechanism for encryption of the document data. SSL 3 requires a trusted directory for certificates, while RFC 2069 does not need this. It seems feasible that some IPP implementations would be happy to limit themselves to the RFC 2069 functionality, while others may want to provide the increased set provided by SSL 3. We did not see any reason for the IPP project to decide which of the two should be used, the IPP model should allow for either. The only requirement we have found so far for additional info in the IPP protocol is the ability to attach a certificate with a document reference for cases where the server is asked to retrieve the document before printing. Any other security features that we have talked about are either handled by the underlaying protocol (HHTP 1.1 or SSL 3) or they are local functions in the server (such as access control lists). Commercial transactions We went over this subject again and decided to recommend postponing such features to IPP Version 2, as there is still too much movement in this general area. Homework assignments: It was decided that we need to start documenting our findings to be included in the Requirements and the Model documents. Roger will take a stab at the proposed text for the Requirements document, while Steve, Xavier and Daniel will work on the Model text. Xerox has a problem with the Thursday afternoon phone conference time, and will come up with a proposal for a different time. Carl-Uno will try to find a new time, so stay tuned for new announcement about the time for next week. ---- Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Fri Feb 21 15:36:09 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA09208 for ipp-outgoing; Fri, 21 Feb 1997 15:34:05 -0500 (EST) Message-ID: From: Babak Jahromi To: "'Harry Lewis '" , "'ipp@pwg.org'" Subject: RE: IPP> RE: MOD - Push back on simplifying Print operation response Date: Fri, 21 Feb 1997 12:35:12 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 60 TEXT Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Well, I think the thins client (NC) platform might be a great dream, but I doubt any IPP member would want to spend time desinging ONLY for a platform that has currently almost zero market share. Ideally we would like to cover both, without making any sacrifice for the %99 of the cases, namely the traditional desktop OS. Babak >-----Original Message----- >From: Harry Lewis [SMTP:harryl@VNET.IBM.COM] >Sent: Friday, February 21, 1997 7:05 AM >To: ipp@pwg.org >Subject: IPP> RE: MOD - Push back on simplifying Print operation response > >Sorry for the multitude of embeds, but this thread touches on something >that has been bothering me about IPP. I'm not judging which is the right >or wrong approach, but either we're building IPP for the scenario where >standard desktop applications (i.e. Babak's response), run on a >traditional desktop OS but the WEB underlies communications and print >submission *OR* we're building IPP for the NC (thin-client) world where >the WEB *IS* the OS and applications or applets, which have been modified >to run in this environment, now use print services based on IPP. > >Or both, inevitably staged, based on Microsoft's NT5.0 direction. > >Where is the real focus of IPP? > >>Isn't what you call "print submission GUI" the everyday applications >>people use? like Word, Excel, Corel, Quicken. etc. etc.? >> >>So I wouldn't plan on changing any of it! >> >>Babak >> >>>-----Original Message----- >>>From: Robert.Herriot@Eng.Sun.COM [SMTP:Robert.Herriot@Eng.Sun.COM] >>>Sent: Thursday, February 20, 1997 3:27 PM >>>To: ipp@pwg.org; hastings@cp10.es.xerox.com >>>Subject: Re: IPP> MOD - Push back on simplifying Print operation response >>> >>> >>>> >>>> My concern is that either: >>>> >>>> 1. User friendly implmentations will make additional protocol calls >>>> to get job and printer status. That means that each Print operation >>>> will require three calls, not one. If we layer on HTTP that means >>>> a new session startup/teardown for each of the three calls. >>> >>>My assumption is that the GUI from which the Print submission is made is >>>a different process from the one showing status in most cases. In such an >>>environment, the Print submission GUI would probably not inform the >>>job status GUI about the changes. The primary issue is whether a print >>>submission GUI (or command) would inform the user of the special case >>>you site below where the printer is stopped and needs attention before it >>>will resume printing. > > From ipp-archive Fri Feb 21 16:06:10 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA09558 for ipp-outgoing; Fri, 21 Feb 1997 16:03:00 -0500 (EST) Date: Fri, 21 Feb 1997 13:01:23 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199702212101.NAA16605@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, ipp@pwg.org, hastings@cp10.es.xerox.com, babakj@MICROSOFT.com Subject: RE: IPP> MOD - Push back on simplifying Print operation response X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO > From babakj@MICROSOFT.com Thu Feb 20 15:39:00 1997 > > > Isn't what you call "print submission GUI" the everyday applications > people use? like Word, Excel, Corel, Quicken. etc. etc.? > > So I wouldn't plan on changing any of it! > > Babak > I hadn't planned on changing the print submission GUI in Windows, but the design is intended to allow Unix and possibly Java clients to submit jobs with IPP attributes which a receiving Printer (i.e. Print Server) can process. We are unfortunately caught in a world where Windows client do attribute processing and Unix servers sometimes need to do attribute processing because Unix clients don't. Bob Herriot From ipp-archive Fri Feb 21 18:56:11 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA10087 for ipp-outgoing; Fri, 21 Feb 1997 18:56:08 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 21 Feb 1997 16:56:19 -0700 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - 2/24 Telecon Sender: ipp-owner@pwg.org Precedence: first-class Status: RO We will have a Model group teleconference on Monday 2/24 Confirmation number: 315227 Call in Toll-Free number: 800-753-9188 Monday, 2/24/97 3:00 - 5:00 Mountain Time PM Scott Isaacson ************************************************************ 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: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Sun Feb 23 19:41:38 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA12448 for ipp-outgoing; Sun, 23 Feb 1997 19:37:25 -0500 (EST) From: Keith_Carter@aussmtp.austin.ibm.com X-Lotus-FromDomain: AUSNOTES To: ipp@pwg.org Message-ID: <86256448:000323D3.00@aussmtp3.austin.ibm.com> Date: Sun, 23 Feb 1997 18:38:00 -0500 Subject: IPP> DIR - Directory Issues Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Directory Team, I noticed that "directory-issues.doc" does not contain all of the issues in "IPP-DIR-ISSUES-01.doc". I recommend that the non-redundant issues (minus the proposals) from IPP-DIR-ISSUES-01.doc be included in directory-issues.doc to produce a single source of directory issues. Unfortunately, at present I am not able to post anything to the ftp site. Otherwise, I would do this myself. Thanks, Keith From ipp-archive Mon Feb 24 10:36:45 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA13301 for ipp-outgoing; Mon, 24 Feb 1997 10:36:18 -0500 (EST) From: Keith_Carter@aussmtp.austin.ibm.com X-Lotus-FromDomain: AUSNOTES To: ipp@pwg.org Message-ID: <86256448:0054DFD0.00@aussmtp3.austin.ibm.com> Date: Mon, 24 Feb 1997 09:35:18 -0500 Subject: IPP> MOD - Comments on printer-state and printer-state-reasons Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Model and Semantics Team, First, for personal reasons, I must leave our telecon today (2/24) at 4:30PM Central Time. This is a situation I didn't foresee at our telecon on 2/21. Hopefully, we can cut to the chase on printer-state and printer-state-reasons at 4:00PM sharp Central Time so I can at least participate for 30 minutes. Now, here are my comments on printer-state and printer-state-reasons based on version 1.3.1 of the spec and Tom's document "comments on printer-state and printer-state-reasons attributes" dated 2/19/97 (printer-state-comments-tnh.pdf): 1. I agree with Tom's comments 1-6. 2. On comment 7, the attribute "printer-is-accepting-jobs" documented in the 1.3 spec already covers the condition described for "warning-not-accepting-jobs". 3. I agree with comment 8 in that each value for "printer-state-reasons" should have a "severityLevel", a "subunit" and a "reason". I believe "traingLevel" is overkill for IPP 1.0. 4. I agree with "processing/idle" value for printer-state. 5. In my opinion, a Printer should inform an IPP application of "printer-state-reason" for each output device connected to the Printer. Here are 2 examples. Example 1. A Printer supports 3 network-attached printers NETPRT1-3 connected to a print server using network ports NETPORT1-3 respectively. NETPRT1 has a paper jam, NETPRT2 has run out of paper in its input tray and NETPRT3 is idle. "printer-state" is "mixed". "printer-state-reasons" are "NETPORT1:critical-jammed, NETPORT2:critical-input-tray-empty, NETPORT3:idle". With this approach, an IPP application that sees a "printer-state" of "mixed" can read the state of each output device. The application may: display the state of each device to the end-user (who may be the operator); display the most critical error(s) that require action; make a decision to submit a job if at least one of the devices is "idle" or "processing"; or display "printer-state-as-text" (i.e. rely on the Printer's summary of its printer state). Example 2. PRT, IPP1 and IPP2 represent URLs for Printers. A Printer, PRT, uses 2 Printers IPP1-2 as its output devices. IPP1 and IPP2 each support multiple output devices. One of the devices in IPP1 has a paper jam and the other device is idle. One of the devices in IPP2 is idle and ther other is processing jobs. For PRT, "printer-state" is "mixed". For PRT, "printer-state-reasons" are "IPP1:mixed, IPP2:idle/processing". An application may: display the state reasons from PRT for IPP1-2 (i.e. "mixed" and "processing/idle"); display "printer-state-as-text" from PRT; or issue a Get-Attributes operation on IPP1 and process the printer-state and printer-state-reasons as described in Example 1. I believe that Example 1 is the typical fan-out scenario in the PC LAN world. The current model for IPP 1.0 requires an end-user to either submit a Job to a Printer to receive notifications of printer state events or to poll a Printer for its state using the Get-Attributes or Get-Jobs operation. I am working on a proposed extension to the model so end-users can receive real time printer events without polling or submitting jobs to a Printer. A person with whom I must discuss this proposal won't return to the office until 2/26 so look for a proposal on 2/27 in time for our telecon on 2/28. If I determine that this proposal is too complex for IPP 1.0, then I'll state so and we can table this matter until IPP 2.0. Have a super day, Keith From ipp-archive Mon Feb 24 13:21:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA13696 for ipp-outgoing; Mon, 24 Feb 1997 13:21:08 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 24 Feb 1997 11:20:36 -0700 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - 2/21 Minutes Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I will post the minutes from the 2/21 call ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/970221-model-minutes.pdf The ftp server seems to be rejecting my attempts at logging in. Until then, included is a txt copy. There is another call at 3:00 PM Mountain today 2/24. See the other email. We also conlcuded the following: If you want something added to the MODEL issues list, please make a special note of it in your e-mail by using "ISSUE" or someother signifcant hint. Also, word issues as you would like to see them on the issues list. For other, less significant comments on a document review or something, just include them in the email without calling attention to them as "ISSUES". Scott ------------------------------------------------------- IPP Model Group Meeting Minutes 2/21/97 2:00 - 4:00 PM Discussion Items: Agenda turned out to be: - Review scope and purpose of the Model document - Review 1.3.1 document and discuss items marked as issues. - Review new issues lists 2. What is the scope and purpose of the Model document: There seems to be a lot of details about the attributes and their values and syntaxes, however there seems to be very little on over all Model issues. This is due to tht face that we have not done a full edit on the document. We need to add in some higher level sections on: use of directory, use of notifications, use of security, and then include some design goals such as: use of URIs, use of attributes for late binding and document management, use of attribute adornment, etc. Scott will take an edit pass on the document once Bob H is done with the attribute sections. 3. What do printer object supplied defaults mean in relation to embedded commands in formated documents? For example, if the printer object default for media is set to some value, and a job is submitted with no media attributes and the submitted job is some well formated PDL with embedded commands to select the media through the interpreter, what is the relationships of all of these values? Is the embedded command intended to be the definitive answer since the end user just created the document and that is what they explicitly requested? Or, did the end user just pull the document off of some server somewhere and they really want to override the embedded commands with the printer default values? We did not come to closure on this issue. 4. Status attributes coming back in the Print Operation? We still have not closed on: 1) not allowing any status attributes to come back in the Print response. 2) Allowing only a well known, "hard coded", fixed set of attributes to come back in the response, or 3) Allow a general purpose request any attribute to come back in the response. Some of the issues with option 1 are requireing multiple operations for info that is generally needed. Some of the issues with option 2 are supporting attributes from multiple objects in the response and lack of run time extesibiblity. Some of the issues with option 3 are added complexity and processing in every operation even if it is used very infrequently. Tom H will make a proposal. 5. The issue about requesting specific attributes vs requesting groups in the Get Attributes is resolved. We will allow for the requesting of specific attributes. 6. Tom H then started to take notes. We agreed to assign a person with one or more helpers to work on each Open issue. The first name is the assigned person who will be responsible to contact the others and work out a solution. Page 9, line 355: How does a Printer indicate priorities of defaults: those that override what is in a document and those that do not? Do we need a tag or an overal policy attribute that affects all attributes? Status: Open. Assigned: Bob H and Tom H. Page 10, line 378: What should be returned on a Print operation? Job-state, Queue-position, printer-state, and printer-state-reasons? Status: Open. Assigned: Tom H to make a proposal. Page 11, line 411: Should a client be able to request specific attributes in a Get-Attributes operation? Resolution: Yes. Status: Closed Page 15, line 498: Are the coded-characters that are specified in the Model and Semantics standard, abstract or the actual coded-characters? If abstract, then the protocol standard must specify the mapping onto actual coded-characters. Status: Open Assigned: Roger, Bob H Page 16, after line 498: version and Page 36, line 1025: Will document-formats be registered as name and version combined? Or do we just use the current IANA registration setup for the Printer MIB for Interpreter Language Families? Status: Open Assigned: Tom H, Bob H Page 16, after line 498: How are different currencies handled, if we have a cost attribute? While the locale may ofter imply a currency, there may be circumstances, when a different currency is needed than that implied by the locale. Status: Open Assigned: ??? Page 19, lines 562-563: Do we need a tag to indicate that certain attribute values are only for indicated document-formats or can setting up different fan-in Printers (one for each document-format) suffice? How does auto-sensing of document-formats fit into either solution? Status: Open Assigned: Keith C, Bob H, Tom H. Page 22, lines 632-669: We agreed to abandon having URL and name attributes that are common to Jobs and Printers. Go back to job-URL, printer-URL, job-name, and printer-name. The semantics of each was too different depending on whether the object was Job or Printer and we only had two such attributes. Status: Closed Assigned: Bob H will reformulate as originally but using *URL', instead of *identifier' in the name of the attribute. Page 25, lines 740-742: How can the user specify the level of detail to be sent by the Printer on notifications? Status: Closed Agreement: The System Adminstrator specifies which attributes are returned in notifications. Examples will be added to the document. Page 25, lines 770-773: How many different values for job-priority are needed? Status: Closed Agreement: Use the same range as ISO DPA: 1-100, so that it is easier to map to the various print systems that have a number of different priorities (even though the utility of having a large number may be questioned). MVS has A-Z, BSD has 1-39, etc. Page 27, lines 827-828: How do production attributes that conflict with embedded attributes get resolved and how this conflict resolution is probably PDL dependent. Status: Open Assigned: Bob H and Roger d Page 30, lines 921-930: Not clear whether the client must specify input-tray, as well as, or instead of, a medium name? Its listed as type2EnumPlus. Status: Closed Agreement: The user may specify a medium name, a medium size, or an input tray, but not more than one. Bob H will clarify the text. [Editor's note: the data type should be changed from type2EnumPlus to type2Enum, since a client can only specify one value.] Page 37, lines 1035-1043: Keith suggests adding more text attributes: font-style, line-numbers, text-border, word-wrap, number-of-columns, file-name, file-time, file-date. All are Booleans, except font-style. The group agreed in principle to add these. Status: Open Assigned: Keith C, write up actual complete text for each for future review. Page 39, lines 1106-1107: Is reverse-landscape and reverse-portrait needed for content-orientation or should we specify that the direction of rotation should be whatever is needed by the Printer for finishing, if finishing is supported. Status: Closed Agreement: Instead of specifying the direction of rotation (like ISO DPA), IPP will only specify that the direction of rotation of landscape is what is needed for accomplishing finishing, if any is supported. If finishing is not supported, then the direction of rotation for landscape does not matter (and will be +90 in some implementations and -90 in others). Bob H to add more explanation along these lines. Page 42, after line 1191 and page 43, lines 1200-1204: What does the printing job-state include? Should the state be called processing, instead, so that it may cover more than just putting marks on paper? Status: Open Assigned: Bob H, Keith C, Tom H Page 47, line 1294: Are there too many printer-types listed (from the Printer MIB which was also copied into ISO DPA)? Only laser, ink-jet, impact are what most users want to know. Status: Closed Agreement: We agreed to delete the printer-type from IPP V1.0 altogether. Pages 48-49: Printer-state, and printer-state-reasons. We started to discuss Tom H's proposal and compare it with Bob H's new formulations in the document. Keith C is writing up his ideas as well. We will have a special telecon, Monday, 2/24, 2pm PST, 5pm EST, to discuss the three proposals. From ipp-archive Mon Feb 24 14:36:50 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA14210 for ipp-outgoing; Mon, 24 Feb 1997 14:34:17 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 24 Feb 1997 12:31:17 -0700 From: Scott Isaacson To: Keith_Carter@aussmtp.austin.ibm.com, ipp@pwg.org Subject: IPP> DIR - Directory Issues -Reply Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Thanks for the reminder Keith, I'll get the list integrated. And, oh by the way, I am having a Super Day.... Scott >>> 02/23/97 04:38pm >>> Directory Team, I noticed that "directory-issues.doc" does not contain all of the issues in "IPP-DIR-ISSUES-01.doc". I recommend that the non-redundant issues (minus the proposals) from IPP-DIR-ISSUES-01.doc be included in directory-issues.doc to produce a single source of directory issues. Unfortunately, at present I am not able to post anything to the ftp site. Otherwise, I would do this myself. Thanks, Keith From ipp-archive Mon Feb 24 14:56:49 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA14586 for ipp-outgoing; Mon, 24 Feb 1997 14:53:04 -0500 (EST) Message-Id: <3.0.32.19970224113534.014e43a0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 24 Feb 1997 11:35:35 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> MOD - ISSUE - IPP Architecture Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Architecture View of IPP I have looked a little more closely at our current model approach to IPP and I am not happy. :-( We started off with the assumption that we would build IPP as a simpler subset of DPA, taking into consideration some lessons that we have learned. One of the lessons that I have learned, is that we messed up about objects when we defined DPA. Objects were introduced in DPA as an afterthought and does not really follow architectural rules for object oriented design. One of my hopes was that we would do a better job of this as we set out to design IPP as a subset of DPA. My impression of our current "model" design is that we have done most of the thinking from the bottom up, concentrating on how we could select a reasonable subset of attributes and to focus on how we could further simplify the attributes that remains, plus adding in a few new ones for good measure. Although some discussion has been held on modeling issues, my feeling is that we have never questioned the IPP architecture, but just tried to do some simplification of the current DPA approach. I now want us to take a step back and consider that although IPP version 1 will have a more limited set of capabilities than DPA, we still have to pay attention that we get a foundation on which we can expand in future versions. The best way of insuring this is, in my view, to apply a better, object oriented architecture right from the start and start looking at the design also from a top down perspective. I am not trying to make things more complex than they are currently planned to be, but would like to see a better structure in how we design them. The two areas in which I think we could do better are in defining objects, and in selecting the right level of operations: Object =3D=3D=3D=3D=3D=3D I think that we have got too far in our simplification efforts when we came up with the solution that we did not need a Document object. I would like to re-introduce the Document as a separate object for the following reasons: =B7 We have already decided that we need to have document level attributes that override corresponding job level attributes. The current solution to mark such attributes with an adornment, I find really messy, not only from an object orientation perspective, but also from a syntax perspective. =B7 The argument that we should not define documents as objects, because we do not have any operations on documents in version 1, does not make sense to me. As soon as we want to start adding more functionality to IPP in future versions, the first thing we are going to need is operations that can work on individual documents. A reminder is that DPA has in effect baked several operations into one with its Print operation, one of which works with documents. =B7 The monolithic design that we currently have for the IPP Print operation does not give us a lot of flexibility for the future, which is why I suggest that we should define operations for documents already in IPP version 1. Scott has informed me that the MOD group has already accepted to define Document as an object, it is not yet fully reflected in the working document, so this is not really an issue. Operations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I would like to see operations that are related to the IPP objects. My assumption is that we have three main objects in IPP version 1 - Printer, Job, and Document. Here are the operations that I would like to see: =B7 Get Printer Attributes This would be used to find out about printer capabilities, and possibly status, before submitting a Job.=20 The printer capabilities could be cashed, so this operation does not need to be made for every print request. =B7 Send Job Attributes Used to initiate a new Job. It would contain all the attributes needed to validate if the job can be done (although you can still run into problems when document data is passed later). There would be an attribute stating the number of documents in the Job, or an indication that it is a Job of indeterminate length, where the number is not known when printing starts. The client would receive a response, confirming if the job can be done or not (with error codes) and a job-id is returned if accepted.=20 =B7 Send Document and Document Attributes This operation would be used to send one document, with its Document Attributes, if any. It would contain the job-id, so the Printer knows to which Job it belongs. Alternatively, one Document Reference could be sent, with its Document Attributes, if any. The server would return succes or error (with error codes). =B7 Send End-of-Job Message This is a very simple operation, that just signals to the Printer that a Job of indeterminate length has finished sending all the data for that Job. It would not be used for other Jobs, and would not need to be supported by printers that cannot handle Jobs of indeterminable lenght. =B7 Cancel Job Operation to delete a Job. As default, also deletes the associated Documents. (In a future version of IPP we may want to allow for documents to be changed or deleted in separate operations.) =B7 Get Job Attributes This operation is used to check up on a Job=92s current attribute settings, as well as the Job status. (May also include some Printer status attributes, which are necessary to explain Job status). =B7 Send Job Notification (probably realized on a different transfer= protocol) This operation would send success or failure notifications from the server to the client (and possibly others, such as the operator or administrator, or an intended recipient for the Job. =B7 Send Printer Notification (probably realized on a different transfer protocol) This is intended to signal problems with the Printer (may be due to problems on the device). It can be sent to the operator (or the end-user if there is no dedicated operator). I assume that IPP operations defined in the model document can be combined when sent over a particular transfer protocol, but I have more difficulty in seeing how to split up model level operations into several operations in the transfer protocol. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Mon Feb 24 15:36:49 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA15019 for ipp-outgoing; Mon, 24 Feb 1997 15:32:39 -0500 (EST) Date: Mon, 24 Feb 1997 12:31:02 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199702242031.MAA18185@woden.eng.sun.com> To: ipp@pwg.org, rdebry@juno.com Subject: Re: IPP>SEC X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO > From rdebry@juno.com Fri Feb 21 11:27:09 1997 > > IPP Security Requirements > 2) Access controlled: The Printer object has an associated Access > Control List (ACL). Identification is required, but authentication (other > than perhaps a password) is not. Data is most likely always sent in the > clear. Again this is probably most suited for environments where > Printers are not accessible from outside of an organization's firewall. > However certain printers may be usable only by certain groups within an > organization. This scheme also allows for accounting to be applied to > printing based on user or group identity. You have included a good selection of security scenarios, but I think that you have missed one. Your #2 case above may cover this case, but I'm not sure. The one you have missed is the most prevalent one in use today, namely the weak Unix security model where the underlying transport supplies the user id and the user doesn't have to deal with security explicitly except during login. The server authenticates using this user id. This user id is easily spoofed by a knowledgeable user and it doesn't work across domains, but it is better than nothing and is good enough for many sites. If #2 covers this case, it needs some more wordsmithing. Bob Herriot From ipp-archive Mon Feb 24 17:51:50 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA15785 for ipp-outgoing; Mon, 24 Feb 1997 17:50:37 -0500 (EST) From: rdebry@us.ibm.com X400-Originator: rdebry@us.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100005083734000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100005083734000002*@MHS> To: Subject: IPP>PRO Date: Mon, 24 Feb 1997 17:49:11 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 I talked today with one of the IBM web server developers about the use of http post method vs. new http methods for ipp. His view was that there would not be a significant performance or load difference for these two alternatives. He thought that defining a new protocol was the worst choice. He also told me that in IBM web servers, new method handlers could be written by anyone and bound into the server later, so defining new methods on IBM servers doesn't require the server code itself to be changed. From ipp-archive Mon Feb 24 18:41:51 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA16265 for ipp-outgoing; Mon, 24 Feb 1997 18:41:06 -0500 (EST) Message-Id: <199702242341.AA03855@interlock.lexmark.com> To: "ipp%pwg.org" From: Don Wright Date: 24 Feb 97 18:31:13 EST Subject: IPP> IPP Conference Calls for 2/26 adn 3/5 Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Following are the details for the IPP conference calls or Wed. 2/26 and 3/5: (details same as previous calls) Phone no.: 1-423-673-6712 Time: 4:00 PM EST to 6:30 PM EST Partipicant access code: 190148 See you on Wednesday. Don ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From ipp-archive Mon Feb 24 20:11:53 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA16946 for ipp-outgoing; Mon, 24 Feb 1997 20:08:23 -0500 (EST) Message-Id: <3.0.1.32.19970224170833.00e5f968@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 24 Feb 1997 17:08:33 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Agenda for IPP Phone Conference 970226 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Agenda for IPP Phone Conference 970226 My understanding is that there is not an lot of progress in the other subgroups due to the intensive discussions in the MOD subgroup. However, here is my proposal for our next conference: - Review progress on Requirements editing (security requirements have been added) - Review progress on Directory (if any?) - Review progress on Protocol (if any?) - Discuss if we are getting ready to get the Prototyping subgroup started. - Spend the rest of the time trying to sort out a few more of the Model issues Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Mon Feb 24 20:46:53 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA17384 for ipp-outgoing; Mon, 24 Feb 1997 20:42:02 -0500 (EST) Message-ID: From: Babak Jahromi To: "'rdebry@us.ibm.com'" , "'ipp@pwg.org'" Subject: RE: IPP>PRO Date: Mon, 24 Feb 1997 17:40:53 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 24 TEXT Sender: ipp-owner@pwg.org Precedence: first-class Status: RO How about clients? Would it be as easy to add support for an IPP-Post to a client? I will find out if Microsoft's IIS offers the same capability. Babak >-----Original Message----- >From: rdebry@us.ibm.com [SMTP:rdebry@us.ibm.com] >Sent: Monday, February 24, 1997 2:49 PM >To: ipp@pwg.org >Subject: IPP>PRO > >I talked today with one of the IBM web server developers about >the use of http post method vs. new http methods for ipp. His view >was that there would not be a significant performance or load >difference for these two alternatives. He thought that defining a >new protocol was the worst choice. > >He also told me that in IBM web servers, new method handlers >could be written by anyone and bound into the server later, so >defining new methods on IBM servers doesn't require the server >code itself to be changed. From ipp-archive Mon Feb 24 21:36:52 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA17853 for ipp-outgoing; Mon, 24 Feb 1997 21:35:47 -0500 (EST) Message-ID: From: Babak Jahromi To: "'rdebry@us.ibm.com'" , "'ipp@pwg.org'" Subject: RE: IPP>PRO Date: Mon, 24 Feb 1997 18:37:00 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 35 TEXT Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Apprently IIS's ISAPI filters let you define custom methods. Still hanging on the client-side issue. Babak >-----Original Message----- >From: Babak Jahromi >Sent: Monday, February 24, 1997 5:41 PM >To: 'rdebry@us.ibm.com'; 'ipp@pwg.org' >Subject: RE: IPP>PRO > > >How about clients? Would it be as easy to add support for an IPP-Post to >a client? > >I will find out if Microsoft's IIS offers the same capability. > >Babak > >>-----Original Message----- >>From: rdebry@us.ibm.com [SMTP:rdebry@us.ibm.com] >>Sent: Monday, February 24, 1997 2:49 PM >>To: ipp@pwg.org >>Subject: IPP>PRO >> >>I talked today with one of the IBM web server developers about >>the use of http post method vs. new http methods for ipp. His view >>was that there would not be a significant performance or load >>difference for these two alternatives. He thought that defining a >>new protocol was the worst choice. >> >>He also told me that in IBM web servers, new method handlers >>could be written by anyone and bound into the server later, so >>defining new methods on IBM servers doesn't require the server >>code itself to be changed. From ipp-archive Mon Feb 24 22:26:54 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA18297 for ipp-outgoing; Mon, 24 Feb 1997 22:22:58 -0500 (EST) Message-ID: From: Babak Jahromi To: "'ipp@pwg.org'" , "'rdebry@us.ibm.com'" Subject: IPP> FW: MyPost vs. Post Date: Mon, 24 Feb 1997 19:23:15 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 29 TEXT Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Seems like Win32 Internet APIs allows inventing a new HTTP method in the client side as well. >-----Original Message----- >Sent: Monday, February 24, 1997 7:15 PM >To: Babak Jahromi >Subject: RE: MyPost vs. Post > >In that case the answer is yes for WinInet. -- >When you call HttpOpenRequest(), the second argument is the verb which can be >anything -- a GET, a POST, or whatever else you will pass to that function. >--Wininet Development > >---------- >From: Babak Jahromi >Sent: Monday, February 24, 1997 6:57 PM >Subject: RE: MyPost vs. Post > > >What I have in mind is to potentially define a new "post" command that both >client and the server would understand and use. Today Windows Internet >clients (like the browser) use Wininet.dll APIs to talk to an HTTP server. So >to invent a new HTTP method, ideally the client can tell the Wininet APIs to >use this new custom method, and on the server side we can implement an ISAPI >filter that horors the new method. > >Babak > From ipp-archive Tue Feb 25 10:27:00 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA20900 for ipp-outgoing; Tue, 25 Feb 1997 10:23:12 -0500 (EST) From: rdebry@us.ibm.com X400-Originator: rdebry@us.ibm.com X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100005132512000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100005132512000002*@MHS> To: , Subject: IPP> FW: MyPost vs. Post Date: Tue, 25 Feb 1997 10:21:38 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 Babek, so would you propose one new method, say "PRINT" with sub-operations to express the IPP methods, or would you propose several new HTTP methods, one for each IPP method? ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/25/97 08:17 AM --------------------------- ipp-owner @ pwg.org 02/24/97 08:24 PM To: Roger K Debry/Boulder/IBM, ipp @ pwg.org@internet cc: Subject: IPP> FW: MyPost vs. Post Seems like Win32 Internet APIs allows inventing a new HTTP method in the client side as well. >-----Original Message----- >Sent: Monday, February 24, 1997 7:15 PM >To: Babak Jahromi >Subject: RE: MyPost vs. Post > >In that case the answer is yes for WinInet. -- >When you call HttpOpenRequest(), the second argument is the verb which can be >anything -- a GET, a POST, or whatever else you will pass to that function. >--Wininet Development > >---------- >From: Babak Jahromi >Sent: Monday, February 24, 1997 6:57 PM >Subject: RE: MyPost vs. Post > > >What I have in mind is to potentially define a new "post" command that both >client and the server would understand and use. Today Windows Internet >clients (like the browser) use Wininet.dll APIs to talk to an HTTP server. So >to invent a new HTTP method, ideally the client can tell the Wininet APIs to >use this new custom method, and on the server side we can implement an ISAPI >filter that horors the new method. > >Babak > From ipp-archive Tue Feb 25 11:37:01 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA21370 for ipp-outgoing; Tue, 25 Feb 1997 11:34:22 -0500 (EST) From: rdebry@us.ibm.com X400-Originator: rdebry@us.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100005135859000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100005135859000002*@MHS> To: Subject: IPP>MOD Date: Tue, 25 Feb 1997 11:32:50 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 I'd like to suggest a topic for tomorrow's conference call and would also like to have folks think about this and post thoughts to the discussion list as food for thought for tomorrow. I've talked to different folks that have different points of view and I'd like to get those more formally on the table. The Microsoft proposal we saw in San Jose used what I would view as a quite different scheme for handling printer and job status from where I think we are heading with IPP. I'd like other's thoughts on this. Do you think IPP can/would use a scheme like Microsoft's (HTML templates) for printer and job status or does the IPP Get Attributes/Get Jobs request and response look like something else? From ipp-archive Tue Feb 25 12:22:00 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA21845 for ipp-outgoing; Tue, 25 Feb 1997 12:21:09 -0500 (EST) From: rdebry@us.ibm.com X400-Originator: rdebry@us.ibm.com X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100005138844000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100005138844000002*@MHS> To: , Subject: IPP>SEC Date: Tue, 25 Feb 1997 12:18:29 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 Bob, does the following work for the case you suggested: 2) Access controlled: The Printer object has an associated Access Control List (ACL). Identification is required, but authentication (other than perhaps a password) is not. | Identification may flow with the IPP request or may be | included as part of the underlying transport. Data is most likely always sent in the clear. Again this is probably most suited for environments where Printers are not accessible from outside of an organization*,s firewall. However certain printers may be usable only by certain groups within an organization. This scheme also allows for accounting to be applied to printing based on user or group identity. From ipp-archive Tue Feb 25 13:22:02 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA22233 for ipp-outgoing; Tue, 25 Feb 1997 13:17:12 -0500 (EST) Message-ID: From: Babak Jahromi To: "'rdebry@us.ibm.com'" , "'ipp@pwg.org'" Subject: RE: IPP> FW: MyPost vs. Post Date: Tue, 25 Feb 1997 10:00:58 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 65 TEXT Sender: ipp-owner@pwg.org Precedence: first-class Status: RO At this point Microsoft in not inventing a new HTTP printing method for NT 5.0. I was only talking about the future possiblities. I am not even convinced inventing a new HTTP method would by us anything. But it seems like we can invent new methods if it turns out to be beneficial, and still depend on stock Web servers and clients. Babak >-----Original Message----- >From: rdebry@us.ibm.com [SMTP:rdebry@us.ibm.com] >Sent: Tuesday, February 25, 1997 7:22 AM >To: Babak Jahromi; ipp@pwg.org >Subject: IPP> FW: MyPost vs. Post > > >Babek, so would you propose one new method, say "PRINT" with sub-operations >to >express the IPP methods, or would you propose several new HTTP methods, one >for >each IPP method? >---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/25/97 >08:17 >AM --------------------------- > > ipp-owner @ pwg.org > 02/24/97 08:24 PM > > >To: Roger K Debry/Boulder/IBM, ipp @ pwg.org@internet >cc: >Subject: IPP> FW: MyPost vs. Post > > >Seems like Win32 Internet APIs allows inventing a new HTTP method in the >client side as well. > >>-----Original Message----- >>Sent: Monday, February 24, 1997 7:15 PM >>To: Babak Jahromi >>Subject: RE: MyPost vs. Post >> >>In that case the answer is yes for WinInet. -- >>When you call HttpOpenRequest(), the second argument is the verb which can >>be >>anything -- a GET, a POST, or whatever else you will pass to that function. >>--Wininet Development >> >>---------- >>From: Babak Jahromi >>Sent: Monday, February 24, 1997 6:57 PM >>Subject: RE: MyPost vs. Post >> >> >>What I have in mind is to potentially define a new "post" command that both >>client and the server would understand and use. Today Windows Internet >>clients (like the browser) use Wininet.dll APIs to talk to an HTTP server. >>So >>to invent a new HTTP method, ideally the client can tell the Wininet APIs to >>use this new custom method, and on the server side we can implement an ISAPI >>filter that horors the new method. >> >>Babak >> > From ipp-archive Tue Feb 25 14:42:01 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA22633 for ipp-outgoing; Tue, 25 Feb 1997 14:41:09 -0500 (EST) Message-ID: From: Babak Jahromi To: "'ipp@pwg.org'" Subject: FW: IPP> FW: MyPost vs. Post Date: Tue, 25 Feb 1997 11:42:39 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 42 TEXT Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Let me calrify a point regarding the support in "stock" clients for new HTTP methods: I was not including the browsers here, rather I was referring to the underlying APIs that clients programs can call to issue these methods (browsers would just be another client programs in this frame work). I was basically saying that Win32 Internet/Intranet APIs do allow the use of a new HTTP method. So anyone, perhaps the IPP printer client module, can depend on these APIs to issue a custom IPP method over HTTP. Again, not that I believe we need to do this at this point. Babak >-----Original Message----- >From: Babak Jahromi >Sent: Tuesday, February 25, 1997 10:01 AM >To: 'rdebry@us.ibm.com'; ipp@pwg.org >Subject: RE: IPP> FW: MyPost vs. Post > > >At this point Microsoft in not inventing a new HTTP printing method for NT >5.0. I was only talking about the future possiblities. I am not even >convinced inventing a new HTTP method would by us anything. But it seems like >we can invent new methods if it turns out to be beneficial, and still depend >on stock Web servers and clients. > >Babak > >-----Original Message----- >From: rdebry@us.ibm.com [SMTP:rdebry@us.ibm.com] >Sent: Tuesday, February 25, 1997 7:22 AM >To: Babak Jahromi; ipp@pwg.org >Subject: IPP> FW: MyPost vs. Post > > >Babek, so would you propose one new method, say "PRINT" with sub-operations >to >express the IPP methods, or would you propose several new HTTP methods, one >for >each IPP method? From ipp-archive Tue Feb 25 15:07:01 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA22970 for ipp-outgoing; Tue, 25 Feb 1997 15:06:51 -0500 (EST) From: rdebry@us.ibm.com X400-Originator: rdebry@us.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100005149529000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100005149529000002*@MHS> To: Subject: IPP>ADM Date: Tue, 25 Feb 1997 15:05:18 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 As I've pointed people to the PWG ftp site to get the IPP documents, it has become increasingly difficult to point them to the latest documentation. The I-Ds are spread across several directories and they are changing over time. I'd like to propose the following idea -- what if we kept a copy of the latest internet drafts in one common place with a standard name so that we could point people unfamiliar with the history and reams of documentation out there to one place where they could get the lastest and greatest. For example, have a directory called "Current-Internet-Drafts" which would have in it "Model", "Requirements", Directory-Schema", and "Protocol" etc. without version numbers. We could choose to promote documents to this directory when we were re ady to have the rest of the world read and comment on them. From ipp-archive Tue Feb 25 15:12:10 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA23229 for ipp-outgoing; Tue, 25 Feb 1997 15:09:45 -0500 (EST) From: JON@xcd.com MMDF-Warning: Parse error in original version of preceding line at xcdsco1.xcd.com Organization: XCd, Inc. To: scott_isaacson@novell.com, robert.herriot@eng.sun.com, don@lexmark.com, ipp@pwg.org Date: Tue, 25 Feb 1997 11:40:41 PST Subject: IPP> Dumb question Priority: normal X-mailer: Pegasus Mail/Mac (v2.1.2) Message-ID: <13055FC7586@xcd1.xcd.com> Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Is the IETF Internet Printing Protocol (IPP) the same thing as the Novell-initiated LDPA (Lightweight Document Printing Application) specification that received a lot of attention at the end of last year? From ipp-archive Tue Feb 25 17:02:02 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA23772 for ipp-outgoing; Tue, 25 Feb 1997 17:01:28 -0500 (EST) Message-Id: <3.0.1.32.19970225134416.0146bd88@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 25 Feb 1997 13:44:16 PST To: rdebry@vnet.ibm.com, ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM In-Reply-To: <5030100005149529000002*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO At 12:05 PM 2/25/97 PST, you wrote: >Epilogue: Roger K deBry > >As I've pointed people to the PWG ftp site to get the IPP documents, it has >become increasingly difficult to point them to the latest documentation. The >I-Ds are spread across several directories and they are changing over time. >I'd like to propose the following idea -- what if we kept a copy of the latest >internet drafts in one common place with a standard name so that we could point >people unfamiliar with the history and reams of documentation out there to one >place where they could get the lastest and greatest. For example, have a >directory called "Current-Internet-Drafts" which would have in it "Model", >"Requirements", Directory-Schema", and "Protocol" etc. without version >numbers. We could choose to promote documents to this directory when we were re >ady to have the rest of the world read and comment on them. > Roger, the main idea is that people unfamiliar with the project should go to the Web site rather than the FTP site, and that we try to keep up with the latest version there. Using a standard name for the latest draft of its kind is still a good idea and would do the referencing from the Web pages a lot easier. I would expect the editor/whip for each subgroup to keep an eye on this for both the FTP and Web versions. Please note that I do not want us to label things as Internet Drafts if they have not yet been sent to the IETF for publishing as such. So far, only our input to IETF in San Jose are in that category. I have asked people before to please clean up the "new_XXX" folders to get rid of older version and make sure that they only remain in the respective "historic" sub folders. Please editors and main contributors do this! Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Tue Feb 25 17:07:05 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA24066 for ipp-outgoing; Tue, 25 Feb 1997 17:05:00 -0500 (EST) From: rdebry@us.ibm.com X400-Originator: rdebry@us.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100005155594000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100005155594000002*@MHS> To: Subject: IPP>MOD Date: Tue, 25 Feb 1997 17:03:25 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 If we intend the protocol to support Printers which cannot spool jobs, or which have limited spool space, then I think we need an attribute which expresses this fact so that a client can use the protocol appropriately for that client. I've spent some time reviewing the proposal I made at the San Jose meeting with our control unit developers. While depending upon the underlying wire protocol to handle the pacing of data works okay when there is infinite spool space, we strongly believe that an application layer protocol, such as that which I suggested, is required when the printer must print while receiving data. We have implemented a very similar scheme for TCP/IP IPDS printers and it works quite well. From ipp-archive Tue Feb 25 17:47:03 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA24417 for ipp-outgoing; Tue, 25 Feb 1997 17:42:18 -0500 (EST) Message-Id: <3.0.1.32.19970225144217.00e5bcb8@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 25 Feb 1997 14:42:17 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> MOD - ISSUE - Revised discussion paper on Architecture Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Architecture View of IPP (This is a revised and narrowed down version of my earlier paper, after discussion with Tom Hastings today, and focused on the changes that we now suggest should be made to the model document). =20 I want us to take a step back and consider that although IPP version 1 will have a more limited set of capabilities than DPA, we still have to pay attention that we get a foundation on which we can expand in future= versions. I am not trying to make things more complex than they are currently planned to be, but would like to see a better structure in how we design them. The two areas in which I think we could do better are in defining objects, and in selecting the right level of operations: Objects I strongly favor having Document as an object. Scott has informed me that the MOD group has already accepted to define Document as an object, although it is not yet fully reflected in the working document, so this is not an issue any more. Operations I would like to see operations that are related to the IPP objects. My assumption is that we have three main objects in IPP version 1 - Printer, Job, and Document. Here are the operations that I would like to see: =B7 Get Printer Attributes This would be used to find out about printer capabilities, and possibly status, before submitting a Job. The printer capabilities could be cashed, so this operation does not need to be made for every print request. =B7 Create Job Used to initiate a new Job. It would contain all the Job attributes needed to validate if the job can be done (although you can still run into problems when document data is passed later).=20 The client would receive a response, confirming if the job can be done or not (with error codes) and a job-id is returned if accepted.=20 =B7 Add Document (to Job) This operation would be used to send one document, with its Document Attributes, if any. It would contain the job-id, so the Printer knows to which Job it belongs. Alternatively, one Document Reference could be sent, with its Document Attributes, if any. The server would return success or error (with error codes). Jobs could still be turned down at this stage, e.g. if the printer does not support the document format or if it cannot fulfill any of the Document attributes. =B7 Close Job This operation just signals to the Printer that all Documents belonging to the Job have been sent. =B7 Cancel Job Operation to delete a Job. As default, also deletes the associated Documents. =20 =B7 Get Job Attributes This operation is used to check up on a Job=92s current attribute settings, as well as the Job status. (May also include some Printer status attributes, which are necessary to explain the Job status). =B7 Send Job Notification (probably realized on a different transfer= protocol) This operation would send success or failure notifications about the Job from the server to the client and possibly others, such as the operator or administrator, or an intended recipient for the Job output. This definition should include the minimum amount of information sent back (which should be in machine readable format, and optionally in human readable form). =B7 Send Printer Notification (probably realized on a different transfer protocol) This is intended to signal problems with the Printer (may be due to problems on the device). It can be sent to the operator (or the end-user if there is no dedicated operator). This definition should include the minimum amount of information sent back (which should be in machine readable format, and optionally in human readable form). An assumption is still that several "model" operations, can be combined when we map them to a particular transfer protocol such as HTTP 1.1. For example, the operations Create Job, Add Document, and Close Job could be combined in cases where one small document is to be sent. At the same time, these operations could be mapped to separate transfer operations for bigger documents or multiple document cases. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Tue Feb 25 18:57:03 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA24830 for ipp-outgoing; Tue, 25 Feb 1997 18:56:49 -0500 (EST) Message-Id: <199702252357.AA18481@interlock.lexmark.com> To: "rdebry%us.ibm.com" Cc: "ipp%pwg.org" From: Don Wright Date: 25 Feb 97 18:45:04 EST Subject: Re: IPP>ADM Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I agree with Roger's proposal with one minor twist --- I think I would call the directory something like Public_Drafts or something like that since most of the documents there won't actually be Internet Drafts at the time they are posted. This will also make the WEBMaster's job easier since he won't have to change the WEB page to point to a different name everytime one is uploaded. Any other opinions? Don To: ipp%pwg.org @ interlock.lexmark.com @ SMTP cc: (bcc: Don Wright) From: rdebry%us.ibm.com @ interlock.lexmark.com @ SMTP Date: 02/25/97 03:05:18 PM Subject: IPP>ADM Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 As I've pointed people to the PWG ftp site to get the IPP documents, it has become increasingly difficult to point them to the latest documentation. The I-Ds are spread across several directories and they are changing over time. I'd like to propose the following idea -- what if we kept a copy of the latest internet drafts in one common place with a standard name so that we could point people unfamiliar with the history and reams of documentation out there to one place where they could get the lastest and greatest. For example, have a directory called "Current-Internet-Drafts" which would have in it "Model", "Requirements", Directory-Schema", and "Protocol" etc. without version numbers. We could choose to promote documents to this directory when we were re ady to have the rest of the world read and comment on them. From ipp-archive Tue Feb 25 22:27:06 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA25312 for ipp-outgoing; Tue, 25 Feb 1997 22:24:24 -0500 (EST) Message-Id: <3.0.1.32.19970225192321.0148ab90@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 25 Feb 1997 19:23:21 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC - Weekly phone conference 970227 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO We will hold the next phone conference for the SEC subgroup on Thursday, February 27, at 1pm Pacific time (duration up to two hours). Agenda items: - Report from Jerry on IBM security architecture board meeting and their input for IPP (new try) - Comments on the list of requirements (sent by Roger to the IPP DL) - Requirements list from a security perspective (Jerry) - Report from Daniel and Carl-Uno about security services/protocols. - Discussion about how to start a secure IPP transfer (client/server?) and which attributes we will need in the directory and/or printer object to support it. - Do we need to create a separate issues list for security? - Find a new time for coming SEC phone conferences. ---- The conference number is: 1-800-857 5607 with passcode: cmanros New participants are always welcome! Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Wed Feb 26 01:27:07 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA25809 for ipp-outgoing; Wed, 26 Feb 1997 01:25:55 -0500 (EST) Message-ID: <330E18A2.29EA@mail.utexas.edu> Date: Fri, 21 Feb 1997 13:50:26 -0800 From: Maureen Cockerill Carter Organization: University of Texas at Austin X-Mailer: Mozilla 3.0Gold (Win95; I; 16bit) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> DIR - Directory Issues Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Directory Team, Document directory-issues.doc does not contain all of the issues in document IPP-DIR-ISSUES-01.doc. Both documents are in the new-DIR directory. IPP-DIR-ISSUES-01.doc contained all of the directory issues I could find in the email and/or notes from previous telecons as of 1/24/97. I propose that the issues in IPP-DIR-ISSUES-01.doc (the issues which are not redundant with the issues already documented in directory-issues.doc) be added to directory-issues.doc. Unfortunately, I didn't note who initiated each issue in IPP-DIR-ISSUES-01.doc. Also, I proposed a solution to most issues in IPP-DIR-ISSUES-01.doc to spark some feedback. These proposals probably don't belong in directory-issues.doc. Take care, Keith Carter From ipp-archive Wed Feb 26 02:52:09 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA26232 for ipp-outgoing; Wed, 26 Feb 1997 02:48:27 -0500 (EST) Message-Id: <9702260748.AA10262@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen (Unverified) X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Feb 1997 23:46:31 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Model 2/24/97 telecon minutes posted Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I've posted the minutes of the IPP Model telecon from Monday, 2/24/97. The agenda was printer-status. I've posted the minutes at: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/minutes/ -rw-r--r-- 1 pwg pwg 14336 Feb 26 07:42 970224-model-telecon-minutes.doc -rw-r--r-- 1 pwg pwg 12682 Feb 26 07:42 970224-model-telecon-minutes.pdf Tom From ipp-archive Wed Feb 26 06:22:12 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id GAA26777 for ipp-outgoing; Wed, 26 Feb 1997 06:17:09 -0500 (EST) Date: Wed, 26 Feb 1997 03:15:34 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199702261115.DAA19445@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP> IPP >MOD new model document Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have downloaded the document: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-1.4-rev.doc It has the changes that we agreed to during the meetings on Friday and Monday. The changes include the new printer-state changes. Look for revision marks to see the changes. There are not many. Bob Herriot From ipp-archive Wed Feb 26 11:47:14 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA27797 for ipp-outgoing; Wed, 26 Feb 1997 11:42:46 -0500 (EST) X-Nvlenv-01Date-Transferred: 26-Feb-1997 11:22:07 -0500; at X-WB-AREA-HUB.XEROX X-Nvlenv-01Date-Transferred: 26-Feb-1997 11:15:33 -0500; at X-WB-NGM-MIME.XEROX X-Nvlenv-01Date-Posted: 26-Feb-1997 11:13:25 -0500; at X-WB-0311-MS3.XEROX Date: Wed, 26 Feb 1997 08:16:48 PST From: Peter_Zehler@wb.xerox.com (Zehler,Peter) To: IPP@pwg.org (IPP redirector) Subject: IPP> MOD optional attributes for more info and driver installer Message-Id: <"<865F143381E2667C>865F143381E2667C@X-WB-0311-MS3.XEROX"@-SMF-> Sender: ipp-owner@pwg.org Precedence: first-class Status: RO All, The ability to obtain more information about a printer or to download the appropriate driver is outside the scope of IPP version 1. I am proposing 2 optional attributes be added to the printer. The attributes would be extensions of Printer Description Attributes. The attributes are printer-more-info and printer-driver-installer. These attributes are optional. The printer-more-info attribute is to be used to give the end user a URI to obtain additional information. The URI is intended to provide a hook for printer venders or pay-for-print operations to interact with end users in ways outside the scope of IPP(e.g. cost of a print job, locations of driver installers, map to location). The printer-driver-installer attribute is a URI to a "installer service". The intention is that this is a programmatic hook to obtain the appropriate driver. Protocol specific mechanisms will be used to obtain the driver installer for the correct client environment. I have some HTTP specific examples below. The use of a simple URI here implies that no special treatment of this attribute is implied. The IPP printer does not require any additional knowledge of the client environment to satisfy the GetAttribute request. The IPP protocol is not complicated by the print driver installation hook. The two attributes should be in both the printer and directory services. Putting them in the printer permits client usage of these attributes in environments that are not using a directory service to represent their printers. The attribute must be in the printer when the printer is located by means outside directory services(e.g. URI in magazine advertisement). Inclusion of these attributes in the printer also permits printer vendors to provide factory default values enabling ease of installation. The value may be changed by printer configuration tools or administrator operations in IPP version 2. Inclusion of these attributes in the directory schema permits ease of administration. Site specific policies can be quickly enacted. The use of these attributes are not mandatory. I intend to provide an informational RFC to codify their use. This informational RFC is not part of the IPP standard. It is meant to document how actual implementations of driver download and additional information work in conjunction with IPP. ________________________ Example of multiple levels of driver installation service using IPP and HTTP Drivers already on client or install disk. Use the Printer Description Attribute, printer-model (or the proposed printer-device-id), to determine which driver to install. The driver is already on your system, on the OS install disk, or a vendor supplied printer install disk. In this scenario the client OS and language is known by the user and the appropriate driver is selected by the user. The driver install method is provided by the OS. Driver installer on printer Home Page. Use printer-more-info, to locate print driver installer page for the printer. Other mechanisms can be used to locate the page such as knowing the printer vendors Home Page and following links, advertisement, word of mouth etc. An end user is required to interpret the information on the print driver installer page and select the appropriate driver installer for the client OS. The intention here is the printer Home Page is specific to the associated printer. Driver installer obtained from URI in non-IPP fashion. Issue an HTTP Get to the URI from the printer-driver- installer attribute to get the appropriate driver. The Installer provider can provide service in an implementation specific fashion. It may just default to some specific installer(eg NT 5.0). A super-Installer could be downloaded. This would be responsible for obtaining the parameters required to install the appropriate driver in the client environment. The third way a provider may download the appropriate driver Installer is to look at the product tokens in the HTTP Get request. The tokens and their formats are not standard and vary from browser to browser. Driver installer obtained from URI in IPP fashion. Issue an HTTP Get to the URI from the printer-driver-installer attribute to get the appropriate driver. Included in the Get will be IPP specific product tags. The Installer will use IPP product tags in the HTTP Get request to determine which installer to download to the client. Pete From ipp-archive Wed Feb 26 13:52:15 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA28324 for ipp-outgoing; Wed, 26 Feb 1997 13:50:40 -0500 (EST) From: rdebry@us.ibm.com X400-Originator: rdebry@us.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100005209519000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100005209519000002*@MHS> To: Subject: IPP>MOD Date: Wed, 26 Feb 1997 13:48:59 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 I've drawn up the following diagram to help me think about the components in an IPP system. Perhaps this would be useful in the model document. Does the picture look about right? I'd appreciate any comments. You'll need a monospace font for things to line up right. o +-------------+ \|/ | Application | / \ +------+------+ End-User | +-------------+ +-----+ +------+-------+ | Browser | | GUI | | Print Driver | +------+------+ +--+--+ +------+-------+ | | | | +---+------------+---+ D S | | IPP Client | I E | +---------+----------+ R C | | E U C R ---------- HTTP ----------- T I O T | R Y | Y +---------+---------+ | Web Server | +---------+---------+ | +---------+---------+ | IPP Server | +---------+---------+ | +---------+---------+ | Print Service | +---------+---------+ | Output Device(s) From ipp-archive Wed Feb 26 14:42:15 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA28711 for ipp-outgoing; Wed, 26 Feb 1997 14:40:42 -0500 (EST) Message-ID: From: Babak Jahromi To: "'rdebry@us.ibm.com'" , ipp@pwg.org Subject: RE: IPP>MOD Date: Wed, 26 Feb 1997 11:42:26 -0800 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I am not sure what you mean by GUI in the diagram? Isn't GUI part of the application? Also, appliaction calls the Printer driver directly, assuming my understanding of the the GUI piece is correct. There is usually another component between Printer Driver and "IPP client", namely the spooler. Unless you were including the spooler in the Printer Driver (but spooler is normally running as a separate process from the app). So most likely the IPP client would be running as a spooler component. Also, I am not sure how the browser would work independent of the IPP client. Are you assuming the browser would have the IPP client built-in? Babak > -----Original Message----- > From: rdebry@us.ibm.com [SMTP:rdebry@us.ibm.com] > Sent: Wednesday, February 26, 1997 10:49 AM > To: ipp@pwg.org > Subject: IPP>MOD > > Classification: > Prologue: > Epilogue: Roger K deBry > Senior Techncial Staff Member > Architecture and Technology > IBM Printing Systems > email: rdebry@us.ibm.com > phone: 1-303-924-4080 > > I've drawn up the following diagram to help me think about the > components > in an IPP system. Perhaps this would be useful in the model document. > Does the picture look about right? I'd appreciate any comments. > You'll need a monospace font for things to line up right. > > o +-------------+ > \|/ | Application | > / \ +------+------+ > End-User | > +-------------+ +-----+ +------+-------+ > | Browser | | GUI | | Print Driver | > +------+------+ +--+--+ +------+-------+ > | | | > | +---+------------+---+ > D S | | IPP Client | > I E | +---------+----------+ > R C | | > E U > C R ---------- HTTP ----------- > T I > O T | > R Y | > Y +---------+---------+ > | Web Server | > +---------+---------+ > | > +---------+---------+ > | IPP Server | > +---------+---------+ > | > +---------+---------+ > | Print Service | > +---------+---------+ > | > Output Device(s) > From ipp-archive Wed Feb 26 15:22:14 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA29091 for ipp-outgoing; Wed, 26 Feb 1997 15:21:59 -0500 (EST) From: rdebry@us.ibm.com X400-Originator: rdebry@us.ibm.com X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100005215138000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100005215138000002*@MHS> To: , Subject: RE: IPP>MOD Date: Wed, 26 Feb 1997 15:20:18 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 Babek asked the following questions with regard to my diagram: I am not sure what you mean by GUI in the diagram? Isn't GUI part of the application? Also, appliaction calls the Printer driver directly, assuming my understanding of the the GUI piece is correct. RKD> The GUI here is meant to be an IPP GUI, that is, it provides RKD> a GUI to functions provided by the IPP Client. It is not RKD> the application's GUI. The Browser in this picture may be RKD> a legacy Browser with no special support for IPP, In this case RKD> it could do things like get job status, just as in your NT 5.0, RKD> using html templates. There is usually another component between Printer Driver and "IPP client", namely the spooler. Unless you were including the spooler in the Printer Driver (but spooler is normally running as a separate process from the app). So most likely the IPP client would be running as a spooler component. RKD> I could add a spooler as you suggest, but wonder if it would be RKD> there for all possible clients. Maybe it's in the picture as an RKD> optional component. Also, I am not sure how the browser would work independent of the IPP client. Are you assuming the browser would have the IPP client built-in? RKD> No, I am assuming a vanilla Browser with no IPP support. One could RKD> think of the combination of the GUI and the IPP client as an IPP RKD> enabled browser (if it provided browser function in addition to RKD> IPP function). > > o +-------------+ > \|/ | Application | > / \ +------+------+ > End-User | > +-------------+ +-----+ +------+-------+ > | Browser | | GUI | | Print Driver | > +------+------+ +--+--+ +------+-------+ > | | | > | +---+------------+---+ > D S | | IPP Client | > I E | +---------+----------+ > R C | | > E U > C R ---------- HTTP ----------- > T I > O T | > R Y | > Y +---------+---------+ > | Web Server | > +---------+---------+ > | > +---------+---------+ > | IPP Server | > +---------+---------+ > | > +---------+---------+ > | Print Service | > +---------+---------+ > | > Output Device(s) > From ipp-archive Wed Feb 26 18:32:17 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA29789 for ipp-outgoing; Wed, 26 Feb 1997 18:27:20 -0500 (EST) From: rdebry@us.ibm.com X400-Originator: rdebry@us.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100005226713000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100005226713000002*@MHS> To: Subject: IPP>MOD - Updated Diagram Date: Wed, 26 Feb 1997 18:25:37 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 Here is an updated diagram based on Babek's comments and those made during today's phone call. Comments??? +-------------+ | Application | +-----+-------+ | o +-----+-------+ \|/ | Spooler | / \ +------+------+ End-User | +-----+ +------+-------+ | GUI | | Print Driver | +--+--+ +------+-------+ | | +---+------------+---+ D S | IPP Client | I E +---------+----------+ R C | E U C R --------- Transport ----------- T I O T | R Y +--------+----------+ Y | IPP Server | +--------+----------+ | +--------+----------+ | Print Service | +--------+----------+ | Output Device(s) From ipp-archive Wed Feb 26 18:57:17 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA00164 for ipp-outgoing; Wed, 26 Feb 1997 18:52:22 -0500 (EST) Date: Wed, 26 Feb 1997 15:50:35 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199702262350.PAA19841@woden.eng.sun.com> To: scott_isaacson@novell.com, robert.herriot@Eng.Sun.COM, don@lexmark.com, ipp@pwg.org, JON@xcd.com Subject: Re: IPP> Dumb question X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO > From JON@xcd.com Tue Feb 25 12:12:22 1997 > > Is the IETF Internet Printing Protocol (IPP) the same thing as the > Novell-initiated LDPA (Lightweight Document Printing Application) > specification that received a lot of attention at the end of last year? > The IPP effort grew out of the LDPA submission (Xerox and Novell) and HTPP submission (IBM). But IPP is not the same. Bob Herriot From ipp-archive Wed Feb 26 21:07:19 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA00724 for ipp-outgoing; Wed, 26 Feb 1997 21:05:34 -0500 (EST) Date: Wed, 26 Feb 1997 18:03:56 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199702270203.SAA19988@woden.eng.sun.com> To: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP>MOD - Updated Diagram X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Although your picture now reflects Windows applications more accurately, it is now too Windows specific. If the spooler and driver box were eliminated, then this diagram would indicate that a client application interacts with the ipp client (library). For Windows the application consists of a spooler, driver and print provider, but that is probably more detail than our document needs. Also, the browser is just a special application, though it may be important enough to show separately. Bob Herriot > From rdebry@us.ibm.com Wed Feb 26 15:27:55 1997 > > Here is an updated diagram based on Babek's comments and those > made during today's phone call. Comments??? > > > > > > > > +-------------+ > | Application | > +-----+-------+ > | > o +-----+-------+ > \|/ | Spooler | > / \ +------+------+ > End-User | > +-----+ +------+-------+ > | GUI | | Print Driver | > +--+--+ +------+-------+ > | | > +---+------------+---+ > D S | IPP Client | > I E +---------+----------+ > R C | > E U > C R --------- Transport ----------- > T I > O T | > R Y +--------+----------+ > Y | IPP Server | > +--------+----------+ > | > +--------+----------+ > | Print Service | > +--------+----------+ > | > Output Device(s) > > > From ipp-archive Wed Feb 26 21:22:18 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA01065 for ipp-outgoing; Wed, 26 Feb 1997 21:20:30 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 26 Feb 1997 10:10:44 -0700 From: "Scott A. Isaacson" To: robert.herriot@eng.sun.com, don@lexmark.com, ipp@pwg.org, JON@xcd.com Subject: IPP> Dumb question -Reply Sender: ipp-owner@pwg.org Precedence: first-class Status: RO At the November 1996 meeting, Novell presented a protocol for Internet Printing call LDPA. With the input and cooperation of many existing and new players in the Printer Working Group (PWG http://www.pwg.org/) that proposal has become Internet Printing Protocol (IPP). LDPA was an RPC based end user view of DPA. IPP is even more simplified, and there is much discussion as to whether IPP will be based on standard HTTP or HTTP with extensions. Come and get involved. See http://www.pwg.org/ipp/ ************************************************************ 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: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ >>> 02/25/97 12:40pm >>> Is the IETF Internet Printing Protocol (IPP) the same thing as the Novell-initiated LDPA (Lightweight Document Printing Application) specification that received a lot of attention at the end of last year? From ipp-archive Thu Feb 27 09:52:25 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA02918 for ipp-outgoing; Thu, 27 Feb 1997 09:48:35 -0500 (EST) From: Keith_Carter@aussmtp.austin.ibm.com X-Lotus-FromDomain: AUSNOTES To: ipp@pwg.org Message-ID: <8625644B:004FD54D.00@aussmtp3.austin.ibm.com> Date: Thu, 27 Feb 1997 08:48:35 -0500 Subject: IPP>MOD - COMMENTS ON UPDATED DIAGRAM Mime-Version: 1.0 Content-type: text/plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Roger, Thanks for taking the ball on this. My comments are as follows: 1. "Event Notification" should be shown vertically next to Directory and Security since an IPP Printer can send print events to an end-user via email or HTTP. 2. The diagram doesn't show that an IPP Server can reside in an output device. Perhaps the diagram should replace "IPP Server", "Print Service" and "Output Device" with "IPP Printer". The Model spec already shows the various configurations for an "IPP Printer" so the diagram doesn't have to repeat those configurations. I'll review this diagram with others and, after the review, send any additional comments. Have a super day, Keith To: Keith Carter cc: From: DELEGATE @ AUSVMR Date: 02-26-97 05:38:26 PM Subject: IPP>MOD - UPDATED DIAGRAM To: KCARTER --AUSNOTES From: DELEGATE Subject: IPP>MOD - UPDATED DIAGRAM +--------------------------------------------------------------------------+ H The following note is being forwarded from KCARTER at AUSVMR. H H DO NOT USE the F6 REPLY function to reply to this note. You must H H contact the sender directly if you wish to reply, and not DELEGATE. H +--------------------------------------------------------------------------+ ---------------------------- Note: ------------------------------------- Received: from lists.underscore.com by vnet.IBM.COM (IBM VM SMTP V2R3) with Wed, 26 Feb 97 18:29:56 EST Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7 Received: by pwg.org (bulk_mailer v1.5); Wed, 26 Feb 1997 18:28:26 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA From: rdebry@us.ibm.com X400-Originator: rdebry@us.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: ó/ADMD=IBMSMTP/C=US/;5030100005226713000002y X400-Content-Type: P2-1988 (22) Message-Id: <5030100005226713000002*@MHS> To: Subject: IPP>MOD - Updated Diagram Date: Wed, 26 Feb 1997 18:25:37 -0500 Sender: ipp-owner@pwg.org Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 Here is an updated diagram based on Babek's comments and those made during today's phone call. Comments??? +-------------+ H Application H +-----+-------+ H o +-----+-------+ \H/ H Spooler H / \ +------+------+ End-User H +-----+ +------+-------+ H GUI H H Print Driver H +--+--+ +------+-------+ H H +---+------------+---+ D S H IPP Client H I E +---------+----------+ R C H E U C R --------- Transport ----------- T I O T H R Y +--------+----------+ Y H IPP Server H +--------+----------+ H +--------+----------+ H Print Service H +--------+----------+ H Output Device(s) >>>> DO NOT REPLY TO THIS NOTE <<<< From ipp-archive Thu Feb 27 10:52:26 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA03322 for ipp-outgoing; Thu, 27 Feb 1997 10:50:23 -0500 (EST) From: rdebry@us.ibm.com To: , <"robert.herriot@ENG"@??.ibm.com>, Subject: Re: IPP>MOD - Updated Diagram Message-Id: <5030100000004091000002L012*@MHS> Date: Thu, 27 Feb 1997 10:48:59 -0500 Mime-Version: 1.0 Content-Type: text/plain; name="MEMO 02/27/97 10:52:01" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 Bob, because of the number of windows clients and the desktop appIications that run on windows clients, I believe that the Windows case is too important to simplify as you've suggested. However the diagram could possibly show spooler and device driver as optional components. Any one else have strong feelings on this? ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/27/97 08:42 AM --------------------------- ipp-owner @ pwg.org 02/26/97 07:07 PM To: Roger K Debry/Boulder/IBM, ipp @ pwg.org@internet cc: Subject: Re: IPP>MOD - Updated Diagram Although your picture now reflects Windows applications more accurately, it is now too Windows specific. If the spooler and driver box were eliminated, then this diagram would indicate that a client application interacts with the ipp client (library). For Windows the application consists of a spooler, driver and print provider, but that is probably more detail than our document needs. Also, the browser is just a special application, though it may be important enough to show separately. From ipp-archive Thu Feb 27 11:12:31 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA03643 for ipp-outgoing; Thu, 27 Feb 1997 11:09:26 -0500 (EST) X-Nvlenv-01Date-Transferred: 27-Feb-1997 11:04:09 -0500; at X-WB-AREA-HUB.XEROX X-Nvlenv-01Date-Transferred: 27-Feb-1997 10:57:40 -0500; at X-WB-NGM-MIME.XEROX X-Nvlenv-01Date-Posted: 27-Feb-1997 10:55:10 -0500; at X-WB-0311-MS3.XEROX Date: Thu, 27 Feb 1997 07:58:25 PST From: Peter_Zehler@wb.xerox.com (Zehler,Peter) To: IPP@pwg.org (IPP redirector) Subject: IPP> TES Message-Id: <"D9AD153381E2667C@X-WB-0311-MS3.XEROX"@-SMF-> Sender: ipp-owner@pwg.org Precedence: first-class Status: RO All, I am available and willing to serve as the whip for the prototype group. Pete From ipp-archive Thu Feb 27 11:27:28 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA04100 for ipp-outgoing; Thu, 27 Feb 1997 11:24:40 -0500 (EST) Message-Id: <9702271624.AA10650@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Feb 1997 08:22:46 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Model Minutes from 2/21/97 is 0 bytes long! Sender: ipp-owner@pwg.org Precedence: first-class Status: RO -rw-r--r-- 1 pwg pwg 0 Feb 24 20:06 970221-model-minutes.PDF Tom From ipp-archive Thu Feb 27 11:47:26 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA04441 for ipp-outgoing; Thu, 27 Feb 1997 11:46:29 -0500 (EST) From: rdebry@us.ibm.com To: Subject: IPP>MOD - Model diagram Message-Id: <5030100000007184000002L042*@MHS> Date: Thu, 27 Feb 1997 11:45:06 -0500 Mime-Version: 1.0 Content-Type: text/plain; name="MEMO 02/27/97 11:47:14" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 Here is another rev of the diagram, based on comments from Keith and Bob. dotted boxes (...) indicate optional components. For example, a Windows client would include a spooler and a device driver. A Unix client might not. Similarly, an IPP Printer may include a Printing Service (spooler, scheduler, etc.) but may simply be an IPP Server in the output device. Comments? +--------------+ | Application | +------+-------+ | o +..............+ \|/ | Spooler | / \ +..............+ End-User | +-----------+ +-----+ +..............+ | Browser | | GUI | | Print Driver | +-----+-----+ +--+--+ +..............+ | | | | +---+------------+---+ N D S | | IPP Client | O I E | +---------+----------+ T R C | | I E U | F C R -------------- Transport ----------- I T I C O T | --+ A R Y +--------+--------+ | T Y | IPP Server | | I +--------+--------+ | O | | N +.................+ | IPP Printer | Print Service | | +.................+ | | | Output Device(s) | --+ From ipp-archive Thu Feb 27 12:02:29 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA04845 for ipp-outgoing; Thu, 27 Feb 1997 11:59:13 -0500 (EST) Message-Id: <9702271649.AA10659@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Feb 1997 08:47:13 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Model 1.4 pdf and pdr files posted Sender: ipp-owner@pwg.org Precedence: first-class Status: RO -rw-r--r-- 1 pwg pwg 279040 Feb 26 11:09 ipp-model-1.4-rev.doc -rw-r--r-- 1 pwg pwg 201460 Feb 27 16:46 ipp-model-1.4-rev.pdf -rw-r--r-- 1 pwg pwg 203030 Feb 27 16:47 ipp-model-1.4-rev.pdr The PDF has the revision marks in black and the pdr has the revision marks in red. Tom From ipp-archive Thu Feb 27 12:07:30 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA05173 for ipp-outgoing; Thu, 27 Feb 1997 12:04:40 -0500 (EST) Message-ID: <3315BD7E.6173@underscore.com> Date: Thu, 27 Feb 1997 11:59:42 -0500 From: Jeff Schnitzer Organization: Underscore, Inc. X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: Tom Hastings CC: kcarter@vnet.ibm.com, ipp@pwg.org Subject: Re: IPP> MOD - Model Minutes from 2/21/97 is 0 bytes long! References: <9702271624.AA10650@zazen.cp10.es.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Tom Hastings wrote: > > -rw-r--r-- 1 pwg pwg 0 Feb 24 20:06 970221-model-minutes.PDF > > Tom Uh, I just checked our FTP log. It was 0 bytes long when uploaded by Keith on Mon Feb 24 17:07:13 EST. Since that time there have been eight downloads of the file -- and Tom's the first to report the problem! I've deleted the empty file from the server so Keith may try uploading it again. /Jeff --------------------------------------------------------------- Jeffrey D. Schnitzer | Email: jds@underscore.com Underscore, Inc. | Voice: (603) 889-7000 41-C Sagamore Park Rd | Fax: (603) 889-2699 Hudson, NH 03051-4915 | Web: http://www.underscore.com --------------------------------------------------------------- From ipp-archive Thu Feb 27 12:17:27 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA05535 for ipp-outgoing; Thu, 27 Feb 1997 12:17:13 -0500 (EST) Message-Id: <3.0.1.32.19970227091541.01823e00@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 27 Feb 1997 09:15:41 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC - Some input for today's phone conference Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: first-class Status: RO The following text contains all of the possible boilerplate type text that we might use to explain security in general. This was compiled by Daniel Manchala at erox from various sources on security in netwoks. It probably contains more than what we want to include in IPP right now, but we should discuss what to cross out and what to keep. ---- Security Services=20 The following is a list of terms that is defined for the Security Infrastructure Working Group. It has only basic terms, plus those terms with controversial or multiple meanings. For a more complete glossary of security terms, see Network Security by Charlie Kaufmann, Radia Perlman & Mike Speciner; Computer Security Basics by Deborah Russell & G. T. Gabgemi Sr; or The Directory, CCITT Recommendations of the X.500 Series, 89/267=20 Basic Concepts 1 AAA: Overall term for security. The three A's are generally taken to be Authentication, Authorization, and Auditing although it may mean Authentication, Authorization & Accounting in some contexts.=20 2 Authentication: The process of reliably determining the identity of a communicating party. There are three classic ways of authenticating oneself: something you know, something you have and something you are. The two entities involved in the communication could use the following two ways to authenticate themselves. =B7 Single entity authentication. Only one of the entities is authenticated by the other. It could be either data origin or data recipient= authentication. =B7 Mutual authentication. Both the parties authenticate each other. 3 Authorization: The granting of rights to a user, program or process. Permission to access a resource. It is used to protect a resource from unauthorized use. This can be achieved by the use of access control lists (ACL) or capabilities. 4 Auditing: Keep a record of events that might have some significance, such as when access to resources occurred. To record independently and later examine system activity. Audit data is generally used for security concerns (e.g. intrusion detection and consistency checks).=20 5 Accounting: Keep a record of events that might have some significance, such as when access to resources occurred, who accessed it, what was accessed and for how long. Accounting data is generally used for commercial concerns (e.g. billing and charges).=20 Security Service Attributes 1. Anonymity: The ability to communicate so that the other principal can't find out the identity of the sender.=20 2. Integrity: Keeping information from corruption or unauthorized modification either maliciously or accidentally. Integrity protects against forgery or tampering.=20 3. Non-Repudiation: There is proof who sent a message that a recipient can show to a third party and the third party can independently verify the source.=20 4. Privacy (Confidentiality): Protection from the unauthorized disclosure of data.=20 Encryption Concepts 1. Encryption: To scramble information so that only someone knowing the appropriate secret can obtain the original information.=20 2. Public Key: Dual key (RSA/PGP style) cryptography. Uses two different keys, either one for encryption and the other for decryption. Also called a asymmetric cryptography.=20 3. Secret Key: Single key cryptography. Also called symmetric cryptography.= =20 4. Session Key: A short lived Secret Key used by two principals for the purpose of secure communications between them.=20 Authorization Concepts ACL: Access Control List. A list of the subjects authorized to access that object. The list usally indicates what type of access is allowed for each user.=20 Groups: A named set of users, created for convenience in stating authorization policy.=20 Roles: A specific function a principal plays with respect to another principal. Examples include a system administrator of a individual computer system, and a bank teller at a particular bank. If a principal has multiple functions with respect to another principal, it has multiple roles (e.g. A person can have both the bank teller role and the customer role at a particular bank).=20 Capability: An identifier that specifies an object and the access rights for the subject who possess the capability. See also "Certificate / Ticket / Token"=20 =20 Proxy Agent: A principal that has been authorized to work on the behalf of another.=20 Proxy: A token that grants the rights of a principal to another.=20 Restricted Proxy: A token that grants the rights of a principal to another while placing restrictions on the privileges granted.=20 Certificate / Ticket / Token: Different names for a object used to grant privileges. While these terms have individual meanings in specific contexts (Kerberos generates tickets, physical objects are tokens), there is no general agreement on how they differ. We will use Certificate / Ticket / Token largely interchangeably. Capability & Proxy are related terms, but with narrower focus.=20 CRL: Certificate Revocation List. A list of revoked certificates.=20 Miscellaneous Denial of Service: An action that prevents a system or its resources from functioning efficiently and reliably. The following table describes how some of the available security protocols would support the security services that we are looking for: S.No Services HTTP/1.1 SSL (V2) SSL (V3) LDAP 1. Authentication =B7 single entity Yes Yes Yes -- =B7 mutual No No Yes -- 2. Authorization =B7 ACL -- -- -- -- . Capabilities -- -- -- Yes =20 3. Non-repudiation No No No -- 4. Integrity No Yes Yes -- 5. Confidentiality No Yes Yes -- 6. Administration =B7 Certificate Mgmt. -- -- -- -- Yes -- means "not applicable" ---- The following text was produced after some discussion between Dainel and Carl-Uno. This is just intended as a problem description at this stage. We need to discuss which of these scenarios we want to support and how. We started looking at in which order the different protocols are invoked etc. and came up with a number of possible cases: =B7 The IPP server enforces security on all IPP clients that wants to talk t= o it, by switching from IPP to e.g. SSL if an IPP client tries to invoke any operation over IPP. If the client cannot respond, that is the end of the story. =B7 The IPP client wants to enforce security and starts off by invoking SSL before trying to invoke any IPP operations. If the server cannot respond, that is the end of the story. =B7 The IPP client may want to first find out if the IPP server supports a particular security protocol, such as SSL version 3. It then first invokes a Get Printer Attributes operation to get the information, or might get it over Directory, if the IPP server would refuse to answer. The IPP client should get the information back that the server supports security protocols A,B and C. The IPP client then chooses one, provided it has capability to use at least one of them and the communication goes along. =B7 The IPP server may want to enforce security, but rather then just refusing the connection it returns an error in which information about available security protocols are given as error reasons. =B7 A server or client may support both secure and non-secure printing. In this case it should be possible to inform each other about the possible options and allow each end to select what they want to do. Taking these different possible scenarios together, it starts looking like we might need either some kind of negotiation feature at the beginning of an IPP session in cases where either the IPP client or the IPP server end wants to use any of the security features, or we well need to define a fixed behavior pattern and possible restrictions for how server and clients should behave to invoke the security services. In either case, it looks like at a minimum, we will need to define a Printer attribute (multi-valued) that can give information about security protocols supported by the IPP server, and which can be found both as directory and as Printer atttributes. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Thu Feb 27 12:42:29 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA05963 for ipp-outgoing; Thu, 27 Feb 1997 12:40:05 -0500 (EST) From: rdebry@us.ibm.com To: Subject: IPP>MOD - HTML and IPP streams Message-Id: <5030100000010054000002L042*@MHS> Date: Thu, 27 Feb 1997 12:38:42 -0500 Mime-Version: 1.0 Content-Type: text/plain; name="MEMO 02/27/97 12:41:05" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 Yesterday's conference call was very lively. I appreciate the debate, it helps me to sort out things in my own mind. Based on the updated diagram I have drawn and posted in a separate note, and yesterdays discussion, I'd suggest the following relative to the use of HTML and IPP: A Web Browser must support HTML (pretty obvious) An IPP Client must support IPP, and may optionally support HTML An IPP Server must support IPP and may optionally support HTML. I don't think that we can say that an IPP Server MUST support HTML in order to be IPP compliant. Actually sounds pretty silly to me to say that HTML is required to be IPP compliant! I don't think that this is an interoperability issue, is it? From ipp-archive Thu Feb 27 13:47:28 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA06715 for ipp-outgoing; Thu, 27 Feb 1997 13:44:44 -0500 (EST) From: rdebry@us.ibm.com To: , Message-Id: <5030100000013426000002L062*@MHS> Date: Thu, 27 Feb 1997 13:43:20 -0500 Mime-Version: 1.0 Content-Type: text/plain; name="MEMO 02/27/97 13:45:56" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 Don, I gave the requirements document a quick read. The major comment I have is that the way the document is currently written, it would appear that the only required client interface is a Web Browser. While I would agree that using a Web Browser is an important requirement, the document should not lead one to believe that it is the only requirement! Since the first paragraph in the Terminology section discusses the use of Worl Wide Web tools, and Browsers are explicitly dicsussed in the second paragraph, there is no need to explicitly call out Browsers (and not mention other kinds of clients) in each of the remaining sections. For example: Change the title to "Requirements for An Internet Printing Protocol" In the abstract chnage the first sentence to read "This document describes the requirement for An Intrenet printing protocol." In section 2, REQUIREMENTS, change the first sentence to read "The next three scetions identify the requirements of an Internet printing protocol ..." In section 2.1.3, Viewing the status of a printer, chnage the first sentence to read "Before using a selected printer or, in fact at any time, the end user needs the ability to verify the characteristics and status of both printers and jobs queued for the printer." In section 2.1.4, Submitting a print job, change the 4th sentence to read "Printing by reference is defined as submitting a job and providing a reference to an existing document." In section 2.1.5, Viewing the status of a submitted print job, change the first sentence to read "After a job has been submitted to a printer, the end -user needs a way to view the status of that job (i.e. job waiting, job printing, job done)." From ipp-archive Thu Feb 27 14:22:28 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA07346 for ipp-outgoing; Thu, 27 Feb 1997 14:21:42 -0500 (EST) From: rdebry@us.ibm.com To: Subject: IPP>PRO - segments and synchronous responses Message-Id: <5030100000016765000002L052*@MHS> Date: Thu, 27 Feb 1997 14:20:16 -0500 Mime-Version: 1.0 Content-Type: text/plain; name="MEMO 02/27/97 14:23:23" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 In yesterday's call, I think it was Tom who suggested that a printer condition affecting the flow of data (such as out of paper) could be signaled asynchronously on a separate channel, leaving tcp flow control to manage holding up the data and restarting the flow when the printer problem was cleared. I am very hesitant to do this on a completely different channel (and by the way one that is not actually part of IPP). If we ever do get into situations where it is desireable or necessary to synchronize between the client and the server, it becomes very difficult when dealing with two completely different channels. o The user might turn notification off o The user might not "see" the notification, i.e. only looks at his email once a day. o The client will not see the notification, since it goes directly to the user. o The Printer has no choice but to wait until the condition is fixed, then continue to receive data o The client has no choice but to wait until the Printer begins receiving data again. It could detect that no data is flowing and warn the user, but it does not know why data is not flowing. This may be a dumb analogy, but consider the situation where I call my friend on the phone. As we talk, he smells smoke and discovers that his house is on fire. He says "wait a minute", and without saying anything more he goes away, leaving me on the phone waiting for him to say "go ahead". He then writes a letter (a separate channel) telling me his house is on fire, then proceeds to try to put it out. Seems pretty silly when compared to just saying "wait a minute, my house is on fire". From ipp-archive Thu Feb 27 15:37:28 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA08314 for ipp-outgoing; Thu, 27 Feb 1997 15:36:34 -0500 (EST) Date: Thu, 27 Feb 1997 12:34:27 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199702272034.MAA20561@woden.eng.sun.com> To: rdebry@us.ibm.com Subject: Re: IPP>MOD - Updated Diagram Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO If you are going to show the Windows case, then there are two ways. In both cases an application connects directly with an IPP client. Then either have another case with the intervening Windows pieces, or have a separate diagram to explode the application box for the Windows case. > From rdebry@us.ibm.com Thu Feb 27 07:50:58 1997 > From: rdebry@us.ibm.com > To: , <"robert.herriot@ENG"@??.ibm.com>, > > Subject: Re: IPP>MOD - Updated Diagram > Date: Thu, 27 Feb 1997 10:48:59 -0500 > Mime-Version: 1.0 > Sender: ipp-owner@pwg.org > X-Lines: 37 > > Classification: > Prologue: > Epilogue: Roger K deBry > Senior Techncial Staff Member > Architecture and Technology > IBM Printing Systems > email: rdebry@us.ibm.com > phone: 1-303-924-4080 > > Bob, because of the number of windows clients and the desktop appIications that > run on windows clients, I believe that the Windows case is too important to > simplify > as you've suggested. However the diagram could possibly show spooler and > device driver as optional components. > > Any one else have strong feelings on this? > ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/27/97 08:42 > AM --------------------------- > > ipp-owner @ pwg.org > 02/26/97 07:07 PM > > > To: Roger K Debry/Boulder/IBM, ipp @ pwg.org@internet > cc: > Subject: Re: IPP>MOD - Updated Diagram > > Although your picture now reflects Windows applications more > accurately, it is now too Windows specific. If the spooler and driver > box were eliminated, then this diagram would indicate that a client > application interacts with the ipp client (library). For Windows the > application consists of a spooler, driver and print provider, but that > is probably more detail than our document needs. > > Also, the browser is just a special application, though it may be > important enough to show separately. > > From ipp-archive Thu Feb 27 16:12:31 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA08953 for ipp-outgoing; Thu, 27 Feb 1997 16:08:26 -0500 (EST) Date: Thu, 27 Feb 1997 13:06:37 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199702272106.NAA20588@woden.eng.sun.com> To: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP>MOD - HTML and IPP streams X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO > From rdebry@us.ibm.com Thu Feb 27 09:40:59 1997 > From: rdebry@us.ibm.com > > ... I'd suggest the following relative to the use of HTML > and IPP: > > A Web Browser must support HTML (pretty obvious) > > An IPP Client must support IPP, and may optionally support HTML > > An IPP Server must support IPP and may optionally support HTML. > > I don't think that we can say that an IPP Server MUST support HTML in > order to be IPP compliant. Actually sounds pretty silly to me to say that > HTML is required to be IPP compliant! I don't think that this is an > interoperability issue, is it? > Actually, we did say that an IPP server must support IPP AND HTML because if HTML is optional, then a client which expects HTML, must have a fallback. If clients must have a fallback to IPP, then no server need have HTML. I think the primary issue is whether a server gives exactly the same information and capabilities via IPP and HTML. From ipp-archive Thu Feb 27 16:57:30 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA09823 for ipp-outgoing; Thu, 27 Feb 1997 16:55:46 -0500 (EST) Message-Id: <9702272155.AA10811@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Feb 1997 13:53:42 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> REQ - unable to read issues.pdf and closed.pdf with 2.1 acroread Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I get the following error reading issues.pdf and closed.pdf in the requirements sub-directory (new_REQ): There was an error processing this page. There was a problem reading this document(9). This file contains information not understood by this viewer. Do I need a later version of the acrobat reader? Thanks, Tom From ipp-archive Thu Feb 27 17:07:34 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA10337 for ipp-outgoing; Thu, 27 Feb 1997 17:03:45 -0500 (EST) Message-ID: <33160224.1A74@sharplabs.com> Date: Thu, 27 Feb 1997 13:54:03 -0800 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: Robert Herriot CC: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP>MOD - HTML and IPP streams References: <199702272106.NAA20588@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Keep in mind how future implementers are going to read the statement "A Server must support HTML". We (and some future incarnation of an IPP WG) are basically going to end up with a core IPP standards-track RFC, with several other supporting documents, similar to: * RFC XXXX IPP Model, Syntax and Semantics (Core Protocol) * RFC XXXX IPP over HTTP 1.1 (1 particular mapping) * RFC XXXX IPP over HTTP 1.0 (another...) * RFC XXXX IPP over ONC (yet another....) * RFC XXXX IPP over DCE (ditto) * RFC XXXX IPP over (Other transports, etc.) * RFC XXXX IPP Security * RFC XXXX IPP Commercial Transaction Extensions . . . Etc. IMHO, I think the core document should not mandate a particular mapping or HTML, an IPP implementation MUST be compliant with * The core document AND * One or more mapping documents And that should be about it. The way I see it, HTML is just another PDL, and is handled by some interpreter module that is outside the scope of IPP. The only thing that IPP includes that comes from the HTML world is the requirement that URLs/URNs/URIs must be generated and understood by clients and servers. Just my 0.02 worth Randy Robert Herriot wrote: > > > From rdebry@us.ibm.com Thu Feb 27 09:40:59 1997 > > From: rdebry@us.ibm.com > > > > ... I'd suggest the following relative to the use of HTML > > and IPP: > > > > A Web Browser must support HTML (pretty obvious) > > > > An IPP Client must support IPP, and may optionally support HTML > > > > An IPP Server must support IPP and may optionally support HTML. > > > > I don't think that we can say that an IPP Server MUST support HTML in > > order to be IPP compliant. Actually sounds pretty silly to me to say that > > HTML is required to be IPP compliant! I don't think that this is an > > interoperability issue, is it? > > > > Actually, we did say that an IPP server must support IPP AND HTML because > if HTML is optional, then a client which expects HTML, must have a fallback. > If clients must have a fallback to IPP, then no server need have HTML. > > I think the primary issue is whether a server gives exactly the same > information and capabilities via IPP and HTML. -- Randy Turner Network Architect Sharp Laboratories of America rturner@sharplabs.com From ipp-archive Thu Feb 27 17:12:32 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA10782 for ipp-outgoing; Thu, 27 Feb 1997 17:10:18 -0500 (EST) Message-Id: <199702272210.AA00755@interlock.lexmark.com> To: Tom Hastings Cc: "ipp%pwg.org" From: Don Wright Date: 27 Feb 97 17:09:22 EST Subject: Re: IPP> REQ - unable to read issues.pdf and closed.pdf with 2.1 acroread Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Tom: You really need to upgrade to Acrobat Reader 3.0 but... Attention everyone with the Acrobat Distiller Version 3.0 ---- Please set your distiller to generate Acrobat Reader version 2.1 PDF. This will insure that the widest possible audience is able to read what you generate. To do this follow these steps: 1) Launch the distiller 2) Select Distiller from the action bar 3) Select Job Options 4) In the File Settings select Acrobat 2.1 Compatibility To: ipp%pwg.org @ interlock.lexmark.com @ SMTP cc: (bcc: Don Wright) From: hastings%cp10.es.xerox.com @ interlock.lexmark.com (Tom Hastings) @ SMTP Date: 02/27/97 01:53:42 PM Subject: IPP> REQ - unable to read issues.pdf and closed.pdf with 2.1 acroread I get the following error reading issues.pdf and closed.pdf in the requirements sub-directory (new_REQ): There was an error processing this page. There was a problem reading this document(9). This file contains information not understood by this viewer. Do I need a later version of the acrobat reader? Thanks, Tom From ipp-archive Thu Feb 27 17:17:35 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA11183 for ipp-outgoing; Thu, 27 Feb 1997 17:16:37 -0500 (EST) Message-ID: <331605C9.50BA@sharplabs.com> Date: Thu, 27 Feb 1997 14:08:09 -0800 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> Ignore attachment Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Ignore the attachment I posted on my previous mail message...... Thanks Randy -- Randy Turner Network Architect Sharp Laboratories of America rturner@sharplabs.com From ipp-archive Thu Feb 27 17:17:35 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA11204 for ipp-outgoing; Thu, 27 Feb 1997 17:17:20 -0500 (EST) Message-Id: <199702272217.OAA17545@bulletin> To: Robert.Herriot@Eng.Sun.COM (Robert Herriot) cc: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP>MOD - HTML and IPP streams In-reply-to: Your message of "Thu, 27 Feb 1997 13:06:37 PST." <199702272106.NAA20588@woden.eng.sun.com> Date: Thu, 27 Feb 1997 14:17:26 PST From: "Steve Zilles" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO > Date: Thu, 27 Feb 1997 13:06:37 -0800 > From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) > > > From rdebry@us.ibm.com Thu Feb 27 09:40:59 1997 > > From: rdebry@us.ibm.com > > > > ... I'd suggest the following relative to the use of HTML > > and IPP: > > > > A Web Browser must support HTML (pretty obvious) > > > > An IPP Client must support IPP, and may optionally support HTML > > > > An IPP Server must support IPP and may optionally support HTML. > > > > I don't think that we can say that an IPP Server MUST support HTML in > > order to be IPP compliant. Actually sounds pretty silly to me to say that > > HTML is required to be IPP compliant! I don't think that this is an > > interoperability issue, is it? > > > > Actually, we did say that an IPP server must support IPP AND HTML because > if HTML is optional, then a client which expects HTML, must have a fallback. > If clients must have a fallback to IPP, then no server need have HTML. > > I think the primary issue is whether a server gives exactly the same > information and capabilities via IPP and HTML. I would express Rogers list of statements somewhat differently and I think the difference is important as to why we said we would require HTML from the user. A Web Browser must support HTML (pretty obvious) A Client of the IPP Model may support access to that model using an HTML binding to the model information. A Client of the IPP Model may support access to that model using an IPP defined binding to the model information (see Protocol Group) An IPP Server must support must support both the IPP defined binding and the HTML binding to the model information This recognizes the difference between supporting the model and supporting a partiucular binding to the model. At least from my point of view, this is why we made the statement. After some thought, I would be happy if a server only had to implement the HTML binding, both for query and submission. Steve From ipp-archive Thu Feb 27 18:02:32 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA13577 for ipp-outgoing; Thu, 27 Feb 1997 17:59:38 -0500 (EST) From: Keith_Carter@aussmtp.austin.ibm.com X-Lotus-FromDomain: AUSNOTES To: ipp@pwg.org Message-ID: <8625644B:00535F48.00@aussmtp3.austin.ibm.com> Date: Thu, 27 Feb 1997 16:37:55 -0500 Subject: IPP> MOD - Description of additional text formatting attributes Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Model Team, Here are the descriptions of additional text formatting attributes for the issue on page 33 of the 1.4 spec. I started the section numbers based on version 1.4 of the spec. 5.2.8.15 font-style (type2Enum) This job attribute specifies the style of the font to use for all text in the document. The standard values are: normal The characters are upright. bold The characters are bolded or highlighted. italic The characters are italicized. bold-italic The characters are bolded and italicized. NOTE TO MODEL TEAM: There are more styles but I tried to list the most common styles to hit the 80-20 rule so we don't spend too much time on this matter. 5.2.8.16 insert-line-numbers (boolean) This job attribute specifies that the lines should be numbered in the document. Line numbers will appear throughout the document on the left side of each printed line. 5.2.8.17 text-border (boolean) This job attribute specifies that a border should be drawn around each logical text block within the text document. The border shall be drawn throughout the text document on each page. A logical text block can be the entire page or a column. The standard values are: yes Draw a border. no Do not draw a border. 5.2.8.18 word-wrap (boolean) This job attribute specifies how long lines are printed in the document. The standard values are: yes Any text that extends beyond the right margin is moved to the next print line. no Any text that extends beyond the right margin is truncated at the right margin. 5.2.8.19 file-name (boolean) This job attribute automatically prints the file name of a document on each logical page. The file name appears throughout the document at a location on the page determined by an implementation. The standard values are: yes Print the file name on each logical page. no Do not print the file name on each logical page. 5.2.8.20 file-date (boolean) This job attribute automatically prints the file date of a document on each logical page. The file date appears throughout the document at a location on the page determined by an implementation. The standard values are: yes Print the file date on each logical page. no Do not print the file date on each logical page. 5.2.8.21 file-time (boolean) This job attribute automatically prints the file time of a document on each logical page. The file time appears throughout the document at a location on the page determined by an implementation. The standard values are: yes Print the file time on each logical page. no Do not print the file time on each logical page. NOTE TO MODEL TEAM. Support for file-name, file-date and file-time requires that these values be passed with a print job so the IPP Printer can place this information on each page. We might assert job-name has file-name. File information is useful so an end-user remembers what file they printed. I suppose if a Printer prints an HTML file by reference, then the file-name is the URL of the file. I'm not sure how to get file-date and file-time in that case. Let's discuss at our telecon on Friday, 2/28. Keith From ipp-archive Thu Feb 27 18:07:32 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA14183 for ipp-outgoing; Thu, 27 Feb 1997 18:05:42 -0500 (EST) Date: Thu, 27 Feb 1997 15:03:47 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199702272303.PAA20671@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, szilles@Adobe.COM Subject: Re: IPP>MOD - HTML and IPP streams Cc: ipp@pwg.org, rdebry@us.ibm.com X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO You stated quite well what I think we agreed to. I would like to be able to agree with your last statement: "After some thought, I would be happy if a server only had to implement the HTML binding, both for query and submission." But the last time I suggested it, others said that HTML would not be a good representation for a client that needs to get the meaning from it. Do you have some additional proposals to resolve this issue? Are you suggesting that HTML tags could hold such information? On another related issue, would you expect an IPP query could supply the sort of information that a ppd file supplies, namely the PostScript that is associated with a particular attribute value? Bob Herriot > From szilles@Adobe.COM Thu Feb 27 14:15:50 1997 > > > Date: Thu, 27 Feb 1997 13:06:37 -0800 > > From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) > > > > > From rdebry@us.ibm.com Thu Feb 27 09:40:59 1997 > > > From: rdebry@us.ibm.com > > > > > > ... I'd suggest the following relative to the use of HTML > > > and IPP: > > > > > > A Web Browser must support HTML (pretty obvious) > > > > > > An IPP Client must support IPP, and may optionally support HTML > > > > > > An IPP Server must support IPP and may optionally support HTML. > > > > > > I don't think that we can say that an IPP Server MUST support HTML in > > > order to be IPP compliant. Actually sounds pretty silly to me to say that > > > HTML is required to be IPP compliant! I don't think that this is an > > > interoperability issue, is it? > > > > > > > Actually, we did say that an IPP server must support IPP AND HTML because > > if HTML is optional, then a client which expects HTML, must have a fallback. > > If clients must have a fallback to IPP, then no server need have HTML. > > > > I think the primary issue is whether a server gives exactly the same > > information and capabilities via IPP and HTML. > > I would express Rogers list of statements somewhat differently and I > think the difference is important as to why we said we would require > HTML from the user. > > A Web Browser must support HTML (pretty obvious) > > A Client of the IPP Model may support access to that model using an > HTML binding to the model information. > > A Client of the IPP Model may support access to that model using an IPP > defined binding to the model information (see Protocol Group) > > An IPP Server must support must support both the IPP defined binding and > the HTML binding to the model information > > This recognizes the difference between supporting the model and > supporting a partiucular binding to the model. At least from my point of > view, this is why we made the statement. > > After some thought, I would be happy if a server only had to implement > the HTML binding, both for query and submission. > Steve > From ipp-archive Thu Feb 27 19:27:33 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA18782 for ipp-outgoing; Thu, 27 Feb 1997 19:22:41 -0500 (EST) Message-Id: <3.0.1.32.19970227161733.01829800@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 27 Feb 1997 16:17:33 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> MOD - Re. HTML and IPP streams In-Reply-To: <199702272106.NAA20588@woden.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO At 01:06 PM 2/27/97 PST, Robert Herriot wrote: > >> From rdebry@us.ibm.com Thu Feb 27 09:40:59 1997 >> From: rdebry@us.ibm.com >> >> ... I'd suggest the following relative to the use of HTML >> and IPP: >> >> A Web Browser must support HTML (pretty obvious) >> >> An IPP Client must support IPP, and may optionally support HTML >> >> An IPP Server must support IPP and may optionally support HTML. >> >> I don't think that we can say that an IPP Server MUST support HTML in >> order to be IPP compliant. Actually sounds pretty silly to me to say that >> HTML is required to be IPP compliant! I don't think that this is an >> interoperability issue, is it? >> > >Actually, we did say that an IPP server must support IPP AND HTML because >if HTML is optional, then a client which expects HTML, must have a fallback. >If clients must have a fallback to IPP, then no server need have HTML. > >I think the primary issue is whether a server gives exactly the same >information and capabilities via IPP and HTML. > I am starting to get really confused about this whole discussion. We have decided that the model specification is to be made in a TRANSPORT INDEPENDENT manner, and now people start suggesting that we should make IPP dependent on HTML! I think we are on the wrong track here and need to back up to the point, where people started assuming that we make HTML part of the package. My assumption up till now has been that certain functions in our overall scenarios COULD be realized by using HTTP/HTML, but that such functions would be OUTSIDE THE SCOPE of our three IPP standards document. I think that bringing in HTML in this disciussion is starting to mix in too many ideas about implementation into our model discussion, which we should not do. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Thu Feb 27 20:07:34 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA21244 for ipp-outgoing; Thu, 27 Feb 1997 20:05:24 -0500 (EST) Date: Thu, 27 Feb 1997 17:00:35 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199702280100.RAA20788@woden.eng.sun.com> To: ipp@pwg.org, Keith_Carter@aussmtp.austin.ibm.com Subject: Re: IPP> MOD - Description of additional text formatting attributes X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Below are some comments on the details of your proposal. But first a general comment. Although these are mostly useful features for a text converter, the question is whether they are basic enough to be in our model. Some, such as insert-line-numbers, might have additional attributes to control the numbering process in some implementations. Others, such as file-date and file-time might have a different arrangement of attributes in some implementations, e.g. file-date and file-time might be a single attribute with a date format as the value. I am not worried by features which could get more refinement with the addition of additional attributes. That's an easy extension, and the idea proposed by the attribute seems basic enough. But I do get concerned about features seem too arbitrary and would likely be performed by an entirely different attribute or set of attributes in other implementations. The three attributes that fall into this latter category are: file-name, file-date and file-time. Another implementation might give very different control over headers and footers. This leads me to wonder if these 3 attributes would be better handled by an extension mechanism that allows a Printer to provide additional attributes for the special features that it provides. Bob Herriot > From Keith_Carter@aussmtp.austin.ibm.com Thu Feb 27 15:00:56 1997> > > > 5.2.8.16 insert-line-numbers (boolean) > > This job attribute specifies that the lines should be numbered in the > document. Line > numbers will appear throughout the document on the left side of each > printed line. Please add the sentence: The number of the first line of the first page shall be 1. The number of the first line each page, except the first page, shall be one more than the number of the last line of the previous page. The Printer shall not number header and footer lines. > > 5.2.8.17 text-border (boolean) > > This job attribute specifies that a border should be drawn around each > logical text > block within the text document. The border shall be drawn throughout > the text > document on each page. A logical text block can be the entire page or > a column. > > The standard values are: > > yes Draw a border. > no Do not draw a border. Rather than defining "logical text block", I would prefer that the sentence state: This job attribute specifies that a border shall be drawn around each column of text on each page within the document. A Printer shall determine the size and position of each border from the size and position of the text column, and not from the position, length or width of the text within the text column. For example, the border for a text column is the same whether the text fills the column or ends part way down the column. > > 5.2.8.19 file-name (boolean) > > This job attribute automatically prints the file name of a document on > each logical > page. The file name appears throughout the document at a location on > the page > determined by an implementation. > > The standard values are: > > yes Print the file name on each logical page. > no Do not print the file name on each logical page. How are you defining logical page. I would prefer the following wording: This job attribute specifies whether the Printer shall print the file name of a document in the header or footer of each page. An implementation shall determine the location of the file name, i.e. header versus footer, and its position within the header or footer. > 5.2.8.20 file-date (boolean) Same comment as above. > 5.2.8.21 file-time (boolean) Same comment as above. This attribute and the one above raise the general question that I have above about parametization of a filter. Another implementation might combine file-date and file-time into a single attribute with various formats supported. > Let's discuss at our telecon on Friday, 2/28. If I remember correctly, our telecon is Monday 3/3 at 10 AM PST. From ipp-archive Thu Feb 27 20:12:35 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA21806 for ipp-outgoing; Thu, 27 Feb 1997 20:10:40 -0500 (EST) Date: Thu, 27 Feb 1997 17:08:40 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199702280108.RAA20807@woden.eng.sun.com> To: ipp@pwg.org, cmanros@cp10.es.xerox.com Subject: Re: IPP> MOD - Re. HTML and IPP streams X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO HTML, etc. are part of the protocol documents. The model document will not specify whether HTML is required or not. The protocol document will address mappings from the model to a protocol. But the unanswered question is what the protocol document will say about conformance, especially if it defines two bindings (to use Steve's term). Bob Herriot > From cmanros@cp10.es.xerox.com Thu Feb 27 16:23:44 1997 > > At 01:06 PM 2/27/97 PST, Robert Herriot wrote: > > > >> From rdebry@us.ibm.com Thu Feb 27 09:40:59 1997 > >> From: rdebry@us.ibm.com > >> > >> ... I'd suggest the following relative to the use of HTML > >> and IPP: > >> > >> A Web Browser must support HTML (pretty obvious) > >> > >> An IPP Client must support IPP, and may optionally support HTML > >> > >> An IPP Server must support IPP and may optionally support HTML. > >> > >> I don't think that we can say that an IPP Server MUST support HTML in > >> order to be IPP compliant. Actually sounds pretty silly to me to say that > >> HTML is required to be IPP compliant! I don't think that this is an > >> interoperability issue, is it? > >> > > > >Actually, we did say that an IPP server must support IPP AND HTML because > >if HTML is optional, then a client which expects HTML, must have a fallback. > >If clients must have a fallback to IPP, then no server need have HTML. > > > >I think the primary issue is whether a server gives exactly the same > >information and capabilities via IPP and HTML. > > > > I am starting to get really confused about this whole discussion. We have > decided that the model specification is to be made in a TRANSPORT > INDEPENDENT manner, and now people start suggesting that we should make IPP > dependent on HTML! > > I think we are on the wrong track here and need to back up to the point, > where people started assuming that we make HTML part of the package. > > My assumption up till now has been that certain functions in our overall > scenarios COULD be realized by using HTTP/HTML, but that such functions > would be OUTSIDE THE SCOPE of our three IPP standards document. I think > that bringing in HTML in this disciussion is starting to mix in too many > ideas about implementation into our model discussion, which we should not do. > > Carl-Uno > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - 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 > From ipp-archive Fri Feb 28 07:57:39 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA22488 for ipp-outgoing; Fri, 28 Feb 1997 07:55:38 -0500 (EST) X-Nvlenv-01Date-Transferred: 28-Feb-1997 08:02:58 -0500; at X-WB-AREA-HUB.XEROX X-Nvlenv-01Date-Transferred: 28-Feb-1997 7:56:05 -0500; at X-WB-NGM-MIME.XEROX X-Nvlenv-01Date-Posted: 28-Feb-1997 07:54:08 -0500; at X-WB-0311-MS3.XEROX Date: Fri, 28 Feb 1997 04:57:32 PST From: Peter_Zehler@wb.xerox.com (Zehler,Peter) To: IPP@pwg.org (IPP redirector) Subject: IPP> REQ Issues and directory cleanup Message-Id: <"E4AF163381E2667C@X-WB-0311-MS3.XEROX"@-SMF-> Sender: ipp-owner@pwg.org Precedence: first-class Status: RO All, I have uploaded the latest issues lists (open and closed). I still need someone to generate the pdf for me. I have cleaned up the directory a bit. If there are additional files in the directory that should be moved to historic could the poster(s) do that? If I moved something I should not have it is in historic and can be moved back up. Pete From ipp-archive Fri Feb 28 08:47:39 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA24663 for ipp-outgoing; Fri, 28 Feb 1997 08:45:37 -0500 (EST) From: rdebry@us.ibm.com To: Subject: Re: IPP>MOD - HTML and IPP streams Message-Id: <5030100000036268000002L082*@MHS> Date: Fri, 28 Feb 1997 08:44:07 -0500 Mime-Version: 1.0 Content-Type: text/plain; name="MEMO 02/27/97 18:00:19" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 Steve Zilles Wrote:-- After some thought, I would be happy if a server only had to implement the HTML binding, both for query and submission. If this is the case, I don't know why we bother to do a standard at all. Clearly, I can gin up whatever set of html pages (including forms java applets, etc) I want to and since I send them out to a browser there is no interoperability problems and the client is forced into whatever model I want to describe on the server side. Saying that it confomrs to IPP is rather uninteresting! From ipp-archive Fri Feb 28 09:32:39 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA26674 for ipp-outgoing; Fri, 28 Feb 1997 09:31:42 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 27 Feb 1997 11:04:24 -0700 From: "Scott A. Isaacson" To: ipp@pwg.org Subject: IPP> ADM - This is not and I-D wording Sender: ipp-owner@pwg.org Precedence: first-class Status: RO IPP Editors, In each of the documents that we are working on which eventually will become an I-D, we have a boilerplate section right up front that contains a set of paragraphs that must be contained word for word in the I-D. In order to solve the confusion between IPP posting a working document on the FTP server which we call an I-D and submitting a document to the IETF asking them to post an I-D, I propose that we put the following paragraph in the first section of our documents: This document is a working document of the Internet Printing Protocol (IPP) project in the Printer Working Group (PWG). It is subject to change at any time. The current version of this document can be found at http://www.pwg.org/ipp. This document is not yet an IETF Internet-Draft, however it is intended to become one. When it does, the following paragraphs will replace this paragraph. ************************************************************ 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: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Fri Feb 28 09:32:41 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA26672 for ipp-outgoing; Fri, 28 Feb 1997 09:31:43 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 27 Feb 1997 10:52:33 -0700 From: "Scott A. Isaacson" To: Robert.herriot@eng.sun.com, ipp@pwg.org, rdebry@us.ibm.com Subject: IPP>SEC -Reply Sender: ipp-owner@pwg.org Precedence: first-class Status: RO >>> 02/25/97 10:18am >>> 2) Access controlled: The Printer object has an associated Access Control List (ACL). Identification is required, but authentication (other than perhaps a password) is not. | Identification may flow with the IPP request or may be | included as part of the underlying transport. Data is most likely always sent in the clear. Again this is probably most suited for environments where Printers are not accessible from outside of an organization*,s firewall. However certain printers may be usable only by certain groups within an organization. This scheme also allows for accounting to be applied to printing based on user or group identity. >>> 02/25/97 10:18am >>> It looks like this clarifies the distinction that the "identity" of the client is either supplied by the application level protocol OR by the underlying connection services OR both and that this identity is just a suggestion of truth, there is no verification (validation). This identity usually comes from some authenticated name within the system, but once it crosses over into the print service, there is probably not more validation being done, and as Bob suggested, this could (relatively) easily be spoofed. Scott From ipp-archive Fri Feb 28 09:32:43 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA26698 for ipp-outgoing; Fri, 28 Feb 1997 09:31:59 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 27 Feb 1997 12:35:48 -0700 From: "Scott A. Isaacson" To: IPP@pwg.org, Peter_Zehler@wb.xerox.com Subject: IPP> MOD optional attributes for more info and driver installer -Reply Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I agree with most of your comments. Thanks for trying to take some vague, handwaving, out of scope issues and creating a simple compromising proposal. I still have some questions though: >>> Zehler,Peter 02/26/97 09:16am >>> > Driver installer obtained from URI in non-IPP fashion. Issue an > HTTP Get to the URI from the printer-driver-installer attribute to > get the appropriate driver. The Installer provider can provide service in > an implementation specific fashion. It may just default to some specific > installer(eg NT 5.0). A super-Installer could be downloaded. This > would be responsible for obtaining the parameters required to > install the > appropriate driver in the client environment. The third way a > provider may download the appropriate driver Installer is to look at > the product tokens in the HTTP Get request. The tokens > and their formats are not standard and vary from browser to browser. You suggest "issuing an HTTP Get" on the URI. This implies that the URI may only be an HTTP scheme URI. What about some other scheme? Should we force it to be an HTTP scheme URI? > Driver installer obtained from URI in IPP fashion. Issue an HTTP > Get to the URI from the printer-driver-installer attribute to get the > appropriate driver. Included in the Get will be IPP specific product > tags. The Installer will use IPP product tags in the HTTP Get request to > determine which installer to download to the client. This implies some sort of tags in HTML? Do we need to define the new tags? How is this different than the Super Installer from the section before? Isn't the this "IPP fashion" just the super installer? Scott From ipp-archive Fri Feb 28 09:32:45 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA26705 for ipp-outgoing; Fri, 28 Feb 1997 09:32:02 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 27 Feb 1997 11:31:18 -0700 From: "Scott A. Isaacson" To: ipp@pwg.org, rdebry@us.ibm.com Subject: IPP>MOD -Reply Sender: ipp-owner@pwg.org Precedence: first-class Status: RO >>> 02/25/97 03:03pm >>> > If we intend the protocol to support Printers which cannot spool jobs, > or which, have limited spool space, then I think we need an attribute > which expresses this fact so that a client can use the protocol > appropriately for that client. I've spent some time reviewing the > proposal I made at the San Jose meeting with our control unit > developers. While depending upon the underlying wire protocol > to handle the pacing of data works okay when there is infinite spool > space, we strongly believe that an application layer protocol, such as > that which I suggested, is required when the printer must print while > receiving data. We have implemented a very similar scheme for TCP/IP > IPDS printers and it works quite well. We discussed this at the Wednesday call. The discussion wound up being a requirements discussion. Which are the following requirements are part of IPP requirements: 1. Receive all errors and events over a separate channel from the job submission channel 2. Receive all errors and events over the job submission channel synchronously (in every response to every request there might be errors and events that have happened) 3. Receive all errors and events over the job submission channel asynchronously (some async packet comming back indepented of the job submission or query requests and responses) If you realize that IPP allows for events and errors to be reported via our simple notification attributes over some other channel using some other mechanism, here is a solution to your scenario from the telecon: A user submits a job and is in the process of transfering segments. The printer started printing the job since it had to (it doesn't spool) or it choose to (for some performance reason). There is a problem where the printer can't print any more (jam lets say). The buffers are filling up, and so the client can't send any more data until the jam is cleared. All the user knows is that it can't write any more. It doesn't know why, it just knows that it can't. The device could send an printer error out which is then routed to any interested party. The end user, if they were interested would receive the event (via the method defined then the supplied URL), or if it had not registered intereset it could always go poll using a Get Attributes operation on the printer. In either case, it sees the device is stopped because of a jam. Then the human can decide to either clear the jam physically which would allow for more segments to be sent, or the end user could just simply cancel the job since it is waiting for the transport to clear and probably stopping other printing from happening on the same channel. This solution seems to solve the problems generated in the scenario, by staying with requirements level 1 (not 2 or 3). Scott From ipp-archive Fri Feb 28 09:32:47 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA26737 for ipp-outgoing; Fri, 28 Feb 1997 09:32:29 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 27 Feb 1997 15:07:25 -0700 From: "Scott A. Isaacson" To: ipp@pwg.org Subject: IPP> MOD - Names of printer states Sender: ipp-owner@pwg.org Precedence: first-class Status: RO In the 1.4 version of the Model doc, we defined the following printer state values (type1Enum): unknown idle processing stopped Hows this for a state transition diagram +----------+ +-----------+ | | | | | | T2 | | | UNKN |<------>| IDLE | | | | | | | | | +----------+ +-----------+ ^ \ T3/ ^ | \ / | | \ / | | \/ |T6 |T1 /\ | | / \T4 | | / \ | v / \ v +----------+ +-----------+ | | | | | | T5 | | | PROC |<------>| STOP | | | | | | | | | +----------+ +-----------+ IDLE = Idle UNKN = Unknown PROC = Processing STOP = Stop T1: UNKN -> PROC A job was submitted even though the state was unkown. The state became known at the same moment it started processing the job OR the state became known and the printer is Processing. T1: PROC -> UNKN Something happened, it is just now unknown T2: UNKN -> IDLE The state became known and the printer is idle T2: IDLE -> UNKN Something happened, it is just now unknown T3: PROC -> IDLE Printer is now less busy than it used to be T3: IDLE -> PROC Printer is now more busy than it used to be T4: UNKN -> STOP The state became known and the printer is idle. T4: STOP -> UNKN Something happened, it is just now unknown T5: PROC -> STOP A critical error has occurred. There is new info in printer-state-reasons. The printer will probably return to the Processing state when errors are cleared. T5: STOP -> PROC All critical errors have been fixed, the printer is fairly busy T6: IDLE -> STOP A critical error has occurred. There is new info in printer-state-reasons. The printer will probably return to the Idle state when errors are cleared. T6: STOP -> IDLE All critical errors have been fixed, the printer is not too busy Also, in explaining the definintions of IDLE and PROC using the expected state of a jobs if they were to be submitted, people tend to say: You mean that Idle should be "Ready" and Processing should be "Busy". What do people think about these name changes, no semantic changes? 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: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Fri Feb 28 09:32:50 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA26699 for ipp-outgoing; Fri, 28 Feb 1997 09:31:58 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 27 Feb 1997 10:30:01 -0700 From: "Scott A. Isaacson" To: Keith_Carter@aussmtp.austin.ibm.com, ipp@pwg.org Subject: IPP> MOD - Comments on printer-state and printer-state-reasons -Reply Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Keith, You wrote: >>> 02/24/97 07:35am >>> 5. In my opinion, a Printer should inform an IPP application of "printer-state-reason" for each output device connected to the Printer. Here are 2 examples. Example 1. A Printer supports 3 network-attached printers NETPRT1-3 connected to a print server using network ports NETPORT1-3 respectively. NETPRT1 has a paper jam, NETPRT2 has run out of paper in its input tray and NETPRT3 is idle. "printer-state" is "mixed". "printer-state-reasons" are "NETPORT1:critical-jammed, NETPORT2:critical-input-tray-empty, NETPORT3:idle". With this approach, an IPP application that sees a "printer-state" of "mixed" can read the state of each output device. The application may: display the state of each device to the end-user (who may be the operator); display the most critical error(s) that require action; make a decision to submit a job if at least one of the devices is "idle" or "processing"; or display "printer-state-as-text" (i.e. rely on the Printer's summary of its printer state). Example 2. PRT, IPP1 and IPP2 represent URLs for Printers. A Printer, PRT, uses 2 Printers IPP1-2 as its output devices. IPP1 and IPP2 each support multiple output devices. One of the devices in IPP1 has a paper jam and the other device is idle. One of the devices in IPP2 is idle and ther other is processing jobs. For PRT, "printer-state" is "mixed". For PRT, "printer-state-reasons" are "IPP1:mixed, IPP2:idle/processing". An application may: display the state reasons from PRT for IPP1-2 (i.e. "mixed" and "processing/idle"); display "printer-state-as-text" from PRT; or issue a Get-Attributes operation on IPP1 and process the printer-state and printer-state-reasons as described in Example 1. >>> 02/24/97 07:35am >>> We had some disucussion about this in the Monday call after you left. We have decided to leave the syntax of this attribute as just STRING without defining the syntax within the string. We also decided to remove the state value "mixed" or "printing/idle". These just add complexity and confusion to the end user without real added value. However, since printer-state-reasons is just a string, then a given implementation could do as you are suggesting below, and show the state, etc of connected output devices. Since those output devices are not necessarily modeled as IPP printers, it is not guaranteed that their state values will be the same the the standard values for an IPP printer. You also write the following: >>> 02/24/97 07:35am >>> The current model for IPP 1.0 requires an end-user to either submit a Job to a Printer to receive notifications of printer state events or to poll a Printer for its state using the Get-Attributes or Get-Jobs operation. I am working on a proposed extension to the model so end-users can receive real time printer events without polling or submitting jobs to a Printer. A person with whom I must .... >>> 02/24/97 07:35am >>> We all realize the importance of an event delivery mechanism, but we have backed away from trying to define one an PART of IPP. I would be happy to review what you might propose, but I would be careful, as you have already suggested, that it is way beyond the scope of IPP 1.0 Scott From ipp-archive Fri Feb 28 10:42:42 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA00078 for ipp-outgoing; Fri, 28 Feb 1997 10:40:27 -0500 (EST) From: rdebry@us.ibm.com To: Subject: IPP>MOD Requirements for in channel vs out of channel Message-Id: <5030100000072013000002L032*@MHS> Date: Fri, 28 Feb 1997 10:38:56 -0500 Mime-Version: 1.0 Content-Type: text/plain; name="MEMO 02/28/97 10:42:00" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/28/97 08:20 AM --------------------------- Scott wote: We discussed this at the Wednesday call. The discussion wound up being a requirements discussion. Which are the following requirements are part of IPP requirements: 1. Receive all errors and events over a separate channel from the job submission channel 2. Receive all errors and events over the job submission channel synchronously (in every response to every request there might be errors and events that have happened) 3. Receive all errors and events over the job submission channel asynchronously (some async packet comming back indepented of the job submission or query requests and responses) If you realize that IPP allows for events and errors to be reported via our simple notification attributes over some other channel using some other mechanism, here is a solution to your scenario from the telecon: RKD> I would like to see us express requirements from an end-user's point RKD> of view, not from an implementation or architecture point of view, RKD> which the above appear to be to me. RKD> Are there any obvious differences in any of the above schemes as far RKD> as the end user is concerned? If not, then any of the above will work RKD> and we should pick the one that then best meets implementation and RKD> architecture needs. RKD> Here is one stab at the end-user requirement. Please feel free to RKD> suggest changes: RKD> When requesting an IPP operation, an end user always needs to see any RKD> conditions which affect the outcome of that operation in a reliable RKD> and timely fashion, and in a way which lets the end user modify or RKD> cancel the request as appropriate. From ipp-archive Fri Feb 28 10:47:42 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA00333 for ipp-outgoing; Fri, 28 Feb 1997 10:43:03 -0500 (EST) From: rdebry@us.ibm.com To: Subject: IPP> ADM - This is not and I-D wording Message-Id: <5030100000072185000002L052*@MHS> Date: Fri, 28 Feb 1997 10:41:28 -0500 Mime-Version: 1.0 Content-Type: text/plain; name="MEMO 02/28/97 10:44:18" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 Could we also get some common boilerplate describing the suite of documents available on IPP? ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/28/97 08:38 AM --------------------------- ipp-owner @ pwg.org 02/28/97 07:42 AM To: ipp @ pwg.org@internet cc: Subject: IPP> ADM - This is not and I-D wording IPP Editors, In each of the documents that we are working on which eventually will become an I-D, we have a boilerplate section right up front that contains a set of paragraphs that must be contained word for word in the I-D. In order to solve the confusion between IPP posting a working document on the FTP server which we call an I-D and submitting a document to the IETF asking them to post an I-D, I propose that we put the following paragraph in the first section of our documents: This document is a working document of the Internet Printing Protocol (IPP) project in the Printer Working Group (PWG). It is subject to change at any time. The current version of this document can be found at http://www.pwg.org/ipp. This document is not yet an IETF Internet-Draft, however it is intended to become one. When it does, the following paragraphs will replace this paragraph. ************************************************************ 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: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Fri Feb 28 10:57:40 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA00909 for ipp-outgoing; Fri, 28 Feb 1997 10:56:48 -0500 (EST) From: rdebry@us.ibm.com To: Subject: IPP>SEC - minutes of 2/27/97 conference call Message-Id: <5030100000073135000002L052*@MHS> Date: Fri, 28 Feb 1997 10:55:18 -0500 Mime-Version: 1.0 Content-Type: text/plain; name="MEMO 02/28/97 10:58:28" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 Minutes are posted as ftp://ftp.pwg.org/pub/pwg/ipp/new_SEC/min0327. It is a text file. From ipp-archive Fri Feb 28 11:27:42 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA01457 for ipp-outgoing; Fri, 28 Feb 1997 11:24:00 -0500 (EST) Mime-Version: 1.0 Date: Fri, 28 Feb 1997 11:28:02 -0500 Message-ID: <0000ACDD.1337@digprod.com> From: bwagner@digprod.com (Bill Wagner) Subject: Re[2]: IPP>MOD - HTML and IPP streams Cc: ipp@pwg.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I, and I expect others, seem to have missed a major step here. I would appreciate some clarification of the perceived relation between IPP and HTML. "Support" is perhaps too imprecise a term. 1. If, as Randy suggests, HTML is considered as a PDL to be delivered to the printer interpreter, then it needs no mention in IPP any more than any other PDL. 2. If, as Bob's message seems to suggest, HTML is a parallel implementation to IPP ( "the same information and capabilities via IPP and HTML"), some clarification of how this is to be done would be helpful. In addition, the need for two parallel capabilities is unclear. If IPP is browser oriented, and the browsers must 'support' HTML, and the desired capabilities can be provided with HTML (???), then why do IPP? 3. If, as Roger's message suggests, HTML is an optional facility that may be used by IPP to, perhaps, provide more elegant messages to the user, it would seem that a fallback already exists and that HTML support is optional. Again, I would appreciate a quick summary of the perceived relationship between IPP and HTML. Bill Wagner, Osicom/DPI ______________________________ Reply Separator _________________________________ Subject: Re: IPP>MOD - HTML and IPP streams Author: rturner@sharplabs.com at Internet Date: 2/27/97 1:54 PM Keep in mind how future implementers are going to read the statement "A Server must support HTML". We (and some future incarnation of an IPP WG) are basically going to end up with a core IPP standards-track RFC, with several other supporting documents, similar to: * RFC XXXX IPP Model, Syntax and Semantics (Core Protocol) * RFC XXXX IPP over HTTP 1.1 (1 particular mapping) * RFC XXXX IPP over HTTP 1.0 (another...) * RFC XXXX IPP over ONC (yet another....) * RFC XXXX IPP over DCE (ditto) * RFC XXXX IPP over (Other transports, etc.) * RFC XXXX IPP Security * RFC XXXX IPP Commercial Transaction Extensions . . . Etc. IMHO, I think the core document should not mandate a particular mapping or HTML, an IPP implementation MUST be compliant with * The core document AND * One or more mapping documents And that should be about it. The way I see it, HTML is just another PDL, and is handled by some interpreter module that is outside the scope of IPP. The only thing that IPP includes that comes from the HTML world is the requirement that URLs/URNs/URIs must be generated and understood by clients and servers. Just my 0.02 worth Randy Robert Herriot wrote: > > > From rdebry@us.ibm.com Thu Feb 27 09:40:59 1997 > > From: rdebry@us.ibm.com > > > > ... I'd suggest the following relative to the use of HTML > > and IPP: > > > > A Web Browser must support HTML (pretty obvious) > > > > An IPP Client must support IPP, and may optionally support HTML > > > > An IPP Server must support IPP and may optionally support HTML. > > > > I don't think that we can say that an IPP Server MUST support HTML in > > order to be IPP compliant. Actually sounds pretty silly to me to say that > > HTML is required to be IPP compliant! I don't think that this is an > > interoperability issue, is it? > > > > Actually, we did say that an IPP server must support IPP AND HTML because > if HTML is optional, then a client which expects HTML, must have a fallback. > If clients must have a fallback to IPP, then no server need have HTML. > > I think the primary issue is whether a server gives exactly the same > information and capabilities via IPP and HTML. -- Randy Turner Network Architect Sharp Laboratories of America rturner@sharplabs.com From ipp-archive Fri Feb 28 12:27:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA02320 for ipp-outgoing; Fri, 28 Feb 1997 12:25:15 -0500 (EST) X-Nvlenv-01Date-Transferred: 28-Feb-1997 12:33:23 -0500; at X-WB-AREA-HUB.XEROX X-Nvlenv-01Date-Transferred: 28-Feb-1997 12:26:33 -0500; at X-WB-NGM-MIME.XEROX X-Nvlenv-01Date-Posted: 28-Feb-1997 12:24:34 -0500; at X-WB-0311-MS3.XEROX Date: Fri, 28 Feb 1997 09:27:53 PST From: Peter_Zehler@wb.xerox.com (Zehler,Peter) To: IPP@pwg.org (IPP redirector), Scott_Isaacson@novell.com Subject: RE: IPP> MOD optional attributes for more info and driver, inst Message-Id: <"<7212173381E2667C>7212173381E2667C@X-WB-0311-MS3.XEROX"@-SMF-> Sender: ipp-owner@pwg.org Precedence: first-class Status: RO All, Scott responded to the "Example of multiple levels of driver installation service using IPP and HTTP" section of my mailnote Scott wrote: >You suggest "issuing an HTTP Get" on the URI. This implies that the URI >may only be an HTTP scheme URI. What about some other scheme? >Should we force it to be an HTTP scheme URI? I took HTTP as an example. FTP could also be a valid scheme. I selected HTTP as an example because its transfer response is immediate. HTTP has the capability of informing the server of the client environment built in. I don't think we should force driver installation services to be an HTTP scheme. I want to see how the prototypes handle it and evaluate the solutions at that time. Scott also question the following section in my mailnote: PZ> Driver installer obtained from URI in IPP fashion. Issue an HTTP PZ> Get to the URI from the printer-driver-installer attribute to get the PZ> appropriate driver. Included in the Get will be IPP specific product PZ> tags. The Installer will use IPP product tags in the HTTP Get request to PZ> determine which installer to download to the client. Scott wrote: >This implies some sort of tags in HTML? Do we need to define the new >tags? How is this different than the Super Installer from the section >before? Isn't the this "IPP fashion" just the super installer? I am implying that when IPP takes up driver installation one solution would be to define IPP specific tag(s) to enable the retrieval the correct variant of a driver installer. There are other solutions. In my example I needed IPP specific tags to convey variant selection criteria unambiguously. The difference between this case and the superinstaller case is how the client environment is determined. The superinstaller executes on the client machine. This could be accomplished using Java. The superinstaller determines the client environment locally and installs the driver in a platform specific manner. In my HTTP Get example the client send its environment information in the request and the installation service uses the tags to return the correct variant. From ipp-archive Fri Feb 28 12:27:48 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA02290 for ipp-outgoing; Fri, 28 Feb 1997 12:24:00 -0500 (EST) From: rdebry@us.ibm.com To: Subject: Re[2]: IPP>MOD - HTML and IPP streams Message-Id: <5030100000079262000002L022*@MHS> Date: Fri, 28 Feb 1997 12:22:25 -0500 Mime-Version: 1.0 Content-Type: text/plain; name="MEMO 02/28/97 12:25:39" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 I doubt that we have consensus here. Personally, I think the use of HTML as optional support is quite a nice approach to providing information not in IPP or to provide it in a more elegant or manufacturer-unique way. The use of HTML templates in the Microsoft implementation is a nice example of allowing the printer manufacturer to adorn their responses with a logo or whatever they use to add unique value. Another example would be the Kinko's case where I could use standard HTML to put up a slick intro-page, advertise the day's specials, negotiate complex printing costs (print 50-100 copies for $xx.xx), etc., but then use standard IPP to actually communicate the print job. In both of these cases, I think that we ought to view HTML as an optional support in a printing system, and not a mandatory server capability!!! It's certainly not part of IPP in my mind. ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/28/97 10:12 AM --------------------------- ipp-owner @ pwg.org 02/28/97 09:25 AM To: cc: ipp @ pwg.org@internet Subject: Re[2]: IPP>MOD - HTML and IPP streams I, and I expect others, seem to have missed a major step here. I would appreciate some clarification of the perceived relation between IPP and HTML. "Support" is perhaps too imprecise a term. 1. If, as Randy suggests, HTML is considered as a PDL to be delivered to the printer interpreter, then it needs no mention in IPP any more than any other PDL. 2. If, as Bob's message seems to suggest, HTML is a parallel implementation to IPP ( "the same information and capabilities via IPP and HTML"), some clarification of how this is to be done would be helpful. In addition, the need for two parallel capabilities is unclear. If IPP is browser oriented, and the browsers must 'support' HTML, and the desired capabilities can be provided with HTML (???), then why do IPP? 3. If, as Roger's message suggests, HTML is an optional facility that may be used by IPP to, perhaps, provide more elegant messages to the user, it would seem that a fallback already exists and that HTML support is optional. Again, I would appreciate a quick summary of the perceived relationship between IPP and HTML. Bill Wagner, Osicom/DPI ______________________________ Reply Separator _________________________________ Subject: Re: IPP>MOD - HTML and IPP streams Author: rturner@sharplabs.com at Internet Date: 2/27/97 1:54 PM Keep in mind how future implementers are going to read the statement "A Server must support HTML". We (and some future incarnation of an IPP WG) are basically going to end up with a core IPP standards-track RFC, with several other supporting documents, similar to: * RFC XXXX IPP Model, Syntax and Semantics (Core Protocol) * RFC XXXX IPP over HTTP 1.1 (1 particular mapping) * RFC XXXX IPP over HTTP 1.0 (another...) * RFC XXXX IPP over ONC (yet another....) * RFC XXXX IPP over DCE (ditto) * RFC XXXX IPP over (Other transports, etc.) * RFC XXXX IPP Security * RFC XXXX IPP Commercial Transaction Extensions . . . Etc. IMHO, I think the core document should not mandate a particular mapping or HTML, an IPP implementation MUST be compliant with * The core document AND * One or more mapping documents And that should be about it. The way I see it, HTML is just another PDL, and is handled by some interpreter module that is outside the scope of IPP. The only thing that IPP includes that comes from the HTML world is the requirement that URLs/URNs/URIs must be generated and understood by clients and servers. Just my 0.02 worth Randy Robert Herriot wrote: > > > From rdebry@us.ibm.com Thu Feb 27 09:40:59 1997 > > From: rdebry@us.ibm.com > > > > ... I'd suggest the following relative to the use of HTML > > and IPP: > > > > A Web Browser must support HTML (pretty obvious) > > > > An IPP Client must support IPP, and may optionally support HTML > > > > An IPP Server must support IPP and may optionally support HTML. > > > > I don't think that we can say that an IPP Server MUST support HTML in > > order to be IPP compliant. Actually sounds pretty silly to me to say that > > HTML is required to be IPP compliant! I don't think that this is an > > interoperability issue, is it? > > > > Actually, we did say that an IPP server must support IPP AND HTML because > if HTML is optional, then a client which expects HTML, must have a fallback. > If clients must have a fallback to IPP, then no server need have HTML. > > I think the primary issue is whether a server gives exactly the same > information and capabilities via IPP and HTML. -- Randy Turner Network Architect Sharp Laboratories of America rturner@sharplabs.com From ipp-archive Fri Feb 28 12:42:45 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA03277 for ipp-outgoing; Fri, 28 Feb 1997 12:39:40 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 28 Feb 1997 10:36:59 -0700 From: "Scott A. Isaacson" To: ipp@pwg.org, rdebry@us.ibm.com Subject: IPP>PRO - segments and synchronous responses -Reply Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Roger wrote: >>> 02/27/97 12:20pm >>> > o The user might turn notification off > o The user might not "see" the notification, i.e. only looks at his email > once a day. > o The client will not see the notification, since it goes directly to the > user. > o The Printer has no choice but to wait until the condition is fixed, then > continue to receive data > o The client has no choice but to wait until the Printer begins receiving > data again. It could detect that no data is flowing and warn the user, > but it does not know why data is not flowing. Yes, but sometimes this is what the end user wants is to turn this stuff off. In the Novell environment, we find that people turn off notification very frequently. > This may be a dumb analogy, but consider the situation where I call my > friend on the phone. As we talk, he smells smoke and discovers that > his > house is on fire. He says "wait a minute", and without saying anything > more > he goes away, leaving me on the phone waiting for him to say "go > ahead". > He then writes a letter (a separate channel) telling me his house is on > fire, > then proceeds to try to put it out. Seems pretty silly when compared to > just > saying "wait a minute, my house is on fire". Not a dumb analogy, just one that is not applicable. A voice telephone connection is a free flowing, abstract, not specific, bi-directional channel where there is no clear client or server. You do not have to say something to get something back. What if it was a request response channel like HTTP and your friend wanted to say his house was on fire but you had nothing to tell him -- The line is silent, he can't say anything because you are quiet and he can only respond to what you say. On the real phone line, he can say "Hey, be quiet I have something important to say" while you are talking. We do not have such a connection and it would be a major change in requirement to have such (set up twp TCP connections). Scott From ipp-archive Fri Feb 28 14:37:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA04187 for ipp-outgoing; Fri, 28 Feb 1997 14:34:46 -0500 (EST) From: rdebry@us.ibm.com To: Subject: IPP>MOD - Suggestions for new introduction Message-Id: <5030100000087758000002L082*@MHS> Date: Fri, 28 Feb 1997 14:33:15 -0500 Mime-Version: 1.0 Content-Type: text/plain; name="MEMO 02/28/97 14:36:18" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 I've posted a suggested new introduction to the Model Document in ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/newintro.txt This is based on the system diagram that's been discussed here for the past few days. The objective of this intro is to put IPP into context with the rest of the components required to implement a printing system, e.g. Security, Directory, Transport, etc. I'd appreciate any comments. From ipp-archive Fri Feb 28 14:47:45 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA04528 for ipp-outgoing; Fri, 28 Feb 1997 14:45:26 -0500 (EST) Message-Id: <3.0.1.32.19970228113257.018a3fa8@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 28 Feb 1997 11:32:57 PST To: masinter@parc.xerox.com From: Carl-Uno Manros Subject: IPP> SEC - Protocol names for security protocols Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Larry, we have had a discussion in the IPP security sbgroup, which has resulted in a question for you. We need some way of signalling whether a particular printer optionally supports or even enforces the use of a secure protocol in combination with IPP. Examples that we are looking at include RFC 2069 security and the various versions of SSL. I believe that if SSL is used in combination with HTTP it is currently identified with "SHTTP" in the URL rather than just "HTTP". Is this correct? If we could assume that all security protocols used with HTTP would carry their own protocol names, it would make life a lot simpler for us. As we are planning to identify printers with a URL address, we would then give a printer that can handle both secure and non-secure print requests two URL names, one with "HTTP://..." and one with "SHTTP://...." and the IPP client can then invoke operations on one or the other. A printer that only supports secure printing, would obviously only have an "SHTTP://..." address. So I am back to our question: Can we assume that secure versions of HTTP will always have separate names, eg. what is planned for RFC 2069? Our assumption is that once you are in the secure protocol, you can then negotiate which security features within that protocol you want to use. You may want to forward this note to the HTTP list, in case you do not have an easy answer. Thankful for your feedback, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Fri Feb 28 15:22:49 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA04937 for ipp-outgoing; Fri, 28 Feb 1997 15:19:34 -0500 (EST) Message-ID: <33173AD7.65D7@sharplabs.com> Date: Fri, 28 Feb 1997 12:06:47 -0800 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: "Zehler,Peter" CC: IPP redirector , Scott_Isaacson@novell.com Subject: Re: IPP> MOD optional attributes for more info and driver, inst References: <"<7212173381E2667C>7212173381E2667C@X-WB-0311-MS3.XEROX"@-SMF-> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I wouldn't go any further with standardizing driver installation than the following paragraph: "The directory entry for printers will contain one or more URLs that contain locations for drivers for one or more different platforms or operating environments". What protocol you use to obtain the driver will depend upon the URL "protocol" field (HTTP:, FTP:, etc.). The URL should provide enough context information for an unambiguous retrieval of the driver. To talk about "Well, you issue an HTTP GET request..." I think goes into more detail than we need to specify in order to obtain an IPP driver for a particular device. Randy -- Randy Turner Network Architect Sharp Laboratories of America rturner@sharplabs.com From ipp-archive Fri Feb 28 15:57:45 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA05398 for ipp-outgoing; Fri, 28 Feb 1997 15:53:00 -0500 (EST) From: rdebry@us.ibm.com To: Subject: IPP>MOD - Names of printer states Message-Id: <5030100000093077000002L072*@MHS> Date: Fri, 28 Feb 1997 15:51:27 -0500 Mime-Version: 1.0 Content-Type: text/plain; name="MEMO 02/28/97 15:54:38" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 Scott, it appears that there is no difference between transition T2 and T4 in your diagram, is this correct? From ipp-archive Fri Feb 28 16:07:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA05734 for ipp-outgoing; Fri, 28 Feb 1997 16:05:29 -0500 (EST) Message-Id: <3.0.1.32.19970228130509.018a3fa8@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 28 Feb 1997 13:05:09 PST To: rdebry@vnet.ibm.com From: Carl-Uno Manros Subject: Re: IPP>MOD - Suggestions for new introduction Cc: ipp@pwg.org In-Reply-To: <5030100000087758000002L082*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO At 11:33 AM 2/28/97 PST, you wrote: >Classification: >Prologue: >Epilogue: Roger K deBry >Senior Techncial Staff Member >Architecture and Technology >IBM Printing Systems >email: rdebry@us.ibm.com >phone: 1-303-924-4080 > >I've posted a suggested new introduction to the Model Document in >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/newintro.txt > Roger, thanks for doing this. It certainly helps us quite a bit further. I have a few comments: 1) When you talk about users, you limit it to human users and assume human interfaces. Obviously an application could use IPP directly without human intervention. I think this should be called out somewhere. 2) In the picture, you have the Brower connected directly to Transport. My suggestion is that it is connected to the IPP Client (I suppose this is one of the points on which we not yet have agreement). 3) On Notification Service you state that we assume that this exists. My assumption is that you could have an implementation that does not support this. You could have an IPP Client regularly pull the IPP Server for status information instead (not so elegant, but possible - many implementations use this now). 4) You also claim that a Directory Service is assumed. You could advertise your Printers on Web pages as an alternative to listing them in a directory, hence this is also not a service that has to be present. 5) The relationship between an IPP Server and a Printing Service is not very clear in the text. I assume that the IPP Server is a component of the Printing Service. We need to say that. Again thanks, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Fri Feb 28 16:27:45 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA06091 for ipp-outgoing; Fri, 28 Feb 1997 16:25:36 -0500 (EST) From: Keith_Carter@aussmtp.austin.ibm.com X-Lotus-FromDomain: AUSNOTES To: ipp@pwg.org Message-ID: <8625644C:006F7938.00@aussmtp3.austin.ibm.com> Date: Fri, 28 Feb 1997 15:12:13 -0500 Subject: IPP> MOD - COMMENTS ON PRINTER-STATE AND PRINTER-STATE-REASONS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Scott, Thanks for your response. My response noted as KC>> below. Keith Date: Thu, 27 Feb 1997 10:30:01 -0700 From: "Scott A. Isaacson" To: Keith_Carter@aussmtp.austin.ibm.com, ipp@pwg.org Keith, You wrote: >>> 02/24/97 07:35am >>> 5. In my opinion, a Printer should inform an IPP application of "printer-state-reason" for each output device connected to the Printer. Here are 2 examples. Example 1. A Printer supports 3 network-attached printers NETPRT1-3 connected to a print server using network ports NETPORT1-3 respectively. NETPRT1 has a paper jam, NETPRT2 has run out of paper in its input tray and NETPRT3 is idle. "printer-state" is "mixed". "printer-state-reasons" are "NETPORT1:critical-jammed, NETPORT2:critical-input-tray-empty, NETPORT3:idle". With this approach, an IPP application that sees a "printer-state" of "mixed" can read the state of each output device. The application may: display the state of each device to the end-user (who may be the operator); display the most critical error(s) that require action; make a decision to submit a job if at least one of the devices is "idle" or "processing"; or display "printer-state-as-text" (i.e. rely on the Printer's summary of its printer state). Example 2. PRT, IPP1 and IPP2 represent URLs for Printers. A Printer, PRT, uses 2 Printers IPP1-2 as its output devices. IPP1 and IPP2 each support multiple output devices. One of the devices in IPP1 has a paper jam and the other device is idle. One of the devices in IPP2 is idle and ther other is processing jobs. For PRT, "printer-state" is "mixed". For PRT, "printer-state-reasons" are "IPP1:mixed, IPP2:idle/processing". An application may: display the state reasons from PRT for IPP1-2 (i.e. "mixed" and "processing/idle"); display "printer-state-as-text" from PRT; or issue a Get-Attributes operation on IPP1 and process the printer-state and printer-state-reasons as described in Example 1. >>> 02/24/97 07:35am >>> We had some disucussion about this in the Monday call after you left. We have decided to leave the syntax of this attribute as just STRING without defining the syntax within the string. We also decided to remove the state value "mixed" or "printing/idle". These just add complexity and confusion to the end user without real added value. However, since printer-state-reasons is just a string, then a given implementation could do as you are suggesting below, and show the state, etc of connected output devices. Since those output devices are not necessarily modeled as IPP printers, it is not guaranteed that their state values will be the same the the standard values for an IPP printer. KC>> Ok. You also write the following: >>> 02/24/97 07:35am >>> The current model for IPP 1.0 requires an end-user to either submit a Job to a Printer to receive notifications of printer state events or to poll a Printer for its state using the Get-Attributes or Get-Jobs operation. I am working on a proposed extension to the model so end-users can receive real time printer events without polling or submitting jobs to a Printer. A person with whom I must .... >>> 02/24/97 07:35am >>> We all realize the importance of an event delivery mechanism, but we have backed away from trying to define one an PART of IPP. I would be happy to review what you might propose, but I would be careful, as you have already suggested, that it is way beyond the scope of IPP 1.0 KC>> After thinking about how to do this, I agree that we should KC>> postpone this capability until after IPP 1.0. Scott >>>> DO NOT REPLY TO THIS NOTE <<<< From ipp-archive Fri Feb 28 16:42:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA06458 for ipp-outgoing; Fri, 28 Feb 1997 16:39:12 -0500 (EST) X-Nvlenv-01Date-Transferred: 28-Feb-1997 16:23:37 -0500; at X-WB-AREA-HUB.XEROX X-Nvlenv-01Date-Transferred: 28-Feb-1997 16:35:38 -0500; at X-WB-NGM-MIME.XEROX X-Nvlenv-01Date-Posted: 28-Feb-1997 16:14:42 -0500; at X-WB-0311-MS3.XEROX Date: Fri, 28 Feb 1997 13:18:06 PST From: Peter_Zehler@wb.xerox.com (Zehler,Peter) To: IPP@pwg.org (IPP redirector) Subject: Re: IPP> MOD optional attributes for more info and driver,, ins Message-Id: <"EA46173381E2667C@X-WB-0311-MS3.XEROX"@-SMF-> Sender: ipp-owner@pwg.org Precedence: first-class Status: RO All, Randy wrote: >I wouldn't go any further with standardizing driver installation >than the following paragraph: >"The directory entry for printers will contain one or more URLs >that contain locations for drivers for one or more different >platforms or operating environments". >What protocol you use to obtain the driver will depend upon the >URL "protocol" field (HTTP:, FTP:, etc.). The URL should provide >enough context information for an unambiguous retrieval of the >driver. To talk about "Well, you issue an HTTP GET request..." >I think goes into more detail than we need to specify in order >to obtain an IPP driver for a particular device. All I am looking for is 2 IPP attributes. One URL for end user interactions to obtain additional information(i.e. printer-more-info.) The second for programmatic access to the location of the printer's driver installer(i.e. printer-driver-installer.) The important differentiation here is one attribute is target at the end user and is very general. The other attribute is for programmatic access and is specific to driver installation. Neither of these attributes would be mandatory. Pete From ipp-archive Fri Feb 28 17:57:49 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA06975 for ipp-outgoing; Fri, 28 Feb 1997 17:53:32 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 28 Feb 1997 15:33:01 -0700 From: Scott Isaacson To: bwagner@digprod.com Cc: ipp@pwg.org Subject: Re[2]: IPP>MOD - HTML and IPP streams -Reply Sender: ipp-owner@pwg.org Precedence: first-class Status: RO One of the "major" steps missed was the discussion from the Wednesday telecon. We discussed the difference between: 1. A network print provider wriitten to this new IPP protocol which is submitting a job and which desires to get queries and status back using some well formed protocol like IPP (not arbitrary HTML) and 2. A Web Browser using a Job URL to query and get an HTML document back showing status or results of queries. The question was, do we have to pick on or the other for the IPP protocol? The discussion in the telecon seemed to indicate that we could use BOTH. Since there is a huge amount of input suggesting the need for some well formed protocol (not HTML), we know that we have to do that at least. The question remains is how to do the HTML response as well? I don't think anyone is suggesting at this point (at least I have not heard it outloud) that we should do job canceling via an HTML form that is filled out and submitted. So in my view, HTML only comes into play when a standard off the shelf today browser (no new IPP stuff) is being used for job and printer status and queries. No submission or cancel. This is not to be confused with the fact that HTML could be a PDL that is sent to a printer using IPP as a job submission protocol. The job just happens to be HTML rather than text or some PDL like PostScript. Scott >>> Bill Wagner 02/28/97 09:28am >>> I, and I expect others, seem to have missed a major step here. I would appreciate some clarification of the perceived relation between IPP and HTML. "Support" is perhaps too imprecise a term. 1. If, as Randy suggests, HTML is considered as a PDL to be delivered to the printer interpreter, then it needs no mention in IPP any more than any other PDL. 2. If, as Bob's message seems to suggest, HTML is a parallel implementation to IPP ( "the same information and capabilities via IPP and HTML"), some clarification of how this is to be done would be helpful. In addition, the need for two parallel capabilities is unclear. If IPP is browser oriented, and the browsers must 'support' HTML, and the desired capabilities can be provided with HTML (???), then why do IPP? 3. If, as Roger's message suggests, HTML is an optional facility that may be used by IPP to, perhaps, provide more elegant messages to the user, it would seem that a fallback already exists and that HTML support is optional. Again, I would appreciate a quick summary of the perceived relationship between IPP and HTML. Bill Wagner, Osicom/DPI ______________________________ Reply Separator _________________________________ Subject: Re: IPP>MOD - HTML and IPP streams Author: rturner@sharplabs.com at Internet Date: 2/27/97 1:54 PM Keep in mind how future implementers are going to read the statement "A Server must support HTML". We (and some future incarnation of an IPP WG) are basically going to end up with a core IPP standards-track RFC, with several other supporting documents, similar to: * RFC XXXX IPP Model, Syntax and Semantics (Core Protocol) * RFC XXXX IPP over HTTP 1.1 (1 particular mapping) * RFC XXXX IPP over HTTP 1.0 (another...) * RFC XXXX IPP over ONC (yet another....) * RFC XXXX IPP over DCE (ditto) * RFC XXXX IPP over (Other transports, etc.) * RFC XXXX IPP Security * RFC XXXX IPP Commercial Transaction Extensions . . . Etc. IMHO, I think the core document should not mandate a particular mapping or HTML, an IPP implementation MUST be compliant with * The core document AND * One or more mapping documents And that should be about it. The way I see it, HTML is just another PDL, and is handled by some interpreter module that is outside the scope of IPP. The only thing that IPP includes that comes from the HTML world is the requirement that URLs/URNs/URIs must be generated and understood by clients and servers. Just my 0.02 worth Randy Robert Herriot wrote: > > > From rdebry@us.ibm.com Thu Feb 27 09:40:59 1997 > > From: rdebry@us.ibm.com > > > > ... I'd suggest the following relative to the use of HTML > > and IPP: > > > > A Web Browser must support HTML (pretty obvious) > > > > An IPP Client must support IPP, and may optionally support HTML > > > > An IPP Server must support IPP and may optionally support HTML. > > > > I don't think that we can say that an IPP Server MUST support HTML in > > order to be IPP compliant. Actually sounds pretty silly to me to say that > > HTML is required to be IPP compliant! I don't think that this is an > > interoperability issue, is it? > > > > Actually, we did say that an IPP server must support IPP AND HTML because > if HTML is optional, then a client which expects HTML, must have a fallback. > If clients must have a fallback to IPP, then no server need have HTML. > > I think the primary issue is whether a server gives exactly the same > information and capabilities via IPP and HTML. -- Randy Turner Network Architect Sharp Laboratories of America rturner@sharplabs.com From ipp-archive Fri Feb 28 18:17:49 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA07429 for ipp-outgoing; Fri, 28 Feb 1997 18:14:48 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 28 Feb 1997 16:14:29 -0700 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> ADM - 2/26 telecon notes (partial) Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I volunteered to take notes during the last 1/2 hour of the telecon. Here they are: 1. Discussion on the need for an attribute that reveals if the Printer is a spooling Printer or not. Is there a need for more than just TCP/IP flow control? Do we need a bidirectional channel? Can all of the status info be sent back in the responses (synchronously)? Since all LARGE jobs will have to be split up by the application segmenting, we know that we will have to do some sort of segmenting. The term chunking should not be used for segmenting since it overlaps with MIME chunking. 2. If we choose to make a mapping of IPP model semantics over HTTP we will haver several documents - one for mapping over HTTP/1.0 and one for mapping over HTTP/1.1 3. Should Job State Reasons include any printer state reasons? Also, in 1.4 we said that all Printer Status attributes were returned in the Job Submit response. We also stated that the semantics were based on the Printer status just befor the job "is submitted". However, we need to rethink this. If we put printer state reasons in the Job status attributes and we return Job Status attributes rather than Printer Status Attributes, then we solve the problem presented in the scenarios. ************************************************************ 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: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Fri Feb 28 18:17:50 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA07648 for ipp-outgoing; Fri, 28 Feb 1997 18:17:40 -0500 (EST) From: rdebry@us.ibm.com To: Subject: Re: IPP>MOD - Suggestions for new introduction Message-Id: <5030100000102358000002L082*@MHS> Date: Fri, 28 Feb 1997 18:16:03 -0500 Mime-Version: 1.0 Content-Type: text/plain; name="MEMO 02/28/97 18:19:08" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 My responses follow: ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/28/97 04:07 PM --------------------------- ipp-owner @ pwg.org 02/28/97 02:06 PM To: rdebry @ vnet.ibm.com@internet cc: ipp @ pwg.org@internet Subject: Re: IPP>MOD - Suggestions for new introduction At 11:33 AM 2/28/97 PST, you wrote: >Classification: >Prologue: >Epilogue: Roger K deBry >Senior Techncial Staff Member >Architecture and Technology >IBM Printing Systems >email: rdebry@us.ibm.com >phone: 1-303-924-4080 > >I've posted a suggested new introduction to the Model Document in >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/newintro.txt > Roger, thanks for doing this. It certainly helps us quite a bit further. I have a few comments: 1) When you talk about users, you limit it to human users and assume human interfaces. Obviously an application could use IPP directly without human intervention. I think this should be called out somewhere. RKD> Applications are shown using IPP directly, however perhaps the optional RKD> printer driver and spooler confuses this. The text also suggests that RKD> applications can use IPP directly. 2) In the picture, you have the Brower connected directly to Transport. My suggestion is that it is connected to the IPP Client (I suppose this is one of the points on which we not yet have agreement). RKD> No, I don't think that the browser is ever connected to an IPP RKD> client. It may access the server, however. 3) On Notification Service you state that we assume that this exists. My assumption is that you could have an implementation that does not support this. You could have an IPP Client regularly pull the IPP Server for status information instead (not so elegant, but possible - many implementations use this now). RKD> I'd certainly be willing to make it an optional component if RKD> everyone else agrees. 4) You also claim that a Directory Service is assumed. You could advertise your Printers on Web pages as an alternative to listing them in a directory, hence this is also not a service that has to be present. RKD> I intended that this be an optional component. I'll reword if this RKD> is not clear. 5) The relationship between an IPP Server and a Printing Service is not very clear in the text. I assume that the IPP Server is a component of the Printing Service. We need to say that. RKD> I tried to suggest that the IPP server and the Printing Service were RKD> both components of an IPP Printer, where printing service referes to RKD> spooling, scheduling, kinds of function. Again thanks, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - 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 From ipp-archive Fri Feb 28 18:22:50 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA08049 for ipp-outgoing; Fri, 28 Feb 1997 18:21:42 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 28 Feb 1997 16:21:13 -0700 From: Scott Isaacson To: ipp@pwg.org, rdebry@us.ibm.com Subject: IPP>MOD - HTML and IPP streams -Reply Sender: ipp-owner@pwg.org Precedence: first-class Status: RO >>> 02/27/97 10:38am >>> > A Web Browser must support HTML (pretty obvious) > An IPP Client must support IPP, and may optionally support HTML > An IPP Server must support IPP and may optionally support HTML. > > I don't think that we can say that an IPP Server MUST support HTML in > order to be IPP compliant. Actually sounds pretty silly to me to say that > HTML is required to be IPP compliant! I don't think that this is an > interoperability issue, is it? I don't understand this. If a Browser supports HTML (and not IPP) and a server does not support supplying HTML, how does the browser get this HTML that it supports but nobody generates? Or do you mean that since the server supports HTML generation (optionally) then if it does not support generating HTML, then Web Browsers just don't get HTML. Scott From ipp-archive Fri Feb 28 18:32:48 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA08505 for ipp-outgoing; Fri, 28 Feb 1997 18:30:03 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 28 Feb 1997 16:29:47 -0700 From: Scott Isaacson To: don@lexmark.com, ipp@pwg.org, rdebry@us.ibm.com Sender: ipp-owner@pwg.org Precedence: first-class Status: RO >>> 02/27/97 11:43am >>> > Don, I gave the requirements document a quick read. The major > comment I have is that the way the document is currently written, > it would appear that the only required client interface is a Web > Browser. While I would agree that using a Web Browser is an > important requirement, the document should not lead one to > believe that it is the only requirement! Since the first paragraph > in the Terminology section discusses the use of Worl Wide Web > tools, and Browsers are explicitly dicsussed in the second paragraph, > there is no need to explicitly call out Browsers (and not mention other > kinds of clients) in each of the remaining sections. Great comments, I agree with them all. Since I agree with them and I expect others to do so as well, I am assuming that we are generally agreeing with the following assumptions: 1. Browsers are not now and will not be (in the relatively near future) but the entire desktop operating system of client nodes on the Internet (maybe some day, just not now for IPP) 2. Some "changes" will have to be made to today's browsers if IPP is mapped to some transport and endcoding that is not just HTTP and HTML forms if Browsers want to submit jobs directly using IPP (not just through an IPP print provider for all apps on the desktop). Scott From ipp-archive Fri Feb 28 18:37:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA08826 for ipp-outgoing; Fri, 28 Feb 1997 18:37:36 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 28 Feb 1997 16:37:45 -0700 From: Scott Isaacson To: Robert.Herriot@Eng.Sun.COM, ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP>MOD - HTML and IPP streams -Reply Sender: ipp-owner@pwg.org Precedence: first-class Status: RO >>> Robert Herriot 02/27/97 02:06pm >>> > Actually, we did say that an IPP server must support IPP AND HTML > because if HTML is optional, then a client which expects HTML, must > have a fallback. If clients must have a fallback to IPP, then no server > need have HTML. What about current browsers that have not been written to IPP but have been written to use HTML? We leave them out in the cold? > I think the primary issue is whether a server gives exactly the same > information and capabilities via IPP and HTML. The semantic mapping for IPP over HTTP will not include any presentation information. The semantic mapping for IPP over HTML must not as well. So IPP over HTML will just be abstract attributes and values. There will be an infinite number of ways to realize this in HTML. I see IPP over HTML as just another way to do just a Get Attributes operation (and maybe a Get Jobs) operation. Not a Print or a Cancel. The resulting HTML file will not be parsable by a program, but should be displayable by a browser and understandable to an end user. Scott From ipp-archive Fri Feb 28 18:42:48 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA09139 for ipp-outgoing; Fri, 28 Feb 1997 18:42:15 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 28 Feb 1997 16:42:16 -0700 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - 3/3 Telecon Sender: ipp-owner@pwg.org Precedence: first-class Status: RO We will have a Model group teleconference on Monday 3/3. Sorry for the confusion. Some thought it would be today, Friday 2/28. At the Wednesday call, I thought we agreed to do it on Monday. Maybe I promised something and forgot. Confirmation number: 317675 Call in Toll-Free number: 800-753-0487 Monday, 3/3/97 11:00 AM - 1:00 PM Mountain Time 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: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Fri Feb 28 18:57:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA09492 for ipp-outgoing; Fri, 28 Feb 1997 18:56:32 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 28 Feb 1997 16:56:39 -0700 From: Scott Isaacson To: ipp@pwg.org, rdebry@us.ibm.com Subject: IPP>MOD - Names of printer states -Reply Sender: ipp-owner@pwg.org Precedence: first-class Status: RO >>> 02/28/97 01:51pm >>> > Scott, it appears that there is no difference between transition T2 and > T4 in your diagram, is this correct? Cut and paste typo in the text, sorry. All of the transitions to and from UNKN are just about the same. The state was known and now is unknown for some reason, or is was unknown, and now that it is known, it just moves into the correct state. T3, T5, and T6 are all more interesting. Do I have it correct? Can you go grom PROC to STOP to IDLE? Scott From ipp-archive Fri Feb 28 19:27:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA09834 for ipp-outgoing; Fri, 28 Feb 1997 19:27:42 -0500 (EST) Message-Id: <9703010027.AA11319@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Feb 1997 16:25:36 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - ISSUE: Add back simple job-print-after with just absolute time Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Subj: ISSUE: Proposal to add back the original job-print-after attribute From: Tom Hastings File: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/pr-after.doc .pdf Date: 2/28/97 I agree that we went to far with the job-hold-until proposal. However, I then think we too far in the other direction by deleting job-print-after altogether. The job-print-after attribute is an ISO DPA level 2 attribute. It is needed in order for a user that has a big job to be able to submit the job now but request that it be scheduled later, so as not to hog the printer during busy hours. Being able to submit now for print later is a very important feature when dealing with large documents within organizations. It is also allows intranet capability to charge less for night printing. I suggest adding the job-print-after attribute back as only an absolute time. We can worry about how the administrator puts absolute time into templates as relative time for IPP V2.0. I also think that we don't need to introduce the held state, but can have the job-print-after-specified value of the job-state-reasons indicate that the job is not a candidate for printing, just like we are doing for the other job-state-reasons while the job is in the pending state. I have posted a complete .doc and .pdf showing the revision marks for adding back this simplified job-print-after job attribute: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ -rw-r--r-- 1 pwg pwg 14848 Mar 1 00:21 pr-after.doc -rw-r--r-- 1 pwg pwg 7957 Mar 1 00:21 pr-after.pdf -rw-r--r-- 1 pwg pwg 8070 Mar 1 00:21 pr-after.pdr The .pdr has red revision marks; the .pdf has black revision marks. Tom From ipp-archive Fri Feb 28 19:37:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA10156 for ipp-outgoing; Fri, 28 Feb 1997 19:36:49 -0500 (EST) Message-ID: <3317780F.237C@sharplabs.com> Date: Fri, 28 Feb 1997 16:27:59 -0800 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: Scott Isaacson CC: Robert.Herriot@Eng.Sun.COM, ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP>MOD - HTML and IPP streams -Reply References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Scott Isaacson wrote: > > >>> Robert Herriot 02/27/97 02:06pm > >>> > > Actually, we did say that an IPP server must support IPP AND HTML > > because if HTML is optional, then a client which expects HTML, must > > have a fallback. If clients must have a fallback to IPP, then no server > > need have HTML. > > What about current browsers that have not been written to IPP but have > been written to use HTML? We leave them out in the cold? > > > I think the primary issue is whether a server gives exactly the same > > information and capabilities via IPP and HTML. > > The semantic mapping for IPP over HTTP will not include any presentation > information. The semantic mapping for IPP over HTML must not as well. > So IPP over HTML will just be abstract attributes and values. There will > be an infinite number of ways to realize this in HTML. > > I see IPP over HTML as just another way to do just a Get Attributes > operation (and maybe a Get Jobs) operation. Not a Print or a Cancel. > The resulting HTML file will not be parsable by a program, but should be > displayable by a browser and understandable to an end user. > > Scott One interesting note is that when you say "IPP over HTML", you're implying that HTML is a transport protocol. Usually when we have been speaking about IPP over , the has been HTTP, raw TCP/IP, or maybe ONC or DCE RPC. This might mean a re-thinking of our document strategy, unless you really mean something like "IPP over HTTP 1.x w/HTML hooks" ;) I'm not sure if HTML qualifies as a transport and if not then we need to look at what the term "IPP over HTML" means, and would there be other mappings to "languages" like HTML in the future. Randy -- Randy Turner Network Architect Sharp Laboratories of America rturner@sharplabs.com