From ipp-archive Thu May 1 00:54:30 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA05408 for ipp-outgoing; Thu, 1 May 1997 00:52:05 -0400 (EDT) Message-ID: <01BC55B0.C648DC00@mgiroux@worldnet.att.net> From: Michael Giroux To: "'Dave Kristol'" , Scott Lawrence Cc: "ipp@pwg.org" , "http-wg@cuckoo.hpl.hp.com" Subject: IPP> RE: MIME multipart/* vs HTTP Date: Wed, 30 Apr 1997 21:45:52 -0700 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4008 Encoding: 28 TEXT Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > In my ignorance of MIME, I've been puzzled about this boundary > business. Assuming each multipart contains a Content-Length header, > does it matter what the boundary is? I agree, but let me say something about Content-Length. Content-Length is not a very efficient mechanism for high volume (tens of thousands of concurrent connections, at 200+ TPS) servers. It requires that the server cache the entire message in order to determine the final length, then send the content. This will generally require that the data is processed at least twice. First to cache it, and again to send it. It would be better if these protocols used a scheme that breaks the message into multiple messages. Each message would start with a length field. In this way, it would be easy to add a boundry marker as defined by a zero length part at end. Continuous streams of bytes are nice for some applications, but for high volume server activity, it is much better to have a protocol that is more specific about the length of the content, and does not require intermediate cache of content so you can calculate the length. I'm not that familiar with MIME, but I would expect that one could define a MIME type that does contain "records", each of which contains a control header (length) and data (length bytes long). Michael Giroux From ipp-archive Thu May 1 02:09:32 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA06130 for ipp-outgoing; Thu, 1 May 1997 02:07:03 -0400 (EDT) Message-Id: <199705010606.CAA02395@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Scott Lawrence" cc: Roger K Debry , ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP>PRO - http comments In-reply-to: Your message of "Wed, 30 Apr 1997 14:50:25 EDT." <199704301850.OAA29642@devnix.agranat.com> Date: Thu, 01 May 1997 02:06:52 -0400 Sender: ipp-owner@pwg.org Precedence: bulk Status: RO My original reply seems to have started an interesting thread on the subject on the http-wg list; I'll let you know how it comes out, but the opinion that the HTTP Content-Length header may be used for each part of a multipart/* seems to be well supported. The meaning of multipart is defined in the MIME specifications. Content-Length isn't part of the multipart definition. As such, it's only a comment, and should be ignored. Keith From ipp-archive Thu May 1 02:09:33 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA06142 for ipp-outgoing; Thu, 1 May 1997 02:09:21 -0400 (EDT) Message-Id: <199705010609.CAA02419@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert.Herriot@eng.sun.com (Robert Herriot) cc: ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP>PRO - http comments In-reply-to: Your message of "Wed, 30 Apr 1997 20:27:05 PDT." <199705010327.UAA25414@woden.eng.sun.com> Date: Thu, 01 May 1997 02:09:14 -0400 Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > If there is a Content-Length header with a value of n, can the program > skip over n bytes without looking for an erroneous boundary-string > within the n bytes? it's bad engineering to have more than one dimension for the same quantity. within a multipart, content-length should *always* be ignored -- or at most used as a "hint" (say, to allocate memory in one big chunk instead of lots of little chunks). but the reader should work correctly even if content-length is completely bogus. Keith From ipp-archive Thu May 1 02:59:38 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA07053 for ipp-outgoing; Thu, 1 May 1997 02:55:41 -0400 (EDT) Message-Id: <199705010655.CAA04062@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Michael Giroux cc: "'Dave Kristol'" , Scott Lawrence , "ipp@pwg.org" , "http-wg@cuckoo.hpl.hp.com" , moore@cs.utk.edu Subject: IPP> Re: MIME multipart/* vs HTTP In-reply-to: Your message of "Wed, 30 Apr 1997 21:45:52 PDT." <01BC55B0.C648DC00@mgiroux@worldnet.att.net> Date: Thu, 01 May 1997 02:55:26 -0400 Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > Content-Length is not a very efficient mechanism for high volume > (tens of thousands of concurrent connections, at 200+ TPS) servers. > It requires that the server cache the entire message in order to > determine the final length, then send the content. This will generally > require that the data is processed at least twice. First to cache it, > and again to send it. Correct, and this is one of the main reasons why content-length mechanisms were not chosen for delimiting multipart boundaries in MIME messages. The other reason was differences in the representation of text messages on different platforms. HTTP doesn't have the latter problem to the same degree as MIME email does, but it does have the former problem. Content-Length is almost as undesirable for HTTP as it is for MIME email. (Not to mention that mixing the protocol-level framing in with the description of the payload causes all sorts of confusion.) > It would be better if these protocols used a scheme that breaks the > message into multiple messages. Each message would start with > a length field. In this way, it would be easy to add a boundry marker > as defined by a zero length part at end. Exactly the solution adopted for SMTP chunking. Keith From ipp-archive Thu May 1 03:29:33 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA07541 for ipp-outgoing; Thu, 1 May 1997 03:25:36 -0400 (EDT) Message-Id: <9705010725.AA03506@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, 1 May 1997 00:23:28 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - IPP Model telecon minutes from 4/25/97 Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I've posted the IPP Model telecon minutes from 4/25/97 in: ftp://ftp.pwg.org/pub/pwg/new_MOD/minutes/ -rw-r--r-- 1 pwg pwg 16384 May 1 07:18 970425-model-telecon-minutes.doc -rw-r--r-- 1 pwg pwg 8164 May 1 07:18 970425-model-telecon-minutes.pdf I've also copied them as text into this message. There will be another Model telecon, this Friday, 5/2, from 1-3 PDT (4-6 EDT). Scott will send out an agenda. Tom Subj: Minutes of the 4/25/97 IPP Model telecon From: Tom Hastings Date: 4/30/97 File: cc970425.doc .pdf Attendees: Jay Martin, Roger deBry, Keith Carter, Bob Herriot, Tom Hastings Proposed Agenda: 1. Defaults (explicit vs implicit) 2. Best Effort a. Client Print Request values vs Printer Supported values (This is the current semantics of best-effort in the model doc. (Note: I suggest this be a print operation parameter rather than a Job attribute) b. External Job Production Instructions vs Embedded values 3. Review conformance text 4. If we get rid of all tags, how do we handle "ready and not-ready" 5. Review mandatory attributes 6. Proposal for a color attribute? 7. Do we need security supported attribute? 8. Proposal for a "I can override the PDL with external attributes" attribute (is this just item 2.b above?) 1. Defaults (explicit and implicit) 1a. We agreed to get rid of the large number of groups of attributes and have only two groups. This will simplify implementation and the specification. The groups agreed to are: 1b. For the Job object: job-status, and job-template 1c. For the Printer object: printer-status, and job-template 1d. When an attribute is registered the registration needs to specify to which group the attribute is to become a member. 1e. Also the "all" group means both groups, i.e., all attributes, for each object. 1f. We may want a more generic name for job-status and printer-status groups, since each includes all attributes that are not part of the job template group. Perhaps printer-status-and-description or status-and-capabilities [no agreement on a better term] 1g. When a user submits a Get Attributes or a Get Jobs without specifying any attributes or any groups, the default is "all". Then we don't need to specify any simple subset, which would be contentious. 1h. The Job template attributes on the Job object specify what is wanted when (1) supplied by the client in the Print operation and (2) when supplied by the Printer as a default because the client did not supply the job template attribute. 1i. The Job template attributes on the Printer object specify the default value for the attribute. Thus the data type is the same for the job template attribute when on the Job object or on the Printer object. 1j. For each xxx Job template attribute there shall be a corresponding xxx-supported and xxx-ready Printer attribute. There will be a specified mapping of the data types for the Job Template attributes to the corresponding xxx-supported and xxx-ready attributes, as in the current draft. There is nothing special about the first value of the xxx-supported attribute; the first value is not the default value. See decision 1I. 1k. For Printer attributes that are not job template attributes there will be none of the form xxx-supported. 1l. If the client does not supply an attribute, the Printer shall supply the default value as specified by the Printer object (set by means outside IPP V1.0). If the Printer does not implement that attribute the Printer shall implement the "default behavior" for that attribute as specified in the Model for each attribute. 1m. When new attributes are registered, their default behavior specification should be what current implementations do that do not know about such an attribute. 2. Best Effort 2a. We re-affirmed that for IPP V1.0, best efforts should be a per job attribute. We did not discuss the suggestion in the agenda that the best-efforts be a Print operation input parameter, rather than a job template attribute. Scott needs to tell us the advantage of making it a Print operation parameter. Perhaps it is because the current specification requires that the default value be 'do-not-substitute', so that the Printer object cannot have a default value for this attribute that is different from 'do-not-substitute'. If best-efforts is changed from being a Job Template attribute to being a Print operation input parameter, best-effort could also become a job status attribute that the Printer copies from the Print operation input parameter and returns on a Get-Attributes operation on a job and a Get-Jobs operation. 2b. External Instructions vs. Embedded values (in the PDL) We decided that the IPP job template attributes that a client supplies are all overrides of what is in the PDL. Various systems will be able to support such overrides to varying degrees, but systems are getting better at allowing such overrides. Such overrides become more important as the web significantly increases the percentage of print jobs that supply already formatted documents (with embedded instructions) to be printed. For IPP V1.0, we doubt that we will be able to come up with a mechanism to allow the Printer to indicate which attributes the Printer supports as embedded in the PDL and/or allows the client to override what is embedded in the PDL. So the Printer object xxx-supported attribute values are ambiguous as to (1) whether the Printer supports the client supplying such values in the protocol to override what is in the PDL when the same instructions are also in the PDL, or (2) whether such values may be supplied by the client only when they are not in the PDL. 3. Review Conformance text in Model version 2.1 3a. Page 18, line 634: We did not agree that attributes that the client supplies are "hints" in IPP. So delete "or hints". 3b. Page 18, line 651: We agreed that the value "unknown" cannot be returned by a Printer as a default value. If the Printer object software had to deal with a Printer for which the Printer object software cannot determine the default value used by the output device, that Printer object software had better always supply its own default value explicitly to the hardware device, so the 'unknown' value is shall not be a legal value for a default attribute. 3c. Similarly a client cannot submit the "unknown" value for a job template attribute. Thus the supported values for a job template attribute are the legal values that a client can submit and that a system administrator can specify as the default values for the Printer. 3d. ACTION ITEM (Tom): Talk to Scott about the suggestion that the Conformance section should just list which other sections and the pertinent contents that a conforming Printer shall conform to and to move the specifics to the sections where the operation is discussed. Then we achieve both goals: (1) have a single place that an implementer can use as a check list for conformance (which points to other sections for specifics) and (2) put the specific conformance statements in the actual specification where they will be easiest for the reader to understand. 4. Getting rid of all tags, how do we handle ready and not-ready 4a. We reaffirmed the idea of getting rid of all tags. They are too complicated. 4b. The Printer object will have 3 attributes whose names are algorithmically generated from the base xxx Job Template attribute: xxx - means the default value (same name as the corresponding job attribute and with the same syntax and values) xxx-supported - means the supported values, whether ready or not. xxx-ready - the subset of the xxx-supported values that are currently ready, i.e., may be used without human intervention. 4c. We decided that having a Printer represent its capabilities with respect to instructions embedded in the PDL would probably wait until after IPP V1. ACTION ITEM (Jay Martin): Prepare a discussion slide for the San Diego meeting about the ideal Printer driver that would be a Universal Printer Driver. Such a driver would discover the capabilities of a Printer using IPP, display the Printer's capabilities to the user, and produce the required IPP to perform the user's selections. We did not have time to get to agenda items 5-7. 8. Proposal for a "I can override the PDL with external attributes" attribute. This is just 2b above. From ipp-archive Thu May 1 11:19:37 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA08848 for ipp-outgoing; Thu, 1 May 1997 11:17:00 -0400 (EDT) Date: Thu, 1 May 1997 11:17:29 -0400 (EDT) From: JK Martin Message-Id: <199705011517.LAA04151@uscore.underscore.com> To: ipp@pwg.org Subject: Re: IPP> MOD - IPP Model telecon minutes from 4/25/97 X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Tom Hastings wrote: > I've posted the IPP Model telecon minutes from 4/25/97 in: > > ftp://ftp.pwg.org/pub/pwg/new_MOD/minutes/ > -rw-r--r-- 1 pwg pwg 16384 May 1 07:18 970425-model-telecon-minutes.doc > -rw-r--r-- 1 pwg pwg 8164 May 1 07:18 970425-model-telecon-minutes.pdf For the record (since these are official meeting minutes), what Tom meant to say was that the abovementioned files are located in: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/minutes/ (That is, the "ipp/" directory was inadvertently omitted.) ...jay From ipp-archive Thu May 1 12:14:38 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA09706 for ipp-outgoing; Thu, 1 May 1997 12:14:20 -0400 (EDT) Date: Thu, 1 May 1997 12:14:44 -0400 (EDT) From: JK Martin Message-Id: <199705011614.MAA04299@uscore.underscore.com> To: ipp@pwg.org Subject: IPP> Initial discussion of the Universal Print Driver in San Diego Cc: upd@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Tom's recently posted Model telecon minutes had this listed near the end: > ACTION ITEM (Jay Martin): Prepare a discussion slide for the San Diego > meeting about the ideal Printer driver that would be a Universal Printer > Driver. Such a driver would discover the capabilities of a Printer using > IPP, display the Printer's capabilities to the user, and produce the > required IPP to perform the user's selections. After the telecon--but before the minutes were posted--a quick discussion was held on the IPP list about a new UPD group, etc. (The UPD mailing list has since been created.) That discussion ended up with the idea of having a "dinner discussion" in San Diego on Thursday nite, May 15. (I am supposed to post the results of the "call for interest" for that event tomorrow, so send me email if you haven't already.) According to the MOD minutes item above, I now have an action item that involves taking some IPP meeting time. The question is, should some small amount of time (say, 1 hour) be carved out for such an initial discussion, or should the "dinner discussion" approach be used? We might be able to find some time on Friday, so as not to disturb the very busy IPP meeting schedule. If we use some Friday time, it'll have to be Friday morning, since I have a flight out in mid-afternoon. If the current subscription list for the just-created UPD mailing list is any indication of interest, then perhaps some "official" time would be appropriate at this point. (Even then, we still might want to have that "discussion dinner", perhaps to nail down exactly what is discussed in the Friday meeting, if it's scheduled.) Again, if you're interested in the Thursday nite dinner discussion, please send me private email (mailto:jkm@underscore.com). ...jay PS: Here is the current subscription list to the UPD mailing list as of the date/time of this message (after only two days in existence): adamsc@pogo.wv.tek.com andrea@vividimage.com Angelo_Caruso@wb.xerox.com cjackson@Adobe.COM CWHITTLE@novell.com davidm@truespectra.com David_Kellerman@nls.com DMitchell@ti.com fumiona@venus.dtinet.or.jp gleeson@zk3.dec.com greg@erc.epson.com harald.ripa@axis.com harryl@us.ibm.com jds@underscore.com jeff@boulder.qms.com jheuer@novell.com jkm@underscore.com JRackowitz@engpo.msmailgw.intermec.com Keith_Carter@aussmtp.austin.ibm.com Lee_Farrell@cissc.canon.com lpyoung@lexmark.com mabry@rd.qms.com Miyasaka.Takashi@exc.epson.co.jp patrick_mckinley@om.cv.hp.com rbergma@dpc.com rdebry@us.ibm.com robk@truespectra.com sbeckst@dpc.com shimura@pure.cpdc.canon.co.jp tom.grav@i-data.com tony@vividimage.com verhelst@xs4all.nl walker@dazel.com YUKI@KEI-CA.CCMAIL.CompuServe.COM ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-archive Thu May 1 12:16:43 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA09695 for ipp-outgoing; Thu, 1 May 1997 12:13:10 -0400 (EDT) Message-Id: <199705011613.MAA17836@life.ai.mit.edu> X-Mailer: Microsoft Outlook Express 4.71.0544.0 From: "Phillip M. Hallam-Baker" To: "Scott Lawrence" , "Larry Masinter" Cc: , Subject: IPP> Re: MIME multipart/* vs HTTP Date: Thu, 1 May 1997 12:19:41 -0400 X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_01BC5629.F21A77C0"; micalg=sha1; protocol=application/x-pkcs7-signature X-MimeOLE: Produced By Microsoft MimeOLE Engine V4.71.0544.0 Sender: ipp-owner@pwg.org Precedence: bulk Status: RO This is a multi-part message in MIME format. ------=_NextPart_000_01BC5629.F21A77C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >> Besides searching for the boundary marker was very expensive computationally, every byte had to be examnined. > >I think 'very' is pretty subjective, and using string matching >algorithms like boyer-moore mean that the number of comparisons >is reduced for longer boundary strings. Its still prohibitive if you want to send video through the channel. I want to be able to have http proxies perform high level routing using minimal state and FSM graphs. I don't care much about wasted bytes, provided they don't cause the header to exceed the first "fast" packet and they are not a performance problem at low bandwidth they are unlikely to be a problem with large data sizes where the control/data ratio is much lower. There is absolutely no problem with a 1000 TPS server sending static files using content length. The vast majority of Web files are static and this will remain so - few people use dynamic images. HTTP has a solution to the content length for variable length data - chunked. When chunked was proposed the problems with MIME were understood. I would have liked to see MIME adopted and add a content length but that was politically incorrect and chunked is better. I don't see what the problem is, Web->Mail gateways have to perform some relatively simple transformations. Big deal. >The standard says only that the boundary string DOES NOT appear >in the body. It happens that if you know nothing about the body >at all, then you can implement this in a probabalistic way, e.g., >the likelihood that a randomly generated boundary string would >appear in arbitrary data could be made arbitrarily small ("less >than the probability that the computer would spontaneously explode"). Not true for real time streams which can become introspective. Imagine you have a network monitor that is pushing a record of network packets onto a central display. The monitors own packets appear here from time to time causing the marker to appear. The probablistic argument is BOGUS and WRONG. The probability is not infintessimal, it is real and most likely to bite people like us. But since it is never necessary to use MIME with HTTP the problem does not appear. Phill ------=_NextPart_000_01BC5629.F21A77C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIGVAYJKoZIhvcNAQcCoIIGRTCCBkECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBUMw ggU/MIIEqKADAgECAhBhQxVohIHU1aLeK14myavFMA0GCSqGSIb3DQEBBAUAMGIxETAPBgNVBAcT CEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVyaVNpZ24gQ2xh c3MgMSBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcjAeFw05NzA0MTAwMDAwMDBaFw05ODA0MTAy MzU5NTlaMIIBGzERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTQw MgYDVQQLEytWZXJpU2lnbiBDbGFzcyAxIENBIC0gSW5kaXZpZHVhbCBTdWJzY3JpYmVyMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvQ1BTIEluY29ycC4gYnkgUmVmLixMSUFC LkxURChjKTk2MScwJQYDVQQLEx5EaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQxJDAiBgNV BAMTG1BoaWxsaXAgTWFydGluIEhhbGxhbS1CYWtlcjEgMB4GCSqGSIb3DQEJARYRaGFsbGFtQGFp Lm1pdC5lZHUwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAn1xytd7KYvG9xC2rzkxgAmoQLavzeX5J hSRifuyeS0Ib8m4juKZA+SM6K+C8PAt+nfRu2/QtDFlS6KRs/ty8rQIDAQABo4ICfTCCAnkwCQYD VR0TBAIwADCCAh8GA1UdAwSCAhYwggISMIICDjCCAgoGC2CGSAGG+EUBBwEBMIIB+RaCAadUaGlz IGNlcnRpZmljYXRlIGluY29ycG9yYXRlcyBieSByZWZlcmVuY2UsIGFuZCBpdHMgdXNlIGlzIHN0 cmljdGx5IHN1YmplY3QgdG8sIHRoZSBWZXJpU2lnbiBDZXJ0aWZpY2F0aW9uIFByYWN0aWNlIFN0 YXRlbWVudCAoQ1BTKSwgYXZhaWxhYmxlIGF0OiBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT OyBieSBFLW1haWwgYXQgQ1BTLXJlcXVlc3RzQHZlcmlzaWduLmNvbTsgb3IgYnkgbWFpbCBhdCBW ZXJpU2lnbiwgSW5jLiwgMjU5MyBDb2FzdCBBdmUuLCBNb3VudGFpbiBWaWV3LCBDQSA5NDA0MyBV U0EgVGVsLiArMSAoNDE1KSA5NjEtODgzMCBDb3B5cmlnaHQgKGMpIDE5OTYgVmVyaVNpZ24sIElu Yy4gIEFsbCBSaWdodHMgUmVzZXJ2ZWQuIENFUlRBSU4gV0FSUkFOVElFUyBESVNDTEFJTUVEIGFu ZCBMSUFCSUxJVFkgTElNSVRFRC6gDgYMYIZIAYb4RQEHAQEBoQ4GDGCGSAGG+EUBBwEBAjAsMCoW KGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L0NQUyAwEQYJYIZIAYb4QgEBBAQD AgeAMDYGCWCGSAGG+EIBCAQpFidodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9D UFMwDQYJKoZIhvcNAQEEBQADgYEAJh3+fz9jUp3TQecpDPMYoZLUJ42ncGftpS00xNE8ILttcpp9 CPSB38TMpr0JIyetRoMCB6M4Sq5IrNadWE/Ot5Rj//x8GjP5f2UWjZnenvCgSGbZdy0d0j+9jk9O +sDZ2f7fKCMYabUDVatyJfIhLVlxuXChUKdiCiEiUEjOtnUxgdowgdcCAQEwdjBiMREwDwYDVQQH EwhJbnRlcm5ldDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNDAyBgNVBAsTK1ZlcmlTaWduIENs YXNzIDEgQ0EgLSBJbmRpdmlkdWFsIFN1YnNjcmliZXICEGFDFWiEgdTVot4rXibJq8UwCQYFKw4D AhoFADANBgkqhkiG9w0BAQEFAARAbaPLXkqsn7NibcesiCdUM0FGl+Aqw1UlfKK6SpkC+tP/9s0v MG3ytUlHhDqslPVkV2tNgYXqGhRhM/cOiz2v7g== ------=_NextPart_000_01BC5629.F21A77C0-- From ipp-archive Thu May 1 12:19:53 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA09824 for ipp-outgoing; Thu, 1 May 1997 12:17:54 -0400 (EDT) Message-Id: <199705011617.MAA18018@life.ai.mit.edu> X-Mailer: Microsoft Outlook Express 4.71.0544.0 From: "Phillip M. Hallam-Baker" To: "Robert Herriot" , "Larry Masinter" Cc: , , , Subject: Re: IPP>PRO - http comments Date: Thu, 1 May 1997 12:24:06 -0400 X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_01BC562A.8FD753C0"; micalg=sha1; protocol=application/x-pkcs7-signature X-MimeOLE: Produced By Microsoft MimeOLE Engine V4.71.0544.0 Sender: ipp-owner@pwg.org Precedence: bulk Status: RO This is a multi-part message in MIME format. ------=_NextPart_000_01BC562A.8FD753C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit --->> It would be good to get a definitive answer as to whether >> Content-Length takes priority over the boundary string in a >> multipart/*. At a recent IETF meeting I asked such a question to some >> knowledgeable person who said that Content-Length was ignored in this >> context and that the boundary string was the only way to determine the >> end of a part in a multipart/*. I would prefer that Content-Length >> take priority if it is present. > >My take: > >It is illegal to send content where the content-length and the boundary >string disagree. So one doesn't take priority over the other. A >recipient >should signal an error if it detects that they are different. I agree with the first part but not the second. If you see a content length the obvious thing to do is to avoid the computationaly intensive check of each byte (yes O(1) is less than anything Boyer-Moore can do and that is not subjective). You hop straight to the boundary. If you see a boundary marker ther, then its OK other wise you signal an error. Note that if there are additional boundaries within the content length delimited block you don't see them. So content length should take priority but you may in some cases be able to detect an error. >Senders that are at all uncertain about the length of the data should >omit content-length and rely on the boundary alone. Yep Phill. ------=_NextPart_000_01BC562A.8FD753C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIGVAYJKoZIhvcNAQcCoIIGRTCCBkECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBUMw ggU/MIIEqKADAgECAhBhQxVohIHU1aLeK14myavFMA0GCSqGSIb3DQEBBAUAMGIxETAPBgNVBAcT CEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVyaVNpZ24gQ2xh c3MgMSBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcjAeFw05NzA0MTAwMDAwMDBaFw05ODA0MTAy MzU5NTlaMIIBGzERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTQw MgYDVQQLEytWZXJpU2lnbiBDbGFzcyAxIENBIC0gSW5kaXZpZHVhbCBTdWJzY3JpYmVyMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvQ1BTIEluY29ycC4gYnkgUmVmLixMSUFC LkxURChjKTk2MScwJQYDVQQLEx5EaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQxJDAiBgNV BAMTG1BoaWxsaXAgTWFydGluIEhhbGxhbS1CYWtlcjEgMB4GCSqGSIb3DQEJARYRaGFsbGFtQGFp Lm1pdC5lZHUwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAn1xytd7KYvG9xC2rzkxgAmoQLavzeX5J hSRifuyeS0Ib8m4juKZA+SM6K+C8PAt+nfRu2/QtDFlS6KRs/ty8rQIDAQABo4ICfTCCAnkwCQYD VR0TBAIwADCCAh8GA1UdAwSCAhYwggISMIICDjCCAgoGC2CGSAGG+EUBBwEBMIIB+RaCAadUaGlz IGNlcnRpZmljYXRlIGluY29ycG9yYXRlcyBieSByZWZlcmVuY2UsIGFuZCBpdHMgdXNlIGlzIHN0 cmljdGx5IHN1YmplY3QgdG8sIHRoZSBWZXJpU2lnbiBDZXJ0aWZpY2F0aW9uIFByYWN0aWNlIFN0 YXRlbWVudCAoQ1BTKSwgYXZhaWxhYmxlIGF0OiBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT OyBieSBFLW1haWwgYXQgQ1BTLXJlcXVlc3RzQHZlcmlzaWduLmNvbTsgb3IgYnkgbWFpbCBhdCBW ZXJpU2lnbiwgSW5jLiwgMjU5MyBDb2FzdCBBdmUuLCBNb3VudGFpbiBWaWV3LCBDQSA5NDA0MyBV U0EgVGVsLiArMSAoNDE1KSA5NjEtODgzMCBDb3B5cmlnaHQgKGMpIDE5OTYgVmVyaVNpZ24sIElu Yy4gIEFsbCBSaWdodHMgUmVzZXJ2ZWQuIENFUlRBSU4gV0FSUkFOVElFUyBESVNDTEFJTUVEIGFu ZCBMSUFCSUxJVFkgTElNSVRFRC6gDgYMYIZIAYb4RQEHAQEBoQ4GDGCGSAGG+EUBBwEBAjAsMCoW KGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L0NQUyAwEQYJYIZIAYb4QgEBBAQD AgeAMDYGCWCGSAGG+EIBCAQpFidodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9D UFMwDQYJKoZIhvcNAQEEBQADgYEAJh3+fz9jUp3TQecpDPMYoZLUJ42ncGftpS00xNE8ILttcpp9 CPSB38TMpr0JIyetRoMCB6M4Sq5IrNadWE/Ot5Rj//x8GjP5f2UWjZnenvCgSGbZdy0d0j+9jk9O +sDZ2f7fKCMYabUDVatyJfIhLVlxuXChUKdiCiEiUEjOtnUxgdowgdcCAQEwdjBiMREwDwYDVQQH EwhJbnRlcm5ldDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNDAyBgNVBAsTK1ZlcmlTaWduIENs YXNzIDEgQ0EgLSBJbmRpdmlkdWFsIFN1YnNjcmliZXICEGFDFWiEgdTVot4rXibJq8UwCQYFKw4D AhoFADANBgkqhkiG9w0BAQEFAARAKJfcKqBvdMTGY85mlTP21EYOq33sfiVn5xK6HDNShUo0UeQD SzocOAA9jjbtsD2j0y3QmvY6kOKD1cSIjGgYzg== ------=_NextPart_000_01BC562A.8FD753C0-- From ipp-archive Thu May 1 14:29:38 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA13023 for ipp-outgoing; Thu, 1 May 1997 14:26:36 -0400 (EDT) Message-ID: <3368EE86.6652@sharplabs.com> Date: Thu, 01 May 1997 12:27:02 -0700 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> IPP/HTTP analysis document Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I will absolutely (I mean it this time) have the IPP/HTTP document out on Friday (tomorrow), so hopefully folks will have time to analyze it for a few days prior to the next meeting. Randy -- Randy Turner Network Architect Sharp Laboratories of America rturner@sharplabs.com From ipp-archive Thu May 1 15:49:39 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA14348 for ipp-outgoing; Thu, 1 May 1997 15:48:50 -0400 (EDT) Date: Thu, 1 May 1997 12:45:57 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705011945.MAA03802@woden.eng.sun.com> To: ipp@pwg.org Subject: Re: IPP>PRO - http comments Cc: http-wg@cuckoo.hpl.hp.com X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO We seem to have a wide variety of beliefs about how Content-Length and boundary strings interact when a part of a multipart/* contains a Content-Length. I prefer the behavior described by the last email in this series. But this exchange shows a lack of consensus. Can we reach consensus, or this an email versus HTTP difference in behavior? I have summarized the differt opinions below. >From moore@cs.utk.edu Wed Apr 30 23:10:31 1997 The meaning of multipart is defined in the MIME specifications. Content-Length isn't part of the multipart definition. As such, it's only a comment, and should be ignored. >From masinter@parc.xerox.com Wed Apr 30 18:51:51 1997 It is illegal to send content where the content-length and the boundary string disagree. So one doesn't take priority over the other. A recipient should signal an error if it detects that they are different. >From masinter@parc.xerox.com Wed Apr 30 18:51:51 1997 in reply to my question to his reply above BH> If there is a Content-Length header with a value of n, can the program BH> skip over n bytes without looking for an erroneous boundary-string BH> within the n bytes? I think that a careful program would use the content-length to check the boundary-string, rather than vice versa. However, "non-standard values are non-standard"; there's only so far you should go in a standard saying what programs have to do when confronted with non-standard input. >From hallam@ai.mit.edu Thu May 1 09:14:39 1997 replying to Larry's comments I agree with the first part but not the second. If you see a content length the obvious thing to do is to avoid the computationaly intensive check of each byte (yes O(1) is less than anything Boyer-Moore can do and that is not subjective). You hop straight to the boundary. If you see a boundary marker ther, then its OK other wise you signal an error. Note that if there are additional boundaries within the content length delimited block you don't see them. So content length should take priority but you may in some cases be able to detect an error. >Senders that are at all uncertain about the length of the data should >omit content-length and rely on the boundary alone. Yep From ipp-archive Thu May 1 21:44:42 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA18507 for ipp-outgoing; Thu, 1 May 1997 21:43:35 -0400 (EDT) Message-Id: <199705020143.VAA11947@spot.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert.Herriot@eng.sun.com (Robert Herriot) cc: ipp@pwg.org, http-wg@cuckoo.hpl.hp.com, moore@cs.utk.edu Subject: Re: IPP>PRO - http comments In-reply-to: Your message of "Thu, 01 May 1997 12:45:57 PDT." <199705011945.MAA03802@woden.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 May 1997 21:43:28 -0400 Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > We seem to have a wide variety of beliefs about how Content-Length > and boundary strings interact when a part of a multipart/* contains a > Content-Length. I prefer the behavior described by the last > email in this series. But this exchange shows a lack of consensus. > Can we reach consensus, or this an email versus HTTP difference in > behavior? This whole exchange is a good illustration on why I'm opposed to the reuse of HTTP/1.1 for non-web applications, including a printing protocol. HTTP/1.1 is a real mess. MIME is also a real mess. They are messy because they needed to be backward compatible with a widely deployed installed base, while adding new features not anticipated for in the original protocol design. Any new printing protocol will have its own baggage also. Should it then inherit additional baggage from HTTP and MIME? Being able to print from a web browser would be a Good Thing, but I seriously question whether it's worthwhile to standardize this interface. Printer shops are going to need to add their own front-ends anyway, for queueing and to add additional services not supported directly by a printer. It would be far better to define a new protocol which doesn't inherit the baggage of HTTP/1.1. The "baggage" isn't the amount of code required to implement the protocol, it's the difficulty in dealing with lots of protocol variants -- caused by multiple earlier versions with ill-defined specifications, as well as future changes to HTTP -- and the resulting lack of interoperability and increased testing/support costs. (not to mention the overhead of having arguments about whether Content-Length is valid within a multipart content which is carried over HTTP.) It seems like the lpr problem all over again, only worse. (Except that the one thing "right" about the lpr protocol design is that it's framing protocol is almost foolproof -- a byte count followed by that many bytes.) Do you really want to burn HTTP/1.1 and MIME support into printer ROMs? Why not use something which is simpler and easier to get right? Keith p.s. Use of Content-Length *within* a multipart (as opposed to the top level) seems like a huge design botch precisely because it begs the question of what happens if Content-Length is wrong (as it often is). If there's really a good reason for using it within a multipart, I'd like to know about it. From ipp-archive Thu May 1 22:09:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA18975 for ipp-outgoing; Thu, 1 May 1997 22:05:23 -0400 (EDT) Message-Id: <199705020205.WAA11986@spot.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Phillip M. Hallam-Baker" cc: "Robert Herriot" , "Larry Masinter" , rdebry@us.ibm.com, lawrence@agranat.com, ipp@pwg.org, http-wg@cuckoo.hpl.hp.com, moore@cs.utk.edu Subject: Re: IPP>PRO - http comments In-reply-to: Your message of "Thu, 01 May 1997 12:24:06 EDT." <199705011617.MAA18018@life.ai.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 May 1997 22:05:00 -0400 Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > Note that if there are additional boundaries within the content length > delimited block you don't see them. > > So content length should take priority but you may in some cases be > able to detect an error. Content-Length fields do sometimes appear in MIME message bodyparts. Such Content-Length fields are often incorrect, but are generally ignored by MIME user agents because they're nonstandard. Those same messages can and do get returned in HTTP responses as message/rfc822 objects. (this is actually a nice way to provide HTTP access to a mail archive, since the client will format it as if it would an email message.) Should the HTTP server then scan the internals of a message/rfc822 or multipart/* message that it's returning, and correct or remove every Content-Length header field, just so the HTTP client doesn't have to scan for the boundary marker? This doesn't make any sense to me. Not only does it require the server to alter message content, it also puts the computational burden in the wrong place. (The following is with my AD hat on:) Otherwise: Content-Length is part of the HTTP protocol, not part of the MIME specification. Content-Length is valid for an HTTP entity header, but not valid for the header of a component of a multipart. This needs to be clarified in the next verison of the HTTP protocol specification. In general, it is not acceptable for HTTP multipart to have a inconsistent definition from MIME multipart. If exceptions are needed for backward compatibility, the specification needs to say exactly when those exceptions apply -- but not for all multipart variants regardless of how they are transmitted. Keith From ipp-archive Fri May 2 11:24:50 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA21269 for ipp-outgoing; Fri, 2 May 1997 11:24:48 -0400 (EDT) Message-ID: <336A0739.603E@sharplabs.com> Date: Fri, 02 May 1997 08:24:41 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> PC WEEK: IETF charters group for Web-based printing standard Content-Type: multipart/mixed; boundary="------------6A722EFC596C" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO This is a multi-part message in MIME format. --------------6A722EFC596C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit http://www8.zdnet.com/pcweek/news/0428/01eipp.html --------------6A722EFC596C Content-Type: text/html; charset=us-ascii; name="01eipp.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="01eipp.html" Content-Base: "http://www8.zdnet.com/pcweek/news/0428 /01eipp.html" PC WEEK: IETF charters group for Web-based printing standard

  Bring Token Ring up to speed.  Click here for 3Com Token Ring Solutions.

May 1, 1997 6:15 PM ET
IETF charters group for Web-based printing standard
By Scott Berinato

  The Internet Engineering Task Force has chartered a consortium of vendors to develop a standard interface for Web printing.

The Printer Working Group announced this week that the IETF has formally chartered the Internet Printing Protocol Working Group to create the interface, which would address job submission, ticketing and some basic management features for Web-based printing, IPP officials said.

Formed last November under a charter from the PWG, the IPP is faced with making printing over the Web simpler, by providing universal protocols for submitting jobs and controlling printers connected to the Internet. The architecture will address printers either connected to a Web server or with an embedded Web server, so that designated users could access the device remotely.

In this vein, enterprises could set up "public printers," so one business partner could push a hard copy to another enterprise over the Web, avoiding overnight delivery costs.

A Web printing standard would also lay the groundwork for publishers to push customized magazines to subscribers, said IPP officials.

Sources said Microsoft Corp. presented to the working group its architecture for Web printing, which contains some of the basics the group hopes to implement. However, the Redmond, Wash., developer did not address all the issues, such as job ticketing, that the IPP wants to standardize, sources said.

Windows NT 5.0 will support the IPP specification, the sources said.

The IPP protocol will be designated for printers, but officials of the IPP said there's no reason such a design couldn't be transferred to other Web-enabled devices.

"They've got very broad industry support and that will help," said Grey Held, associate editor of the Hard Copy Observer, in Newtonville, Mass. "I think [support for] the IPP spec will show up by the end of the year. It's on the fast track. People are anxious for it."

A first draft of the Web printing guidelines is available at www.pwg.org/ipp.

Members of the IPP working group include Adobe Systems Inc., Canon Computer Systems Inc., Hewlett-Packard Co., IBM, Kyocera Electronics Inc., Lexmark International Inc., Microsoft, Netscape Communications Corp., Novell Inc., QMS Inc., Sharp Electronics Inc., Sun Microsystems Inc., Tektronix Inc. and Xerox Corp.

Copyright(c) 1997 Ziff-Davis Publishing Company. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of Ziff-Davis Publishing Company is prohibited. PC Week and the PC Week logo are trademarks of Ziff-Davis Publishing Company. PC Week Online and the PC Week Online logo are trademarks of Ziff-Davis Publishing Company.

Send mail to PC Week

--------------6A722EFC596C-- From ipp-archive Fri May 2 11:59:50 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA22251 for ipp-outgoing; Fri, 2 May 1997 11:56:40 -0400 (EDT) Message-Id: <3.0.1.32.19970502085302.00e22068@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 2 May 1997 08:53:02 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - IPP in the press Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO There is one article, apparently based on the earlier Novell relesae under: http://www.techweb.com/wire/wire.html To find the article, which is dated April 20, you also need to make a search for "Novell" 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 May 2 12:24:51 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA22917 for ipp-outgoing; Fri, 2 May 1997 12:21:56 -0400 (EDT) Message-Id: <3.0.1.32.19970502090745.01036cb8@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 2 May 1997 09:07:45 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - yet another press article Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO NetworkWorld ran an article in their 4/21 issue regarding Internet Printing that highlights Microsoft's NT printing activities and the IETF IPP work. See below. ------ Microsoft explores Web-enabled printing for NT By Christine Burns 04/21:/97 Redmond, Wash. Microsoft Corp. has got feelers out for the best way to implement Web-enabled printing in future versions of Windows NT. At the same time, the company is working with Internet Engineering Task Force (IETF) partners on a common protocol for sending print jobs across the Internet. It is unclear whether Microsoft will ship the new NT feature before the standard is finalized. Given the ease with which users can share files across the Internet, vendors have begun looking at ways to let individuals send print jobs from any desktop to any printer using standard World-Wide Web technologies. This same technology could eventually simplify management of remote printers using the Internet, as well. Novell, Inc. and IBM - two leaders in the IETF effort - have committed to supporting the emerging standard in all of their operating systems. Microsoft acknowledged its involvement in the standards work and general plans to implement Web-enabled printing in NT. 'However we decide to implement Internet printing in NT, we will also support the IETF standards,' said Enzo Schiano, group product manager for Windows NT Server. Schiano would not say whether this printing feature would appear in the upcoming NT 5.0 release or a later version. While Schiano declined to comment on implementation, documents submitted to the IETF by Microsoft do offer insights on Web-enabled printing for NT. A slide presentation shows an NT client sending a print job over the Internet to an NT server. The client machine employs a 32-bit Internet/HTTP print provider, which sends the print job to an NT print server running Microsoft's Internet Information Server and integrated HTTP print server software. This HTTP print server receives the raw HTTP command from the client and forwards it to the appropriate networked printer. The slides also show a browser getting an HTML view of printer status and job information that was generated automatically by the NT print server. While Microsoft weighs its options, the standards effort moves ahead. The IETF working group two weeks ago produced a preliminary draft of the Internet Printing Protocol. IPP defines client and server functions for Internet printing. A formal draft of the IPP specification is expected in December. Products based on IPP will not appear until 1998. Industry analysts were skeptical about Microsoft maintaining compatibility with IPP products. 'They forced the printer vendors into their proprietary camp before,' said Angele Boyd, vice president of peripheral research with International Data Corp in Framingham, Mass. 'It's a tough call to choose between Microsoft's market and that of Novell, Netscape [Communications Corp.] and IBM combined. They might have to support multiple protocols.' The first version of IPP defines a common interface by which computers locate printers across the Web, submit jobs to them, query the status of the printers and jobs, and cancel previously submitted jobs. This version will give administrators some ability to monitor Web printers, but future versions will support advanced printer management features, said Scott Isaacson, a print services architect at Novell. Isaacson said Novell will support IPP in future versions of its yet-to-be-released Novell Distributed Printing Service. Additionally, Novell will build extensions that address management and usability functions not included in the IPP specification. ------ 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 May 2 12:59:51 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA23449 for ipp-outgoing; Fri, 2 May 1997 12:59:03 -0400 (EDT) From: Roger K Debry To: , Subject: Re: IPP>PRO - things that worry me Message-Id: <5030100002150715000002L052*@MHS> Date: Fri, 2 May 1997 13:01:07 -0400 Mime-Version: 1.0 Content-Type: text/plain; name="MEMO 05/02/97 12:58:52" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Classification: Scott, thanks for your response. Just a couple of things: 1) Could you provide a short scenario of how using byte ranges would work for recovery when sending very large files for those of us who are novices in http? That would be genuinely helpful. 2) I can see in your response to my last question see how shutting down the connection signals some problem, but I'd like to be able to tell the client what the problem is! 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 05/02/97 10:52 AM --------------------------- lawrence @ devnix.agranat.com 04/30/97 11:44 AM To: Roger K Debry/Boulder/IBM cc: ipp @ pwg.org@internet Subject: Re: IPP>PRO - things that worry me >>>>> "RKD" == Roger K Debry writes: RKD> As we close in on the definition of the protocol, there RKD> are still some things that worry me. RKD> 1) Will our proposed use of http handle the transport of RKD> very very large (many Gbyte) files efficiently and with sufficient RKD> recovery? I know you all have tried to convince me that tcp/ip RKD> provides everything that is necessary to guarantee delivery, RKD> but I still am concerned that we may have left holes where RKD> a connection remains open because of some failure, or some RKD> component times out, the print file does not get delivered and RKD> no one knows why or how to recover because there is no ipp RKD> level notification of what has happened. I don't understand what you believe is missing. The file would be sent as (part of) the body of an HTTP POST, which only acknowleged when the entire body has been received and understood. As to sufficient recovery, for files of that size you might want to consider the use of multipart/byterange to break up the file so that you can avoid resending the entire file following some failures. This does not require any HTTP/1.1 change that I can think of. RKD> 2) Have we sufficiently handled the case where a print driver is RKD> generating the print ouput and putting it on the wire a piece at RKD> a time? Does chunking solve this problem? If the problem you refer to is not knowing how big the content is at the time you are generating the HTTP headers, then yes, chunking does solve that problem. RKD> 3) Have we sufficiently handled the case where ipp is implemented RKD> in an output device that has no capability to spool the data so must RKD> start printing while receiving the data? What happens when a printer RKD> failure occurs during transmission in this case? The printer (in its role as HTTP server) will not have sent an acknowlegement of the POST yet. When the failure occurs, it can prematurely close the TCP connection. The client will (correctly) interpret this premature close as an error in the server and will know that the POST has not occured (ie the file has not been printed). -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-archive Fri May 2 13:09:52 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA23910 for ipp-outgoing; Fri, 2 May 1997 13:09:12 -0400 (EDT) Message-Id: <199705021709.NAA32390@devnix.agranat.com> To: Roger K Debry cc: ipp@pwg.org Subject: Re: IPP>PRO - things that worry me In-reply-to: <5030100002150715000002L052*@MHS> Date: Fri, 02 May 1997 13:09:19 -0400 From: "Scott Lawrence" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO >>>>> "RKD" == Roger K Debry writes: RKD> 1) Could you provide a short scenario of how using byte ranges RKD> would work for recovery when sending very large files for those RKD> of us who are novices in http? That would be genuinely helpful. I'd be glad to, but it will have to wait until after Interop - I don't want to attempt a hasty answer and don't have time for more than that. (If anyone on the list will be at Interop, stop by and say hello at booth #4206 - it would be good to have faces to go with the names :-) RKD> 2) I can see in your response to my last question see how RKD> shutting down the connection signals some problem, but I'd like RKD> to be able to tell the client what the problem is! I'm afraid there is no easy answer to this one. There has been some (small) discussion of this on the http-wg list, and there just isn't a way to do it in the current protocol at the HTTP layer. If IPP is layered _above_ HTTP, then there may well be an answer; as I understand the current thinking there would be a status URL associated with any job, so a client who say an early close on the file transmission could GET the status URL. -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-archive Fri May 2 14:24:53 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA25581 for ipp-outgoing; Fri, 2 May 1997 14:21:30 -0400 (EDT) Message-Id: <199705021818.OAA25826@spot.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: carl@manros.com, szilles@adobe.com cc: ipp@pwg.org, Harald Alvestrand Subject: IPP> misleading press release issued by IPP WG In-reply-to: Your message of "25 Apr 1997 18:09:05 EDT." <199704252216.AA20536@interlock2.lexmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 02 May 1997 14:18:02 -0400 Sender: ipp-owner@pwg.org Precedence: bulk Status: RO re: The press release issued last week by the IPP WG Don Wright's quote listing vendors as participants in IETF was misleading. IETF recognizes only individuals -- not vendors or even representatives of vendors -- as participants in its working groups. Articles based on this press release have already started to appear, which are damaging IETF's reputation and misleading the public about IETF's function. I've received several complaints about these articles from IETF participants. The IPP WG is hereby directed to issue a correction to its earlier press release, to be sent to the same contacts as the original press release, which clearly explains that IETF participants are individuals rather than vendor representatives. The WG is further directed to change its web pages and ftp site so that any mention of vendor participation in the IPP WG or IETF is changed to refer to individual participation only. The correction to the press release and changes to the web pages are required by Tuesday, May 6. The correction must be explicitly approved by the IETF Applications Area directors before it is issued. (Harald is currently on holiday, but should be back by then.) Keith Moore co-Director, Applications Area Internet Engineering Task Force p.s. I understand if this comes as a surprise to IETF newcomers. However, on April 17 I sent the following note to the IPP chairs regarding the press release being drafted, in an attempt to prevent mischaracterization of IETF: > To: Carl-Uno Manros , szilles@adobe.com > cc: moore@cs.utk.edu, Harald Alvestrand > From: Keith Moore > Subject: IPP press release > Date: Thu, 17 Apr 1997 15:05:20 EDT > > > IETF WGs have traditionally not done press releases. A popular belief > is that media attention makes a group's work more difficult. If the > working group is open to all, reaches consensus on a solution, and > produces an effective solution to a problem that needs solving, > acceptance and deployment are not usually a problem. > > On the other hand, the absence of public information about a WG's > activities invites disinformation and media speculation, which is > clearly undesirable. Keeping the media informed about the activities > of an IETF WG, so long as the information is accurate, seems like a > Good Thing, and the WG itself is probably the best source of that > information. Nor do I know of any IETF policy that would preclude a > WG from doing issuing a press release. > > On one point, however, IETF policy is clear. IETF participants are > considered to represent themselves as individuals, not the companies > they work for. It is therefore inappropriate for an IETF WG to claim > that it has representatives from particular companies. > > Having said that, I don't see any problem with a press release > including brief statements in support of an IETF WG's efforts, from > companies and/or individuals, assuming you can get agreement as to > whose statements come first... > > Keith Even though the list of vendors was part of a quote by Don Wright, it is clearly being taken by the press as a statement from the group. This is not unreasonable given that the press release was issued by the group. The false impression needs to be corrected. From ipp-archive Fri May 2 14:29:56 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA26033 for ipp-outgoing; Fri, 2 May 1997 14:28:18 -0400 (EDT) From: Keith_Carter@aussmtp.austin.ibm.com X-Lotus-FromDomain: AUSNOTES To: ipp@pwg.org cc: debry%bldvmb@aussmtp.austin.ibm.com, Robert.Herriot@eng.sun.com, scott_isaacson@novell.com, hastings@cp10.es.xerox.com Message-ID: <8625648B:0063979E.00@aussmtp3.austin.ibm.com> Date: Fri, 2 May 1997 13:27:24 -0500 Subject: IPP> MOD: Proposal to improve job submission in IPP 1.0 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Roger deBry and I want to propose a change to the IPP Model that delineates job and document boundaries through IPP operations rather than relying on an underlying protocol to do so. In our opinion, recent email has indicated that chunking and multi-part MIME will complicate IPP implementations. We believe using IPP operations will simplify IPP implementations. We would like to discuss this proposal at the IPP Model call on Friday, May 2. Rather than write alot of words at this point, here is an example of submitting a job with 3 documents. The first document, DOC1, uses multiple writes to send to the Printer. The second document, DOC2, is a reference to a URL. The third document, DOC3, can be sent in single write. CreateJob (Printer URL, job-template attributes and values) SendDocument (Job URL, document-name=DOC1, document-part=first, data-length=500, ) SendDocument (Job URL, document-name=DOC1, document-part=middle, data-length=500, ) SendDocument (Job URL, document-name=DOC1, document-part=middle, data-length=500, ) SendDocument (Job URL, document-name=DOC1, document-part=last, data-length=150, ) SendDocument (Job URL, document-name=DOC2, document-URL=) SendDocument (Job URL, document-name=DOC3, document-part=only, data-length=100, ) EndJob (Job URL) CreateJob is the operation suggested in proposals from Randy Turner and Bob Herriot. SendDocument and EndJob are new operations. For SendDocument, the document-part attribute allows an IPP Client to specify the part of the document data that is being sent as follows: first = first set of data sent for a document middle = set 2 to n-1 of data sent for a document last = last set (n) of data sent for a document only = only set of data sent for a document document-part=first must be paired with document-part=end. document-part=middle is optional but can only be sent after document-part=first and before document-part=last. document-part=only can be sent once per document object. document-part=only cannot be sent between document-part=first and document-part=last. The benefits of this proposal are as follows: 1. An IPP Server can easily distinguish document boundaries based on a standard Model operation. 2. An IPP Server can easily distinguish end-of-job based on a standard Model operation. 3. An IPP Server has the opportunity to respond with status at several points throughout the transmission of a job (i.e. provide status in the response to SendDocument and EndJob). 4. The IPP Operations map more easily to APIs that IPP Applications might use to submit IPP requests. If the IPP working group agrees with this proposal, then Roger and/or I will write a more thorough description for the IPP Model spec which the IPP working group can subsequently review. Enjoy, Keith From ipp-archive Fri May 2 14:44:55 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA26701 for ipp-outgoing; Fri, 2 May 1997 14:39:59 -0400 (EDT) Message-Id: <3.0.1.32.19970502111557.00e11b50@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 2 May 1997 11:15:57 PDT To: ipp@pwg.org, groberts@rinc.ussj.ricoh.com From: Carl-Uno Manros Subject: IPP> Proposed Agenda for the IPP meeting in San Diego on May 15 In-Reply-To: <3368A2B1.180A@rinc.ussj.ricoh.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Proposed Agenda for the PWG IPP meeting in San Diego on May 15 8:30 - 12:00 am Discussion about options for the IPP Protocol This will include a presentation and demonstration from Microsoft and HP 1:00 - 5 pm Discussion about how the Prototyping efforts could support the protocol choices Discusion of IPP Security Discussion of the Universal Print Driver (this is expected to later become a separete activity within the PWG) ---- Comments, please, e.g. do we need to have any time for Model considering that there will be a full day meeting on that subject on May 14. BTW, for those of you planning to attend that meeting, do not forget to notify Patrick Powell. So far he has only got a handfull of names! 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 May 2 14:54:52 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA27170 for ipp-outgoing; Fri, 2 May 1997 14:52:52 -0400 (EDT) Message-ID: <336A3813.3654@sharplabs.com> Date: Fri, 02 May 1997 11:53:07 -0700 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: Keith_Carter@aussmtp.austin.ibm.com CC: ipp@pwg.org, debry%bldvmb@aussmtp.austin.ibm.com, Robert.Herriot@eng.sun.com, scott_isaacson@novell.com, hastings@cp10.es.xerox.com Subject: Re: IPP> MOD: Proposal to improve job submission in IPP 1.0 References: <8625648B:0063979E.00@aussmtp3.austin.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Let me first state that I think a protocol along the lines of what Roger and Keith are suggesting would work, with some additional "filling out" as they would normally do if they were to formally spec. this out in a document. It does however bring us back to the decision whether or not to use HTTP or a completely new protocol. All of the operations and benefits of the protocol suggested could be accomplished by tightly coupling IPP semantics to HTTP. The "fleshing out" of a formal proposal that details Roger and Keith's design would (IMHO) duplicate alot of what HTTP is already providing. Not that one way is any better than the other, but like what was suggested by someone in an earlier protocol telecon, "Do we want to create another protocol that is 80-100% semantically equivalent to HTTP?" I think chunking of a multipart message could be done effectively, similar to what Steve Zilles and I were discussing at the last telecon, and the feature of being able to return intermediate status between "SendDocument" operations could be provided by allowing clients to send jobs using multiple POST operations. Like I mentioned earlier, I will have a document that references these mechanisms, and references how Bob Herriot's proposal would have to change if we were to be HTTP 1.1 compliant. I will have this document out by the end of the day (today, Friday). Randy Keith_Carter@aussmtp.austin.ibm.com wrote: > > Roger deBry and I want to propose a change to the IPP Model that > delineates job and document boundaries through IPP operations rather than > relying on an underlying protocol to do so. In our opinion, recent email > has indicated that chunking and multi-part MIME will complicate IPP > implementations. We believe using IPP operations will simplify IPP > implementations. We would like to discuss this proposal at the IPP Model > call on Friday, May 2. > > Rather than write alot of words at this point, here is an example of > submitting a job with 3 documents. The first document, DOC1, uses > multiple writes to send to the Printer. The second document, DOC2, is a > reference to a URL. The third document, DOC3, can be sent in single > write. > > CreateJob (Printer URL, job-template attributes and values) > SendDocument (Job URL, document-name=DOC1, document-part=first, > data-length=500, ) > SendDocument (Job URL, document-name=DOC1, document-part=middle, > data-length=500, ) > SendDocument (Job URL, document-name=DOC1, document-part=middle, > data-length=500, ) > SendDocument (Job URL, document-name=DOC1, document-part=last, > data-length=150, ) > SendDocument (Job URL, document-name=DOC2, document-URL=) > SendDocument (Job URL, document-name=DOC3, document-part=only, > data-length=100, ) > EndJob (Job URL) > > CreateJob is the operation suggested in proposals from Randy Turner and > Bob Herriot. SendDocument and EndJob are new operations. > > For SendDocument, the document-part attribute allows an IPP Client to > specify the part of the document data that is being sent as follows: > > first = first set of data sent for a document > middle = set 2 to n-1 of data sent for a document > last = last set (n) of data sent for a document > only = only set of data sent for a document > > document-part=first must be paired with document-part=end. > document-part=middle is optional but can only be sent after > document-part=first and before document-part=last. document-part=only > can be sent once per document object. document-part=only cannot be sent > between document-part=first and document-part=last. > > The benefits of this proposal are as follows: > > 1. An IPP Server can easily distinguish document boundaries based > on a standard Model operation. > 2. An IPP Server can easily distinguish end-of-job based on a standard > Model operation. > 3. An IPP Server has the opportunity to respond with status at several > points throughout the transmission of a job (i.e. provide status > in the response to SendDocument and EndJob). > 4. The IPP Operations map more easily to APIs that IPP Applications > might use to submit IPP requests. > > If the IPP working group agrees with this proposal, then Roger and/or I > will write a more thorough description for the IPP Model spec which the > IPP working group can subsequently review. > > Enjoy, > > Keith -- Randy Turner Network Architect Sharp Laboratories of America rturner@sharplabs.com From ipp-archive Fri May 2 15:09:54 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA27624 for ipp-outgoing; Fri, 2 May 1997 15:03:15 -0400 (EDT) Date: Fri, 2 May 1997 14:59:52 -0400 (EDT) From: JK Martin Message-Id: <199705021859.OAA08903@uscore.underscore.com> To: cmanros@cp10.es.xerox.com Subject: Re: IPP> Proposed Agenda for the IPP meeting in San Diego on May 15 Cc: ipp@pwg.org, upd@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Carl-Uno, Based on the private mail sent to me regarding interest in the new Universal Print Driver concept, it would appear that many folks would like to spend more than a few minutes on the topic in San Diego. And, based on the current work, the IPP will need as much time as possible in San Diego *without* going into the UPD stuff. I'll be posting a more formal message to the UPD list in the next few minutes regarding what appears to be the best plan, but I don't think UPD should take any of the precious time currently allotted to the IPP. Hopefully no one has a problem with this. ...jay ----- Begin Included Message ----- >From ipp-owner@pwg.org Fri May 2 14:45 EDT 1997 Date: Fri, 2 May 1997 11:15:57 PDT To: ipp@pwg.org, groberts@rinc.ussj.ricoh.com From: Carl-Uno Manros Subject: IPP> Proposed Agenda for the IPP meeting in San Diego on May 15 Proposed Agenda for the PWG IPP meeting in San Diego on May 15 8:30 - 12:00 am Discussion about options for the IPP Protocol This will include a presentation and demonstration from Microsoft and HP 1:00 - 5 pm Discussion about how the Prototyping efforts could support the protocol choices Discusion of IPP Security Discussion of the Universal Print Driver (this is expected to later become a separete activity within the PWG) ---- Comments, please, e.g. do we need to have any time for Model considering that there will be a full day meeting on that subject on May 14. BTW, for those of you planning to attend that meeting, do not forget to notify Patrick Powell. So far he has only got a handfull of names! 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 ----- End Included Message ----- From ipp-archive Fri May 2 15:34:53 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA28365 for ipp-outgoing; Fri, 2 May 1997 15:34:10 -0400 (EDT) From: Roger K Debry To: Subject: Re: IPP> MOD: Proposal to improve job submission in IPP 1.0 Message-Id: <5030100002158282000002L022*@MHS> Date: Fri, 2 May 1997 15:36:03 -0400 Mime-Version: 1.0 Content-Type: text/plain; name="MEMO 05/02/97 15:33:37" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Classification: The proposal that Keith and I are making would still ride very nicely on top of http. Each operation would simply be a separate post. The attractive feature of this is that the semantics of the model map onto http or any other transport in the exactly same way. 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 05/02/97 01:25 PM --------------------------- ipp-owner @ pwg.org 05/02/97 12:59 PM Please respond to rturner@sharplabs.com@internet To: Keith_Carter @ aussmtp.austin.ibm.com@internet cc: hastings @ cp10.es.xerox.com@internet, scott_isaacson @ novell.com@internet, Robert.Herriot @ eng.sun.com@internet, debry%bldvmb @ aussmtp.austin.ibm.com@internet, ipp @ pwg.org@internet Subject: Re: IPP> MOD: Proposal to improve job submission in IPP 1.0 Let me first state that I think a protocol along the lines of what Roger and Keith are suggesting would work, with some additional "filling out" as they would normally do if they were to formally spec. this out in a document. It does however bring us back to the decision whether or not to use HTTP or a completely new protocol. All of the operations and benefits of the protocol suggested could be accomplished by tightly coupling IPP semantics to HTTP. The "fleshing out" of a formal proposal that details Roger and Keith's design would (IMHO) duplicate alot of what HTTP is already providing. Not that one way is any better than the other, but like what was suggested by someone in an earlier protocol telecon, "Do we want to create another protocol that is 80-100% semantically equivalent to HTTP?" I think chunking of a multipart message could be done effectively, similar to what Steve Zilles and I were discussing at the last telecon, and the feature of being able to return intermediate status between "SendDocument" operations could be provided by allowing clients to send jobs using multiple POST operations. Like I mentioned earlier, I will have a document that references these mechanisms, and references how Bob Herriot's proposal would have to change if we were to be HTTP 1.1 compliant. I will have this document out by the end of the day (today, Friday). Randy Keith_Carter@aussmtp.austin.ibm.com wrote: > > Roger deBry and I want to propose a change to the IPP Model that > delineates job and document boundaries through IPP operations rather than > relying on an underlying protocol to do so. In our opinion, recent email > has indicated that chunking and multi-part MIME will complicate IPP > implementations. We believe using IPP operations will simplify IPP > implementations. We would like to discuss this proposal at the IPP Model > call on Friday, May 2. > > Rather than write alot of words at this point, here is an example of > submitting a job with 3 documents. The first document, DOC1, uses > multiple writes to send to the Printer. The second document, DOC2, is a > reference to a URL. The third document, DOC3, can be sent in single > write. > > CreateJob (Printer URL, job-template attributes and values) > SendDocument (Job URL, document-name=DOC1, document-part=first, > data-length=500, ) > SendDocument (Job URL, document-name=DOC1, document-part=middle, > data-length=500, ) > SendDocument (Job URL, document-name=DOC1, document-part=middle, > data-length=500, ) > SendDocument (Job URL, document-name=DOC1, document-part=last, > data-length=150, ) > SendDocument (Job URL, document-name=DOC2, document-URL=) > SendDocument (Job URL, document-name=DOC3, document-part=only, > data-length=100, ) > EndJob (Job URL) > > CreateJob is the operation suggested in proposals from Randy Turner and > Bob Herriot. SendDocument and EndJob are new operations. > > For SendDocument, the document-part attribute allows an IPP Client to > specify the part of the document data that is being sent as follows: > > first = first set of data sent for a document > middle = set 2 to n-1 of data sent for a document > last = last set (n) of data sent for a document > only = only set of data sent for a document > > document-part=first must be paired with document-part=end. > document-part=middle is optional but can only be sent after > document-part=first and before document-part=last. document-part=only > can be sent once per document object. document-part=only cannot be sent > between document-part=first and document-part=last. > > The benefits of this proposal are as follows: > > 1. An IPP Server can easily distinguish document boundaries based > on a standard Model operation. > 2. An IPP Server can easily distinguish end-of-job based on a standard > Model operation. > 3. An IPP Server has the opportunity to respond with status at several > points throughout the transmission of a job (i.e. provide status > in the response to SendDocument and EndJob). > 4. The IPP Operations map more easily to APIs that IPP Applications > might use to submit IPP requests. > > If the IPP working group agrees with this proposal, then Roger and/or I > will write a more thorough description for the IPP Model spec which the > IPP working group can subsequently review. > > Enjoy, > > Keith -- Randy Turner Network Architect Sharp Laboratories of America rturner@sharplabs.com From ipp-archive Fri May 2 15:54:55 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA28997 for ipp-outgoing; Fri, 2 May 1997 15:51:43 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 02 May 1997 13:51:13 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - CHANGE!! 5/2 telecon Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I just recevied an emergency call from the telecon company. Due to hardware problems, they needed to move the call in number. The new number is: 888-208-1811 code: 333570 5/2/97 2:00 Moutain If you call the old number, you will get a message to call some other number which will then get you the new number. Oh well.... 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 May 2 15:54:55 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA28883 for ipp-outgoing; Fri, 2 May 1997 15:49:59 -0400 (EDT) Date: Fri, 2 May 1997 15:50:15 -0400 (EDT) From: JK Martin Message-Id: <199705021950.PAA09282@uscore.underscore.com> To: moore@cs.utk.edu Subject: Re: IPP>PRO - http comments Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Keith, Thanks for raising these questions. It's time we started answering them, too, IMHO. I fully understand the desire of the printer industry to address the global potential for Internet-based printing, particularly the "pay for print" markets. I also understand the desire for a general--but often oversimplified--feature to replace certain fax applications by Internet-based printing. Where I get a bit concerned is that it seems as if intranet printing is getting shoved into the backseat (or even the trunk) in all of this. Thinking back to the IETF BOF in San Jose last December, perhaps this concern was also shared by the many folks who simply wanted to extend and better standardize the LPD protocol (RFC 1179). To be sure, an HTTP-based printing protocol could be used within the general intranet environment. However, it certainly is not necessarily the more optimum approach with regard to resources and performance. Using a non-HTTP printing protocol should not in any way preclude the use of HTTP and other typical Web technologies to improve the overall printing environment. As we dive deeper and deeper into the HTTP-compatible IPP protocol, things are getting murkier and murkier. The complexities we have already stumbled upon barely justify the effort given the level of capabilities defined, not to mention the complexities we have yet to encounter. Our company has had the opportunity to use a clean and *simple* network printing protocol to effect feature-rich, high-performance in intranet environments. That protocol provides virtually all features and capabilities currently defined in IPP...and yet has been proven in the field for some 10 years now. I am curious how many people out there would be willing to consider the definition of a leaner, meaner network printing protocol for use in intranet environments. Such a protocol would not necessarily be targeted as a replacement for the current IPP work; rather, it would be conducted in parallel to that work, and leverage the basic model and operational aspects defined thus far. Any interest out there? ...jay PS: Has anyone ever asked Netscape how much effort would be involved in adding a new standard protocol to their browser technology? ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- ----- Begin Included Message ----- >From ipp-owner@pwg.org Thu May 1 21:48 EDT 1997 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert.Herriot@eng.sun.com (Robert Herriot) cc: ipp@pwg.org, http-wg@cuckoo.hpl.hp.com, moore@cs.utk.edu Subject: Re: IPP>PRO - http comments Date: Thu, 01 May 1997 21:43:28 -0400 > We seem to have a wide variety of beliefs about how Content-Length > and boundary strings interact when a part of a multipart/* contains a > Content-Length. I prefer the behavior described by the last > email in this series. But this exchange shows a lack of consensus. > Can we reach consensus, or this an email versus HTTP difference in > behavior? This whole exchange is a good illustration on why I'm opposed to the reuse of HTTP/1.1 for non-web applications, including a printing protocol. HTTP/1.1 is a real mess. MIME is also a real mess. They are messy because they needed to be backward compatible with a widely deployed installed base, while adding new features not anticipated for in the original protocol design. Any new printing protocol will have its own baggage also. Should it then inherit additional baggage from HTTP and MIME? Being able to print from a web browser would be a Good Thing, but I seriously question whether it's worthwhile to standardize this interface. Printer shops are going to need to add their own front-ends anyway, for queueing and to add additional services not supported directly by a printer. It would be far better to define a new protocol which doesn't inherit the baggage of HTTP/1.1. The "baggage" isn't the amount of code required to implement the protocol, it's the difficulty in dealing with lots of protocol variants -- caused by multiple earlier versions with ill-defined specifications, as well as future changes to HTTP -- and the resulting lack of interoperability and increased testing/support costs. (not to mention the overhead of having arguments about whether Content-Length is valid within a multipart content which is carried over HTTP.) It seems like the lpr problem all over again, only worse. (Except that the one thing "right" about the lpr protocol design is that it's framing protocol is almost foolproof -- a byte count followed by that many bytes.) Do you really want to burn HTTP/1.1 and MIME support into printer ROMs? Why not use something which is simpler and easier to get right? Keith p.s. Use of Content-Length *within* a multipart (as opposed to the top level) seems like a huge design botch precisely because it begs the question of what happens if Content-Length is wrong (as it often is). If there's really a good reason for using it within a multipart, I'd like to know about it. ----- End Included Message ----- From ipp-archive Fri May 2 16:09:54 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA00068 for ipp-outgoing; Fri, 2 May 1997 16:08:26 -0400 (EDT) From: Roger K Debry To: Subject: IPP>MOD - 5/2 call Message-Id: <5030100002159698000002L082*@MHS> Date: Fri, 2 May 1997 16:10:34 -0400 Mime-Version: 1.0 Content-Type: text/plain; name="MEMO 05/02/97 16:08:18" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Classification: Anyone else having problems connecting to today's call? I can't get in. I vene asked the operator to call the number, but she said the call is going through, just nothing happening at the other end. Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-archive Fri May 2 16:50:23 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA00819 for ipp-outgoing; Fri, 2 May 1997 16:43:08 -0400 (EDT) Message-Id: <3.0.1.32.19970502133930.01093748@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 2 May 1997 13:39:30 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - PING for IETF in Munich Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO It is time to start booking your trips if you want to attend the IETF meeting in Munich on August 11 - 15. Please PING me informing me if you plan to attend the IPP meeting there. 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 May 2 18:09:54 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA01578 for ipp-outgoing; Fri, 2 May 1997 18:09:09 -0400 (EDT) Message-Id: <9705022209.AA04305@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, 2 May 1997 15:07:02 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Updated list of IPP attributes and tags Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Bob Herriot updated the table of IPP attributes and tags using revison marks. Again, the list is for the 2.0 Model document and needs to be updated with the current Model group agreements. I suggest that this table should be kept up to date and included in the Model document. The columns can be changed from tags to the xxx-yyy attributes where each yyy is a different column. This table will be a good work sheet for us and will help the reader understand all the attributes at a glance. ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ -rw-r--r-- 1 pwg pwg 21504 May 2 22:04 ippatt20.doc -rw-r--r-- 1 pwg pwg 22357 May 2 22:04 ippatt20.pdf Tom From ipp-archive Fri May 2 18:14:56 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA01601 for ipp-outgoing; Fri, 2 May 1997 18:12:11 -0400 (EDT) Date: Fri, 2 May 1997 15:09:14 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705022209.PAA17718@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD thoughts on proposal from Roger and Keith X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO For the SendDoc operation, we agreed to use a byterange-like parameter to indicate when the document was complete. I suggest we use a similar mechanism for the document instead of a boolean for last document. Then, each document is numbered, starting at 1 and may optionally include the total number of documents. The last document must contain the total. When the number equals the total, the server knows that the last document is being received. Having such a number provides more useful information than a boolean and this information may prove useful in the future. Bob Herriot From ipp-archive Fri May 2 18:14:57 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA01622 for ipp-outgoing; Fri, 2 May 1997 18:12:45 -0400 (EDT) From: npham@nectech.com Mime-Version: 1.0 Date: Fri, 2 May 1997 15:06:22 -0400 Message-ID: <000B2E99.3125@nectech.com> Subject: Re: UPD> Re: IPP> Proposed Agenda for the IPP meeting in San Cc: ipp@pwg.org, upd@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: bulk Status: RO How do I get information about upcoming meeting Schedule. Nick Pham NEC Technologies, Inc. ______________________________ Reply Separator _________________________________ Subject: UPD> Re: IPP> Proposed Agenda for the IPP meeting in San Die Author: JK Martin at SMTP Date: 5/2/97 2:59 PM Carl-Uno, Based on the private mail sent to me regarding interest in the new Universal Print Driver concept, it would appear that many folks would like to spend more than a few minutes on the topic in San Diego. And, based on the current work, the IPP will need as much time as possible in San Diego *without* going into the UPD stuff. I'll be posting a more formal message to the UPD list in the next few minutes regarding what appears to be the best plan, but I don't think UPD should take any of the precious time currently allotted to the IPP. Hopefully no one has a problem with this. ...jay ----- Begin Included Message ----- >From ipp-owner@pwg.org Fri May 2 14:45 EDT 1997 Date: Fri, 2 May 1997 11:15:57 PDT To: ipp@pwg.org, groberts@rinc.ussj.ricoh.com From: Carl-Uno Manros Subject: IPP> Proposed Agenda for the IPP meeting in San Diego on May 15 Proposed Agenda for the PWG IPP meeting in San Diego on May 15 8:30 - 12:00 am Discussion about options for the IPP Protocol This will include a presentation and demonstration from Microsoft and HP 1:00 - 5 pm Discussion about how the Prototyping efforts could support the protocol choices Discusion of IPP Security Discussion of the Universal Print Driver (this is expected to later become a separete activity within the PWG) ---- Comments, please, e.g. do we need to have any time for Model considering that there will be a full day meeting on that subject on May 14. BTW, for those of you planning to attend that meeting, do not forget to notify Patrick Powell. So far he has only got a handfull of names! 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 ----- End Included Message ----- From ipp-archive Fri May 2 18:35:58 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA03108 for ipp-outgoing; Fri, 2 May 1997 18:31:43 -0400 (EDT) Message-Id: <3.0.1.32.19970502152805.010a92f0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 2 May 1997 15:28:05 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Re: complaint from Keith Moore on press release Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I have sent the following reply to Keith and Harald concerning our use of company names in the Printer Working Group press release. I did not bother to include the WinWord attachment with this copy, but it was sent to Keith and Harald. They may refuse to read it or it might get dropped by their email software, but I wanted to give them the real original in this case, not an ASCII version in which the PWG banner could be included. Carl-Uno ----- Keith, I am seriously sorry and worried that this has upset people in the IETF, it was certainly not intended. A few remarks to our defense: 1) We discussed your comments in one of our conferences, and it was suggested that if the press release was clearly labeled as coming from the PWG, giving their view and comments about the IPP project, we would not violate any IETF rules. All distributed copies to the media had a big logo stating that this was issued by the PWG. I now realize that it was a mistake not to inform you personally and explicitly, rather then relying on your reading what comes out on the IPP DL. I have attached a copy of the exact text that was distributed to the media (hope you have some means of reading an MS Word document), so that there is nothing unclear about the exact content. 2) There were a number of further drafts after April 17, distributed for review on the IPP list. Why did you not speak up, if you noticed that your comments had not been taken into account properly? 3) What is the difference between a particular company putting out a press release about supporting a particular IETF project and the PWG (as a group of cooperating vendors) doing the same? A lot of such press releases including company names appear all the time. A recent example was a press release from Novell on IPP a couple of weeks ago, which was published on the IPP DL. 4) A general observation about the policy not to mention company names is that it does not seem to be applied in practise, even in IETF sanctioned publications. How do you explain that not only author names, but also the company or organisations they belong to are mentioned on the front page of every RFC? On the IETF WG mailing lists, people usually have a signature that in most cases contain their organisation, phone number etc. Should that also be forbidden? I am willing to take on the cost of sending out a correction to the press release, but we would like you to draft the text. Especially if you want it out by May 6, there is not a lot of time for sending drafts backwards and forwards. We should need your draft on the IPP DL by Monday morning, so that people in the WG have a chance to see it and comment, before it gets distributed. FYI, we spent about 3 weeks to reach agreement on the earlier release. Concerning the Web pages, I want you to give a few concrete examples. There might be some older documents on our FTP site, from the time before we were established as a WG, that might fall under the category you mentioned, they could simply get deleted (or have access restricted to the members of the PWG). I cannot commit to go through all our documents on the Web site for possible re-editing by May 6. That is unreasonable, people in this project are working very hard and should not have to give up their week-end to do this. This is not unwillingness, it is just realism. Also, you have not given us any earlier indications that anything on our Web site was not in order. Actually, I just received the following message from our web editor in response to your message: ------- A quick check of the Web pages shows that other than the press release itself there was only one place a company name was used: next to the name of the Web page maintainer ("Jeffrey L Copeland at QMS, Inc."). That was there to keep me from getting confused with the Jeffrey Copeland at Systemhouse, but I've removed it anyway. As a stop-gap for the press release problem, I've removed the references to it on the web page. As soon as there's a fix for the release itself, I'll put the new one up. ---- Even though it seems that your latest message and directions are a slight overreaction, I can assure you we will do our best to comply - within reason. Regards, Carl-Uno IPP WG co-chair 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 May 2 18:39:58 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA03547 for ipp-outgoing; Fri, 2 May 1997 18:39:36 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 02 May 1997 16:39:26 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - 5/2 call mintues Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I posted ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/minutes/970502-model-minutes.txt Below the text is included: Minutes of the 5/2/97 Model Teleconference 2-4 pm Mountain Attendees: Roger deBry Jim Walker Jay Martin Scott Isaacson Peter Zehler Keith Carter Tom Hastings Bob Herriot Note taker: Scott Isaacson Agenda 1. Mandatory attributes were proposed in the 2.1 version of the document. There has been no comment on these. Review, and comment. 2. Since we are getting rid of tags, it is not acceptable to live with the ambiguity as clarified by Tom in last weeks minutes. That is xxx-supported values are: 1) client desires to override the PDL (the same instruction is in the PDL) or 2) client desires action only when the information is not in the PDL. This was once being solved by the embedded and embedded-only tags. Since we have no tags, the proposal is to define a set of xxx-capable attributes to go along with the xxx-supported attributes. Jim Walker took an action item to write this up can clarify semantics of xxx-supported, xxx-capable and best-effort and embedded instructions in PDL. 3. compression is currently in the Job Templates section. It makes no sense to have a "default" compression value as a printer attribute. 4. There is some value to have a document-format default attribute at the printer object. Bob suggested the reason, but I lost it in my notes. 5. We do not need a number-of-documents-completed attribute. 6. locale-supported will go into the operation headers rather than be negotiated as a Printer attribute. 7. scheduling-algorithm stays but it is single valued (it is not scheduling-alorithms-supported which can come later). 8. We reviewed Keith and Roger's proposal. Seems to be general agreement to move the multiple write operations up into the model document. Jim suggested that if we do, we need to consider a new state that shows the "being built" nature of the job rahter than just relying on a printer-state-reason of incomplete. However, it was pointed out, this suggestion is independent of the new operations proposal and applies to the existing model semantics as well. New issue: Should we have an additional job state? In reviewing the propsal, it became clear that this protocol could use byte ranges rather than "first", "middle", "last", "only" in order to help with some sending recovery problems (you get to the second to last packet of a 5 Mb job and have to start over if there are no byte ranges at all). Rules are: ranges must be in order (no gaps) but ranges can overlap (backwards). Each range has a FIRST, LAST, TOTAL. Total must be given on the last packet. It may be given on non last packets, and if it is, it could go up on the next packet but never down. If it is not known, it need not be given. By definition, when last == total (take into account 0 indexing) then it is the last packet for a document. Valid Examples First-Last, Total Example 1: 0-99 100-199 200-299,300 Example 2: 0-99 80-199 200-299,300 Example 3: 0-99,300 100-199,300 200-299,300 Example 4: 0-99,200 100-199,250 200-299,300 Example 5: 0-99,100 Invalid examples Example 1: 0-99 200-299 100-199,300 Example 2: 0-99,150 100-124,125 Example 3: 0-99,150 There was a suggestion to use a "last doc" flag in the send-doc rather than introduce a whole new end-job operation. 9. We are waiting for more work from the security team. 10. We do not need to introduce a read/write tag now (in order to be ready for future modify operations) since a simple work around could be introduced later which is an attribute which is a list of writeable attributes. The assumption NOW is that no attributes are writable. 11. Don Fullman at Xerox put together a table showing the relationship of tags to attributes. This table will become something like: xxx xxx-supported (Y/N), xxx-capable(Y/N), xxx-available(Y/N), etc. 12. To fix Tom's notes from last week, there is no xxx-ready proposed. Just an optional xxx-available. If xxx-supported is multi-valued, then so it xxx-available. For each value in xxx-supported, there is a corresponding value in xxx-available, which shows is state of readiness. If xxx-available is not implemented, then all xxx-supported values are assumed to be ready. Scott From ipp-archive Fri May 2 19:24:56 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA04139 for ipp-outgoing; Fri, 2 May 1997 19:20:26 -0400 (EDT) Message-Id: <3.0.1.32.19970502161656.010b41a8@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 2 May 1997 16:16:56 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - PC Week Report on IPP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO The responses on the PWG press release have started appearing. You can find out what it contains on URL: http://www8.zdnet.com/pcweek/news/0428/01eipp.html Unfortunately, they describe the IPP project as a vendor group being charted by the IETF, which is obviously incorrect, something that was never stated in the press release, but this is probably the kind of reporting that has caused Keith Moore to get up on the barricades. Have you ever tried to get a jounalist to accept exactly what you tell them, without them trying to improve the story? 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 May 2 20:25:00 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA04783 for ipp-outgoing; Fri, 2 May 1997 20:21:24 -0400 (EDT) Message-Id: <3.0.32.19970502172147.006c5940@pop3.fapo.com> X-Sender: lstein@pop3.fapo.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 02 May 1997 17:22:36 -0700 To: P1284_3@lexmark.com, p1394@pwg.org, ipp@pwg.org, pmp@pwg.org From: Larry Stein Subject: IPP> Meeting Charges for San Diego Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Sorry for the multiple postings, but I wanted to have the best chance of getting to everyone. The meeting charges for the IEEE P1284.x, IPP, 1394PWG, JPM and PWG meetings will be $30.00 per person per day. This includes the meeting room rentals, AV, continental breakfast, and AM/PM breaks. If you are staying at the Marriott this will be charged to your room. If not, then please bring a check or cash. The Marriott may be able to take credit cards for the charges. Thank you, Larry Stein ***************************************************************************** Larry A. Stein Phone: (619)292-2740 Warp Nine Engineering Fax: (619)292-8020 Web: http://www.fapo.com ***************************************************************************** From ipp-archive Fri May 2 20:39:56 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA05622 for ipp-outgoing; Fri, 2 May 1997 20:36:37 -0400 (EDT) Date: Fri, 2 May 1997 17:33:43 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705030033.RAA19075@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO teleconference, Monday May 5 10am-12noon PDT X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO There will be a Monday teleconference call for the IPP protocol group. dates: April 28, May 5, 12 and 19. 10am-12noon PDT. phone number: 415-547-4810 password: 2808413 Agenda: discuss proposal from Roger and Keith about SendDocument operation discuss Randy's comparison document (if anyone receives it in time to read) any further comments on the current IPP protocol proposal. From ipp-archive Fri May 2 22:44:57 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA06473 for ipp-outgoing; Fri, 2 May 1997 22:42:52 -0400 (EDT) Message-Id: <1.5.4.32.19970503024348.006ce07c@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: Fri, 02 May 1997 19:43:48 -0700 To: moore@cs.utk.edu, hta@uninett.no, pwg@pwg.org From: Carl-Uno Manros Subject: IPP> More about your objections to the PWG Press Release Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Keith, I need to make a couple of corrections to my earlier message. You need to send your message with proposed text for the press release correction to the main list of the PWG which is: pwg@pwg.org as this concerns the whole PWG as an organization, which you try to put a muzzle on. I suggest however, that you also copy it to ipp@pwg.org as they are obviously interested. If you want, we can restrict discussion of this subject to the PWG list rather than to the IPP list, but it means that you also need to subscribe to that list, if you want to follow the discussion. BTW, that list follows the rules and accepted behaviour of the PWG. Another detail. I have accepted to send out the correction, but I want the text to be short enough to fit on a single page, including the name and fax address; after all you are not the one paying for it. Alternatively, I can give you the list and you can issue your own press release. Regards, Carl-Uno From ipp-archive Sat May 3 11:00:05 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA11485 for ipp-outgoing; Sat, 3 May 1997 10:58:10 -0400 (EDT) Date: Sat, 3 May 1997 07:57:16 -0700 (PDT) From: Patrick Powell Message-Id: <199705031457.HAA09985@dickory.sdsu.edu> To: lawrence@agranat.com, masinter@parc.xerox.com Subject: Re: IPP> Re: MIME multipart/* vs HTTP Cc: http-wg@cuckoo.hpl.hp.com, ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I have been trying to pick up the thread of the discussion about HTTP chunked transfers, and am a little puzzled. I pulled out the HTTP/1.1 reference, section 3.5 and 3.6; this dicusses transfer-codings. Here is the excerpt from the standard: # .6 Transfer Codings # Transfer coding values are used to indicate an encoding # transformation that has been, can be, or may need to be applied to an # entity-body in order to ensure "safe transport" through the network. # This differs from a content coding in that the transfer coding is a # property of the message, not of the original entity. # transfer-coding = "chunked" | transfer-extension # transfer-extension = token # All transfer-coding values are case-insensitive. HTTP/1.1 uses # transfer coding values in the Transfer-Encoding header field (section # 14.40). # Transfer codings are analogous to the Content-Transfer-Encoding # values of MIME , which were designed to enable safe transport of # binary data over a 7-bit transport service. However, safe transport # has a different focus for an 8bit-clean transfer protocol. In HTTP, # the only unsafe characteristic of message-bodies is the difficulty in # determining the exact body length (section 7.2.2), or the desire to # encrypt data over a shared transport. # The chunked encoding modifies the body of a message in order to # transfer it as a series of chunks, each with its own size indicator, # followed by an optional footer containing entity-header fields. This # allows dynamically-produced content to be transferred along with the # information necessary for the recipient to verify that it has # received the full message. # ielding, et. al. Standards Track [Page 24] # FC 2068 HTTP/1.1 January 1997 # Chunked-Body = *chunk # "0" CRLF # footer # CRLF # chunk = chunk-size [ chunk-ext ] CRLF # chunk-data CRLF # hex-no-zero = # chunk-size = hex-no-zero *HEX # chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-value ] ) # chunk-ext-name = token # chunk-ext-val = token | quoted-string # chunk-data = chunk-size(OCTET) # footer = *entity-header # The chunked encoding is ended by a zero-sized chunk followed by the # footer, which is terminated by an empty line. The purpose of the # footer is to provide an efficient way to supply information about an # entity that is generated dynamically; applications MUST NOT send # header fields in the footer which are not explicitly defined as being # appropriate for the footer, such as Content-MD5 or future extensions As I see this, the length of the data is specified as part of the transfer. This means that you do not have to worry about the content, etc. What am I missing in this discussion? Patrick Powell From ipp-archive Sat May 3 15:25:08 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA13599 for ipp-outgoing; Sat, 3 May 1997 15:23:57 -0400 (EDT) Date: Sat, 3 May 1997 12:21:51 -0700 (PDT) From: Patrick Powell Message-Id: <199705031921.MAA10901@dickory.sdsu.edu> To: cmanros@cp10.es.xerox.com, ipp@pwg.org Subject: Re: IPP> ADM - PC Week Report on IPP Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Press and Press Releases: My late father was (at various times) Associate Editor and City Desk editor of several major papers. His usual comment about 'getting things right' was: "If we spell your name right, don't mention you were drunk, and don't tell them about your (mistress/graft/unpaid parking tickets) then consider yourself a lucky man." I don't think things have changed much in the journalism world... :-) Patrick ("And you left MY name off the list!") Powell From ipp-archive Sat May 3 16:40:09 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA14420 for ipp-outgoing; Sat, 3 May 1997 16:38:37 -0400 (EDT) From: Harry Lewis To: Subject: IPP> misleading press release issued by IPP WG Message-Id: <5030100002179318000002L082*@MHS> Date: Sat, 3 May 1997 16:40:35 -0400 Mime-Version: 1.0 Content-Type: text/plain; name="MEMO 05/03/97 16:36:11" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Classification: Keith, I respect your position as IETF area director. I think you are overstepping boundaries, however, when you request the PWG modify their web page. This is a PWG web page, not IETF. Does the IETF have difficulty accepting that industry consortia may exist who wish to seek charter for various projects, some that fall under jurisdiction of the IETF? Does the IETF mandate that another organization relinquish it's identity when it interfaces with the IETF? What purpose would this have? Please recognize that IPP is a project within the PWG as well as a charter within the IETF. I know it probably doesn't matter, but I seem to recall member companies being quoted in press during creation of the Printer MIB while we were chartered with the IETF. Past mistakes should not be used to set precedence, but, perhaps this is why Don felt it was ok to mention the companies. By the way, can you explain the reasoning behind a policy that accommodates the Company Name for the author of an Internet Draft, yet prohibits the calling out of companies participating in a sanctioned standards seeking work effort? Harry Lewis - IBM Printing Systems ------ Forwarded by Harry Lewis/Boulder/IBM on 05/03/97 02:19 PM ------- >The IPP WG is hereby directed to issue a correction to its earlier >press release, to be sent to the same contacts as the original press >release, which clearly explains that IETF participants are individuals >rather than vendor representatives. >The WG is further directed to change its web pages and ftp site so >that any mention of vendor participation in the IPP WG or IETF is >changed to refer to individual participation only. From ipp-archive Sat May 3 19:25:12 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA15721 for ipp-outgoing; Sat, 3 May 1997 19:20:29 -0400 (EDT) Message-Id: <9705032320.AA04557@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: Sat, 3 May 1997 16:18:21 PDT To: Harald.T.Alvestrand@uninett.no From: Tom Hastings Subject: Re: IPP> MOD - Suggestion: add RequiredResources call to Windows GDI to help drivers emit IPP job submission input parameters Cc: Babak Jahromi , ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Harald, Sorry, I missed this e-mail. Tom At 06:24 04/05/97 PST, Harald.T.Alvestrand@uninett.no wrote: >Tom, >naive question: >Does the IPP print model have to include the possibility of the first >portion of the document being printed before the request is completely >sent to the printer? We want to allow IPP to be implemented in a printer that doesn't have to spool the data before starting to print. In other words, we want to allow IPP to be used by simple desktop printers. Unfortunately, this does require that resources be declared up front, not at the end. In fact we now have a lot of experience with job submission protocols that allow the job parameters to be at the end: LPD - the control file is usually written after the data file, so that desktop printers have already printed most of the data before getting the control file and discovering that it was supposed to be two-sided, or was supposed to use the transparencies medium. That is one major reason that we cannot use LPD in this effort. PostScript - PostScript as an AtEnd feature which is used for declaring fonts and media. A Windows Print driver has no choice but to use this AtEnd feature, since the windows print driver is fed GDI a page at a time and has to produce the PDL as it goes. Hence the suggestion in the original mail message to allow the application (which know all the resources that will be needed before starting to make the GDI calls to print the document) to pass on this valuable information to the Print Driver in a new GDI call. We need to put some kind of architecture assumptions into IPP along the lines that IPP requires resource and job level parameters to be specified first in the protocol, so that the recipient can act upon them for getting all of the data. This does put a minor burden on clients, but is not too difficult if the requirement is known to the client implementors. NOTE- This requirement that the job parameters be first before the document data is not just for desktop printers that don't spool. As IPP gets used for "print-by-reference", where the document data is only a reference to a document, such as a URL, the job parameters have to be specified separately from the document data anyway. A Printer (object) that controls multiple output devices may want to know ahead of time about the job parameters. Perhaps the output device is going to pull the actual data. Also many systems support multiple document formats (PDLs), so that having the job parameters be separate and in a PDL-independent representation will help such systems that would like to avoid having to parse the PDL data twice: once looking for resources and a second time to produce the hardcopy. Tom > >If not, why not design the protocol so that resource requirements can >be attached to the *end* of the print request? Been there, done that. Don't want to repeat such mistakes. > >OTOH, I personally think that it would probably be better in version >1.0 to take the "do or die approach": let the human or driver negotiate >some resources (like A4 paper) up front, and then the job either prints >or crashes. Just make sure the error report is right..... There's no >way I can think of where one can negotiate on *every* resource one >can think of - for instance, some *ancient* PostScript printers allowed >you to put 68000 machine code into PostScript files; do you want to >include negotiation on the CPU type in the printer? Certainly not. > >KISS..... We agree. The hard part is deciding for which party to make it simple: the client or the server/printer. Requiring job parameters to be first is a little harder for the client (than allowing the client to put them last), but make a hugh simplication for the server/printer. So the net is much simpler to require job parameters to precede document data. > > Harald A > > From ipp-archive Sun May 4 00:00:13 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA17670 for ipp-outgoing; Sat, 3 May 1997 23:58:45 -0400 (EDT) Date: Sat, 3 May 1997 23:54:41 -0400 (EDT) From: JK Martin Message-Id: <199705040354.XAA12478@uscore.underscore.com> To: hastings@cp10.es.xerox.com Subject: Re: IPP> MOD - Suggestion: add RequiredResources call... Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Tom, You've done a great job in describing your position in your response to Harald on this topic. It wasn't until I read your fine posting that it finally dawned on me where I was having some problems with the directions the IPP was taking. It is possible to describe any one of the vast majority of today's printing systems as having one of the two following models: Model A: client ---> printer Model B: client ---> spooling server ---> printer Where I think IPP gets into real trouble is that it tries to achieve these goals simultaneously: 1. Provide all printing features required by 99% of the world's population; 2. Assure that all such defined features can be implemented in a desktop printer costing $150 ($119.99 at Wall-Mart); 3. Make all of this happen by mid-1997. How many times have we heard statements like: "We can't go that route, it's not possible in a desktop printer." Seems like we had better come to grips with the possibility where IPP should only attempt to address "Model B" above; then, as hardware technology decreases in price, allow desktop printers to catch up. That is, let IPP address the "client ---> spooling server" portion of the model, and develop a cheap, simple, and fast protocol to deal with the "spooling server ---> printer" side of the model. Sure, one could take sufficient time and resources and ultimately define a printing approach that scales from my mother's direct-attached ink-jet printer all the way up to the 200+ page-per-minute laser screamers in Fortune 10 companies, but the age-old question arises: "Why?" Just because you CAN do something doesn't mean you necessarily SHOULD. My company has plenty of experience with large Enterprises using LPD on every type of client in the Enterprise--including Windows 3.1--that feed large spooling servers. These servers then use a plethora of protocols to effect the print jobs on a wide variety of both network and direct-attached (serial/parallel) printers. And you know what? Those companies are crying for a standard protocol to talk to the printers. Lack of features on the client side is not even on the horizon for them. One last thing: >>KISS..... > >We agree. The hard part is deciding for which party to make it simple: >the client or the server/printer. It's starting to look like NEITHER side is going to be simple. And I really believe that at least one side CAN be simple...if we step back and re-evaluate some of the directions we've been taking. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-archive Sun May 4 04:35:16 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA20247 for ipp-outgoing; Sun, 4 May 1997 04:31:57 -0400 (EDT) Message-ID: <336C49CF.B81A4CB5@sharplabs.com> Date: Sun, 04 May 1997 01:33:19 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Laboratories of America X-Mailer: Mozilla 4.0b3 [en] (Win95; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> Document available...(finally) X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I have posted a new document to the PWG FTP server: ftp:://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipphttp_rt.doc It describes some HTTP 1.1 compliance-related issues and updates some of the mapping techniques described in my earlier internet-draft. Randy From ipp-archive Sun May 4 12:15:20 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA22448 for ipp-outgoing; Sun, 4 May 1997 12:11:45 -0400 (EDT) Date: Sun, 4 May 1997 09:09:44 -0700 (PDT) From: Patrick Powell Message-Id: <199705041609.JAA11613@dickory.sdsu.edu> To: Harald.T.Alvestrand@uninett.no, hastings@cp10.es.xerox.com Subject: Re: IPP> MOD - Suggestion: add RequiredResources call to Windows GDI Cc: babakj@microsoft.com, ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk Status: RO # > # >If not, why not design the protocol so that resource requirements can # >be attached to the *end* of the print request? # Been there, done that. Don't want to repeat such mistakes. I have also been there, done that, and I agree: - Put the format/options/job control/etc first - have a negotiation protocol, not just 'blast the job and see if it prints' protocol # > # >OTOH, I personally think that it would probably be better in version # >1.0 to take the "do or die approach": let the human or driver negotiate # >some resources (like A4 paper) up front, and then the job either prints # >or crashes. Just make sure the error report is right..... There's no # >way I can think of where one can negotiate on *every* resource one # >can think of - for instance, some *ancient* PostScript printers allowed # >you to put 68000 machine code into PostScript files; do you want to # >include negotiation on the CPU type in the printer? # Certainly not. There is a fine dividing line on this problem. I think that there should be some ability to 'find' printer characteristics, but some of these should not be 'hardwired' into the spec, i.e. - format. The current approach seems to be very very sane- have 'resources/attributes' with fixed 'key/tag' values, and then have some 'text' based ones which can have a 'non-fixed' text format. This allows you the best of both worlds. You could put 'manufacutuers information' in the text format. # > # >KISS..... # We agree. The hard part is deciding for which party to make it simple: # the client or the server/printer. Requiring job parameters to be first is a # little harder for the client (than allowing the client to put them last), # but make a hugh simplication for the server/printer. So the net is much # simpler to require job parameters to precede document data. I want to have the server as simple as possible. That way the chances of having it done 'RIGHT' and 'UNIFORMLY' and 'CONSISTENTLY' by multi-leben-dozen different manufacturers goes up tremendously. The less things to mess up the more likely it will get done right. Patrick Powell # > # > Harald A --JAA11549.862761798/dickory-- From ipp-archive Sun May 4 12:40:20 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA22974 for ipp-outgoing; Sun, 4 May 1997 12:38:56 -0400 (EDT) Date: Sun, 4 May 1997 08:39:13 -0700 (PDT) From: Patrick Powell Message-Id: <199705041539.IAA11524@dickory> To: Harald.T.Alvestrand@uninett.no, hastings@cp10.es.xerox.com Subject: Re: IPP> MOD - Suggestion: add RequiredResources call to Windows GDI to help drivers emit IPP job submission input parameters Cc: babakj@microsoft.com, ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk Status: RO # > # >If not, why not design the protocol so that resource requirements can # >be attached to the *end* of the print request? # Been there, done that. Don't want to repeat such mistakes. I have also been there, done that, and I agree: - Put the format/options/job control/etc first - have a negotiation protocol, not just 'blast the job and see if it prints' protocol # > # >OTOH, I personally think that it would probably be better in version # >1.0 to take the "do or die approach": let the human or driver negotiate # >some resources (like A4 paper) up front, and then the job either prints # >or crashes. Just make sure the error report is right..... There's no # >way I can think of where one can negotiate on *every* resource one # >can think of - for instance, some *ancient* PostScript printers allowed # >you to put 68000 machine code into PostScript files; do you want to # >include negotiation on the CPU type in the printer? # Certainly not. There is a fine dividing line on this problem. I think that there should be some ability to 'find' printer characteristics, but some of these should not be 'hardwired' into the spec, i.e. - format. The current approach seems to be very very sane- have 'resources/attributes' with fixed 'key/tag' values, and then have some 'text' based ones which can have a 'non-fixed' text format. This allows you the best of both worlds. You could put 'manufacutuers information' in the text format. # > # >KISS..... # We agree. The hard part is deciding for which party to make it simple: # the client or the server/printer. Requiring job parameters to be first is a # little harder for the client (than allowing the client to put them last), # but make a hugh simplication for the server/printer. So the net is much # simpler to require job parameters to precede document data. I want to have the server as simple as possible. That way the chances of having it done 'RIGHT' and 'UNIFORMLY' and 'CONSISTENTLY' by multi-leben-dozen different manufacturers goes up tremendously. The less things to mess up the more likely it will get done right. Patrick Powell # > # > Harald A From ipp-archive Sun May 4 13:15:20 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA23549 for ipp-outgoing; Sun, 4 May 1997 13:12:33 -0400 (EDT) X-Sender: szilles@elroy Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 4 May 1997 09:18:09 -0800 To: rturner@sharplabs.com, ipp@pwg.org From: szilles@Adobe.COM (Steve Zilles) Subject: Re: IPP> Document available...(finally) Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk Status: RO The URL that you actually posted was ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipphttp-rt.doc -------------------------------------------------------------- Stephen N. Zilles | e-mail: szilles@adobe.com | Adobe Systems Inc. | | Mailstop W14 | tel: (work) (408) 536-4766 | 345 Park Avenue | (Admin) (408) 536-4751 | San Jose, CA 95110-2704 | fax: (408) 537-4042 | -------------------------------------------------------------- From ipp-archive Sun May 4 16:20:23 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA24569 for ipp-outgoing; Sun, 4 May 1997 16:17:28 -0400 (EDT) Message-ID: <336CEEEA.2E14@sharplabs.com> Date: Sun, 04 May 1997 13:17:46 -0700 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: Steve Zilles CC: ipp@pwg.org Subject: Re: IPP> Document available...(finally) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Steve Zilles wrote: > > The URL that you actually posted was > > ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipphttp-rt.doc > Thats right. sorry. I guess that's why they DON'T call me the 'duke of URL' R. -- Randy Turner Network Architect Sharp Laboratories of America rturner@sharplabs.com From ipp-archive Sun May 4 16:20:23 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA24558 for ipp-outgoing; Sun, 4 May 1997 16:16:10 -0400 (EDT) Message-Id: <1.5.4.32.19970504201706.00668468@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: Sun, 04 May 1997 13:17:06 -0700 To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> Document available...(finally) Sender: ipp-owner@pwg.org Precedence: bulk Status: RO At 09:18 AM 5/4/97 -0800, you wrote: >The URL that you actually posted was > >ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipphttp-rt.doc > >-------------------------------------------------------------- >Stephen N. Zilles | e-mail: szilles@adobe.com | >Adobe Systems Inc. | | >Mailstop W14 | tel: (work) (408) 536-4766 | >345 Park Avenue | (Admin) (408) 536-4751 | >San Jose, CA 95110-2704 | fax: (408) 537-4042 | >-------------------------------------------------------------- > >\ FYI, I have also added .TXT and .PDF versions of the document. Carl-Uno From ipp-archive Mon May 5 04:40:31 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA26771 for ipp-outgoing; Mon, 5 May 1997 04:37:28 -0400 (EDT) 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 From: Harald.T.Alvestrand@uninett.no To: Tom Hastings cc: Babak Jahromi , ipp@pwg.org Subject: Re: IPP> MOD - Suggestion: add RequiredResources call to Windows GDI to help drivers emit IPP job submission input parameters In-reply-to: Your message of "Sat, 03 May 1997 16:18:21 PDT." <9705032320.AA04557@zazen.cp10.es.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 May 1997 10:37:32 +0200 Message-ID: <23387.862821452@munken.uninett.no> Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Frankly, I think that modifying the Windows GDI (and by extension modifying every single application that prints through Windows) is even more pie-in-the-sky than replacing every single printer in the world. There are more of those beasties than there ever were printers, and quite a few businesses that depend on software that can't be modified for one reason or another. So we've more or less settled that in the common case, there HAS to be one link in the chain that can look at both ends of the job at the same time, and understand enough about it to figure out what its requirements are. Print-by-URL is irrelevant to this discussion, since there the distinction between parameters "before the URL" and "after the URL" is pretty slim; they are both communicated to the printer before the URL is dereferenced. So - the spooler is there; just choose which side of the IPP-defined interface you want it. Harald A From ipp-archive Mon May 5 11:40:35 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA27930 for ipp-outgoing; Mon, 5 May 1997 11:37:33 -0400 (EDT) Date: Mon, 5 May 1997 11:37:58 -0400 (EDT) From: JK Martin Message-Id: <199705051537.LAA18404@uscore.underscore.com> To: ipp@pwg.org Subject: IPP> MOD - Concise table of valid attributes and associated values available? X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Has anyone generated a document that simply lists all valid attributes *and* the set of valid values for those attributes? Some of the documents in the IPP ftp new_MOD directory come close, but not quite. Also, the PWG really needs to improve the FTP site by maintaining a simple catalog of documents in any given directory. You know, a simple table where each document is listed with a summary title and filename. This would really help folks navigate our document repository. If we could come up with a simple standard catalog mechanism, we could then mandate that all authors must update the corresponding catalog when a new file is placed into a given directory. Even experienced PWG participants have a hard time finding anything very quickly, given the way filenames are assigned now. ...jay From ipp-archive Mon May 5 12:30:43 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA28641 for ipp-outgoing; Mon, 5 May 1997 12:26:01 -0400 (EDT) Message-Id: <3.0.32.19970505091959.006cebec@pop3.fapo.com> X-Sender: lstein@pop3.fapo.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 05 May 1997 09:25:26 -0700 To: P1284_3@lexmark.com, p1394@pwg.org, ipp@pwg.org From: Larry Stein Subject: IPP> Meeting Location Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO The May IEEE/PWG meetings will be held in the following rooms at the Marriott Suites: P1284.3 May 8-9 Maestro Room P1284.4 May 12-13 Maestro Room 1394PWG May 14 Symphony Bay 1&2 IPP May 15 Symphony Bay 1&2 JMP/PWG May 16 Maestro Room The weathers great in San Diego, dress casual and comfortable. -Larry ***************************************************************************** Larry A. Stein Phone: (619)292-2740 Warp Nine Engineering Fax: (619)292-8020 Web: http://www.fapo.com ***************************************************************************** From ipp-archive Mon May 5 12:30:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA28745 for ipp-outgoing; Mon, 5 May 1997 12:27:56 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 05 May 1997 10:27:39 -0600 From: Scott Isaacson To: hastings@cp10.es.xerox.com, jkm@underscore.com Cc: ipp@pwg.org Subject: Re: IPP> MOD - Suggestion: add RequiredResources call... Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Jay, You wrote: ************************************************************ 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 ************************************************************ >>> JK Martin 05/03 9:54 PM >>> > > Model A: client ---> printer > > Model B: client ---> spooling server ---> printer > ... > > Seems like we had better come to grips with the possibility where IPP > should only attempt to address "Model B" above; then, as hardware > technology decreases in price, allow desktop printers to catch up. > > ... > > That is, let IPP address the "client ---> spooling server" portion of > the model, and develop a cheap, simple, and fast protocol to deal with > the "spooling server ---> printer" side of the model. I was under the assumption that most everyone was focused on model B with a desire to not do anything explicit to preclude model A. I hope that this assumption is still valid. We need to define a job submission and control protocol that works for model B. If someday, someone happens to implement IPP directly within the output device (printer) which has a network interface card, then so much the better, but we do not force that in order for IPP to be successful. At that time, the model really becomes a single logical/architectural model: client --> IPP Printer which can be realized in many physical network configurations client --> IPP Printer (running on a general purpose network node which is probably a "computer" such as a typical file server, app server, etc.) client --> IPP Printer (running in a specialized network node called printer, multi-function device, output device, or whatever). As to "Why?" do we need to even address model A at all in our thoughts and decisions: There are implementations today (in the Novell environments specifically) where the "server" is embedded in the "printer". In this case the "server" is not a "spooling server" but a "print server". The embedded print server uses a file server for actual disk space, but all status, control, queries, and events are realized through the embedded "server" (or model A). Therefore, since model A does exist in today's market, we must address it. Having said that, I agree with you that I do not want IPP (v1.0) to become "all things to all peole with all devices by mid 1997". We should continue to focus on Model B and allow for hardware and other issues to help realize model B in within the output device (what you call model A). Also, I am interested in how you would apply real quantitative requirements to "cheap, simple, and fast" when you suggest a protocol to deal with the "spooling server ---> printer" side of the model? I am assuming that you are refering to the fact that as IPP is currently shaping up, IPP would not satisfy "cheap, simple, and fast"? I am also assuming that you are refering to an earlier email you osted about IPP protocol issues and suggestions to which I have not responded nor have I seen any other responses. Scott From ipp-archive Mon May 5 13:55:36 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA29854 for ipp-outgoing; Mon, 5 May 1997 13:55:21 -0400 (EDT) Date: Mon, 5 May 1997 13:55:33 -0400 (EDT) From: JK Martin Message-Id: <199705051755.NAA19192@uscore.underscore.com> To: SISAACSON@novell.com Subject: IPP> MOD - Base printer implementation requirements Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Scott, Thanks for replying to my message. I changed the subject line to perhaps better reflect this thread. (The subject used to be something like "MOD - Suggestion: add RequiredResources call...") > > Model A: client ---> printer > > > > Model B: client ---> spooling server ---> printer > > ... > > > > Seems like we had better come to grips with the possibility where IPP > > should only attempt to address "Model B" above; then, as hardware > > technology decreases in price, allow desktop printers to catch up. > > > > ... > > > > That is, let IPP address the "client ---> spooling server" portion of > > the model, and develop a cheap, simple, and fast protocol to deal with > > the "spooling server ---> printer" side of the model. > > I was under the assumption that most everyone was focused on model B with a > desire to not do anything explicit to preclude model A. I hope that this > assumption is still valid. We need to define a job submission and control > protocol that works for model B. If someday, someone happens to implement > IPP directly within the output device (printer) which has a network > interface card, then so much the better, but we do not force that in order > for IPP to be successful. At that time, the model really becomes a single > logical/architectural model: I reread that last paragraph several times, but still remain confused about whether you agree or disagree with my statements. Your last sentences seem to agree with my suggestion that we should let printers catch up in hardware capabilities in the future, and not worry about low-end printers today for IPP. And yet, your first statements says that the IPP group desires to "not do anything explicit to preclude Model A." As I mentioned, too many times we hear comments like "we can't do that feature/approach, since low-end printers can't support it"...and hence, we either eliminate the feature, or alter our approach due to this constraint. As a result, we seem to be moving in a direction that complicates the protocol due to the constraints found in low-end printers. Scott, perhaps you (and others) can help me out with what we here at Underscore believe is a critical environmental issue surrounding IPP: IPP seems to put forth the public notion that it will provide "printing from anywhere on the Internet to any printer accessible on the Internet." The various usage scenarios described in the Requirements document revolve around these target environments (ie, the environment surrounding the target printer): - Pay-for-Print (aka, "Kinko's", etc) - Printers used as virtual fax machines - Uniform access to geographically dispersed printers in an organization For the sake of simplicity, let's ignore for a moment those issues surrounding security viz a viz access to the printer by the client. The question is: Doesn't the IPP group believe that all such printers would be front-ended by some sort of spooling system? In our experience, Enterprise-level customers shun direct client-to-printer operation (despite our previous attempts to convince them otherwise). Why is this? The answer usually revolves around job queuing, both for managing visibility of jobs, and to effect a degree of fairness (eg, FIFO). Does this jive with others' experiences? (I'd really like to hear from others on this question.) If you believe this is true, that all such printers are front-ended by spooling services, then perhaps now you can see my concerns regarding how the IPP design is being skewed by the lack of capabilities for low-end printers. > As to "Why?" do we need to even address model A at all in our thoughts and > decisions: There are implementations today (in the Novell environments > specifically) where the "server" is embedded in the "printer". In this > case the "server" is not a "spooling server" but a "print server". The > embedded print server uses a file server for actual disk space, but all > status, control, queries, and events are realized through the embedded > "server" (or model A). Therefore, since model A does exist in today's > market, we must address it. With all due respect (as you are a Novell printing systems architect ;-), the NetWare PSERVER model is not exactly "Model A" as I had drawn. True, status requests are sent to the embedded PSERVER, but that PSERVER (by definition) uses a front-end spooler (NetWare QMS), right? So, instead of Model A (shown as): client ---> printer The PSERVER environment is really: client ---> spooling server <--- printer (with embedded PSERVER) The only difference between the PSERVER model and Model B is that the printer initiates communications between the spooling server and itself (unlike Model B, in which the spooling server initiates the communications with the printer). Is this characterization true in your opinion? > Having said that, I agree with you that I do not want IPP (v1.0) to become > "all things to all peole with all devices by mid 1997". We should continue > to focus on Model B and allow for hardware and other issues to help realize > model B in within the output device (what you call model A). Again, I think we need to start talking about "minimum printer implementation" when we reach for various design alternatives for IPP. > Also, I am interested in how you would apply real quantitative requirements > to "cheap, simple, and fast" when you suggest a protocol to deal with the > "spooling server ---> printer" side of the model? I am assuming that you > are refering to the fact that as IPP is currently shaping up, IPP would not > satisfy "cheap, simple, and fast"? I am also assuming that you are refering > to an earlier email you osted about IPP protocol issues and suggestions to > which I have not responded nor have I seen any other responses. This topic is certainly worthy of a separate thread. I have not thought about hard and fast metrics (in terms of numbers and rates, etc), however few characterizations of "cheap, simple and fast" could be: - Separate channels for control and data, ala FTP; when the data is transmitted as a singular stream, then parsing time decreases *dramatically* (potentially to zero). - A single control channel utilized for the entire job submission; a single channel precludes the need for state management, where the printer has to maintain all kinds of state until the job is fully submitted. - A simple control channel framing protocol, easily implementable on any platform, including very low-end embedded varieties. How does this sound to you (and others)? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-archive Mon May 5 14:00:47 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA29885 for ipp-outgoing; Mon, 5 May 1997 13:57:30 -0400 (EDT) Message-Id: <2.2.32.19970505175750.010d5b48@nevrona.mail> X-Sender: jimg@nevrona.mail X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 05 May 1997 10:57:50 -0700 To: ipp@pwg.org From: Jim Gunkel Subject: IPP> IBM Network Printer Manager X-MDMail-Server: MDaemon v2.1 rB b1 32-R X-MDaemon-Deliver-To: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I've just been lurking here but I came across some info that might be of interest to everyone on this list. IBM has come out with a Java based network printer manager and have a demo download at http://www.printers.ibm.com/npm.html. Haven't looked into it yet but it looks to be along the same lines. I'm own a component software development company and we're interested in the technology that you are developing since our main product is a reporting tool. We are looking into enhancing our product to allow internet based printing. Jim Gunkel Nevrona Designs http://www.nevrona.com/designs From ipp-archive Mon May 5 14:55:37 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA01165 for ipp-outgoing; Mon, 5 May 1997 14:54:47 -0400 (EDT) From: Harry Lewis To: Cc: Subject: IPP> IBM Network Printer Manager Message-Id: <5030100002213418000002L082*@MHS> Date: Mon, 5 May 1997 14:56:33 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO This note went across the IPP reflector >I've just been lurking here but I came across some info that might be of >interest to everyone on this list. IBM has come out with a Java based >network printer manager and have a demo download at >http://www.printers.ibm.com/npm.html. Haven't looked into it yet but it >looks to be along the same lines. >I'm own a component software development company and we're interested in the >technology that you are developing since our main product is a reporting >tool. We are looking into enhancing our product to allow internet based >printing. >Jim Gunkel >Nevrona Designs >http://www.nevrona.com/designs The current focus of IBM's JAVA NPM is printer status, configuration and events. If there is enough interest, to clarify the PWG understanding of this product, I will be happy to bring a demo of JAVA NPM with me to San Diego. I would need the cooperation of the PWG Chair in finding a place on the agenda. This could even be done "after hours", directly following whatever topic is in session on Wednesday, Thursday or Friday. Harry Lewis - IBM Printing Systems From ipp-archive Mon May 5 15:14:08 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA01769 for ipp-outgoing; Mon, 5 May 1997 15:03:28 -0400 (EDT) Message-Id: <9705051903.AA04883@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: Mon, 5 May 1997 12:01:17 PDT To: ipp@pwg.org From: Tom Hastings Subject: PRO - Re: IPP> Document available...(finally) Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I reposted Randy's .pdf file with line and page numbers as agreed at the telecon today. ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipphttp-rt.doc -rw-r--r-- 1 pwg pwg 29002 May 4 15:41 ipphttp-rt.PDF Tom >Return-Path: >X-Sender: manros@pop.mindspring.com >Date: Sun, 4 May 1997 13:17:06 PDT >To: ipp@pwg.org >From: Carl-Uno Manros >Subject: Re: IPP> Document available...(finally) >Sender: ipp-owner@pwg.org > >At 09:18 AM 5/4/97 -0800, you wrote: >>The URL that you actually posted was >> >>ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipphttp-rt.doc >> >>-------------------------------------------------------------- >>Stephen N. Zilles | e-mail: szilles@adobe.com | >>Adobe Systems Inc. | | >>Mailstop W14 | tel: (work) (408) 536-4766 | >>345 Park Avenue | (Admin) (408) 536-4751 | >>San Jose, CA 95110-2704 | fax: (408) 537-4042 | >>-------------------------------------------------------------- >> >>\ > >FYI, > >I have also added .TXT and .PDF versions of the document. > >Carl-Uno > > > From ipp-archive Mon May 5 15:30:38 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA02663 for ipp-outgoing; Mon, 5 May 1997 15:29:45 -0400 (EDT) Mime-Version: 1.0 Date: Mon, 5 May 1997 15:34:17 -0400 Message-ID: <00013E2D.1337@digprod.com> From: bwagner@digprod.com (Bill Wagner) Subject: Re: IPP> MOD - Base printer implementation requirements 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: bulk Status: RO Although I agree that I see what appear to be contradictory comments about the base system (high end printer vs printer preceded by server vs hardware not able to implement), and I see some unlikely statements ($150 printers are still rated as personal printers, not workgroup printers), Jay's base premise frightens me. The notion that IPP is *just* for internet printing (as distinguished from intranet or intra-enterprise printing) is a very frightening one. Granted that internet printing has a certain pizzas right now, I would still expect 90% of the printing will be within a company. I strongly question whether there is any rational in developing a protocol just for internet printing. Indeed, since one of the intentions is to provide a substantial improvement over LPR, I would certainly expect that intra-enterprise printing is the major target. Similarly, the notion that the IPP must avoid the complexities and inconveniences of addressing the desktop printer seem again to missing the major part of the market. Perhaps it would be appropriate to reaffirm the objectives of the IPP project? Bill Wagner, Osicom/DPI From ipp-archive Mon May 5 16:15:39 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA03559 for ipp-outgoing; Mon, 5 May 1997 16:13:48 -0400 (EDT) Date: Mon, 5 May 1997 16:10:24 -0400 (EDT) From: JK Martin Message-Id: <199705052010.QAA20092@uscore.underscore.com> To: bwagner@digprod.com Subject: Re: IPP> MOD - Base printer implementation requirements Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Bill, > Although I agree that I see what appear to be contradictory comments > about the base system (high end printer vs printer preceded by server > vs hardware not able to implement), and I see some unlikely statements > ($150 printers are still rated as personal printers, not workgroup > printers), Jay's base premise frightens me. You raise an interesting question about terminology here. I quickly agree with you that $150 printers would be characterized as "personal" printers and not "workgroup" printers. However, Tom repeatedly states the IPP's intention to support "desktop" printers. So, exactly how do we define a "desktop" printer? Hopefully this is not a silly question, given that serious design decisions are being made based on the need to support "desktop" printers. Should only "network printers" be considered when defining implementation constraints? (And yes, what constitutes a "network printer", etc?) > The notion that IPP is *just* for internet printing (as distinguished > from intranet or intra-enterprise printing) is a very frightening one. > Granted that internet printing has a certain pizzas right now, I would > still expect 90% of the printing will be within a company. I strongly > question whether there is any rational in developing a protocol just > for internet printing. Indeed, since one of the intentions is to > provide a substantial improvement over LPR, I would certainly expect > that intra-enterprise printing is the major target. I sure hope so, too. What I see happening though (IMHO) is that the IPP group is assuming that an HTTP-based approach should work equally well in an *intranet* environment as an *internet* environment. This is why I said "just because you can, doesn't mean you should." Solving the intranet problem is just as big a need (no, bigger?) than solving the Pay-for-Print and "fax replacement" requirements noted in the IPP requirements doc. ...jay From ipp-archive Mon May 5 16:29:02 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA04045 for ipp-outgoing; Mon, 5 May 1997 16:25:01 -0400 (EDT) Date: Mon, 5 May 1997 13:21:59 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705052021.NAA24317@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD reconsideration of model decision X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Scott, Here is a change, that I propose for the model document. At the model meeting last Friday, we decided to add a suffix 'capable' to production attributes in the Printer's JobTemplate group. The 'capable' suffix was to allow a printer to distinguish between features that it is capable of handling ('capable' suffix) and features that it supports via IPP attributes ('supported' suffix). An output device that supports IPP would likely have the same values in the 'supported' attribute as in the 'capable' attribute, in which case it would not need to have any 'capable' attributes (according to the Friday proposed rules). Whereas a print server that has to modify a PostScript file, might show 'as-is' as the only supported values for many production attributes, but would show a complete feature list for each 'capable' attributes. I think we got the concept right, but we did not get the operation for the client right. With Friday rule, when a client presents a set of potential values for an attribute to an end-user, it implements one of the following two rules: o Rule 1, the client is embedding production attributes in the PDL: look for the 'capable' attributes first and then the 'supported' attributes. o Rule 2, the client is explicitly including the IPP production attributes: look for the 'supported' attributes only. I think that this complexity, if it is implemented, should be on the server side, and the client should see one set of allowed values for each attribute. A client knows whether it is following rule 1 or 2 (above). So it would be better for GetAttributes to have an additional parameter called "allowed" whose value is 'supported' or 'capable' (default 'supported'). This attribute tells the server whether to follow rule 1 or 2 when producing the list of allowed values for each attribute. An administrator could see the 'supported' and 'capable' attributes, but not an end-user. The end-user sees only 'allowed' values. Note: If an attribute on the server has a 'supported' suffix, but no 'capable' suffix, then the 'capable' value is the same as the 'supported' value. The words 'allowed', 'supported' and 'capable' may not be the right words for these three concepts, but I haven't thought of any better ones yet. Comments? Bob Herriot From ipp-archive Mon May 5 16:44:55 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA04603 for ipp-outgoing; Mon, 5 May 1997 16:36:23 -0400 (EDT) Message-Id: <199705052034.QAA09259@spot.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Carl-Uno Manros cc: Keith Moore , Harald Alvestrand , ipp@pwg.org Subject: IPP> Re: ADM - Re: misleading press release issued by IPP WG In-reply-to: Your message of "Fri, 02 May 1997 13:26:17 PDT." <3.0.1.32.19970502132617.01087bf8@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 May 1997 16:34:22 -0400 Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > I am seriously sorry and worried that this has upset people in the > IETF, it was certainly not intended. A few remarks to our defense: > > 1) We discussed your comments in one of our conferences, and it was > suggested that if the press release was clearly labeled as coming from > the PWG, giving their view and comments about the IPP project, we > would not violate any IETF rules. The concern in any case is that IETF or IPP is represented as having vendors, or vendor representatives, as members of the working group. > 2) There were a number of further drafts after April 17, distributed > for review on the IPP list. Why did you not speak up, if you noticed > that your comments had not been taken into account properly? Time constraints, along with a large number of working groups, prevent me from keeping track of working groups on a daily basis, or even every single week. For most working groups this is sufficient, but then again, most working groups only produce draft documents that go through to the IESG for review anyway. > 3) What is the difference between a particular company putting out a > press relaese about supporting a particular IETF project and the PWG > (as a group of cooperating vendors) doing the same? If either PWG or a vendor wants to say it's supporting IETF's work, fine. IETF simply does not wish to be misrepresented. The press release can easily be taken to say that vendors are participants in an IETF working group. This is not IETF policy and is not how IETF working groups operate. IETF would also ask for a correction if a vendor represented IETF in a similar way. > 4) A general observation about the policy not to mention company names > is that it does not seem to be applied in practise, even in IETF > sanctioned publications. The IETF does list its participants' affiliations (unless the participant wishes otherwise), but the participants themselves are individuals, who are assumed to represent only themselves. > I am willing to take on the cost of sending out a correction to the > press release, but we would like you to draft the text. Per your suggestion in a separate message, I am willing to draft the correction and send it out, once you supply the contact addresses. > Concerning the Web pages, I want you to give a few concrete > examples. There might be some older documents on our FTP site, from > the time before we were established as a WG, that might fall under the > category you mentioned, they could simply get deleted (or have access > restricted to the members of the PWG). It isn't necessary to remove all vendor references, only to correct those documents that imply that IETF or IPP has vendors or vendor representatives as participants of its working groups. > Actually, I just received the following message from our web editor in > response to your message: > > ------- > > A quick check of the Web pages shows that other than the press release > itself there was only one place a company name was used: next to the > name of the Web page maintainer ("Jeffrey L Copeland at QMS, Inc."). > That was there to keep me from getting confused with the Jeffrey > Copeland at Systemhouse, but I've removed it anyway. > > As a stop-gap for the press release problem, I've removed the > references to it on the web page. As soon as there's a fix for the > release itself, I'll put the new one up. > ---- This sounds fine to me. And there's no problem with references of the style "Jeffrey L Copeland at QMS, Inc.". Keith From ipp-archive Mon May 5 17:10:39 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA05126 for ipp-outgoing; Mon, 5 May 1997 17:07:20 -0400 (EDT) Message-Id: <3.0.1.32.19970505140127.01056728@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 5 May 1997 14:01:27 PDT To: JK Martin , bwagner@digprod.com From: Carl-Uno Manros Subject: IPP> MOD - RE: Base printer implementation requirements Cc: ipp@pwg.org In-Reply-To: <199705052010.QAA20092@uscore.underscore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I have inserted a few comments below, preceded by CBM>, otherwise this starts becoming totally unreadable. Carl-Uno At 01:10 PM 5/5/97 PDT, JK Martin wrote: >Bill, > >> Although I agree that I see what appear to be contradictory comments >> about the base system (high end printer vs printer preceded by server >> vs hardware not able to implement), and I see some unlikely statements >> ($150 printers are still rated as personal printers, not workgroup >> printers), Jay's base premise frightens me. > >You raise an interesting question about terminology here. I quickly >agree with you that $150 printers would be characterized as "personal" >printers and not "workgroup" printers. However, Tom repeatedly states >the IPP's intention to support "desktop" printers. > >So, exactly how do we define a "desktop" printer? Hopefully this is >not a silly question, given that serious design decisions are being >made based on the need to support "desktop" printers. > >Should only "network printers" be considered when defining implementation >constraints? (And yes, what constitutes a "network printer", etc?) CBM> I think using these terms in the context of model and protocol are CBM> meaningless, but they give some general idea in the requirements doc. CBM> The first set of IPP implementations will most certainly be of type CBM> print server that can front for any type of printer, including a $150 CBM> printer which is hooked up directly to the print server machine. CBM> The next stage is more likely to include IPP servers embedded in CBM> print devices connected to the network, and whether that networked CBM> printer fits on a desktop or not seems really irrelevant. > >> The notion that IPP is *just* for internet printing (as distinguished >> from intranet or intra-enterprise printing) is a very frightening one. >> Granted that internet printing has a certain pizzas right now, I would >> still expect 90% of the printing will be within a company. I strongly >> question whether there is any rational in developing a protocol just >> for internet printing. Indeed, since one of the intentions is to >> provide a substantial improvement over LPR, I would certainly expect >> that intra-enterprise printing is the major target. > >I sure hope so, too. What I see happening though (IMHO) is that the IPP >group is assuming that an HTTP-based approach should work equally well >in an *intranet* environment as an *internet* environment. This is why >I said "just because you can, doesn't mean you should." > >Solving the intranet problem is just as big a need (no, bigger?) than >solving the Pay-for-Print and "fax replacement" requirements noted in >the IPP requirements doc. > CBM> I do not think that anybody is neglecting the intranet type scenarios. CBM> Actually when it comes to security, we need to make rather explicit CBM> the differences between the intranet and the Internet cases. > ...jay 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 May 5 17:30:40 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA05618 for ipp-outgoing; Mon, 5 May 1997 17:29:50 -0400 (EDT) Date: Mon, 5 May 1997 17:26:09 -0400 (EDT) From: JK Martin Message-Id: <199705052126.RAA20271@uscore.underscore.com> To: cmanros@cp10.es.xerox.com Subject: IPP> Re: MOD - RE: Base printer implementation requirements Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Carl-Uno wrote: > CBM> The first set of IPP implementations will most certainly be of type > CBM> print server that can front for any type of printer, including a $150 > CBM> printer which is hooked up directly to the print server machine. > CBM> The next stage is more likely to include IPP servers embedded in > CBM> print devices connected to the network, and whether that networked > CBM> printer fits on a desktop or not seems really irrelevant. Ok, this sounds better to me. (Does everyone else agree with this??) As far as deriving base constraints goes, to me the real question is: Must an "IPP Printer" must be able spool print jobs? I would like to see an answer of "Yes", but clearly this is where desktop printers (and many, if not most, network printers) fail to perform. And I believe this is usually the reasons behind most case of "we can't do that due to printer limitations." > CBM> I do not think that anybody is neglecting the intranet type scenarios. The phrase "neglecting the intranet" may not be the best choice of words here. With all due respect, the IPP may be "neglecting to provide a reasonably simple and efficient network printing protocol for the intranet." I'm hoping the Model team can start working more closely with Netscape (as briefly discussed during today's telecon), whereby we investigate the approach of adding a new standard protocol to web browsers. This approach could end up making all parties happy in the end. ...jay From ipp-archive Mon May 5 17:50:47 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA06582 for ipp-outgoing; Mon, 5 May 1997 17:48:29 -0400 (EDT) Date: Mon, 5 May 1997 14:40:29 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705052140.OAA25039@woden.eng.sun.com> To: cmanros@cp10.es.xerox.com, jkm@underscore.com Subject: Re: IPP> Re: MOD - RE: Base printer implementation requirements Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > From jkm@underscore.com Mon May 5 14:31:42 1997 > > Carl-Uno wrote: > > > CBM> The first set of IPP implementations will most certainly be of type > > CBM> print server that can front for any type of printer, including a $150 > > CBM> printer which is hooked up directly to the print server machine. > > CBM> The next stage is more likely to include IPP servers embedded in > > CBM> print devices connected to the network, and whether that networked > > CBM> printer fits on a desktop or not seems really irrelevant. > > Ok, this sounds better to me. (Does everyone else agree with this??) > I agree. I have always made the same assumptions as Carl-Uno. From ipp-archive Mon May 5 17:50:48 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA06118 for ipp-outgoing; Mon, 5 May 1997 17:41:41 -0400 (EDT) Date: Mon, 5 May 1997 17:41:52 -0400 (EDT) From: JK Martin Message-Id: <199705052141.RAA20462@uscore.underscore.com> To: Robert.Herriot@Eng.Sun.COM Subject: Re: IPP>MOD reconsideration of model decision Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Bob, Perhaps I haven't read your message (below) properly to understand exactly what you're driving at, so forgive me if these statements aren't relevant to your message. On the issue of dealing with embedded, PDL-specific coding within the body of a document, I thought we reached these conclusions and consensus: 1. We don't want to promote the direct embedding of device and job controls within print data; instead, we want to move towards complete separation of print data and such controls. (This is what spawned the UPD discussion, etc.) 2. Parsing print data to extract and/or override such controls by the server side of IPP is an untenable situation. 3. As a result, we're taking the approach of "whatever is embedded in the print data is the responsibility of the client." If the client declares certain attributes--but the print data overrides them during the printing process--then the client takes the responsibility for the results. Does this correctly summarize the consensus and direction? If so, then your statements below might be modified so as not to suggest that an IPP-aware client can freely elect Rule #1 in which the cient proceeds to embed device/job controls in the print data. Sure, a client can do whatever it wants. I'm just hoping the IPP group doesn't encourage (in any way) the implementation of IPP-aware clients that embed device and/or job controls in the print data. ...jay ----- Begin Included Message ----- >From ipp-owner@pwg.org Mon May 5 16:29 EDT 1997 Date: Mon, 5 May 1997 13:21:59 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) To: ipp@pwg.org Subject: IPP>MOD reconsideration of model decision Scott, Here is a change, that I propose for the model document. At the model meeting last Friday, we decided to add a suffix 'capable' to production attributes in the Printer's JobTemplate group. The 'capable' suffix was to allow a printer to distinguish between features that it is capable of handling ('capable' suffix) and features that it supports via IPP attributes ('supported' suffix). An output device that supports IPP would likely have the same values in the 'supported' attribute as in the 'capable' attribute, in which case it would not need to have any 'capable' attributes (according to the Friday proposed rules). Whereas a print server that has to modify a PostScript file, might show 'as-is' as the only supported values for many production attributes, but would show a complete feature list for each 'capable' attributes. I think we got the concept right, but we did not get the operation for the client right. With Friday rule, when a client presents a set of potential values for an attribute to an end-user, it implements one of the following two rules: o Rule 1, the client is embedding production attributes in the PDL: look for the 'capable' attributes first and then the 'supported' attributes. o Rule 2, the client is explicitly including the IPP production attributes: look for the 'supported' attributes only. I think that this complexity, if it is implemented, should be on the server side, and the client should see one set of allowed values for each attribute. A client knows whether it is following rule 1 or 2 (above). So it would be better for GetAttributes to have an additional parameter called "allowed" whose value is 'supported' or 'capable' (default 'supported'). This attribute tells the server whether to follow rule 1 or 2 when producing the list of allowed values for each attribute. An administrator could see the 'supported' and 'capable' attributes, but not an end-user. The end-user sees only 'allowed' values. Note: If an attribute on the server has a 'supported' suffix, but no 'capable' suffix, then the 'capable' value is the same as the 'supported' value. The words 'allowed', 'supported' and 'capable' may not be the right words for these three concepts, but I haven't thought of any better ones yet. Comments? Bob Herriot ----- End Included Message ----- From ipp-archive Mon May 5 18:05:40 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA07106 for ipp-outgoing; Mon, 5 May 1997 18:01:29 -0400 (EDT) Mime-Version: 1.0 Date: Mon, 5 May 1997 18:06:22 -0400 Message-ID: <00013EFA.1337@digprod.com> From: bwagner@digprod.com (Bill Wagner) Subject: Re: IPP> Re: MOD - RE: Base printer implementation requireme 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: bulk Status: RO I suggest that, if IPP initially is restricted to (logical) printers that can spool, it will be a lingering inherent defect that will be very hard to reverse. I believe that this is the wrong approach and is contrary to original intent of this project. Bill Wagner, Osicom/DPI From ipp-archive Mon May 5 18:14:06 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA07460 for ipp-outgoing; Mon, 5 May 1997 18:07:21 -0400 (EDT) Date: Mon, 5 May 1997 15:03:37 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705052203.PAA25256@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, jkm@underscore.com Subject: Re: IPP>MOD reconsideration of model decision Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I believe that you are correct in stating that we want to get away from embedded control information in a PDL file and servers that modify such embedded information. But the question is how to handle the transition. There are currently print servers that modify control information in PostScript documents. We have said in email during the past few hours, that we will implement print servers somewhat before output devices support IPP. If an output device supports values X and Y for attribute A, and a print server supports those values only when they are embedded in PostScript, then we have a problem. A client GUI that allows submission of pre-existing PostScript files can show only 'as-is' as the value for attribute A or show it as grayed out. A client program for building a directory entry should show values X and Y. So we are stuck if we want to support today's technology before IPP output devices arrive. I have tried to define things so that the 'capable' concept can fall away gracefully when it is no longer needed. That is, in time there is no difference between 'capable' and 'supported' values. > From jkm@underscore.com Mon May 5 14:38:44 1997 > > Bob, > > Perhaps I haven't read your message (below) properly to understand > exactly what you're driving at, so forgive me if these statements > aren't relevant to your message. > > On the issue of dealing with embedded, PDL-specific coding within the body > of a document, I thought we reached these conclusions and consensus: > > 1. We don't want to promote the direct embedding of device and job > controls within print data; instead, we want to move towards complete > separation of print data and such controls. (This is what spawned > the UPD discussion, etc.) > > 2. Parsing print data to extract and/or override such controls by the > server side of IPP is an untenable situation. > > 3. As a result, we're taking the approach of "whatever is embedded in > the print data is the responsibility of the client." If the client > declares certain attributes--but the print data overrides them during > the printing process--then the client takes the responsibility for > the results. > > Does this correctly summarize the consensus and direction? > > If so, then your statements below might be modified so as not to > suggest that an IPP-aware client can freely elect Rule #1 in which the > cient proceeds to embed device/job controls in the print data. > > Sure, a client can do whatever it wants. I'm just hoping the IPP group > doesn't encourage (in any way) the implementation of IPP-aware clients > that embed device and/or job controls in the print data. > > ...jay > > ----- Begin Included Message ----- > > From ipp-owner@pwg.org Mon May 5 16:29 EDT 1997 > Date: Mon, 5 May 1997 13:21:59 -0700 > From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) > To: ipp@pwg.org > Subject: IPP>MOD reconsideration of model decision > > Scott, > > Here is a change, that I propose for the model document. > > At the model meeting last Friday, we decided to add a suffix 'capable' > to production attributes in the Printer's JobTemplate group. The > 'capable' suffix was to allow a printer to distinguish between features > that it is capable of handling ('capable' suffix) and features that it > supports via IPP attributes ('supported' suffix). > > An output device that supports IPP would likely have the same values in > the 'supported' attribute as in the 'capable' attribute, in which case > it would not need to have any 'capable' attributes (according to the > Friday proposed rules). Whereas a print server that has to modify a > PostScript file, might show 'as-is' as the only supported values for > many production attributes, but would show a complete feature list for > each 'capable' attributes. > > I think we got the concept right, but we did not get the operation for > the client right. With Friday rule, when a client presents a set of > potential values for an attribute to an end-user, it implements one of the > following two rules: > > o Rule 1, the client is embedding production attributes in the PDL: > look for the 'capable' attributes first and then the 'supported' attributes. > > o Rule 2, the client is explicitly including the IPP production attributes: > look for the 'supported' attributes only. > > I think that this complexity, if it is implemented, should be on the > server side, and the client should see one set of allowed values for > each attribute. > > A client knows whether it is following rule 1 or 2 (above). So it > would be better for GetAttributes to have an additional parameter > called "allowed" whose value is 'supported' or 'capable' (default > 'supported'). This attribute tells the server whether to follow rule 1 > or 2 when producing the list of allowed values for each attribute. > > An administrator could see the 'supported' and 'capable' attributes, > but not an end-user. The end-user sees only 'allowed' values. > > Note: If an attribute on the server has a 'supported' suffix, but no > 'capable' suffix, then the 'capable' value is the same as the > 'supported' value. > > The words 'allowed', 'supported' and 'capable' may not be the right words > for these three concepts, but I haven't thought of any better ones yet. > > Comments? > > Bob Herriot > > > ----- End Included Message ----- > > From ipp-archive Mon May 5 18:24:04 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA08036 for ipp-outgoing; Mon, 5 May 1997 18:17:05 -0400 (EDT) Date: Mon, 5 May 1997 18:17:20 -0400 (EDT) From: JK Martin Message-Id: <199705052217.SAA21513@uscore.underscore.com> To: Robert.Herriot@Eng.Sun.COM Subject: Re: IPP>MOD reconsideration of model decision Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Bob, > So we are stuck if we want to support today's technology before IPP > output devices arrive. If existing print drivers are considered "today's technology", then today's technology won't know anything about IPP, correct? Perhaps I'm missing something, then. Does anyone think that IPP is being designed such that today's print drivers can submit jobs to an IPP Printer? Maybe that's where I'm getting confused. I'm making the assumption that to drive an IPP Printer, you need an IPP-aware print driver. Is this assumption incorrect? ...jay From ipp-archive Mon May 5 18:35:41 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA08555 for ipp-outgoing; Mon, 5 May 1997 18:33:30 -0400 (EDT) Date: Mon, 5 May 1997 18:33:51 -0400 (EDT) From: JK Martin Message-Id: <199705052233.SAA21536@uscore.underscore.com> To: bwagner@digprod.com Subject: Re: IPP> Re: MOD - RE: Base printer implementation requireme Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Bill, > I suggest that, if IPP initially is restricted to (logical) printers > that can spool, it will be a lingering inherent defect that will be > very hard to reverse. I believe that this is the wrong approach and is > contrary to original intent of this project. I understand your position completely. We disagree, but that's ok. ;-) Regardless of whether we agree or not, I'm still quite concerned about IPP solving the needs of the intranet (aka, Enterprise-level printing). Hopefully no one will assume I'm taking the position that the only problems to be solved by IPP are those occurring in the Enterprise. There are other problems to be solved, to be sure, but please understand that my company's vested interest is solving Enterprise-related problems, so I'll continue to ask questions and raise issues on behalf of that environment. (But certainly not to the exclusion of other problems.) Our experience has indicated that within the Enterprise, all network printers must be front-ended by a spooling server; direct printing from a client system to a network is highly discouraged, or even forbidden. Does this experience match others' in the Enterprise? I'd really like to hear from other people on this question, either publicly or privately. To those list members associated with educational institutions: do educational institutions (particularly higher education facilities) allow, encourage or otherwise accept direct client-to-printer job submission over the network? Or do you also demand routing jobs through spooling systems? Just so no one misunderstands, I think IPP as a front-end to a spooling system is a great approach. It's just the spooler-to-printer protocol that concerns me. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-archive Mon May 5 19:00:43 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA09300 for ipp-outgoing; Mon, 5 May 1997 18:56:25 -0400 (EDT) Date: Mon, 5 May 1997 15:52:44 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705052252.PAA25711@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, jkm@underscore.com Subject: Re: IPP>MOD reconsideration of model decision Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > From jkm@underscore.com Mon May 5 15:14:09 1997 > > Bob, > > > So we are stuck if we want to support today's technology before IPP > > output devices arrive. > > If existing print drivers are considered "today's technology", then > today's technology won't know anything about IPP, correct? Correct, but I am thinking UNIX when I talk about print servers that inject PostScript into document data. This might happen via a client GUI, via a client command, or via the selection of a particular logical printer which causes the server inject some PostScript into the document (e.g. duplexing). > > Perhaps I'm missing something, then. Does anyone think that IPP is > being designed such that today's print drivers can submit jobs to > an IPP Printer? I am assuming that in the Window's world, there could be an IPP Print Provider for IPP printers which would take the PostScript or PCL file received from the driver and forward it to the Printer using IPP protocol. I wouldn't expect job attributes to play any role in this case. > > Maybe that's where I'm getting confused. I'm making the assumption > that to drive an IPP Printer, you need an IPP-aware print driver. > Is this assumption incorrect? If the driver wants to make use of dynamic attribute information, then the driver needs to be IPP aware. But a driver/GUI could works as it does currently with static awareness. It can communicate with an IPP Printer via a new IPP Print Provider, or use the existing one (e.g. lpr). In the latter case, the IPP Printer would have an lpr-to-IPP gateway. > > ...jay > From ipp-archive Mon May 5 20:10:42 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA10556 for ipp-outgoing; Mon, 5 May 1997 20:08:24 -0400 (EDT) Message-Id: <3.0.1.32.19970505170410.01064df0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 5 May 1997 17:04:10 PDT To: JK Martin , Robert.Herriot@eng.sun.com From: Carl-Uno Manros Subject: Re: IPP>MOD reconsideration of model decision Cc: ipp@pwg.org In-Reply-To: <199705052217.SAA21513@uscore.underscore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO At 03:17 PM 5/5/97 PDT, JK Martin wrote: >Perhaps I'm missing something, then. Does anyone think that IPP is >being designed such that today's print drivers can submit jobs to >an IPP Printer? I had assumed so, provided that you put a new piece of software in between the old print driver and the protocol stub. New "IPP-aware" drivers can later replace that combination with an IPP-driver. 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 May 5 20:10:43 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA10567 for ipp-outgoing; Mon, 5 May 1997 20:09:01 -0400 (EDT) Date: Mon, 05 May 1997 17:09:28 PST From: David_Kellerman@nls.com To: ipp@pwg.org Message-ID: <009B3CFF.8DDC0059.4@nls.com> Subject: Re: IPP> Re: MOD - RE: Base printer implementation requirements Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Jay Martin wrote, in part: > Our experience has indicated that within the Enterprise, all network > printers must be front-ended by a spooling server; direct printing from > a client system to a network is highly discouraged, or even forbidden. > > Does this experience match others' in the Enterprise? I'd really like > to hear from other people on this question, either publicly or privately. As background, so you'll know where my comments are coming from, Northlake makes printer interface software for the Digital OpenVMS environment. It may seem we're a little off the beaten path, but these systems (and our software) see service on both client and server side of our customers' printing strategies, on heterogeneous networks, departmental to enterprise scales, low-end to production printing, so we cover a fair amount of ground. A couple comments: 1. No, I see no such consistency in our customers. Many have chosen server architectures, but many prefer less centralized approaches. In support of this, I would point out all the multi-protocol network printer interfaces out there -- they're there because customers insisted on them, and what they do is make the printer accessible to multiple systems on some good-sized networks. 2. When you talk about a preference for server-based as opposed to decentralized configurations, you ought to ask why. A big part of the answer is that today's clients and printers often behave unreliably; also, they have problems with sharing. Interposing a server system helps with these problems, but at considerable cost. Thing is, better printing protocols would help a lot, too. I'd hate to give up on this as a goal for IPP. 3. Assuming your printer is capable of spooling is no panacea. For example, just recently we spent a lot of time with one of our customer tracking down an intermittent failure (happened only at night with the lights out, you know) sending print jobs to a UNIX system acting as a print server -- it was running out of disk space when too many jobs queued up. I'd say if you're careful to consider problematic scenarios in your protocol design, not just the happy case, the spooled printer isn't that much better off than the non-spooled one. Jay, what I'm reading into your comments is the notion that assuming a spooled server simplifies that protocol requirements. I question how true this is. The example of storage constraints (client or server side) may be typical -- a robust protocol has to deal with similar issues either way. In our environment, we've been very successful with decentralized printing configurations. Admittedly, we have the advantage of a relatively robust, capable client system, and we tend to gloss over the issue of fair sharing of the printer. When they can be made to work reliably, these configurations offer advantages in flexibility and cost. I'd like to see IPP make them work better, not bypass them. :: David Kellerman Northlake Software 503-228-3383 :: david_kellerman@nls.com Portland, Oregon fax 503-228-5662 From ipp-archive Tue May 6 00:05:45 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA12775 for ipp-outgoing; Tue, 6 May 1997 00:03:50 -0400 (EDT) Message-ID: From: Babak Jahromi To: "'JK Martin'" , bwagner@digprod.com Cc: ipp@pwg.org Subject: RE: IPP> Re: MOD - RE: Base printer implementation requireme Date: Mon, 5 May 1997 21:06:06 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.14) Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I agree. I just don't see how network printing without print servers could scale. Unless we put the serves inside the printers, and charge that much more, in which case we are forcing customers to pay for a dedicated server they cannot use for other reasons, and cannot upgrade. Babak > -----Original Message----- > From: JK Martin [SMTP:jkm@underscore.com] > Sent: Monday, May 05, 1997 3:34 PM > To: bwagner@digprod.com > Cc: ipp@pwg.org > Subject: Re: IPP> Re: MOD - RE: Base printer implementation > requireme > > Bill, > > > I suggest that, if IPP initially is restricted to (logical) > printers > > that can spool, it will be a lingering inherent defect that > will be > > very hard to reverse. I believe that this is the wrong approach > and is > > contrary to original intent of this project. > > I understand your position completely. We disagree, but that's ok. > ;-) > > Regardless of whether we agree or not, I'm still quite concerned about > IPP solving the needs of the intranet (aka, Enterprise-level > printing). > > Hopefully no one will assume I'm taking the position that the only > problems to be solved by IPP are those occurring in the Enterprise. > > There are other problems to be solved, to be sure, but please > understand > that my company's vested interest is solving Enterprise-related > problems, > so I'll continue to ask questions and raise issues on behalf of that > environment. (But certainly not to the exclusion of other problems.) > > Our experience has indicated that within the Enterprise, all network > printers must be front-ended by a spooling server; direct printing > from > a client system to a network is highly discouraged, or even forbidden. > > Does this experience match others' in the Enterprise? I'd really like > to hear from other people on this question, either publicly or > privately. > > To those list members associated with educational institutions: do > educational institutions (particularly higher education facilities) > allow, encourage or otherwise accept direct client-to-printer job > submission over the network? Or do you also demand routing jobs > through spooling systems? > > Just so no one misunderstands, I think IPP as a front-end to a > spooling > system is a great approach. It's just the spooler-to-printer protocol > that concerns me. > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- From ipp-archive Tue May 6 07:25:52 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA15744 for ipp-outgoing; Tue, 6 May 1997 07:23:19 -0400 (EDT) Message-Id: <199705061123.AA02410@interlock2.lexmark.com> To: JK Martin Cc: "Robert.Herriot%Eng.Sun.COM" , "ipp%pwg.org" From: Don Wright Date: 6 May 97 7:23:22 EDT Subject: Re: IPP>MOD reconsideration of model decision Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Jay Martin said: >If existing print drivers are considered "today's technology", then >today's technology won't know anything about IPP, correct? > >Perhaps I'm missing something, then. Does anyone think that IPP is >being designed such that today's print drivers can submit jobs to >an IPP Printer? > >Maybe that's where I'm getting confused. I'm making the assumption >that to drive an IPP Printer, you need an IPP-aware print driver. >Is this assumption incorrect? I hope we are all balled up in terminology not technology. From this printer manufacturer's perspective, a printer driver creates the datastream for a printer. A "redirector" or "port driver" pushes that datastream out the desired physical connection (parallel port, serial port, IPX/SPX ethernet, etc.) My assumption is that IPP will work with today's drivers but require new "redirector" or "port driver" software. Don From ipp-archive Tue May 6 11:15:53 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA17410 for ipp-outgoing; Tue, 6 May 1997 11:15:29 -0400 (EDT) Date: Tue, 6 May 1997 11:15:40 -0400 (EDT) From: JK Martin Message-Id: <199705061515.LAA25575@uscore.underscore.com> To: peter@digideas.com.au Subject: Re: IPP> Re: MOD - RE: Base printer implementation requireme Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Peter, > > Just so no one misunderstands, I think IPP as a front-end to a spooling > > system is a great approach. It's just the spooler-to-printer protocol > > that concerns me. > > Do you need a standard for this? Surely it is up to the spooler or > spooler host OS manufacturer to negotiate with the the printer > manufacuter. Our customers are demanding a unified protocol between a spooling system and a network printer. Similar to the concept of a "Universal Print Driver", such a protocol would allow the same interface (or "filter", or "driver", or whatever) to be used to communicate with potentially all kinds of network printers. By reducing the number of network techniques for getting the data from the spooling server (or "client" in more general terms) to the printer, then everyone wins. The user wins by having fewer software components to maintain, and the printer vendor wins by having to support fewer protocol implementations in the printer. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-archive Tue May 6 13:00:54 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA18332 for ipp-outgoing; Tue, 6 May 1997 12:58:21 -0400 (EDT) Message-ID: <336F632C.E314BE3A@sharplabs.com> Date: Tue, 06 May 1997 09:58:22 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.0b3 [en] (WinNT; I) MIME-Version: 1.0 To: Don Wright CC: JK Martin , "Robert.Herriot%Eng.Sun.COM" , "ipp%pwg.org" Subject: Re: IPP>MOD reconsideration of model decision X-Priority: 3 (Normal) References: <199705061123.AA02410@interlock2.lexmark.com> Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Don Wright wrote: > Jay Martin said: > >If existing print drivers are considered "today's technology", then > > >today's technology won't know anything about IPP, correct? > > > >Perhaps I'm missing something, then. Does anyone think that IPP is > > >being designed such that today's print drivers can submit jobs to > >an IPP Printer? > > > >Maybe that's where I'm getting confused. I'm making the assumption > > >that to drive an IPP Printer, you need an IPP-aware print driver. > >Is this assumption incorrect? > > I hope we are all balled up in terminology not technology. From > this > printer manufacturer's perspective, a printer driver creates the > datastream for a printer. A "redirector" or "port driver" pushes > that > datastream out the desired physical connection (parallel port, > serial > port, IPX/SPX ethernet, etc.) > > My assumption is that IPP will work with today's drivers but > require > new "redirector" or "port driver" software. > > Don IPP should work fine with today's drivers, if, as you suggest, an IPP port driver is instrumented at a layer beneath the driver. However, existing drivers will not be able to take advantage of any IPP-specific attribute specifications and capabilities. Existing drivers take user-specified job attributes and encode them into whatever PDL is going out; unfortunately, this would all be opaque to an IPP port driver beneath the printer driver, so in this model, existing drivers would just be using IPP as a transport. In the IPP-aware driver situation, it would be possible for the GUI to include IPP, as well as, printer-specific attributes, that could be included in the outgoing data stream. It is unlikely in this scenario that a port driver would be used underneath the IPP-aware printer driver. But it might be the case that an HTTP-aware port driver could sit underneath the IPP-aware driver and transport the IPP datastream coming from the driver. I guess what I'm saying is there's going to be alot of ways to deploy IPP, and existing print drivers can (and should) be supported. Randy From ipp-archive Tue May 6 14:25:55 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA18938 for ipp-outgoing; Tue, 6 May 1997 14:24:07 -0400 (EDT) From: Roger K Debry To: Subject: Re: IPP>MOD reconsideration of model decision Message-Id: <5030100002245171000002L012*@MHS> Date: Tue, 6 May 1997 14:25:53 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I think other's have also responded, ... comments below: Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 If existing print drivers are considered "today's technology", then today's technology won't know anything about IPP, correct? Perhaps I'm missing something, then. Does anyone think that IPP is being designed such that today's print drivers can submit jobs to an IPP Printer? RKD> Yes, in most environments there is RKD> a separate component that actually RKD> handles the wire protocol. In various RKD> systems these are called a port driver, RKD> port monitor, or redirector. While existing RKD> print drivers would not have to be changed RKD> to work with IPP, these components would. Maybe that's where I'm getting confused. I'm making the assumption that to drive an IPP Printer, you need an IPP-aware print driver. Is this assumption incorrect? ...jay From ipp-archive Tue May 6 14:31:01 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA19041 for ipp-outgoing; Tue, 6 May 1997 14:28:31 -0400 (EDT) Message-ID: From: "Danknick, Dan" To: "'ipp@pwg.org'" Subject: RE: IPP>MOD reconsideration of model decision Date: Tue, 6 May 1997 11:26:43 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > >I hope we are all balled up in terminology not technology. From this >printer manufacturer's perspective, a printer driver creates the >datastream for a printer. A "redirector" or "port driver" pushes that >datastream out the desired physical connection (parallel port, serial >port, IPX/SPX ethernet, etc.) > >My assumption is that IPP will work with today's drivers but require >new "redirector" or "port driver" software. That is certainly the approach we see as a short term solution. There are of course a number of ways this can be accomplished, from Java IPP clients to Navigator plug-ins. The downside of being on the receive-only end of the print stream is that it could be difficult to communicate target printer capabilities to the PDL generator in advance. Dan Danknick Canon Information Systems From ipp-archive Tue May 6 14:31:02 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA19082 for ipp-outgoing; Tue, 6 May 1997 14:29:06 -0400 (EDT) Date: Tue, 6 May 1997 14:28:42 -0400 (EDT) From: JK Martin Message-Id: <199705061828.OAA27808@uscore.underscore.com> To: P1284_3@lexmark.com, p1394@pwg.org, ipp@pwg.org, pwg@pwg.org, pmp@pwg.org, jmp@pwg.org Subject: IPP> Meeting room assignments for the San Diego meetings X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO The previously published meeting room assignments for the upcoming San Diego meetings have been slightly changed. The May IEEE/PWG meetings will now be held in the following rooms at the Marriott Suites in San Diego: P1284.3 May 8-9 Maestro Room P1284.4 May 12-13 Symphony Bay 1 1394PWG May 14 Symphony Bay 1,2,3 IPP May 15 Symphony Bay 1,2,3 JMP/PWG May 16 Symphony Bay 1 ...jay PS: Sorry for the massive cross-posting; we don't quite yet have a policy/mechanism for sending messages of this type to a single list. ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- ----- Begin Included Message ----- Date: Mon, 05 May 1997 09:25:26 -0700 To: P1284_3@lexmark.com, p1394@pwg.org, ipp@pwg.org From: Larry Stein The May IEEE/PWG meetings will be held in the following rooms at the Marriott Suites: P1284.3 May 8-9 Maestro Room P1284.4 May 12-13 Maestro Room 1394PWG May 14 Symphony Bay 1&2 IPP May 15 Symphony Bay 1&2 JMP/PWG May 16 Maestro Room The weathers great in San Diego, dress casual and comfortable. -Larry ***************************************************************************** Larry A. Stein Phone: (619)292-2740 Warp Nine Engineering Fax: (619)292-8020 Web: http://www.fapo.com ***************************************************************************** ----- End Included Message ----- From ipp-archive Tue May 6 14:58:33 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA19543 for ipp-outgoing; Tue, 6 May 1997 14:34:43 -0400 (EDT) Date: Tue, 6 May 1997 14:34:16 -0400 (EDT) From: JK Martin Message-Id: <199705061834.OAA27837@uscore.underscore.com> To: ipp@pwg.org Subject: Re: IPP>MOD reconsideration of model decision X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > Does anyone think that IPP is > being designed such that today's print drivers can submit jobs to > an IPP Printer? > > RKD> Yes, in most environments there is > RKD> a separate component that actually > RKD> handles the wire protocol. In various > RKD> systems these are called a port driver, > RKD> port monitor, or redirector. While existing > RKD> print drivers would not have to be changed > RKD> to work with IPP, these components would. Which platforms support such a wire protocol shim? I thought Windows/NT and Windows '95 did, but what about: Windows 3.1 Windows for Workgroups OS/2 2.x OS/2 Warp others? Thanks for the Wintel info. We Unix folks have different operational situations, that's for sure. ;-) ...jay From ipp-archive Tue May 6 14:58:36 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA20178 for ipp-outgoing; Tue, 6 May 1997 14:44:26 -0400 (EDT) Message-Id: <3.0.1.32.19970506113521.00fa8eb8@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 6 May 1997 11:35:21 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Agenda for PWG IPP Conference Call - May 7, 1997 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Agenda for PWG IPP Conference call - May 7, 1997 1) Reports on activities in the subgroups - Model (Scott Isaacson) - Protocol (Bob Herriot) - Any other activity? 2) Discuss changes to the IPP FTP site to comply with latest directives from Keith Moore ---- Dial-in Number: 1-423-673-6712 Access code: 190148 Date: 5/7 Time: 4PM Eastern, 1PM Pacific Duration: 2.5 hours Participants: 20 Max ---- 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 May 6 14:58:39 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA20174 for ipp-outgoing; Tue, 6 May 1997 14:44:21 -0400 (EDT) Message-Id: <3.0.1.32.19970506112738.00fa7490@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 6 May 1997 11:27:38 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Final Agenda for the PWG IPP meeting in San Diego on May 15 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Agenda for the PWG IPP meeting in San Diego on May 15 ----------------------------------------------------- 8:30 - 12:00 am Report of outcome from PWG MOD meeting May 14 (Scott Isaacson) Discussion about options for the IPP Protocol (Bob Herriot and Randy Turner) This will include a presentation and demonstration (Paul Moore and Sylvan Butler) 1:00 - 2:00 pm Continue discussion about options for the IPP Protocol 2:00 - 5:00 pm Discussion about how the Prototyping efforts could support the IPP protocol choices (Peter Zehler) Discussion of IPP Security (Carl-Uno Manros, Daniel Manchala, Roger deBry and others) ------ Note that we have dropped the Universal Print Driver from the agenda, as a separate over-dinner meeting will be held on that subject Wednesday evening, May 14. 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 May 6 15:04:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA20309 for ipp-outgoing; Tue, 6 May 1997 14:46:55 -0400 (EDT) Date: Tue, 6 May 1997 11:47:25 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705061847.LAA06091@woden.eng.sun.com> To: jkm@underscore.com, don@lexmark.com Subject: Re: IPP>MOD reconsideration of model decision Cc: Robert.Herriot@Eng.Sun.COM, ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > From don@lexmark.com Tue May 6 04:25:33 1997 > > My assumption is that IPP will work with today's drivers but require > new "redirector" or "port driver" software. > > Don > I agree with you, Don, and others who have replied. From ipp-archive Tue May 6 15:08:47 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA20377 for ipp-outgoing; Tue, 6 May 1997 14:48:16 -0400 (EDT) From: Roger K Debry To: Subject: Re: IPP>MOD reconsideration of model decision Message-Id: <5030100002246208000002L082*@MHS> Date: Tue, 6 May 1997 14:49:33 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I think that I agree with Jay on this one. I fear that we are burdening IPP with complexity in order to to solve a problem on a small set of servers. Is the class of servers that changes controls in the Postscript file a very large piece of the Universe? I suspect not. Rather than solve every conceivable problem in this very large universe, we ought to get back on track with the rule I thought we agreed to awhile back -- to solve the few problems well that represent the largest customer value. Over time the rest of the world will catch up and do things **right**. Rule (1) below makes no sense to me. Clients (drivers) that understand IPP (and therefore know what xxx-capable means) ought not to imbed controls in the PDL, period! I think that adding xxx-capable is adding undue complexity!!! 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 05/06/97 12:33 PM --------------------------- ipp-owner @ pwg.org 05/05/97 04:14 PM Please respond to ipp-owner@pwg.org @ internet To: jkm @ underscore.com @ internet, Robert.Herriot @ Eng.Sun.COM @ internet cc: ipp @ pwg.org @ internet Subject: Re: IPP>MOD reconsideration of model decision I believe that you are correct in stating that we want to get away from embedded control information in a PDL file and servers that modify such embedded information. But the question is how to handle the transition. There are currently print servers that modify control information in PostScript documents. We have said in email during the past few hours, that we will implement print servers somewhat before output devices support IPP. If an output device supports values X and Y for attribute A, and a print server supports those values only when they are embedded in PostScript, then we have a problem. A client GUI that allows submission of pre-existing PostScript files can show only 'as-is' as the value for attribute A or show it as grayed out. A client program for building a directory entry should show values X and Y. So we are stuck if we want to support today's technology before IPP output devices arrive. I have tried to define things so that the 'capable' concept can fall away gracefully when it is no longer needed. That is, in time there is no difference between 'capable' and 'supported' values. > From jkm@underscore.com Mon May 5 14:38:44 1997 > > Bob, > > Perhaps I haven't read your message (below) properly to understand > exactly what you're driving at, so forgive me if these statements > aren't relevant to your message. > > On the issue of dealing with embedded, PDL-specific coding within the body > of a document, I thought we reached these conclusions and consensus: > > 1. We don't want to promote the direct embedding of device and job > controls within print data; instead, we want to move towards complete > separation of print data and such controls. (This is what spawned > the UPD discussion, etc.) > > 2. Parsing print data to extract and/or override such controls by the > server side of IPP is an untenable situation. > > 3. As a result, we're taking the approach of "whatever is embedded in > the print data is the responsibility of the client." If the client > declares certain attributes--but the print data overrides them during > the printing process--then the client takes the responsibility for > the results. > > Does this correctly summarize the consensus and direction? > > If so, then your statements below might be modified so as not to > suggest that an IPP-aware client can freely elect Rule #1 in which the > cient proceeds to embed device/job controls in the print data. > > Sure, a client can do whatever it wants. I'm just hoping the IPP group > doesn't encourage (in any way) the implementation of IPP-aware clients > that embed device and/or job controls in the print data. > > ...jay > > ----- Begin Included Message ----- > > From ipp-owner@pwg.org Mon May 5 16:29 EDT 1997 > Date: Mon, 5 May 1997 13:21:59 -0700 > From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) > To: ipp@pwg.org > Subject: IPP>MOD reconsideration of model decision > > Scott, > > Here is a change, that I propose for the model document. > > At the model meeting last Friday, we decided to add a suffix 'capable' > to production attributes in the Printer's JobTemplate group. The > 'capable' suffix was to allow a printer to distinguish between features > that it is capable of handling ('capable' suffix) and features that it > supports via IPP attributes ('supported' suffix). > > An output device that supports IPP would likely have the same values in > the 'supported' attribute as in the 'capable' attribute, in which case > it would not need to have any 'capable' attributes (according to the > Friday proposed rules). Whereas a print server that has to modify a > PostScript file, might show 'as-is' as the only supported values for > many production attributes, but would show a complete feature list for > each 'capable' attributes. > > I think we got the concept right, but we did not get the operation for > the client right. With Friday rule, when a client presents a set of > potential values for an attribute to an end-user, it implements one of the > following two rules: > > o Rule 1, the client is embedding production attributes in the PDL: > look for the 'capable' attributes first and then the 'supported' attributes. > > o Rule 2, the client is explicitly including the IPP production attributes: > look for the 'supported' attributes only. > > I think that this complexity, if it is implemented, should be on the > server side, and the client should see one set of allowed values for > each attribute. > > A client knows whether it is following rule 1 or 2 (above). So it > would be better for GetAttributes to have an additional parameter > called "allowed" whose value is 'supported' or 'capable' (default > 'supported'). This attribute tells the server whether to follow rule 1 > or 2 when producing the list of allowed values for each attribute. > > An administrator could see the 'supported' and 'capable' attributes, > but not an end-user. The end-user sees only 'allowed' values. > > Note: If an attribute on the server has a 'supported' suffix, but no > 'capable' suffix, then the 'capable' value is the same as the > 'supported' value. > > The words 'allowed', 'supported' and 'capable' may not be the right words > for these three concepts, but I haven't thought of any better ones yet. > > Comments? > > Bob Herriot > > > ----- End Included Message ----- > > From ipp-archive Tue May 6 15:23:40 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA21654 for ipp-outgoing; Tue, 6 May 1997 15:10:00 -0400 (EDT) From: Roger K Debry To: Subject: IPP> Re: MOD - RE: Base printer implementation requirements Message-Id: <5030100002247127000002L072*@MHS> Date: Tue, 6 May 1997 15:11:07 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > CBM> I do not think that anybody is neglecting the intranet type scenarios. The phrase "neglecting the intranet" may not be the best choice of words here. With all due respect, the IPP may be "neglecting to provide a reasonably simple and efficient network printing protocol for the intranet." RKD> My personal view is that the most important objective of IPP RKD> must be printing in the enterprise. It is also my view that RKD> that is where IPP is focused. Jay, if you believe that IPP RKD> is neglecting to provide a reasonably simple and efficient RKD solution for the enterprise than we are off the mark. Help RKD> us get back on track. I'm hoping the Model team can start working more closely with Netscape (as briefly discussed during today's telecon), whereby we investigate the approach of adding a new standard protocol to web browsers. This approach could end up making all parties happy in the end. ...jay From ipp-archive Tue May 6 15:34:11 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA22130 for ipp-outgoing; Tue, 6 May 1997 15:15:22 -0400 (EDT) Message-Id: <3.0.1.32.19970506115045.00fa8e08@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 6 May 1997 11:50:45 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC - PWG Phone Conference on IPP Security - May 8 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO The PWG SEC subgroup will hold a phone conference on: Thursday May 8, 1:00 - 3:00 pm PST I expect to have an input paper for discussion out to the DL by tomorrow morning, which describes a proposal for security levels in IPP Version 1.0 and initial recommendations for suitable security protocols that meet both the objectives of being IETF sanctioned and on the standards track, as well as being available as products (two conditions which obviously narrow down the choices). The outcome of this discussion will determine what we bring up for discussion in next week's PWG IPP meeting in San Diego. The number to call in on is: 1-800-857 5607 with passcode: cmanros Please note that this is an 800 number, so also people with limited budgets for phone costs can attend. 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 May 6 15:38:53 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA23084 for ipp-outgoing; Tue, 6 May 1997 15:23:16 -0400 (EDT) Date: Tue, 6 May 1997 15:18:50 -0400 (EDT) From: JK Martin Message-Id: <199705061918.PAA27989@uscore.underscore.com> To: cmanros@cp10.es.xerox.com Subject: Re: IPP> ADM - Final Agenda for the PWG IPP meeting in San Diego on May 15 Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > Note that we have dropped the Universal Print Driver from the agenda, as a > separate over-dinner meeting will be held on that subject Wednesday > evening, May 14. The UPD dinner discussion is scheduled for Thursday evening, May 15. ...jay From ipp-archive Tue May 6 16:06:03 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA25798 for ipp-outgoing; Tue, 6 May 1997 16:05:40 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 06 May 1997 14:01:49 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - New Attributes Table Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I posted the following: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/atts-rev-4.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/atts-rev-4.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/atts-rev-4.txt This shows the relationship between Job attributes, Printer default attributes, supported, and the new proposed "capable" attributes. Take a look and we will discuss on Friday. Scott From ipp-archive Tue May 6 16:36:07 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA26528 for ipp-outgoing; Tue, 6 May 1997 16:31:22 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 06 May 1997 14:31:11 -0600 From: Scott Isaacson To: Robert.Herriot@Eng.Sun.COM, ipp@pwg.org Subject: Re: IPP>MOD reconsideration of model decision Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Bob, Below you suggest the need for a client to query on "allowed" attributes and the server fills in the correct supported or capable if they are both implemented. I have reviewed your email, and still don't get the need for your suggestion. My understanding: A client queries the Printer and gets back some attributes. Since it gets xxx-supported and xxx-capable, it knows the difference in semantics of the two and does the right thing. If it sees a value in xxx-capable, it knows that it must format some PDL string in order to realize the request. If it sees a xxx-supported attribute it knows that is must supply a corresponding xxx attribute in the print request or live with the default (the xxx attribute at the Printer). Scott >>> Robert Herriot 05/05 2:21 PM >>> Scott, Here is a change, that I propose for the model document. At the model meeting last Friday, we decided to add a suffix 'capable' to production attributes in the Printer's JobTemplate group. The 'capable' suffix was to allow a printer to distinguish between features that it is capable of handling ('capable' suffix) and features that it supports via IPP attributes ('supported' suffix). An output device that supports IPP would likely have the same values in the 'supported' attribute as in the 'capable' attribute, in which case it would not need to have any 'capable' attributes (according to the Friday proposed rules). Whereas a print server that has to modify a PostScript file, might show 'as-is' as the only supported values for many production attributes, but would show a complete feature list for each 'capable' attributes. I think we got the concept right, but we did not get the operation for the client right. With Friday rule, when a client presents a set of potential values for an attribute to an end-user, it implements one of the following two rules: o Rule 1, the client is embedding production attributes in the PDL: look for the 'capable' attributes first and then the 'supported' attributes. o Rule 2, the client is explicitly including the IPP production attributes: look for the 'supported' attributes only. I think that this complexity, if it is implemented, should be on the server side, and the client should see one set of allowed values for each attribute. A client knows whether it is following rule 1 or 2 (above). So it would be better for GetAttributes to have an additional parameter called "allowed" whose value is 'supported' or 'capable' (default 'supported'). This attribute tells the server whether to follow rule 1 or 2 when producing the list of allowed values for each attribute. An administrator could see the 'supported' and 'capable' attributes, but not an end-user. The end-user sees only 'allowed' values. Note: If an attribute on the server has a 'supported' suffix, but no 'capable' suffix, then the 'capable' value is the same as the 'supported' value. The words 'allowed', 'supported' and 'capable' may not be the right words for these three concepts, but I haven't thought of any better ones yet. Comments? Bob Herriot From ipp-archive Tue May 6 16:59:31 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA27467 for ipp-outgoing; Tue, 6 May 1997 16:53:43 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 06 May 1997 14:53:31 -0600 From: Scott Isaacson To: Robert.Herriot@Eng.Sun.COM, jkm@underscore.com Cc: ipp@pwg.org Subject: Re: IPP>MOD reconsideration of model decision Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Jay makes some excellent summary principles below: >>> JK Martin 05/05 3:41 PM >>> > > If so, then your statements below might be modified so as not to > suggest that an IPP-aware client can freely elect Rule #1 in which the > cient proceeds to embed device/job controls in the print data. > > Sure, a client can do whatever it wants. I'm just hoping the IPP group > doesn't encourage (in any way) the implementation of IPP-aware clients > that embed device and/or job controls in the print data. > IPP aware clients better to the right thing (the UPD for example) -- where the right thing is IPP-aware client can NOT freely embed device/job controls in the print data. The IPP group realizes there must be a transition period where we continue to work with what we got (non IPP aware clients) while at the same time moving to a brave new world. Scott From ipp-archive Tue May 6 16:59:31 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA27134 for ipp-outgoing; Tue, 6 May 1997 16:47:59 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 06 May 1997 14:47:37 -0600 From: Scott Isaacson To: cmanros@cp10.es.xerox.com, jkm@underscore.com Cc: ipp@pwg.org Subject: IPP> Re: MOD - RE: Base printer implementation requirements Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Jay writes: >>> JK Martin 05/05 3:26 PM >>> > As far as deriving base constraints goes, to me the real question is: > > Must an "IPP Printer" must be able spool print jobs? > > I would like to see an answer of "Yes", but clearly this is where desktop > printers (and many, if not most, network printers) fail to perform. And I > believe this is usually the reasons behind most case of "we can't do that > due to printer limitations." I fail to see why a "yes" answer matters? If someone decides to implement IPP in a printer that can not spool, what changes? If it is too busy processing one job and another comes in from another client, it returns a "busy" or a "out of spool space" just as in the case where a server implementation supports 2000 spooled jobs and the 2001st job comes in. When it is asked how many "queued jobs" it answers "0" or "1" depending if it is processing a job or not. If it is too busy to even establish a client connection (it only supports one at a time) then the second one times out, just as if it supported 500 client connection and the 501st comes in and fails and experiences a time out. Will anybody implement IPP in a printer like this? Probably not. Does the model preclude them from doing so? No. Will this type of printer ever be used as as a shared network printer? Probaly not, but if it is, and it does not embed IPP then it can be front ended by a "server" that does. > And I > believe this is usually the reasons behind most case of "we can't do that > due to printer limitations." I believe the only time we should change the model or make decisions based on info like "we can't do that" is when we are talking about what exists in reality today and the near future - like "many printers that support a PDL like PostScript can't support overriding PDL instrcutions with exteranal attributes" In view of that statement, we must "work" in the exising world and not just some future fantasy world. I don't want to succumb to the argument that since the printing spectrum is soooo wide, we can not do one thing or the other since it fails at the exteme ends. IPP should fall comfortably in the middle of the spectrum and all for niche extensions to support the fringes of the spectrum. Scott Scott From ipp-archive Tue May 6 17:04:31 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA27649 for ipp-outgoing; Tue, 6 May 1997 16:57:57 -0400 (EDT) Date: Tue, 6 May 1997 13:58:25 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705062058.NAA07351@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, ipp@pwg.org, SISAACSON@novell.com Subject: Re: IPP>MOD reconsideration of model decision X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > From SISAACSON@novell.com Tue May 6 13:34:29 1997 > > Bob, > > Below you suggest the need for a client to query on "allowed" attributes and > the server fills in the correct supported or capable if they are both > implemented. I have reviewed your email, and still don't get the need for > your suggestion. > > My understanding: > > A client queries the Printer and gets back some attributes. Since it gets > xxx-supported and xxx-capable, it knows the difference in semantics of the > two and does the right thing. If it sees a value in xxx-capable, it knows > that it must format some PDL string in order to realize the request. If it > sees a xxx-supported attribute it knows that is must supply a corresponding > xxx attribute in the print request or live with the default (the xxx > attribute at the Printer). > > Scott Perhaps, I didn't explain the idea clearly. I intended that the client wouldn't have to do the work of looking for both 'capable' and 'supported' attributes. Instead the server would do the same work and just send an 'allowed' attribute with the value of the 'capable' or 'supported' according to the two rules I defined (included further down in this email). With my rule, a client using IPP attributes only uses 'allowed' attributes and can be totally unaware of the 'capable' parameter to getAttributes. A client that will imbed all production attributes still uses the 'allowed' attributes, but specifies the 'capable' parameter to the getAttributes operation. Without my proposed change, such a client would have to look for 'capable' and 'supported' attribute when building a GUI -- perhaps not a big thing for this legacy support, but I would rather that legacy support be in a server as much as possible. > > > >>> Robert Herriot 05/05 2:21 PM >>> > Scott, > > Here is a change, that I propose for the model document. > > At the model meeting last Friday, we decided to add a suffix 'capable' > to production attributes in the Printer's JobTemplate group. The > 'capable' suffix was to allow a printer to distinguish between features > that it is capable of handling ('capable' suffix) and features that it > supports via IPP attributes ('supported' suffix). > > An output device that supports IPP would likely have the same values in > the 'supported' attribute as in the 'capable' attribute, in which case > it would not need to have any 'capable' attributes (according to the > Friday proposed rules). Whereas a print server that has to modify a > PostScript file, might show 'as-is' as the only supported values for > many production attributes, but would show a complete feature list for > each 'capable' attributes. > > I think we got the concept right, but we did not get the operation for > the client right. With Friday rule, when a client presents a set of > potential values for an attribute to an end-user, it implements one of the > following two rules: > > o Rule 1, the client is embedding production attributes in the PDL: > look for the 'capable' attributes first and then the 'supported' > attributes. > > o Rule 2, the client is explicitly including the IPP production > attributes: > look for the 'supported' attributes only. > > I think that this complexity, if it is implemented, should be on the > server side, and the client should see one set of allowed values for > each attribute. > > A client knows whether it is following rule 1 or 2 (above). So it > would be better for GetAttributes to have an additional parameter > called "allowed" whose value is 'supported' or 'capable' (default > 'supported'). This attribute tells the server whether to follow rule 1 > or 2 when producing the list of allowed values for each attribute. > > An administrator could see the 'supported' and 'capable' attributes, > but not an end-user. The end-user sees only 'allowed' values. > > Note: If an attribute on the server has a 'supported' suffix, but no > 'capable' suffix, then the 'capable' value is the same as the > 'supported' value. > > The words 'allowed', 'supported' and 'capable' may not be the right words > for these three concepts, but I haven't thought of any better ones yet. > > Comments? > > Bob Herriot > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From ipp-archive Tue May 6 17:09:41 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA28043 for ipp-outgoing; Tue, 6 May 1997 17:03:38 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 06 May 1997 15:03:20 -0600 From: Scott Isaacson To: bwagner@digprod.com, babakj@MICROSOFT.com, jkm@underscore.com Cc: ipp@pwg.org Subject: RE: IPP> Re: MOD - RE: Base printer implementation requireme Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Babak writes: >>> Babak Jahromi 05/05 10:06 PM >>> > I agree. I just don't see how network printing without print servers > could scale. 100% correct - it will not scale! However, on the other hand, in a work group environment with a very small number of users and a very small number of users, why FORCE a server based solution (at extra hardware and technical expertise cost) to the small work group (unless of course that means more IntranetWare or NT servers which are part of our business right? ;-) ...) Not all printers will be full blown printer servers, but SOME are and will be. I believe the IPP model right now allows for an embedded solution but does not force one nor does it preclude it. Some desktop printers will never be shared .. they will not have NICs, how can they ever embedd IPP. Some middle of the line work group printers which are only shared printers may have embedded IPP solutions. My 2cents. Scott From ipp-archive Tue May 6 17:22:40 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA28425 for ipp-outgoing; Tue, 6 May 1997 17:08:14 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 06 May 1997 15:07:57 -0600 From: Scott Isaacson To: David_Kellerman@nls.com, ipp@pwg.org Subject: Re: IPP> Re: MOD - RE: Base printer implementation requirements Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Dave, >>> 05/05 7:09 PM >>> > 3. Assuming your printer is capable of spooling is no panacea. For > ..... > when too many jobs queued up. I'd say if you're careful to consider > problematic scenarios in your protocol design, not just the happy > case, the spooled printer isn't that much better off than the > non-spooled one. Good explaination of why spooling maxing out is a common problem wether the spool size is 1 job or 5 million jobs. Once it maxes out, then there is a common error handling problem. The "no spooling" case is just on the very low end of the specturm of the "spooling" case. Scott From ipp-archive Tue May 6 17:26:42 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA28965 for ipp-outgoing; Tue, 6 May 1997 17:15:49 -0400 (EDT) Date: Tue, 6 May 1997 17:15:53 -0400 (EDT) From: JK Martin Message-Id: <199705062115.RAA28595@uscore.underscore.com> To: Robert.Herriot@Eng.Sun.COM Subject: Re: IPP>MOD reconsideration of model decision Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Bob, Ok, so I'm dense... I still can't quite come to grips with your explanation below, and I'm really trying! > Perhaps, I didn't explain the idea clearly. I intended that the client > wouldn't have to do the work of looking for both 'capable' and > 'supported' attributes. Instead the server would do the same work and > just send an 'allowed' attribute with the value of the 'capable' or > 'supported' according to the two rules I defined (included further down > in this email). With my rule, a client using IPP attributes only uses > 'allowed' attributes and can be totally unaware of the 'capable' > parameter to getAttributes. A client that will imbed all production > attributes still uses the 'allowed' attributes, but specifies the > 'capable' parameter to the getAttributes operation. Without my > proposed change, such a client would have to look for 'capable' and > 'supported' attribute when building a GUI -- perhaps not a big thing > for this legacy support, but I would rather that legacy support be in > a server as much as possible. Perhaps a line drawing or two would serve to clarify these situations? Something like a set of quick pictures of the scenarios you describe? ...jay From ipp-archive Tue May 6 17:31:15 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA29503 for ipp-outgoing; Tue, 6 May 1997 17:21:19 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 06 May 1997 15:20:50 -0600 From: Scott Isaacson To: ipp@pwg.org, jkm@underscore.com Subject: Re: IPP>MOD reconsideration of model decision Sender: ipp-owner@pwg.org Precedence: bulk Status: RO >>> JK Martin 05/06 12:34 PM >>> > > Which platforms support such a wire protocol shim? I thought Windows/NT > and Windows '95 did, but what about: > > Windows 3.1 > Windows for Workgroups > OS/2 2.x > OS/2 Warp > others? Windows 95 and Windows NT make a very open and explicit Printer Provider interface. In the DOS and Windows worlds, this has been implemented at a "redirector" - really deep, under the covers, fairly "unknown" to the OS itself, lives a redictor that traps interrupts and puts itself between the application and the low level OS port interfaces. If a job comes it it "steals" the job away from the OS and "redirects" it out to the network. It can also have configuration information in it os send along (not runtime) but preconfigured job attributes to cause certain behavior of the back end job processiong instrcutions. In the Novell world, this was done with the capture command. When I "captured" the port, jobs would be redirected with the parameters set a capturing time. There are also similar redirectors in the OS/2 and OS/2 Warp worlds, but I forget how formal the interfaces are (that is if it is a more low level "redirector" interface or a higher level "provider" interface). Scott From ipp-archive Tue May 6 17:51:04 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA01074 for ipp-outgoing; Tue, 6 May 1997 17:50:16 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 06 May 1997 15:50:05 -0600 From: Scott Isaacson To: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP>MOD reconsideration of model decision Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Roger, my comments are below >>> Roger K Debry 05/06 12:49 PM >>> > I think that I agree with Jay on this one. I fear that we are burdening > IPP with complexity in order to to solve a problem on a small set of > servers. Is the class of servers that changes controls in the Postscript > file a very large piece of the Universe? I suspect not. Rather than solve > every conceivable problem in this very large universe, we ought to > get back on track with the rule I thought we agreed to awhile back -- > to solve the few problems well that represent the largest customer > value. Over time the rest of the world will catch up and do things > **right**. Rule (1) below makes no sense to me. Clients (drivers) that > understand IPP (and therefore know what xxx-capable means) > ought not to imbed controls in the PDL, period! I think that adding > xxx-capable is adding undue complexity!!! An implemented xxx-capable attribute on a Printer means: This printer is capable of the features implied by the values of this attribute, however, in order to have a job realize these features, the instructions must be in the PDL, not in the external attributes. An implemented xxx-supported attribute on a Printer means: This printer supports the features implied by the values of this attribute, however, in order to have a job realize these features, the instructions must be in the Job attributes (not in the PDL) and if a similar instruction happens to be in the PDL, this printer can override that with the value in the Job attribute. xxx-capable allows us to work with existing, non IPP aware printer drivers. xxx-supported allows us to move to a better future with Job attribute, printer capabilities, and control all outside the PDL (the only reason it is all mumbled up in the PDL is becuase there has never really been a separate control channel to a printer, just a data channel). If we go with Jay's suggestion and just let a client "get what they get" if they submit job attributes as well as PDL encodded instructions, then maybe xxx-capable is just for the directory entry (the printer is capapable of some feature, get the right legacy driver, non IPP aware, and you are off and running with no job attributes). But I think it is useful for the directory at least, perhaps not for client queries directly at the printer. Scott From ipp-archive Tue May 6 18:26:05 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA01581 for ipp-outgoing; Tue, 6 May 1997 18:22:29 -0400 (EDT) From: Roger K Debry To: Subject: Re: IPP>MOD reconsideration of model decision Message-Id: <5030100002254604000002L042*@MHS> Date: Tue, 6 May 1997 18:24:15 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO It seems to get more complicated by the minute ... 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 05/06/97 04:21 PM --------------------------- ipp-owner @ pwg.org 05/06/97 03:29 PM Please respond to ipp-owner@pwg.org @ internet To: Robert.Herriot @ Eng.Sun.COM @ internet cc: ipp @ pwg.org @ internet Subject: Re: IPP>MOD reconsideration of model decision Bob, Ok, so I'm dense... I still can't quite come to grips with your explanation below, and I'm really trying! > Perhaps, I didn't explain the idea clearly. I intended that the client > wouldn't have to do the work of looking for both 'capable' and > 'supported' attributes. Instead the server would do the same work and > just send an 'allowed' attribute with the value of the 'capable' or > 'supported' according to the two rules I defined (included further down > in this email). With my rule, a client using IPP attributes only uses > 'allowed' attributes and can be totally unaware of the 'capable' > parameter to getAttributes. A client that will imbed all production > attributes still uses the 'allowed' attributes, but specifies the > 'capable' parameter to the getAttributes operation. Without my > proposed change, such a client would have to look for 'capable' and > 'supported' attribute when building a GUI -- perhaps not a big thing > for this legacy support, but I would rather that legacy support be in > a server as much as possible. Perhaps a line drawing or two would serve to clarify these situations? Something like a set of quick pictures of the scenarios you describe? ...jay From ipp-archive Wed May 7 07:56:11 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA03090 for ipp-outgoing; Wed, 7 May 1997 07:54:09 -0400 (EDT) Message-Id: <9705071154.AA00157@cabeza.cp10.es.xerox.com> X-Mailer: exmh version 1.6.7 5/3/96 To: ipp@pwg.org Subject: IPP> SEC - Draft document prereading for IPP Security phone conference Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 7 May 1997 04:54:10 PDT From: John Wenn Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Below is a rough draft of a security document. This will be discussed at the next IPP Security conference call (5/8). Two tables didn't convert nicely to text, they will be distributed later today (possibly pdf files on the web site?). The previous IETF draft on security dealt with security terms and standards. This draft tries to address IPP security requirements and examines various standard security protocols to see how they meet the requirements. --------------------------------------------- May 5, 1997 Expires November 5, 1997 Internet Printing Protocol/1.0: Security Abstract This document is one of a set of documents which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing on the Internet. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (ISO/IEC 10175 DPA) standard, which describes a distributed printing service. The full set of IPP documents includes: Internet Printing Protocol/1.0: Requirements Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Security Internet Printing Protocol/1.0: Protocol Specification This document deals with the security considerations for IPP. Table of Contents 1.0 Introduction 2.0 Internet Printing Scenarios 2.1 Printing public documents on well known printers 2.2 Printing private documents on well known printers 2.3 Printing public documents on outside printers 2.4 Printing private documents on outside printers 2.5 Printing public documents by reference 3.0 Security Considerations of IPP Operations 3.1 Submit Job 3.2 Cancel Job 3.3 List Jobs 4.0 Security Solutions 1.0 Introduction It is required that the Internet Printing Protocol be able to operate within a secure environment. Wherever possible, IPP ought to make use of existing security protocols and services. IPP will not invent new security features when the requirements described in this document can be met by existing protocols and services. Examples of such services include Secure Sockets (SSL), Digest Access Authentication in HTTP, and the Content MD-5 Header Field in MIME. It is difficult to anticipate the security risks that might exist in any given IPP environment. For example, if IPP is used within a given corporation over a private network, the risks of exposing print data may be low enough that the corporation will choose to not use encryption on that data. However, if the connection between the client and the Printer is over a public network, the client may wish to protect the content of the information during transmission through the network with encryption. Furthermore, the value of the information being printed may vary from one use of the protocol to the next. Printing payroll checks, for example, might have a different value than printing public information from a file. Since we cannot anticipate the security levels or the specific threats that any given IPP print administrator may be concerned with, IPP must be capable of operating with different security mechanisms and security policies as required by the individual installation. Security policies might vary from very strong, to very weak, to none at all, and corresponding security mechanisms will be required. This document will describe the various scenarios within which IPP must operate. It will then describe the security concerns of the various IPP operations. Finally, it will describe the standard security solutions that can be used for addressing the requirements. 2.0 Internet Printing Scenarios The scenarios described here are those expected to be used in IPP 1.0. There are explicitly several possible arrangements that are outside the scope of the initial solution. The security needs of the IPP are derived from two considerations. First is how well known the server is to the client. An environment where the clients and servers are well known to each other does not need as strong authentication as clients and servers that are working together for the first time. Second is the sensitivity of the document. A public document does not need as strong privacy as a document with sensitive information. 2.1 Printing public documents on well known printers This scenario happens frequently. Printing public information on a well known printer (e.g. local or part of an intranet) has minimal security concerns. 2.2 Printing private documents on well known printers If one prints private information, the contents of the document should be protected. While the identity of the printer may be well known, the document must still guarded against such threats as eavesdropping. The strongest security requirement here is that of privacy. 2.3 Printing public documents on outside printers When the printer and client are not well known to each other, the security requirement of authentication is added. There are two sides to authentication, (1) client authentication - where the client authenticates itself to the printer. This is part of client authorization, where only authorized clients can use the printer resource. (2) printer authentication - this protects the client against others pretending to be the printer. Of the two, client authentication is almost always used, with printer authentication being the weaker requirement. 2.4 Printing private documents on outside printers Printing sensitive information on a printer not well known to the client requires full security. This means privacy of the document contents and mutual authentication between the client and printer. 2.5 Printing public documents by reference Another usage of IPP is print by reference. Here a reference (e.g. URL) of a document is given to the printer, and the printer retrieves the document. In 1.0, only public documents will be printed by reference. Printing by reference of private documents would require that the client grant the printer some authorization information that the printer could then use to retrieve the document. This granting of authorization is not currently implemented in the internet security infrastructure (although work in this area is going on). 3.0 Security Considerations of IPP Operations Various IPP operations have security concerns. They are Submit Job, Cancel Job and List Jobs. One aspect of IPP is that the servers for the three operations may be different, even when following the life of a single print job. This means that a security context may have to be established with each server independently. If the different operations occur on the same server, a security context may be reused between operations (if the underlying security mechanism allows long lived security contexts). 3.1 Print This was the basis of the previous security discussion. For submitting a print job, the issues of privacy of the document being transferred and the authentication of client with printer are all possible. 3.2 Cancel Job Cancel Job security is an authorization issue. Is the client in attempting the operation authorized to do so? To securely determine the answer, client authentication is a requirement. 3.3 Get Jobs Whether the Get Jobs operation has security implications depends on the policy set by the printer. One common policy is for the complete job queue is returned to anyone who asks. This policy has no security. For more secure printers, a common policy is to list the details only on the print jobs owned by the client, while giving little or no details about other jobs. This policy requires client authentication to match the client to the print jobs. 4.0 Security Solutions This section is an examination of potential security solutions. As described in the introduction, these are all existing security protocols. It should be noted that the final security solutions chosen depends on the final IPP protocol. Not all of the potential solutions are applicable to all the IPP protocol choices. The security needs of the scenarios discussed in section two can be divided into the following categories. 1) no security (sections 2.1 and 2.5) 2) privacy only (section 2.2) 3) client authentication and authorization (section 2.3) 4) complete security, meaning mutual authentication, authorization and privacy (section 2.4) Category 1 If the client wants no security, it can send the print job, i.e., the job content and the job attributes to the printer direct. The printer will print the job for the client. Cases where there is no need for security or where security is difficult to obtain include the print by reference URL. Category 2 If the client needs privacy only, client could use PGP with the key ring, with probably one key in the ring. This key is used to encrypt a session key that could be used for privacy. S/MIME could also be used. S/MIME requires sender's authentication and may well fall into the third category. For channel only security, one could use SSL2, but this requires client authentication and may well fall into the third category. However, if a password is sent in the clear to the lower security layer that does encryption, one could use S/MIME or SSL2 or SSL3 or TLS. Category 3 The third category requires one sided authentication that is also used for authorization. The password in fact is used for authorization purposes, and is encrypted by the lower security layer. S/MIME and SSL2 are good examples. TLS supports both one sided and mutual authentication and can also be used for this category. Category 4 The fourth category requires mutual authentication, integrity, and privacy. Although, S/MIME provides all except mutual authentication, and two way mail can provide mutual authentication, we leave S/MIME into the third category. TLS and SSL3 are good channel level security providers in this category. A protocol selection should be made by IPP depending upon the security level section made by the client, and the right hand shake messages should be passed. Based on the key information on either side, job information including content and attributes are encrypted and send either using object security or channel security. For knowing the status of the job, or for performing more operations on the job, the session identifier could be reused if the call needs to be made to the same server. Otherwise the whole set of selections needs to be made, the security level can be inherited from the job submission or made independently. Event notification about the completion of the job can be made either securely, or need not have any security at all. The security features for this can be decided at the job submission time in the IPP protocol. (Carl-Uno: HOW, do we need an extra attribute for this?) Security in IPP - Comparison of underlying technologies [Table 1 here] Summary of the findings about security service applicability for IPP: TLS - Transport Layer Security: Seems OK, is near completion in the IETF and existing SSL product are probably compliant, or can be made compliant without much effort. SSL 2 and SSL 3 - Secure Socket Layer: Proprietary solution initially by Netscape, but TLS is very close. Cannot be used as reference in an IETF RFC. PGP/MIME - Pretty Good Privacy MIME variant: The original PGP is widely deployed (but not much liked by the US government). The PGP/MIME version is now being worked on but is still not out, not yet stable, and not yet implemented and deployed. Timing problem. S/MIME - Secure MIME: Currently a private implementation from RSA. Although coming out as product from a number of vendors, unlikely to make it on the IETF standards track unless RSA decides to release their proprietary products as open standards. This is unlikely to happen in the time frame that we need. SASL - Simple Authentication and Session Layer: This seems to be winning mind share in the IETF, but is really only a security feature negotiation protocol and does not provide any security services in itself. Hence quite limited usefulness. Also it is too new to be finished in the time frame that we need, it is not yet even an Internet-Draft from a WG. HHTP 1.1 Security Extensions, RFC 2069: This provides some limited security services, mainly only client side authentication. Security specialists frown upon this solution because it uses unencrypted user names and passwords. However, this solution could be used in combination with a protocol that provides for secure transport. SHTTP - Secure HTTP: Although on the IETF standards track, this seems to lack some important features and does not seem to go anywhere in the market place. Security types for transmitting documents There are two types of security that could be used for transmitting documents securely: channel security and object security. In the former case, the transmission medium is made secure by mutual authentication, and encrypting everything between the client and server by the transmission medium. The transmission medium can be any of the following: transport layer (SSL), network layer (IPV6) or higher layers (secure FTP or Telnet). In the latter case of object security, each object is encrypted and sent over either a secure or an insecure channel. The recipient has the corresponding key to decrypt the object and get the contents. Most of the widely used object security mechanisms are S/MIME and PGP/MIME which are email systems. From table 1, all rows except those corresponding to S/MIME and PGP/MIME provide channel security. Comparison of technologies implementing object security Technology Certification structure Scaleability Comments S/MIME Hierarchies with roles of user and certifier formalized Scaleable from small groups to large enterprises. Interoperability with focus on email. PGP Key-ring or web-of-trust Small work groups only Specification and application. PEM Hierarchy Large enterprises. Not easy to scale downward RFC 1421-1424. Cannot handle MIME - 7bit text only. MOSS Hierarchy Scaleable. Not interoperable between different implementations Specific features of various technologies: S/MIME: (Secure/Multipurpose Internet Mail Extensions) Security services and features offered: a. Sender Authentication is provided using digital signatures. The recipient reads the sender's digital signature. Non-repudiation of origin is also achieved using digital signatures. b. Privacy (using encryption). c. Integrity is achieved by using hashing to detect message tampering. d. Provides anonymity by using anonymous e-mailers and gateways. The digital signature and the original message are placed in an encrypted digital envelope. e. Supports DES, Triple-DES, RC2. f. X.509 digital certificates supported. g. Supports PKCS #7(cryptographic message formatting, architecture for certificate-based key management) and #10(message for certification request). Usage, implementation and interoperability: a. Used to securely transmit e-mail messages in MIME format. b. Public domain mailer RIPEM available. c. RSA's toolkit TIPEM (Toolkit for Interoperable Privacy Enhanced Messaging) can be used to build S/MIME clients. It includes C object code for digital envelopes, digital signatures and digital certificate operations. d. Any two packages that implement S/MIME can communicate securely. e. Compatible with IMAP (Internet Message Access Protocol - RFC 1730). f. S/MIME works both on the Internet or any other e-mail environment. Transport Layer Security 1.0 (TLS) TLS is a two layered protocol. The lower level TLS Record Protocol that sits on top of TCP and the TLS Handshake Protocol. The TLS Handshake protocol consists of a suite of three sub protocols which are used to allow peers to agree upon security parameters for the record layer, authenticate themselves, instantiate negotiated security parameters, and report error conditions to each other. TLS is application protocol independent. It is based on SSL v3. Security services and features offered: a. Privacy: (optional). Uses symmetric keys. Encryption done by the TLS Record Protocol. The keys are generated for each connection by the TLS Handshake Protocol. b. Integrity: Using keyed MAC. Hash functions (SHA, MD5) are used for MAC computations. c. Authentication (Both one-sided and Mutual): The TLS Handshake Protocol uses public key cryptography. Encryption algorithms are negotiated. Usage, implementation and interoperability: a. Interoperability: Independent applications can be developed utilizing TLS and successfully exchange cryptographic parameters without knowledge of each others code. Cannot interoperate with SSL 3.0 b. Extensibility: New encryption methods can be incorporated as necessary. c. Efficiency: To reduce the number of sessions that need to be established from scratch, TLS provides session caching scheme. d. Other operations: Compression, fragmentation is done by the TLS Record Protocol. Handshake protocol steps: 1. Exchange hello messages to agree on algorithms, exchange random values, and check for session resumption. 2. Exchange the necessary cryptographic parameters to allow the client and server to agree on a premaster secret. 3. Exchange certificates and cryptographic information to allow the client and server to authenticate themselves. 4. Generate a master secret from the premaster secret and exchanged random values. 5. Provide security parameters to the record layer. 6. Allow the client and server to verify that their peer has calculated the same security parameters and that the handshake occurred without tampering by an attacker. [Table 3 here] Note: The https protocol uses port 443 regardless of which security protocol it is using. From ipp-archive Wed May 7 10:06:12 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA03782 for ipp-outgoing; Wed, 7 May 1997 10:04:15 -0400 (EDT) From: Roger K Debry To: , Subject: Re: IPP>MOD reconsideration of model decision Message-Id: <5030100002267294000002L042*@MHS> Date: Wed, 7 May 1997 10:04:42 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO 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 05/07/97 07:35 AM --------------------------- SISAACSON @ novell.com 05/06/97 04:20 PM To: Roger K Debry/Boulder/IBM, ipp @ pwg.org@internet cc: Subject: Re: IPP>MOD reconsideration of model decision Roger, my comments are below >>> Roger K Debry 05/06 12:49 PM >>> > I think that I agree with Jay on this one. I fear that we are burdening > IPP with complexity in order to to solve a problem on a small set of > servers. Is the class of servers that changes controls in the Postscript > file a very large piece of the Universe? I suspect not. Rather than solve > every conceivable problem in this very large universe, we ought to > get back on track with the rule I thought we agreed to awhile back -- > to solve the few problems well that represent the largest customer > value. Over time the rest of the world will catch up and do things > **right**. Rule (1) below makes no sense to me. Clients (drivers) that > understand IPP (and therefore know what xxx-capable means) > ought not to imbed controls in the PDL, period! I think that adding > xxx-capable is adding undue complexity!!! An implemented xxx-capable attribute on a Printer means: This printer is capable of the features implied by the values of this attribute, however, in order to have a job realize these features, the instructions must be in the PDL, not in the external attributes. RKD> This seems a bit of an oxymoron. If a client is capable of RKD> understanding what an xxx-capable attribute is at all, then RKD> it must be ipp-aware. If it is ipp-aware, it is a new driver RKD> which ought to exploit ipp by setting controls as ipp RKD> attributes, not imbedding them in the PDL. An implemented xxx-supported attribute on a Printer means: This printer supports the features implied by the values of this attribute, however, in order to have a job realize these features, the instructions must be in the Job attributes (not in the PDL) and if a similar instruction happens to be in the PDL, this printer can override that with the value in the Job attribute. RKD> How do I change attributes on a page-by-page basis then? xxx-capable allows us to work with existing, non IPP aware printer drivers. RKD> I'm really lost --- sorry to be dense but I don't understand RKD> how xxx-capable allows a non-ipp aware driver to do anything RKD> (since it is non-ipp aware it doesn't understand any ipp RKD> attributes so how does it know what ipp-capable means?) Are RKD> we are worried about a client which takes an existing PDL RKD> file and submits it for printing? If so, what does it care RKD> about xxx-capable for since it does not build the PDL. If we RKD> are worried about some clients that take the existing PDL and RKD> add controls to it, I'd ask once again how many of those are RKD> there and does that number justify this added complexity. xxx-supported allows us to move to a better future with Job attribute, printer capabilities, and control all outside the PDL (the only reason it is all mumbled up in the PDL is becuase there has never really been a separate control channel to a printer, just a data channel). If we go with Jay's suggestion and just let a client "get what they get" if they submit job attributes as well as PDL encodded instructions, then maybe xxx-capable is just for the directory entry (the printer is capapable of some feature, get the right legacy driver, non IPP aware, and you are off and running with no job attributes). But I think it is useful for the directory at least, perhaps not for client queries directly at the printer. RKD> Think about this alternative. Just as we have agreed that RKD> downloading and installing a print driver is outside the RKD> scope of IPP, why not declare the way that *legacy* drivers RKD> get information about the printer, i.e. xxx-capable, to be RKD> outside the scope of IPP. That's the way that drivers work RKD> today, they use ppd files or other side files which describe RKD> capabilities of the device required to generate the correct RKD> ouput. We have provided an attribute which points to a place RKD> where drivers and driver installers live. Why not let ppd files RKD> or other side files live at the same place? Now when I install RKD> a legacy device as an IPP printer I get the driver *and* the RKD> ppd (or whatever) files that the driver would normally use anyway. Scott From ipp-archive Wed May 7 11:21:13 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA04977 for ipp-outgoing; Wed, 7 May 1997 11:17:35 -0400 (EDT) Message-Id: <33709CDC.752B@dazel.com> Date: Wed, 07 May 1997 10:16:44 -0500 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 -- xxx-supported attributes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I was assigned the following task from the last model meeting: >> 2. Since we are getting rid of tags, it is not acceptable to live with the >> ambiguity as clarified by Tom in last weeks minutes. That is xxx-supported >> values are: 1) client desires to >> override the PDL (the same instruction is in the PDL) or 2) client desires >> action only when the information is not in the PDL. This was once being >> solved by the embedded and embedded-only tags. Since we have no tags, the >> proposal is to define a set of xxx-capable attributes to go along with the >> xxx-supported attributes. Jim Walker took an action item to write this up >> can clarify semantics of xxx-supported, xxx-capable and best-effort and >> embedded instructions in PDL. Here are the three alternatives as I see them: (1) The server advertises the productions that it is capable of supporting, assuming that the client inserts the appropriate printer- and PDL- specific sequence in the PDL data stream. This is the situation as we have today in the PC driver world, and the situation that most seem to think that we ought to try to get away from. (2) The server advertises the productions that it can support, assuming that the client sends the appropriate IPP attribute in the job (or document) control stream, and does not insert any conflicting production instructions in the PDL data stream. This is the ideal situation in the UPD world. (3) The server advertises the productions that it can support, whether the client sends the appropriate IPP attribute, and/or has the same or conflicting production instructions in the PDL data stream. This is the robust case that everybody *thinks* they want, but I would argue that this situation is untenable in general (e.g., I pass a document that is already 4-up'ed, and tell the server that I want it 2-up'ed, and, by the way, best-effort is do-not-substitute). I believe that IPP printers ought to *only* support option (2) above. First of all, we can do option (1) today without the IPP printer advertising its capabilities. In this case, the driver would use PPD files (or whatever other information it already has or wants today) and generate an appropriate PDL data stream, and forward that data stream on to an IPP printer with few, if any, IPP attributes. The driver would not need to query the capabilities of the printer, as it could just get that information the same way that it does today. After all, if we were going to modify the driver to query the IPP printer, why not go ahead and modify it to set the appropriate attributes in the job control stream, as in option (2), rather than in the data stream. Furthermore, knowing the capabilities supported in option (1) does not help with pre-generated files either; the user does not know (unless they have software to scan the file) what capabilities were utilized in generating the data file, so it does not help that they know what capabilities the printer will support. As I have already stated above, I do not believe that option (3) is supportable, especially if we try to tie this together with the best-effort attribute. If we say that the IPP printer can only advertise the supported attributes that it can override what is specified in the data file, then will any IPP printers be able to any supported attributes. In other words, if I am a print server that fronts a duplex printer, yet I am unable to guarantee that I can override a simplex/duplex capability specified in a PDL data stream, then I cannot advertise sides-supported. So, I believe that option (2) is the only option that we should attempt to specify in IPP, especially version 1.0. With this option, we can say that the xxx-supported attribute describes those capabilities that the IPP printer can support if the associated xxx attribute is specified in the print job. If a conflicting instruction is specified in the PDL data stream, then the results are undefined. comments welcome... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-archive Wed May 7 11:21:14 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA04966 for ipp-outgoing; Wed, 7 May 1997 11:16:41 -0400 (EDT) Message-Id: <01BC5AD8.4059E440@PZEHLER.ocp.mc.xerox.com> From: Peter Zehler To: "'IPP Redirector'" Subject: RE: IPP> Re: MOD - RE: Base printer implementation requirements Date: Wed, 7 May 1997 08:15:42 PDT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk Status: RO All, >From Jay's and Scott's conversation. ____________ JKM> As far as deriving base constraints goes, to me the real question = is: JKM> JKM> Must an "IPP Printer" must be able spool print jobs? JKM> I would like to see an answer of "Yes", but clearly this is where = desktop JKM> printers (and many, if not most, network printers) fail to perform. = And I JKM> believe this is usually the reasons behind most case of "we can't = do that JKM> due to printer limitations." SAI>I fail to see why a "yes" answer matters? If someone decides to = implement SAI>IPP in a printer that can not spool, what changes? If it is too = busy SAI>processing one job and another comes in from another client, it = returns a SAI>"busy" or a "out of spool space" just as in the case where a server SAI>implementation supports 2000 spooled jobs and the 2001st job comes = in. =20 SAI>Will anybody implement IPP in a printer like this? Probably not. = Does the SAI>model preclude them from doing so? No. Will this type of printer = ever be SAI>used as as a shared network printer? Probaly not, but if it is, and = it does SAI>not embed IPP then it can be front ended by a "server" that does. __________ PJZ: I have been listening. I am prototyping IPP on a printer that can only = accept and process a job at a time. I chose this printer specifically = to check the lower bounds of an IPP implementation. I have to agree = with Scott. Spooling is not the printer feature that determines if a = printer is capable of supporting IPP. IPP will be sitting (somewhere) = on top of TCP. The flow control capabilities of this layer of the = protocol should allow me to gate the inflow of PDL data while the = printer "catches up" with the PDL stream. I also have the job-k-octets = to limit the job size for a low-end printer. =20 This class of printer will not be IPP feature rich. The printer itself = will not be feature rich. It is true some clients will be denied = service while the printer is busy. All services must handle the = "capacity + 1" problem. IPP seems to handle this problem. There is = still the issue for the application to determine when it should time = out. IPP level print job submission operations should help accomodate = application level timeout detection. We will have to see where the = print operation semantics discussion ends up. Will this type of printer be used as as a shared network printer? Yes = it can, if the workload is low enough. If IPP service is not available = often enough for the site's needs, an IPP spooler can be put between the = client and the printer. A bigger printer could also be used. The factor that will determine if a printer can be IPP compliant will be = the complexity of IPP, IPP conformance specification, and the available = printer resources that are available for IPP. _________________________________ Pete = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 =20 From ipp-archive Wed May 7 11:31:26 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA05772 for ipp-outgoing; Wed, 7 May 1997 11:30:50 -0400 (EDT) Message-ID: <3370A013.7701@parc.xerox.com> Date: Wed, 7 May 1997 08:30:27 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> [Fwd: Re: Template for Masinter-form] Content-Type: multipart/mixed; boundary="------------15DA1EC34FF1" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO This is a multi-part message in MIME format. --------------15DA1EC34FF1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit If you want to use multipart/form-data, it's apparently destined for standards track. Larry --------------15DA1EC34FF1 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from alpha.xerox.com ([13.1.64.93]) by casablanca.parc.xerox.com with SMTP id <71841>; Wed, 7 May 1997 02:53:16 PDT Received: from tyholt.uninett.no ([129.241.131.12]) by alpha.xerox.com with SMTP id <18061(6)>; Wed, 7 May 1997 02:53:11 PDT Received: (from daemon@localhost) by tyholt.uninett.no (8.7.6/8.7.3) id LAA00912 for directorate-real; Wed, 7 May 1997 11:52:39 +0200 (METDST) Received: from munken.uninett.no (munken.uninett.no [129.241.131.10]) by tyholt.uninett.no (8.7.6/8.7.3) with SMTP id LAA00905; Wed, 7 May 1997 11:52:31 +0200 (METDST) 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 From: Harald.T.Alvestrand@uninett.no To: Steve Coya cc: iesg-secretary@ietf.org, moore@cs.utk.edu, directorate@apps.ietf.org Subject: Re: Template for Masinter-form In-reply-to: Your message of "Tue, 29 Apr 1997 08:08:22 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 7 May 1997 02:53:27 PDT Message-ID: <7059.862998807@munken.uninett.no> Sender: unknown@uninett.no The IESG has approved the Internet-Draft "Returning Values from Forms: multipart/form-data" as a Proposed Standard. The IESG contact person is Harald Alvestrand and Keith Moore. Technical Summary This specification defines an Internet Media Type, multipart/form-data. Its intended use is as a way of returning a set of values as the result of a user filling out a form. Typical applications include form values generated by HTML forms and submitted by HTTP post or by electronic mail, but the format is independent of those contexts. The definition of multipart/form-data is derived from its original definition in RFC 1867, which was Experimental. Working Group Summary No basic objections have been raised. Alternative methods have been suggested, but have not been written up, so alternative technology does not exist at the moment. Protocol Quality The spec has been reviewed for the IESG by Harald T. Alvestrand There are implementations; see the URL ftp://ftp.parc.xerox.com/pub/masinter/file-upload-impl.txt for details. --------------15DA1EC34FF1-- From ipp-archive Wed May 7 11:41:15 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA06328 for ipp-outgoing; Wed, 7 May 1997 11:38:48 -0400 (EDT) From: Roger K Debry To: Subject: IPP> MOD -- xxx-supported attributes Message-Id: <5030100002270780000002L002*@MHS> Date: Wed, 7 May 1997 11:40:29 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I agree with your conclusions. 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 05/07/97 09:37 AM --------------------------- ipp-owner @ pwg.org 05/07/97 09:27 AM Please respond to walker@dazel.com @ internet To: ipp @ pwg.org @ internet cc: Subject: IPP> MOD -- xxx-supported attributes I was assigned the following task from the last model meeting: >> 2. Since we are getting rid of tags, it is not acceptable to live with the >> ambiguity as clarified by Tom in last weeks minutes. That is xxx-supported >> values are: 1) client desires to >> override the PDL (the same instruction is in the PDL) or 2) client desires >> action only when the information is not in the PDL. This was once being >> solved by the embedded and embedded-only tags. Since we have no tags, the >> proposal is to define a set of xxx-capable attributes to go along with the >> xxx-supported attributes. Jim Walker took an action item to write this up >> can clarify semantics of xxx-supported, xxx-capable and best-effort and >> embedded instructions in PDL. Here are the three alternatives as I see them: (1) The server advertises the productions that it is capable of supporting, assuming that the client inserts the appropriate printer- and PDL- specific sequence in the PDL data stream. This is the situation as we have today in the PC driver world, and the situation that most seem to think that we ought to try to get away from. (2) The server advertises the productions that it can support, assuming that the client sends the appropriate IPP attribute in the job (or document) control stream, and does not insert any conflicting production instructions in the PDL data stream. This is the ideal situation in the UPD world. (3) The server advertises the productions that it can support, whether the client sends the appropriate IPP attribute, and/or has the same or conflicting production instructions in the PDL data stream. This is the robust case that everybody *thinks* they want, but I would argue that this situation is untenable in general (e.g., I pass a document that is already 4-up'ed, and tell the server that I want it 2-up'ed, and, by the way, best-effort is do-not-substitute). I believe that IPP printers ought to *only* support option (2) above. First of all, we can do option (1) today without the IPP printer advertising its capabilities. In this case, the driver would use PPD files (or whatever other information it already has or wants today) and generate an appropriate PDL data stream, and forward that data stream on to an IPP printer with few, if any, IPP attributes. The driver would not need to query the capabilities of the printer, as it could just get that information the same way that it does today. After all, if we were going to modify the driver to query the IPP printer, why not go ahead and modify it to set the appropriate attributes in the job control stream, as in option (2), rather than in the data stream. Furthermore, knowing the capabilities supported in option (1) does not help with pre-generated files either; the user does not know (unless they have software to scan the file) what capabilities were utilized in generating the data file, so it does not help that they know what capabilities the printer will support. As I have already stated above, I do not believe that option (3) is supportable, especially if we try to tie this together with the best-effort attribute. If we say that the IPP printer can only advertise the supported attributes that it can override what is specified in the data file, then will any IPP printers be able to any supported attributes. In other words, if I am a print server that fronts a duplex printer, yet I am unable to guarantee that I can override a simplex/duplex capability specified in a PDL data stream, then I cannot advertise sides-supported. So, I believe that option (2) is the only option that we should attempt to specify in IPP, especially version 1.0. With this option, we can say that the xxx-supported attribute describes those capabilities that the IPP printer can support if the associated xxx attribute is specified in the print job. If a conflicting instruction is specified in the PDL data stream, then the results are undefined. comments welcome... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-archive Wed May 7 13:06:21 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA07014 for ipp-outgoing; Wed, 7 May 1997 13:03:33 -0400 (EDT) Message-Id: <3.0.1.32.19970507095850.0114cfe0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 7 May 1997 09:58:50 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC - Security texts on FTP server Cc: jwenn@cp10.es.xerox.com, manchala@cp10.es.xerox.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO John Wenn sent out a message with the new draft text for discussion to the mailing list last night. I have now stored a .TXT version in the new_SEC folder under the imaginative name of: security.txt (I made a few edits to it to make it a little more readable). I have also stored a file called: SEC-rationale.doc which contains the second half of the security.txt document, but including the three tables, which did not come through as readable in the .TXT version. As this part is mainly providing some background material (which we are not proposing to put into the actual I-D later), I hope this is acceptable for now. I will also provide a .PDF version of the .DOC file this evening (when I am back at my home machine that runs Win95). My thanks to John Wenn and Daniel Manchala for putting this text together. Regards, Carl-Uno From ipp-archive Wed May 7 13:26:15 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA07626 for ipp-outgoing; Wed, 7 May 1997 13:23:01 -0400 (EDT) Date: Wed, 7 May 1997 13:22:36 -0400 (EDT) From: JK Martin Message-Id: <199705071722.NAA01162@uscore.underscore.com> To: walker@dazel.com Subject: Re: IPP> MOD -- xxx-supported attributes Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Jim, Thanks for the outstanding analysis and summary. > (2) The server advertises the productions that it can support, assuming > that the client sends the appropriate IPP attribute in the job (or > document) control stream, and does not insert any conflicting > production instructions in the PDL data stream. This is the ideal > situation in the UPD world. > > [...] > > I believe that IPP printers ought to *only* support option (2) above. > > [...] > > So, I believe that option (2) is the only option that we should attempt to > specify in IPP, especially version 1.0. With this option, we can say that > the xxx-supported attribute describes those capabilities that the IPP > printer can support if the associated xxx attribute is specified in the > print job. If a conflicting instruction is specified in the PDL data > stream, then the results are undefined. I concur with your conclusions and recommendations up and down the line. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-archive Wed May 7 14:51:17 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA08838 for ipp-outgoing; Wed, 7 May 1997 14:50:57 -0400 (EDT) Mime-Version: 1.0 Date: Wed, 7 May 1997 14:55:45 -0400 Message-ID: <00014604.1337@digprod.com> From: bwagner@digprod.com (Bill Wagner) Subject: Re[2]: IPP> Re: MOD - RE: Base printer implementation requir To: "'IPP Redirector'" Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: ipp-owner@pwg.org Precedence: bulk Status: RO In theory, at least, any spooler can be sent a job larger than it can store (at least at the time). Therefore, unless the model provides for identifying the total job size before starting transmission, it would be possible that even a "spooling printer" would have to consume some portion of the job before being able to accept the entire job. Therefore, as has been suggested, a 'non-spooling' printer can be considered as one providing very limited spooling capacity. But the message exchange seems to have avoided addressing the basic statement that prompted Jay's request that only spooling printers (or servers) be considered. Harald had asked: "Does the IPP print model have to include the possibility of the first portion of the document being printed before the request is completely sent to the printer?" Tom's response (in part) was: "We want to allow IPP to be implemented in a printer that doesn't have to spool the data before starting to print. In other words, we want to allow IPP to be used by simple desktop printers. Unfortunately, this does require that resources be declared up front, not at the end." Although I happen to agree with Tom, and understood this to be an IPP objective, perhaps it is not the proper answer to Harald's question. Perhaps, the 'loaded' terms in the answer (desktop, sooler) distracted us from the question. I therefore would like to resubmit the question to see if there is consensus to to whether: "the IPP print model [must] include the possibility of the first portion of the document being printed before the request is completely sent to the printer?". Bill Wagner, Osicom/DPI From ipp-archive Wed May 7 15:21:16 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA09362 for ipp-outgoing; Wed, 7 May 1997 15:21:03 -0400 (EDT) Message-Id: <9705071920.AA05798@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, 7 May 1997 12:18:00 PDT To: Scott Isaacson From: Tom Hastings Subject: IPP> MOD - Comments on the New Attributes Table Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Here are my comments on the attributes table that Scott posted. It will help us a lot in updating the document to use this table as a work sheet. Thanks for doing. Tom At 13:01 05/06/97 PDT, Scott Isaacson wrote: >I posted the following: > >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/atts-rev-4.doc >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/atts-rev-4.pdf >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/atts-rev-4.txt > >This shows the relationship between Job attributes, Printer default >attributes, >supported, and the new proposed "capable" attributes. > >Take a look and we will discuss on Friday. > >Scott 1. Clarify that Opt/Man means optional/mandatory for the Printer to implement (not the requester to implement, not for the requester to supply in a request. 2. I think we need the Opt/Man for every box in the table, not just for rows. Since most are optional for Printer conformance, just add an * to each cell that is mandatory for a Printer to implement. 3. If the job-name is not queriable then how can the client find out if the Printer implements job-name? I suggest that the default value of a text attribute be either the empty string, or a string with just an "*" in it. We need to pick one of those forms and specify default text that way. 4. A lot of 1setOf got changed to setOf. I'm still trying to sell you all on the idea that we not have setOf at all where an attribute can have no value or only for the very few attributes whose values are registered by some other source, for which we can't get a distinguished 'none' value. Reasons for opposing emtpy attribute values in the client to Printer or in responses from the Printer to the Client: a. Most attributes have a distinguished value for none already, so have a second way, namely an attribute with no value, is more complex and will likely lead to inoperatibility problems where some implementation send one form, some send the other, and all implemementations have to accept both forms, in order to achieve interoperability. b. Its very confusing to users to see or specify an attribute with no values. Only programmers and mathematicians are comformatble with empty sets. c. When advertizing the xxx-supported, we would need a way to indicate whether an empty value is supported or not! Ugh. It so much simpler for the xxx-supported to include the explicity 'none' value as one of the values that are supported, if that is a legal value and to omit the 'none' value from the xxx-supported attribute if 'none' is not supported. d. If a Printer doesn't implement an attribute at all or doesn't implement an attribute for a particular document-format, the Printer just omits returning that attribute at all on a GetAttributes operation. So the only attribute that I think there might be a case for setOf, instead of 1setOf, is notification-addresses, where URLs are the values. 5. I suggest that medium be changed from type 2 keyword to type 4 keyword. The IPP standard can still have the long list of standard values for type 4 keywords. 6. Need to add Opt/Man for the other tables. If add * to each cell, then fine. 7. For consistency with the rest of the attributes in the second table, how about adding "job-" to "submission-time" and "completion-time"? 8. document-URL - need way to find out what schemes are supported for documents. From ipp-archive Wed May 7 15:51:19 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA09865 for ipp-outgoing; Wed, 7 May 1997 15:46:40 -0400 (EDT) Date: Wed, 7 May 1997 15:39:10 -0400 (EDT) From: JK Martin Message-Id: <199705071939.PAA01922@uscore.underscore.com> To: pzehler@ocp.mc.xerox.com Subject: RE: IPP> Re: MOD - RE: Base printer implementation requirements Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Peter, > I am prototyping IPP on a printer that can only accept and process a > job at a time. I chose this printer specifically to check the lower > bounds of an IPP implementation. > > [...] > > It is true some clients will be denied service while the printer is > busy. All services must handle the "capacity + 1" problem. IPP seems > to handle this problem. How does IPP handle the problem where a printer implementation only accepts a single connection at a time, where all other connection requests are denied (or ignored) until the current job has completed? In the marketplace today, there are *lots* of printers with network interfaces that accept only a single LPD connection at any one time; if a job (or any other LPD service request) is being handled, any connection attempt simply fails with a TCP-level "time-out" indication. As client software developers, this situation gives us tremendous grief, as we are unable to discern between "the printer is too busy to answer you right now" and "the printer is not responding on the network". It is my ardent hope that printer vendors strive to develop network printers capable of saying "I'm too busy right now, try later", rather than simply ignoring the connection attempt. > There is still the issue for the application to determine when it > should time out. IPP level print job submission operations should help > accomodate application level timeout detection. Thanks for raising the issue of application time-out, Peter. To me, this aspect of the IPP protocol could be the kiss of death, whereby submission of a print job is handled in multiple, independent transactions. Lest we forget, one of the *biggest* problems facing the average user is controlling time-out values for printers when those printers do not have a decent protocol with which to determine when a job is done (or has aborted, or whatever). Our experience has been that users absolutely despise such required "fine tuning" of a printer's operational parameters. How will this problem scenario be handled by the typical IPP implementation within a network printer with no spooling capability (ie, can process only a single job at a time): 1. Client executes a "CreateJob" operation on the printer 2. Client sends the first of three documents to the printer. 3. Client crashes...never to return. If the answer is something like: "The printer will have to use an internal time-out parameter to know when to abort an in-process job submission, and that parameter will have to be exposed to the system manager for potential modification." then I'd suggest we haven't really come very far in advancing network printing. This is probably my biggest concerns with using HTTP as the basis for a network printing protocol, at least when an operation spans multiple independent transactions between the client and the server. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-archive Wed May 7 18:01:17 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA10934 for ipp-outgoing; Wed, 7 May 1997 17:57:53 -0400 (EDT) Message-Id: <199705072157.AA00376@interlock2.lexmark.com> To: "ipp%pwg.org" From: Don Wright Date: 7 May 97 17:48:01 EDT Subject: IPP> May 7, 1997 IPP Conference Call Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Attached are the minutes for today's conference call in text format. I have placed these and a PDF version on the ftp server at: ftp://ftp.pwg.org/pub/pwg/ipp/minutes/970507-ipp-conference-call.txt ftp://ftp/pwg.org/pub/pwg/ipp/minutes/970507-ipp-conference-call.pdf Don ++++++++++++++ Internet Printing Project Conference Call - May 7, 1997 The meeting was called to order at 4:10 PM EDT. Attendees: * Bob Herriott - Sun * Carl-Uno Manros - Xerox * Peter Zehler - Xerox * Randy Turner - Sharp * Don Wright - Lexmark * Tom Hastings - Xerox * Scott Isaacson - Novell * Lee Farrell - Canon * Jeff Copeland - QMS * Jim Walker - Dazel * Jay Martin - Underscore Agenda: - Subgroup Reports * Model * Protocol * Others - FTP/WWW Site MODEL SUBGROUP Work on the document was done over the last week-end. Scott is adding more to it now including some of the work on "capable." Jim Walker and Roger Debry expressed their opinion that the "capable" function is not needed and we don't gain anything from it. After much discussion, the group came around to using the "capable" attributes only for administrative and directory entry usage. Scott's goal is to get the document out before this Friday's conference call. The group discussed some overall problems with the organization of the document. PROTOCOL The committee wants to reach closure on the issue of whether we fully adopt HTTP or just borrow ideas from it. The goal is to work through this issue at the San Diego meeting. There was a discussion on the issue of caching of attributes; how to take advantage of caching, what attributes should be cacheable, etc. What performance issues would be solved by allowing caching? How would cacheable versus non- cacheable objects be separated. If we do something that isn't exactly HTTP should we step back all the way and develop the protocol from scratch? Is there value in being really close to HTTP in the ability to re-use code? Jay Martin discussed CPAP and whether it is applicable to the IPP problem. What are the implications of choosing a protocol other than HTTP or a HTTP-like protocol based upon existing work going on? Jay Martin was asked to present more information on CPAP at the San Diego meeting. ADMINISTRATIVE ITEMS * Scott to send out the agenda for the Model meeting on May 14th. All planning to attending should notify Patrick Powell. * UPD discussion is out of the day-time agenda and moved to a dinner meeting on May 15th. * Press Release discussion - No requirement now for the PWG to send out a correction - Minor changes to the WEB site - No changes made to the ftp site - Continue to post documents in text format - references to companies only when then include the name of the person * Randy Turner asked for a clear direction on the prototyping effort from Pete Zehler at the San Diego meeting. * Should the next PWG press release on IPP talk about a future technology demonstration? * The June meeting will be a 2 day meeting. * Next IPP conference call will be May 21, 1997. Meeting adjourned at 5:45 PM EDT. ++++++++++++++ ************************************************************* * 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 Wed May 7 18:28:37 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA11463 for ipp-outgoing; Wed, 7 May 1997 18:18:38 -0400 (EDT) Date: Wed, 7 May 1997 18:15:07 -0400 (EDT) From: JK Martin Message-Id: <199705072215.SAA02863@uscore.underscore.com> To: cmanros@cp10.es.xerox.com Subject: Re: IPP> May 7, 1997 IPP Conference Call Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Carl-Uno, As mentioned in the minutes of today's telecon: > Jay Martin was asked to present more information on CPAP at the > San Diego meeting. I don't believe we set a date for my quickie presentation. (As I recall, this presentation and discussion should be limited to 30-60 minutes.) Would my CPAP presentation be on Wednesday (May 14), or Thursday (May 15)? As of this writing, I'm not scheduled to arrive in San Diego until Wednesday evening, so I need to know right away whether my presentation will be given on Wednesday or Thursday, in case I have to change my travel plans. Thanks. ...jay From ipp-archive Wed May 7 22:31:20 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA12891 for ipp-outgoing; Wed, 7 May 1997 22:28:32 -0400 (EDT) Date: Wed, 7 May 1997 19:30:41 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705080230.TAA23021@woden.eng.sun.com> To: ipp@pwg.org, walker@dazel.com Subject: Re: IPP> MOD -- xxx-supported attributes X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I think that Jim and I have a different understanding of how the UPD should work in the case where an attribute is specified externally and embedded in the PDL. I think that we all agree that in a perfect world, the PDL contains no embedded attributes and all attributes are specified externally. Meanwhile, I would expect that customer will want to print existing documents with attributes embedded in the PDL and want to override them with external IPP attributes. Certainly, Jim's case of 4-up internally and 2-up externally presents a problem. But other attributes, such as sides to not present a problem, especially if the PDL interpreter supports IPP attributes. I also think that I don't understand how option 2 (below) works. How does a client know whether an attribute should be embedded or external. Are there some rules? I think that IPP needs to support the following scenarios: 1) UPD printer: the printer honors an external attribute and ignores the corresponding embedded attribute if any, unless the external attribute is absent or has the value 'as-is'. Note: I include true printer features in the list of such external attributes and exclude image transformations, such as n-up. Note: embedded attributes that are beyond IPP capabilities (e.g. different media on different pages) require the 'as-is' value. 2) UPD client: the client queries the IPP printer for attributes and generates external attributes. It does not embed control information in the PDL. If the printer is an IPP printer, then the supported production attributes should be the same as those supported as embedded attribute. If the printer is a legacy printer (supported by an IPP print server), then some attributes supported as embedded by the output device may not be supported by the IPP print server. For such a printer, a Windows client would use a legacy driver to gain access to all the features. Unix clients should, likewise, use their legacy mechanism for accessing a legacy printer. Issue: what about the "different media on different pages" raised above? 3) Windows client legacy: the client continues to send just a PDL file with attributes embedded in the PDL. The attributes are known to the client and do not come from the IPP printer. The IPP printer must not attempt to add external IPP attributes unless their value is 'as-is'. 4) Unix client/gateway legacy: the client/gateway continues to send a PDL and some lpr attributes. The attributes are known to the client and don't come from the IPP printer. The lpr attributes are translated to IPP attributes. I think that all of this argues against the need for 'capable' attributes because the client software that generates embedded attributes in the PDL continues to operate as it currently does. And it doesn't use the external attributes. The one exception is for setting up the directory service. Then the question is which attributes should the printer display: the ones accessible via IPP attributes or the ones accessible via embedding? It does seem a bit strange for a client to find printers via the IPP mechanism and then use a legacy driver to print, but it might still be useful. I also wonder, how useful are IPP print servers that talk to legacy printers if they are unable to support IPP production attributes. In other words, why would anyone switch from a legacy driver to a UPD for a legacy printer if they lose functionality? Those are my thoughts. Comments welcome. Bob Herriot > From walker@dazel.com Wed May 7 08:28:55 1997 > > I was assigned the following task from the last model meeting: > > >> 2. Since we are getting rid of tags, it is not acceptable to live with the > >> ambiguity as clarified by Tom in last weeks minutes. That is xxx-supported > >> values are: 1) client desires to > >> override the PDL (the same instruction is in the PDL) or 2) client desires > >> action only when the information is not in the PDL. This was once being > >> solved by the embedded and embedded-only tags. Since we have no tags, the > >> proposal is to define a set of xxx-capable attributes to go along with the > >> xxx-supported attributes. Jim Walker took an action item to write this up > >> can clarify semantics of xxx-supported, xxx-capable and best-effort and > >> embedded instructions in PDL. > > Here are the three alternatives as I see them: > > (1) The server advertises the productions that it is capable of supporting, > assuming that the client inserts the appropriate printer- and PDL- > specific sequence in the PDL data stream. This is the situation > as we have today in the PC driver world, and the situation that > most seem to think that we ought to try to get away from. > > (2) The server advertises the productions that it can support, assuming > that the client sends the appropriate IPP attribute in the job (or > document) control stream, and does not insert any conflicting > production instructions in the PDL data stream. This is the ideal > situation in the UPD world. > > (3) The server advertises the productions that it can support, whether the > client sends the appropriate IPP attribute, and/or has the same or > conflicting production instructions in the PDL data stream. This > is the robust case that everybody *thinks* they want, but I would > argue that this situation is untenable in general (e.g., I pass a > document that is already 4-up'ed, and tell the server that I want > it 2-up'ed, and, by the way, best-effort is do-not-substitute). > > I believe that IPP printers ought to *only* support option (2) above. > > First of all, we can do option (1) today without the IPP printer > advertising its capabilities. In this case, the driver would use PPD > files (or whatever other information it already has or wants today) and > generate an appropriate PDL data stream, and forward that data stream on > to an IPP printer with few, if any, IPP attributes. The driver would not > need to query the capabilities of the printer, as it could just get that > information the same way that it does today. After all, if we were going > to modify the driver to query the IPP printer, why not go ahead and modify > it to set the appropriate attributes in the job control stream, as in > option (2), rather than in the data stream. > > Furthermore, knowing the capabilities supported in option (1) does not > help with pre-generated files either; the user does not know (unless they > have software to scan the file) what capabilities were utilized in > generating the data file, so it does not help that they know what > capabilities the printer will support. > > As I have already stated above, I do not believe that option (3) is > supportable, especially if we try to tie this together with the > best-effort attribute. If we say that the IPP printer can only advertise > the supported attributes that it can override what is specified in the > data file, then will any IPP printers be able to any supported attributes. > In other words, if I am a print server that fronts a duplex printer, yet I > am unable to guarantee that I can override a simplex/duplex capability > specified in a PDL data stream, then I cannot advertise sides-supported. > > So, I believe that option (2) is the only option that we should attempt to > specify in IPP, especially version 1.0. With this option, we can say that > the xxx-supported attribute describes those capabilities that the IPP > printer can support if the associated xxx attribute is specified in the > print job. If a conflicting instruction is specified in the PDL data > stream, then the results are undefined. > > comments welcome... > ...walker > > -- > Jim Walker > System Architect/DAZEL Wizard > DAZEL Corporation, Austin, TX > From ipp-archive Thu May 8 13:06:27 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA15244 for ipp-outgoing; Thu, 8 May 1997 13:05:28 -0400 (EDT) From: Roger K Debry To: Subject: IPP>MOD - SendDocument proposal Message-Id: <5030100002306733000002L032*@MHS> Date: Thu, 8 May 1997 13:06:58 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO The following text suggests revisions to the current model document to add the notion of createJob and SendDocument to the IPP Model. Line numbers and section numbers are from the April 24th version 2.1 model document. The text which follows will be slightly more readable if you use a mono-space font on your mail. Keith and I are proposing that we not use the byte range notion discussed in last week's telecon but go back to the original proposal. We do not believe that byte ranges add any value at this point, they complicate the model, and are not consistent with the way existing OS/2 and Windows drivers work. If at some point we, or a specific vendor implementation, wants to add checkpointing and recovery then this issue can be revisited and properly designed to provide that function. Finally, we did not use Bob Herriot's suggestion to add document numbers. We see no immediate value in this proposal, it does not fit the OS/2 and Windows models, and it assumes that we will use a number to identify a document in the future and not a URL. It's not clear that this is the right decision. So, in the spirit of keeping things simple ............. Section 3, lines 690 - 696 becomes Printer: Create Job (Section ...) Get Attributes (Section ...) Get Jobs (Section ...) Job Object: Send Document (Section ...) Get Attributes (Section ...) Cancel Job (Section ...) Section 4.1, lines 838 - 841 becomes Operations which can be invoked on a Printer include: Create Job (Section ...) Get Attributes (Section ...) Get Jobs (Section ...) Section 4.2, lines 905 - 909 becomes A Job object is used to model a print job. A job can contain one or more documents. The information required to create a job object is sent in a Create Job operation from the end user via a client implementation to a Printer. The Printer may perform some validation checks to verify that the job may indeed be processed. For example, the Create Job operation may request that the documents within the job be printed duplex (on both Section 4.2, lines 933 - 935 becomes The following operations can be invoked on Jobs: Send Document (Section ...) Cancel Job (Section ...) Get Attributes (Section ...) Section 4.3, lines 937 - 939 becomes Documents consist of printable data and attributes which describe the data to be printed. In this version of the protocol only attributes defined in section 6.4.1 may be defined for individual documents. Documents are sent in a Send Document operation. Section 5.1, lines 1042 - 1045 becomes For a Printer object: Create Job (Section ...) Get Attributes (Section ...) Get Jobs (Section ...) Section 5.1, lines 1047 - 1049 becomes For a Job object: Send Document (Section ...) Cancel Job (Section ...) Get Attributes (Section ...) Section 5.2.1 lines 1067 - 1074 becomes 5.2.1 Create Job Operation When an end user desires to submit a print job, the client send a Create Job Request and receives a Create Job Response. The information in a Create Job Request along with any default information associated with the Printer is sufficient to create a Job object. An instance of a Job object contains all of the information needed by the Printer to print one or more documents as a print job. When a Printer receives a Create Job Request, it either accepts or rejects the request. The Printer accepts the Create Job Request and creates the a Job object if it is able to accept each Issue: this section needs to be cleaned up to match the conformance section and get rid of adornments Section 5.2.1.1 lines 1101 - 1106 becomes 5.2.1.1 Create Job Request The following abstract data types are part of the Print Request: Job and Document A set of Job attributes as defined in Attributes section 6.2. This section may be empty. If so, Printer defaults are used. Section 5.2.1.2 lines 1108 - 1109 becomes 5.2.1.2 Create Job Response The following abstract data types are part of the Create Job Response: New section to be added: x.x.x. Send Document Operation Once a Job object has been created, a client uses the Send Document operation to transport the documents to be printed and add them to the named Job object. A document may be sent in a single Send Document operation or split into pieces and sent with multiple Send Document operations. x.x.x.1 Send-Document Request The client submits the request to a Job URL. The following abstract data types are part of the Send-Document request: Content Length Number of data bytes in this Request Document Part flag Indicates that this is the first, middle, last, or only segment of a document End of job flag Used in the last request of a job to signal end-of-job to the Printer Document Attributes A set of Document attributes as defined in section 6.4. Document Contents bytes of document content in the format defined by the Document-format atttribute. Document content is optional and not included when printing by reference. x.x.x.2 Send-Document Response The following abstract data types are part of the Send-Document response: Bytes Written Records the actual bytes accepted by the Printer. This allows the client to handle cases where the Printer failed to accept the total amount of data in the request for some reason. Status status information, including error status Message optional status message Section 6.4, replacement for the whole section Note: I re-wrote this section to put all document attributes in one place and clean up the definitions. 6.4.1 Document Data Attributes (Set by a Client/End User) This group of attributes describes the document data for the job. They are supplied in the Send-Document request. 6.4.1.1 document-name(name, Mandatory) This attribute contains the name of the document used by the client to initially identify the document. When a client prints by reference, i.e. includes the document-URL attribute and no document content, this attribute shall be absent. When a document's contents are spread across multiple Send Document operations, document-name is ignored by the Printer in all but the first Send Document operation for that document. 6.4.1.2 document-format (type2 keyword) This attribute defines the document format of this document. When a client prints by reference, i.e. includes the document-URL attribute and no document content, this attribute shall be absent. When a document's contents are spread across multiple Send Document operations, document-format is ignored by the Printer in all but the first Send Document operation for that document. 6.4.1.3 document-URL (url) This attribute contains the URL of the document when the document content is not included in the Send Document operation. Document-number is the only other attribute allowed when a document-URL attribute is present in a Send Document operation. Examples These examples may be included in the model document to halp clarify the use of send document. However, this is open to discussion. We believe that the model as now defined maps very nicely to both the OS/2 and Windows driver model. Using the proposal we saw from Babek at the San Jose PWG meeting, for example, the Windows API calls would map as shown: OpenPrinter - establish connection StartDocPrinter - Create Job (printer url, job attributes) WritePrinter - Send Document (job-url, part = first, length, data) WritePrinter - Send Document (job-url, part = middle, length, data) WritePrinter - Send Document (job-url, part = middle, length, data) EndDocPrinter - Send Document (job-url, eoj, part = last, length, data) ClosePrinter - close connection The following example illustrates the use of Send Document in more detail. In this example, a print job contains three documents. The first requires multiple writes to send the job, the second is a print by reference, the third can be sent in a single write: CreateJob (Printer URL, job-template attributes and values) SendDocument (Job URL, document-part=first, data-length=500, document-name=DOC1 document-format=Postscript ) SendDocument (Job URL, document-part=middle data-length=500, ) SendDocument (Job URL, document-part=middle, data-length=500, ) SendDocument (Job URL, document-part=last, data-length=150, ) SendDocument (Job URL, document-URL= document-name=DOC2) SendDocument (Job URL, document-part=only, End-of-Job, document-name=DOC3, document-format=PCL ) From ipp-archive Thu May 8 21:11:34 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA19352 for ipp-outgoing; Thu, 8 May 1997 21:06:56 -0400 (EDT) Date: Thu, 8 May 1997 18:09:05 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705090109.SAA04916@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO comments on CPAP X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I just read over the CPAP spec (a March 1992 version). I am making a few comments to help with a discussion before the meeting next week. In CPAP a client opens a connection (e.g TCP/IP) and sends a series of operations. The syntax for CPAP (simplified) is: Integer-opcode Sequence-Number Length blank Data The Data may be raw data (e.g. document data) or a sequence of attributes in the form: name=string-value^A (control A ends each value. The send-data operation sends raw data. Most of the other operations send attributes. A typical session is (from the CPAP document) with each operation explicity named: client action server action create circuit accept circuit start session reply identify user start document reply open circuit returned accept circuit send data disconnect circuit end document < repeat from start document above for more documents > end of job reply disconnect circuit There are many operations and they include ones for management. I like some ideas and not others in CPAP. On the downside CPAP opens a new circuit for sending document data for each document (for Level II). Level I does not, but the document advises the use of Level II. This seems to have all the HTTP problems of too much TCP build/ tear-down traffic. On the good side, CPAP looks slightly more compact because of its integer opcode and length. But the biggest savings in terms of processing may be that the server knows that the operations are in the context of the session and doesn't have to re-establish context with each operation. For example, out SendJob currently contains the job-URL. This seems redundant if the server knows from the preceding CreateJob what job it is expecting to receive data. My take is that there are some good ideas in CPAP that are worth using, but I wonder if the PWG wants to take it as a whole. Bob Herriot From ipp-archive Fri May 9 00:46:34 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA21756 for ipp-outgoing; Fri, 9 May 1997 00:45:00 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 08 May 1997 22:44:16 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - new model document Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I have posted a new version of the model document. ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970509.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970509.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970509.txt It is not in very good shape. I am about 3/4 of the way through, but I ran out of time in order to post in a reasonable amount of time for the 5/9 teleconference. With some many revision marks, it is really hard to read right now. Notice I went from version 2.2 to a dated version (970509) - this will help in making it an I-D more quickly. Some highlights: 1. Left terminology in section 2, moved most of conformance to section 7. This is still not as clean as I would like it to be. 2. I tried to do a lot with the Job Templates section. I added xxx-supported and xxx-available. I have completely left out xxx-capable for right now 3. I started to clean up the attributes section. 6.2 is for Job Template attributes 6.3 is for Job attributes 6.4 is for Document 6.5 is for Printer Notice how I started to work on the first few job template attributes (I only did three or four) please give feed back on how that is turning out. 3. Tom fixed a lot of language in the Operations section. I just got Roger's write up and I have not put that in yet on SendDoc. 4. Carl-Uno has some suggested edits which I just got and I have not rolled those in yet. The plan from here on out. 1. Review the doc as it is on Friday 5/9 (the PDF with line numbers please) 2. Don't worry about little edits, just the main structure for right now 3. I will then redo the document and issue a real I-D (i'll post the PDF and DOC versions with line numbers) 4. This will be the doc to review in San Diego. Scott From ipp-archive Fri May 9 01:05:00 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA22237 for ipp-outgoing; Fri, 9 May 1997 00:53:01 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 08 May 1997 22:52:48 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - 5/14 agenda Sender: ipp-owner@pwg.org Precedence: bulk Status: RO IPP Working Group Meeting MOD subgroup Wednesday May 14, 1997 - 8:30 am - 5 pm. Meeting Place: StartTech, 9475 Chesapeake Drive, Suite D San Diego, CA 92123 Phone (619) 874-6543 FAX (619) 279-8424 email : papowell@sdsu.edu (directions see previous e-mail) Meet in the Marriott hotel lobby at 8:00 to car pool. I too will have a car to drive if someone needs a ride. Agenda: 1. Discuss high level goals - Physical configurations supported - Must an IPP Printer spool - Desktop vs workgroup printer support - Is section 3 still valid 2. Review current Job Template model - xxx-supported - xxx-available - close on xxx-capable discussion 3. Mandatory Attribute review 4. Review proposed SendDocument proposal 5. Review extensibility statement 6. Security impact on model 7. I18N impact on model 8. Review the (yet to be published I-D) ISSUE comments 1 by 1 I bet we can get that all done by 10:30, what else should we do?? Naw, just kidding, if we get through that by 5:00 I'll be surprised. Anything else you would like to see covered, please let me know. Scott From ipp-archive Fri May 9 01:41:37 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA23142 for ipp-outgoing; Fri, 9 May 1997 01:37:10 -0400 (EDT) Date: Fri, 9 May 1997 01:37:09 -0400 (EDT) From: JK Martin Message-Id: <199705090537.BAA07683@uscore.underscore.com> To: Robert.Herriot@Eng.Sun.COM Subject: Re: IPP>PRO comments on CPAP Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Bob, Thanks for getting the discussion rolling. This post is a bit long, but hopefully reads very quickly. After reading this message, one should be able to fully understand CPAP in the context of HTTP-like protocol operations without having to read the CPAP spec: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/cpap.ps > In CPAP a client opens a connection (e.g TCP/IP) and sends a series > of operations. The syntax for CPAP (simplified) is: > Integer-opcode Sequence-Number Length blank Data The Opcode, Sequence-Number and Length fields are all displayable text. There is no binary data involved. (Just so folks are clear on this.) Also, "Sequence-Number" is more like "Transaction-Id", similar to that used in SNMP and other protocols. The client is free to set that number to any value of its choice, since it's primary purpose is to identify the associated reply message. Speaking of request and reply (response) messages: One of the interesting aspects of CPAP is that there is only ONE type of response message: Reply Every request message has a corresponding Reply, but the same message format is used for all responses. Unlike some protocols that define messages such as: Foo-Request, Foo-Response More-Request, More-Response ...etc CPAP instead has a *very* simple data model that requires only a single type of response message. While the vast bulk of activity between the client and server can be totally synchronous, the design of CPAP allows a client to post several requests, then receive the responses. The client keys off the Reply's sequence number (we call it "message id" at Underscore) to know which request the Reply is for. Other key aspects about the protocol design: * All requests utilize a simple command (opcode) and zero or more "variables" (named strings); like HTTP, there are no fixed formats for the message definitions, thereby allowing for arbitrary extensibility. * All message data is displayable text; however the payload of the message can be arbitrary binary data; note, though, that none of the defined messages contains any kind of binary data. * Control messages and document data can exist either entirely separately (via separate channels), or co-exist within a single channel; in the single channel case, the document data is passed in multiple DATA messages. * When a separate data channel is used to convey a document, neither the client NOR the server must parse any of the data; when the client closes the data channel connection, the server knows the document data is complete. The concept of separate control and data channels was directly lifted from the experience learned from FTP. It works. And it works really well: * The client can stream data down the data channel without having to know how much data is involved, or have to deal with "boundary" delimiters. * Since there is absolutely NO framing involved, performance can reach the theoretical maximum between the client and server. * Separate channels allows for some very interesting (and useful) implementations whereby separate processes can handle the control and data channels in a very effective manner. Bob, you're a Unix person. On that last item, think about the classic BSD LPD implementation. The "if" filter can simply stream its document data at the printer without getting at all involved in the session/job negotiation. Very fast. Very simple. Very cheap. Here's another view of the "protocol ladder" between the client and server for a typical job submission transaction: Line Client Side Server Side ----------------------------------------------- 1 Open connection ---> 2 <--- Accept connection 3 Start Session ---> 4 <--- Reply 5 Start Job ---> 6 Start Document ---> 7 <--- Reply 8 Open data channel ---> 9 <--- Accept connection 10 Send document data ---> 11 . 12 . 13 . 14 Close data channel ---> 15 End Job ---> 16 <--- Reply 17 Close connection ---> Notes (reference Line number): 1 - Stream-level (TCP) connection. 2 - 3 - Client identifies itself. 4 - Server accepts, and provides information about itself; or rejects, (via a NAK message) providing a reason for rejection (no access, no resources, etc), at which point the connection is closed by the server. 5 - Provides identification about the requesting user and the job itself 6 - Client specifies this document's attributes, such as PDL, etc. 7 - Server returns the port number to which the client should connect to deliver the document data. 8 - Client connects to the the server-assigned data channel port number. 9 - 10 - Data is pumped down the wire as fast as the client can send it; the server receives the data as fast as it can, letting TCP handle flow control. 11 - 12 - 13 - 14 - Client has delivered all document data, so closes the connection; the server sees this, and thus knows it now has all the document data. The sequence of steps 6 thru 14 repeat for each document in the job. 15 - Client tells the server this job is completed. 16 - Server responds with the complete set of accounting data for the job. 17 - > There are many operations and they include ones for management. The management-related protocol operations deserve serious considerations, but they shouldn't necessarily be considered at this point. > I like some ideas and not others in CPAP. > > On the downside CPAP opens a new circuit for sending document data for > each document (for Level II). Level I does not, but the document advises > the use of Level II. This seems to have all the HTTP problems of too much > TCP build/ tear-down traffic. CPAP uses far fewer TCP connections than that proposed in the most recent drafts. Moreover, those connections significantly simplify the protocol interactions, while at the same time requiring a far less complex parsing and control implementation. > On the good side, CPAP looks slightly more compact because of its > integer opcode and length. But the biggest savings in terms of > processing may be that the server knows that the operations are > in the context of the session and doesn't have to re-establish context > with each operation. For example, out SendJob currently contains > the job-URL. This seems redundant if the server knows from the preceding > CreateJob what job it is expecting to receive data. No one should underestimate the value and power of maintaining a single, monolithic control channel to effect a client-server transaction. Perhaps more importantly, though is the SIMPLICITY in the implementation, which translates to smaller, faster and more robust products. > My take is that there are some good ideas in CPAP that are worth > using, but I wonder if the PWG wants to take it as a whole. I don't think we have the situation where the PWG can "pick and choose" things from CPAP and stuff them into the current HTTP-based approach. The current HTTP-based approach and CPAP have these critical similarities: * Both use simple named strings to convey parameters, attributes, etc. * Both employ a framing mechanism that can allow for arbitrarily long messages * Both allow for arbitrary extensibility thru the addition of attributes included with the request and/or response messages Some last thoughts I'd like to share with everyone: * CPAP is not perfect. It can use some improvements here and there, but the essential framework is very, very solid. Above all, it's emminently extensible, so no one should feel like their getting locked into a given set of capabilities. * I would not FOR A SECOND expect the IPP to accept CPAP as it is; besides adding some missing pieces (which should take about 5 seconds), I would hope the group would take CPAP and turn it into something of its own (and change the name). * CPAP has been field-tested on all platforms except the Macintosh for about 10 years now. Underscore itself has ported CPAP implementations to a dozen different Unix systems, and created a NetWare PSERVER NLM from scratch around this protocol. It has been very thoroughly tested. * In addition to handling print job submission tasks, the protocol also defines other critical areas the printer industry sorely needs, including comprehensive job accounting, event logging, surrogate client support (in which the printer can use an external network host for such things as on-the-fly downloading of fonts, forms and configuration data). In fact, an entire file transfer mechanism is defined to allow the printer to use a network host at will for storage and retrieval...simply. One final note for those more intent on marketing rather than technology: While it's true that Digital developed this protocol (by Brian Reid and Chris Kent, at the DEC Western Research Labs), Digital is in effect no longer using the protocol. CPAP was only implemented on Digital's PrintServer family of network printers; this product family was based on a version of the VAX chip set that is no longer in production. Digital no longer manufactures PrintServers...and can't, since the underlying hardware is no longer in production. Furthermore, it does not appear that Digital intends to port the PrintServer architecture to another printer platform. In other words, should the PWG utilize CPAP in IPP, no one in the printer industry should worry about not having a "level playing field" here. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-archive Fri May 9 08:26:39 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA25716 for ipp-outgoing; Fri, 9 May 1997 08:23:23 -0400 (EDT) Message-Id: <33731712.EE0@dazel.com> Date: Fri, 09 May 1997 07:22:42 -0500 From: Jim Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 3.0 (WinNT; I) Mime-Version: 1.0 To: Scott Isaacson Cc: ipp@pwg.org Subject: Re: IPP> MOD - new model document References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Scott Isaacson wrote: > > I have posted a new version of the model document. > > ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970509.doc > ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970509.pdf > ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970509.txt > > ... I just downloaded the .doc file, and got the following message: The file C:\users\walker\IPP\ipp-model-970509.doc is infected with the virus CONCEPT (Removable). heads up... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-archive Fri May 9 10:16:40 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA26416 for ipp-outgoing; Fri, 9 May 1997 10:12:37 -0400 (EDT) Message-ID: <33733006.770B@underscore.com> Date: Fri, 09 May 1997 10:09:10 -0400 From: Jeff Schnitzer Organization: Underscore, Inc. X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: walker@dazel.com CC: Scott Isaacson , ipp@pwg.org Subject: Re: IPP> MOD - new model document References: <33731712.EE0@dazel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Jim, Thanks for the notice. Until a clean copy is put on the server, I've renamed ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970509.doc to ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970509.doc-INFECTED This way it's still available to those who like to live dangerously... /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 --------------------------------------------------------------- Jim Walker wrote: > > Scott Isaacson wrote: > > > > I have posted a new version of the model document. > > > > ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970509.doc > > ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970509.pdf > > ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970509.txt > > > > ... > > I just downloaded the .doc file, and got the following message: > > The file C:\users\walker\IPP\ipp-model-970509.doc is > infected with the virus CONCEPT (Removable). > > heads up... > ...walker > > -- > Jim Walker > System Architect/DAZEL Wizard > DAZEL Corporation, Austin, TX From ipp-archive Fri May 9 12:13:29 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA27263 for ipp-outgoing; Fri, 9 May 1997 12:03:20 -0400 (EDT) From: Harry Lewis To: , Subject: IPP> PMP> Re: JMP> JobStateValue Message-Id: <5030100002337350000002L002*@MHS> Date: Fri, 9 May 1997 12:04:50 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Jay Martin wrote (to the JMP group) >One question that we all must come to grips with: > If a vendor wants to create a product used to monitor jobs, > will the choice of access be SNMP and the Job MIB, or IPP? >We are, after all, in the process of trying to solve the very same problem >in two completely different ways...at least when it comes to job status. >This doesn't feel good. Thank you, Jay! I've tried to point this out several times in the past. The PWG is not working together in this vein. IPP has taken an all encompassing approach, basically ignoring the fact that printer configuration and status can be handled via the printer MIB - a standard which is already implemented in at least 6 vendors printers and has the support of several printer management software products. IPP as a standard job submission protocol is a great idea. I guess there is nothing wrong with also making it an all encompassing status and configuration protocol... but, at least, we should be doing some sort of mapping back to the Printer and Job MIBs. Harry Lewis - IBM Printing Systems From ipp-archive Fri May 9 12:51:43 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA28244 for ipp-outgoing; Fri, 9 May 1997 12:50:20 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 09 May 1997 10:50:07 -0600 From: Scott Isaacson To: ipp@pwg.org, jmp@pwg.org, harryl@us.ibm.com Subject: IPP> PMP> Re: JMP> JobStateValue Sender: ipp-owner@pwg.org Precedence: bulk Status: RO >>> Harry Lewis 05/09 10:04 AM >>> > Thank you, Jay! I've tried to point this out several times in the past. > The PWG is not working together in this vein. IPP has taken an all > encompassing approach, basically ignoring the fact that printer > configuration and status can be handled via the printer MIB - a standard > which is already implemented in at least 6 vendors printers and has the > support of several printer management software products. > > IPP as a standard job submission protocol is a great idea. I guess there > is nothing wrong with also making it an all encompassing status and > configuration protocol... but, at least, we should be doing some sort > of mapping back to the Printer and Job MIBs. Harry, I have thought some about this - "Why not let IPP just be job submission and do a better job of integrate the end user's client software with the Job MIB and Printer MIB for job and printer status.?" I keep coming back to one main thought: I do not envision a SNMP stack on every end user client. It seems to heavy weight for me. I see SNMP enable apps on every manager/operator client, but that is typically a different configuration. I say let the MIBs stay on the course they are on, which is a good one in my view, because they are oriented towards "print device management". There is a big difference between "printing system management" and "print device management." There is some overlap between the two, but let IPP (non-SNMP based at all) be a full solution for the end user even when the end user starts to take on the role of a "jr. manager" their own jobs and devices in order to make job submission decisions. These are all printing system kinds of things, not just device kinds of things. Since there is overlap, there must be (SHALL be to use better conformance language) consistency between job attributes in the Job Monitoring MIB and IPP and printer attributes in the Printer MIB and IPP. In the IPP requirements we say only a subset of the end user requirements are satisfied in V1.0. I expect much better integration (and less overlap) with the MIBs when we talk about solving the manager requirements. For administrative requirements, I don't see the MIBs being involved very much. Scott From ipp-archive Fri May 9 13:16:43 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA29020 for ipp-outgoing; Fri, 9 May 1997 13:14:57 -0400 (EDT) Mime-Version: 1.0 Date: Fri, 9 May 1997 13:19:50 -0400 Message-ID: <00014C52.1337@digprod.com> From: bwagner@digprod.com (Bill Wagner) Subject: Re: IPP> PMP> Re: JMP> JobStateValue To: ipp@pwg.org, jmp@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: bulk Status: RO Scott, When we agonize about IPP disregarding the MIB's, it is not SNMP that is the question but rather the parameters used in IPP versus those in the MIB's. There is nothing to say that the MIB objects need only be accessible via SNMP. It is indeed things such as "consistency between job attributes in the Job Monitoring MIB and IPP and printer attributes in the Printer MIB and IPP" that is the point of concern." Your opinion that "For administrative requirements, I don't see the MIBs being involved very much." is very interesting in that I believe that administration is exactly the purpose of the MIB's. To suggest that IPP should be a more universal solution handling device management as well as job submission may not be to the advantage of IPP either, since it burdens IPP with an additional, non-trivial functionality. Bill Wagner, Osicom/DPI ______________________________ Reply Separator _________________________________ Subject: IPP> PMP> Re: JMP> JobStateValue Author: Scott Isaacson at Internet Date: 5/9/97 10:50 AM >>> Harry Lewis 05/09 10:04 AM >>> > Thank you, Jay! I've tried to point this out several times in the past. > The PWG is not working together in this vein. IPP has taken an all > encompassing approach, basically ignoring the fact that printer > configuration and status can be handled via the printer MIB - a standard > which is already implemented in at least 6 vendors printers and has the > support of several printer management software products. > > IPP as a standard job submission protocol is a great idea. I guess there > is nothing wrong with also making it an all encompassing status and > configuration protocol... but, at least, we should be doing some sort > of mapping back to the Printer and Job MIBs. Harry, I have thought some about this - "Why not let IPP just be job submission and do a better job of integrate the end user's client software with the Job MIB and Printer MIB for job and printer status.?" I keep coming back to one main thought: I do not envision a SNMP stack on every end user client. It seems to heavy weight for me. I see SNMP enable apps on every manager/operator client, but that is typically a different configuration. I say let the MIBs stay on the course they are on, which is a good one in my view, because they are oriented towards "print device management". There is a big difference between "printing system management" and "print device management." There is some overlap between the two, but let IPP (non-SNMP based at all) be a full solution for the end user even when the end user starts to take on the role of a "jr. manager" their own jobs and devices in order to make job submission decisions. These are all printing system kinds of things, not just device kinds of things. Since there is overlap, there must be (SHALL be to use better conformance language) consistency between job attributes in the Job Monitoring MIB and IPP and printer attributes in the Printer MIB and IPP. In the IPP requirements we say only a subset of the end user requirements are satisfied in V1.0. I expect much better integration (and less overlap) with the MIBs when we talk about solving the manager requirements. For administrative requirements, I don't see the MIBs being involved very much. Scott From ipp-archive Fri May 9 13:26:48 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA29636 for ipp-outgoing; Fri, 9 May 1997 13:22:56 -0400 (EDT) Message-ID: <33735D36.4282@parc.xerox.com> Date: Fri, 9 May 1997 10:21:58 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: Scott Isaacson CC: ipp@pwg.org, jmp@pwg.org, harryl@us.ibm.com Subject: Re: IPP> PMP> Re: JMP> JobStateValue References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO There was a proposal floating around to do SNMP -> HTTP proxy standard, so that there could be a standard way that a HTTP client could play SNMP. If so, then maybe IPP's HTTP-based submit could return the URL of the SNMP->HTTP based job monitoring? Where are the descriptions of the job management MIB and the printer MIB? Larry -- http://www.parc.xerox.com/masinter From ipp-archive Fri May 9 13:41:42 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA00256 for ipp-outgoing; Fri, 9 May 1997 13:37:43 -0400 (EDT) Date: Fri, 9 May 1997 13:38:03 -0400 (EDT) From: JK Martin Message-Id: <199705091738.NAA09106@uscore.underscore.com> To: SISAACSON@novell.com Subject: IPP> Alignment of IPP and the Job Monitoring MIB Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO [This thread was: "IPP> PMP> Re: JMP> JobStateValue" ] Scott, > I say let the MIBs stay on the course they are on, which is a good one in my > view, because they are oriented towards "print device management". There > is a big difference between "printing system management" and "print device > management." Actually, the Job Monitoring MIB is precisely NOT device management; instead, it is a component of printing system management. Within the PWG, the Printer MIB is the target of device-only activities. ...jay From ipp-archive Fri May 9 13:51:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA00737 for ipp-outgoing; Fri, 9 May 1997 13:51:25 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 09 May 1997 11:51:14 -0600 From: Scott Isaacson To: bwagner@digprod.com, ipp@pwg.org, jmp@pwg.org Subject: Re: IPP> PMP> Re: JMP> JobStateValue Sender: ipp-owner@pwg.org Precedence: bulk Status: RO >>> Bill Wagner 05/09 11:19 AM >>> I agree that there can be many ways at getting at a piece of information - SNMP GET, IPP query, PDL specific query, etc. If they are all trying to get the "same" peice of info, then the printer just has to implement it once and support multiple views. If we state that IPP requires one piece of info and the Printer MIB requires something different, and they are closely related semantically but just different enough that it requires the Printer to implement two things, this would not good - think that we are all ok on that. > > Your opinion that "For administrative requirements, I don't see the > MIBs being involved very much." is very interesting in that I believe > that administration is exactly the purpose of the MIB's. I was trying to make a distinction bewteen what an "administrator" does (in the IPP requirements) document and what a "manager" does. I often use these terms almost interchangeable, but sometimes I try to make a clear distinction. If an adminstrator does things like: - create a new "printer" (name it, advertise it, register it, etc) - set access control rights - define the authentication and other security mechanisms - configure it to service one or more channels - etc. how would SNMP and MIBs help with that? > To suggest that IPP should be a more universal solution handling > device management as well as job submission may not be to the > advantage of IPP either, since it burdens IPP with an additional, > non-trivial functionality. I really did not mean to imply that IPP should be used for device management. Thanks for clarifying. The end user only needs to know about Printer status in order to make job submission decisions. I DO NOT see IPP as encompassing the MIB scope. Sorry if I caused confusion. Scott From ipp-archive Fri May 9 13:57:02 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA00796 for ipp-outgoing; Fri, 9 May 1997 13:52:11 -0400 (EDT) From: Harry Lewis To: , Subject: IPP> PMP> Re: JMP> JobStateValue Message-Id: <5030100002342328000002L082*@MHS> Date: Fri, 9 May 1997 13:53:34 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Scott, >I have thought some about this - "Why not let IPP just be job submission and >do a better job of integrate the end user's client software with the Job MIB >and Printer MIB for job and printer status.?" I keep coming back to one >main thought: >I do not envision a SNMP stack on every end user client. It seems to heavy >weight for me. I see SNMP enable apps on every manager/operator client, but >that is typically a different configuration. You make a good point, but I wonder just how (relatively) heavy it is? HP can correct me if I'm wrong, but I think every Mopier and/or 5si driver that installs out there today brings in an SNMP stack (at least I saw some SNMP related file names flash by as I was loading the Mopier Driver onto my w95 client). IBM's drivers do the same. Lexmark's drivers might not load SNMP on the client but they have to load NPAP. Is IPP really going to lighten the load? >I say let the MIBs stay on the course they are on, which is a good one in my >view, because they are oriented towards "print device management". There >is a big difference between "printing system management" and "print device >management." There is some overlap between the two, but let IPP (non-SNMP >based at all) be a full solution for the end user even when the end user >starts to take on the role of a "jr. manager" their own jobs and devices >in order to make job submission decisions. These are all printing system >kinds of things, not just device kinds of things. You really can't say the Job MIB is oriented toward device mgt. It's Job all the way and heavily oriented to end-users. >Since there is overlap, there must be (SHALL be to use better conformance >language) consistency between job attributes in the Job Monitoring MIB and >IPP and printer attributes in the Printer MIB and IPP. No argument here! I think the PWG will have failed if there is no conformance. Scott, I do follow your main point (I think) and that is that every client will naturally have HTTP and every Administrator will most likely have SNMP. And, since there is overlap between end-user and admin (printing) functions, we can't really have two distinct architectures. It's not hard for me to imaging a future devoid of SNMP and everything happening "on the web"... but, as we get carried away with this idea... we at least have to realize that IPP can't really seem to agree on whether HTTP is really the right protocol and printers have already implemented the Printer MIB and some will most likely also embrace the Job MIB (after all... Job MIB hasn't been dropped from the PWG venue, even though IPP is now some 8 or so months old). Another way to imagine the future is one where a standard IPP (non-HTTP, perhaps) protocol exists for print submission and the SNMP Printer and Job MIBs facilitate status and configuration of the printer and job. Harry Lewis From ipp-archive Fri May 9 14:21:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA02280 for ipp-outgoing; Fri, 9 May 1997 14:14:39 -0400 (EDT) From: Keith_Carter@aussmtp.austin.ibm.com X-Lotus-FromDomain: AUSNOTES To: ipp@pwg.org Message-ID: <86256492:0063EF8E.00@aussmtp3.austin.ibm.com> Date: Fri, 9 May 1997 13:14:27 -0500 Subject: IPP> MOD - Proposal for status code keywords in the Model document Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: bulk Status: RO This note contains: 1) Proposed status code keyword definitions for the Model document 2) Mapping of Bob Herriot's analysis of HTTP 1.1 to Model status codes 3) Issues (and in some cases proposed answers) Note that I added a prefix "OK" or "error" to each status keyword so an IPP application can detect the class of status code upfront. Enjoy, Keith 1.0 PROPOSED STATUS CODE DEFINITIONS FOR THE MODEL DOCUMENT ----------------------------------------------------------- 4.3 Status and Message The Status code provides information on the results of a request. The Message provides a short textual description of the Status. The Status is intended for use by automata and the Message is intended for the human user. An IPP application (i.e. a browser, GUI, print driver or gateway) is not required to examine or display the Message. 4.4 Status Codes (type2 keyword) Each Status is described below, including a description of which operation(s) it can follow and any metainformation required in the response. 4.4.1 Successful Status Codes This class of status code indicates that the client's request was successfully received, understood, and accepted. 4.4.1.1 OK The request has succeeded. The information returned with the response is dependent on the operation, for example: CreateJob A Job is created and the Job URL is returned in the response; SendDocument Data is written to a Document in a Job; Cancel The Job is cancelled; Get-Jobs The Jobs currently belonging to the Printer are returned in the response; Get-Attributes The values for the attributes specified in the request are returned in the response. 4.4.1.2 OK-attribute-not-implemented (NEW) The operation has succeeded. On a Get-Attributes operation, if an IPP Printer encounters any attributes in the request that are not implemented, the Printer shall return this status and indicate in the response which attributes are not supported by the Printer. On a Get-Jobs operation, if an IPP Printer encounters any attributes in the request that are not implemented and the values (if specified) for Job Owner and Job States are supported by the Printer, the Printer shall return this status and indicate in the response which attributes are not supported by the Printer. 4.4.1.3 OK-attribute-ignored-or-value-substituted The operation has succeeded. On a CreateJob operation, the request specifies substitute-as-needed for the best-effort attribute. In response to the CreateJob, the IPP Printer substituted a value for at least one attribute value that is not supported and/or ignored at least one attribute that is not implemented. In practice, an IPP application should avoid this situation by querying an IPP object for its valid attributes and values before performing an operation on the object. 4.4.2 Error Status Codes This class of status code is intended for cases in which there is an error. IPP applications should display any included Message to the end-user. Unless otherwise noted, these status codes apply to all operations. 4.4.2.1 error-bad-request The request could not be understood by the IPP Printer due to malformed syntax. The IPP application should not repeat the request without modifications. 4.4.2.2 error-user-authentication-required The request requires user authentication. 4.4.2.3 error-payment-required This request requires payment by the end-user to perform the CreateJob operation. 4.4.2.4 error-forbidden-operation The IPP Printer understood the request, but is refusing to fulfill it. Authorization will not help and the request should not be repeated. This status code is commonly used when the IPP Printer does not wish to reveal exactly why the request has been refused or when no other response is applicable. 4.4.2.5 error-operation-not-allowed The operation is not allowed for the object identified by the URL. For example, a CreateJob operation is not allowed on a Job object specified by a Job URL. 4.4.2.6 error-operation-not-authorized The request requires that an end-user have access to an object and the authorization to perform an operation on the object. For example, an end-user might be authorized to list others' Jobs but the end-user is not authorized to cancel others' Jobs. For another example, an end-user might not have access to a Printer either because the end-user is not defined in the access control list for the Printer or the end-user does not have access to the Printer across a firewall. 4.4.2.7 error-URL-not-found The server name in the URL is not found or the server cannot find the object specified in the URL. No indication is given of whether the condition is temporary or permanent. An application should use a Directory Service to return a list of valid Printer URLs and use the GetJobs operation to return a list of valid Job URLs for a Printer so an end-user can select from a valid list of URLs. 4.4.2.8 error-URL-gone The requested object is no longer available to the server specified in the URL. This condition should be considered permanent. Clients with link editing capabilities should delete references to the URL after user approval. This response is cachable. This response is primarily intended to notify the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for resources belonging to individuals no longer working at a site. 4.4.2.9 error-URL-too-long The server specified in the URL is refusing to service the request because the URL is longer than the server is willing to interpret. This condition is only likely to occur when an IPP application allows an end-user to type an invalid URL for an IPP object and then specifies that URL on an operation. An application should use a Directory Service to return a list of valid Printer URLs and use the Get-Jobs operation to return a list of valid Job URLs for a Printer so an end-user can select from a valid list of URLs. 4.4.2.10 error-attribute-not-implemented-or-value-not-supported For a CreateJob operation, if the IPP Printer does not implement at least one attribute and/or at least one attribute value in the request and either the request specifies do-not-substitute for the best-effort attribute or the Printer cannot process the request correctly, the Printer shall return this status. For example, if the Print operation specifies do-not-substitute for the best-effort attribute, the request requires A4 paper and that paper size is not supported by the Printer, the Printer shall return this status. For a Get-Jobs operation, if the IPP Printer does not support at least one attribute value for Job Owner and/or Job States in the request, the Printer shall return this status. In practice, an IPP application should avoid this situation by querying an IPP Printer for its valid attributes and values before performing a Print operation on the Printer. 4.4.2.11 error-internal-server-error The IPP Printer encountered an unexpected condition which prevented it from fulfilling the request. 4.4.2.12 error-service-unavailable The IPP Printer is currently unable to handle the request due to a temporary overloading or maintenance of the Printer. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay may be indicated in the Message. If no delay is given, the IPP application should handle the response as it would for a 200 response. 4.4.2.13 error-IPP-version-not-supported The IPP Printer does not support, or refuses to support, the IPP protocol version that was used in the request message. The IPP Printer is indicating that it is unable or unwilling to complete the request using the same major version as the client other than with this error message. The response should contain a Message describing why that version is not supported and what other versions are supported by that IPP Printer. A conforming IPP client shall specify the valid version for IPP 1.0 on each request. A conforming IPP server shall not return this status code to a conforming IPP 1.0 client. An IPP server shall return this status code to a non-conforming IPP client. 4.4.2.14 error-operation-not-implemented The IPP Printer does not support the functionality required to fulfill the request. This is the appropriate response when the IPP Printer does not recognize an operation and is not capable of supporting it for any object. 4.4.2.15 error-printer-error A printer error, such as a paper jam, occurs while the IPP Printer processes a SendDocument operation. The response shall contain the Job Status with the specific error and should contain a Message describing the error. An IPP application should check the Job Status in the response for the specific error. 4.4.2.16 error-write-fault (NEW) A write error, such as a memory overflow (i.e. the document data exceeds the memory of the Printer) or a disk full condition, occurs while the IPP Printer processes a SendDocument operation. The IPP application must check the Bytes Written in the response to determine how many bytes were actually successfully processed by the Printer. 4.4.2.17 error-document-rejected (NEW) The Printer cannot process a Document in a Job for one of the following reasons: (1) the document-format of a document is not supported by the Printer (2) the document exceeds number-of-documents supported by the Printer. For example, if a Job contains multiple documents and the Printer supports the document-format(s) of some, but not all, of these documents, then the Printer returns this Status when it first encounters an unsupported document-format. 4.4.2.18 error-unknown (NEW) The IPP client encountered an unexpected condition which prevented it from fulfilling the request. The response should contain a Message describing the error. 2.0 UPDATE TO BOB'S ANALYSIS OF HTTP 1.1 AND MODEL STATUS CODES --------------------------------------------------------------- This section is a copy of Bob's note with his analysis of my original proposal except that I have replaced the IPP status code values with IPP status code keywords. I have tried to capture differences in the Issues section of this note. Marks in column 1 denote: x should be in IPP Version 1.0 f may be in a future version, do don't reuse error code i new concept in IPP not in HTTP (these error codes start at x51) HTTP codes that IPP probably doesn't need but don't suggest reusing them A k in column 2 indicates the status code is in Keith's proposal as defined in this note. The proposed IPP status code keyword is to the right of its corresponding HTTP 1.1 status code where appropriate. Informational 1xx f 100 Continue f 101 Switching Protocols Successful 2xx xk 200 OK -> OK x 201 Created (for CreateJob instead of 200) -> OK (see Issue #1) f 202 Accepted 203 Non-Authoritative Information x 204 No Content (e.g. CancelJob) -> OK (see Issue #1) 205 Reset Content 206 Partial Content ik 251 Attribute Substitution/Ignored -> OK-attribute-ignored-or-value-substituted Redirection 3xx 300 Multiple Choices f 301 Moved Permanently f 302 Moved Temporarily 303 See Other f 304 Not Modified 305 Use Proxy Client Error 4xx xk 400 Bad Request -> error-bad-request xk 401 Unauthorized -> error-user-authentication-required xk 402 Payment Required -> error-payment-required xk 403 Forbidden -> error-forbidden-operation xk 404 Not Found -> error-URL-not-found xk 405 Method Not Allowed -> error-operation-not-allowed x 406 Not Acceptable (see Issue #2) 407 Proxy Authentication Required f 408 Request Timeout 409 Conflict xk 410 Gone -> error-URL-gone x 411 Length Required (see Issue #3) 412 Precondition Failed x 413 Request Entity Too Large (see Issue #3) xk 414 Request-URI Too Long -> error-URL-too-long 415 Unsupported Media Type ik 451 Attribute Not Implement/Value Not Supported -> error-attribute-not-implemented-or-value-not-supported k 45x not defined -> error-operation-not-authorized (see Issue #4) Server Error 5xx xk 500 Internal Server Error -> error-internal-server-error xk 501 Not Implemented -> error-operation-not-implemented 502 Bad Gateway xk 503 Service Unavailable -> error-service-unavailable 504 Gateway Timeout xk 505 HTTP Version Not Supported -> error-ipp-version-not-supported k 551 Printer Error -> error-printer-error 3.0 ISSUES ---------- Based on previous email on my original proposal, I documented the following issues. Any mistakes in articulating the issue are mine. 1. Should there be a single OK status returned for all operations that are performed successfully (i.e. asserting there is no attribute or value substitution) or should there be more granular status codes in the following cases? Operation IPP HTTP 1.1 --------- --- -------- CreateJob OK vs. Created (201) (i.e. a Job is created) SendDocument OK vs. Created? (201) (i.e. a Document is created) CancelJob OK vs. No Content (204) (i.e. no entity body returned) PROPOSAL: Use a single OK status keyword in IPP for all operations. Other implementations might not have the same underlying status codes as HTTP 1.1. An HTTP 1.1 implementation can map Created and No Content to OK. 2. HTTP 1.1 defines a status code of Not Acceptable (406). The HTTP RFC states: "The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request." Should there be an IPP status code for this error? 3. HTTP 1.1 defines status codes Length Required (411) and Request Entity Too Large (413). Length Required means the "The server refuses to accept the request without a defined Content-Length". This seems like a bug in the implementation of an IPP client. Request Entity Too Large means "The server is refusing to process a request because the Request-URI is longer than the server is willing to interpret." Should there be IPP status codes for these errors? 4. This proposal defines Status codes user-authentication-required, operation-not-authorized and operation-forbidden. HTTP 1.1 defines Unauthorized (401) which maps to user-authentication-required and Forbidden (403) which maps to operation-forbidden. I added operation-not-authorized because I believe this is a separate error per the definition of authentication and authorization in the IPP Security internet draft. Should all 3 status codes be in the IPP Model, a subset or a superset? PROPOSAL: Keith will request a position from the Security group. 5. Should there be a status code for attribute-substition and another status for attribute-ignored instead of a single status code? ANSWER: Use 1 status code, OK-attribute-ignored-or-value-substituted since both conditions can occur for the same operation. 6. Should there be a status code for attribute-not-implemented and another status for attribute-value-not-supported instead of a single status code? ANSWER: Use 1 status code, error-attribute-not-implemented-or-value-not-supported, since both conditions can occur for the same operation. 7. Should there be a status code ipp-version-not-supported? PROPOSAL: Yes. Keith will write up a section for the Model document on IPP version. 8. Should there be a way for implementors to have private error codes? PROPOSAL: Since Status codes are type2 keywords, "implementors can,at any time, add new values by proposing them to the PWG for registration (or an IANA-appointed registry advisor after the PWG is no longer certified) where these are reviewed for approval". Is this sufficient? 9. Since multiple documents isn't indicated by an attribute, but rather by the content that is sent, we need a distinct error code:multiple-documents-not-supported (if we allow a conforming Printer to reject a multiple document job in a Print operation). The description of number-of-documents states the following: "The printer shall reject a job if the number of documents is not in the range of this attribute". PROPOSAL: The error is really that a Printer receives a Job with n+1 documents where the Printer can only support n documents per Job. So the error isn't limited to whether one or more than one Document is supported per job. I added document-rejected (see above) to cover this and another case. From ipp-archive Fri May 9 15:02:00 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA02983 for ipp-outgoing; Fri, 9 May 1997 14:57:39 -0400 (EDT) Message-Id: <01BC5C83.1C5A91A0@PZEHLER.ocp.mc.xerox.com> From: Peter Zehler To: "'IPP Redirector'" Cc: "'Carl-Uno Manros'" Subject: IPP> TES> Prototype Status Date: Fri, 9 May 1997 11:11:19 PDT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk Status: RO All, I've noticed that I have a time slot to report on the state of the = prototype group at the San Diego meeting. I've made a few phone calls = to try and get some idea of what should be reported. Everyone I talk to = seems to agree. The status is: "what do you mean?" The prototype and testing group has nothing to test or prototype until = there is a concrete proposal for the object model and protocol. = Everyone I have talked to still intends to build a prototype. Time = estimates would just be a shot in the dark at this time. The range I = got was from 1 to 3 months. I was curious about the various companies capacity to contribute to any = proof of concept or architectural verification work that might be needed = by the IPP group. The lukewarm answers was that we might be able to = take on something. The specific response was a request for = clarification of the proof of concept work. As of yet the TES group has not been asked to do anything specific. If = I have missed something I would like to know about it. =20 I have asked some basic questions about the capacity of the TES group to = respond to any requests from the other IPP subgroups.=20 1) What resources are available to work on proof of concept work? The = answer to this question really depends on the task at hand and the = expertise of the people available. This will have to be answered as = issues are passed onto the TES group. 2) What is your capacity to produce a prototype? I was curious here = about how long after the specification of IPP will we be ready to show = something. The answer here depends on where IPP ends up. The common = answer was from 1 to 3 months. The prototypes range from embedding IPP = in a low-end network printer to a gateway to a full blown DPA like print = system. My questions to the group and its chairs: Is there anything specific = you need to know? Are there any general areas that you need explored? By the way...the TES group has no open issues at this time. Then again = it has no closed issues either. Pete From ipp-archive Fri May 9 16:01:43 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA03808 for ipp-outgoing; Fri, 9 May 1997 15:57:52 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 09 May 1997 13:57:12 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - 5/9 call phone number Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I just remembered that we had problems last week with the phone number - I just checked and the correct number is 888-206-4962 code: 333570 5/9/97 2:00 - 4 Mountain Scott From ipp-archive Fri May 9 16:01:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA03823 for ipp-outgoing; Fri, 9 May 1997 16:00:33 -0400 (EDT) Message-Id: <3.0.1.32.19970509125323.013b86e0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 9 May 1997 12:53:23 PDT To: John Amenyo , cmanros@cp10.es.xerox.com From: Carl-Uno Manros Subject: IPP> PRO - Re: Comm Protocols for IPP Cc: ipp@pwg.org In-Reply-To: <199705091815.AA21154@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO John, I am forwading this message to the IPP DL for discussion. Is the T.120 protocol definition available for free somewhere on the Internet, and if so can you give us a reference? Generally, the IETF is not terribly keen on using protocols to which there is no public access (or which you can only get hold of by paying lots of $$$$). Nobody has so far suggested to use T.120 as an alternative. Can you give us an idea about what it does and why you think it would be suitable for IPP? Please look at our web site at: http://www.pwg.org/ipp if you want to get more up=to-date information about the IPP project or want information about how to subscribe to our mailing list. Regards, Carl-Uno Manros At 11:15 AM 5/9/97 PDT, John Amenyo wrote: > > >I have just started reading the WG draft documents on IPP and I noticed that >the drafts proposed using HTTP as the transport protocol. > >It has occurred to me that the T.120 protocol could play some useful role, >especially if one is interested in "real-time" tele-printing over the >Internet. > >Could you tell me if the use of T.120 has been considered and if a decision >or consensus had developed that T.120 could NOT play a role? >If T.120 has not been explicitly considered/discussed by the WG, would it >be possible to get the members considered opinions on whether T.120 could >play a role at all? > >Thanks very much. > > jtA > > > > 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 May 9 17:16:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA04827 for ipp-outgoing; Fri, 9 May 1997 17:14:54 -0400 (EDT) Message-Id: <199705092117.OAA29662@slafw.sharplabs.com> Reply-To: From: "Randy Turner" To: Subject: IPP> HTTP proposal (most recent proposal) Date: Fri, 9 May 1997 13:53:22 -0700 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO After consideration of my latest document, and talking to some folks (potential IPP users), I believe that HTTP 1.1 would be sufficient to meet the requirments of IPP. I was actually thinking that we could possibly go the route of being HTTP-like, and kinda filling in with our own special requirements for IPP where HTTP failed to meet our expectations. But I don't see any thing that we want to do, that HTTP cannot do. Especially when it comes to Print-By-Reference. If you think about it, we need new requests added to the model to possibly handle Print-By-Reference. I think everyone would agree that the bulk of the documents users are going to want to print by reference are Web documents, and if our IPP servers are required to fetch these documents, then they better be HTTP compliant with regards to these requests. And if we support HTTP for Print-By-Reference, then we already have a core HTTP engine implemented (data types, methods, etc.) and the rationale for straying from using HTTP all but disappears. If we decide to use HTTP for IPP, then I think we could come up to speed much quicker in demonstrating working IPP prototypes, based on standard technology. And utilizing persistent connections I think the performance would be acceptable. We should in any case add an attribute to the printer object that identifies the URL schemes that the IPP service recognizes and supports for use in Print-By-Reference requests. On another note, regarding Roger and Keith's latest document for 'SendJob', I basically concur with most of what they are proposing. I would however like the 'document-format' attribute to be optional on SendJob. Most of the time, clients would be unable to specify this (at least in initial implementations). I'm assuming here that initial implementations will come in the flavor of port drivers and not printer drivers. I'm also not sure whether we need all of the document 'position' indicators like first, middle, and only. Seems like all we need is 'last' or some other 'end-of document' indicator. Randy From ipp-archive Fri May 9 19:26:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA05370 for ipp-outgoing; Fri, 9 May 1997 19:22:20 -0400 (EDT) Date: Fri, 9 May 1997 16:24:29 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705092324.QAA16505@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO teleconference, Monday May 5 10am-12noon PDT X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO There will be a Monday teleconference call for the IPP protocol group. dates: May 12 and 19. 10am-12noon PDT. phone number: 415-547-4810 password: 2808413 Agenda: discuss Randy's comparison document discuss CPAP any further comments on the current IPP protocol proposal. discuss agenda for Thursday's meeting. From ipp-archive Fri May 9 19:41:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA05824 for ipp-outgoing; Fri, 9 May 1997 19:37:59 -0400 (EDT) Date: Fri, 9 May 1997 19:38:05 -0400 (EDT) From: JK Martin Message-Id: <199705092338.TAA10849@uscore.underscore.com> To: Robert.Herriot@Eng.Sun.COM Subject: Re: IPP>PRO teleconference, Monday May 5 10am-12noon PDT Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Bob, I'm really sorry, but I have a conflict during this Monday's telecon, so I won't be able to participate in the CPAP (or other) discussions. If by chance the telecon time is moved to the afternoon (PST), then that would be great. However, I know this is highly unlikely. ...jay ----- Begin Included Message ----- >From ipp-owner@pwg.org Fri May 9 19:27 EDT 1997 Date: Fri, 9 May 1997 16:24:29 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) To: ipp@pwg.org Subject: IPP>PRO teleconference, Monday May 5 10am-12noon PDT There will be a Monday teleconference call for the IPP protocol group. dates: May 12 and 19. 10am-12noon PDT. phone number: 415-547-4810 password: 2808413 Agenda: discuss Randy's comparison document discuss CPAP any further comments on the current IPP protocol proposal. discuss agenda for Thursday's meeting. ----- End Included Message ----- From ipp-archive Fri May 9 23:06:49 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA06595 for ipp-outgoing; Fri, 9 May 1997 23:02:08 -0400 (EDT) Date: Fri, 9 May 1997 20:04:16 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705100304.UAA18426@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO another reason for needing byterange and document number X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO After reading through the WebNFS document and spotting the following paragraphs, I think we need byteranges and document numbers. 10.0 Timeout and Retransmission A WebNFS client should follow the example of conventional NFS clients and handle server or network outages gracefully. If a reply is not received within a given timeout, the client should retransmit the request with its original XID (described in Section 8 of RFC 1831). The XID can be used by the server to detect duplicate requests and avoid unnecessary work. While it would seem that retransmission over a TCP connection is unnecessary (since TCP is responsible for detecting and retransmitting lost data), at the RPC layer retransmission is still required for recovery from a lost TCP connection, perhaps due to a server crash or, because of resource limitations, the server has closed the connection. When the TCP connection is lost, the client must re-establish the connection and retransmit pending requests. It seems to me that this same issue exists with regard to IPP operations including those that send document data. Thus a client may send a block of document data where the transmission succeeds at the TCP level, but the server crashes before sending a "data received and processed" reponse. In such a case, the server may or may not have processed the data. Since the client will have to retransmit the data, the server needs to know whether it is new data or another copy of the last data, thus the need for byte ranges and document numbers to identify the piece of data. Comments? Bob Herriot From ipp-archive Fri May 9 23:11:49 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA07034 for ipp-outgoing; Fri, 9 May 1997 23:10:07 -0400 (EDT) Date: Fri, 9 May 1997 23:10:07 -0400 (EDT) From: JK Martin Message-Id: <199705100310.XAA13200@uscore.underscore.com> To: Robert.Herriot@Eng.Sun.COM Subject: Re: IPP>PRO another reason for needing byterange and document number Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Is IPP expected to support checkpointing to the point where the client will resume submission of document at *precisely* the point where the transmission failed? I wouldn't think so. Rather, the client would resume transmission at the *start* of the document that failed. Is this true? ...jay ----- Begin Included Message ----- >From ipp-owner@pwg.org Fri May 9 23:07 EDT 1997 Date: Fri, 9 May 1997 20:04:16 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) To: ipp@pwg.org Subject: IPP>PRO another reason for needing byterange and document number After reading through the WebNFS document and spotting the following paragraphs, I think we need byteranges and document numbers. 10.0 Timeout and Retransmission A WebNFS client should follow the example of conventional NFS clients and handle server or network outages gracefully. If a reply is not received within a given timeout, the client should retransmit the request with its original XID (described in Section 8 of RFC 1831). The XID can be used by the server to detect duplicate requests and avoid unnecessary work. While it would seem that retransmission over a TCP connection is unnecessary (since TCP is responsible for detecting and retransmitting lost data), at the RPC layer retransmission is still required for recovery from a lost TCP connection, perhaps due to a server crash or, because of resource limitations, the server has closed the connection. When the TCP connection is lost, the client must re-establish the connection and retransmit pending requests. It seems to me that this same issue exists with regard to IPP operations including those that send document data. Thus a client may send a block of document data where the transmission succeeds at the TCP level, but the server crashes before sending a "data received and processed" reponse. In such a case, the server may or may not have processed the data. Since the client will have to retransmit the data, the server needs to know whether it is new data or another copy of the last data, thus the need for byte ranges and document numbers to identify the piece of data. Comments? Bob Herriot ----- End Included Message ----- From ipp-archive Fri May 9 23:41:50 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA07527 for ipp-outgoing; Fri, 9 May 1997 23:36:55 -0400 (EDT) Date: Fri, 9 May 1997 20:38:27 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705100338.UAA18734@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, jkm@underscore.com Subject: Re: IPP>PRO another reason for needing byterange and document number Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I don't see this as checkpointing. I would assume that the client retains the data until it receives a response from the printer indicating that it has received the data. Likewise the server would know the "high water" mark for a file and ignore data below it. The question is whether the client should retransmit the failed operation or figure out how to start the sequence all over again. I am suggesting the NFS and Web NFS algorithms when I suggest retransmitting the failed operation. Do you really think it is easier for both client and server to restart the sequence of operations? Bob Herriot > From jkm@underscore.com Fri May 9 20:12:03 1997 > Date: Fri, 9 May 1997 23:10:07 -0400 (EDT) > From: JK Martin > To: Robert.Herriot@Eng > Subject: Re: IPP>PRO another reason for needing byterange and document number > Cc: ipp@pwg.org > X-Sun-Charset: US-ASCII > Content-Length: 2240 > X-Lines: 57 > > Is IPP expected to support checkpointing to the point where the > client will resume submission of document at *precisely* the point > where the transmission failed? > > I wouldn't think so. Rather, the client would resume transmission > at the *start* of the document that failed. > > Is this true? > > ...jay > > ----- Begin Included Message ----- > > From ipp-owner@pwg.org Fri May 9 23:07 EDT 1997 > Date: Fri, 9 May 1997 20:04:16 -0700 > From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) > To: ipp@pwg.org > Subject: IPP>PRO another reason for needing byterange and document number > > After reading through the WebNFS document and spotting the following paragraphs, > I think we need byteranges and document numbers. > > 10.0 Timeout and Retransmission > > A WebNFS client should follow the example of conventional NFS clients > and handle server or network outages gracefully. If a reply is not > received within a given timeout, the client should retransmit the > request with its original XID (described in Section 8 of RFC 1831). > The XID can be used by the server to detect duplicate requests and > avoid unnecessary work. > > While it would seem that retransmission over a TCP connection is > unnecessary (since TCP is responsible for detecting and > retransmitting lost data), at the RPC layer retransmission is still > required for recovery from a lost TCP connection, perhaps due to a > server crash or, because of resource limitations, the server has > closed the connection. When the TCP connection is lost, the client > must re-establish the connection and retransmit pending requests. > > > It seems to me that this same issue exists with regard to IPP operations > including those that send document data. Thus a client may send a block > of document data where the transmission succeeds at the TCP level, but > the server crashes before sending a "data received and processed" > reponse. In such a case, the server may or may not have processed the > data. Since the client will have to retransmit the data, the server > needs to know whether it is new data or another copy of the last data, > thus the need for byte ranges and document numbers to identify the > piece of data. > > Comments? > > Bob Herriot > > > ----- End Included Message ----- > > From ipp-archive Fri May 9 23:46:50 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA07939 for ipp-outgoing; Fri, 9 May 1997 23:43:42 -0400 (EDT) Date: Fri, 9 May 1997 23:43:55 -0400 (EDT) From: JK Martin Message-Id: <199705100343.XAA13377@uscore.underscore.com> To: Robert.Herriot@Eng.Sun.COM Subject: Re: IPP>PRO another reason for needing byterange and document number Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Restarting jobs due to failed transmissions can get to be a real rats nest. Just so everyone knows that... ;-) Restarting after failure can be easy or hard, depending on your criteria. I hope we don't go hog-wild here, either. Exactly where the client and server "intelligently" resume where they left off depends on a few factors. The first that pops into mind is whether the documents sent (successfully) before the failure have already been printed or not (and which of those documents have been printed, etc). We have seen several cases in which the customer preferred to print the document set in a contiguous manner on the printer. That is, even though some of the documents were printed prior to the failure, the customer would rather print all over from the beginning. (This is actually the standard BSD UNIX method of handling restarts, by the way.) Some reasonable things can be done in the area of recovery, but I'd just like to warn folks that it is often not as easy as it looks. Feature-rich, configurable checkpointing/recovery could very well be something we defer to a future release of IPP. Just my pennies worth. ...jay ----- Begin Included Message ----- >From ipp-owner@pwg.org Fri May 9 23:41 EDT 1997 Date: Fri, 9 May 1997 20:38:27 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) To: Robert.Herriot@Eng.Sun.COM, jkm@underscore.com Subject: Re: IPP>PRO another reason for needing byterange and document number Cc: ipp@pwg.org I don't see this as checkpointing. I would assume that the client retains the data until it receives a response from the printer indicating that it has received the data. Likewise the server would know the "high water" mark for a file and ignore data below it. The question is whether the client should retransmit the failed operation or figure out how to start the sequence all over again. I am suggesting the NFS and Web NFS algorithms when I suggest retransmitting the failed operation. Do you really think it is easier for both client and server to restart the sequence of operations? Bob Herriot > From jkm@underscore.com Fri May 9 20:12:03 1997 > Date: Fri, 9 May 1997 23:10:07 -0400 (EDT) > From: JK Martin > To: Robert.Herriot@Eng > Subject: Re: IPP>PRO another reason for needing byterange and document number > Cc: ipp@pwg.org > X-Sun-Charset: US-ASCII > Content-Length: 2240 > X-Lines: 57 > > Is IPP expected to support checkpointing to the point where the > client will resume submission of document at *precisely* the point > where the transmission failed? > > I wouldn't think so. Rather, the client would resume transmission > at the *start* of the document that failed. > > Is this true? > > ...jay > > ----- Begin Included Message ----- > > From ipp-owner@pwg.org Fri May 9 23:07 EDT 1997 > Date: Fri, 9 May 1997 20:04:16 -0700 > From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) > To: ipp@pwg.org > Subject: IPP>PRO another reason for needing byterange and document number > > After reading through the WebNFS document and spotting the following paragraphs, > I think we need byteranges and document numbers. > > 10.0 Timeout and Retransmission > > A WebNFS client should follow the example of conventional NFS clients > and handle server or network outages gracefully. If a reply is not > received within a given timeout, the client should retransmit the > request with its original XID (described in Section 8 of RFC 1831). > The XID can be used by the server to detect duplicate requests and > avoid unnecessary work. > > While it would seem that retransmission over a TCP connection is > unnecessary (since TCP is responsible for detecting and > retransmitting lost data), at the RPC layer retransmission is still > required for recovery from a lost TCP connection, perhaps due to a > server crash or, because of resource limitations, the server has > closed the connection. When the TCP connection is lost, the client > must re-establish the connection and retransmit pending requests. > > > It seems to me that this same issue exists with regard to IPP operations > including those that send document data. Thus a client may send a block > of document data where the transmission succeeds at the TCP level, but > the server crashes before sending a "data received and processed" > reponse. In such a case, the server may or may not have processed the > data. Since the client will have to retransmit the data, the server > needs to know whether it is new data or another copy of the last data, > thus the need for byte ranges and document numbers to identify the > piece of data. > > Comments? > > Bob Herriot > > > ----- End Included Message ----- > > ----- End Included Message ----- From ipp-archive Sat May 10 00:01:49 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA08489 for ipp-outgoing; Fri, 9 May 1997 23:58:34 -0400 (EDT) Date: Fri, 9 May 1997 21:00:02 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705100400.VAA18945@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, jkm@underscore.com Subject: Re: IPP>PRO another reason for needing byterange and document number Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > From jkm@underscore.com Fri May 9 20:45:45 1997 > > Restarting jobs due to failed transmissions can get to be a real rats > nest. Just so everyone knows that... ;-) > > Restarting after failure can be easy or hard, depending on your criteria. > I hope we don't go hog-wild here, either. > I think that I am talking about something different. I am talking about the case where a print server fails when it has partially received data. The previously received data remains intact. When the client makes contact with the server, the server resumes building the data files for the job at the point where it left off. If this were an IPP printer instead, I think the issue is the same except that the printer may have already printed a partial page so that the new data may start another partial page. I think that you are seeing some problem that I am missing. Bob Herriot > > ----- Begin Included Message ----- > > From ipp-owner@pwg.org Fri May 9 23:41 EDT 1997 > Date: Fri, 9 May 1997 20:38:27 -0700 > From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) > To: Robert.Herriot@Eng.Sun.COM, jkm@underscore.com > Subject: Re: IPP>PRO another reason for needing byterange and document number > Cc: ipp@pwg.org > > I don't see this as checkpointing. I would assume that the client retains > the data until it receives a response from the printer indicating that > it has received the data. Likewise the server would know the "high water" > mark for a file and ignore data below it. > > The question is whether the client should retransmit the failed > operation or figure out how to start the sequence all over again. I am > suggesting the NFS and Web NFS algorithms when I suggest retransmitting > the failed operation. > > Do you really think it is easier for both client and server to restart > the sequence of operations? > > > Bob Herriot > > From jkm@underscore.com Fri May 9 20:12:03 1997 > > Date: Fri, 9 May 1997 23:10:07 -0400 (EDT) > > From: JK Martin > > To: Robert.Herriot@Eng > > Subject: Re: IPP>PRO another reason for needing byterange and document number > > Cc: ipp@pwg.org > > X-Sun-Charset: US-ASCII > > Content-Length: 2240 > > X-Lines: 57 > > > > Is IPP expected to support checkpointing to the point where the > > client will resume submission of document at *precisely* the point > > where the transmission failed? > > > > I wouldn't think so. Rather, the client would resume transmission > > at the *start* of the document that failed. > > > > Is this true? > > > > ...jay > > > > ----- Begin Included Message ----- > > > > From ipp-owner@pwg.org Fri May 9 23:07 EDT 1997 > > Date: Fri, 9 May 1997 20:04:16 -0700 > > From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) > > To: ipp@pwg.org > > Subject: IPP>PRO another reason for needing byterange and document number > > > > After reading through the WebNFS document and spotting the following paragraphs, > > I think we need byteranges and document numbers. > > > > 10.0 Timeout and Retransmission > > > > A WebNFS client should follow the example of conventional NFS clients > > and handle server or network outages gracefully. If a reply is not > > received within a given timeout, the client should retransmit the > > request with its original XID (described in Section 8 of RFC 1831). > > The XID can be used by the server to detect duplicate requests and > > avoid unnecessary work. > > > > While it would seem that retransmission over a TCP connection is > > unnecessary (since TCP is responsible for detecting and > > retransmitting lost data), at the RPC layer retransmission is still > > required for recovery from a lost TCP connection, perhaps due to a > > server crash or, because of resource limitations, the server has > > closed the connection. When the TCP connection is lost, the client > > must re-establish the connection and retransmit pending requests. > > > > > > It seems to me that this same issue exists with regard to IPP operations > > including those that send document data. Thus a client may send a block > > of document data where the transmission succeeds at the TCP level, but > > the server crashes before sending a "data received and processed" > > reponse. In such a case, the server may or may not have processed the > > data. Since the client will have to retransmit the data, the server > > needs to know whether it is new data or another copy of the last data, > > thus the need for byte ranges and document numbers to identify the > > piece of data. > > > > Comments? > > > > Bob Herriot > > > > > > ----- End Included Message ----- > > > > > > > ----- End Included Message ----- > > From ipp-archive Sat May 10 21:06:59 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA09907 for ipp-outgoing; Sat, 10 May 1997 21:04:34 -0400 (EDT) Message-Id: <1.5.4.32.19970511010537.006c34a0@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: Sat, 10 May 1997 18:05:37 -0700 To: JK Martin , Robert.Herriot@Eng.Sun.COM From: Carl-Uno Manros Subject: Re: IPP>PRO another reason for needing byterange and document number Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk Status: RO At 11:10 PM 5/9/97 -0400, JK Martin wrote: >Is IPP expected to support checkpointing to the point where the >client will resume submission of document at *precisely* the point >where the transmission failed? > >I wouldn't think so. Rather, the client would resume transmission >at the *start* of the document that failed. > >Is this true? > > ...jay > Jay, starting over from the beginning is not checkpointing in my book. The whole point of checkpointing is so that you do not have to start a big transmission over again from the beginning. Carl-Uno From ipp-archive Sun May 11 04:17:02 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA10907 for ipp-outgoing; Sun, 11 May 1997 04:16:52 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Sun, 11 May 1997 02:16:56 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - new model document Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I have posted a new model document at ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970512.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970512.doc The .doc file is really a RTF file so I hope it is not infected with the concept virus. I will try to post the text version soon - the generic/text driver is crashing my machine. The pdf with line numbers is the document we will be reveiwing on Wed. Scott From ipp-archive Mon May 12 09:22:21 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA12793 for ipp-outgoing; Mon, 12 May 1997 09:20:36 -0400 (EDT) From: Roger K Debry To: Subject: Re: IPP>PRO another reason for needing byterange and documen Message-Id: <5030100002379598000002L082*@MHS> Date: Mon, 12 May 1997 09:23:03 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO The normal meaning of checkpointing is that the client determines the boundaries upon which it will restart. It then must organize the data to be sent on those boundaries. Boundaries are arbitrary. 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 05/12/97 07:07 AM --------------------------- ipp-owner @ pwg.org 05/10/97 07:13 PM Please respond to ipp-owner@pwg.org @ internet To: Robert.Herriot @ Eng.Sun.COM @ internet, jkm @ underscore.com @ internet cc: ipp @ pwg.org @ internet Subject: Re: IPP>PRO another reason for needing byterange and documen At 11:10 PM 5/9/97 -0400, JK Martin wrote: >Is IPP expected to support checkpointing to the point where the >client will resume submission of document at *precisely* the point >where the transmission failed? > >I wouldn't think so. Rather, the client would resume transmission >at the *start* of the document that failed. > >Is this true? > > ...jay > Jay, starting over from the beginning is not checkpointing in my book. The whole point of checkpointing is so that you do not have to start a big transmission over again from the beginning. Carl-Uno From ipp-archive Mon May 12 09:27:23 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA12808 for ipp-outgoing; Mon, 12 May 1997 09:22:35 -0400 (EDT) From: Roger K Debry To: Subject: Re: IPP>PRO another reason for needing byterange and documen Message-Id: <5030100002379634000002L042*@MHS> Date: Mon, 12 May 1997 09:25:01 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Yes, I thought we had already agreed to this. >Jay Martin write ... >Feature-rich, configurable checkpointing/recovery could very well be >something we defer to a future release of IPP. > >Just my pennies worth. ...jay From ipp-archive Mon May 12 09:57:21 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA13766 for ipp-outgoing; Mon, 12 May 1997 09:55:46 -0400 (EDT) From: Roger K Debry To: Subject: Re: IPP>PRO another reason for needing byterange and documen Message-Id: <5030100002380558000002L082*@MHS> Date: Mon, 12 May 1997 09:58:14 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Bob, I'm glad that someone else finally realizes that we need something in the IPP layer to help with recovery. If you would go back to the protocol proposal that I presented in the San Jose PWG meeting, you will see that what we are getting very close to that proposal. However, that proposal used a sequence number, rather than byte range. I believe that byte range is definate overkill, and a sequence number would be simpler (especially for a re-director) to generate. Bob Berriot Wrote: > A WebNFS client should follow the example of conventional >NFS clients and handle server or network outages gracefully. >If a reply is not received within a given timeout, the client >should retransmit the request with its original XID (described >in Section 8 of RFC 1831). The XID can be used by the server >to detect duplicate requests and avoid unnecessary work. >While it would seem that retransmission over a TCP connection >is unnecessary (since TCP is responsible for detecting and >retransmitting lost data), at the RPC layer retransmission is >still required for recovery from a lost TCP connection, perhaps >due to a server crash or, because of resource limitations, the >server has closed the connection. When the TCP connection >is lost, the client must re-establish the connection and >retransmit pending requests. It seems to me that this same issue > exists with regard to IPP operations including those that send >document data. Thus a client may send a block of document >data where the transmission succeeds at the TCP level, but >the server crashes before sending a "data received and >processed" reponse. In such a case, the server may or may >not have processed the data. Since the client will have to >retransmit the data, the server needs to know whether it is new >data or another copy of the last data, thus the need for byte ranges >and document numbers to identify the piece of data. >Comments? >Bob Herriot From ipp-archive Mon May 12 10:08:05 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA14231 for ipp-outgoing; Mon, 12 May 1997 10:05:54 -0400 (EDT) From: Roger K Debry To: Subject: Re: IPP>PRO another reason for needing byterange and documen Message-Id: <5030100002380905000002L052*@MHS> Date: Mon, 12 May 1997 10:08:21 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO >Jay Martin wrote: >Is IPP expected to support checkpointing to the point where the >client will resume submission of document at *precisely* the point >where the transmission failed? >I wouldn't think so. Rather, the client would resume transmission >at the *start* of the document that failed. >Is this true? ...jay There are several places you could restart: 1) The entire job (not adequate for large production environments. 2) The document that failed (also not adequate for large production jobs. Although there was some argument that large jobs could be broken up into multiple documents, I doubt that we want IPP to have that kind of impact on existing production applications. At least I'm not willing to go and tell my customers that they have to rewrite their apps.) 3) The last Send Document - this doesn't seem too difficult, especially with sequence numbers to identify each segment. This also seems like a rational boundary to build checkpoints on. 4) bytes within a Send Document - much harder to do, requires some dialogue between the client and the server to synchronize data. 5) You could also restart on a page boundary, but this is really much harder to do. From ipp-archive Mon May 12 10:17:24 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA14716 for ipp-outgoing; Mon, 12 May 1997 10:15:51 -0400 (EDT) From: Roger K Debry To: Subject: IPP>MOD - Multiple documents per job Message-Id: <5030100002381165000002L052*@MHS> Date: Mon, 12 May 1997 10:18:18 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I polled our operating systems on the proposal to handle multiple document jobs by carrying all of the document attributes for each document up front in the Create Jobs. The response was nearly unanimous that this is too difficult for existing printing systems to comply with. Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-archive Mon May 12 11:12:23 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA15330 for ipp-outgoing; Mon, 12 May 1997 11:08:22 -0400 (EDT) Message-ID: <01BC5F31.CD219E60@tagosaku.gv.atsugi.fujixerox.co.jp> From: Takemi Yamazaki To: "ipp@pwg.org" Subject: IPP> Would you please delete my name from the mailing list? Date: Tue, 13 May 1997 00:07:29 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Takemi Yamazaki Fuji Xerox From ipp-archive Mon May 12 15:02:24 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA17011 for ipp-outgoing; Mon, 12 May 1997 14:59:45 -0400 (EDT) Message-Id: <3.0.1.32.19970512115423.00e21d48@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 12 May 1997 11:54:23 PDT To: Paul Moore From: Carl-Uno Manros Subject: IPP> Re: IETF draft for publication Cc: ipp@pwg.org In-Reply-To: <41135C785691CF11B73B00805FD4D2D7028C4E5F@RED-17-MSG.dns.mi crosoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO At 10:01 AM 5/12/97 PDT, Paul Moore wrote: >Carl-Uno, > >Can you publish this in readiness for Thursday's meeting (its in word 95 >format) > >Thanks > >Paul > > Paul, thanks, I have just uploaded your new document into the new_PRO folder under the names: swp-rfc95.doc and swp-rfc95.txt I will add a .pdf version this evening. 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 May 12 15:32:24 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA17514 for ipp-outgoing; Mon, 12 May 1997 15:30:40 -0400 (EDT) Date: Mon, 12 May 1997 12:32:42 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705121932.MAA21295@woden.eng.sun.com> To: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP>MOD - Multiple documents per job X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Perhaps the fall back position is that all attributes are up front in Create Jobs, and that an allowed value is "forward". Then a server knows that if the job has no forward values, it knows all it needs to know about the job in advance. > From rdebry@us.ibm.com Mon May 12 07:23:05 1997 > > I polled our operating systems on the proposal to handle > multiple document jobs by carrying all of the document > attributes for each document up front in the Create Jobs. > > The response was nearly unanimous that this is too difficult > for existing printing systems to comply with. > > Roger K deBry > Senior Techncial Staff Member > Architecture and Technology > IBM Printing Systems > email: rdebry@us.ibm.com > phone: 1-303-924-4080 > From ipp-archive Mon May 12 15:52:25 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA17998 for ipp-outgoing; Mon, 12 May 1997 15:48:00 -0400 (EDT) From: Roger K Debry To: Subject: Re: IPP>MOD - Multiple documents per job Message-Id: <5030100002395274000002L042*@MHS> Date: Mon, 12 May 1997 15:50:25 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Can you say more ... I'm not clear on exactly what you are proposing? 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 05/12/97 01:44 PM --------------------------- ipp-owner @ pwg.org 05/12/97 01:38 PM Please respond to ipp-owner@pwg.org @ internet To: Roger K Debry/Boulder/IBM, ipp @ pwg.org @ internet cc: Subject: Re: IPP>MOD - Multiple documents per job Perhaps the fall back position is that all attributes are up front in Create Jobs, and that an allowed value is "forward". Then a server knows that if the job has no forward values, it knows all it needs to know about the job in advance. > From rdebry@us.ibm.com Mon May 12 07:23:05 1997 > > I polled our operating systems on the proposal to handle > multiple document jobs by carrying all of the document > attributes for each document up front in the Create Jobs. > > The response was nearly unanimous that this is too difficult > for existing printing systems to comply with. > > Roger K deBry > Senior Techncial Staff Member > Architecture and Technology > IBM Printing Systems > email: rdebry@us.ibm.com > phone: 1-303-924-4080 > From ipp-archive Mon May 12 16:02:24 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA18467 for ipp-outgoing; Mon, 12 May 1997 16:02:04 -0400 (EDT) From: Roger K Debry To: Subject: IPP> Re: IETF draft for publication Message-Id: <5030100002395868000002L082*@MHS> Date: Mon, 12 May 1997 16:04:29 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I hope that this submission is intended as Microsoft's/HP's suggestions for mapping the IPP model to a protocol. We clearly need and value their help and suggestions to make IPP the best possible solution that we can. If however, it is intended as a competitive protocol (And this is sure the way the document reads) then I'm not sure what to do with it. I'd like to have one standard and have Microsoft and HP contribute to it in significant way to make it be the best possible interface that we can. To see a proposal for a different (but similar) standard smacks of Microsoft and HP just doing their own thing and expecting the rest of us to accept it as a standard. Not my view of good community! 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 05/12/97 01:45 PM --------------------------- ipp-owner @ pwg.org 05/12/97 01:07 PM Please respond to ipp-owner@pwg.org @ internet To: paulmo @ microsoft.com @ internet cc: ipp @ pwg.org @ internet Subject: IPP> Re: IETF draft for publication At 10:01 AM 5/12/97 PDT, Paul Moore wrote: >Carl-Uno, > >Can you publish this in readiness for Thursday's meeting (its in word 95 >format) > >Thanks > >Paul > > Paul, thanks, I have just uploaded your new document into the new_PRO folder under the names: swp-rfc95.doc and swp-rfc95.txt I will add a .pdf version this evening. 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 May 12 16:12:36 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA18930 for ipp-outgoing; Mon, 12 May 1997 16:10:39 -0400 (EDT) Date: Mon, 12 May 1997 13:12:39 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705122012.NAA21676@woden.eng.sun.com> To: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP>MOD - Multiple documents per job X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I am proposing a mechanism that is similar to what PDF and PostScript use when a value cannot be computed until later in a job. If a client does not know the value of some attribute when it is performing the CreateJob operation, it includes the attribute, but sets its value to "forward". This lets the server know that the client is specifying the information and to expect the information later. Some servers will not be able to handle certain attributes later. It may be that "forward" needs to be more specific, namely "before document" "after document" or "end of job". For example, the number-of-documents may be "forward, end-of-job" because the client doesn't know until the entire job is submitted. I don't want to propose a general mechanism at this time, but I wonder if you could ask the people who didn't want to specify everything up front to be more specific about what they could specify up front and what they could not. Also, ask them when they would be able to specify the information: before-the-document, after-the-document, or end-of-job? I would hope that the list of items that have to wait is small. Bob Herriot > From rdebry@us.ibm.com Mon May 12 12:55:19 1997 > > Can you say more ... I'm not clear on exactly > what you are proposing? > > > To: Roger K Debry/Boulder/IBM, ipp @ pwg.org @ internet > cc: > Subject: Re: IPP>MOD - Multiple documents per job > > Perhaps the fall back position is that all attributes are up front > in Create Jobs, and that an allowed value is "forward". Then > a server knows that if the job has no forward values, it knows > all it needs to know about the job in advance. > > > From rdebry@us.ibm.com Mon May 12 07:23:05 1997 > > > > I polled our operating systems on the proposal to handle > > multiple document jobs by carrying all of the document > > attributes for each document up front in the Create Jobs. > > > > The response was nearly unanimous that this is too difficult > > for existing printing systems to comply with. > > > > Roger K deBry > > Senior Techncial Staff Member > > Architecture and Technology > > IBM Printing Systems > > email: rdebry@us.ibm.com > > phone: 1-303-924-4080 > > > > > > From ipp-archive Mon May 12 16:12:36 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA18919 for ipp-outgoing; Mon, 12 May 1997 16:10:09 -0400 (EDT) Message-Id: <3.0.1.32.19970512121750.00e2d500@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 12 May 1997 12:17:50 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> PRO - Re: Comm Protocols for IPP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO >Return-Path: >Date: Mon, 12 May 1997 07:40:08 PDT >From: John Amenyo >To: Carl-Uno Manros >Subject: Re: PRO - Re: Comm Protocols for IPP > > >The T.120 std is an ITU-TSS standard. It has been designed for "real-time >multi-point communications." Namely, it is used for real-time data sharing >in heterogenous environments. T.120 has also been adopted for the data >sharing portion of the H.323 ITU standard >H.323 in turn is likely to become the basis for all real-time conferencing >(over the Internet + Intranets + Extranets) (voice/audio, video, data, >multimedia). > >T.120 has been endorsed by many vendors in the computing and communications >industries. A primer on T.120 exists at: > > http://www.databeam.com/Products/CCTS/t120primer/t120primer.html > >What is the connection with (tele-) printing over the Internet? > >Real-time (desktop/video/tele-) conferencing is a form of real-time >human-to-human communication/messaging. Real-time tele-printing is easily >conceived as a form of human-to-machine or machine-to-machine comm/messaging, >particularly, if one chooses to regard it as document transfer and management. >In effect, the machines "conference" in real-time, e.g., negotiating printing >options; there occurs document/(bulk) data transfer from one to another >(a printer) which then prints the document. > > human---desktop-----------Net---------------------------printer > > > human---desktop-----------Net-----------printserver-----printer > > > human---desktop-----------Net-----------printserver-----printer > | > +-----------printer > >Once this viewpoint is accepted, the solutions already worked on in T.120 >can be used to solved some of the problems you are likely to encounter >in Printing-over-the-Internet: > > * Real-time support > * Locating/Discovery/Registration of Printers/PrintServers > * Document distribution to multiple printers (c.f., multicast > and "multi-point" printing). > * Handling security issues. > >Furthermore, some printing over the Internet is likely to occur as part of >human-to-human conferencing (e.g., at the end of conferencing sessions), >so using T.120 would most likely make it easy to support this. Furthermore, >since H.323 (and thus T.120) has been adopted by Intel and Microsoft for >Internet telephony interoperability, creating a role for T.120 in printing >over the Internet means that any printing occuring in conjunction with >Internet telephony sessions could easily be accommodated without the need >for extra "comm pathway" software in the machines providing the service. > >I got the impression (probably unfair since I have not finished reading the >IPP stuff) that IPP would be most suitable for point-to-point printing, >particularly in the context of a user trying to print documents encountered >in the Web/HTML environment. But what about tele-printing of massive >documents in a distributed document management situation? How would one >handle the scenario where the document resides on a different machine >than the user's desktop/workstation and the document is to transferred and >printed elsewhere at a remote location? What about the support for "printing" >to unconventional "printer-like" devices such as COM, CD-ROM mastering, CD-R >and DVD recording? What about support for "printing" "multimedia" documents? > >I am not sure T.120 and HTTP would necessarily be competing with each other >in real-time tele-printing. In much the same way I don't think they would >compete when Web sessions are used concurrently with real-time desktop >conferencing. For example, a T.120 data sharing session could actually be >the mutual viewing of Web pages (which are accessed via HTTP). > >I cannot really provide a good answer to standards documentations/resources >which cost a lot of money. Nonetheless, I think the IETF's experience with >other standards such as the various Ethernet stds and ATM indicates that >both sides could find a common ground if there is a will and willingness to >leverage the strengths of each other. > >Finally, I am not particularly advocating that T.120 ought to be used in >printing-over-the-Internet. I thought the "conferencing" (human/human vs >machine/machine) is particularly strong and I would like to hear what >others think about exploiting T.120 for real-time tele-printing, provided one >could ignore the "political" issues for a moment :-) > > >Thanks for your response. > > > jtA > >> John, >> >> I am forwading this message to the IPP DL for discussion. Is the T.120 >> protocol definition available for free somewhere on the Internet, and if so >> can you give us a reference? Generally, the IETF is not terribly keen on >> using protocols to which there is no public access (or which you can only >> get hold of by paying lots of $$$$). Nobody has so far suggested to use >> T.120 as an alternative. Can you give us an idea about what it does and >> why you think it would be suitable for IPP? >> >> Please look at our web site at: http://www.pwg.org/ipp if you want to get >> more up=to-date information about the IPP project or want information about >> how to subscribe to our mailing list. >> >> Regards, >> >> Carl-Uno Manros >> >> At 11:15 AM 5/9/97 PDT, John Amenyo wrote: >> > >> > >> >I have just started reading the WG draft documents on IPP and I noticed that >> >the drafts proposed using HTTP as the transport protocol. >> > >> >It has occurred to me that the T.120 protocol could play some useful role, >> >especially if one is interested in "real-time" tele-printing over the >> >Internet. >> > >> >Could you tell me if the use of T.120 has been considered and if a decision >> >or consensus had developed that T.120 could NOT play a role? >> >If T.120 has not been explicitly considered/discussed by the WG, would it >> >be possible to get the members considered opinions on whether T.120 could >> >play a role at all? >> > >> >Thanks very much. >> > >> > jtA >> > >> > >> > >> > >> 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 >> > > > 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 May 12 17:32:25 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA20186 for ipp-outgoing; Mon, 12 May 1997 17:30:49 -0400 (EDT) Message-Id: <199705122031.QAA02879@devnix.agranat.com> To: ipp@pwg.org Subject: IPP> SEC In-reply-to: <9705071154.AA00157@cabeza.cp10.es.xerox.com> Date: Mon, 12 May 1997 16:31:15 -0400 From: "Scott Lawrence" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO SEC> RFC 2069: This provides some limited security services, mainly SEC> only client side authentication. Security specialists frown upon SEC> this solution because it uses unencrypted user names and SEC> passwords. However, this solution could be used in combination SEC> with a protocol that provides for secure transport. RFC 2069 does not transmit user names or passwords in any form - put simply, it transmits a cryptographic digest derived from the username, password, and a server generated challenge. The authentication derives from the fact that the client cannot generate it correctly without knowing the user credentials. SEC> SHTTP - Secure HTTP: Although on the IETF standards track, this SEC> seems to lack some important features and does not seem to go SEC> anywhere in the market place. Actually, I believe that it provides everything IPP would need (including non-repudiation - a service that has received too little attention), but it is true that it may not be getting enough support from the marketplace and doesn't seem to enjoy support in the IESG (I don't know why not). -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-archive Mon May 12 17:47:25 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA20689 for ipp-outgoing; Mon, 12 May 1997 17:46:40 -0400 (EDT) From: Roger K Debry To: Subject: Re: IPP>MOD - Multiple documents per job Message-Id: <5030100002400295000002L052*@MHS> Date: Mon, 12 May 1997 17:49:04 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Bob, here is an alternative that I think my systems could easily handle: If the client wants confirmation that the job will be accepted before it sends any document content. then it must include all of the attributes it wants validated up front in create job. If it doesn't care, then it does not have to. Document attributes in the create job are not in any specific order and are viewed just as a collection of attributes, i.e. they are not in document order nor are they to be associated with particular documents in some fashion. The request just says, here is a bunch of attributes, can the Printer support them? For example, if I had a job with the following documents -- a Postscript document, a PCL document, a PCL document, a text document, a PCL document, and a Postscript document, the attributes in create job would be , not . Attributes would be repeated in subsequent send document operations as part of the document they belong to. This allows the server to validate the attributes, but not have to save the values and associate them with the documents which may come later in the stream. Clients which don't care about up front validation don't have to declare document attributes in create job, they would be part of each document just as in the validation case. This would make the server side much simpler. It does not add any complexity to the client, and only increases the over-all size of the data transmitted sightly larger. Comments?? 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 05/12/97 03:06 PM --------------------------- ipp-owner @ pwg.org 05/12/97 02:22 PM Please respond to ipp-owner@pwg.org @ internet To: Roger K Debry/Boulder/IBM, ipp @ pwg.org @ internet cc: Subject: Re: IPP>MOD - Multiple documents per job I am proposing a mechanism that is similar to what PDF and PostScript use when a value cannot be computed until later in a job. If a client does not know the value of some attribute when it is performing the CreateJob operation, it includes the attribute, but sets its value to "forward". This lets the server know that the client is specifying the information and to expect the information later. Some servers will not be able to handle certain attributes later. It may be that "forward" needs to be more specific, namely "before document" "after document" or "end of job". For example, the number-of-documents may be "forward, end-of-job" because the client doesn't know until the entire job is submitted. I don't want to propose a general mechanism at this time, but I wonder if you could ask the people who didn't want to specify everything up front to be more specific about what they could specify up front and what they could not. Also, ask them when they would be able to specify the information: before-the-document, after-the-document, or end-of-job? I would hope that the list of items that have to wait is small. Bob Herriot > From rdebry@us.ibm.com Mon May 12 12:55:19 1997 > > Can you say more ... I'm not clear on exactly > what you are proposing? > > > To: Roger K Debry/Boulder/IBM, ipp @ pwg.org @ internet > cc: > Subject: Re: IPP>MOD - Multiple documents per job > > Perhaps the fall back position is that all attributes are up front > in Create Jobs, and that an allowed value is "forward". Then > a server knows that if the job has no forward values, it knows > all it needs to know about the job in advance. > > > From rdebry@us.ibm.com Mon May 12 07:23:05 1997 > > > > I polled our operating systems on the proposal to handle > > multiple document jobs by carrying all of the document > > attributes for each document up front in the Create Jobs. > > > > The response was nearly unanimous that this is too difficult > > for existing printing systems to comply with. > > > > Roger K deBry > > Senior Techncial Staff Member > > Architecture and Technology > > IBM Printing Systems > > email: rdebry@us.ibm.com > > phone: 1-303-924-4080 > > > > > > From ipp-archive Mon May 12 21:37:27 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA22282 for ipp-outgoing; Mon, 12 May 1997 21:35:25 -0400 (EDT) Date: Mon, 12 May 1997 18:37:29 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705130137.SAA24521@woden.eng.sun.com> To: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP>MOD - Multiple documents per job X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Your suggestion seems to add some additional information that a client must supply about needed resources. Then the client supplies the information twice, in a summary at the beginning of the job and detailed information with each job. If the client has such information at the beginning, I would expect it could fully specify all attributes. If we are going to have all job attributes at the beginning of the job (and we may abandon the idea), then I believe that any attribute that pertains to a particular document is identified so that no additional information needs to be supplied with the document itself, unless a value is marked as "forward". I think that this idea started out as a simplification. We need to keep it that way or abandon it. We need to be clear about what problem we are solving here. Bob Herriot > From rdebry@us.ibm.com Mon May 12 14:53:59 1997 > > Bob, here is an alternative that I think my systems > could easily handle: > > If the client wants confirmation that the job will be accepted > before it sends any document content. then it must include > all of the attributes it wants validated up front in create job. > If it doesn't care, then it does not have to. > > Document attributes in the create job are not in any specific > order and are viewed just as a collection of attributes, i.e. > they are not in document order nor are they to be associated > with particular documents in some fashion. The request just > says, here is a bunch of attributes, can the Printer support > them? > > For example, if I had a job with the following documents -- > a Postscript document, a PCL document, a PCL document, > a text document, a PCL document, and a Postscript > document, the attributes in create job would be > > , > > not > > . > > Attributes would be repeated in subsequent send document > operations as part of the document they belong to. This > allows the server to validate the attributes, but not have to > save the values and associate them with the > documents which may come later in the stream. Clients which > don't care about up front validation don't have to declare > document attributes in create job, they would be part of each > document just as in the validation case. > > This would make the server side much simpler. It does not > add any complexity to the client, and only increases the > over-all size of the data transmitted sightly larger. > > Comments?? > > 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 05/12/97 03:06 > PM --------------------------- > > ipp-owner @ pwg.org > 05/12/97 02:22 PM > Please respond to ipp-owner@pwg.org @ internet > > > To: Roger K Debry/Boulder/IBM, ipp @ pwg.org @ internet > cc: > Subject: Re: IPP>MOD - Multiple documents per job > > I am proposing a mechanism that is similar to what PDF and PostScript use > when a value cannot be computed until later in a job. > > If a client does not know the value of some attribute when it is > performing the CreateJob operation, it includes the attribute, but > sets its value to "forward". This lets the server know that the client > is specifying the information and to expect the > information later. Some servers will not be able to handle certain > attributes later. It may be that "forward" needs to be more > specific, namely "before document" "after document" or "end of job". > > For example, the number-of-documents may be "forward, end-of-job" > because the client doesn't know until the entire job is submitted. > > I don't want to propose a general mechanism at this time, but I > wonder if you could ask the people who didn't want to specify everything > up front to be more specific about what they could specify up front > and what they could not. Also, ask them when they would be able > to specify the information: before-the-document, after-the-document, or > end-of-job? I would hope that the list of items > that have to wait is small. > > Bob Herriot > > > > From rdebry@us.ibm.com Mon May 12 12:55:19 1997 > > > > Can you say more ... I'm not clear on exactly > > what you are proposing? > > > > > > To: Roger K Debry/Boulder/IBM, ipp @ pwg.org @ internet > > cc: > > Subject: Re: IPP>MOD - Multiple documents per job > > > > Perhaps the fall back position is that all attributes are up front > > in Create Jobs, and that an allowed value is "forward". Then > > a server knows that if the job has no forward values, it knows > > all it needs to know about the job in advance. > > > > > From rdebry@us.ibm.com Mon May 12 07:23:05 1997 > > > > > > I polled our operating systems on the proposal to handle > > > multiple document jobs by carrying all of the document > > > attributes for each document up front in the Create Jobs. > > > > > > The response was nearly unanimous that this is too difficult > > > for existing printing systems to comply with. > > > > > > Roger K deBry > > > Senior Techncial Staff Member > > > Architecture and Technology > > > IBM Printing Systems > > > email: rdebry@us.ibm.com > > > phone: 1-303-924-4080 > > > > > > > > > > > > > > > From ipp-archive Tue May 13 00:47:29 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA23382 for ipp-outgoing; Tue, 13 May 1997 00:46:14 -0400 (EDT) Message-ID: <3377F228.3E6E@parc.xerox.com> Date: Mon, 12 May 1997 21:46:32 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: Roger K Debry CC: ipp@pwg.org Subject: Re: IPP> Re: IETF draft for publication References: <5030100002395868000002L082*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > To see a > proposal for a different (but similar) standard smacks > of Microsoft and HP just doing their own thing and expecting > the rest of us to accept it as a standard. I believe we will be best served if we accept the proposal as if it had been submitted in good faith, no matter what you might believe about the intentions of the submitters. Personally, I see sending us a copy for review and discussion as significantly different than "doing their own thing and expecting the rest of us to accept it as a standard", as has been done, e.g., with the so-called "Internet Imaging Protocol." From ipp-archive Tue May 13 09:32:33 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA25821 for ipp-outgoing; Tue, 13 May 1997 09:31:01 -0400 (EDT) From: Roger K Debry To: Subject: Re: IPP>MOD - Multiple documents per job Message-Id: <5030100002419120000002L002*@MHS> Date: Tue, 13 May 1997 09:33:18 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO ... snip ... If we are going to have all job attributes at the beginning of the job (and we may abandon the idea), then I believe that any attribute that pertains to a particular document is identified so that no additional information needs to be supplied with the document itself, unless a value is marked as "forward". RKD> Although it may require some duplication of RKD> attributes, I believe my scheme to be simpler RKD> for the following reasons: RKD> Your scheme will require some addditional RKD> structuring of the data on Create Job to RKD> be able to define which document a set of RKD> attributes is associated with. This means extra RKD> parsing and processing of the input stream. RKD> My proposal does not require this. RKD> Your scheme always requires the client build RKD> this information up in the Create Job, using RKD> the forward attribute when it does not have RKD> the information available when Create Job is RKD> built. My proposal only requires this if the client RKD> wishes to have up-front validation. A well- RKD> behaved client should not require validation, RKD> since it queries the printer before it builds the RKD> Create Job request. RKD> Your scheme requires the Printer remember RKD> the per document attributes, and then be RKD> able to recall them when actually processing RKD> the data for that job. My proposal does not RKD> require this. I think that this idea started out as a simplification. We need to keep it that way or abandon it. We need to be clear about what problem we are solving here. RKD> I thought that the discussion that triggered this RKD> idea was to allow the Printer to validate the PDLs RKD> of all documents in the job, at Create Document RKD> time. Is it more than this? Bob Herriot > From rdebry@us.ibm.com Mon May 12 14:53:59 1997 > > Bob, here is an alternative that I think my systems > could easily handle: > > If the client wants confirmation that the job will be accepted > before it sends any document content. then it must include > all of the attributes it wants validated up front in create job. > If it doesn't care, then it does not have to. > > Document attributes in the create job are not in any specific > order and are viewed just as a collection of attributes, i.e. > they are not in document order nor are they to be associated > with particular documents in some fashion. The request just > says, here is a bunch of attributes, can the Printer support > them? > > For example, if I had a job with the following documents -- > a Postscript document, a PCL document, a PCL document, > a text document, a PCL document, and a Postscript > document, the attributes in create job would be > > , > > not > > . > > Attributes would be repeated in subsequent send document > operations as part of the document they belong to. This > allows the server to validate the attributes, but not have to > save the values and associate them with the > documents which may come later in the stream. Clients which > don't care about up front validation don't have to declare > document attributes in create job, they would be part of each > document just as in the validation case. > > This would make the server side much simpler. It does not > add any complexity to the client, and only increases the > over-all size of the data transmitted sightly larger. > > Comments?? > > 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 05/12/97 03:06 > PM --------------------------- > > ipp-owner @ pwg.org > 05/12/97 02:22 PM > Please respond to ipp-owner@pwg.org @ internet > > > To: Roger K Debry/Boulder/IBM, ipp @ pwg.org @ internet > cc: > Subject: Re: IPP>MOD - Multiple documents per job > > I am proposing a mechanism that is similar to what PDF and PostScript use > when a value cannot be computed until later in a job. > > If a client does not know the value of some attribute when it is > performing the CreateJob operation, it includes the attribute, but > sets its value to "forward". This lets the server know that the client > is specifying the information and to expect the > information later. Some servers will not be able to handle certain > attributes later. It may be that "forward" needs to be more > specific, namely "before document" "after document" or "end of job". > > For example, the number-of-documents may be "forward, end-of-job" > because the client doesn't know until the entire job is submitted. > > I don't want to propose a general mechanism at this time, but I > wonder if you could ask the people who didn't want to specify everything > up front to be more specific about what they could specify up front > and what they could not. Also, ask them when they would be able > to specify the information: before-the-document, after-the-document, or > end-of-job? I would hope that the list of items > that have to wait is small. > > Bob Herriot > > > > From rdebry@us.ibm.com Mon May 12 12:55:19 1997 > > > > Can you say more ... I'm not clear on exactly > > what you are proposing? > > > > > > To: Roger K Debry/Boulder/IBM, ipp @ pwg.org @ internet > > cc: > > Subject: Re: IPP>MOD - Multiple documents per job > > > > Perhaps the fall back position is that all attributes are up front > > in Create Jobs, and that an allowed value is "forward". Then > > a server knows that if the job has no forward values, it knows > > all it needs to know about the job in advance. > > > > > From rdebry@us.ibm.com Mon May 12 07:23:05 1997 > > > > > > I polled our operating systems on the proposal to handle > > > multiple document jobs by carrying all of the document > > > attributes for each document up front in the Create Jobs. > > > > > > The response was nearly unanimous that this is too difficult > > > for existing printing systems to comply with. > > > > > > Roger K deBry > > > Senior Techncial Staff Member > > > Architecture and Technology > > > IBM Printing Systems > > > email: rdebry@us.ibm.com > > > phone: 1-303-924-4080 > > > > > > > > > > > > > > > From ipp-archive Tue May 13 11:17:35 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA26517 for ipp-outgoing; Tue, 13 May 1997 11:13:31 -0400 (EDT) Message-ID: <337884D9.73F8@sharplabs.com> Date: Tue, 13 May 1997 08:12:25 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> RE: Multiple documents per job Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Can we not just include in the CreateJob operation, the default attributes for the job, then when we actually send the job data, use entity headers per document to possibly override the defaults? Maybe I'm oversimplifying the problem,it seems simple to me. Randy From ipp-archive Tue May 13 18:12:37 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA27872 for ipp-outgoing; Tue, 13 May 1997 18:09:05 -0400 (EDT) Date: Tue, 13 May 1997 14:47:27 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705132147.OAA04849@woden.eng.sun.com> To: ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP> RE: Multiple documents per job X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > From rturner@sharplabs.com Tue May 13 08:20:48 1997 > > Can we not just include in the CreateJob operation, the default > attributes for the job, then when we actually send the job data, > use entity headers per document to possibly override the defaults? > > Maybe I'm oversimplifying the problem,it seems simple to me. > > Randy > That's what we started with. As proposals get more complicated to solve problems that may not be very important, I suggest we go back to Randy suggests. Bob Herriot From ipp-archive Wed May 14 09:07:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA29697 for ipp-outgoing; Wed, 14 May 1997 09:05:51 -0400 (EDT) From: Roger K Debry To: Subject: Re: IPP> RE: Multiple documents per job Message-Id: <5030100002452236000002L062*@MHS> Date: Wed, 14 May 1997 09:08:06 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I agree. Thanks Randy for helping us keep focused on simplification. 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 05/14/97 07:01 AM --------------------------- ipp-owner @ pwg.org 05/13/97 04:16 PM Please respond to ipp-owner@pwg.org @ internet To: rturner @ sharplabs.com @ internet, ipp @ pwg.org @ internet cc: Subject: Re: IPP> RE: Multiple documents per job > From rturner@sharplabs.com Tue May 13 08:20:48 1997 > > Can we not just include in the CreateJob operation, the default > attributes for the job, then when we actually send the job data, > use entity headers per document to possibly override the defaults? > > Maybe I'm oversimplifying the problem,it seems simple to me. > > Randy > That's what we started with. As proposals get more complicated to solve problems that may not be very important, I suggest we go back to Randy suggests. Bob Herriot From ipp-archive Fri May 16 03:33:08 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA04537 for ipp-outgoing; Fri, 16 May 1997 03:31:11 -0400 (EDT) Message-Id: <199705160731.AA14189@interlock2.lexmark.com> To: "ipp%pwg.org" From: Don Wright Date: 16 May 97 3:19:07 EDT Subject: IPP> PRO: Paul Moore's Presentation Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I have uploaded Paul Moore's (of Microsoft) presentation on the Simple Web Protocol to the ftp server. It is located at: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/swp9705.pdf Since this was a powerpoint presentation, there is no text only version available. 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 May 16 21:38:19 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA05977 for ipp-outgoing; Fri, 16 May 1997 21:37:24 -0400 (EDT) Date: Fri, 16 May 1997 18:39:20 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705170139.SAA14233@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO Monday 5/19 meeting (canceled) X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I am cancelling the Monday 5/19 meeting because I don't think we are ready to do anything new until Randy and I have a chance to write up what we agreed to yesterday. Bob Herriot From ipp-archive Fri May 16 21:38:20 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA05966 for ipp-outgoing; Fri, 16 May 1997 21:34:49 -0400 (EDT) Message-ID: <337C1153.61C6@parc.xerox.com> Date: Fri, 16 May 1997 00:48:35 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: Don Wright CC: "ipp%pwg.org" Subject: Re: IPP> PRO: Paul Moore's Presentation References: <199705160731.AA14189@interlock2.lexmark.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO ftp://ftp.parc.xerox.com/pub/masinter/http-ng.html are the slides I was reading from. Larry -- http://www.parc.xerox.com/masinter From ipp-archive Mon May 19 00:08:48 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA11555 for ipp-outgoing; Mon, 19 May 1997 00:08:10 -0400 (EDT) Message-Id: <199705190412.NAA29853@fuji.mol.minolta.co.jp> Date: Mon, 19 May 1997 13:07:51 +0900 To: ipp@pwg.org From: kita@mol.minolta.co.jp (Yasunari Kitagaki) X-Sender: kita@fuji.mol.minolta.co.jp Subject: IPP>DIR OID and string attribute Cc: kita@mol.minolta.oc.jp MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-Mailer: Eudora-J(1.3.8-J13) Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I have read the document, named ipp-dir-schema-2.0, and I would like to clarify about mapping the ipp-dir-schema to LDAP. -What are the attributes described as the string or OID? In LDAP, attribute name must be desided as the string or be mapped to OID. >From RFC1777 Appendix A, AttributeType ::= LDAPString -- text name of the attribute, or dotted -- OID representation AttributeValue ::= OCTET STRING LDAP ::= OCTET STRING If there is the documentatation, let me know its URL. ---------------------------- Yasunari Kitagaki kita@mol.minolta.co.jp Minolta Co., Ltd. From ipp-archive Mon May 19 09:23:54 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA12657 for ipp-outgoing; Mon, 19 May 1997 09:21:27 -0400 (EDT) From: Roger K Debry To: Subject: IPP>PRO Monday 5/19 meeting (canceled) Message-Id: <5030100002624340000002L002*@MHS> Date: Mon, 19 May 1997 09:23:50 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO For those of us not at the PWG meeting, what did you agree to??? 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 05/19/97 07:18 AM --------------------------- ipp-owner @ pwg.org 05/16/97 07:47 PM Please respond to ipp-owner@pwg.org @ internet To: ipp @ pwg.org @ internet cc: Subject: IPP>PRO Monday 5/19 meeting (canceled) I am cancelling the Monday 5/19 meeting because I don't think we are ready to do anything new until Randy and I have a chance to write up what we agreed to yesterday. Bob Herriot From ipp-archive Mon May 19 11:53:55 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA13246 for ipp-outgoing; Mon, 19 May 1997 11:51:59 -0400 (EDT) Message-Id: <199705191552.AA09753@interlock2.lexmark.com> To: "ipp%pwg.org" From: Don Wright Date: 19 May 97 11:42:01 EDT Subject: IPP> PWG May Meeting Minutes Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I have uploaded the meeting minutes for the May PWG IPP project meeting held in San Diego. The minutes are available as both a PDF file and a TXT file. They are located at: ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-0597.txt ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-0597.pdf Additionally, the text version is attached below. Don +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ PWG Internet Printing Project Meeting Minutes May 15, 1997 San Diego, CA The meeting started on May 15, 1997 at 8:45 AM led by Carl-Uno Manros. The attendees were: * Ron Bergman - Data Products * Lee Farrell - Canon * Don Wright - Lexmark * Scott Isaacson - Novell * Jeff Copeland - QMS * Bob Pentecost - HP * Sylvan Butler - HP * Tom Hastings - Xerox * Harry Lewis - IBM * William Wagner - Digital Products * Robert Herriot - Sun * Carl-Uno Manros - Xerox * Keith Carter - IBM * Stuart Rowley - Kyocera * Peter Zehler - Xerox * Steve Zilles - Adobe * Randy Turner - Sharp * Paul Moore - Microsoft * J.K. Martin - Underscore * Larry Masinter - Xerox * Tony Liao - Vivid Image * Stephen Holmstead * Takami Kurono - Brother * Jerry Hadsell - IBM * Rick Yardumian - Xerox * Xavier Riley - Xerox * Zhi-hony Huang - Zenographics * Gary Roberts - Ricoh * Richard Schneider - Epson * Robert Kline - TrueSpectra * Patrick Powell - SDSU * David Kellerman - Northlake Software * Dave Kuntz - HP * David Manchala - Xerox Planned Agenda Morning: * Report of outcome from PWG MOD meeting May 14 (Scott Isaacson) * Presentation on SWP - Paul Moore, Sylvan Butler * CPAP Presentation - JK Martin * HTTP/NG - Larry Masinter * IPP Discussion - Bob Herriot, Randy Turner Afternoon: * Discussion about Prototyping efforts supporting the IPP protocol choices - Peter Zehler * Discussion of IPP Security - Carl-Uno Manros Model Meeting Report (Details will be published in model meeting minutes) * Discussed whether model was meeting the goals and the requirements as outlined in the Requirements I-D. * Discussed the job template attributes * Discussed what does "best efforts" mean - new values: "shall" and "should" * New draft to the IETF will take a little while due to re-formatting, etc. Probably would be 2 weeks before the next the draft. Presentation by Paul Moore on SWP (Simple Web Printing) (Charts and document are available on the PWG Web site.) - Work has been underway for some time - Enhanced and changed based upon feedback from IETF, etc - It mandates * Print submission protocol - Command sequence - data format - encoding - return values * HTTP 1.1 * Security - It suggests * Client configuration * Return URL * Access Control - It excludes * job monitoring and control protocol * printer discovery and client configuration * print by reference ** Discussion on if HTTP is correct ** Discussion on use of Unicode versus a charset value for the text in the headers ** Discussion on using HTTP chunking to determine the length of a job ** Should SWP send big-endian or little-endian? - big - Management, discovery * via HTML * no client changes * Not mandated - Implementation planned to be similar to what Babak presented in February. - Issues: 1) Enumerations versus keywords 2) Byte ordering 3) application/SWP 4) Mandate return URI - yes 5) What about unsupported attributes - ignore? 6) Adornments 7) Denial of service for anonymous users --- 8) Security 9) Is this to be an IETF standard? 10) TYPE as text versus 32-bit INT 11) Transport independent except length of print data 12) Charset - mandate unicode? 13) one post or multiple post (to get back job URI before whole job is posted) 14) What does the server do if the print job is too big? 15) Discovery of printers and their capabilities 16) Should we have SWP as well as a full-blown version to replace LPR. Should one be a subset of the other? IPP Model and Protocol Overview Steve Zilles discussed briefly the material he presented at the IETF meeting in Memphis. CPAP - JK Martin No presentation -- time was used for discussions. ** Wide ranging discussion on: - what are we trying to do? - what is wrong with LPD? - are we trying to do everything through HTTP? - is asynchronous notification a requirement? - job submission versus status queries? - is something like CPAP needed for Intranet solutions? - how is policy reflected back to the client? - should the protocol be self-describing? - how are the MIBs (printer and job monitoring) related to IPP? HTTP New Generation - Larry Masinter - HTTP-NG is a promise, not yet real - An effort to "fix" HTTP - HTTP mission creep (too many projects hopping on the HTTP band-wagon) - Need something to address the inefficiencies of HTTP - More information from www.w3.org or ftp.parc.xerox.com/pub/masin ter/http-ng.html Lunch Break Protocol Discussion - Bob Herriot 1) Encoding SWP HTTP-like application/IPP CPAP form-based - attributes * Herriot proposal for application/IPP - document data * swp (content length implicit) * explicit doc #, chunk # - operations - responses (attributes and status) 2) 1 job operation or 2 A long discussion again was held on the issue of HTTP and the concept of using something like SWP versus form-based upload. The SWP proposal does not require the use of the browser in any way to perform the actual printing. The browser simply insures that the remote printer/server is accessible via HTTP and through firewalls, etc. that might be present. The group in attendance voted to recommend to the entire working group that the first proposal should be based on HTTP/1.1 versus a newly created UDP or TCP/IP protocol. The results were 6 to 16 in favor of HTTP (Paul Moore of Microsoft voted twice.) Resumed discussion on encoding. A discussion was held on how to encode data. Embedded white space versus including a length value was discussed. Using embedded white space was perceived as being more difficult and time consuming that length. This results in an encoding of the attributes that looks like: Length | Attribute-Name | Length | Attribute-Value [00 08] JOB-NAME [00 0C] MSWORD-NOTES First byte: Major Version (starts at 1) Second byte: Minor Version (starts at 0) Content Length includes all the attributes and not the length itself. The minimum value is 0 which means no attributes. Discussion on how to do multiple documents within a job - multiple chunking - meta-job - doing the simple case and adding it via versioning - multiple content-types: application/ipp - using an attribute ("document count") to indicate multiple documents ** resolution: using "send-job" with single document count for the single document per job and use "create-job" with multiple document count to associate multiple documents Operation is an attribute and is the first attribute in the list. Operations: - create-job (create a job, data to follow, URI returned) - send-data (data (attributes & pdl) for a previously sent create-job) - print-job (attributes and print data all in one, URI returned) - cancel - get-jobs - get attributes - validate (attributes but no PDL, no URI returned) What is the minimum implementation? Is an IPP implementation in a printer required to support multiple documents within a job? A printer could reject a create-job operation and force the client to use multiple print-job operations instead. Resolution: Paul Moore will be writing a proposal for a level 1 conformance (encoding, operations and the transport) which will be a new version of the SWP document within the next couple of weeks. This draft will be made available to the group for review before publishing it as an IETF draft. It will be viewed and discussed at one of the conference calls. Security Carl-Uno Manros presented the security sub-group's work-in-progress and status. His charts will be available on the WEB/ftp server. The combination of Digest Authentication and Transport Layer Security (=SSL3) look like a good combination for our specification. If a weaker security all that is necessary then Digest would be used; TLS if a stronger security is needed. A new security negotiation "Simple Authentication and Session Layer" or SASL is gaining mind share within the IETF. Issues: - object security works only with original MIME - channel security protocols only work with a particular protocol - if a new transfer protocol is used, there might not be a security means available. Goal is to have a new internet-draft available in the next two weeks. Implementation Discussion Can a special service provider register for a particular document type so that it can be "filtered" before it is printed? - yes, in the SWP case, via an ISAPI extension, etc. Documents Work done by the protocol group will be reflected back into the model document (new operations, conformance.) A directory document should be published in the next few weeks by Keith Carter. Next meeting - June 25/26 in Nashua, NH. The meeting adjourned at 6:10PM. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ************************************************************* * 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 Tue May 20 01:34:04 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA16677 for ipp-outgoing; Tue, 20 May 1997 01:31:06 -0400 (EDT) Message-ID: <3381372A.579@parc.xerox.com> Date: Mon, 19 May 1997 22:31:22 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: Don Wright CC: "ipp%pwg.org" Subject: Re: IPP> PWG May Meeting Minutes References: <199705191552.AA09753@interlock2.lexmark.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO http://www.parc.xerox.com/http-ng is a better reference for current information on HTTP-NG. Larry From ipp-archive Tue May 20 01:49:04 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA17155 for ipp-outgoing; Tue, 20 May 1997 01:48:43 -0400 (EDT) Message-Id: <1.5.4.32.19970520054514.006735f4@pop3.holonet.net> X-Sender: cumanros@pop3.holonet.net X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 19 May 1997 22:45:14 -0700 To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> DSEC - Presentation from San Diego Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I have now uploaded the slides from lat week's meeting in San Diego. They are called: Security-SD.PDF and .ppt and can be found in the new_SEC folder. Carl-Uno From ipp-archive Tue May 20 01:54:16 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA17342 for ipp-outgoing; Tue, 20 May 1997 01:53:43 -0400 (EDT) Message-Id: <1.5.4.32.19970520055022.0067c30c@pop3.holonet.net> X-Sender: cumanros@pop3.holonet.net X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 19 May 1997 22:50:22 -0700 To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Agenda for PWG IPP Phone Conference May 21 Sender: ipp-owner@pwg.org Precedence: bulk Status: RO ADM - Agenda for PWG IPP Phone Conference May 21 1) Discuss the outcome and agreements from San Diego. There are some things that I am missing from the minutes, which need to be clarified before we put things out for a consensus check 2) Tom Hastings has suggested that we spend some time discussing harmonization between IPP and Job Monitoring Regards, Carl-Uno From ipp-archive Tue May 20 04:44:07 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA18326 for ipp-outgoing; Tue, 20 May 1997 04:40:13 -0400 (EDT) Message-Id: <9705200840.AA08588@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, 20 May 1997 01:38:00 PDT To: ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: IPP> Resolving IPP/JMP job-state and job-state-reasons differences: for Wed 5/21 IPP telecon, 1-3pm PDT (4-6pm EDT) Sender: ipp-owner@pwg.org Precedence: bulk Status: RO For the IPP telecon, Wed, 5/21, 1-3 pm PDT (4-6 pm EDT). The Job Monitoring MIB project is nearling completion and we wanted to make sure that the JMP model of a print job covered IPP. In other words, an SNMP agent will have to map the IPP semantics onto the JMP representation of a job. The JMP wanted to meet with the IPP folks to resolve these differences. Since JMP will be monitoring output devices and servers that implement different protocols, JMP may need to be a superset of IPP, not one-to-one. However, an SNMP agent must be able to map the semantics of an IPP server or printer into the JMP semantics. I've posted a detailed comparison of the IPP job-state and job-state-reasons attributes with the JMP jmJobState object and the jobStateReasons1 attribute in both sub-directories: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 52224 May 20 08:25 ippstate.doc -rw-r--r-- 1 pwg pwg 50264 May 20 08:26 ippstate.pdf -rw-r--r-- 1 pwg pwg 34760 May 20 08:26 ippstate.txt The document lists the differencs, and lists alternatives for resolving the differences. Then it lists the entire IPP or JMP specification for these attributes, as modified last week by both the IPP and JMP projects. Take a look. Thanks, Tom From ipp-archive Tue May 20 10:09:08 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA19376 for ipp-outgoing; Tue, 20 May 1997 10:08:26 -0400 (EDT) Message-Id: <3.0.1.32.19970520070337.01022d98@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 20 May 1997 07:03:37 PDT To: Richard Shockey , Larry Masinter From: Carl-Uno Manros Subject: IPP> Re: two reasons not to use vcard for fax recipient capabilities Cc: ietf-fax@imc.org, ipp@pwg.org In-Reply-To: <3.0.1.32.19970519205023.00716c4c@popd.ix.netcom.com> References: <3380F3F2.3CE4@parc.xerox.com> <3.0.1.32.19970513093132.006e1750@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO At 06:50 PM 5/19/97 PDT, Richard Shockey wrote: >It just struck me ... what are the IPP folks doing about exchange of >capablilities of "Internet Printers"? They must be establishing a session. >Anyone know what they are doing? > In IPP you can get the capabilities of a printer before trying to send something to it. We are also considering a Validate operation in which you send the attributes of an intended print job to the printer, but without any print data, to check whether the combination of attributes would be acceptable in a real print job. We intend to use HTTP 1.1 as transfer protocol (warts and all). Your suspicions that IPP might become a better Internet fax protocol than Internet Fax might indeed come true :-) Carl-Uno Manros IETF IPP WG 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 May 20 11:59:09 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA20298 for ipp-outgoing; Tue, 20 May 1997 11:56:19 -0400 (EDT) From: Keith Carter To: Subject: IPP> SEC: DIR: Security attribute(s) required in Directory Schema Message-Id: <5040300001627180000002L002*@MHS> Date: Tue, 20 May 1997 11:57:56 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Security group, What attribute(s) are required for security in the Directory Schema? Currently, I have a request to add an attribute that indicates if a Printer has/does not have security. Is that sufficient? Please advise, Keith From ipp-archive Tue May 20 13:29:12 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA20878 for ipp-outgoing; Tue, 20 May 1997 13:25:28 -0400 (EDT) Message-Id: <9705201725.AA08672@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, 20 May 1997 10:23:04 PDT To: ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: IPP> RESEND: MOD - Resolving IPP/JMP job-state and job-state-reasons differences: for Wed 5/21 IPP telecon, 1-3pm PDT (4-6pm EDT) Sender: ipp-owner@pwg.org Precedence: bulk Status: RO For the IPP telecon, Wed, 5/21, 1-3pm PDT (4-6 EDT). As stated in my mail yesterday, the JMP meeting assigned me the action item to put the harmonization of IPP and JMP job-state and job-state-reasons on the IPP agenda. I've replaced the 3 files with some added material: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 61952 May 20 17:04 ippstate.doc -rw-r--r-- 1 pwg pwg 70651 May 20 17:04 ippstate.pdf -rw-r--r-- 1 pwg pwg 40971 May 20 17:04 ippstate.txt and updated the date to 5/20/97. I copied in the job state transition table from the Job Monitoring MIB appendix, since an IPP issue suggests that we need such a table. Also I copied in the table that shows which job states, each job-state-reason can be used with from the Job Monitoring MIB. IPP should have such a table as well. Sorry for the repost. Thanks, Tom P.S. We are not sure of the phone number for tommorrow's IPP call, since the attached mail was only for the previous 3 calls: >Return-Path: >To: "ipp%pwg.org" >From: Don Wright >Date: Tue, 22 Apr 1997 12:13:56 PDT >Subject: IPP> ADM> Conference Call Schedule >Sender: ipp-owner@pwg.org > >I have reserved lines for the usual Wednesday conference >calls for April 23, April 30 and May 7. All the details >are the same as always but just for anyone new: > >Dial-in Number: 1-423-673-6712 >Access code: 190148 >Date: 4/23, 4/30 and 5/7 >Time: 4PM Eastern, 1PM Pacific >Duration: 2.5 hours >Participants: 20 Max > >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 * >************************************************************* >Return-Path: >X-Sender: hastings@zazen (Unverified) >Date: Tue, 20 May 1997 01:38:00 PDT >To: ipp@pwg.org, jmp@pwg.org >From: Tom Hastings >Subject: IPP> Resolving IPP/JMP job-state and job-state-reasons differences: > for Wed 5/21 IPP telecon, 1-3pm PDT (4-6pm EDT) >Sender: ipp-owner@pwg.org > >For the IPP telecon, Wed, 5/21, 1-3 pm PDT (4-6 pm EDT). > >The Job Monitoring MIB project is nearling completion and we wanted to make >sure that the JMP model of a print job covered IPP. In other words, an SNMP >agent will have to map the IPP semantics onto the JMP representation of a >job. The JMP wanted to meet with the IPP folks to resolve these differences. >Since JMP will be monitoring output devices and servers that implement >different protocols, JMP may need to be a superset of IPP, not one-to-one. >However, >an SNMP agent must be able to map the semantics of an IPP server or printer >into the JMP semantics. > >I've posted a detailed comparison of the IPP job-state and job-state-reasons >attributes with the JMP jmJobState object and the jobStateReasons1 attribute >in both sub-directories: > >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ >ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ >-rw-r--r-- 1 pwg pwg 52224 May 20 08:25 ippstate.doc >-rw-r--r-- 1 pwg pwg 50264 May 20 08:26 ippstate.pdf >-rw-r--r-- 1 pwg pwg 34760 May 20 08:26 ippstate.txt > >The document lists the differencs, and lists alternatives for resolving the >differences. Then it lists the entire IPP or JMP specification for these >attributes, as modified last week by both the IPP and JMP projects. > >Take a look. > >Thanks, >Tom > > > From ipp-archive Tue May 20 14:04:11 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA21791 for ipp-outgoing; Tue, 20 May 1997 14:01:01 -0400 (EDT) Message-Id: <3.0.1.32.19970520105617.00ea78f0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 20 May 1997 10:56:17 PDT To: Keith Carter , From: Carl-Uno Manros Subject: IPP> SEC: DIR: Re. Security attribute(s) required in Directory Schema In-Reply-To: <5040300001627180000002L002*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO At 08:57 AM 5/20/97 PDT, Keith Carter wrote: >Security group, > >What attribute(s) are required for security in the Directory Schema? >Currently, I have a request to add an attribute that indicates if a Printer >has/does not have security. Is that sufficient? > >Please advise, > >Keith > Keith, we have not yet worked out all the details, but a binary value will certainly not cut it. I foresee the need for a multi-valued attribute that lists the supported security protocols (if any) for a particular Printer and we will probably need to allocate some of these values, unless some other group in the IETF has already done that work for us. Secondly, certain security protocols, such as TLS, actually requires that the session between the client and the server is initiated over the security protocol, rather than over IPP/HTTP, which means that you need a separate URL for that Printer which starts off: https://www...... For such cases, we need to decide whether we need to make two separate directory entries considering that the Printer may now have a "secure URL" and a "normal URL" if it supports both types, or if the "secure URL" is just an extra directory attribute in the entry for the "normal URL" version. However, some printers may only accept secure communication, in which case there is no valid "normal URL". Confused enough? We will need to do some more work on this in the SEC subgroup. Suggestions from the DIR subgroup or anybody else are obviously welcome. 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 May 20 14:39:12 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA22287 for ipp-outgoing; Tue, 20 May 1997 14:37:52 -0400 (EDT) Message-Id: <3.0.1.32.19970520113317.0102e968@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 20 May 1997 11:33:17 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC - yet another security protocol Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO >Mime-Version: 1.0 >To: IETF-Announce@ietf.org >Sender:ietf-announce-request@ietf.org >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-petke-remote-pass-auth-00.txt >Date: Tue, 20 May 1997 09:47:39 -0400 >X-Orig-Sender: cclark@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Remote Passphrase Authentication > Author(s) : G. Brown > Filename : draft-petke-remote-pass-auth-00.txt > Pages : 40 > Date : 05/19/1997 > >Remote Passphrase Authentication provides a way to authenticate a user to a >service by using a pass phrase over an insecure network, without revealing >the pass phrase to eavesdroppers. In addition, the service need not know >and does not learn the user's pass phrase, making this scheme useful in >distributed environments where it would be difficult or inappropriate to >trust a service with a pass phrase database or to allow the server to learn >enough to masquerade as the user in a future authentication attempt. > >This scheme was inspired by Dave Raggett's Mediated Digest Authentication, >draft-ietf-http-mda-00.txt. > >This specification is divided into five parts. Part Zero contains an >extended introduction to the problem and potential solutions. Part One >explains the mechanism. Part Two explains how to incorporate the mechanism >into HTTP. Part Three explains the protocol between the service and deity. >Part Four explains the GSS-API token formats. Feel free to start with Part >One; Part Zero provides background information and is not a prerequisite >for Part One. > >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-petke-remote-pass-auth-00.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-petke-remote-pass-auth-00.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-petke-remote-pass-auth-00.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. > 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 May 20 15:04:13 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA22991 for ipp-outgoing; Tue, 20 May 1997 15:01:09 -0400 (EDT) Date: Tue, 20 May 1997 12:01:49 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705201901.MAA00044@woden.eng.sun.com> To: ipp@pwg.org, jmp@pwg.org, hastings@cp10.es.xerox.com Subject: Re: IPP> Resolving IPP/JMP job-state and job-state-reasons differences: Sender: ipp-owner@pwg.org Precedence: bulk X-Sun-Charset: US-ASCII Status: RO Good analysis Tom. The following is my opinion on what should change to align IPP and JobMIB. I think that IPP and the JobMIB each offer some good ideas. I would like to keep the job states very simple and make sure that they go in a simple progression with detours handled by job-state-reasons. We mostly did that in IPP, but the JobMIB did a better job at the end of the job. I suggest that the IPP (and JobMIB) state progression be: ---> completed pending -> processing - | ---> canceled Even though canceled could be handled by a job-state-reason under completed, I think that it is an important reminder that the job didn't complete for some reason, hopefully explained in the job-state-reasons. This means that there are the following job-state-reasons: o job-held during the pending state o printer-stopped during the pending or processing state o job-retained during the completed or canceled state. It also means that the follow IPP states go away: o terminating becomes canceled which has a longer duration o retained becomes a job-state-reasons job-retained I would prefer that both IPP and the JobMIB adopt these states. It requires changes for both, but I think it is a better solution than either currently offers. Bob Herriot From ipp-archive Tue May 20 15:14:14 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA23605 for ipp-outgoing; Tue, 20 May 1997 15:09:18 -0400 (EDT) Message-Id: <199705201909.AA19920@interlock2.lexmark.com> To: "ipp%pwg.org" From: Don Wright Date: 20 May 97 14:03:07 EDT Subject: IPP> Conference Calls Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Here's the info on the next three conference calls: May 21 ------ Call-in: 1-423-673-6712 Access: 190148 May 28 ------ Call-in: 1-309-671-1035 Access: 190148 June 4 ------ Call-in: 1-423-673-6712 Access: 190148 All calls are at 4PM EDT (1PM PDT) 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 Tue May 20 15:39:13 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA24111 for ipp-outgoing; Tue, 20 May 1997 15:38:54 -0400 (EDT) Date: Tue, 20 May 1997 12:37:21 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705201937.MAA00431@woden.eng.sun.com> To: paulmo@microsoft.com, hastings@cp10.es.xerox.com Subject: IPP> Re: Unsigned integer count for attribute name keywords and attribute values Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > From hastings@cp10.es.xerox.com Tue May 20 11:48:48 1997 > > Paul, > > Bob and I were talking about the two-octet binary integer count that > we agreed to for IPP encoding. The following details need to be > carefully specified in the IPP encoding document, in order to get proper > interoperability: > > 1. The maximum value for attribute name keywords is 255 octets, since > attribute name keywords are US ASCII. The minimum is 1. > From the Model document, page 43. Did we agree to one or two bytes for the length of attribute names? I thought two, just in case we ever use Unicode rather than UTF-8 to encode attribute names. We wouldn't want the attributes to then be limited to 127 characters. > > 2. The maximum value for attribute values is 4095 characters times the > worst case explosion factor for UTF-8, which is 3 or 4. In any case, > the high order sign bit shall be 0. The maximum length of a 2 byte Unicode character is 3 bytes in UTF-8, A 4 byte "Unicode" character can be as much as 6 bytes. There are currently no such characters, as far as I know. I don't understand why we should make that statement that the high order sign bit needs to be 0. I would expect that it is a 16 bit unsigned integer. In fact, I would expect that all of the lengths are unsigned integers, be they 2 bytes or 4 bytes, but we need to make that clear. > > 3. The two-octet integer is not padded, so RISC machines that require > integers to be aligned on 2, 4, or 8 byte boundaries, must pick up the > two-octets whereever they are. We don't want some clients padding the > data to meet their server's alignment requirements and then such servers > not being able to accept unaligned data from other clients. We should > probably outlaw the ASCII NUL (decimal 0) in attribute names and values > as well, just to make sure. The current Model document lists the > abstract characters that are allowed in keywords, but the encoding document > could specify that ASCII NUL could be introduced. I think we need to > specifically outlaw ASCII NUL in the encoding document. Padding is a host issue and not a protocol issue. Since our protocol is based on precise locations of bytes in the stream, the protocol definition implies that there can be no padding. Because each name and value is specified by a length, it shouldn't matter if an ASCII NUL is present. In fact, I would NOT want to have two rules for termination of a name, such as length or NULL, whichever comes first. This gets us back into the HTTP question of Content-length versus boundary-string and which one wins. If a name or value contains a NUL, then it must be part of the name or value. This rule is especially important if we later allow other encodings such as Unicode which has numerous NUL bytes, e.g. in every ASCII character. > > 4. The first of the two octets is the most significant, as in all > protocols. So-called Big Endian. > > Ok? > > Thanks, > Tom > > From ipp-archive Tue May 20 16:09:13 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA24587 for ipp-outgoing; Tue, 20 May 1997 16:07:34 -0400 (EDT) Message-Id: <3.0.1.32.19970520130248.0102c908@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 20 May 1997 13:02:48 PDT To: Frank_Dawson/CAM/Lotus@lotus.com, cweider@microsoft.com From: Carl-Uno Manros Subject: IPP> Re: First draft of Schema Registry charter Cc: ietf-schema-reg@imc.org, ipp@pwg.org In-Reply-To: <8525649D.0068E21A.00@mta2.lotus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO At 12:10 PM 5/20/97 PDT, Frank_Dawson/CAM/Lotus@lotus.com wrote: > >Folks: > >I am not particularly happy about the number of schemas we have for >directories either. It would be very much simplier if everyone would just >use mine ;-) > Folks, in the IPP project, we are trying to create one directory schema protocol that contains recommended attributes for finding and selecting printers and print servers. We would be very happy if there was ONE recommendation on how to write a directory protocol independent schema. I made this suggestion back in Memphis and I am repeating it again here. Even if we historically have x different ways of describing schemas right now, wouldn't it make sense to define a form to be used for new specifications? Isn't that a good task for this group? Think about how much easier schema registration would be down the line! Carl-Uno Manros Co-chair IPP WG Any suggestion 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 May 20 19:44:16 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA25399 for ipp-outgoing; Tue, 20 May 1997 19:42:09 -0400 (EDT) Date: Tue, 20 May 1997 16:44:05 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705202344.QAA02587@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO future face-to-face meeting X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Randy and I talked about having a face-to-face meeting in June before the Boston meeting in order to work out details of the protocol. We believe that we need to wrap up most loose ends by the June meeting in Boston. The location would likely be in the San Francisco Bay area, possibly at Sun, and the likely meeting dates would be Tuesday June 10 or Wednesday June 11. If you are interested in attending such a meeting, please let me know whether such dates would work for you and indicate your preference for June 10 or 11. Bob Herriot From ipp-archive Wed May 21 01:34:18 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA26679 for ipp-outgoing; Wed, 21 May 1997 01:33:21 -0400 (EDT) Message-Id: <9705210533.AA08891@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, 20 May 1997 22:30:59 PDT To: Robert.Herriot@eng.sun.com (Robert Herriot) From: Tom Hastings Subject: Re: IPP> Re: Unsigned integer count for attribute name keywords and attribute values Cc: paulmo@microsoft.com, ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk Status: RO At 12:37 05/20/97 PDT, Robert Herriot wrote: > >> From hastings@cp10.es.xerox.com Tue May 20 11:48:48 1997 >> Snip... >> 3. The two-octet integer is not padded, so RISC machines that require >> integers to be aligned on 2, 4, or 8 byte boundaries, must pick up the >> two-octets whereever they are. We don't want some clients padding the >> data to meet their server's alignment requirements and then such servers >> not being able to accept unaligned data from other clients. We should >> probably outlaw the ASCII NUL (decimal 0) in attribute names and values >> as well, just to make sure. The current Model document lists the >> abstract characters that are allowed in keywords, but the encoding document >> could specify that ASCII NUL could be introduced. I think we need to >> specifically outlaw ASCII NUL in the encoding document. > >Padding is a host issue and not a protocol issue. Since our protocol is >based on precise locations of bytes in the stream, the protocol >definition implies that there can be no padding. Because each name and >value is specified by a length, it shouldn't matter if an ASCII NUL is >present. In fact, I would NOT want to have two rules for termination >of a name, such as length or NULL, whichever comes first. This gets us >back into the HTTP question of Content-length versus boundary-string >and which one wins. If a name or value contains a NUL, then it must be >part of the name or value. This rule is especially important if we >later allow other encodings such as Unicode which has numerous NUL >bytes, e.g. in every ASCII character. I agree we don't want two rules and I wasn't suggesting such. If NUL is included in character coded data, it would contribute to the count like any other character. If NUL is included in character coded data, it would not terminate the string. In UTF-8, as opposed to Unicode (which is two-octets for every characters), there are no all-zero octets, except for the Unicode NUL character. All other characters have all non-zero octets. That is one of the reasons for UTF-8: to allow the C NUL terminated string to be processed by all existing software. But for our application we don't want NUL terminated strings, since we have a count instead. To be more clear, we should outlaw ASCII NUL character in ASCII coded strings and outlaw the UTF-8 NUL *character* in UTF-8 strings. Otherwise, some client may be putting in such padding (within the count) in order to align the two-octet attribute name or attribute value that follow, so that the particular server that the client was built with could pick up the integers as (aligned) integers, because they were aligned in memory as the data was unmarshalled into memory, rather than picking up the two-octet integers as individual octets. Another reason to outlaw these NUL characters, is to prevent servers from having to filter them out before doing string compares. If one client starts to embed NULs and some servers filter them out, then we get interoperability problems with the servers that don't. In short, this is a small problem with a simple fix: Just add a sentence that forbids the counted ASCII and UTF-8 strings to contain the NUL character when representing attribute names and attribute values in IPP. Tom From ipp-archive Wed May 21 02:14:19 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA27220 for ipp-outgoing; Wed, 21 May 1997 02:13:39 -0400 (EDT) Message-Id: <9705210613.AA08928@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, 20 May 1997 23:11:18 PDT To: ipp@pwg.org From: Tom Hastings Subject: Re: IPP> Resolving IPP/JMP job-state and job-state-reasons differences: Cc: Robert.Herriot@eng.sun.com (Robert Herriot), jmp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I agree with Bob's suggestions for both IPP and the Job Monitoring MIB for simplifying the job-state and using job-state-reasons to indicate information about the state. I have a refinement concerning the job-held reason. If a job has no reasons that jobs are held in the pending state, then the job-held reason need not be implemented at all. If an implementation has only one reason that jobs are held while in the pending state, then that implemenation shall implement and return at least the job-held reason. However, if there are several reasons, then that implementation shall implement (and return) the job-held reason *in combination* with the other more specific reason(s). Then an application that doesn't understand all the reasons that jobs can be held, can at least know that the job isn't going to be scheduled if the job-held reason is present (and perhaps flag that job in some distinguishing way to its user). The additional more-specific reasons for holding a job are: IPP JMP job-incomplete becoming: job-spooling? job-sending-to-output-device job-queued-in-output-device job-hold-until-specified job-hold-until-specified required-resources-not-ready required-resource-not-ready documents-needed job-hold-set job-process-after-specified job-pre-processing job-paused job-interrupted ... I think that the IPP reasons need review, and then should be added to JMP. The JMP reasons do not need to be added to IPP though, since JMP is attempting to monitor other systems in addition to IPP. Tom At 12:01 05/20/97 PDT, Robert Herriot wrote: > >Good analysis Tom. > >The following is my opinion on what should change to align IPP and JobMIB. >I think that IPP and the JobMIB each offer some good ideas. > >I would like to keep the job states very simple and make sure that >they go in a simple progression with detours handled by job-state-reasons. >We mostly did that in IPP, but the JobMIB did a better job at the end of >the job. > >I suggest that the IPP (and JobMIB) state progression be: > > ---> completed >pending -> processing - | > ---> canceled > >Even though canceled could be handled by a job-state-reason under completed, >I think that it is an important reminder that the job didn't complete >for some reason, hopefully explained in the job-state-reasons. > >This means that there are the following job-state-reasons: > > o job-held during the pending state > o printer-stopped during the pending or processing state > o job-retained during the completed or canceled state. > >It also means that the follow IPP states go away: > > o terminating becomes canceled which has a longer duration > o retained becomes a job-state-reasons job-retained > >I would prefer that both IPP and the JobMIB adopt these states. It >requires changes for both, but I think it is a better solution than >either currently offers. > >Bob Herriot > > > > From ipp-archive Wed May 21 09:54:23 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA28327 for ipp-outgoing; Wed, 21 May 1997 09:53:02 -0400 (EDT) From: Roger K Debry To: Cc: Subject: IPP>PRO future face-to-face meeting Message-Id: <5030100002699130000003L003*@MHS> Date: Wed, 21 May 1997 09:55:08 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I would be interested in such a meeting, but would strongly suggest that we all have a straw proposal to work from. I find meeting much more productive if we have a documented proposal to work from and a specific set of issues to work on. At this point I have no preference for dates. 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 05/21/97 07:45 AM --------------------------- BLDVMA.GEBERT @ D03AU003 05/20/97 06:04 PM Please respond to BLDVMA.GEBERT @ VM To: Roger K Debry/Boulder/IBM, Roger K Debry/Boulder/IBM cc: Subject: IPP>PRO future face-to-face meeting *********************************************************** SECURITY CLASSIFICATION: I could not believe this note. Those guys must have absolutely nothing to do and absolutely no regard for other people's time if they want to schedule a meeting between already very frequent meetings. From my experience with their conf calls, they should try to find a higher degree of focus, rather than calling more meetings. I am very appreciative of the fact that you have more patience with this cooperative process. I would not be able to sit through 10 minutes of their meetings! Hopefully they will at a minimum have a conf room with a phone able to tie in other people who will only want to hear a small fraction of the uninteresting discussions and get the few useful pieces. Steve. *** Forwarding note from SMTP3 --IINUS1 05/20/97 17:47 *** ========================================================================= Received: from lists.underscore.com by vnet.IBM.COM (IBM VM SMTP V2R3) with TCP; Tue, 20 May 97 19:47:29 EDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA25541; Tue, 20 May 1997 19:46:55 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 20 May 1997 19:45:57 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA25399 for ipp-outgoing; Tue, 20 May 1997 19:42:09 -0400 (EDT) Date: Tue, 20 May 1997 16:44:05 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705202344.QAA02587@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO future face-to-face meeting X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Randy and I talked about having a face-to-face meeting in June before the Boston meeting in order to work out details of the protocol. We believe that we need to wrap up most loose ends by the June meeting in Boston. The location would likely be in the San Francisco Bay area, possibly at Sun, and the likely meeting dates would be Tuesday June 10 or Wednesday June 11. If you are interested in attending such a meeting, please let me know whether such dates would work for you and indicate your preference for June 10 or 11. Bob Herriot From ipp-archive Wed May 21 10:04:25 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA28773 for ipp-outgoing; Wed, 21 May 1997 10:02:09 -0400 (EDT) From: Roger K Debry To: Subject: IPP> SEC: DIR: Security attribute(s) required in Directory S Message-Id: <5030100002699495000002L052*@MHS> Date: Wed, 21 May 1997 10:04:18 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO This should be a topic for discussion at our security conf call this week. 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 05/21/97 07:59 AM --------------------------- ipp-owner @ pwg.org 05/20/97 10:04 AM Please respond to ipp-owner@pwg.org @ internet To: ipp @ pwg.org @ internet cc: Subject: IPP> SEC: DIR: Security attribute(s) required in Directory S Security group, What attribute(s) are required for security in the Directory Schema? Currently, I have a request to add an attribute that indicates if a Printer has/does not have security. Is that sufficient? Please advise, Keith From ipp-archive Wed May 21 10:14:25 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA29244 for ipp-outgoing; Wed, 21 May 1997 10:09:48 -0400 (EDT) Message-Id: <9705211409.AB09004@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, 21 May 1997 07:07:24 PDT To: ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: Resend: IPP> Resolving IPP/JMP job-state and job-state-reasons differences Cc: Robert.Herriot@eng.sun.com (Robert Herriot) Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I wasn't very clear in my previous reply to Bob (attached) about why there is a need for the generic job-held reason to indicate that the job isn't a candidate for scheduling. We only need the job-held reason, IFF there are any reasons in the pending state that are not holding up the job. In IPP, the reasons: job-sending-to-output-device and job-queued-in-output-device are reasons that the job is in the pending state, but is not being held up. So an application program that is flagging jobs to its user that are not candidates for processing (i.e., are being held), would NOT want to flag a job that was being sent to the output device or was already queued in the output device. Since IPP has a need for the generic job-held reason, so does JMP. Tom At 23:11 05/20/97 PDT, Tom Hastings wrote: >I agree with Bob's suggestions for both IPP and the Job Monitoring MIB >for simplifying the job-state and using job-state-reasons to indicate >information about the state. > >I have a refinement concerning the job-held reason. > >If a job has no reasons that jobs are held in the pending state, then >the job-held reason need not be implemented at all. > >If an implementation has only one reason that jobs are held while in the >pending state, then that implemenation shall implement and return at least >the job-held reason. However, if there are several reasons, then that >implementation shall implement (and return) the job-held reason >*in combination* with the other more specific reason(s). Then an application >that doesn't understand all the reasons that jobs can be held, can at least >know that the job isn't going to be scheduled if the job-held reason is >present (and perhaps flag that job in some distinguishing way to its user). > >The additional more-specific reasons for holding a job are: > > IPP JMP >job-incomplete becoming: job-spooling? >job-sending-to-output-device >job-queued-in-output-device >job-hold-until-specified job-hold-until-specified >required-resources-not-ready required-resource-not-ready > documents-needed > job-hold-set > job-process-after-specified > job-pre-processing > job-paused > job-interrupted > ... > >I think that the IPP reasons need review, and then should be added to JMP. >The JMP reasons do not need to be added to IPP though, since JMP is attempting >to monitor other systems in addition to IPP. > >Tom > > >At 12:01 05/20/97 PDT, Robert Herriot wrote: >> >>Good analysis Tom. >> >>The following is my opinion on what should change to align IPP and JobMIB. >>I think that IPP and the JobMIB each offer some good ideas. >> >>I would like to keep the job states very simple and make sure that >>they go in a simple progression with detours handled by job-state-reasons. >>We mostly did that in IPP, but the JobMIB did a better job at the end of >>the job. >> >>I suggest that the IPP (and JobMIB) state progression be: >> >> ---> completed >>pending -> processing - | >> ---> canceled >> >>Even though canceled could be handled by a job-state-reason under completed, >>I think that it is an important reminder that the job didn't complete >>for some reason, hopefully explained in the job-state-reasons. >> >>This means that there are the following job-state-reasons: >> >> o job-held during the pending state >> o printer-stopped during the pending or processing state >> o job-retained during the completed or canceled state. >> >>It also means that the follow IPP states go away: >> >> o terminating becomes canceled which has a longer duration >> o retained becomes a job-state-reasons job-retained >> >>I would prefer that both IPP and the JobMIB adopt these states. It >>requires changes for both, but I think it is a better solution than >>either currently offers. >> >>Bob Herriot >> >> >> >> > > > From ipp-archive Wed May 21 10:34:25 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA29887 for ipp-outgoing; Wed, 21 May 1997 10:31:53 -0400 (EDT) Message-Id: <9705211431.AA09037@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, 21 May 1997 07:29:32 PDT To: ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: IPP> MOD - simplified legal state transition diagram Sender: ipp-owner@pwg.org Precedence: bulk Status: RO So the simplified legal state transition diagram for IPP and JMP would become, following Bob's proposal: New state Old state unknown(2) pending(3) processing(4) canceled(5) completed(6) unknown(2) yes yes pending(3) yes yes processing(4) yes yes yes canceled(5) yes completed(6) yes A blank entry indicates impossible transitions. Self loops are not indicated, such as a Get-Attributes operation on a job, since they aren't a job state transition. For IPP we need to consider which job states and job state transtions are required for conformance and which are optional. JMP requires that processing(4), canceled(5), and completed(6) are mandatory, so that pending(3) is optional. What about unknown(2)? The former needsAttention state was also mandatory, so that the new job-state reason: printer-stopped, should become a mandator job state reason, correct? For IPP and JMP, all transitions into the canceled state should be required. However, the transition from processing back to pending (a job-held situation) is optional. From ipp-archive Wed May 21 10:39:29 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA00251 for ipp-outgoing; Wed, 21 May 1997 10:37:57 -0400 (EDT) Message-Id: <9705211437.AA09046@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, 21 May 1997 07:35:44 PDT To: Roger K Debry From: Tom Hastings Subject: Re: IPP>PRO future face-to-face meeting Cc: , Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I strongly agree with Roger on having a straw proposal to work from. Bob and Randy, Can you two produce such a straw proposal with issues listed? Thanks, Tom At 06:55 05/21/97 PDT, Roger K Debry wrote: >I would be interested in such a meeting, but would strongly >suggest that we all have a straw proposal to work from. I >find meeting much more productive if we have a documented >proposal to work from and a specific set of issues to work on. > >At this point I have no preference for dates. > >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 05/21/97 07:45 >AM --------------------------- > > BLDVMA.GEBERT @ D03AU003 > 05/20/97 06:04 PM >Please respond to BLDVMA.GEBERT @ VM > > >To: Roger K Debry/Boulder/IBM, Roger K Debry/Boulder/IBM >cc: >Subject: IPP>PRO future face-to-face meeting > >*********************************************************** >SECURITY CLASSIFICATION: > I could not believe this note. Those guys must have absolutely > nothing to do and absolutely no regard for other people's time > if they want to schedule a meeting between already very frequent > meetings. From my experience with their conf calls, they should > try to find a higher degree of focus, rather than calling more > meetings. I am very appreciative of the fact that you have > more patience with this cooperative process. I would not be > able to sit through 10 minutes of their meetings! > > Hopefully they will at a minimum have a conf room with a phone > able to tie in other people who will only want to hear a small > fraction of the uninteresting discussions and get the few > useful pieces. Steve. > >*** Forwarding note from SMTP3 --IINUS1 05/20/97 17:47 *** >========================================================================= >Received: from lists.underscore.com by vnet.IBM.COM (IBM VM SMTP V2R3) with >TCP; > Tue, 20 May 97 19:47:29 EDT >Received: from localhost (daemon@localhost) by lists.underscore.com >(8.7.5/8.7.3) with SMTP id TAA25541; Tue, 20 May 1997 19:46:55 -0400 (EDT) >Received: by pwg.org (bulk_mailer v1.5); Tue, 20 May 1997 19:45:57 -0400 >Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id >TAA25399 for ipp-outgoing; Tue, 20 May 1997 19:42:09 -0400 (EDT) >Date: Tue, 20 May 1997 16:44:05 -0700 >From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) >Message-Id: <199705202344.QAA02587@woden.eng.sun.com> >To: ipp@pwg.org >Subject: IPP>PRO future face-to-face meeting >X-Sun-Charset: US-ASCII >Sender: ipp-owner@pwg.org > > >Randy and I talked about having a face-to-face meeting in June before the >Boston meeting in order to work out details of the protocol. We >believe that we need to wrap up most loose ends by the June meeting >in Boston. > >The location would likely be in the San Francisco Bay area, possibly >at Sun, and the likely meeting dates would be Tuesday June 10 or >Wednesday June 11. > >If you are interested in attending such a meeting, please let me >know whether such dates would work for you and indicate your preference >for June 10 or 11. > >Bob Herriot > > > > > From ipp-archive Wed May 21 12:24:24 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA01148 for ipp-outgoing; Wed, 21 May 1997 12:24:23 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 21 May 1997 10:23:21 -0600 From: Scott Isaacson To: kita@mol.minolta.co.jp, ipp@pwg.org Cc: kita@mol.minolta.oc.jp Subject: Re: IPP>DIR OID and string attribute Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Since I am one of the authors of the directory schema document, I will try to respond to your question by making some background statements: 1. There is clear direction that the IPP directory schema effort is a secondary effort to defining the printing model and protocol mapping. The IETF has specifically asked the working group not not provide a mapping of the IPP directory schema to LDAP. However, most participants feel that this needs to be done at some point in the future (either through specific product or some informational RFC). In short, there is no existing or even soon to exist mapping from the IPP directory schema document to LDAP. All references to LDAP specifics will be removed from the directory schema document. 2. There has been much disucssion about whether the schema for a directory entry representing a Printer is a subset of the IPP Printer object or just an overlapping related set of attributes. The IPP Printer object is defined in terms of a set of attributes which are identified in the Model document as "keywords". At the 5/15/97 IPP meeting, there was good discussion on how to encode model document "keywords" in to an IPP request/response over HTTP/1.1. 3. I have assumed that the intent of the directory document is to also define the schema in terms of attributes identified only with "keywords" These keywords could then be mapped to any real represention in a specific directory protocol. It looks like you have done the correct mapping from IPP directory schema attributes to LDPAString for use in the on-the-wire protocol. 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 ************************************************************ >>> Yasunari Kitagaki 05/18 10:07 PM >>> I have read the document, named ipp-dir-schema-2.0, and I would like to clarify about mapping the ipp-dir-schema to LDAP. -What are the attributes described as the string or OID? In LDAP, attribute name must be desided as the string or be mapped to OID. >From RFC1777 Appendix A, AttributeType ::= LDAPString -- text name of the attribute, or dotted -- OID representation AttributeValue ::= OCTET STRING LDAP ::= OCTET STRING If there is the documentatation, let me know its URL. ---------------------------- Yasunari Kitagaki kita@mol.minolta.co.jp Minolta Co., Ltd. From ipp-archive Wed May 21 12:41:48 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA01591 for ipp-outgoing; Wed, 21 May 1997 12:32:21 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 21 May 1997 10:32:05 -0600 From: Scott Isaacson To: hastings@cp10.es.xerox.com, Robert.Herriot@Eng.Sun.COM, paulmo@microsoft.com Cc: ipp@pwg.org Subject: IPP> Re: Unsigned integer count for attribute name keywords andattribute values Sender: ipp-owner@pwg.org Precedence: bulk Status: RO >>> Robert Herriot 05/20 1:37 PM >>> > Did we agree to one or two bytes for the length of attribute names? I > thought two, just in case we ever use Unicode rather than UTF-8 to > encode attribute names. We wouldn't want the attributes to then be > limited to 127 characters. I thought all lengths would be 2 or 4 bytes, never just 1. I thought we limited attribute names to be the same as keywords now: US ASCII characters (a-zA-Z), digits (0-9), hyphen (-) and underscore (_). We all know the consequences of not being able to internationalize these attribute names, but why are you suggesting maybe someday worrying about UTF-8 for attribute names? Scott From ipp-archive Wed May 21 13:24:25 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA02158 for ipp-outgoing; Wed, 21 May 1997 13:19:33 -0400 (EDT) Message-Id: <3.0.1.32.19970521100930.00f73108@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 21 May 1997 10:09:30 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC - PWG phone conference - May 22, 1 - 2:30 pm Cc: jwenn@cp10.es.xerox.com, manchala@cp10.es.xerox.com, xriley@cp10.es.xerox.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO PWG Phone Conference on IPP Security - May 22, 1 - 2:30 pm PST Agenda Review and comment on Roger's latest Security draft text (input to San Diego). ftp://ftp.pwg.org/pub/pwg/ipp/new_SEC/sec2.doc Discuss and propose security attributes that we need to include in the Directory Schema document. Dial-in number: 1-800-857 5607 Passcode: cmanros 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 May 21 14:09:25 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA02639 for ipp-outgoing; Wed, 21 May 1997 14:09:21 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 21 May 1997 12:09:17 -0600 From: Scott Isaacson To: Robert.Herriot@Eng.Sun.COM, ipp@pwg.org Subject: Re: IPP>PRO future face-to-face meeting Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I am interested. Scott >>> Robert Herriot 05/20 5:44 PM >>> Randy and I talked about having a face-to-face meeting in June before the Boston meeting in order to work out details of the protocol. We believe that we need to wrap up most loose ends by the June meeting in Boston. The location would likely be in the San Francisco Bay area, possibly at Sun, and the likely meeting dates would be Tuesday June 10 or Wednesday June 11. If you are interested in attending such a meeting, please let me know whether such dates would work for you and indicate your preference for June 10 or 11. Bob Herriot From ipp-archive Wed May 21 14:19:43 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA03087 for ipp-outgoing; Wed, 21 May 1997 14:18:18 -0400 (EDT) Message-ID: <41135C785691CF11B73B00805FD4D2D702B7CDB1@RED-17-MSG.dns.microsoft.com> From: Paul Moore To: "'Scott Isaacson'" , hastings@cp10.es.xerox.com, Robert.Herriot@Eng.Sun.COM Cc: ipp@pwg.org Subject: RE: IPP> Re: Unsigned integer count for attribute name keywordsan dattribute values Date: Wed, 21 May 1997 10:46:52 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.30) Sender: ipp-owner@pwg.org Precedence: bulk Status: RO The length ot the attribute name is 2 bytes. The one that I think is much more interesting - which we did not drill into - is keyword values for attributes. I still have those as 2 byte enumerations. I think this is the right thing to do and Tom agreed at the meeting but there was not a lot of discusion. Eg Operation has two values 1 (which means Validate) and 2 (meaning printjob). DocumentFormat uses the rfc1759 values etc. > -----Original Message----- > From: Scott Isaacson [SMTP:SISAACSON@novell.com] > Sent: Wednesday, May 21, 1997 9:32 AM > To: hastings@cp10.es.xerox.com; Robert.Herriot@Eng.Sun.COM; Paul > Moore > Cc: ipp@pwg.org > Subject: IPP> Re: Unsigned integer count for attribute name > keywordsandattribute values > > > > >>> Robert Herriot 05/20 1:37 PM >>> > > > Did we agree to one or two bytes for the length of attribute names? > I > > thought two, just in case we ever use Unicode rather than UTF-8 to > > encode attribute names. We wouldn't want the attributes to then be > > limited to 127 characters. > > I thought all lengths would be 2 or 4 bytes, never just 1. I thought > we > limited attribute names to be the same as keywords now: US ASCII > characters > > (a-zA-Z), digits (0-9), hyphen (-) and underscore (_). We all know > the > consequences of not being able to internationalize these attribute > names, > but why are you suggesting maybe someday worrying about UTF-8 for > attribute > names? > > Scott > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From ipp-archive Wed May 21 14:29:31 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA03566 for ipp-outgoing; Wed, 21 May 1997 14:25:39 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 21 May 1997 12:25:25 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - 5/14 mintues Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I posted the minutes from the 5/14 model meeting in San Diego. Thanks to Patrick for hosting the meeting. ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/minutes/970514-model-minutes.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/minutes/970514-model-minutes.txt The text version is below: -------------- IPP Model Meeting 5/14/97 Attendees: Keith Carter, Patrick Powell, Peter Zehler, Carl-Uno Manros, Steve Zilles, Randy Turner, Rob Klien, Bob Herriot, Scott Isaacson, Tom Hasting, Jeff Copeland, Ron Bergman, Harry Lewis Agenda 1. Review High level goals Must an IPP Printer spool? Desktop vs. Workgroup Section 3 Review SWP proposal and scope 2. Review Job Template Attributes No xxx-capable Definition of xxx-supported xxx-available 3. Review Mandatory attributes 4. Protocol Issues Look at Get Jobs Look at Create-Job and Send-Document Are all attributes required in the Create-Job Model relationship to protocol Use of MIME types 5. Extensibility Statements 6. Security 7. I18N 8 Review 9701512 version of the Model Doc 9. What does IETF require in terms of Management? Discussion 1. Reviewed the high level goals as enumerated in the Requirements Document and the Charter. Decided that the Model as is stands is at the right level to support those goals and requirements. Reaffirmed that an IPP Printer is a logical abstraction that is more than just a "print device". Text in the document should use Printer Object when there might be confusion between an IPP Printer abstraction and a print device. 2. Decided that section 3 needs to be just an introduction of the IPP model, not a comparison between some generic model that does not exist and IPP. 3. Clarified that the "originating-host" is always the host of the job submitting client. "originating-host" is not used in the case where the IPP Printer forwards the job onto some other print subsystem. 4. Reminder that the Model document still includes concepts that are not to be implemented in v1.0 of the protocol. 5. Steve Zilles reminded us that the IPP model is really a OO Database model. The Printer, Job, and Document objects are objects in the OO database. The Printer is responsible for implementing a named logical instance of the data base and for implementing an instance of an object to represent itself in the database. There are no exposed operations to create or delete or modify new instances of Printer objects in IPP v1.0, but there are operations to query the database objects (get-attributes, get-jobs). There are operations to control the life cycle of the Job object though. create new instances of Job objects (Create-Job) and Documents (Send- Document); destroy Job objects (Cancel). The protocol is just an access protocol into this OO Database. 6. We reviewed the diagrams on page 17 and 21. Theses need to be simplified and condensed into a much more readable section : specifically change Print Service => Native Print Service 7. We all seemed to agree that explicit spooling operations (get-document, resubmit, etc.) should not part of the model 8. Some suggested that RFC 758 or the Bradnor RFC are the right documents to find correct language for conformance 9. There was some disagreement about fan-in. Agreed that multiple clients fanning into the same IPP Printer is expected and allowed as part of the model. Agreed that multiple Printer Objects for a single printer output device is allowed by the model, but not called out explicitly. Fan in of that sort could be used for either multiple defaults or access control manipulation. 10. Concluded that the Model document does not need to address compatibility or coexistance with no modifications to Existing Web Browsers or not (this is a protocol issue). 11 Reminded ourselves that there are really 3 pieces to the overall IPP document suite: Abstract Model, Encoding, and Transport mapping 12. For Job template attributes, we should ignore English grammar rules for plural and singular and just use regular rules for xxx, xxx-supported, and xxx-available. Decided not to worry about xxx-capable type attributes. 13. There was much discussion on job-name: whether it should be a mandatory attribute that the client must supply in the submit request or whether it should be optional and one could be generated by the Printer if not supplied by the client. We decided to make ALL Job Template attributes optional in the submit request. That means that the Printer simply generates a name based on whatever info it has (document names, user name, submitting host name, printer name, etc.) The rules on job-name generation need to be cleaned up to not be so limiting. 14. All "name", "text", and "fileName" attributes are defined as characters in the Model document. This leaves open the option of Unicode or other DBCS in the actual protocol. 15. Reaffirmed that keywords must start with a character (no digits) 16. The model document is now too verbose and full of too much wasted space structure. The editor should compress the format of the Model document. 17. We had a 3 hour discussion on best-effort. The final proposal was to do away with any notion of "substitute" values when there is a conflict between what is requested and what is supported. The expectation is that if a client specifies something and it is not supported, return an error so that the client can query what is supported. best-effort will now apply to only conflicts between IPP attributes and what is in the document stream (PDL) itself. Proposed values are: SHALL_HONOR_IPP_ATTR (IPP attribute values take precedence over PDL instructions), SHOULD_HONOR_IPP_ATTR (same as SHALL with no guarantees), and NEED_NOT_HONOR_IPP_ATTR (PDL takes precedence over IPP attributes). 18. Clarified that defaults are not overrides. What does a user intend when the user does not specify an attribute: either 1) They want the admin default, 2) They want the PDL default. In either case, they really don't know or care, they really care if they specify the value. The idea of "default behavior" will be removed from the Model document. It is not possible to specify a consistent default behavior for features that are not implemented or for extensions that are yet to be added. 19. When a Job object is created only supplied attributes will be copied from the request into the Job object. In order to determine the defaults that will be applied, query the Printer Job Template attributes to get defaults. 20. There was a motion to include all of the Job Monitoring MIB attributes in the IPP. This motion was rejected. 21. There was a discussion about including security concepts in the Model document. There was a suggestion that there be a "job-submitter-credentials" attribute in the submit request. All security issues are still on hold awaiting more details in the security document. 22. "orig-user" is part of the security solution and is not mandatory. 23. Moved to change from "job-state-as-text" and "printer- state-as-text" to "job-state-message" and "printer-state- message", make them optional, and allow for less rigid rules about text string content. 24. Moved to make all time related attributes relative to job submission (not absolute time). That is "job-sumission- time" moves to "time-since-submitted". There was also a discussion about having "time-since-xxx" attributes for each of the Job state transitions (pending to processing, processing to completed). I did not capture the final decision on this. These are mandatory 25. Moved to make printer-locales-supported and printer- locale MANDATORY 26. Reminder that get-jobs includes a set of attributes in which the requester has interest. 27. We had a discussion on using MIME registered types as document-format values. I didn't capture a final decision on this issue. 28. Decided that all implementations shall support a single operation with data and separate create with later data operations. However, as I record these minutes, I note that this decision was reversed the next day at the general IPP meeting where "levels of conformance" where introduced. 29. Issues about Job and Document fragmentation are left as a protocol exercise. When there is resolution, the model document will be updated to reflect the decision 30 We went through is "Issue:" paragraph in the 9970512 model document. Scott will update the Model document and include new text to document the closed issues. ACTIONS ------------- 1. Clean up picture on page 17, take out output device, make an ASCII version of Steve's drawing Who: Scott and Steve 2. Fix section 3. Do not put in management functions Who: Patrick 3. Rename IPP Printer to IPP Printer Object Who: Scott 4. name (start with char, at least length 1) Who: Scott 5. Restructure the document Who: Scott 6. Fix the section on "implements" it does not read correctly as it pertains to Job attributes Who: Scott 7. Define SHALL and SHOULD get rid of NEED_NOT Who: Scott 8. Create a table of attributes Who: Tom 9. Supply text for "color" Job Template attribute "color- supported" Who: Randy 10 Fix missing and incorrect conditionally mandatory Who: Scott 11. Determine if the following Job Template attributes should be mandatory or not: job name, best-effort, copies. Who: Scott 12. job-state-reasons should be 1setOf Who: Scott 13. Add printer-locales-supported and make it and printer- locale MANDATORY Who: Scott 14. Remove scheduling-algorithm Who: 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 May 21 15:29:27 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA04130 for ipp-outgoing; Wed, 21 May 1997 15:27:38 -0400 (EDT) Date: Wed, 21 May 1997 12:26:03 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705211926.MAA12823@woden.eng.sun.com> To: hastings@cp10.es.xerox.com, Robert.Herriot@Eng.Sun.COM, paulmo@microsoft.com, SISAACSON@novell.com Subject: Re: IPP> Re: Unsigned integer count for attribute name keywords andattribute values Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > From SISAACSON@novell.com Wed May 21 09:35:27 1997 > > > > >>> Robert Herriot 05/20 1:37 PM >>> > > > Did we agree to one or two bytes for the length of attribute names? I > > thought two, just in case we ever use Unicode rather than UTF-8 to > > encode attribute names. We wouldn't want the attributes to then be > > limited to 127 characters. > > I thought all lengths would be 2 or 4 bytes, never just 1. I thought we > limited attribute names to be the same as keywords now: US ASCII characters > > (a-zA-Z), digits (0-9), hyphen (-) and underscore (_). We all know the > consequences of not being able to internationalize these attribute names, > but why are you suggesting maybe someday worrying about UTF-8 for attribute > names? I'm not suggesting we support them in version one, but I am suggesting that the protocol should not make them impossible for a future time when a foreign site might want to add an attribute for a Printer (i.e. print server) which uses a localized-name. Admittedly, we haven't dealt with the issue of how a client converts an attribute-name to a localized phrase. If we had a solution for that then we might see no need for attribute names that are not ASCII. From ipp-archive Wed May 21 15:29:42 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA04148 for ipp-outgoing; Wed, 21 May 1997 15:29:25 -0400 (EDT) From: Keith Carter To: Subject: IPP> MOD - IPP Versioning Message-Id: <5040300001660586000002L062*@MHS> Date: Wed, 21 May 1997 15:30:52 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Attached is a proposed section in the Model document for IPP versioning based on RFC 2068. I've replaced "HTTP" with "IPP", "1.1" with "1.0" and "MUST" with "shall". I retained all of the remaining text from RFC 2068 so we can determine what we want to keep or delete. Question: At the IPP working group meeting on Thursday, May 15, did we decide how to distinguish compliance level 1 (i.e. Print-Job and Validate for SWP) from compliance level 2 (i.e. all IPP operations)? Will a minor version number be used to distinguish these compliance levels (e.g. SWP = 1.0, Full = 1.1)? If so, the attached text must be modified to explain this. Enjoy, Keith ---- Start of Version Section ---- x.x IPP Version IPP uses a "." numbering scheme to indicate versions of the protocol. The protocol versioning policy is intended to allow the sender to indicate the format of a message and its capacity for understanding further IPP communication, rather than the features obtained via that communication. No change is made to the version number for the addition of message components which do not affect communication behavior or which only add to extensible field values. The number is incremented when the changes made to the protocol add features which do not change the general message parsing algorithm, but which may add to the message semantics and imply additional capabilities of the sender. The number is incremented when the format of a message within the protocol is changed. The version of an IPP message is indicated by an IPP-Version field in the first line of the message. IPP-Version = "IPP" "/" 1*DIGIT "." 1*DIGIT Note that the major and minor numbers shall be treated as separate integers and that each may be incremented higher than a single digit. Thus, IPP/2.4 is a lower version than IPP/2.13, which in turn is lower than IPP/12.3. Leading zeros shall be ignored by recipients and shall not be sent. Applications sending Request or Response messages, as defined by this specification, shall include an IPP-Version of "IPP/1.0". Use of this version number indicates that the sending application is at least conditionally compliant with this specification. The IPP version of an application is the highest IPP version for which the application is at least conditionally compliant. NOTE TO REVIEWERS: Do we want to remove the following paragraph? Note: Converting between versions of IPP may involve modification of header fields required or forbidden by the versions involved. ---- End of Version Section ---- From ipp-archive Wed May 21 15:34:27 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA04161 for ipp-outgoing; Wed, 21 May 1997 15:29:34 -0400 (EDT) From: Keith Carter To: Subject: IPP> MOD - UPDATE FOR STATUS CODE KEYWORDS IN THE MODEL DOCUMENT Message-Id: <5040300001660589000002L092*@MHS> Date: Wed, 21 May 1997 15:30:56 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Here is the update for the status code section based on the IPP telecon on 5/9 and IPP meetings on 5/14 and 5/15. The status code classes match HTTP 1.1 and the keyword names should map easily to the 3 digit status codes in HTTP 1.1 (e.g. IPP status "client-error-bad-request" maps to HTTP 1.1 status "400 Bad Request" where 4xx is the class for "Client Error" in HTTP 1.1). I marked IPP-specific status codes as "(IPP)". FYI, I also marked the HTTP 1.1 status codes specifically described in SWP as "(SWP)". Finally, I included notes to reviewers inline. Enjoy, Keith ---- Start of Status Section ---- 4.3 Status and Message The Status code provides information on the results of a request. The Message provides a short textual description of the Status. The Status is intended for use by automata and the Message is intended for the human user. An IPP application (i.e. a browser, GUI, print driver or gateway) is not required to examine or display the Message. The prefix of the Status keyword defines the class of response as follows: o informational - Request received, continuing process o successful - The action was successfully received, understood, and accepted o redirection - Further action must be taken in order to complete the request o client-error - The request contains bad syntax or cannot be fulfilled o server-error - The server failed to fulfill an apparently valid request IPP status codes are extensible. IPP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications shall understand the class of any status code, as indicated by the prefix, and treat any unrecognized response as being equivalent to the first status code of that class, with the exception that an unrecognized response shall not be cached. For example, if an unrecognized status code of client-error-foo-bar is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a client-error-bad-request status code. In such cases, IPP applications should present the Message to the user, since that Message is likely to include human- readable information which will explain the unusual status. 4.4 Status Codes (type2 keyword) Each Status is described below, including a description of which operation(s) it can follow and any metainformation required in the response. 4.4.1 Informational This class of status code indicates a provisional response and is to be used for informational purposes only. There are no status codes defined in IPP 1.0 for this class of status code. 4.4.2 Successful This class of status code indicates that the client's request was successfully received, understood, and accepted. 4.4.2.1 successful-OK (SWP) The request has succeeded. The information returned with the response is dependent on the operation, for example: Print-Job A Job is created and the Job URI is returned in the response; Validate A validation request is fully supported by an IPP Printer; Create-Job A Job is created and the Job URI is returned in the response; Send-Data Data is written in a Job; Cancel The Job is cancelled; Get-Jobs The Jobs currently belonging to the IPP Printer are returned in the response; Get-Attributes The values for the attributes specified in the request are returned in the response. NOTE TO REVIEWERS: SWP only includes OK. SWP does not include Created nor No Content successful status codes. This is consistent with our agreement at the IPP Model telecon on May 9, but I believe we had this discussion before Bob Herriot joined the telecon. 4.4.2.2 successful-attribute-ignored (IPP) For the Get-Attributes or Get-Jobs operation, if an IPP Printer does not implement an attribute specified in the request, the Printer shall ignore the attribute and return this status. For all other operations, if an IPP Printer does not implement an attribute specified in the request, the Printer shall return client-error-attribute-value-not-supported. Note that for these operations, an unimplemented attribute will have an unsupported value in the request since the intent is to set or validate a value. In practice, an IPP application should avoid this situation by querying an IPP Printer for its valid attributes and values before performing an operation on the object. 4.4.3 Redirection Status Codes This class of status code indicates that further action needs to be taken to fulfill the request. There are no status codes defined in IPP 1.0 for this class of status code. 4.4.4 Client Error Status Codes This class of status code is intended for cases in which the client seems to have erred. The server should return a Message containing an explanation of the error situation and whether it is a temporary or permanent condition. IPP applications should display any returned Message to the end-user. Unless otherwise noted, these status codes apply to all operations. 4.4.4.1 client-error-bad-request (SWP) The request could not be understood by the server due to malformed syntax. The IPP application should not repeat the request without modifications. 4.4.4.2 client-error-unauthorized The request requires user authentication. The IPP client may repeat the request with suitable authorization credentials. If the request already included authorization credentials, then this status code indicates that authorization has been refused for those credentials. If this response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user should be presented the Message in the response, since that Message may include relevant diagnostic information. 4.4.4.3 client-error-payment-required This request requires payment by the end-user to perform the operation. NOTE TO REVIEWERS: HTTP 1.1 designates this status as reserved for future use. Should IPP do the same? 4.4.4.4 client-error-forbidden (SWP) The server understood the request, but is refusing to fulfill it. Authorization will not help and the request should not be repeated. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused or when no other response is applicable. 4.4.4.5 client-error-method-not-allowed The operation specified in the request is not allowed for the object identified by the request URI. NOTE TO REVIEWERS: HTTP 1.1 further states: "The Reponse MUST include an Allow header containing a list of valid methods for the requested resource." Will IPP over HTTP 1.1 support this? 4.4.4.6 client-error-not-found The server has not found anything matching the request URI. No indication is given of whether the condition is temporary or permanent. In practice, an application should avoid this situation by presenting a list of valid Printer URIs and Job URIs to the end-user. 4.4.4.7 client-error-gone The requested object is no longer available at the server and no forwarding address is known. This condition should be considered permanent. Clients with link editing capabilities should delete references to the request URI after user approval. If the server does not know or has no facility to determine,whether or not the condition is permanent, the status code client-error-not-found should be used instead. This response is cachable unless indicated otherwise. This response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner. 4.4.4.8 client-error-request-entity-too-large (SWP) The server is refusing to process a request because the request entity is larger than the server is willing or able to process. An IPP Printer returns this status code when it limits the size of print jobs and it receives a print job that exceeds that limit. 4.4.4.9 client-error-request-URI-too-long The server is refusing to service the request because the request URI is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly submitted a request with long query information (e.g. an IPP application allows an end-user to enter an invalid URI), when the client has descended into a URL "black hole" of redirection (e.g., a redirected URL prefix that points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present in some servers using fixed-length buffers for reading or manipulating the Request-URI. 4.4.4.10 client-error-unsupported-media-type (SWP) The server is refusing to service the request because the print data is in a format, as specified in document-format, not supported by the IPP Printer. 4.4.4.11 client-error-attribute-value-not-supported (IPP) For a Create-Job, Print-Job or Validate operation, if the IPP Printer does not support at least one attribute value specified in the request, the Printer shall return this status. For example, if the request requires A4 paper and that paper size is not supported by the Printer, the Printer shall return this status. For a Get-Jobs operation, if the IPP Printer does not support at least one attribute value for Job Owner and/or Job States in the request, the Printer shall return this status. In practice, an IPP application should avoid this situation by querying an IPP Printer for its valid attributes and values before performing an operation on the Printer. 4.4.5 Server Error Status Codes This class of status codes indicates cases in which the server is aware that it has erred or is incapable of performing the request. The server should include a Message containing an explanation of the error situation, and whether it is a temporary or permanent condition. IPP applications should display any included Message to the user. These response codes are applicable to any operation. 4.4.5.1 server-error-internal-server-error The server encountered an unexpected condition which prevented it from fulfilling the request. 4.4.5.2 server-error-operation-not-implemented The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize an operation and is not capable of supporting it for any object. 4.4.5.3 server-error-service-unavailable The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay may be indicated in the Message. If no delay is given, the IPP application should handle the response as it would for a server-error-internal-server-error response. 4.4.5.4 server-error-IPP-version-not-supported (IPP) The server does not support, or refuses to support, the IPP protocol version that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client other than with this error message. The response should contain a Message describing why that version is not supported and what other versions are supported by that server. A conforming IPP client shall specify the valid version for IPP 1.0 on each request. A conforming IPP server shall not return this status code to a conforming IPP 1.0 client. An IPP server shall return this status code to a non-conforming IPP client. 4.4.4.5 server-error-printer-error (IPP) A printer error, such as a paper jam, occurs while the IPP Printer processes a Print-Job or Send-Data operation. The response shall contain the Job Status with the specific error and should contain a Message describing the error. An IPP application should check the Job Status in the response for the specific error. 4.4.4.6 server-error-write-fault (IPP) A write error, such as a memory overflow (i.e. the document data exceeds the memory of the Printer) or a disk full condition, occurs while the IPP Printer processes a Print-Job or Send-Data operation. 4.4.4.7 server-error-too-many-documents-in-job (IPP) For a Create-Job operation, the number-of-documents specified in the request exceeds the number-of-documents supported by the Printer. For a Send-Data operation, the IPP Printer cannot process a Document in a Job because the document exceeds the number-of-documents supported by the Printer. If an IPP application receives this status, the application shall send multiple documents as separate Jobs using the Print-Job operation for each document. ---- End of Status Section ---- From ipp-archive Wed May 21 15:39:57 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA04358 for ipp-outgoing; Wed, 21 May 1997 15:39:05 -0400 (EDT) From: root@truespectra.com (Administrator) To: ipp@pwg.org (ipp) Message-ID: <1997May21.134007.1896.45431@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: Wed, 21 May 1997 15:43:35 -0400 Subject: IPP>MOD May 14 MOD meeting Sender: ipp-owner@pwg.org Precedence: bulk Status: RO On further reflection of some of the discussions and decisions made during t= he = MOD meeting at StarTech, I believe we may have been too hasty in deleting th= e = Font parameter requirements and relegating them to the printer MIB. Fonts ar= e = not always a property of the printer and in many cases may be rendered by th= e = OS or other software. I think that fonts are an installed capability no = different from a stapler attachment, media type, sides, finishing capabiliti= es = and should be specifiable on job submission. Further, specifying font = substitutions is not much different than saying to pint the letter size = document on A4 or legal because thats what is available. = Can we put this back in? Comments? Rob Kline From ipp-archive Wed May 21 16:00:09 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA05625 for ipp-outgoing; Wed, 21 May 1997 15:52:21 -0400 (EDT) Date: Wed, 21 May 1997 12:50:21 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705211950.MAA13059@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, hastings@cp10.es.xerox.com Subject: Re: IPP> Re: Unsigned integer count for attribute name keywords and attribute values Cc: paulmo@microsoft.com, ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > From hastings@cp10.es.xerox.com Tue May 20 22:35:24 1997 > > At 12:37 05/20/97 PDT, Robert Herriot wrote: > > > >> From hastings@cp10.es.xerox.com Tue May 20 11:48:48 1997 > >> > > To be more clear, we should outlaw ASCII NUL character in ASCII coded strings > and outlaw the UTF-8 NUL *character* in UTF-8 strings. Otherwise, some client > may be putting in such padding (within the count) in order to align the > two-octet attribute name or attribute value that follow, so that the > particular server that the client was built with could pick up the integers > as (aligned) integers, because they were aligned in memory as the data was > unmarshalled into memory, rather than picking up the two-octet integers as > individual octets. > > Another reason to outlaw these NUL characters, is to prevent servers from > having to filter them out before doing string compares. If one client starts > to embed NULs and some servers filter them out, then we get interoperability > problems with the servers that don't. > > In short, this is a small problem with a simple fix: Just add a sentence > that forbids the counted ASCII and UTF-8 strings to contain the NUL character > when representing attribute names and attribute values in IPP. I don't agree with most of your reasons for outlawing NUL. Padding is not an issue because we specify precisely the byte position of each item in the protocol. Alignment is a notion that each platform deals with as it parses the protocol; it is not a protocol notion. Because the server has a length, it can easily compare the strings using a a length based compare (e.g. memcmp in Unix 95). In addition, many servers will convert the UTF-8 to some other encoding. The real question is what are allowable characters (not encodings) for names and values. We have talked about key-words being limited to letters, digits, hyphen and underscore. That eliminates far more than NUL. For values, we have the same question except the possibilities are more numerous. We have said that values are text. Do we want to say that there are no exceptions. Because of the format of the protocol, an attribute could be an octet string for certain well-known attributes. For attributes with text values, I think that it is reasonable to eliminate certain control characters once the value is decoded, but decoding is the key. If we later allow Unicode encoded values in addition to UTF-8, then some octets will be NULs, even if we eliminate the Unicode character equivalent to NUL. Bob Herriot From ipp-archive Wed May 21 16:00:38 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA05843 for ipp-outgoing; Wed, 21 May 1997 15:55:27 -0400 (EDT) Date: Wed, 21 May 1997 12:48:07 PDT From: "Caruso,Angelo" Subject: IPP> RE: JMP> MOD - simplified legal state transition diagram To: ipp@pwg.org, jmp@pwg.org Message-id: <8F4E833381262D798F4E833381262D79#064#x-wb-0311-ms1.xerox@SMF> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Posting-date: Wed, 21 May 1997 15:54:52 -0400 Priority: normal Hop-count: 3 Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Tom, To test my understanding: you are suggesting that the 'retained' sate be removed from IPP, the 'terminating' state in IPP be renamed 'canceled', and the 'needsAttention' state ne removed from the Job MIB. Correct? Note, this will have the side effect of requiring that the jobStateReasons1 attribute in the Job MIB become mandatory (for sake of the 'printer-stopped' bit). The original motivation for the 'needsAttention' state was that a job monitoring application could quickly determine that the device needs operator intervention without having to poll the job state reasons. Even so, I am in favor of making the change in order for the IPP and JMP job state models to be as identical as possible. I just want to make sure everyone is aware of the trade off being made here. If this change is agreed to, then should we move the newly-mandatory jobStateReasons1 attribute to the job table? Thanks, Angelo ---------- From: jmp-owner@pwg.org To: ipp@pwg.org; jmp@pwg.org Subject: JMP> MOD - simplified legal state transition diagram Date: Wednesday, May 21, 1997 12:00AM So the simplified legal state transition diagram for IPP and JMP would become, following Bob's proposal: New state Old state unknown(2) pending(3) processing(4) canceled(5) completed(6) unknown(2) yes yes pending(3) yes yes processing(4) yes yes yes canceled(5) yes completed(6) yes A blank entry indicates impossible transitions. Self loops are not indicated, such as a Get-Attributes operation on a job, since they aren't a job state transition. For IPP we need to consider which job states and job state transtions are required for conformance and which are optional. JMP requires that processing(4), canceled(5), and completed(6) are mandatory, so that pending(3) is optional. What about unknown(2)? The former needsAttention state was also mandatory, so that the new job-state reason: printer-stopped, should become a mandator job state reason, correct? For IPP and JMP, all transitions into the canceled state should be required. However, the transition from processing back to pending (a job-held situation) is optional. From ipp-archive Wed May 21 16:49:28 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA07281 for ipp-outgoing; Wed, 21 May 1997 16:47:05 -0400 (EDT) Date: Wed, 21 May 1997 13:48:43 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705212048.NAA13592@woden.eng.sun.com> To: ipp@pwg.org, carterk@us.ibm.com Subject: Re: IPP> MOD - UPDATE FOR STATUS CODE KEYWORDS IN THE MODEL DOCUMENT X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Good job. I have some comments below Bob Herriot > From carterk@us.ibm.com Wed May 21 12:48:36 1997 > Is this really necessary, especially if the returned attributes indicate which are unsupported. This is a case of half-full versus half-empty. > 4.4.2.2 successful-attribute-ignored (IPP) I'm not sure if this is a useful error, or even likely to happen. > > 4.4.4.5 server-error-printer-error (IPP) > > A printer error, such as a paper jam, occurs while the IPP Printer > processes a Print-Job or Send-Data operation. The response shall contain > the Job Status with the specific error and should contain a Message > describing the error. An IPP application should check the Job Status > in the response for the specific error. I would expect the client to block on a write and that it wouldn't clear until the server got enough space to write the data. > > 4.4.4.6 server-error-write-fault (IPP) > > A write error, such as a memory overflow (i.e. the document data > exceeds the memory of the Printer) or a disk full condition, occurs > while the IPP Printer processes a Print-Job or Send-Data operation. With the changes from last week where all Printers support PrintJob (1 document per job) and some support CreateJob/SendJobData (1 or more documents per job), this message isn't needed. The error server-error-operation-not-implemented handles this problem instead. > > 4.4.4.7 server-error-too-many-documents-in-job (IPP) > From ipp-archive Wed May 21 16:59:59 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA07770 for ipp-outgoing; Wed, 21 May 1997 16:57:45 -0400 (EDT) Mime-Version: 1.0 Date: Wed, 21 May 1997 17:02:30 -0400 Message-ID: <00016972.1337@digprod.com> From: bwagner@digprod.com (Bill Wagner) Subject: Re: IPP> MOD - simplified legal state transition diagram To: ipp@pwg.org, jmp@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: bulk Status: RO I apologize if I missed a step or two in this exchange. Of course, I agree with the objective and believe the states listed are adequate. However, the 'unknown' state, within general MIB use at least, has been more a reflection on the state of the equipment than the job. That is, the state of a job is unknown because of some sensing difficulty or sequence difficulty with the equipment, not because it is a normal state in the sequence of handling a job. It would be quite possible for a unit to report no state other than unknown. It seems it would also be possible for a unit to recognize a state after it has previously been unknown. For example, if a job can be identified, it can be canceled and the state is then likely to be canceled and not unknown. In short, I suggest that unknown is a wild card rather than a job state that exists before pending and processing and after canceled and completed. If something is necessary for the pre-pending and post complete states, what about Other? Bill Wagner, Osicom/DPI ______________________________ Reply Separator _________________________________ Subject: IPP> MOD - simplified legal state transition diagram Author: Tom Hastings at Internet Date: 5/21/97 7:29 AM So the simplified legal state transition diagram for IPP and JMP would become, following Bob's proposal: New state Old state unknown(2) pending(3) processing(4) canceled(5) completed(6) unknown(2) yes yes pending(3) yes yes processing(4) yes yes yes canceled(5) yes completed(6) yes A blank entry indicates impossible transitions. Self loops are not indicated, such as a Get-Attributes operation on a job, since they aren't a job state transition. For IPP we need to consider which job states and job state transtions are required for conformance and which are optional. JMP requires that processing(4), canceled(5), and completed(6) are mandatory, so that pending(3) is optional. What about unknown(2)? The former needsAttention state was also mandatory, so that the new job-state reason: printer-stopped, should become a mandator job state reason, correct? For IPP and JMP, all transitions into the canceled state should be required. However, the transition from processing back to pending (a job-held situation) is optional. From ipp-archive Wed May 21 18:09:28 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA08594 for ipp-outgoing; Wed, 21 May 1997 18:06:44 -0400 (EDT) Message-ID: <338370C7.A558F44F@sharplabs.com> Date: Wed, 21 May 1997 15:01:44 -0700 From: Randy Turner Organization: Sharp Labs of America X-Mailer: Mozilla 4.0b3C (X11; I; SunOS 4.1.4 sun4m) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> Protocol encoding addition... X-Priority: 3 (Normal) Content-Type: multipart/alternative; boundary="------------62A5254C4C1E8C680E0AAF07" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO --------------62A5254C4C1E8C680E0AAF07 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I would like to propose an additional encoding field that would be included in the application/IPP body for IPP requests. This additional field would be a "transaction identifier" field. IPP clients would generate a unique transaction identifier to be included with each request. The IPP server would not do any processing or interpretation of the transaction identifier. Instead, the IPP server would just include this transaction identifier on the response message to the original request. The client would then use the received transaction identifier to match this response to the original request that it generated previously. While this field may or may not be utilized by HTTP transport implementation, it could definitiely be used by raw IPP implementations directly over TCP ports for request pipelining and verification of responses. The additional field would be a 32-bit binary field in big-endian byte order. This field would appear immediately after the initial version number and IPP general header. Before any attributes or data. Comments? Randy --------------62A5254C4C1E8C680E0AAF07 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
    I would like to propose an additional encoding field that would be included in the
    application/IPP body for IPP requests. This additional field would be a
    "transaction identifier" field.  IPP clients would generate a unique transaction identifier
    to be included with each request. The IPP server would not do any processing or
    interpretation of the transaction identifier. Instead, the IPP server would just include
    this transaction identifier on the response message to the original request.

    The client would then use the received transaction identifier to match this response to
    the original request that it generated previously. While this field may or may not be
    utilized by HTTP transport implementation, it could definitiely be used by raw
    IPP implementations directly over TCP ports for request pipelining and verification of
    responses.

    The additional field would be a 32-bit binary field in big-endian byte order. This
    field would appear immediately after the initial  version number and IPP general
    header. Before any attributes or data.

    Comments?

    Randy
--------------62A5254C4C1E8C680E0AAF07-- From ipp-archive Wed May 21 18:24:28 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA09081 for ipp-outgoing; Wed, 21 May 1997 18:20:54 -0400 (EDT) Message-Id: <3.0.1.32.19970521151607.00ecac50@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 21 May 1997 15:16:07 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - IPP Documents for the IETF Cc: Harald.T.Alvestrand@uninett.no, moore@cs.utk.edu, masinter@parc.xerox.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO In our PWG IPP phone conference today we discussed how to organize our various emerging IPP documents, based on the discussions held in the PWG meeting in San Diego last week, which BTW resulted in a strong recommendation to do our first transfer mapping to HTTP 1.1 (warts and all, more about that later). As we need to update our IETF charter text in the near future, I would like to get the groups reaction on the following proposal for our series of IPP documents to be produced. We have a number of basic standards track documents that are less likely to require change once they are agreed: IPP Model and Semantics IPP Security IPP Directory Schema IPP Encoding of Operations All of the above documents should contain transport independent information. We would then need a transfer specific IPP Profile document (on the standards track), that would reference the 4 documents listed above: Profile for running IPP over HTTP 1.1 (this would include some of HTTP specific security protocol recommendations). In addition, we have the two informational documents that are NOT on the standards track: Internet Printing Requirements Mappings between IPP and RFC 1179 We probably do not need to reference these explicitly from the standards track documents? Can I get your reactions on whether these are the right documents to be listed? An alternative that has been discussed is to merge the IPP Encoding of Operations with the Profile for running IPP over HTTP 1.1 document. Do we gain a lot by keeping these as two separate documents? 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 Wed May 21 18:34:57 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA09554 for ipp-outgoing; Wed, 21 May 1997 18:32:56 -0400 (EDT) Message-Id: <3.0.1.32.19970521152813.00ec8098@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 21 May 1997 15:28:13 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> Protocol encoding addition... In-Reply-To: <338370C7.A558F44F@sharplabs.com> Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO At 03:01 PM 5/21/97 PDT, Randy Turner wrote: >>>> I would like to propose an additional encoding field that would be included in the application/IPP body for IPP requests. This additional field would be a "transaction identifier" field. IPP clients would generate a unique transaction identifier to be included with each request. <<<<<<<< How unique does the identifier has to be? By client, by server, or globally? >>>> The IPP server would not do any processing or interpretation of the transaction identifier. Instead, the IPP server would just include this transaction identifier on the response message to the original request. The client would then use the received transaction identifier to match this response to the original request that it generated previously. While this field may or may not be utilized by HTTP transport implementation, it could definitiely be used by raw IPP implementations directly over TCP ports for request pipelining and verification of responses. <<<<<<<< Sounds like it would be enough if the client can recognize it as unique? >>>> The additional field would be a 32-bit binary field in big-endian byte order. This field would appear immediately after the initial version number and IPP general header. Before any attributes or data. Comments? <<<<<<<< This sounds good, but you still have not explained why we want it and what potential use we would have of it? I assume the intent is to keep several related operations together, but is that not also important for the server to know about? >>>> Randy <<<<<<<< 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 May 21 18:39:29 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA09573 for ipp-outgoing; Wed, 21 May 1997 18:34:59 -0400 (EDT) Message-ID: <338378A1.2C00@parc.xerox.com> Date: Wed, 21 May 1997 15:35:13 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> application/ipp vs. application/print-job References: <338370C7.A558F44F@sharplabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I'm dissatisfied with "application/ipp" as the name for the Internet media type registration, because it's somewhat redundant (i = internet in an internet protocol) and misdirected (the content is not a 'protocol', it's a description of a print job used in one protocol but useful possibly in others). So I suggest renaming it: application/print-job. That is, an 'application/print-job' is a description of a job that the sender wants the recipient to print. It might be possible to send one of these in an internet fax, or in just regular email. You're designing it to work in a particular kind of messaging (one in which the result of the message is something that lets you query status and modify the job later), but it's just a message. As far as a 'transaction identifier' that Randy Turner was proposing, I thought that the transaction was a resource, and that you would identify it using a uniform resource identifier (aka URI aka URL). A 'raw IPP' shouldn't be so raw as to not allow interaction with printer resources using ipp://host URLs instead of http://host URLs, but for the most part, which protocol you were using would just be determined by the name of the scheme. Larry -- http://www.parc.xerox.com/masinter From ipp-archive Wed May 21 18:45:47 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA09824 for ipp-outgoing; Wed, 21 May 1997 18:42:07 -0400 (EDT) From: Keith Carter To: Subject: Fwd: RE: IPP> MOD - UPDATE FOR STATUS CODE KEYWORDS IN THE M Message-Id: <5040300001666613000002L032*@MHS> Date: Wed, 21 May 1997 18:43:29 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Bob, Thanks for the feedback. My responses inline as KC>>. Keith 1) Is this really necessary, especially if the returned attributes indicate which are unsupported. This is a case of half-full versus half-empty. > 4.4.2.2 successful-attribute-ignored (IPP) KC>> I agree since this can only now occur if an IPP application KC>> specifies an unimplemented attribute on a Get-Attributes or KC>> Get-Jobs operation in which case the application will check KC>> the values and see a value of "unsupported" for the KC>> unimplemented attributes. Good catch. 2) I'm not sure if this is a useful error, or even likely to happen. > > 4.4.4.5 server-error-printer-error (IPP) > > A printer error, such as a paper jam, occurs while the IPP Printer > processes a Print-Job or Send-Data operation. The response shall contain > the Job Status with the specific error and should contain a Message > describing the error. An IPP application should check the Job Status > in the response for the specific error. KC>> This can only occur if an IPP Printer does not spool. I believe KC>> this is a supported configuration. If this status code KC>> is overkill for IPP 1.0, then let's remove it. 3) I would expect the client to block on a write and that it wouldn't clear until the server got enough space to write the data. > > 4.4.4.6 server-error-write-fault (IPP) > > A write error, such as a memory overflow (i.e. the document data > exceeds the memory of the Printer) or a disk full condition, occurs > while the IPP Printer processes a Print-Job or Send-Data operation. KC>> Again, this is most likely to occur on an IPP Printer that does KC>> not spool and the client times out. If this status is overkill, KC>> for IPP 1.0 let's remove it. 4) With the changes from last week where all Printers support PrintJob (1 document per job) and some support CreateJob/SendJobData (1 or more documents per job), this message isn't needed. The error server-error-operation-not-implemented handles this problem instead. > > 4.4.4.7 server-error-too-many-documents-in-job (IPP) > KC>> I agree. Good catch. From ipp-archive Wed May 21 18:55:04 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA10562 for ipp-outgoing; Wed, 21 May 1997 18:50:24 -0400 (EDT) Date: Wed, 21 May 1997 15:52:06 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705212252.PAA14695@woden.eng.sun.com> To: ipp@pwg.org, masinter@parc.xerox.com Subject: Re: IPP> application/ipp vs. application/print-job X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > From masinter@parc.xerox.com Wed May 21 15:47:02 1997 > > > So I suggest renaming it: application/print-job. That is, > an 'application/print-job' is a description of a job that the > sender wants the recipient to print. > Because the application/ipp entity is used for all print operations, it would be more accurate to call it application/print-operation. Bob Herriot From ipp-archive Wed May 21 18:59:59 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA10876 for ipp-outgoing; Wed, 21 May 1997 18:54:53 -0400 (EDT) Date: Wed, 21 May 1997 18:51:30 -0400 (EDT) From: JK Martin Message-Id: <199705212251.SAA25067@uscore.underscore.com> To: cmanros@cp10.es.xerox.com Subject: Re: IPP> Protocol encoding addition... Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO In response to Randy's newly proposed addition you wrote: > This sounds good, but you still have not explained why we want it and > what potential use we would have of it? I assume the intent is to keep > several related operations together, but is that not also important for > the server to know about? It's not important (nor even useful) for the server to know about such client-specified transaction IDs. Client-specified transaction IDs can be found in lots of different protocols, including SNMP and CPAP. As Randy pointed out, it helps the client match responses to previous requests. This allows a client to post multiple requests at one time--without waiting for the responses in a synchronous manner--then later match the responses once they arrive from the server. Good idea, Randy, although such transaction IDs probably won't be of much use in the HTTP-mapped implementation scenario. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-archive Wed May 21 19:10:41 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA11801 for ipp-outgoing; Wed, 21 May 1997 19:06:02 -0400 (EDT) Date: Wed, 21 May 1997 19:06:07 -0400 (EDT) From: JK Martin Message-Id: <199705212306.TAA25113@uscore.underscore.com> To: masinter@parc.xerox.com Subject: Re: IPP> application/ipp vs. application/print-job Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Larry, I see your point about the "purity" (or lack thereof) for using "ipp" as the application name. Perhaps you're right, a better name should be assigned for this encoding. However, by the same token, assigning the name "print-job" is probably too generic. It is unlikely that the IPP approach for printing over HTTP (or any other quasi-MIME-encoded mechanism) will be (or is) the only one of its kind in the internet. Assuming that "print-job" is reasonable for other print-like mechanisms (such as fax) is not really clear, is it? Can we think of some other name that better serves to bind the implied encoding with the specification defined by the IPP group? (Sorry, I have no suggestions at this point.) Regarding your comments on transaction indentifiers, sure, we can always use a URI. We can actually use anything we want, so long as the client can easily discern between assigned ID values. However, our experience has shown that an integer value is far more useful within an implementation, given the fact that the transaction ID is a processing aid and not a UI component of some kind. If we are going to have "transaction identifiers", then let's try to keep them as simple as possible, and integers really work out the best. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- ----- Begin Included Message ----- >From ipp-owner@pwg.org Wed May 21 18:43 EDT 1997 Date: Wed, 21 May 1997 15:35:13 PDT From: Larry Masinter To: ipp@pwg.org Subject: IPP> application/ipp vs. application/print-job Content-Transfer-Encoding: 7bit I'm dissatisfied with "application/ipp" as the name for the Internet media type registration, because it's somewhat redundant (i = internet in an internet protocol) and misdirected (the content is not a 'protocol', it's a description of a print job used in one protocol but useful possibly in others). So I suggest renaming it: application/print-job. That is, an 'application/print-job' is a description of a job that the sender wants the recipient to print. It might be possible to send one of these in an internet fax, or in just regular email. You're designing it to work in a particular kind of messaging (one in which the result of the message is something that lets you query status and modify the job later), but it's just a message. As far as a 'transaction identifier' that Randy Turner was proposing, I thought that the transaction was a resource, and that you would identify it using a uniform resource identifier (aka URI aka URL). A 'raw IPP' shouldn't be so raw as to not allow interaction with printer resources using ipp://host URLs instead of http://host URLs, but for the most part, which protocol you were using would just be determined by the name of the scheme. Larry -- http://www.parc.xerox.com/masinter ----- End Included Message ----- From ipp-archive Wed May 21 20:24:30 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA12685 for ipp-outgoing; Wed, 21 May 1997 20:20:50 -0400 (EDT) Message-ID: <3383916D.6F4@parc.xerox.com> Date: Wed, 21 May 1997 17:21:01 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: JK Martin CC: ipp@pwg.org Subject: Re: IPP> application/ipp vs. application/print-job References: <199705212306.TAA25113@uscore.underscore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > However, by the same token, assigning the name "print-job" is probably > too generic. It is unlikely that the IPP approach for printing over > HTTP (or any other quasi-MIME-encoded mechanism) will be (or is) the > only one of its kind in the internet. > However, by the same token, assigning the name "print-job" is probably > too generic. It is unlikely that the IPP approach for printing over > HTTP (or any other quasi-MIME-encoded mechanism) will be (or is) the > only one of its kind in the internet. Some people say "the only good thing about standards is there are so many of them to choose from". However, the outcome of the IPP working group is supposed to be _the_ proposed standard for printing in the Internet. If you just want to do something without making it the standard, then you don't need a standards group where you're forced to listen to fools like me. > Assuming that "print-job" is reasonable for other print-like > mechanisms (such as fax) is not really clear, is it? I would assume that "print-job" was a good name for what it is that you're sending in submitting a job. Maybe you want some more general way to marshall and unmarshall an attribute value list, but then there are lots of those, including application/directory and multipart/form-data. Then you just need a schema and a version of the scheme. Right? Larry -- http://www.parc.xerox.com/masinter From ipp-archive Thu May 22 00:39:32 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA13783 for ipp-outgoing; Thu, 22 May 1997 00:35:38 -0400 (EDT) Message-Id: <9705220435.AB09386@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, 21 May 1997 21:33:26 PDT To: ipp@pwg.org, Scott Isaacson From: Tom Hastings Subject: Re: IPP> MOD - 5/14 mintues Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I have several questions and comments on the detailed minutes that Scott wrote. Thanks for being so thorough, Scott. Tom At 11:25 05/21/97 PDT, Scott Isaacson wrote: > > 4. Reminder that the Model document still includes concepts > that are not to be implemented in v1.0 of the protocol. What concepts are these? Shouldn't they either be labeled as beyound V1.0 or removed? > 14. All "name", "text", and "fileName" attributes are > defined as characters in the Model document. This leaves > open the option of Unicode or other DBCS in the actual > protocol. Why can't we specify UTF8 (not Unicode) in the Model document as the coded character set for values? Then we avoid a lot of messy coded character set mapping rules in the encoding and protocol documents. Believe me coded character set mapping is very hard! Most character sets don't have all the same characters, and/or have over lapping characters. Lets avoid character set mapping altogether in our documents. We specify USASCII for the attribute name keywords in the model document, why not specify UTF8 as well (and follow the recommendations of the IETF here). > > 15. Reaffirmed that keywords must start with a character (no > digits) You mean no leading digits; embeded digits are ok, correct? So need to change the values for the "sides" attribute which are: '1-sided', '2-sided-long-edge', and '2-sided-short-edge'. How about 'one-sided', 'two-sided-long-edge', and 'two-sided-short-edge'. Also the values of the "number-up" attribute which are: '1', '2', and '4'. Two alternative: 'one-up', 'two-up', 'four-up'. Or actual integers, but the number-up-supported would be a setOf Integer. Then there would be no need to register additional values. Perhaps we'd need to introduce a new datatype: integerMember for the job attribute, so that we could continue an algorithmic mapping from the data type of the job attribute to the data type of the xxx-supported, which in this case would be integerMember to 1SetOf Integer. > 17. We had a 3 hour discussion on best-effort. The final > proposal was to do away with any notion of "substitute" > values when there is a conflict between what is requested > and what is supported. The expectation is that if a client > specifies something and it is not supported, return an error > so that the client can query what is supported. best-effort > will now apply to only conflicts between IPP attributes and > what is in the document stream (PDL) itself. Proposed > values are: SHALL_HONOR_IPP_ATTR (IPP attribute values take > precedence over PDL instructions), SHOULD_HONOR_IPP_ATTR > (same as SHALL with no guarantees), and > NEED_NOT_HONOR_IPP_ATTR (PDL takes precedence over IPP > attributes). Just a nit, but so far keywords have been all lower case with hyphens, except for acronyms, so here too. Also we have been using full words, so how about: 'shall-honor-IPP-attributes', 'should-honor-IPP-attributes', 'need-not-honor-IPPP-attributes'? > 18. Clarified that defaults are not overrides. What does a > user intend when the user does not specify an attribute: > either 1) They want the admin default, 2) They want the > PDL default. In either case, they really don't know or > care, they really care if they specify the value. The idea > of "default behavior" will be removed from the Model > document. It is not possible to specify a consistent > default behavior for features that are not implemented or > for extensions that are yet to be added. > > 19. When a Job object is created only supplied attributes > will be copied from the request into the Job object. In > order to determine the defaults that will be applied, query > the Printer Job Template attributes to get defaults. We need to clarify in the above that: The Printer object applies the default values when there is no value supplied by either the client in the IPP protocol or by the document in the PDL. Presumably when the Printer object applies the defaults is implementation dependent. Some implementations for some attributes may scan the PDL at job submission time, shortly thereafter, or just before processing. Some implementations may wait until during interpretation of the PDL. Some implementations may set the output device to the default values just prior to sending the document PDL to the output device. If the PDL changes the output device, the PDL overrode the defaults. > 24. Moved to make all time related attributes relative to > job submission (not absolute time). That is "job-sumission- > time" moves to "time-since-submitted". There was also a > discussion about having "time-since-xxx" attributes for each > of the Job state transitions (pending to processing, > processing to completed). I did not capture the final > decision on this. These are mandatory Processing to completed is what we already have in the "completion-time" attribute, so its not new. I think that we did not agree to add "time-since-processing" on the grounds that that is an attribute in the Job Monitoring MIB for accounting and system utilization, so we didn't need to add it to IPP, since IPP isn't for accounting and utilization analysis. I think we agreed to change the "completion-time" attribute to "time-since-completion" to follow the "submission-time" change to "time-since-submission". This gets rid of the difficult dateTime data type. My notes said the units were milliseconds. But wouldn't seconds be sufficient? Nit: should they both be "time-since-submitted" and "time-since-completed" or "time-since-submision" and "time-since-completion"? [The attribute table that I sent you had the latter] > 27. We had a discussion on using MIME registered types as > document-format values. I didn't capture a final decision > on this issue. My recollection was that we decided to go with MIME registered types, insted of the Printer MIB and Job Monitoring MIB Interpreter Language Family enums. However, this means that our Printer MIB and Job Monitoring MIB are different from IPP (so there may be other members of PWG that disagree with this decision made in the Modeling sub-group of IPP). > 7. Define SHALL and SHOULD get rid of NEED_NOT > Who: Scott Why get rid of "need not"? It needed when the standard has to say that an implementor does not need to do something. Its too confusing to say "may not", since it sounds like a prohibition, rather than a relaxation of requirements. POSIX and ISO standards are quite clear on this terminology. You even have the value for best-effort with the 'need-not' value? On the other hand, when you find the RFC for IETF conformance terminology, they may have covered this point. > 8. Create a table of attributes > Who: Tom Done and sent to Scott, 5/20/97. Scott said he'd post after reviewing it for accuracy and comparison with his notes. From ipp-archive Thu May 22 01:49:32 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA14553 for ipp-outgoing; Thu, 22 May 1997 01:46:15 -0400 (EDT) Message-ID: <3383DDAC.195D@parc.xerox.com> Date: Wed, 21 May 1997 22:46:20 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: Keith Carter CC: ipp@pwg.org Subject: Re: IPP> MOD - IPP Versioning References: <5040300001660586000002L062*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO The HTTP/1.1 versioning language is a very poor model to follow. It's been so troublesome that we had to issue a separate Internet Draft (now to become an RFC) to clarify the issue of use of version numbers between multiple version clients and servers. Given this history, I don't recommend using it in IPP. I hate to question the fundamentals, but there are so many other points of flexibility in what you're designing that I might question the need for yet another verison number. What you're calling "IPP" is really an application profile of a set of other protocols. By coding messages as attribute/values, establishing a registry of attributes, and some notion of optional or manditory, you might not need any other extensibility; if an attribute semantics changes, give it a new attribute name. And if you need something that is completely incompatible, give it a new media type. -- Larry -- http://www.parc.xerox.com/masinter From ipp-archive Thu May 22 02:49:52 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA15253 for ipp-outgoing; Thu, 22 May 1997 02:49:06 -0400 (EDT) Message-Id: <9705220649.AA09453@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, 21 May 1997 23:46:52 PDT To: pwg@pwg.org, ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: IPP> RFC 2119, March 1997 has conformance language spec Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Thanks Larry, Tom >Return-Path: >Date: Wed, 21 May 1997 23:08:45 PDT >From: Larry Masinter >Organization: Xerox PARC >To: Tom Hastings >Subject: Re: IPP> MOD - 5/14 mintues >References: <9705220435.AB09386@zazen.cp10.es.xerox.com> > >RFC 2119: Key words for use in RFCs to Indicate Requirement Level. S. >Bradner. March 1997. (Format: TXT=4723 bytes) (Updated by BCP0014) >-- > >Larry >-- >http://www.parc.xerox.com/masinter > > From ipp-archive Thu May 22 03:19:33 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA16297 for ipp-outgoing; Thu, 22 May 1997 03:16:30 -0400 (EDT) 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 From: Harald.T.Alvestrand@uninett.no To: Carl-Uno Manros cc: ipp@pwg.org, moore@cs.utk.edu, masinter@parc.xerox.com Subject: IPP> Re: ADM - IPP Documents for the IETF In-reply-to: Your message of "Wed, 21 May 1997 15:16:07 PDT." <3.0.1.32.19970521151607.00ecac50@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 22 May 1997 09:16:35 +0200 Message-ID: <27814.864285395@munken.uninett.no> Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Carl-Uno, in your message, you give a total of seven documents: IPP Model and Semantics IPP Security IPP Directory Schema IPP Encoding of Operations Profile for running IPP over HTTP 1.1 Internet Printing Requirements Mappings between IPP and RFC 1179 At the moment there are 3 internet-drafts in the I-D store: draft-ietf-ipp-req-00.txt draft-ietf-ipp-model-00.txt draft-ietf-ipp-dir-schema-00.txt None of these have been updated since Memphis. I really can't tell whether you have the right set of documents unless you have some documents; the organization of these documents is in fact less important than their content. (And no, PDF-format documents on a non-IETF fileserver are NOT considered WG documents available for public review!) About the HTTP issue: You got serious pushback in Memphis, and not only from us, that basing IPP on HTTP was going to get you into trouble that you could avoid by doing a "core" protocol and a "gateway from HTTP to IPP" rather than doing straight "IPP over HTTP". I think you are choosing a course that will seriously hamper the future deployment and utilization of the IPP protocol, for reasons that have much to do with marketing/politics and little to do with sound engineering. That is Not a Good Thing; you will probably require at least a document called "Why We Shot Ourselves In The Foot With HTTP" or equivalent, giving the *engineering* justifications for the choice. Harald A From ipp-archive Thu May 22 03:39:37 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA16774 for ipp-outgoing; Thu, 22 May 1997 03:33:23 -0400 (EDT) Message-Id: <9705220733.AA09489@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, 22 May 1997 00:31:11 PDT To: pwg@pwg.org, ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: IPP> Re: RFC 2119, March 1997 has conformance language spec Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I just read the RFC and it defines the following terms and suggests that the following phrase be put early in the document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Happily, the "shall", "should", and "may" terms are as the PWG has been using in its Printer MIB, Job Monitoring MIB, and IPP documents. It also has "must" as a synonym for "shall". I suggest that we continue to use "shall", rather than switching over or using a mixture, in order to keep our PWG standards using the same terminology. Ok? It also says: "These words are often capitalized." I've sent mail to Scott Bradner asking whether it is recommended to capitalize. Seems like it would make these terms stand out more. Should I capitalize SHALL, SHOULD, MAY (and NEED NOT) in the Job Monitoring MIB? What about IPP documents? Thanks, Tom At 23:46 05/21/97 PDT, Tom Hastings wrote: >Thanks Larry, > >Tom > >>Return-Path: >>Date: Wed, 21 May 1997 23:08:45 PDT >>From: Larry Masinter >>Organization: Xerox PARC >>To: Tom Hastings >>Subject: Re: IPP> MOD - 5/14 mintues >>References: <9705220435.AB09386@zazen.cp10.es.xerox.com> >> >>RFC 2119: Key words for use in RFCs to Indicate Requirement Level. S. >>Bradner. March 1997. (Format: TXT=4723 bytes) (Updated by BCP0014) >>-- >> >>Larry >>-- >>http://www.parc.xerox.com/masinter >> >> > > > From ipp-archive Thu May 22 10:14:37 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA18329 for ipp-outgoing; Thu, 22 May 1997 10:11:47 -0400 (EDT) Message-Id: <199705221359.JAA03410@devnix.agranat.com> To: Tom Hastings Cc: ipp@pwg.org Subject: Re: IPP> Re: RFC 2119, March 1997 has conformance language spec In-reply-to: <9705220733.AA09489@zazen.cp10.es.xerox.com> Date: Thu, 22 May 1997 09:59:14 -0400 From: "Scott Lawrence" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO >>>>> "TH" == Tom Hastings writes: TH> It also says: "These words are often capitalized." TH> I've sent mail to Scott Bradner asking whether it is recommended to TH> capitalize. Seems like it would make these terms stand out more. TH> Should I capitalize SHALL, SHOULD, MAY (and NEED NOT) in the Job Monitoring TH> MIB? What about IPP documents? In many years of dealing with standards documents of all sorts, I have always found it usefull when those keywords are in all caps; as you say, it makes it easy to pick them out of large blocks of text. TH> It also has "must" as a synonym for "shall". I suggest that we continue TH> to use "shall", rather than switching over or using a mixture, in order TH> to keep our PWG standards using the same terminology. Ok? The equivalence is often usefull because of the context in which a requirement is placed. Not using both can lead to some bizarre sentence constructions. So long as the definitions are well understood (which 2119 now makes easy) I see no reason not to use each form where it is appropriate. -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-archive Thu May 22 11:09:43 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA19129 for ipp-outgoing; Thu, 22 May 1997 11:05:24 -0400 (EDT) From: Roger K Debry To: Subject: IPP> ADM - IPP Documents for the IETF Message-Id: <5030100002741800000002L002*@MHS> Date: Thu, 22 May 1997 11:07:28 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Carl-Uno, here are a couple of top-of-the-head ideas on organizing the documents ... If the encoding of operations is really to be transport independent, why not include it in the model document? Then all of the transport independent stuff is in one place. I've often wondered if we could actually do the model document in two distinct parts -- maybe two documents. One is the over-all model definition and operations. The second part is the detailed description of the attributes. I think that the security document is informational only. I don't think that there is any new standard definition being suggested in this document. Any transport specific documents, such as IPP over HTTP should include security mechanisms for that transport. For HTTP, for example, we can describe very simply the use of SSL, TSL, basic http authentication and digest authentication. Some other transport may use a different set of security mechanisms. 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 05/22/97 08:55 AM --------------------------- ipp-owner @ pwg.org 05/21/97 04:28 PM Please respond to ipp-owner@pwg.org @ internet To: ipp @ pwg.org @ internet cc: masinter @ parc.xerox.com @ internet, moore @ cs.utk.edu @ internet, Harald.T.Alvestrand @ uninett.no @ internet Subject: IPP> ADM - IPP Documents for the IETF In our PWG IPP phone conference today we discussed how to organize our various emerging IPP documents, based on the discussions held in the PWG meeting in San Diego last week, which BTW resulted in a strong recommendation to do our first transfer mapping to HTTP 1.1 (warts and all, more about that later). As we need to update our IETF charter text in the near future, I would like to get the groups reaction on the following proposal for our series of IPP documents to be produced. We have a number of basic standards track documents that are less likely to require change once they are agreed: IPP Model and Semantics IPP Security IPP Directory Schema IPP Encoding of Operations All of the above documents should contain transport independent information. We would then need a transfer specific IPP Profile document (on the standards track), that would reference the 4 documents listed above: Profile for running IPP over HTTP 1.1 (this would include some of HTTP specific security protocol recommendations). In addition, we have the two informational documents that are NOT on the standards track: Internet Printing Requirements Mappings between IPP and RFC 1179 We probably do not need to reference these explicitly from the standards track documents? Can I get your reactions on whether these are the right documents to be listed? An alternative that has been discussed is to merge the IPP Encoding of Operations with the Profile for running IPP over HTTP 1.1 document. Do we gain a lot by keeping these as two separate documents? 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 Thu May 22 11:34:38 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA19779 for ipp-outgoing; Thu, 22 May 1997 11:31:43 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 22 May 1997 09:31:30 -0600 From: Scott Isaacson To: ipp@pwg.org, root@truespectra.com Subject: Re: IPP>MOD May 14 MOD meeting Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Rob asks: >>> Administrator 05/21 1:43 PM >>> > On further reflection of some of the discussions and decisions made during > the MOD meeting at StarTech, I believe we may have been too hasty in > deleting the Font parameter requirements and relegating them to the printer > MIB. Fonts are not always a property of the printer and in many cases may be > rendered by the OS or other software. I think that fonts are an installed > capability no different from a stapler attachment, media type, sides, finishing > capabilities and should be specifiable on job submission. Further, specifying > font substitutions is not much different than saying to pint the letter size > document on A4 or legal because thats what is available. > Can we put this back in? Comments? The two attributes are: font-substitutions (setOf setOf font) printer-fonts (setOf font) In the area of fonts, I think the original goal was to be able to query the printer to find out what it had (printer-fonts) or what it would do (font-substitutions) but there were no Job attributes that were associated with the Printer attributes that could take advantage of this information (i.e., there is no "requested-font" Job attribute). All of the interactions between a job, document data, fonts, and the printer would all be done within the PDL. Also, the fonts where just named, not typed. Also, this font information is not "relegated" to the Printer MIB, it is purposefully ignored in the Printer MIB. In light of this idea that as far as fonts are concerned, IPP was only very minimally providing a part of the solution, it seems better to not standardize on a less than half solution, but wait till a more complete solution could be proposed and standardized. In summary: Do these two attributes add a lot of overhead to implement? Probably not. Do they provided some information? Yes. Do they solve the whole problem? Definitely not. Would some implementations be confused and mislead if they implmented these attributes? Yes. The PWG has touched on this for years and has always ignored it or punted wrt to the Printer MIB, so should IPP do the same for right now? Yes. Scott 1.1.1.1 fonts-substitutions (setOf setOf font) This attribute specifies an appropriate substitute for a font that is advertised as supported in the fonts-supported attribute, even though the Printer doesn't actually have the font available. This attribute consists of a set of font pairs: a font name and the font to use instead. If this attribute is unspecified, the Printer does not perform any font substitutions. 1.1.1.2 scheduling-algorithm (type3 keyword, MANDATORY) This attribute indicates the current scheduling algorithm for this Printer. Standard values are: 'none': 'smallest-job-first': 'time-received': 1.1.1.3 printer-fonts (setOf font) This attribute specifies what fonts are available at the Printer or accessible to the Printer. Documents may use these fonts without requiring that the fonts be downloaded with the document data. The standard values are font names. ISSUE: Should the IPP model include all information that is currently contained in printer definition files such as PostScript's printer definition (ppd) files? From ipp-archive Thu May 22 11:44:52 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA20233 for ipp-outgoing; Thu, 22 May 1997 11:43:19 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 22 May 1997 09:42:32 -0600 From: Scott Isaacson To: Robert.Herriot@Eng.Sun.COM, ipp@pwg.org, carterk@us.ibm.com Subject: Re: IPP> MOD - UPDATE FOR STATUS CODE KEYWORDS IN THE MODEL DOCUMENT Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Bob, > 4.4.2.2 successful-attribute-ignored (IPP) > Is this really necessary, especially if the returned attributes indicate > which are unsupported. This is a case of half-full versus half-empty. I thought this was necessary since a Printer could implement the "should" best-effort case and simple ignore some attributes that were not supported. It still prints, the printer is just trying to tell the client some possibly interesting info. > > 4.4.4.6 server-error-write-fault (IPP) > > I would expect the client to block on a write and that it wouldn't > clear until the server got enough space to write the data. But there are cases where the Printer experiences a disk-full condition but still has enough buffer space to return a response packet. I wouldn't get rid of it. > > 4.4.4.7 server-error-too-many-documents-in-job (IPP) > > With the changes from last week where all Printers support PrintJob > (1 document per job) and some support CreateJob/SendJobData (1 or > more documents per job), this message isn't needed. The error > server-error-operation-not-implemented handles this problem instead. > Is there a case where the Printer supports both Print-Job and Create-Job/Send-Job-Data but for some reason has an implementation limit of N documents per job? It would be helpful to have this error code for that case. We have no way (nor do I propose) to query the printer to find out how many multiple docs per job it supports. Scott From ipp-archive Thu May 22 12:34:39 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA21064 for ipp-outgoing; Thu, 22 May 1997 12:29:58 -0400 (EDT) From: jeff@boulder.qms.com (Jeff Copeland) Message-Id: <9705221630.AA07423@boulder.qms.com> Subject: IPP> Microsoft/HP press release on SWP To: ipp@pwg.org Date: Thu, 22 May 1997 10:30:21 -0600 (MDT) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: ipp-owner@pwg.org Precedence: bulk Status: RO can be found at: http://biz.yahoo.com/prnews/97/05/22/adbe_hwp_1.html -- Jeffrey L Copeland +1-303-443-7227 x14 QMS, Inc, Boulder R&D Center fax: +1-303-443-7107 2945-D Center Green Court South jeff@boulder.qms.com Boulder, CO 80301 From ipp-archive Thu May 22 12:59:39 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA21546 for ipp-outgoing; Thu, 22 May 1997 12:58:33 -0400 (EDT) Message-Id: <3.0.1.32.19970522094255.00f383c0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 22 May 1997 09:42:55 PDT To: Larry Masinter From: Carl-Uno Manros Subject: Re: IPP> application/ipp vs. application/print-job Cc: ipp@pwg.org In-Reply-To: <3383916D.6F4@parc.xerox.com> References: <199705212306.TAA25113@uscore.underscore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO At 05:21 PM 5/21/97 PDT, Larry Masinter wrote: >I would assume that "print-job" was a good name for >what it is that you're sending in submitting a job. >Maybe you want some more general way to marshall and >unmarshall an attribute value list, but then there >are lots of those, including application/directory >and multipart/form-data. Then you just need a schema >and a version of the scheme. Right? > >Larry >-- Larry, I think we are discussing past each other in this conversation. One of the parameters for application/ipp is intended to be the actual operation that you want the IPP server to execute. Only one (or possibly two) of these are actually the "print-job" operation. The other operations have to do with getting printer capabilities, finding out status of a job etc. So I think we are looking for for something more generic than "application/print-job". I see the "application/ipp" as a top level label for a number of related operation requests and responses, each describing what the ISO and ITU folks call a "Protocol Data Unit", which can be mapped to several different underlying transfer protocols. Any problems with that? 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 May 22 13:14:39 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA22021 for ipp-outgoing; Thu, 22 May 1997 13:14:21 -0400 (EDT) Message-Id: <3.0.1.32.19970522100840.00f8e2c8@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 22 May 1997 10:08:40 PDT To: Harald.T.Alvestrand@uninett.no From: Carl-Uno Manros Subject: IPP> Re: ADM - IPP Documents for the IETF Cc: ipp@pwg.org, moore@cs.utk.edu, masinter@parc.xerox.com In-Reply-To: <27814.864285395@munken.uninett.no> Illegal-Object: Syntax error in References: value found on alpha.xerox.com: References: ^-illegal end of message identification Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO At 12:16 AM 5/22/97 PDT, Harald.T.Alvestrand@uninett.no wrote: >Carl-Uno, >in your message, you give a total of seven documents: > >IPP Model and Semantics >IPP Security >IPP Directory Schema >IPP Encoding of Operations >Profile for running IPP over HTTP 1.1 >Internet Printing Requirements >Mappings between IPP and RFC 1179 > >At the moment there are 3 internet-drafts in the I-D store: > >draft-ietf-ipp-req-00.txt >draft-ietf-ipp-model-00.txt >draft-ietf-ipp-dir-schema-00.txt > We actually also had one on Security as well, which the IETF secretariat refused to list under IPP, because it was not in the Charter, but I have been over the details about that with Keith earlier. >None of these have been updated since Memphis. You are right, but we have now had sufficiently much discussion and technical contributions for the editors to be able to pull it all together in a series of new drafts. I only wanted to make sure that we have agreement about which documents to produce and make sure that a list of them get into an updated version of the IPP Charter so that we do not run into the same hassle as we had before Memphis. We expect to have a new set of I-Ds ready for IETF publication within the next 2 - 3 weeks. >I really can't tell whether you have the right set of documents >unless you have some documents; the organization of these documents >is in fact less important than their content. I will bear that in mind, but we are to some extent talking hen and egg here. >(And no, PDF-format documents on a non-IETF fileserver are NOT >considered WG documents available for public review!) You may not be following our list and archive, but note that most everything is now supplied in both TXT and PDF formats, both in the FTP archive and on our IPP web pages. >About the HTTP issue: I knew that you would not be happy about this, but it seems to be where the majority of the list members are taking us. >That is Not a Good Thing; you will probably require at least a >document called "Why We Shot Ourselves In The Foot With HTTP" or >equivalent, giving the *engineering* justifications for the choice. I will try to write up the rationale properly before calling for an official IETF consensus on this. Believe or not, I think we are making significant progress. 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 May 22 13:39:40 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA22478 for ipp-outgoing; Thu, 22 May 1997 13:35:03 -0400 (EDT) Message-ID: <338483E9.A2F1E28E@sharplabs.com> Date: Thu, 22 May 1997 10:35:37 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.0b4 [en] (WinNT; I) MIME-Version: 1.0 To: Scott Isaacson CC: Robert.Herriot@Eng.Sun.COM, ipp@pwg.org, carterk@us.ibm.com Subject: Re: IPP> MOD - UPDATE FOR STATUS CODE KEYWORDS IN THE MODEL DOCUMENT X-Priority: 3 (Normal) References: Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Scott Isaacson wrote: ..snip..snip.. > > > > 4.4.4.7 server-error-too-many-documents-in-job (IPP) > > > > With the changes from last week where all Printers support PrintJob > > > (1 document per job) and some support CreateJob/SendJobData (1 or > > more documents per job), this message isn't needed. The error > > server-error-operation-not-implemented handles this problem > instead. > > > > Is there a case where the Printer supports both Print-Job and > Create-Job/Send-Job-Data but for some reason has an implementation > limit of > N documents per job? It would be helpful to have this error code for > that > case. We have no way (nor do I propose) to query the printer to find > out > how many multiple docs per job it supports. I cannot imagine a case where "too many documents per job" would be used. If there are too many documents in a single job, chances are the spooler (or whatever) decided that the job was just too big to handle (disk full, resource allocation error, whatever) to handle the job. I don't think it has anything to do with documents, IMHO. Randy > Scott > > > > > > > > > > > > > > > > > > > > > > > > > > > From ipp-archive Thu May 22 14:24:40 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA23009 for ipp-outgoing; Thu, 22 May 1997 14:20:30 -0400 (EDT) Message-Id: <199705221821.OAA04147@devnix.agranat.com> To: ipp@pwg.org Subject: Re: IPP> application/ipp vs. application/print-job In-reply-to: <3.0.1.32.19970522094255.00f383c0@garfield> Date: Thu, 22 May 1997 14:21:13 -0400 From: "Scott Lawrence" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO At 05:21 PM 5/21/97 PDT, Larry Masinter wrote: LM> I would assume that "print-job" was a good name for LM> what it is that you're sending in submitting a job. >>>>> "CM" == Carl-Uno Manros writes: CM> One of the parameters for application/ipp is intended to be the actual CM> operation that you want the IPP server to execute. [...] So I CM> think we are looking for for something more generic than CM> "application/print-job". CM> I see the "application/ipp" as a top level label for a number of related CM> operation requests and responses [...] I agree with Larrys original comment that 'application/ipp' is both redundant and not very descriptive. From your response, I would agree that 'application/print-operation' would be much better. -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-archive Thu May 22 15:59:41 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA23547 for ipp-outgoing; Thu, 22 May 1997 15:55:13 -0400 (EDT) Message-Id: <3.0.1.32.19970522124946.00f8e3d8@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 22 May 1997 12:49:46 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> Munich PING Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I sent out a PING for Munich a few weeks ago. I have only got a few responses. Here is my current list: Munich PING Lee Farrell Canon Robert Herriot Sun Scott Isaacson Novell Carl-Uno Manros Xerox Steve Zilles Adobe As we expect to have a number of documents up for review in Munich, it would feel more comfortable if there we some more attendants from the IPP team. If you are planning to go, I urge you to make your bookings now. August is tourist season in Germany, so both flights and hotels are filling up. Please let me know if you will be going. 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 Thu May 22 16:54:43 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA24046 for ipp-outgoing; Thu, 22 May 1997 16:50:22 -0400 (EDT) Date: Thu, 22 May 1997 13:52:13 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705222052.NAA26846@woden.eng.sun.com> To: ipp@pwg.org Subject: Re: IPP>PRO change of date for face-to-face meeting X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO June 10 and 11 didn't work out for the face-to-face meeting. Please let me know if you can come to a face-to-face meeting for the IPP protocol (transport and encoding) in the San Francisco Bay Area on either Tuesday June 17 or Wednesday June 18. There may be the same preference as before for Tuesday to avoid conflict with the regular IPP Wed. teleconference. Bob Herriot From ipp-archive Thu May 22 17:49:43 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA24854 for ipp-outgoing; Thu, 22 May 1997 17:49:17 -0400 (EDT) Date: Thu, 22 May 1997 14:51:08 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705222151.OAA27397@woden.eng.sun.com> To: ipp@pwg.org, SISAACSON@novell.com, hastings@cp10.es.xerox.com Subject: Re: IPP> MOD - 5/14 mintues X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > From hastings@cp10.es.xerox.com Wed May 21 21:42:58 1997 > > > Why can't we specify UTF8 (not Unicode) in the Model document as the > coded character set for values? Then we avoid a lot of messy coded > character set mapping rules in the encoding and protocol documents. > Believe me coded character set mapping is very hard! Most character sets > don't have all the same characters, and/or have over lapping characters. > Lets avoid character set mapping altogether in our documents. > We specify USASCII for the attribute name keywords in the model document, > why not specify UTF8 as well (and follow the recommendations of the IETF here). It is the duty of the encoding to specify the encoding. In the model, we could say any character in Unicode and in the encoding document we could specify the UTF-8 encoding of the Unicode characters. But in any case, unless a server supports the entire Unicode character set, something gets dropped somewhere, and if the server uses some other encoding, it has to convert at some point and drop whatever characters the new encoding doesn't support. So, I am still not sure that all implementations will want to restrict the protocol to UTF-8 only. I could see a Japanese site choosing EUC or SJIS to avoid the conversion overhead. It's nice and simple to pick Unicode and UTF-8, but I don't think it is realistic until Unicode is more pervasive. > > 17. We had a 3 hour discussion on best-effort. The final > > proposal was to do away with any notion of "substitute" > > values when there is a conflict between what is requested > > and what is supported. The expectation is that if a client > > specifies something and it is not supported, return an error > > so that the client can query what is supported. best-effort > > will now apply to only conflicts between IPP attributes and > > what is in the document stream (PDL) itself. Proposed > > values are: SHALL_HONOR_IPP_ATTR (IPP attribute values take > > precedence over PDL instructions), SHOULD_HONOR_IPP_ATTR > > (same as SHALL with no guarantees), and > > NEED_NOT_HONOR_IPP_ATTR (PDL takes precedence over IPP > > attributes). We dropped NEED_NOT_HONOR_IPP_ATTR because it was the case where a client could ask for an attribute that the Printer doesn't support. Both the SHALL_HONOR_IPP_ATTR and SHOULD_HONOR_IPP_ATTR provide for a precedence of IPP > embedded and embedded > Printer-default. The distinction was on probability of success. > > > > 19. When a Job object is created only supplied attributes > > will be copied from the request into the Job object. In > > order to determine the defaults that will be applied, query > > the Printer Job Template attributes to get defaults. > > We need to clarify in the above that: > The Printer object applies the default values when there is no value supplied > by either the client in the IPP protocol or by the document in the PDL. > Presumably when the Printer object applies the defaults is implementation > dependent. Some implementations for some attributes may scan the PDL at job > submission time, shortly thereafter, or just before processing. Some > implementations may wait until during interpretation of the PDL. Some > implementations may set the output device to the default values just prior > to sending the document PDL to the output device. If the PDL changes the > output device, the PDL overrode the defaults. I think we would specify expected behavior rather that possible implementations. > I think that we did not agree to add "time-since-processing" on the grounds > that that is an attribute in the Job Monitoring MIB for accounting and > system utilization, so we didn't need to add it to IPP, since IPP isn't > for accounting and utilization analysis. I thought we did agree to have a 'time-since' for each state attribute. Though I think that we also agreed that the clock for such a time stopped when the job moved to the next state. So the name should be time-, that is: time-pending (i.e. time that the job was in the pending state), time-processing, time-completed, time-aborted, time-canceled. > My notes said the units were milliseconds. But wouldn't seconds be > sufficient? We picked milliseconds so that a server with many jobs arriving at subsecond intervals could distinguish order. > > > > 7. Define SHALL and SHOULD get rid of NEED_NOT > > Who: Scott > > Why get rid of "need not"? It needed when the standard has to say that an > implementor does not need to do something. Its too confusing to say > "may not", since it sounds like a prohibition, rather than a relaxation > of requirements. POSIX and ISO standards are quite clear on this terminology. See my comment above for why to get rid of "need not". > > From ipp-archive Thu May 22 18:14:43 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA25480 for ipp-outgoing; Thu, 22 May 1997 18:11:38 -0400 (EDT) Date: Thu, 22 May 1997 15:13:20 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705222213.PAA28027@woden.eng.sun.com> To: carterk@us.ibm.com, masinter@parc.xerox.com Subject: Re: IPP> MOD - IPP Versioning Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > From masinter@parc.xerox.com Wed May 21 22:53:38 1997 > > The HTTP/1.1 versioning language is a very poor model to > follow. It's been so troublesome that we had to issue > a separate Internet Draft (now to become an RFC) to clarify > the issue of use of version numbers between multiple > version clients and servers. > > Given this history, I don't recommend using it in IPP. > Are you suggesting that not include a version number in the protocol? Please say more about what the problem is. We currently have the problem in lpr that there is no version number and that has made extensions more difficult. Bob Herriot From ipp-archive Thu May 22 18:19:47 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA25497 for ipp-outgoing; Thu, 22 May 1997 18:15:37 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 22 May 1997 16:15:24 -0600 From: Scott Isaacson To: Robert.Herriot@Eng.Sun.COM, ipp@pwg.org Subject: Re: IPP>PRO change of date for face-to-face meeting Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I am unable to attend any time the week of 6/16-6/20. Scott >>> Robert Herriot 05/22 2:52 PM >>> June 10 and 11 didn't work out for the face-to-face meeting. Please let me know if you can come to a face-to-face meeting for the IPP protocol (transport and encoding) in the San Francisco Bay Area on either Tuesday June 17 or Wednesday June 18. There may be the same preference as before for Tuesday to avoid conflict with the regular IPP Wed. teleconference. Bob Herriot From ipp-archive Thu May 22 18:29:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA26397 for ipp-outgoing; Thu, 22 May 1997 18:26:23 -0400 (EDT) Date: Thu, 22 May 1997 15:28:12 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705222228.PAA28168@woden.eng.sun.com> To: ipp@pwg.org Subject: Re: IPP> MOD - UPDATE FOR STATUS CODE KEYWORDS IN THE MODEL DOCUMENT X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > From SISAACSON@novell.com Thu May 22 08:45:15 1997 > > Bob, > > > 4.4.2.2 successful-attribute-ignored (IPP) > > Is this really necessary, especially if the returned attributes indicate > > which are unsupported. This is a case of half-full versus half-empty. > > I thought this was necessary since a Printer could implement the "should" > best-effort case and simple ignore some attributes that were not supported. > It still prints, the printer is just trying to tell the client some possibly > interesting info. No, this was for GetAttributes and GetJobs which should report OK and return unsupported attributes with a value of 'unsupported'. In the case of print submission with "should-honor-attributes", the server hopes it can honor, but it doesn't know what it will fail on. > > > > > 4.4.4.6 server-error-write-fault (IPP) > > > > I would expect the client to block on a write and that it wouldn't > > clear until the server got enough space to write the data. > > But there are cases where the Printer experiences a disk-full condition but > still has enough buffer space to return a response packet. I wouldn't get > rid of it. Maybe once we have the protocol better defined we will know whether this is a possibility, but I would expect the printer wait for the disk-full condition to go away. Then it would write the data and return a response of success. If it returns this message instead, then the client has to go into some recovery mode which makes the client more complicated. > > > > > > > 4.4.4.7 server-error-too-many-documents-in-job (IPP) > > > > With the changes from last week where all Printers support PrintJob > > (1 document per job) and some support CreateJob/SendJobData (1 or > > more documents per job), this message isn't needed. The error > > server-error-operation-not-implemented handles this problem instead. > > > > Is there a case where the Printer supports both Print-Job and > Create-Job/Send-Job-Data but for some reason has an implementation limit of > N documents per job? It would be helpful to have this error code for that > case. We have no way (nor do I propose) to query the printer to find out > how many multiple docs per job it supports. > The PrintJob has a limit of one document. CreateJob/SendJobData should have no job limit. It may have an octet-limit for an entire job. From ipp-archive Thu May 22 18:39:45 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA26860 for ipp-outgoing; Thu, 22 May 1997 18:35:58 -0400 (EDT) Message-Id: <3.0.1.32.19970522153051.00fb0008@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 22 May 1997 15:30:51 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC - PWG Phone Conference - May 22, 1997 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO PWG IPP Security Phone Conference - May 22, 1997 This is a short report about what was discussed at today's teleconference. Attending: Roger deBry Jerry Hadsell Scott Isaacson Carl-Uno Manros John Wenn Daniel Manchala Xavier Riley Document structure It was generally recognized that some of text parts need better integration and flow. Almost all of the current text is general in nature and it was decided that any direct recommendations about use of particular security protocols should go into the document mapping IPP to a particular transfer protocol. We should probably remove some of the threats and risks that we are not planning to cover in version 1.0 of IPP. We should also either explain security terms as they get introduced in the document or put in a terminlogy section early on in the document. Jerry Hadsell offered to come up with suggestions for a terminolgy section. It was also discussed whether the document should be informational rather than a standards track document considering that it is unlikely to include any new protocol components, but rather analysis how existing security protocols can be used in combination with IPP. Carl-Uno suggested that we seek advice on this after we have the new version of the document completed. Directory We then discussed what informatio about security might be needed in the Directory Schema. We did not reach agreements on that, but outlined different solutions which were: - Keep it very simple, only a binary value - Describe which kind of security services are described as several attributes - Define which security protocols are supported It was also pointed out that in some caes, like with TLS, the URI would actually be different, which means that a printer that supports both secure and non-secure printing, might have two separate directory entries. Would there be a point in having a reference attribute to point between the two in this case? It was also pointed out that the directory access control may prevent users from even seeing a printer to which they have no access in the directory. We must be able to find enough information in the directory to allow a session between a user and a "secure" Printer to be be boot strapped correctly. We might have a certain overlap with SASL if we start putting up a number of attributes in the directory (or in the Printer object), but in the case of using HTTP this does not seem to have any impact. Other subjects It was felt that we need to create some additional text on how the use of firewalls effects the IPP. Daniel Manchala will provide some additional text. John Wenn also offered that he should write up something on IP SEC in TCP/IP and how that can be used in combination with RFC 2069 security features. Roger deBry will produce a revised version of what we presently have for review in next week's phone conference. All new input to be sent to Roger by Tuesday morning, May 27. The plan is to have a new I-D text to send to the IETF in two weeks time. Next week's phone conference will be held at the same time next Thursday. Carl-Uno will not be able to attend next week, so Roger deBry will lead the conference next 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 Thu May 22 18:54:43 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA27628 for ipp-outgoing; Thu, 22 May 1997 18:53:35 -0400 (EDT) Message-Id: <3.0.1.32.19970522154841.00fb0008@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 22 May 1997 15:48:41 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> DIR - Comments from an X.500/LDAP specialist Cc: frode.hernes@maxware.telemax.no Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO IPPers, I am forwarding the following message from Frode Hernes, an old friend and almost fellow countryman, who has looked at our current I-D for Directory Schema. I think you will find a number of useful and constructive comments in his text. Thanks Frode. Regards, Carl-Uno --- I have just browsed through the IPP Directory draft, and as an author of one general DAP browser (http://www.maxware.com/downloads/demo) I have some comments. First, the URL: Using Windows, I trust that applications register the URIs they can handle, Netscap register ftp:// and http://, our Directory Browser register LDAP:// etc. I would like my Internet Printing application to register IPP:// so that Windows can hand it all print jobs. Then, the directory part: 1. Some of the attributes are 'structured' e.g the Location attribute specifies a sub-syntax for various pieces of information within a string attribute. This has several problems: - It looks ugly in a general browser - It is almost impossible to translate the lead-ins for other languages (unless the lead-ins are well defined, and in that case, why not use separate attributes ?) - It is hard to update and keep track of. So, I would reccoment separate attributes for separate pieces of information. 2. Single valus / Multi value. This is not explicitly said (or I did not see it), but I would recommend that a printer object contains multi-value capability attributes, so that the color attribute contains all the color schemes the printer support etc. This makes it fairly easy to search based on capabilities. 3. Enumerations. I have mixed emotions towards using string-enumerations like "two-sided" or "four colors". On one hand, they are easy to read in english, but on the other hand: - They must be translated for most of the people in the world - They are easy to mis-spell, making it hard for an application to trust them If instead, numeric codes are defined, it will look more cryptic to an end user (the DUA or application will need a table), but they will always be correctly spelled, and the need for translation is obvious. Specific attributes: Many of the attributes references the attributes to the Job object, but I cannot find this object defined. Also, if a Job contains actual parameters, following the same syntax / semantics as an attribute (multi-value) of a Printer, the same attribute name and OID should be used (but single-valued on the Job (?)) Name: The name in the directory should be a CommonName The attribute LabeledURL can be used to hold the printers URL, or a separate attribute PrinterURL can be defined (with the URL syntax from LabeledURL) Location: Most of the suggested information already exists as possible attributes in PilotPerson (room, floor, locality...) I would suggest individual attributes. Color supported: multi-value, enumeration ? DeviceID: If this can be used for PlugAndPlay IDs why not make an attribute we can trust to contain a PlugAndPlay ID if it exists ? Make/model: I would prefer two attributes: Vendor and Model, maybe also 'revision' or 'sub-model' ? Sides-supported: again, split in 1 / 2 and a new attribute Portrait/Landscape ? And yes, you need to define a STRUCTURAL object Class printer with a new OID. It should probably be a subclass of device. Then BNF for the attributes, and assigned OIDs are more important than the API used to initialize the object. As for security, the IETF-ASID group is just now specifying to how to use TLS with LDAP (a one port solution), this may be suited for IPP. Good luck! Frode - - - - - - - - - - - - - Frode Hernes MaXware 12614 Builders Road Herndon, VA 20170 Tel:(703) 435 2587 Mobile:(703) 919 5166 Fax:1 (800) 355 2071 X.400:g=Frode;s=Hernes;o=MaXware;a=Telemax;c=No Mailto:frode.hernes@maxware.telemax.no MaXware A.S: mailto:maxware@maxware.no http://www.maxware.no --- 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 May 22 19:59:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA28588 for ipp-outgoing; Thu, 22 May 1997 19:54:48 -0400 (EDT) From: Harry Lewis To: Subject: IPP> application/ipp vs. application/print-job Message-Id: <5030100002767260000002L002*@MHS> Date: Thu, 22 May 1997 19:56:50 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Larry wrote: >I'm dissatisfied with "application/ipp" as the name for the >Internet media type registration, because it's somewhat >redundant (i = internet in an internet protocol) and misdirected >(the content is not a 'protocol', it's a description of a >print job used in one protocol but useful possibly in others). >So I suggest renaming it: application/print-job. That is, >an 'application/print-job' is a description of a job that the >sender wants the recipient to print. Then I'd just call it "application/print". Harry Lewis - IBM Printing Systems From ipp-archive Thu May 22 20:09:45 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA29063 for ipp-outgoing; Thu, 22 May 1997 20:07:25 -0400 (EDT) Message-ID: <3384E0DE.19C6@sharplabs.com> Date: Thu, 22 May 1997 17:12:14 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Laboratories of America X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> application/ipp vs. application/print-job References: <5030100002767260000002L002*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO The label "application/ipp" was meant to denote that this entity body was to be handled by an IPP application. Which is the reason for using the media type "application" and the subtype "ipp". Whether or not we are using the MIME type according to the strict definition for using a particular media type may be in question, but the rationale is sound and it just seemed like a good fit; i.e., we wanted this entity type to be processed by an "application" that knows about "ipp". Randy From ipp-archive Thu May 22 20:09:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA29052 for ipp-outgoing; Thu, 22 May 1997 20:07:15 -0400 (EDT) From: Harry Lewis To: Subject: Re: IPP> Protocol encoding addition... Message-Id: <5030100002767796000002L062*@MHS> Date: Thu, 22 May 1997 20:09:16 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO In the job MIB spec we have defined jmJobSubmissionID formats which could serve the same pourpose as these transaction ID's. >I would like to propose an additional encoding field that would be >included in the application/IPP body for IPP requests. This additional >field would be a "transaction identifier" field. IPP clients would generate >a unique transaction identifier to be included with each request. >How unique does the identifier has to be? By client, by server, or >globally? Here is an excerpt from the MIB: The value of jmJobSubmissionIDIndex should be one of the registered format types. The first two octets of the string shall indicate which registered format is being used. The agent shall assign a string of registered format (00) for any job without a Job Submission ID. The format values registered so far are: Format Number Description ------ ------------ 00 Set by the agent when neither the client nor the server assigned a job submission ID. 01 octets 3-10: 8-decimal-digit random number octets 11-32: last 22 bytes of the jobName attribute 02 octets 3-10: 8-decimal-digit sequential number octets 11-32: Client MAC address 03 octets 3-10: 8-decimal-digit sequential number octets 11-32: last 22 bytes of the client URL .. to be registered according to procedures of a type 2 enum. See section 7.3 on page 18. NOTE - the job submission id is only intended to be unique between a limited set of clients for a limited duration of time, namely, for the life time of the job in the context of the server or device that is processing the job. Some of the formats include something that is unique per client and a random number so that the same job submitted by the same client will have a different job submission id. For other formats, where part of the id is guaranteed to be unique for each client, such as the MAC address or URL, a sequential number should suffice for each client (and may be easier for each client to manage). Therefore, the length of the job submission id has been selected to reduce the probability of collision to a very low number, but is not intended to be an absolute guarantee of uniqueness. Harry Lewis - IBM Printing Systems From ipp-archive Fri May 23 03:19:48 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA01181 for ipp-outgoing; Fri, 23 May 1997 03:15:51 -0400 (EDT) Message-Id: <199705230720.QAA14139@fuji.mol.minolta.co.jp> Date: Fri, 23 May 1997 16:15:40 +0900 To: Scott Isaacson , ipp@pwg.org From: kita@mol.minolta.co.jp (Yasunari Kitagaki) X-Sender: kita@fuji.mol.minolta.co.jp Subject: Re: IPP>DIR OID and string attribute Cc: kita@mol.minolta.oc.jp MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-Mailer: Eudora-J(1.3.8-J13) Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I can understand the situation of directory issues. >3. I have assumed that the intent of the directory document is to also >define the schema in terms of attributes identified only with "keywords" >These keywords could then be mapped to any real represention in a specific >directory protocol. It looks like you have done the correct mapping from >IPP directory schema attributes to LDPAString for use in the on-the-wire >protocol. Only "keyword" schema indentitication seems good for current LDAP implememtation. As Michigam and Netscape implementation uses a few attributes OID identification and the others are string identification. Attribute systax is only string, this would be OK, but schema level should have OID assigning for the other or future directory services. Yas -------------------------------------------------------- Yasunari Kitagaki Network Engneer-Systems Development Center-Minolta Co., Ltd. e-mail:kita@mol.minolta.co.jp Tel:+81-726-85-6184 FAX:+81-726-85-6185 1-2, Sakura-Machi, Takatsuki-Shi, Osaka 569, Japan From ipp-archive Fri May 23 03:19:49 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA01194 for ipp-outgoing; Fri, 23 May 1997 03:16:27 -0400 (EDT) Message-Id: <199705230720.QAA14144@fuji.mol.minolta.co.jp> Date: Fri, 23 May 1997 16:15:48 +0900 To: ipp@pwg.org From: kita@mol.minolta.co.jp (Yasunari Kitagaki) X-Sender: kita@fuji.mol.minolta.co.jp Subject: Re: IPP> DIR Cc: frode.hernes@maxware.telemax.no MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-Mailer: Eudora-J(1.3.8-J13) Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I have some comments. >First, the URL: > >Using Windows, I trust that applications register the URIs they can handle, >Netscap register ftp:// and http://, our Directory Browser register LDAP:// >etc. >I would like my Internet Printing application to register IPP:// so that >Windows can hand it all print jobs. > First I address the proxy/firewall problem. Most current proxy/firewall have no knowlege of the "IPP" sheme. To print over firewall, "ipp://" not practical. >And yes, you need to define a STRUCTURAL object Class printer with a new >OID. It should probably be a subclass of device. > >Then BNF for the attributes, and assigned OIDs are more important than the >API used to initialize the object. > I agree this point. But attribute syntax should be simple for simple implementation, I think. >As for security, the IETF-ASID group is just now specifying to how to use >TLS with LDAP (a one port solution), this may be suited for IPP. IETF-ASID group is specifying the LDAP v3 related topic. Current version of LDAP does't need to assign OID, but from v3 draft, I guess assigning OID is requred. X.500/LDAP mapping should work with IETF-ASID group. Yas -------------------------------------------------------- Yasunari Kitagaki Network Engneer-Systems Development Center-Minolta Co., Ltd. e-mail:kita@mol.minolta.co.jp Tel:+81-726-85-6184 FAX:+81-726-85-6185 1-2, Sakura-Machi, Takatsuki-Shi, Osaka 569, Japan From ipp-archive Fri May 23 09:09:52 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA02345 for ipp-outgoing; Fri, 23 May 1997 09:04:59 -0400 (EDT) X400-Received: by /c=no/admd=telemax/prmd=internet/; converted ( (1)(0)(10021)(7)(1)(0)(6)(1), (1)(0)(10021)(7)(1)(0)(6)(6), (1)(0)(10021)(7)(1)(0)(6)(100), (2)(6)(1)(4)(11)); Relayed; 23 May 1997 15:04:35 +0200 X400-Received: by /c=NO/admd=TELEMAX/; Relayed; 23 May 1997 13:03:22 Z X400-Received: by mta MHNORWAY in /c=no/admd=telemax/prmd=internet/; converted ( (1)(0)(10021)(7)(1)(0)(6)(1), (1)(0)(10021)(7)(1)(0)(6)(6), (1)(0)(10021)(7)(1)(0)(6)(100), (2)(6)(1)(4)(11)); Relayed; 23 May 1997 15:04:35 +0200 X400-MTS-Identifier: [/c=NO/admd=TELEMAX/; NORWAYII R0000000864392600073] Content-Identifier: 55956 97/05/23 Content-Return: Prohibited X400-Content-Type: P2-1984 ( 2 ) Conversion: Allowed Original-Encoded-Information-Types: Teletex Priority: normal Disclose-Recipients: Prohibited Alternate-Recipient: Allowed X400-Originator: frode.hernes@maxware.telemax.no X400-Recipients: non-disclosure; Message-Id: <"55956 97/05/23*/c=no/admd=telemax/prmd=/o=maxware/s=hernes/g=frode/"@MHS> In-Reply-To: <199705230720.QAA14144@fuji.mol.minolta.co.jp> Date: 23 May 1997 13:03:22 Z From: "Frode Hernes" To: "(Yasunari Kitagaki)" (Receipt notification requested), ipp@pwg.org (Receipt notification requested) Subject: Re: IPP> DIR MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Hi, > > > >Using Windows, I trust that applications register the URIs they can ha= ndle, > >Netscap register ftp:// and http://, our Directory Browser register LD= AP:// > >etc. = > >I would like my Internet Printing application to register IPP:// so th= at > >Windows can hand it all print jobs. > > > First I address the proxy/firewall problem. Most current proxy/firewall= > have no knowlege of the "IPP" sheme. = > To print over firewall, "ipp://" not practical. > = It should be easy to enable another protocol through the firewall (using = another port), an = intelligent firewall may descide to block printing anyhow, because the ac= tual protocol used = is ipp, not http. If the ipp protocol is as successful as I expect it to = be, most firewalls will come = pre-configured to handle this anyway. Frode. - - - - - - - - - - - - - Frode Hernes MaXware 12614 Builders Road Herndon, VA 20170 Tel:(703) 435 2587 Mobile:(703) 919 5166 Fax:1 (800) 355 2071 X.400:g=3DFrode;s=3DHernes;o=3DMaXware;a=3DTelemax;c=3DNo Mailto:frode.hernes@maxware.telemax.no MaXware A.S: mailto:maxware@maxware.no http://www.maxware.no From ipp-archive Fri May 23 10:54:53 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA03042 for ipp-outgoing; Fri, 23 May 1997 10:54:48 -0400 (EDT) From: robk@truespectra.com (Rob Kline) To: ipp@pwg.org (ipp) Message-ID: <1997May23.085652.1896.45660@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, 23 May 1997 10:59:35 -0400 Subject: Re: IPP>MOD May 14 MOD meeting Sender: ipp-owner@pwg.org Precedence: bulk Status: RO While I agree that what was proposed may not be a complete solution to the = font problem, I do believe that it is still useful. Given that we have now = come up with a nicer way to negotiate paramenters for clients before the job= = is submitted, this will allow applications to offer a better interface than = = just lobbing the fully processed PDF for the server to reject. It's also = possible that the fonts may be available on the client and some prerendering= = may be done or the fonts may be sent to the server in some other (legal) way= . = Please remember that postscript is not the only model for descibing print da= ta. The question is then: why are there some job template attributes such as = sides, number up, finishing, that can also be specified in the PDL included= = in the model, and fonts are not? It seems to me that fonts are rather = fundamental, and that we should provide at least basic support in the model= , = rather than to put it off until someone else can solve the problem completel= y. Rob Kline robk@truespectra.com Scott Isaacson = 22/05/97 12:59 PM To: ipp @ Internet, Administrator cc: = Subject: Re: IPP>MOD May 14 MOD meeting Rob asks: >>> Administrator 05/21 1:43 PM >>> > On further reflection of some of the discussions and decisions made durin= g > the MOD meeting at StarTech, I believe we may have been too hasty in = > deleting the Font parameter requirements and relegating them to the printer = > MIB. Fonts are not always a property of the printer and in many cases may be = > rendered by the OS or other software. I think that fonts are an installed = = > capability no different from a stapler attachment, media type, sides, finishing = > capabilities and should be specifiable on job submission. Further, specifying = > font substitutions is not much different than saying to pint the letter size = > document on A4 or legal because thats what is available. = > Can we put this back in? Comments? The two attributes are: font-substitutions (setOf setOf font) printer-fonts (setOf font) In the area of fonts, I think the original goal was to be able to query the= printer to find out what it had (printer-fonts) or what it would do (font-substitutions) but there were no Job attributes that were associated with the Printer attributes that could take advantage of this information (i.e., there is no "requested-font" Job attribute). All of the interaction= s between a job, document data, fonts, and the printer would all be done within the PDL. Also, the fonts where just named, not typed. Also, this font information is not "relegated" to the Printer MIB, it is purposefully ignored in the Printer MIB. In light of this idea that as far as fonts are concerned, IPP was only very= minimally providing a part of the solution, it seems better to not standardize on a less than half solution, but wait till a more complete solution could be proposed and standardized. In summary: Do these two attributes add a lot of overhead to implement? Probably not. Do they provided some information? Yes. Do they solve the whole problem? Definitely not. Would some implementations be confused and= mislead if they implmented these attributes? Yes. The PWG has touched on this for years and has always ignored it or punted wrt to the Printer MIB, so should IPP do the same for right now? Yes. Scott 1.1.1.1 fonts-substitutions (setOf setOf font) This attribute specifies an appropriate substitute for a font that is advertised as supported in the fonts-supported attribute, even though the Printer doesn't actually have the font available. This attribute consists of a set of font pairs: a font name and the font to= use instead. If this attribute is unspecified, the Printer does not perform any font substitutions. 1.1.1.2 scheduling-algorithm (type3 keyword, MANDATORY) This attribute indicates the current scheduling algorithm for this Printer= From ipp-archive Fri May 23 12:29:54 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA03731 for ipp-outgoing; Fri, 23 May 1997 12:27:51 -0400 (EDT) Date: Fri, 23 May 1997 12:28:00 -0400 (EDT) From: JK Martin Message-Id: <199705231628.MAA09924@uscore.underscore.com> To: frode.hernes@maxware.telemax.no Subject: IPP> PRO - Using a new scheme for IPP protocol handling Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Frode, You raise a very interesting point here: > > >Using Windows, I trust that applications register the URIs they can hand= > le, > > >Netscap register ftp:// and http://, our Directory Browser register LDAP= > :// > > >etc. > > >I would like my Internet Printing application to register IPP:// so that > > >Windows can hand it all print jobs. > > > > > First I address the proxy/firewall problem. Most current proxy/firewall > > have no knowlege of the "IPP" sheme. > > To print over firewall, "ipp://" not practical. > > It should be easy to enable another protocol through the firewall > (using another port), an intelligent firewall may descide to block > printing anyhow, because the actual protocol used is ipp, not http. If > the ipp protocol is as successful as I expect it to be, most firewalls > will come pre-configured to handle this anyway. Paul Moore (Microsoft) stated in the San Diego IPP Protocol meeting that he firmly believes that a totally new protocol should be developed if we _really_ want to provide a higher level of network printing capability. He then went on to say (in my words) that if the IPP group really insists on using HTTP for job submission, then fine, just keep it very, very simple (hence, the SWP proposal from Microsoft/HP). I agree with Paul entirely, that a new protocol is necessary to provide the kinds of capabilities we all envision for using and managing network printing services. I had hoped the IPP group would have chosen a path whereby a new protocol would be developed, then mapped to a new URI scheme that would be supported by future versions of web browsers, etc. If the IPP effort is really going to take hold in the general marketplace (and I believe everyone in the IPP believes this is true), then why wouldn't the web browser vendors (and firewall vendors, etc) immediately adopt support for such a new scheme? Just some thoughts. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-archive Fri May 23 15:39:56 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA04654 for ipp-outgoing; Fri, 23 May 1997 15:39:51 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 23 May 1997 13:39:31 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - new attribute table Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I had posted a table showing the relationship of job-template attributes and a proposal for which were mandatory. Tom has taken that and fixed it up to match up with the agreements from the last model meetings. I have posted a txt and a pdf version ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/attr-05.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/attr-05f.txt This is a quick look summary of what will be in the next mod document. I also plan to include the actual table itself in the mod document. Scott From ipp-archive Fri May 23 15:45:03 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA04676 for ipp-outgoing; Fri, 23 May 1997 15:40:09 -0400 (EDT) Message-Id: <9705231939.AA10103@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, 23 May 1997 12:37:31 PDT To: ipp@pwg.org, rturner@sharplabs.com From: Tom Hastings Subject: Re: IPP> MOD - UPDATE FOR STATUS CODE KEYWORDS IN THE MODELDOCUMENT [spool-space-full] Cc: Scott Isaacson , Robert.Herriot@eng.sun.com, carterk@us.ibm.com Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I agree with Randy, that there is no need for a limit on the number of documents for a level 2 implementations (that shall implement CreateJob/SendDocument). In fact, we should make it clear that a conforming level 2 implementation shall accept multiple documents, one with each SendDocument. The only error status codes we need is for the case of when total size of the document data for the job as specified by site policy. Tom At 10:35 05/22/97 PDT, Randy Turner wrote: >Scott Isaacson wrote: > >..snip..snip.. > >> > >> > 4.4.4.7 server-error-too-many-documents-in-job (IPP) >> > >> > With the changes from last week where all Printers support PrintJob >> >> > (1 document per job) and some support CreateJob/SendJobData (1 or >> > more documents per job), this message isn't needed. The error >> > server-error-operation-not-implemented handles this problem >> instead. >> > >> >> Is there a case where the Printer supports both Print-Job and >> Create-Job/Send-Job-Data but for some reason has an implementation >> limit of >> N documents per job? It would be helpful to have this error code for >> that >> case. We have no way (nor do I propose) to query the printer to find >> out >> how many multiple docs per job it supports. > >I cannot imagine a case where "too many documents per job" would be >used. If >there are too many documents in a single job, chances are the spooler >(or whatever) >decided that the job was just too big to handle (disk full, resource >allocation error, whatever) >to handle the job. I don't think it has anything to do with documents, >IMHO. > >Randy > >> Scott >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > > > From ipp-archive Fri May 23 15:45:05 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA04709 for ipp-outgoing; Fri, 23 May 1997 15:40:45 -0400 (EDT) Message-Id: <9705231940.AB10103@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, 23 May 1997 12:37:54 PDT To: ipp@pwg.org, jmp@pwg.org, bwagner@digprod.com (Bill Wagner) From: Tom Hastings Subject: Re: IPP> MOD - simplified legal state transition diagram [unknown] Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Bill, I think you are right, that the 'unknown' job state should be used only when the agent doesn't know about the state of the job that exists. When the job doesn't exist anymore (or before the job exists) is not really a job state at all. I think that this problem can be easily fixed by changing the heading on the column from 'unknown' to something like , ok? Tom At 14:02 05/21/97 PDT, Bill Wagner wrote: >I apologize if I missed a step or two in this exchange. Of course, I agree >with the objective and believe the states listed are adequate. However, the >'unknown' state, within general MIB use at least, has been more a >reflection on the state of the equipment than the job. That is, the state >of a job is unknown because of some sensing difficulty or sequence >difficulty with the equipment, not because it is a normal state in the >sequence of handling a job. > >It would be quite possible for a unit to report no state other than >unknown. It seems it would also be possible for a unit to recognize a state >after it has previously been unknown. For example, if a job can be >identified, it can be canceled and the state is then likely to be canceled >and not unknown. In short, I suggest that unknown is a wild card rather >than a job state that exists before pending and processing and after >canceled and completed. > >If something is necessary for the pre-pending and post complete states, >what about Other? > >Bill Wagner, Osicom/DPI > > >______________________________ Reply Separator _________________________________ >Subject: IPP> MOD - simplified legal state transition diagram >Author: Tom Hastings at Internet >Date: 5/21/97 7:29 AM > > >So the simplified legal state transition diagram for IPP and JMP would become, >following Bob's proposal: > > New state >Old state unknown(2) pending(3) processing(4) canceled(5) completed(6) >unknown(2) yes yes >pending(3) yes yes >processing(4) yes yes yes >canceled(5) yes >completed(6) yes > >A blank entry indicates impossible transitions. Self loops are not >indicated, such as a Get-Attributes operation on a job, since they aren't >a job state transition. > >For IPP we need to consider which job states and job state transtions are >required for conformance and which are optional. > >JMP requires that processing(4), canceled(5), and completed(6) are >mandatory, so that pending(3) is optional. What about unknown(2)? >The former needsAttention state was also mandatory, so that the >new job-state reason: printer-stopped, should become a mandator job state >reason, correct? > >For IPP and JMP, all transitions into the canceled state should be required. >However, the transition from processing back to pending (a job-held situation) >is optional. > > > From ipp-archive Fri May 23 15:45:10 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA04682 for ipp-outgoing; Fri, 23 May 1997 15:40:15 -0400 (EDT) Message-Id: <9705231940.AB10103@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, 23 May 1997 12:37:43 PDT To: Robert.Herriot@eng.sun.com (Robert Herriot) From: Tom Hastings Subject: Re: IPP> MOD - UPDATE FOR STATUS CODE KEYWORDS IN THE MODEL DOCUMENT [spool-space-full] Cc: ipp@pwg.org, carterk@us.ibm.com Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I agree with Bob, we don't want an error for disk full, since that complicates clients that would have to take some action. Instead the PrintJob or SendDocument blocks until the disk space problem takes care of itself. The disk filling up is similar to a non-spooled Printer jamming or running out of paper. A really smart client could/should open up another channel on the Printer URL and do periodic Get-Attribute for the "printer-state" and "printer-state-reasons" attributes to watch for the 'stopped' state and the reasons: 'media-needed' and 'paper-jam'. A simple client need not bother, since all of these conditions ('spool-space-full' on a spooling Printer and media-needed' and 'paper-jam' on a non-spooled, non-queuing Printer) the Printer shall just termporarily hang the data transfer until the condition gets cleared up. (NOTE: RPC-time out problems, if IPP is ever layered on RPC). ISSUE: Should we add a value to the "printer-state-reasons" attribute: 'spool-space-full' so that such a smart client could tell on a Get-Attributes operation? ISSUE: Should we add a Printer attribute that indicates the amount of spooling space available, in K octets? Say: "spooling-space-available"? Then a smart client could tell whether to even try when it has a really large amount of document data to send. Tom At 13:48 05/21/97 PDT, Robert Herriot wrote: >Good job. I have some comments below > >Bob Herriot > >> From carterk@us.ibm.com Wed May 21 12:48:36 1997 >> > > >I'm not sure if this is a useful error, or even likely to happen. Paper jams or media-needed do happen on non-spooled Printers. But we want to require that the Printer must hang, don't we? In order to make it easy for simple clients. Smarter ones can do as Jay Martin's Printer applications do, namely, poll on another channel for printer-state. > >> >> 4.4.4.5 server-error-printer-error (IPP) >> >> A printer error, such as a paper jam, occurs while the IPP Printer >> processes a Print-Job or Send-Data operation. The response shall contain >> the Job Status with the specific error and should contain a Message >> describing the error. An IPP application should check the Job Status >> in the response for the specific error. > > > > >I would expect the client to block on a write and that it wouldn't >clear until the server got enough space to write the data. > >> >> 4.4.4.6 server-error-write-fault (IPP) >> >> A write error, such as a memory overflow (i.e. the document data >> exceeds the memory of the Printer) or a disk full condition, occurs >> while the IPP Printer processes a Print-Job or Send-Data operation. > > > >With the changes from last week where all Printers support PrintJob >(1 document per job) and some support CreateJob/SendJobData (1 or >more documents per job), this message isn't needed. The error >server-error-operation-not-implemented handles this problem instead. I agree. > >> >> 4.4.4.7 server-error-too-many-documents-in-job (IPP) >> > > From ipp-archive Fri May 23 18:19:57 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA07274 for ipp-outgoing; Fri, 23 May 1997 18:17:12 -0400 (EDT) From: Harald.T.Alvestrand@uninett.no To: Carl-Uno Manros cc: ipp@pwg.org, moore@cs.utk.edu, masinter@parc.xerox.com Subject: IPP> Re: ADM - IPP Documents for the IETF In-reply-to: Your message of "Thu, 22 May 1997 10:08:40 PDT." <3.0.1.32.19970522100840.00f8e2c8@garfield> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4079.864425843.1@dale.uninett.no> Date: Sat, 24 May 1997 00:17:24 +0200 Message-ID: <4081.864425844@dale.uninett.no> Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Carl-Uno, I've checked with Steve Coya, and he's quite adamant that he's never authorized refusing a request for an I-D when it came from the group chair. So there must have been some misunderstanding here. Please publish all the documents that you want as I-Ds. I rather like the list of documents, in fact, apart from your arcane choice of base protocol to send operations over! Harald A From ipp-archive Sat May 24 13:20:08 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA09271 for ipp-outgoing; Sat, 24 May 1997 13:16:40 -0400 (EDT) From: Roger K Debry To: Subject: Re: IPP>PRO change of date for face-to-face meeting Message-Id: <5030100002809353000002L032*@MHS> Date: Sat, 24 May 1997 13:18:32 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Bob, I could meet on the 17th. 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 05/24/97 11:13 AM --------------------------- ipp-owner @ pwg.org 05/22/97 04:25 PM Please respond to ipp-owner@pwg.org @ internet To: ipp @ pwg.org @ internet, Robert.Herriot @ Eng.Sun.COM @ internet cc: Subject: Re: IPP>PRO change of date for face-to-face meeting I am unable to attend any time the week of 6/16-6/20. Scott >>> Robert Herriot 05/22 2:52 PM >>> June 10 and 11 didn't work out for the face-to-face meeting. Please let me know if you can come to a face-to-face meeting for the IPP protocol (transport and encoding) in the San Francisco Bay Area on either Tuesday June 17 or Wednesday June 18. There may be the same preference as before for Tuesday to avoid conflict with the regular IPP Wed. teleconference. Bob Herriot From ipp-archive Sat May 24 13:20:09 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA09283 for ipp-outgoing; Sat, 24 May 1997 13:19:59 -0400 (EDT) From: Roger K Debry To: Cc: Cmanros Subject: IPP> Munich PING Message-Id: <5030100002809405000002L052*@MHS> Date: Sat, 24 May 1997 13:21:47 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I will NOT be attending the Munich meeting. 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 05/24/97 11:17 AM --------------------------- ipp-owner @ pwg.org 05/22/97 02:03 PM Please respond to ipp-owner@pwg.org @ internet To: ipp @ pwg.org @ internet cc: Subject: IPP> Munich PING I sent out a PING for Munich a few weeks ago. I have only got a few responses. Here is my current list: Munich PING Lee Farrell Canon Robert Herriot Sun Scott Isaacson Novell Carl-Uno Manros Xerox Steve Zilles Adobe As we expect to have a number of documents up for review in Munich, it would feel more comfortable if there we some more attendants from the IPP team. If you are planning to go, I urge you to make your bookings now. August is tourist season in Germany, so both flights and hotels are filling up. Please let me know if you will be going. 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 Sun May 25 15:50:27 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA15999 for ipp-outgoing; Sun, 25 May 1997 15:49:58 -0400 (EDT) Date: Sun, 25 May 1997 15:50:02 -0400 (EDT) From: JK Martin Message-Id: <199705251950.PAA18022@uscore.underscore.com> To: jmp@pwg.org, ipp@pwg.org Subject: IPP> Job state implementation questions for Unix-based print queues X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Sorry for the cross-post, but given that the PWG is desparately trying to reconcile common aspects between the Job MIB and IPP, both groups need to consider/review this topic. Print queues on Unix systems (both BSD and System V) provide ways for the system administrator to control an individual print queue: Enable/Disable Control whether jobs can be submitted to the queue by end users. (This is termed "Accept" and "Reject" on System V platforms.) Start/Stop Control the despooling of queued jobs to the target output device; if a queue is "stopped", then all queued jobs stay in a "pending" state until the queue is started. Also, a system administrator can selectively delete jobs from a target queue; on System V platforms the "cancel" command is used, while on BSD platforms either the "lprm" command or "lpc abort" command may be used. Some questions: 1. If a queue has been stopped, what should each job indicate for its job state? 2. If a queue is stopped, how can the user easily detect this critical queue-specific state? 3. Similarly, if a queue is disabled, how can the user detect this state? 4. If a system administrator deletes a job from a queue, what should the state and job reason(s) reflect? Thanks in advance for your advice and suggestions. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-archive Tue May 27 09:15:53 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA20593 for ipp-outgoing; Tue, 27 May 1997 09:15:26 -0400 (EDT) Message-ID: <338ADEA5.60EC@sharplabs.com> Date: Tue, 27 May 1997 06:16:21 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Laboratories of America X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> New protocol document available Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I have uploaded a new protocol draft to the PWG FTP server: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-052497.doc This document is a merge of several earlier documents into one document that has been formatted for submission as an internet draft (except where noted in the text). Please review prior to Wednesday conference call...(if possible) Randy (PS: sorry for the last minute submission...) From ipp-archive Tue May 27 12:30:58 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA21629 for ipp-outgoing; Tue, 27 May 1997 12:27:34 -0400 (EDT) From: Harry Lewis To: , Subject: IPP> JMP> Job state implementation questions for Unix-based print Message-Id: <5030100002851437000002L072*@MHS> Date: Tue, 27 May 1997 12:29:43 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Jay, these are good questions: >Some questions: > 1. If a queue has been stopped, what should each job indicate for its > job state? > 2. If a queue is stopped, how can the user easily detect this > critical queue-specific state? > 3. Similarly, if a queue is disabled, how can the user detect > this state? There is an analogous situation for the state NeedsAttention. One could ask, if the printer has an alert, should all the jobs in the printer buffer change to NeedsAttention state, or just the job which is currently printing. Our recommendation is not to ripple all jobs since this would be arduous for the agent. Rather, we envision the job monitoring application also having some indication of the overall health of the printer (Green, Yellow, Red). Only the job which is actually JAMMED (as an example) would reflect NeedsAttention state. Other jobs would be Pending on a "Red" printer. I would really like JMP and/or IPP confirmation of this approach for printer implementations and I offer it in response to your question about queue's as an analogy, presuming you could show overall queue status with a (Green, Yellow, Red) icon. As for your last question: > 4. If a system administrator deletes a job from a queue, what should > the state and job reason(s) reflect? I am not in favor of job state reasons as anything other than optional job attributes, but if I were to take a guess, here, I'd say that: State = CANCELED JobStateReasons1 = No reason (all zero's) JobStateRessons2 = deletedByAdministrator JobStateReasons3 = No reason JobStateReasons4 = No reason So, I guess, that would look like 0x00000000 0x00000002 0x00000000 0x00000000? Harry Lewis. From ipp-archive Tue May 27 12:30:59 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA21787 for ipp-outgoing; Tue, 27 May 1997 12:30:05 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 27 May 1997 10:28:52 -0600 From: Scott Isaacson To: ipp@pwg.org, jmp@pwg.org, jkm@underscore.com Subject: Re: IPP> Job state implementation questions for Unix-based print queues Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Here is how I see it.... >>> JK Martin 05/25 1:50 PM >>> > 1. If a queue has been stopped, what should each job indicate for its > job state? job-state = 'pending' with a job-state-reason = 'printer-stopped' > 2. If a queue is stopped, how can the user easily detect this > critical queue-specific state? printer-state = 'stopped', add a new reason to describe this - something like printer-state-reasons = 'stopped-by-operator'. > 3. Similarly, if a queue is disabled, how can the user detect > this state? The Printer has a boolean attribute called "printer-is-accepting-jobs". If the value is 'true' the Printer (and its queue have been enabled) otherwise the value is 'false'. > 4. If a system administrator deletes a job from a queue, what should > the state and job reason(s) reflect? We added the state 'cancelled' and the reason would be 'cancelled-by-operator'. job-state = 'cancelled', job-state-reasons = 'cancelled-by-operator' Scott From ipp-archive Tue May 27 12:41:09 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA22330 for ipp-outgoing; Tue, 27 May 1997 12:40:34 -0400 (EDT) Message-Id: <9705271638.AA10573@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, 27 May 1997 09:36:25 PDT To: jmp@pwg.org, JK Martin From: Tom Hastings Subject: IPP> Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are there any mandatory job states?] Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk Status: RO If a simple output device implements IPP and doesn't queue or spool, wouldn't the jobs in that output device never be in pending? Such a device would refuse acceptance of another job, while it was processing its current job. That is why pending is conditionally mandatory in IPP and therfore also in JMP. Would it help to indicate that if an implementation queues or spools, that it shall implement the 'pending' state jobs that are queued or spooled but are not yet processing? Tom At 12:26 05/25/97 PDT, JK Martin wrote: >What happened to "pending" as a mandatory job state? I certainly hope >we don't relegate this important state to the "Conditionally Mandatory" >realm. > >> The current draft lists processing, needsAttention, canceled, and completed >> as Mandatory. Since needsAttention has gone away, that leaves three >> states as mandatory: processing, canceled, and completed. Since we added >> aborted, I assume that aborted should be added to the mandatory list. >> >> The complicance at the end of the Job MIB spec also lists these states. >> >> [...snip...] >> >> Tom > > From ipp-archive Tue May 27 14:10:56 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA24605 for ipp-outgoing; Tue, 27 May 1997 14:10:31 -0400 (EDT) Message-ID: <338B24C8.7569@sharplabs.com> Date: Tue, 27 May 1997 11:15:36 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Laboratories of America X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> New protocol document (PDF) available Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I also placed a PDF version of the latest protocol document on the server: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-052497.pdf Randy From ipp-archive Tue May 27 14:15:59 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA24633 for ipp-outgoing; Tue, 27 May 1997 14:12:16 -0400 (EDT) From: Harry Lewis To: , Cc: Subject: IPP> Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are ther Message-Id: <5030100002856254000002L042*@MHS> Date: Tue, 27 May 1997 14:14:12 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Even printers that don't spool or queue will typically "buffer" some number of pages. Given the possibility of single page jobs... then some jobs can be pending. I guess we should ask ourselves what it means to have a "mandatory" state. Just because a state is Mandatory does not mean an implementation must "force" jobs to enter that state. If that were so... I'd REALLY be in favor of eliminating the NeedsAttention state! ;-> Harry Lewis - IBM Printing Systems ------- Forwarded by Harry Lewis/Boulder/IBM on 05/27/97 11:59 AM ------ jmp-owner@pwg.org 05/27/97 11:51 AM Please respond to jmp-owner@pwg.org @ internet To: jkm@underscore.com @ internet, jmp@pwg.org @ internet cc: ipp@pwg.org @ internet Subject: Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are ther If a simple output device implements IPP and doesn't queue or spool, wouldn't the jobs in that output device never be in pending? Such a device would refuse acceptance of another job, while it was processing its current job. That is why pending is conditionally mandatory in IPP and therfore also in JMP. Would it help to indicate that if an implementation queues or spools, that it shall implement the 'pending' state jobs that are queued or spooled but are not yet processing? Tom From ipp-archive Tue May 27 15:20:57 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA27086 for ipp-outgoing; Tue, 27 May 1997 15:16:45 -0400 (EDT) Message-Id: <3.0.1.32.19970527115533.0084abd0@ariel> X-Sender: fullman@ariel X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 27 May 1997 11:55:33 PDT To: Scott Isaacson From: Don Fullman Subject: Re: IPP> MOD - new model document (QUESTION on Job Template attr's and TYPOS) Cc: ipp@pwg.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Scott, et. al., Shouldn't the following Job Template attributes for the Printer Object be "setOf" or "1setOf"? - job-hold-until-available - number-up-supported - number-up-available - sides-supported - sides-available - printer-resolution-available - print-quality-available - compression-supported Many of these were multi-valued in the March 26th version. Why would these be single-valued? One possible reason might be that a printer may not be able to have more than one value ready at the same time, but that doesn't seem to apply to any of the attributes above. It seems to me that any xxx-available and xxx-supported attribute could all be multi-valued. Oh, by the way, I found a few typos that you might be interested in (listed below). Thanks, Don Fullman ------------------------------- POTENTIAL TYPOS: - Throughout both the TOC and the text, xxx-available and xxx-supported attributes have an extra character in the name -- I'm sure a result of cut and paste. - Line 220 contains "xxx" instead of "print-quality". - Line 1607 (** and other locations, too! **) states for the xxx-available attribute that the Printer shall NOT implement the available attribute. - Line 1331, "newly create" should be "newly created". - "pecific" on line 1488 - "both both" on line 1514 - Line 2033 refers to the "held" job state which is no longer a state in subclause 6.3.2.5. (or it should be listed in subclause 6.3.2.5. ------------------------------- At 01:16 AM 5/11/97 PDT, Scott Isaacson wrote: >I have posted a new model document at > >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970512.pdf >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970512.doc > >The .doc file is really a RTF file so I hope it is not infected with the >concept virus. > >I will try to post the text version soon - the generic/text driver is >crashing my machine. > >The pdf with line numbers is the document we will be reveiwing on Wed. > >Scott > From ipp-archive Tue May 27 15:46:00 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA27804 for ipp-outgoing; Tue, 27 May 1997 15:45:04 -0400 (EDT) Message-Id: <01BC6AB5.00D1B720@HORTON> From: Peter Zehler To: "'Tom Hastings'" , "jmp@pwg.org" , JK Martin Cc: "ipp@pwg.org" Subject: RE: IPP> Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are the Date: Tue, 27 May 1997 12:45:27 PDT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Tom, You wrote: If a simple output device implements IPP and doesn't queue or spool, wouldn't the jobs in that output device never be in pending? Such a device would refuse acceptance of another job, while it was processing its current job. That is why pending is conditionally mandatory in IPP and therfore also in JMP. Would it help to indicate that if an implementation queues or spools, that it shall implement the 'pending' state jobs that are queued or spooled but are not yet processing? Tom [PZ] I am implementing IPP in a small printer that does not spool simple print jobs. There can be a time when an entire print job is accepted by the IPP printer and the back end of the physical printer is not yet ready to process the job. At this point the job is blocked pending service by the backend print system. The IPP channel may accept only one job at a time. The print device may service multiple print channels. From the time the job is accepted by the IPP printer until the job is passed onto the native print system the IPP state would be pending. I would not claim a job sitting in memory blocked on the submission to the native print system is queued or spooled. Pete From ipp-archive Tue May 27 15:46:05 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA27708 for ipp-outgoing; Tue, 27 May 1997 15:43:23 -0400 (EDT) Message-Id: <9705271942.AA10760@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, 27 May 1997 12:40:54 PDT To: jmp@pwg.org, ipp@pwg.org From: Tom Hastings Subject: IPP> Updated IPP job-state/job-state-reasons & JMP jmJobState/jmJobStateReasons Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I've cross-posted 5 files dealing with the agreements and updated text on the IPP "job-state" and "job-state-reasons" attributes and the corresonding JMP jmJobState and jmJobStateReason1 objects in: ftp::/ftp.pwg.org/pub/pwg/ipp/new_MOD/ -rw-r--r-- 1 pwg pwg 67224 May 27 19:17 jobstate.pdf -rw-r--r-- 1 pwg pwg 40694 May 27 19:31 jobstate.txt -rw-r--r-- 1 pwg pwg 102901 May 27 19:17 jobstatr.doc -rw-r--r-- 1 pwg pwg 121920 May 27 19:17 jobstatr.pdf -rw-r--r-- 1 pwg pwg 125261 May 27 19:18 jobstatr.pdr ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 67224 May 27 19:25 jobstate.pdf -rw-r--r-- 1 pwg pwg 40694 May 27 19:25 jobstate.txt -rw-r--r-- 1 pwg pwg 102912 May 27 19:25 jobstatr.doc -rw-r--r-- 1 pwg pwg 121956 May 27 19:26 jobstatr.pdf -rw-r--r-- 1 pwg pwg 125293 May 27 19:26 jobstatr.pdr The *.doc files are MS-WORD V6.0a The jobstate.* are with revisions accepted (i.e., no revisions marks). The jobstatr.* are with revisions marked from the current texts of IPP and JMP. The jobstatr.pdf has black revision marks and the jobstatr.pdr file has red revision marks. These results are from the joint IPP/JMP telecon last Wednesday, May 21. There is an IPP issue listed below and in the document which Carl-Uno said we could handle on the IPP telecon, tommorrow, Wed, May 28, if it takes a short time. If it takes longer, we will need to setup a separate IPP Model telecon, since the major discussion for the IPP telecon will be the new protocol document. There is also a JMP issue listed below that could be handled at this separate IPP Model telecon, if the JMP issue listed below need discussion. JMP people, Please read these files to make sure you agree with the agreements we reached last week on IPP and their impact on JMP. It would be good to see if we have agreement between IPP and JMP on these crucial job state and job state reasons attributes (which are JMP SNMP objects). If you have problems, please raise them on the IPP and JMP DLs so that we can decide how to process the issues at the IPP telecon tommorrow: May 28 ------ Call-in: 1-309-671-1035, 1-3pm PDT (4-6pm EDT) Access: 190148 NOTE: A different number from usual IPP numbers. Thanks, Tom Here is the beginning of the files that I posted (you'll have to pull the files to see the actual revised texts for IPP and JMP): Subject: IPP and JMP agreements on job-state and job-state-reasons From: Tom Hastings Date: 5/25/97 File: jobstatr.doc (with revision marks) jobstate.doc (without revisions) I carried out the JMP action item to schedule the discussion about aligning the job state and job state reasons between IPP and JMP, Wednesday, 21 May, 1-3pm PDT. We came to a good agreement taking the best ideas from each. Unfortunately, Ron and Harry were not in on the call. There is one IPP Issue and one JMP issue listed below. I'm attempting to include any rough consensus generated on the e-mail list since last Wednesday's meeting as well. I've included Ron's suggestions to eliminate duplication between the object and textual convention descriptions and to put more explanation in the objects and less in the textual conventions in the process. I've re-ordered the job-state-reasons to be in the order that jobs normally proceed by job states. This will help with understanding that Jay requested about "the day in the life of a job". I've also attempted to make each job state and job state reason more concise without changing the meaning. If any Job Monitoring MIB participants disagree with the agreements, please send e-mail ASAP, since I'm editing the agreements into the Job Monitoring MIB. Talking to Scott, I have taken the "job-state", "job-state-reasons", and "job-state-message" attribute sections from IPP and edited in the changes with revision marks. After each edited IPP section, I've edited corresponding Job Monitoring MIB TC and object or attribute section. I've made jmJobStateReasons1 an object in the jmJobTable, since the JMP e-mail discussion indicated that it should be MANDATORY. The remaining jobStateReasons2, jobStateReasons3, and jobStateReasons4 remain as attributes in the jmAttributeTable. (No attributes in the attribute table are MANDATORY, except jobOwner, and we are discussing means to make jobOwner an object in a MANDATORY table, somehow, possibly using the jmJobIDTable.) IPP ISSUE - Should in-coming and out-going jobs be in 'pending' or 'processing' states? In the Internet-Draft, there is a conflict between the semantics of the 'processing' state specified under the "job-state" attribute and the "job-state-reasons" values: 'job-sending-to-output-device' and 'job-queued- in-output-device' which we agreed to combine into: 'job-outgoing'. JMP ISSUE - generic job-held job state reason vs. adding held job state ---------------------------------------------------------------------- >From the e-mail, the major JMP issue remaining is whether it is important when the job is in the pending state to allow job monitoring applications to be able to distinguish between job state reasons that prevent the job from being a candidate for processing from those that are just purely informational without knowing the particular reason (which may be a newly registered reason that the application couldn't have known about). IPP solves this problem by changing the keyword values for reasons that keep the job from being a candidate for processing to all begin with 'job-hold-'. But the Job Monitoring MIB uses enum codes, not keywords, so there isn't a good way for the agent to indicate such a distinction to an application. There are two possibilities: 1. Add a generic jobHeld value to the JMP JmJobStateReasons1TC which an agent shall set in addition to the specific reason that keeps the job from being a candidate for processing, i.e., the agent shall set jobHeld along with jobHoldUntilSpecified, jobProcessAfterSpecified, and jobHoldUntilResourcesAreReady reasons. 2. Instead of introducing the generic jobHeld value, add back the held job state to JMP (and leave IPP without the 'held' state, since the reason values are distinguishable to an application from the 'job-hold-' keyword prefix. I've written up alternative 1, since it is a superset of IPP. However, alternative 2 is a simple alternative. Since the JMP agent is only reflecting job state and not implementing a job state machine, the complexity of another job state is not such a problem for implementing an agent and is somewhat easier for the application. Summary of IPP and JMP job state and job state reasons agreements ------------------------------------------------------------------ Here is the summary of the job state and job state reasons agreements: 1. In JMP remove the 'held', 'printing', and 'needsAttention' states. 2. In both IPP and JMP add the 'aborted' state and make it a final state. 3. In both IPP and JMP remove the 'aborted-by-system' job-state-reason, since the new 'aborted' state says it all. 4. In IPP replace the 'terminating' state with the 'canceled' and 'aborted' states and make 'canceled' and 'aborted' final states, like the JMP 'canceled' and 'completed' states. So the simplified state transition diagram for IPP and JMP was agreed to be: New state Old state (3) (4) 5) (6) (7) yes yes pending(3) yes yes processing(4) yes yes yes canceled(5) yes aborted(6) yes completed(7) yes Generally state transitions are from left to right. A blank entry indicates unlikely, but allowed, transitions. The following diagram is simpler to understand than the table, so lets replace the above table with the following in both IPP and JMP: +--> canceled / pending --> processing --+----> aborted \ +--> completed Normally a job progresses only from left to right through three states. Conformance Requirements for job states --------------------------------------- JMP requires that processing(4), aborted(6), and completed(7) are mandatory, so that pending(3), canceled(5), and unknown(2) are conditionally mandatory. (IPP level 1 does not have CancelJob, so we have to make the canceled state conditionally mandatory in JMP in order to instrument a level 1 IPP system.) The former JMP needsAttention state was also mandatory, so that the equivalent new job-state-reason: deviceStopped, is a mandatory value of the JMP jmJobStateReasons1 object. The deviceStopped value aligns with the IPP 'printer-stopped' value of the "job-state-reasons" attribute, but we are trying to be more general in JMP, so we use the word 'device', not 'printer'. If deviceStopped is a MANDATORY reason, then the jobStateReasons1 attribute becomes MANDATORY. Therefore, the jobStateReasons1 JMP attribute moves to the jmJobTable, since it is an Integer, not Octets, and will be called the jmJobStateReasons1 object. The other 3 jobStateReasonsN (N=2, 3, and 4) will remain in the jmJobAttributeTable as conditionally mandatory attributes. There were two major reasons that IPP replaced the 'needs-attention' state with the 'printer-stopped' job-state-reason: 1. IPP felt it was as important for a user to know that the printer that their job was waiting for was stopped, as it was for the user whose job was the current job. Therefore, whether the job was in the 'pending' or 'processing' state we wanted to indicate that the printer had stopped for the job. Therefore, need-attention is really a reason, not a state. If needs-attention were a job state, when the printer resumes, the job would go back to either 'pending' or 'processing', depending on which state the job had been in previously. Remembering which previous state was a problem. Also the user should know whether his job was the current one or some other users was the current job, since in an unattended shop, the onus might be on the current user to fix the problem. By keeping the job in the same state ('pending' or 'processing'), instead of moving the job to a different 'needs-attention' state and setting the job-state-reason, there was no need to remember the previous state. 2. The job state reason was renamed from 'needs-attention' to 'printer-stopped', because the printer might need attention but the current job could still make progress because the printer hasn't stopped. For example, toner low or media low or an input tray is empty, but the current job is not using that tray. Also the operator might have intentionally stopped the printer, so needs-attention would be misleading. You'll have to copy the files from ftp://ftp.pwg.org/pub/pwg/ cited above in order to see the actual text changes to IPP and JMP. Tom From ipp-archive Tue May 27 16:56:00 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA29525 for ipp-outgoing; Tue, 27 May 1997 16:51:44 -0400 (EDT) Message-Id: <9705272051.AA00352@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, 27 May 1997 13:49:22 PDT To: ipp@pwg.org, jmp@pwg.org, Peter Zehler From: Tom Hastings Subject: RE: IPP> Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are the Cc: JK Martin Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Peter, How long would a job be in the pending state in your non-queuing, non-spooling IPP system? If the time is not noticable to humans, e.g., 100s of miliseconds, I would think that there wan't much point in simplementin the IPP state of 'pending'. If it was longer, so that end-users would see it for a while, while nothing was happending on the printer, then it would be good to implemente the IPP 'pending' state for your Printer object. So your point was not that 'pending' must be a Mandatory state, but that in your implementation of a simple, non-queuing, non-spooling printer you wanted to be able to implement 'pending'. So we just have to find language that permits non-queuing, non-spooling printers to implement 'pending', but doesn't require it. On the other hand, it might be simpler to mandate the 'pending' state and for implementations that don't queue or spool, the state would never be visible or would be visible for a very short period of time. Tom At 12:45 05/27/97 PDT, Peter Zehler wrote: >Tom, >You wrote: >If a simple output device implements IPP and doesn't queue or spool, wouldn't >the jobs in that output device never be in pending? Such a device would >refuse acceptance of another job, while it was processing its current job. >That is why pending is conditionally mandatory in IPP and therfore also in >JMP. > >Would it help to indicate that if an implementation queues or spools, >that it shall implement the 'pending' state jobs that are queued or spooled >but are not yet processing? > >Tom > >[PZ] I am implementing IPP in a small printer that does not spool simple >print jobs. There can be a time when an entire print job is accepted by >the IPP printer and the back end of the physical printer is not yet ready to >process the job. At this point the job is blocked pending service by the >backend print system. >The IPP channel may accept only one job at a time. The print device may >service multiple print channels. From the time the job is accepted by the IPP >printer until the job is passed onto the native print system the IPP state would >be pending. I would not claim a job sitting in memory blocked on the submission >to the native print system is queued or spooled. >Pete > > From ipp-archive Tue May 27 17:41:10 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA01024 for ipp-outgoing; Tue, 27 May 1997 17:38:10 -0400 (EDT) Date: Tue, 27 May 1997 14:39:37 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705272139.OAA06575@woden.eng.sun.com> To: jmp@pwg.org, rbergma@dpc.com, hastings@cp10.es.xerox.com Subject: RE: JMP> IPP>MOD HELD vs NEEDS-ATTENTION Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO There has been a lot of discussion on the JMP list about the held and needs-attention state. Several people have stated that the primary reason for having 'held' and 'needs-attention' as job-states rather than job-state-reason is that the job-state should be all that most people need to look at. Keeping that in mind, here's is an slightly different view that we should perhaps consider. I put this forth for discussion and can see pro's and con's for keeping the simple 5 job-states of IPP versus adding these two additional states. The Proposal: Change the name of "needs-attention" to "stopped-printing" and define the "stopped-printing" state as an alternate view of the "processing" state. A job is in the "stopped-printing" state when certain job-state-reasons take it out of the "processing" state temporarily. When those reasons clear, the job goes back to the "processing" state. Likewise, the "held" job-state is an alternate view of the "pending" state. A job is in the "held" state when certain job-state-reasons take it out of the "pending" state temporarily. When those reasons clear, the job goes back to the "pending" state. Such reasons include "held-until" (aka "job-hold-until-specified"), "held-for-resources" (aka "required-resources-not-ready"), and "printer-stopped". Any reasons that keeps a job from making progress towards the printer put it in the "held" state. Any reasons that keep a job from processing put it in the "stopped-printing state. Note that the "printing-stopped" reason changes a "processing" job to "stopped-printing" and a "pending" job to a "held" job. If we want more regular names, then we should call "held", "pending-stopped" and we should call "stopped-printing", "processing-stopped". Note: I do not like the name "needs-attention" because it is the printer that needs attention and not the job. Furthermore, the printer may need attention even when a particular job is pending. Comments? Bob Herriot From ipp-archive Tue May 27 17:56:00 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA02300 for ipp-outgoing; Tue, 27 May 1997 17:55:15 -0400 (EDT) Message-Id: <3.0.1.32.19970527144826.00a32850@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 27 May 1997 14:48:26 PDT To: rturner@sharplabs.com From: Carl-Uno Manros Subject: Re: IPP> New protocol document (PDF) available Cc: ipp@pwg.org In-Reply-To: <338B24C8.7569@sharplabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO At 11:15 AM 5/27/97 PDT, you wrote: >I also placed a PDF version of the latest protocol document >on the server: > >ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-052497.pdf > > >Randy > Randy, thanks for doing this while some us where enjoying the holiday. However, there are still a bit too many open issues for me to feel very comfortable. I hope we can resolve a number of them in tomorrows phone conference, before sending out the text as I-D. How about a .TXT version as well? We are trying to make sure that everybody out there is happy. 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 May 27 18:11:04 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA02793 for ipp-outgoing; Tue, 27 May 1997 18:09:15 -0400 (EDT) Date: Tue, 27 May 1997 15:05:04 PDT From: "Caruso,Angelo" Subject: IPP> RE: JMP> HELD vs NEEDS-ATTENTION To: jmp@pwg.org Cc: ipp@pwg.org Message-id: <6C598B3381262D796C598B3381262D79#064#x-wb-0311-ms1.xerox@SMF> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Posting-date: Tue, 27 May 1997 18:14:29 -0400 Priority: normal Hop-count: 3 Sender: ipp-owner@pwg.org Precedence: bulk Status: RO There seem to be two extremes on this whole issue. On the one side there are those who would like all their favorite states included in one easy to use job state object. On the other side are those who want to keep the job state object ultra simple and have lots of job state reasons. Both points of view have been backed up by many good arguments. Last week at the IPP teleconference it seemed that a reasonable COMPROMISE was reached. Unfortunately, several key JMP folks were not present for that discussion and now we're waffling on the whole issue again. Based on todays mail volume there does not appear to be any end in sight. For the record, here is my position. IPP and JMP should use EXACTLY the same set of job states and the same state reasons (the agreement reached at the last IPP/JMP teleconference seemed reasonable to me). How are we to expect the PWG to be taken seriously if we simultaneously create two specifications with different job models? The rest of the world expects and deserves a consistent set of standards from this working group! Please don't respond again how easy it is to map between the two different state models. I understand the mapping because I have been following the discussions. But the rest of the world will not find the mapping to be so obvious. If we learned anything from the Printer MIB interop testing it is that interpreting ONE model correctly is hard enough. Now, we are on the verge of generating two different models to represent the same thing. It's time to find a compromise. Thanks, Angelo From ipp-archive Tue May 27 19:41:00 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA03630 for ipp-outgoing; Tue, 27 May 1997 19:38:00 -0400 (EDT) Message-Id: <3.0.1.32.19970527163209.00a67100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 27 May 1997 16:32:09 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Proposal for revised IETF Charter Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I had undertaken to produce a draft for a revised charter text for the IETF. Here it is. I would like to have your comments on this in tomorrows PWG IPP phone conference, so we can pass it on to the IETF shortly afterwards. You can obviously also send comments to the IPP DL. Carl-Uno --- Internet Printing Protocol (ipp) Charter --------------------------------------------------------------------------- In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at: * Additional Internet Printing Protocol Page: http://www.pwg.org/ipp --------------------------------------------------------------------------- Chair(s) * Carl-Uno Manros * Steve Zilles Applications Area Director(s): * Keith Moore * Harald Alvestrand Area Advisor * Keith Moore Mailing List Information * General Discussion:ipp@pwg.org * To Subscribe: ipp-request@pwg.org * Archive: ftp://ftp.pwg.org/pub/pwg/ipp/ Description of Working Group There is currently no universal standard for printing. Several protocols are in use, but each has limited applicability and none can be considered the prevalent one. This means that printer vendors have to implement and support a number of different protocols and protocol variants. There is a need to define a protocol which can cover the most common situations for printing on the Internet. The goal of this working group is to develop requirements for Internet Printing and to describe a model and semantics for Internet Printing. The further goal is to define a new application level Internet Printing Protocol for the following core functions: - for a user to find out about a printer's capabilities - for a user to submit print jobs to a printer - for a user to find out the status of a printer or a print job - for a user to cancel a previously submitted job The Internet Print Protocol is a client-server type protocol which should allow the server side to be either a separate print server or a printer with embedded networking capabilities. The focus of this effort is optimized for printers, but might be applied to other output devices. These are outside the scope of this working group. The working group will also define a set of directory attributes that can be used to ease finding printers on the network. The Internet Print Protocol will include mechanisms to ensure adequate security protection for materials to be printed, including at a minimum mechanisms for mutual authentication of client and server and mechanisms to protect the confidentiality of communications between client and server. Finally, the IPP working group will produce recommendations for interoperation of LPR clients with IPP servers, and IPP clients with LPR servers. These recommendations will include instructions for both the translation of the LPR protocol onto IPP and the translation of the IPP protocol onto LPR. However, there is no expectation to provide new IPP features to LPR clients, nor is there an explicit requirement to translate LPR extensions to IPP, beyond those features available in the 4.2BSD UNIX implementation of LPR, and which are still useful today. Subjects currently out of scope for this working group are: - protection of intellectual property rights - fax input - scanning The working group shall strive to coordinate its activities with other printing-related standards bodies, without the need to be strictly bound by their standards definitions. These groups are: - ISO/IEC JTC 1/SC 18/WG 4 on Document Printing Application (ISO/IEC 10175 parts 1 - 3) - The Object Management Group (OMG) on OMG Printing Facility (in development) - IEEE (POSIX System Administration - Part 4: Printing Interfaces) - X/Open (Printing Systems Interoperabilty Specification) - The Printer Working Group Goals and Milestones Done - Mar 97 Submit Internet Printing Protocol: Requirements and Scenarios as an Internet-Draft. Done - Mar 97 Submit Internet Printing Protocol/1.0: Model and Semantics as an Internet-Draft. Done - Mar 97 Submit Internet Printing Protocol/1.0: Directory Schema as an Internet-Draft. Done - Apr 97 Review of specifications in IETF meeting in Memphis, TN, USA Jun 97 Submit Internet Printing Protocol/1.0: Security as an Internet-Draft. Jun 97 Submit Internet Printing Protocol/1.0: Encoding of Operations as an Internet-Draft. Jun 97 Submit Internet Printing Protocol/1.0: Profile for running IPP over HTTP 1.1 as an Internet-Draft. Jul 97 Submit revised Internet-Drafts for all previously mentioned documents. Jul 97 Produce At least 2 implemented prototypes. Jul 97 Submit Internet Printing Protocol/1.0: Profile for running IPP over HTTP 1.1 as an Internet-Draft. Jul 97 Submit Mappings between IPP and RFC 1179 as an Internet-Draft. Jul 97 Produce at least 2 implemented prototypes. Aug 97 Review of all Internet-Drafts in Munich meeting of the IETF. Sep 97 Submit Requirements for an Internet Printing Protocol I-D and Mappings between IPP and RFC 1179 I-D to IESG for publication as Informational RFCs. Sep 97 Submit all other I-Ds to the IESG for consideration as Proposed Standards. Current Internet-Drafts * Requirements for an Internet Printing Protocol (97837 bytes) * Internet Printing Protocol/1.0: Model and Semantics (226320 bytes) * Internet Printing Protocol/1.0: Directory Schema (29564 bytes) No Request for Comments ---- 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 May 27 19:51:00 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA04100 for ipp-outgoing; Tue, 27 May 1997 19:49:15 -0400 (EDT) Message-Id: <3.0.1.32.19970527164325.009b6260@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 27 May 1997 16:43:25 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Agenda for PWG IPP Phone Conference - May 28 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Agenda for PWG IPP Phone Conference - May 28, 1-3:30 pm PST - Comments on IPP Document List and Draft IETF IPP Charter Text (Carl-Uno) - Comments on the HTTP 1.1 Transport Mapping for IPP (Randy) - Comments on Job Model synchronization Printer Model vs. IPP (Tom) We expect to spend most of the time on Randy's document The numbers for tomorrow are: Call-in: 1-309-671-1035 Access: 190148 ---- 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 May 28 05:34:52 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id FAA05771 for ipp-outgoing; Wed, 28 May 1997 05:09:36 -0400 (EDT) Message-Id: <9705280909.AB00590@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: Wed, 28 May 1997 02:07:04 PDT To: Harry Lewis From: Tom Hastings Subject: IPP> Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are ther Cc: , Sender: ipp-owner@pwg.org Precedence: bulk Status: RO At 11:14 05/27/97 PDT, Harry Lewis wrote: >Even printers that don't spool or queue will typically "buffer" some number of >pages. But isn't the definition of "queuing" on page 13, line 364, what you mean by "buffering" some number of jobs? Given the possibility of single page jobs... then some jobs can be >pending. I guess we should ask ourselves what it means to have a "mandatory" >state. Just because a state is Mandatory does not mean an implementation must >"force" jobs to enter that state. If that were so... I'd REALLY be in favor of >eliminating the NeedsAttention state! ;-> We keep getting confused by whether a MIB is talking about the printer or is talking about what the agent shall show about the printer. I claim that MIBs are all about the latter and nothing to do with the former. See my early answer to Ron about the completed state. Most printers won't have such a state, the printer throws the job away as soon as it is printed. Its the agent that has to keep the job information in the MIB tables for the time indicated in the jmGeneralJobPersistence object. If the 'completed' state were conditionally mandatory, then an agent would only have to show jobs in the 'completed' state, if the device implemented the completed state. But we aren't going to allow agents off the hook. The agent has to implement the 'completed' state. Same for 'aborted'. 'canceled', is conditionally mandatory, because level 1 IPP doesn't requiure the CancelJob operation. So we aren't going to force agents to show a canceled state, except for printers that implement a CancelJob operation. For needsAttention, is is impossible to design a device that handles paper that doesn't need attention some time (unless it plants, grows, harvests trees, makes paper, and fixes all jams). So making needsAttention Mandatory forces the agent to show jobs in the needsAttention state, if the printer jams. > >Harry Lewis - IBM Printing Systems > > >------- Forwarded by Harry Lewis/Boulder/IBM on 05/27/97 11:59 AM ------ > > jmp-owner@pwg.org > 05/27/97 11:51 AM >Please respond to jmp-owner@pwg.org @ internet > > >To: jkm@underscore.com @ internet, jmp@pwg.org @ internet >cc: ipp@pwg.org @ internet >Subject: Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are ther > >If a simple output device implements IPP and doesn't queue or spool, wouldn't >the jobs in that output device never be in pending? Such a device would >refuse acceptance of another job, while it was processing its current job. >That is why pending is conditionally mandatory in IPP and therfore also in >JMP. > >Would it help to indicate that if an implementation queues or spools, >that it shall implement the 'pending' state jobs that are queued or spooled >but are not yet processing? > >Tom > > > From ipp-archive Wed May 28 05:34:54 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id FAA05785 for ipp-outgoing; Wed, 28 May 1997 05:09:47 -0400 (EDT) Message-Id: <9705280909.AB00590@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: Wed, 28 May 1997 02:06:55 PDT To: ipp@pwg.org, jmp@pwg.org, Harry Lewis From: Tom Hastings Subject: IPP> Re: JMP> Job state implementation questions for Unix-based print Sender: ipp-owner@pwg.org Precedence: bulk Status: RO At 09:29 05/27/97 PDT, Harry Lewis wrote: >Jay, these are good questions: > >>Some questions: > >> 1. If a queue has been stopped, what should each job indicate for its >> job state? In IPP, the Printer's printer-state would have the value: 'stopped' the Printer's printer-state-reasons would have the value: 'paused' (or maybe 'shutdown', depending on how the queue was stopped by the operator). all the 'pending' jobs would have the job-state-reasons value: 'printerStopped' all the 'processing' jobs would have the job-state-reasons value: 'printerStopped' In JMP, the jobStateReasons2 attribute would have the serviceOffLine reason set (bit 0x400000) for all jobs in the pending state. Same for the JMP held state, if JMP has such a state. But JMP doesn't have a Printer, except the Printer MIB, so there isn't the same good stuff about the Printer that IPP has. > >> 2. If a queue is stopped, how can the user easily detect this >> critical queue-specific state? In IPP, the user gets back some Printer status when querying the job as well as job state. In JMP, its harder, since JMP only has the deviceAlert attribute which is the hardware alert code from the Printer MIB. No much about queues in the Printer MIB. We could add two objects to the JMP jmGeneralTable that mirror these two IPP Printer attributes: jmGeneralState jmGeneralStateReasons which indicate the state of the job set and the job set state reasons. The values from IPP printer-state and printer-state-reasons would be: jmGeneralState: unknown, idle, processing, stopped jmGeneralStateReasons: stopped-partly, stopped, media-needed, paper-jam, paused, shudown, connect-to-printer, timed-out, stopping Should we? > >> 3. Similarly, if a queue is disabled, how can the user detect >> this state? In IPP, the Printer has the boolean Mandaory attribute: printer-is-accepting-jobs Again, we don't have the equivalent in the JMP MIB. We could add a boolean object to the jmGeneralTable: jmGeneralIsAcceptingJobs to give the same information on a Job Set basis. Should we? > >There is an analogous situation for the state NeedsAttention. One could >ask, if the printer has an alert, should all the jobs in the printer buffer >change to NeedsAttention state, or just the job which is currently printing. IPP has been stating that the end user wants to know the bad news for his/her pending job, not just for his/her processing job. >Our recommendation is not to ripple all jobs since this would be arduous for >the agent. I agree that rippling would be arduous for the agent, so don't ripple. May I suggest that there is no ardor at all, if the agent just waits until the job is queried to return the jmJobStateReason1 value is deviceStopped, if the device is still stopped. If the device got going again before the 'pending' job was queried, then no extra work was done by the agent for that job. So there need be no "rippling at all". > Rather, we envision the job monitoring application also having >some indication of the overall health of the printer (Green, Yellow, Red). >Only the job which is actually JAMMED (as an example) would reflect >NeedsAttention state. Other jobs would be Pending on a "Red" printer. But the IPP 'printer-stopped' value in the "job-state-reasons attribute" is exactly the 'red' printer indication, but the indication comes more conviently with the job in the job-state-reasons attribute. The IPP printer-state is also stopped, if the user did query the Printer. The big advantage to JMP of using the same approach of the deviceStopped value of the jmJobStateReasons1 object, is that it works for all three of our supported JMP configurations, not just configuration 1 (client talks directly to the output device). So that the Printer MIB isn't needed in order for the user to get the "red" printer indication back. >I would really like JMP and/or IPP confirmation of this approach for printer >implementations and I offer it in response to your question about queue's as >an analogy, presuming you could show overall queue status with a (Green, >Yellow, Red) icon. > >As for your last question: > >> 4. If a system administrator deletes a job from a queue, what should >> the state and job reason(s) reflect? > >I am not in favor of job state reasons as anything other than optional job >attributes, but if I were to take a guess, here, I'd say that: >State = CANCELED >JobStateReasons1 = No reason (all zero's) Current and previsou spec has canceledByOperator or canceledByUser as values. Remember Jay's mail that the user needs to be able to tell whether the user, the operator or the system canceled his/her job. Now that IPP/JMP have the aborted state, the system canceled jobs is indicated by the 'aborted' job state, so that reason has gone away. He also wanted it to be mandatory, so I moved jobStateReason1 attribute to the jmJobTable and called it jmJobStateReason1. >JobStateRessons2 = deletedByAdministrator That is in jmJobStateReasons1 >JobStateReasons3 = No reason >JobStateReasons4 = No reason > >So, I guess, that would look like 0x00000000 0x00000002 0x00000000 0x00000000? More like: 0x00002000 0x00000000 0x00000000 0x00000000 with job-state spec I just posted. > >Harry Lewis. > > From ipp-archive Wed May 28 07:56:11 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA08355 for ipp-outgoing; Wed, 28 May 1997 07:54:21 -0400 (EDT) Message-Id: <01BC6B3C.BD780320@HORTON> From: Peter Zehler To: "'Tom Hastings'" , "ipp@pwg.org" , "jmp@pwg.org" , Peter Zehler Cc: JK Martin Subject: RE: IPP> Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are Date: Wed, 28 May 1997 04:57:06 PDT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Tom, The amount of time a job would be in the pending state on a non-queueing non-spooling printer could be noticable to humans. It is dependant on the size of the print jobs on the other channels. I think it would simplify things just to have the pending state mandatory. Implementations could step through this state so quickly it would never be noticable to humans. Pete Peter, How long would a job be in the pending state in your non-queuing, non-spooling IPP system? If the time is not noticable to humans, e.g., 100s of miliseconds, I would think that there wan't much point in simplementin the IPP state of 'pending'. If it was longer, so that end-users would see it for a while, while nothing was happending on the printer, then it would be good to implemente the IPP 'pending' state for your Printer object. So your point was not that 'pending' must be a Mandatory state, but that in your implementation of a simple, non-queuing, non-spooling printer you wanted to be able to implement 'pending'. So we just have to find language that permits non-queuing, non-spooling printers to implement 'pending', but doesn't require it. On the other hand, it might be simpler to mandate the 'pending' state and for implementations that don't queue or spool, the state would never be visible or would be visible for a very short period of time. Tom From ipp-archive Wed May 28 08:16:11 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA08976 for ipp-outgoing; Wed, 28 May 1997 08:15:49 -0400 (EDT) Message-Id: <9705281215.AA14057@cabeza.cp10.es.xerox.com> X-Mailer: exmh version 1.6.7 5/3/96 To: ipp@pwg.org Cc: rturner@sharplabs.com Subject: IPP> New protocol document & Security issues Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 May 1997 05:15:34 PDT From: John Wenn Sender: ipp-owner@pwg.org Precedence: bulk Status: RO There are a couple of security issues involved in the latest protocol document. They cover sections 5.5, 5.7, 6.x, 6.y & 7. The issues are basically in two areas. (1) You should be using HTTP Digest Authentication (rfc2069), not HTTP Basic Authentication. Basic authentication provides zero security (unencrypted username and passwords are sent over the wire). Digest authentication provides moderate security. So reference Digest authentication is section 5.5. The headers used for Digest authentication are the same (Authorization, Proxy-Authorization, WWW-Authenticate, Proxy-Authenticate), but they have different values. Since the paper doesn't go into details, the other sections should be fine as they are. (2) Not all authentication / authorization is done via HTTP. For example, the connection may be made using SSL. In that case, SSL provides the authentication needed. While the sections are generally good about saying HTTP authentication is used when needed, somewhere the fact that other security mechanisms are used should be made explicit. And, of course, section 7 (security considerations) needs to be rewritten, but the security group should do that. /John From ipp-archive Wed May 28 10:21:12 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA09568 for ipp-outgoing; Wed, 28 May 1997 10:16:32 -0400 (EDT) From: Roger K Debry To: Subject: IPP>MOD - Too Many IPP Operations? Message-Id: <5030100002891502000002L022*@MHS> Date: Wed, 28 May 1997 10:18:34 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO You all must pardon me if I am covering ground that has been covered before, but since I was not able to attend the IPP meetings last week my thinking may be a bit behind where everyone else is at. In reading through the minutes of the meeting and recent email on the discussion list, it seems to me that we may have invented more operations for IPP than we really need. It seems to me that we added CreateJob to allow a client to validate job attributes prior to sending all of the print data. The original send operation (which I think we are back to) simply transmits the print data. The deBry/Carter proposal to use multiple send Documents was not accepted. We are depending upon http chunking to allow the client to send the print data in pieces and upon tcp/ip to guarantee delivery. We added Validate and PrintJob to provide for the simple print case proposed by Microsoft. As I read the minutes and email it also seems that we generally agreed that well behaved clients would always know printer characteristics, either because the Printer has been "installed" on the desktop or the client has queried the capabilities of the printer. So as I see it, we are left with the following: CreateJob - used to validate the print job Validate - used to validate the print job SendDocument - its only value is to transmit the job data PrintJob - transmits the job data and the job attributes What am I missing? In the spirit of simplification, it appears to me that we could get rid of CreateJob and SendDocument. I see little value to these operations given the current set of proposals on the table. The only thing I see is that I save resending the job attributes in the sequence CreateJob, SendDocument over the sequence Validate, PrintJob. Since a well behaved client would know the capabilities of the Printer it would normally not be necessary to validate job attributes and PrintJob would almost always be the preferred method to use. Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-archive Wed May 28 11:16:12 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA10069 for ipp-outgoing; Wed, 28 May 1997 11:13:42 -0400 (EDT) From: don@lexmark.com Message-Id: <199705281513.AA03858@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: rdebry@us.ibm.com Cc: ipp@pwg.org Date: Wed, 28 May 1997 11:13:45 -0400 Subject: Re: IPP>MOD - Too Many IPP Operations? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Roger: My understanding is as follows: ------------------- In the simple case of 1 job/1 document: PrintJob - Creates a job and send it to be printed. ------------------- Rather than overloading PrintJob we have added CreateJob to support multiple documents per job. CreateJob - Use to create a job on the server which responds with some job identifier SendDocument - Used multiple times to send the multiple documents which make up the job created with CreateJob With a server that does not support multiple documents per job, the CreateJob operation is rejected. The client can either split the multiple document job into multiple jobs or go look for a server that supports multiple documents per job. ------------------- ValidateJob is just as you describe. ------------------ Hope this helps! Don To: ipp%pwg.org @ interlock.lexmark.com cc: (bcc: Don Wright) From: rdebry%us.ibm.com @ interlock.lexmark.com @ LEXMTA Date: 05/28/97 10:18:34 AM AST Subject: IPP>MOD - Too Many IPP Operations? You all must pardon me if I am covering ground that has been covered before, but since I was not able to attend the IPP meetings last week my thinking may be a bit behind where everyone else is at. In reading through the minutes of the meeting and recent email on the discussion list, it seems to me that we may have invented more operations for IPP than we really need. It seems to me that we added CreateJob to allow a client to validate job attributes prior to sending all of the print data. The original send operation (which I think we are back to) simply transmits the print data. The deBry/Carter proposal to use multiple send Documents was not accepted. We are depending upon http chunking to allow the client to send the print data in pieces and upon tcp/ip to guarantee delivery. We added Validate and PrintJob to provide for the simple print case proposed by Microsoft. As I read the minutes and email it also seems that we generally agreed that well behaved clients would always know printer characteristics, either because the Printer has been "installed" on the desktop or the client has queried the capabilities of the printer. So as I see it, we are left with the following: CreateJob - used to validate the print job Validate - used to validate the print job SendDocument - its only value is to transmit the job data PrintJob - transmits the job data and the job attributes What am I missing? In the spirit of simplification, it appears to me that we could get rid of CreateJob and SendDocument. I see little value to these operations given the current set of proposals on the table. The only thing I see is that I save resending the job attributes in the sequence CreateJob, SendDocument over the sequence Validate, PrintJob. Since a well behaved client would know the capabilities of the Printer it would normally not be necessary to validate job attributes and PrintJob would almost always be the preferred method to use. Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-archive Wed May 28 11:41:14 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA10861 for ipp-outgoing; Wed, 28 May 1997 11:38:03 -0400 (EDT) From: Harry Lewis To: Cc: Subject: IPP> Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are Message-Id: <5030100002895066000002L062*@MHS> Date: Wed, 28 May 1997 11:40:03 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I wish I knew who wrote this... they did not sign it... I will insert comments with >HRL. >At 11:14 05/27/97 PDT, Harry Lewis wrote: >>Even printers that don't spool or queue will typically "buffer" some number of >>pages. >But isn't the definition of "queuing" on page 13, line 364, what you mean >by "buffering" some number of jobs? >HRL You could say that except the definition implies that the device can >HRL order - i.e. take some action regarding the order of jobs - whereas >HRL a buffer can only "stage" nor "order". We're splitting hairs. >>Given the possibility of single page jobs... then some jobs can be >>pending. I guess we should ask ourselves what it means to have a "mandatory" >>state. Just because a state is Mandatory does not mean an implementation must >>"force" jobs to enter that state. If that were so... I'd REALLY be in favor of >>eliminating the NeedsAttention state! ;-> >We keep getting confused by whether a MIB is talking about the printer >or is talking about what the agent shall show about the printer. >I claim that MIBs are all about the latter and nothing to do with >the former. >HRL You've mesmerized me, here. By the way... this is a *job* MIB. >See my early answer to Ron about the completed state. >HRL Who are you? >Most printers won't have such a state, the printer throws the job away as soon >as it >is printed. Its the agent that has to keep the job information in the >MIB tables for the time indicated in the jmGeneralJobPersistence object. >If the 'completed' state were conditionally mandatory, then an agent would >only have to show jobs in the 'completed' state, if the device implemented >the completed state. But we aren't going to allow agents off the hook. >The agent has to implement the 'completed' state. Same for 'aborted'. >HRL Now I'm slipping into a coma. We're talking about a *job* agent here >HRL that is *embedded* in the device, totally for the purpose of representing >HRL what is happening with the *job* in the device. Why are you making a >HRL distinction between the agent and the device? Besides. We can't go on >HRL discussing which jmJobState values are mandatory! The OID is mandatory, >HRL and there are a list of possible values. If that possibility never >HRL becomes reality, that object never assumes that value! >'canceled', is conditionally mandatory, because level 1 IPP doesn't require >the CancelJob operation. So we aren't going to force agents to show >a canceled state, except for printers that implement a CancelJob operation. >For needsAttention, is impossible to design a device that handles paper >that doesn't need attention some time (unless it plants, grows, harvests trees, >makes paper, and fixes all jams). So making needsAttention Mandatory forces >the agent to show jobs in the needsAttention state, if the printer jams. Harry Lewis - IBM Printing Systems From ipp-archive Wed May 28 12:11:20 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA11668 for ipp-outgoing; Wed, 28 May 1997 12:06:34 -0400 (EDT) From: don@lexmark.com Message-Id: <199705281606.AA06284@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: pwg@pwg.org, PMP@pwg.org, JMP@pwg.org, ipp@pwg.org, P1394@pwg.org Date: Wed, 28 May 1997 12:06:42 -0400 Subject: IPP> Separation of PWG and IETF activities Mime-Version: 1.0 Content-Type: multipart/mixed; Boundary="0__=urMNDk2o5XVzGdWekujhtsUfoBTmt3cAIGtAR9IuAu15Iz68vvLy1BkC" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO --0__=urMNDk2o5XVzGdWekujhtsUfoBTmt3cAIGtAR9IuAu15Iz68vvLy1BkC Content-type: text/plain; charset=us-ascii (Embedded image moved to file: PIC29258.PCX) To: pwg@pwg.org, PMP@pwg.org, JMP@pwg.org, ipp@pwg.org, P1394@pwg.org cc: From: Don Wright @ LEXMARK@LEXMTA Date: 05/28/97 12:06:42 PM Subject: Separation of PWG and IETF activities Through the course of the last few weeks, there have been a number of cases where the activities of the PWG and the IETF have been confused. In order to clearly separate the two, I think the following needs to happen: 1) We need to add a disclaimer to the PWG home page clearly indicating: The contents of these WEB pages reflect work done by the people of the Printer Working Group which may or may not be submitted to the IETF, IEEE or other standards organizations. Official IETF, IEEE, or other standards organization documents, if available, will be found on their WEB page, FTP server or other service. 2) We need to clearly separate PWG administrative e-mail from IETF working groups technical and administrative e-mail. Therefore, according to my understanding, since meetings of the PWG are not "official" IETF activities, all future PWG meeting notices will ONLY be sent to the PWG mailing list and not to the PMP, JMP, or IPP lists. In contrast, the IEEE does sanction the regular meetings of a working group. Since the 1394 printing effort is a study group and hopefully soon an official working group, a more liberal policy will be applied to the P1394 mailing list. I am not sure how to handle the notices of meeting minutes but my first pass at it says that PWG meeting minutes for IPP, JMP and PMP should not be posted or acknowledged on these lists. (If a meeting "didn't happen" how can minutes exist?) Am I going too far? To insure the broadest possible distribution, I have posted this message to all the appropriate mailing lists and I encourage a BRIEF discussion of this proposal but ONLY on the PWG mailing list. Thanks! 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 * ************************************************************* --0__=urMNDk2o5XVzGdWekujhtsUfoBTmt3cAIGtAR9IuAu15Iz68vvLy1BkC Content-type: application/octet-stream; name="PIC29258.PCX" Content-transfer-encoding: base64 CgMBAQAAAAA4AgMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABSAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADl/9L/yf/F/8L/geUA0gDJAMUAAAGE5QDSAMkAxQAAAcHw5f/S/8n/xf/C /7g= --0__=urMNDk2o5XVzGdWekujhtsUfoBTmt3cAIGtAR9IuAu15Iz68vvLy1BkC-- From ipp-archive Wed May 28 12:21:32 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA12596 for ipp-outgoing; Wed, 28 May 1997 12:18:29 -0400 (EDT) Message-Id: <9705281615.AA00777@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, 28 May 1997 09:13:55 PDT To: ipp@pwg.org, jmp@pwg.org, Peter Zehler From: Tom Hastings Subject: IPP> RE: Should 'pending' be a mandatory state or not? Cc: JK Martin Sender: ipp-owner@pwg.org Precedence: bulk Status: RO How about we keep pending as CONDITIONALLY MANDATORY, but state the condition: The pending state shall be implemented if jobs may not be able to be proessed for human noticable amount of time, such as a second or more, in certain circumstances. How about if the Job Monitoring spec states the condition: on all CONDITIONALLY MANDATORY attributes? On all CONDITIONALLY MANDATORY enum values? Tom At 04:57 05/28/97 PDT, Peter Zehler wrote: >Tom, >The amount of time a job would be in the pending state on a non-queueing > non-spooling printer could be noticable to humans. It is dependant on the >size of the print jobs on the other channels. >I think it would simplify things just to have the pending state mandatory. >Implementations could step through this state so quickly it would never be >noticable to humans. >Pete > > >Peter, > >How long would a job be in the pending state in your non-queuing, non-spooling >IPP system? > >If the time is not noticable to humans, e.g., 100s of miliseconds, I would >think that there wan't much point in simplementin the IPP state of 'pending'. >If it was longer, so that end-users would see it for a while, while nothing >was happending on the printer, then it would be good to implemente the >IPP 'pending' state for your Printer object. > >So your point was not that 'pending' must be a Mandatory state, but >that in your implementation of a simple, non-queuing, non-spooling printer >you wanted to be able to implement 'pending'. So we just have to find >language that permits non-queuing, non-spooling printers to implement >'pending', but doesn't require it. > >On the other hand, it might be simpler to mandate the 'pending' state >and for implementations that don't queue or spool, the state would >never be visible or would be visible for a very short period of time. > >Tom > > > > From ipp-archive Wed May 28 12:26:27 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA13220 for ipp-outgoing; Wed, 28 May 1997 12:24:24 -0400 (EDT) From: Roger K Debry To: Cc: Subject: Re: IPP>MOD - Too Many IPP Operations? Message-Id: <5030100002897240000002L002*@MHS> Date: Wed, 28 May 1997 12:26:15 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO We should not design a protocol that depends upon failure of an operation in order for clients to know what to do next. If the client doesn't know what the Printer is capable of doing it should ask, not assume something works and wait to see if it does or not. Sure, we have to consider what happens when an operation fails, but we should not require failure to occur in order to do simple operations. The logic you suggest seems complex and poor design. It puts extra burden on the client, which I would think we want to keep as simple as possible. The client logic ought to be: Do I know I know about the Printer? If no - query the printer, otherwise go ahead Send a PrintJob operation with the job attributes and the document(s) to be printed. If the response to the query tells me that the Printer only supports one document per job, I will do multiple PrintJobs, otherwise I will put all of the documents in one PrintJob. I don't view this as overloading the PrintJob operation. 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 05/28/97 10:04 AM --------------------------- don @ lexmark.com 05/28/97 09:22 AM Please respond to don@lexmark.com @ internet To: Roger K Debry/Boulder/IBM cc: ipp @ pwg.org @ internet Subject: Re: IPP>MOD - Too Many IPP Operations? Roger: My understanding is as follows: ------------------- In the simple case of 1 job/1 document: PrintJob - Creates a job and send it to be printed. ------------------- Rather than overloading PrintJob we have added CreateJob to support multiple documents per job. CreateJob - Use to create a job on the server which responds with some job identifier SendDocument - Used multiple times to send the multiple documents which make up the job created with CreateJob With a server that does not support multiple documents per job, the CreateJob operation is rejected. The client can either split the multiple document job into multiple jobs or go look for a server that supports multiple documents per job. ------------------- ValidateJob is just as you describe. ------------------ Hope this helps! Don To: ipp%pwg.org @ interlock.lexmark.com cc: (bcc: Don Wright) From: rdebry%us.ibm.com @ interlock.lexmark.com @ LEXMTA Date: 05/28/97 10:18:34 AM AST Subject: IPP>MOD - Too Many IPP Operations? You all must pardon me if I am covering ground that has been covered before, but since I was not able to attend the IPP meetings last week my thinking may be a bit behind where everyone else is at. In reading through the minutes of the meeting and recent email on the discussion list, it seems to me that we may have invented more operations for IPP than we really need. It seems to me that we added CreateJob to allow a client to validate job attributes prior to sending all of the print data. The original send operation (which I think we are back to) simply transmits the print data. The deBry/Carter proposal to use multiple send Documents was not accepted. We are depending upon http chunking to allow the client to send the print data in pieces and upon tcp/ip to guarantee delivery. We added Validate and PrintJob to provide for the simple print case proposed by Microsoft. As I read the minutes and email it also seems that we generally agreed that well behaved clients would always know printer characteristics, either because the Printer has been "installed" on the desktop or the client has queried the capabilities of the printer. So as I see it, we are left with the following: CreateJob - used to validate the print job Validate - used to validate the print job SendDocument - its only value is to transmit the job data PrintJob - transmits the job data and the job attributes What am I missing? In the spirit of simplification, it appears to me that we could get rid of CreateJob and SendDocument. I see little value to these operations given the current set of proposals on the table. The only thing I see is that I save resending the job attributes in the sequence CreateJob, SendDocument over the sequence Validate, PrintJob. Since a well behaved client would know the capabilities of the Printer it would normally not be necessary to validate job attributes and PrintJob would almost always be the preferred method to use. Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-archive Wed May 28 12:41:24 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA14254 for ipp-outgoing; Wed, 28 May 1997 12:39:03 -0400 (EDT) From: don@lexmark.com Message-Id: <199705281639.AA07674@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: rdebry@us.ibm.com Cc: ipp@pwg.org Date: Wed, 28 May 1997 12:39:01 -0400 Subject: Re: IPP>MOD - Too Many IPP Operations? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Roger: I don't think the intent was that the only way to know if a printer supports multiple documents per job was through the failure of the CreateJob operation. The intent was that if the client failed to ask, a predictable response, i.e. a failure, would be returned and could be acted upon. This also insured that the client could learn of the failure early: prior to posting megabytes of data to a printer that couldn't support printing the multi-document print job. Using SendDocument to clearly separate the multiple documents within a job was deemed to be good by those in attendance. Using CreateJob to start the process of printing a multiple document job where all the documents were not going to be sent in a single POST was deemed worthy of a separate operation rather than a PrintJob with a special attribute indicating there were multiple documents within a single PrintJob. And, as I said above, it also made it easier for the simple implementation to deal with the case where, through an error on the client-end, a multi-document job was sent to a printer that couldn't support thatfunctionality. Don To: Don Wright cc: ipp%pwg.org @ interlock.lexmark.com From: rdebry%us.ibm.com @ interlock.lexmark.com @ LEXMTA Date: 05/28/97 12:26:15 PM AST Subject: Re: IPP>MOD - Too Many IPP Operations? We should not design a protocol that depends upon failure of an operation in order for clients to know what to do next. If the client doesn't know what the Printer is capable of doing it should ask, not assume something works and wait to see if it does or not. Sure, we have to consider what happens when an operation fails, but we should not require failure to occur in order to do simple operations. The logic you suggest seems complex and poor design. It puts extra burden on the client, which I would think we want to keep as simple as possible. The client logic ought to be: Do I know I know about the Printer? If no - query the printer, otherwise go ahead Send a PrintJob operation with the job attributes and the document(s) to be printed. If the response to the query tells me that the Printer only supports one document per job, I will do multiple PrintJobs, otherwise I will put all of the documents in one PrintJob. I don't view this as overloading the PrintJob operation. 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 05/28/97 10:04 AM --------------------------- don @ lexmark.com 05/28/97 09:22 AM Please respond to don@lexmark.com @ internet To: Roger K Debry/Boulder/IBM cc: ipp @ pwg.org @ internet Subject: Re: IPP>MOD - Too Many IPP Operations? Roger: My understanding is as follows: ------------------- In the simple case of 1 job/1 document: PrintJob - Creates a job and send it to be printed. ------------------- Rather than overloading PrintJob we have added CreateJob to support multiple documents per job. CreateJob - Use to create a job on the server which responds with some job identifier SendDocument - Used multiple times to send the multiple documents which make up the job created with CreateJob With a server that does not support multiple documents per job, the CreateJob operation is rejected. The client can either split the multiple document job into multiple jobs or go look for a server that supports multiple documents per job. ------------------- ValidateJob is just as you describe. ------------------ Hope this helps! Don To: ipp%pwg.org @ interlock.lexmark.com cc: (bcc: Don Wright) From: rdebry%us.ibm.com @ interlock.lexmark.com @ LEXMTA Date: 05/28/97 10:18:34 AM AST Subject: IPP>MOD - Too Many IPP Operations? You all must pardon me if I am covering ground that has been covered before, but since I was not able to attend the IPP meetings last week my thinking may be a bit behind where everyone else is at. In reading through the minutes of the meeting and recent email on the discussion list, it seems to me that we may have invented more operations for IPP than we really need. It seems to me that we added CreateJob to allow a client to validate job attributes prior to sending all of the print data. The original send operation (which I think we are back to) simply transmits the print data. The deBry/Carter proposal to use multiple send Documents was not accepted. We are depending upon http chunking to allow the client to send the print data in pieces and upon tcp/ip to guarantee delivery. We added Validate and PrintJob to provide for the simple print case proposed by Microsoft. As I read the minutes and email it also seems that we generally agreed that well behaved clients would always know printer characteristics, either because the Printer has been "installed" on the desktop or the client has queried the capabilities of the printer. So as I see it, we are left with the following: CreateJob - used to validate the print job Validate - used to validate the print job SendDocument - its only value is to transmit the job data PrintJob - transmits the job data and the job attributes What am I missing? In the spirit of simplification, it appears to me that we could get rid of CreateJob and SendDocument. I see little value to these operations given the current set of proposals on the table. The only thing I see is that I save resending the job attributes in the sequence CreateJob, SendDocument over the sequence Validate, PrintJob. Since a well behaved client would know the capabilities of the Printer it would normally not be necessary to validate job attributes and PrintJob would almost always be the preferred method to use. Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-archive Wed May 28 12:56:15 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA15373 for ipp-outgoing; Wed, 28 May 1997 12:53:26 -0400 (EDT) Message-Id: <3.0.1.32.19970528094120.00aecd80@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 28 May 1997 09:41:20 PDT To: Roger K Debry , From: Carl-Uno Manros Subject: Re: IPP>MOD - Too Many IPP Operations? In-Reply-To: <5030100002891502000002L022*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Roger, I think you are right that the functionality of the new vs. old operations is not yet spelled out sufficiently. I think we need more detailed descriptions of what each operation can submit and what responses it can get. By introducing the concept of level 1 (simple) and level 2 (full) IPP, we also need some means for the client to quickly find out what the server supports. My suggestion is that if you start off with a Validate operation, it will return either level 1 vs. level 2 supported, or alternatively give back a more detailed list of which operations are supported. The latter approach would allow us more flexibility in the future if we want to add new operations. Would we allow an implementation to support say Print Job and Get Attributes, but not Create Job and Send Document? (level 1.5) The same information would be returned of you ask for Printer attributes (hence we need a new attribute for this). This leaves us with the case where the client starts off with a Create Job operation, and the Printer only supports level 1, in which case the response needs to contain an error stating either "level not supported" or "opearation not supported". Carl-Uno At 07:18 AM 5/28/97 PDT, Roger K Debry wrote: >You all must pardon me if I am covering ground that has been covered >before, but since I was not able to attend the IPP meetings last week my >thinking may be a bit behind where everyone else is at. > >In reading through the minutes of the meeting and recent email on the >discussion list, it seems to me that we may have invented more >operations for IPP than we really need. It seems to me that we added >CreateJob to allow a client to validate job attributes prior to sending >all of the print data. The original send operation (which I think we are >back to) simply transmits the print data. The deBry/Carter proposal >to use multiple send Documents was not accepted. We are >depending upon http chunking to allow the client to send the >print data in pieces and upon tcp/ip to guarantee delivery. >We added Validate and PrintJob to provide for the simple print case >proposed by Microsoft. As I read the minutes and email it also seems >that we generally agreed that well behaved clients would always know >printer characteristics, either because the Printer has been "installed" >on the desktop or the client has queried the capabilities of the printer. > >So as I see it, we are left with the following: > >CreateJob - used to validate the print job >Validate - used to validate the print job > >SendDocument - its only value is to transmit the job data >PrintJob - transmits the job data and the job attributes > >What am I missing? In the spirit of simplification, it appears to me that we >could get rid of CreateJob and SendDocument. I see little value to >these operations given the current set of proposals on the table. The >only thing I see is that I save resending the job attributes in the sequence >CreateJob, SendDocument over the sequence Validate, PrintJob. Since >a well behaved client would know the capabilities of the Printer it would >normally not be necessary to validate job attributes and PrintJob >would almost always be the preferred method to use. > 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 May 28 13:11:18 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA15881 for ipp-outgoing; Wed, 28 May 1997 13:09:05 -0400 (EDT) Message-Id: <9705281701.AA00845@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" X-Priority: 2 (High) Date: Wed, 28 May 1997 09:59:05 PDT To: ipp@pwg.org, jmp@pwg.org, Robert.Herriot@eng.sun.com (Robert Herriot) From: Tom Hastings Subject: IPP> RE: Bob Herriot's IPP/JMP 2 new states proposal Cc: rbergma@dpc.com Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Ron Bergman, Harry Lewis and I have reviewed Bob's proposal to add two new states: pending-stopped and processing-stopped. We all like it a lot. We think that the other JMP participants will too. Carl-Uno has agreed to cover the joint IPP/JMP job-state/job-state-reasons spec in the first 15 minutes of the IPP telecon today, so that JMP participants need not stay on the line for the major topic of the protocol. (We know that Harry can't make it, but gives his support). So JMP particpants please call in for 15 minutes at: May 28 ------ Call-in: 1-309-671-1035 Access: 190148 Time: 1-3pm PDT (4-6 EDT) So the updated state transition diagram would become: For IPP: The following figure shows the normal job state transitions. Other transitions are unlikely, but are not forbidden. +--> canceled / pending -----> processing --+----> aborted ^ ^ \ | | +--> completed v v pending-stopped processing-stopped Figure 1 - Normal job state transitions Normally a job progresses only from left to right. For JMP: -- The following figure shows the normal job state transitions. -- Other transitions are unlikely, but are not forbidden. -- -- +---> canceled(7) -- / -- pending(3) ------> processing(5) --+-----> aborted(8) -- ^ ^ \ -- | | +---> completed(9) -- v v -- pending-stopped(4) processing-stopped(5) -- -- <----------------- active -------------->|<-- in-active -->| -- Normally a job progresses only from left to right. We only have 15 minutes, so we may have to consider the following later: Remaining details of the agreement: Do we remove the MANDATORY printer-stopped job-state-reasons value from IPP? Do we remove the MANDATORY deviceStopped jmJobStateReaons1 value from JMP? My suggestion it yes. What about the OPTIONAL printer-stopped-partly job-state-reasons value from IPP? And the OPTIONAL deviceStoppedPartly jmJobStateReasons1 value from JMP? My suggestion is no. Its unlikely to be implemented, but can be. Finally, job-state-reasons is MANDATORY in IPP. Should it remain MANDATORY in JMP or become CONDITIONALLY MANDATORY? What about the remaining MANDATORY values: MAN jobIncoming OPT jobOutgoing CM jobHeld CM jobHoldSpecified, jobHeld CM jobHoldUntilSpecified, jobHeld CM jobHoldUntilResourcesAreReady,jobHeld CM jobProcessAfterSpecified, jobHeld OPT deviceStoppedPartly MAN deviceStopped OPT jobPrinting CM jobCanceledByUser CM jobCanceledByOperator OPT logfilePending OPT logfileTransferring MAN jobCompletedSuccessfully MAN jobCompletedWithWarnings MAN jobCompletedWithErrors MAN = MANDATORY - a conforming agent shall implement CM = CONDITIONALLY MANDATORY - a conforming agent shall implement only if the device has this behavior. OPT = OPTIONAL - a conforming agent need not implement even if the device has the behavior. If all of the values become CONDITIONALLY MANDATORY or OPTIONAL, then jmJobStateReasons1 can be changed from MANDATORY to CONDITIONALLY MANDATORY too (and be moved from the jmJobTable, back to the jmAttributeTable). Tom At 14:39 05/27/97 PDT, Robert Herriot wrote: > >There has been a lot of discussion on the JMP list about the held >and needs-attention state. > >Several people have stated that the primary reason for having 'held' >and 'needs-attention' as job-states rather than job-state-reason is >that the job-state should be all that most people need to look at. > >Keeping that in mind, here's is an slightly different view that we >should perhaps consider. I put this forth for discussion and can >see pro's and con's for keeping the simple 5 job-states of IPP versus >adding these two additional states. > >The Proposal: > >Change the name of "needs-attention" to "stopped-printing" and define >the "stopped-printing" state as an alternate view of the "processing" >state. A job is in the "stopped-printing" state when certain >job-state-reasons take it out of the "processing" state temporarily. >When those reasons clear, the job goes back to the "processing" state. > >Likewise, the "held" job-state is an alternate view of the "pending" >state. A job is in the "held" state when certain job-state-reasons >take it out of the "pending" state temporarily. When those reasons >clear, the job goes back to the "pending" state. Such reasons include >"held-until" (aka "job-hold-until-specified"), "held-for-resources" >(aka "required-resources-not-ready"), and "printer-stopped". > >Any reasons that keeps a job from making progress towards the printer >put it in the "held" state. Any reasons that keep a job from >processing put it in the "stopped-printing state. > >Note that the "printing-stopped" reason changes a "processing" job to >"stopped-printing" and a "pending" job to a "held" job. > >If we want more regular names, then we should call "held", "pending-stopped" >and we should call "stopped-printing", "processing-stopped". > >Note: I do not like the name "needs-attention" because it is the printer >that needs attention and not the job. Furthermore, the printer may need >attention even when a particular job is pending. > >Comments? > >Bob Herriot > > From ipp-archive Wed May 28 13:46:16 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA16544 for ipp-outgoing; Wed, 28 May 1997 13:41:19 -0400 (EDT) Message-Id: <3.0.1.32.19970528103311.009856d0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 28 May 1997 10:33:11 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC - PWG Phone Conference on IPP Security - May 29, 1 - 3 pm PST Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO PWG Phone Conference on IPP Security - May 29, 1 - 3 pm PST Agenda Review and comment on Roger's latest Security draft text. Discuss and propose security attributes that we need to include in the Directory Schema document. Discuss and propose text on security to go into the HTTP 1.1 mapping document. Dial-in number: 1-800-857 5607 Passcode: cmanros As I will be out of the office, the call will be led by Roger deBry. 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 May 28 14:01:20 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA17368 for ipp-outgoing; Wed, 28 May 1997 13:53:43 -0400 (EDT) Message-ID: <338C7254.B2C51319@sharplabs.com> Date: Wed, 28 May 1997 10:58:45 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.0b5 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP>MOD - Too Many IPP Operations? X-Priority: 3 (Normal) References: <5030100002891502000002L022*@MHS> Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Roger K Debry wrote: > You all must pardon me if I am covering ground that has been covered > before, but since I was not able to attend the IPP meetings last week > my > thinking may be a bit behind where everyone else is at. > > In reading through the minutes of the meeting and recent email on the > discussion list, it seems to me that we may have invented more > operations for IPP than we really need. It seems to me that we added > CreateJob to allow a client to validate job attributes prior to > sending > all of the print data. The original send operation (which I think we > are > back to) simply transmits the print data. The deBry/Carter proposal > to use multiple send Documents was not accepted. We are > depending upon http chunking to allow the client to send the > print data in pieces and upon tcp/ip to guarantee delivery. > We added Validate and PrintJob to provide for the simple print case > proposed by Microsoft. As I read the minutes and email it also seems > that we generally agreed that well behaved clients would always know > printer characteristics, either because the Printer has been > "installed" > on the desktop or the client has queried the capabilities of the > printer. > > So as I see it, we are left with the following: > > CreateJob - used to validate the print job > Validate - used to validate the print job > > SendDocument - its only value is to transmit the job data > PrintJob - transmits the job data and the job attributes > > What am I missing? In the spirit of simplification, it appears to me > that we > could get rid of CreateJob and SendDocument. I see little value to > these operations given the current set of proposals on the table. > The > only thing I see is that I save resending the job attributes in the > sequence > CreateJob, SendDocument over the sequence Validate, PrintJob. Since > a well behaved client would know the capabilities of the Printer it > would > normally not be necessary to validate job attributes and PrintJob > would almost always be the preferred method to use. You are not considering the other advantages of the 'CreateJob' operation. The 'Validate' option only validates a set of attributes against what a particular object supports. It has no relationship to a job. Meaning that just because you send a 'Validate' request, does not necessarily mean that a print job is next in the sequence. The 'CreateJob' not only validates attributes but also determines whether or not resources can be applied NOW to processing a job with these requirements. Also, 'CreateJob' returns the URI for the job object created immediately so you have some way to either do a 'GetAttributes' or a 'Cancel' on the job if either one of these operations is required. If you're looking to delete operations, 'Validate' would go before 'CreateJob' IMHO. Randy > Roger K deBry > Senior Techncial Staff Member > Architecture and Technology > IBM Printing Systems > email: rdebry@us.ibm.com > phone: 1-303-924-4080 From ipp-archive Wed May 28 14:36:16 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA17936 for ipp-outgoing; Wed, 28 May 1997 14:35:29 -0400 (EDT) Message-ID: <338C7C1F.BD579025@sharplabs.com> Date: Wed, 28 May 1997 11:40:31 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.0b5 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> Re: New protocol document & Security issues X-Priority: 3 (Normal) References: <9705281215.AA14057@cabeza.cp10.es.xerox.com> Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Precedence: bulk Status: RO John Wenn wrote: > There are a couple of security issues involved in the latest protocol > document. They cover sections 5.5, 5.7, 6.x, 6.y & 7. > > The issues are basically in two areas. > > (1) You should be using HTTP Digest Authentication (rfc2069), not HTTP > Basic > Authentication. Basic authentication provides zero security > (unencrypted > username and passwords are sent over the wire). Digest authentication > > provides moderate security. So reference Digest authentication is > section > 5.5. The headers used for Digest authentication are the same > (Authorization, > Proxy-Authorization, WWW-Authenticate, Proxy-Authenticate), but they > have > different values. Since the paper doesn't go into details, the other > sections > should be fine as they are. We talked about basic authentication in Memphis and we decided that low-end IPP servers could use this because it is simple. We really only need two levels of security, simple and advanced, for interoperability's sake. The simple case would be basic auth., which alot of vendors are already supporting (username and password) in their products. The advanced case would be something like SSL or TLS/SSL, something that meets all of the security requirements discussed in past meetings. In my opinion, just two security models is all we need. > (2) Not all authentication / authorization is done via HTTP. For > example, the > connection may be made using SSL. In that case, SSL provides the > authentication needed. While the sections are generally good about > saying > HTTP authentication is used when needed, somewhere the fact that other > > security mechanisms are used should be made explicit. Within the context of the document (basic HTTP authentication) simple security is all within HTTP. We are defining a mapping document for IPP over HTTP so I have to list HTTP-specific mechanisms for IPP security. These are implementation conformance requirments. However, the overall "Security Considerations" section should be fleshed out with all of the information that we think is necessary for security between IPP clients and servers, whether they are actually in the IPP protocol mapping itself, or, at a layer beneath the IPP/HTTP layer (such as through an API like SSL or TLS/SSL or other). Randy > And, of course, section 7 (security considerations) needs to be > rewritten, but > the security group should do that. > > /John From ipp-archive Wed May 28 14:41:19 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA17957 for ipp-outgoing; Wed, 28 May 1997 14:37:56 -0400 (EDT) Mime-Version: 1.0 Date: Wed, 28 May 1997 14:42:39 -0400 Message-ID: <00017621.1337@digprod.com> From: bwagner@digprod.com (Bill Wagner) Subject: Re: IPP> RE: Should 'pending' be a mandatory state or not? To: ipp@pwg.org, jmp@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: bulk Status: RO It might help if someone indicated what it meant for a state enum to be mandatory or conditionally mandatory. Does mandatory mean that: 1. each job must go though that state and be reported? 2. if the job goes through the state, it must be reported? Does conditionally mandatory mean that: 2. if the job goes through the state, it must be reported? 3. the unit report it if it is able to? I maintain that (1) is unreasonable, since as pointed out, depending upon the implementation, the state may be highly transitory and may not persist long enough to be observed. (2) is reasonable, how ever you wish to define it. I believe it is what Ron suggested. (3) means nothing in terms of consistency, and is useless. Bill Wagner Osicom/DPI ______________________________ Reply Separator _________________________________ Subject: IPP> RE: Should 'pending' be a mandatory state or not? Author: Tom Hastings at Internet Date: 5/28/97 9:13 AM How about we keep pending as CONDITIONALLY MANDATORY, but state the condition: The pending state shall be implemented if jobs may not be able to be proessed for human noticable amount of time, such as a second or more, in certain circumstances. How about if the Job Monitoring spec states the condition: on all CONDITIONALLY MANDATORY attributes? On all CONDITIONALLY MANDATORY enum values? Tom From ipp-archive Wed May 28 15:13:05 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA19101 for ipp-outgoing; Wed, 28 May 1997 15:04:02 -0400 (EDT) From: Roger K Debry To: Cc: Subject: Re: IPP>MOD - Too Many IPP Operations? Message-Id: <5030100002904682000002L022*@MHS> Date: Wed, 28 May 1997 15:06:06 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Randy Turner wrote: You are not considering the other advantages of the 'CreateJob' operation. The 'Validate' option only validates a set of attributes against what a particular object supports. It has no relationship to a job. Meaning that just because you send a 'Validate' request, does not necessarily mean that a print job is next in the sequence. RKD> No, but it might be. The 'CreateJob' not only validates attributes but also determines whether or not resources can be applied NOW to processing a job with these requirements. RKD> This must mean that upon receiving a CreateJob, the RKD> Printer promises to maintain the state it was in with RKD> respect to requested resources until the print job RKD> is complete. Is this agreed? RKD> Does a client send CreateJob, assuming that if resources are RKD> not ready that the Printer will schedule the job accordingly, RKD> i.e. schedule all jobs waiting for A4 paper to print when A4 RKD> paper is loaded, or does a client keep "pinging" the Printer RKD> with CreateJobs until it finds the resources are ready, then RKD> consummates the print job by sending the data? RKD> If we believe that the first is the preferred method for RKD> handling jobs waiting for resources then I claim that just RKD> using the PrintJob operation works as well as CreateJob and RKD> SendDocument since I don't care if the resources are actually RKD> ready NOW or not (and I doubt that I want to keep "pinging" RKD> the Printer to find out). Also, 'CreateJob' returns the URI for the job object created immediately so you have some way to either do a 'GetAttributes' or a 'Cancel' on the job if either one of these operations is required. RKD> Doesn't PrintJob return a URI? If not why doesn't it? If you're looking to delete operations, 'Validate' would go before 'CreateJob' IMHO. From ipp-archive Wed May 28 15:14:08 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA19403 for ipp-outgoing; Wed, 28 May 1997 15:10:36 -0400 (EDT) Message-ID: <338C845A.33F6D9C9@sharplabs.com> Date: Wed, 28 May 1997 12:15:38 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.0b5 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP>MOD - Too Many IPP Operations? X-Priority: 3 (Normal) References: <5030100002904682000002L022*@MHS> Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Roger K Debry wrote: > Randy Turner wrote: > > You are not considering the other advantages of the 'CreateJob' > operation. The 'Validate' option only validates a set of > attributes against what a particular object supports. It > has no relationship to a job. Meaning that just because > you send a 'Validate' request, does not necessarily mean > that a print job is next in the sequence. > > RKD> No, but it might be. > > The 'CreateJob' not only validates attributes but also > determines whether or not resources can be applied NOW > to processing a job with these requirements. > > RKD> This must mean that upon receiving a CreateJob, the > RKD> Printer promises to maintain the state it was in with > RKD> respect to requested resources until the print job > RKD> is complete. Is this agreed? Yes, to some degree, its possible that the server has locked down one or moreresources to process this job. > RKD> Does a client send CreateJob, assuming that if resources are > RKD> not ready that the Printer will schedule the job accordingly, > RKD> i.e. schedule all jobs waiting for A4 paper to print when A4 > RKD> paper is loaded, or does a client keep "pinging" the Printer > RKD> with CreateJobs until it finds the resources are ready, then > RKD> consummates the print job by sending the data? It depends upon the type of 'resource' that may or may not be available. In your example, you specify media as the resource in question (A4). This is only one of numerous possible types of resources. The response to a 'CreateJob' operation (and the clients reaction to this response) is really dependent upon the type of resource allocation problem that might occur, as specified by the clients explicit or implicit job requirements. > RKD> If we believe that the first is the preferred method for > RKD> handling jobs waiting for resources then I claim that just > RKD> using the PrintJob operation works as well as CreateJob and > RKD> SendDocument since I don't care if the resources are actually > RKD> ready NOW or not (and I doubt that I want to keep "pinging" > RKD> the Printer to find out). An out of resources condition is definitely going to happen, and yes,implementations will have to incorporate retries (much like LPD does today) in order to see that the job is printed. > Also, 'CreateJob' > returns the URI for the job object created immediately so you have > some > way to either do a 'GetAttributes' > or a 'Cancel' on the job if either one of these operations is > required. > > RKD> Doesn't PrintJob return a URI? If not why doesn't it? Yes, 'PrintJob' does return a URI, but only after all of your job data has been transferred. Over the internet, this is completely non-deterministic. Randy > If you're looking to delete operations, 'Validate' would go before > 'CreateJob' IMHO. From ipp-archive Wed May 28 15:31:29 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA20102 for ipp-outgoing; Wed, 28 May 1997 15:22:50 -0400 (EDT) Message-Id: <9705281922.AA00943@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, 28 May 1997 12:20:13 PDT To: Paul Moore From: Tom Hastings Subject: RE: IPP> Re: Unsigned integer count for attribute name keywords and attribute values Cc: "'Scott Isaacson'" , Robert.Herriot@eng.sun.com, ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Gee. I thought that we agreed that attribute values were keywords, not numbers. That is why there is a count for every attribute value. Ok? Sorry I didn't see this mail message until now. Tom At 10:46 05/21/97 PDT, Paul Moore wrote: >The length ot the attribute name is 2 bytes. > >The one that I think is much more interesting - which we did not drill >into - is keyword values for attributes. I still have those as 2 byte >enumerations. I think this is the right thing to do and Tom agreed at >the meeting but there was not a lot of discusion. > >Eg Operation has two values 1 (which means Validate) and 2 (meaning >printjob). >DocumentFormat uses the rfc1759 values >etc. So these values should be key words, not enums, ok? Tom > >> -----Original Message----- >> From: Scott Isaacson [SMTP:SISAACSON@novell.com] >> Sent: Wednesday, May 21, 1997 9:32 AM >> To: hastings@cp10.es.xerox.com; Robert.Herriot@Eng.Sun.COM; Paul >> Moore >> Cc: ipp@pwg.org >> Subject: IPP> Re: Unsigned integer count for attribute name >> keywordsandattribute values >> >> >> >> >>> Robert Herriot 05/20 1:37 PM >>> >> >> > Did we agree to one or two bytes for the length of attribute names? >> I >> > thought two, just in case we ever use Unicode rather than UTF-8 to >> > encode attribute names. We wouldn't want the attributes to then be >> > limited to 127 characters. >> >> I thought all lengths would be 2 or 4 bytes, never just 1. I thought >> we >> limited attribute names to be the same as keywords now: US ASCII >> characters >> >> (a-zA-Z), digits (0-9), hyphen (-) and underscore (_). We all know >> the >> consequences of not being able to internationalize these attribute >> names, >> but why are you suggesting maybe someday worrying about UTF-8 for >> attribute >> names? >> >> Scott >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > From ipp-archive Wed May 28 15:51:17 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA20632 for ipp-outgoing; Wed, 28 May 1997 15:49:30 -0400 (EDT) Message-Id: <3.0.1.32.19970528124403.00a4f100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 28 May 1997 12:44:03 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> Re: New protocol document & Security issues In-Reply-To: <338C7C1F.BD579025@sharplabs.com> References: <9705281215.AA14057@cabeza.cp10.es.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Randy, a couple of comments to your latest comments below. At 11:40 AM 5/28/97 PDT, you wrote: >We talked about basic authentication in Memphis and we decided that >low-end IPP >servers could use this because it is simple. We really only need two >levels of security, >simple and advanced, for interoperability's sake. The simple case would >be basic auth., >which alot of vendors are already supporting (username and password) in >their products. >The advanced case would be something like SSL or TLS/SSL, something that >meets >all of the security requirements discussed in past meetings. In my >opinion, just two >security models is all we need. When you say that we discussed this in Memphis, I think that you might have a different view of what was meant with "simple security". You can certainly use the basic stuff that is in your document, but if used, that will fall into the category "no security" as seen by the SEC subgroup. What we mean by "simple security" is the stuff in RFC 2069, and "avanced security" would be things like TSL (equal to SSL3). If you are unhappy with this, I suggest you join in the SEC subfroup discussions. The SEC subgroup will soon have a new draft for review. 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 May 28 16:11:17 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA21164 for ipp-outgoing; Wed, 28 May 1997 16:07:23 -0400 (EDT) From: Roger K Debry To: Cc: Subject: Re: IPP>MOD - Too Many IPP Operations? Message-Id: <5030100002907497000002L072*@MHS> Date: Wed, 28 May 1997 16:09:27 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO ... snip ... > > The 'CreateJob' not only validates attributes but also > determines whether or not resources can be applied NOW > to processing a job with these requirements. > > RKD> This must mean that upon receiving a CreateJob, the > RKD> Printer promises to maintain the state it was in with > RKD> respect to requested resources until the print job > RKD> is complete. Is this agreed? Yes, to some degree, its possible that the server has locked down one or moreresources to process this job. RKD> This seems pretty loose. If a positive reponse to CreateJob RKD> means the resources can be applied NOW (as you suggest in your RKD> initial email) then the resources better be locked down. RKD> If it means it is possible, to some degree, etc ... RKD> then a positive repnsese only means that a job object RKD> is created and waiting for job data. It means nothing in RKD> terms of being able to print NOW. > RKD> Does a client send CreateJob, assuming that if resources are > RKD> not ready that the Printer will schedule the job accordingly, > RKD> i.e. schedule all jobs waiting for A4 paper to print when A4 > RKD> paper is loaded, or does a client keep "pinging" the Printer > RKD> with CreateJobs until it finds the resources are ready, then > RKD> consummates the print job by sending the data? It depends upon the type of 'resource' that may or may not be available. In your example, you specify media as the resource in question (A4). This is only one of numerous possible types of resources. The response to a 'CreateJob' operation (and the clients reaction to this response) is really dependent upon the type of resource allocation problem that might occur, as specified by the clients explicit or implicit job requirements. RKD> Help me by giving some other examples where the response RKD> might be different. I'd like to understand this better. > RKD> If we believe that the first is the preferred method for > RKD> handling jobs waiting for resources then I claim that just > RKD> using the PrintJob operation works as well as CreateJob and > RKD> SendDocument since I don't care if the resources are actually > RKD> ready NOW or not (and I doubt that I want to keep "pinging" > RKD> the Printer to find out). An out of resources condition is definitely going to happen, and yes,implementations will have to incorporate retries (much like LPD does today) in order to see that the job is printed. RKD> Will we really expect to see clients retry while waiting RKD> for a resource to become available. This implies that RKD> they understand that the resource is supported and RKD> will become available reasonably soon (as opposed to RKD> sometime next week). Does LPD really do this? From ipp-archive Wed May 28 16:46:18 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA21780 for ipp-outgoing; Wed, 28 May 1997 16:46:05 -0400 (EDT) Message-Id: <338C9959.38D4@dazel.com> Date: Wed, 28 May 1997 15:45:13 -0500 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: Re: IPP> ADM - Agenda for PWG IPP Phone Conference - May 28 References: <3.0.1.32.19970527164325.009b6260@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Carl-Uno Manros wrote: > > Agenda for PWG IPP Phone Conference - May 28, 1-3:30 pm PST > > - Comments on IPP Document List and Draft IETF IPP Charter Text (Carl-Uno) > > - Comments on the HTTP 1.1 Transport Mapping for IPP (Randy) > > - Comments on Job Model synchronization Printer Model vs. IPP (Tom) > > We expect to spend most of the time on Randy's document > > The numbers for tomorrow are: > > Call-in: 1-309-671-1035 > Access: 190148 So... has anybody been able to dial into this number? I keep getting a busy signal. curious... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-archive Wed May 28 17:01:05 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA22250 for ipp-outgoing; Wed, 28 May 1997 16:55:49 -0400 (EDT) From: Harry Lewis To: Subject: Re: IPP>MOD - Too Many IPP Operations? Message-Id: <5030100002909408000002L082*@MHS> Date: Wed, 28 May 1997 16:57:52 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I'm wondering what happened to Paul Moore's proposal to use a job attribute rather than SendDocument to link the multiple documents in a job. I remember the idea, discussed in SanDiego, of a job being submitted with a attribute which indicated it was the start of a "multi-document" job and the IPP server returning a specific URL to which all documents of this job should be submitted (as separate jobs using a single post for each). I thought this was the start of a good proposal to get around what appears to be one of the main limitations of "Simple Web Printing" which was lack of multi-doc support. Harry Lewis - IBM Printing Systems --------- Forwarded by Harry Lewis/Boulder/IBM on 05/28/97 02:44 PM --------- ipp-owner@pwg.org 05/28/97 01:22 PM Please respond to ipp-owner@pwg.org @ internet To: Roger K Debry/Boulder/IBM@IBMUS cc: ipp@pwg.org @ internet Subject: Re: IPP>MOD - Too Many IPP Operations? Roger: I don't think the intent was that the only way to know if a printer supports multiple documents per job was through the failure of the CreateJob operation. The intent was that if the client failed to ask, a predictable response, i.e. a failure, would be returned and could be acted upon. This also insured that the client could learn of the failure early: prior to posting megabytes of data to a printer that couldn't support printing the multi-document print job. Using SendDocument to clearly separate the multiple documents within a job was deemed to be good by those in attendance. Using CreateJob to start the process of printing a multiple document job where all the documents were not going to be sent in a single POST was deemed worthy of a separate operation rather than a PrintJob with a special attribute indicating there were multiple documents within a single PrintJob. And, as I said above, it also made it easier for the simple implementation to deal with the case where, through an error on the client-end, a multi-document job was sent to a printer that couldn't support thatfunctionality. Don To: Don Wright cc: ipp%pwg.org @ interlock.lexmark.com From: rdebry%us.ibm.com @ interlock.lexmark.com @ LEXMTA Date: 05/28/97 12:26:15 PM AST Subject: Re: IPP>MOD - Too Many IPP Operations? We should not design a protocol that depends upon failure of an operation in order for clients to know what to do next. If the client doesn't know what the Printer is capable of doing it should ask, not assume something works and wait to see if it does or not. Sure, we have to consider what happens when an operation fails, but we should not require failure to occur in order to do simple operations. The logic you suggest seems complex and poor design. It puts extra burden on the client, which I would think we want to keep as simple as possible. The client logic ought to be: Do I know I know about the Printer? If no - query the printer, otherwise go ahead Send a PrintJob operation with the job attributes and the document(s) to be printed. If the response to the query tells me that the Printer only supports one document per job, I will do multiple PrintJobs, otherwise I will put all of the documents in one PrintJob. I don't view this as overloading the PrintJob operation. 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 05/28/97 10:04 AM --------------------------- don @ lexmark.com 05/28/97 09:22 AM Please respond to don@lexmark.com @ internet To: Roger K Debry/Boulder/IBM cc: ipp @ pwg.org @ internet Subject: Re: IPP>MOD - Too Many IPP Operations? Roger: My understanding is as follows: ------------------- In the simple case of 1 job/1 document: PrintJob - Creates a job and send it to be printed. ------------------- Rather than overloading PrintJob we have added CreateJob to support multiple documents per job. CreateJob - Use to create a job on the server which responds with some job identifier SendDocument - Used multiple times to send the multiple documents which make up the job created with CreateJob With a server that does not support multiple documents per job, the CreateJob operation is rejected. The client can either split the multiple document job into multiple jobs or go look for a server that supports multiple documents per job. ------------------- ValidateJob is just as you describe. ------------------ Hope this helps! Don To: ipp%pwg.org @ interlock.lexmark.com cc: (bcc: Don Wright) From: rdebry%us.ibm.com @ interlock.lexmark.com @ LEXMTA Date: 05/28/97 10:18:34 AM AST Subject: IPP>MOD - Too Many IPP Operations? You all must pardon me if I am covering ground that has been covered before, but since I was not able to attend the IPP meetings last week my thinking may be a bit behind where everyone else is at. In reading through the minutes of the meeting and recent email on the discussion list, it seems to me that we may have invented more operations for IPP than we really need. It seems to me that we added CreateJob to allow a client to validate job attributes prior to sending all of the print data. The original send operation (which I think we are back to) simply transmits the print data. The deBry/Carter proposal to use multiple send Documents was not accepted. We are depending upon http chunking to allow the client to send the print data in pieces and upon tcp/ip to guarantee delivery. We added Validate and PrintJob to provide for the simple print case proposed by Microsoft. As I read the minutes and email it also seems that we generally agreed that well behaved clients would always know printer characteristics, either because the Printer has been "installed" on the desktop or the client has queried the capabilities of the printer. So as I see it, we are left with the following: CreateJob - used to validate the print job Validate - used to validate the print job SendDocument - its only value is to transmit the job data PrintJob - transmits the job data and the job attributes What am I missing? In the spirit of simplification, it appears to me that we could get rid of CreateJob and SendDocument. I see little value to these operations given the current set of proposals on the table. The only thing I see is that I save resending the job attributes in the sequence CreateJob, SendDocument over the sequence Validate, PrintJob. Since a well behaved client would know the capabilities of the Printer it would normally not be necessary to validate job attributes and PrintJob would almost always be the preferred method to use. Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-archive Wed May 28 17:01:18 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA22276 for ipp-outgoing; Wed, 28 May 1997 16:59:02 -0400 (EDT) Date: Wed, 28 May 1997 16:59:12 -0400 (EDT) From: JK Martin Message-Id: <199705282059.QAA20663@uscore.underscore.com> To: walker@dazel.com Subject: Re: IPP> ADM - Agenda for PWG IPP Phone Conference - May 28 Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO You're not alone, Jim. Neither myself, Bob Herriot nor Steve Zilles can get in either. I think we'd better plan to reschedule this telecon. The topics to be discussed today are extremely critical to the progress of IPP. ...jay ----- Begin Included Message ----- >From ipp-owner@pwg.org Wed May 28 16:51 EDT 1997 Date: Wed, 28 May 1997 15:45:13 -0500 From: Jim Walker To: ipp@pwg.org Subject: Re: IPP> ADM - Agenda for PWG IPP Phone Conference - May 28 Content-Transfer-Encoding: 7bit Carl-Uno Manros wrote: > > Agenda for PWG IPP Phone Conference - May 28, 1-3:30 pm PST > > - Comments on IPP Document List and Draft IETF IPP Charter Text (Carl-Uno) > > - Comments on the HTTP 1.1 Transport Mapping for IPP (Randy) > > - Comments on Job Model synchronization Printer Model vs. IPP (Tom) > > We expect to spend most of the time on Randy's document > > The numbers for tomorrow are: > > Call-in: 1-309-671-1035 > Access: 190148 So... has anybody been able to dial into this number? I keep getting a busy signal. curious... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX ----- End Included Message ----- From ipp-archive Wed May 28 17:06:24 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA22544 for ipp-outgoing; Wed, 28 May 1997 17:05:14 -0400 (EDT) Message-Id: <199705282105.RAA12190@devnix.agranat.com> To: ipp@pwg.org Subject: Re: IPP> Re: New protocol document & Security issues In-reply-to: <3.0.1.32.19970528124403.00a4f100@garfield> Date: Wed, 28 May 1997 17:05:28 -0400 From: "Scott Lawrence" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO >>>>> "RT" == Randy Turner writes: RT> We talked about basic authentication in Memphis and we decided RT> that low-end IPP servers could use this because it is simple. We RT> really only need two levels of security, simple and advanced, for RT> interoperability's sake. The simple case would be basic auth., RT> which alot of vendors are already supporting (username and RT> password) in their products. >>>>> "CM" == Carl-Uno Manros writes: CM> You can certainly use the basic stuff that is in your document, CM> but if used, that will fall into the category "no security" as seen by the CM> SEC subgroup. Seconding Carl-Uno; The HTTP Basic Authentication scheme is no authentication at all, and I suspect will be treated as such by IESG reviewers. To quote from the report on a recent meeting of the IAB , in a section titled "To be Killed: Plaintext Passwords": "Any protocol that relies on the transmission of unencrypted passwords is terminally broken." If the IPP security mapping document mentions the Basic authentication scheme it at all, it should be to explicitly disallow it as a means of providing a security service. -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-archive Wed May 28 17:41:18 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA23726 for ipp-outgoing; Wed, 28 May 1997 17:37:25 -0400 (EDT) From: Roger K Debry To: Cc: Subject: IPP>PRO - comments on transport mapping document Message-Id: <5030100002912389000002L092*@MHS> Date: Wed, 28 May 1997 17:39:28 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Randy, I have several comments on your document. (1) In the first paragraph of the abstract you say that http response codes and message headers are used to convey abstract IPP model semantics. I disagree with this approach. While there is a lot of value in using http as the transport (chunking, security, persistent connections, etc), we should make every effort to maintain a clean seperation between the http transport layer and the IPP stuff carried inside. Therefore, I favor responses having to do with IPP operations being carried inside of the PDU. (2) In section 1, IPP Model overview, you infer that there are two objects in IPP, the Printer and the Job. The model document also defines Document as an object. (3) In this section you also say that Individual IPP operations can be supplemented by object attribute specifications that are used to refine a particular operations effect on an object. Are you talking about the way taht you have encoded the operations as attributes? While I think you are right on in including the operation as the first bit of information in the PDU, I don't like calling it an attribute. This is very confusing to someone reading the model document. Why not just declare this as a header field in the PDU. Since we "own" the definition of the PDU, can't we define it any way that we want to? Therfore it could by definition have the IPP operation as a "field" and we don't have to overload this notion of an attribute. (4) In section 3, you describe operation-encoding as operation-version followed by some other stuff. Why don't you use protocol-version, or PDU version?? This isn't really an operation-version is it? This implies to me that each IPP operation could have a version. (5) IBM requires print by reference. (6) In section 3.1.1 (and other responses) you use attributes as holders for response information. As in (3), I have a problem with using the notion of attributes to describe response fields. Again, if we own the definition of the PDU lets just say that the data appears in this form and in this order. I don't see any value in trying to define these as attributes. I find it very confusing as it relates to real attributes. (7) In section 3.3 you suggest that each SendDocument carries exactly one document. I thought from the minutes if the San Diego meeting that this notion was rejected. I thought that there would be one SendDocument operation and it could carry multiple documents. I'm not saying that I diagree with you approcah, I actually like it better, but I didn't think this' was consistent with agreements made last week. Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-archive Wed May 28 18:06:21 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA24959 for ipp-outgoing; Wed, 28 May 1997 18:03:29 -0400 (EDT) From: Harry Lewis To: , Subject: Re: IPP> RE: Should 'pending' be a mandatory state or not? Message-Id: <5030100002913609000002L092*@MHS> Date: Wed, 28 May 1997 18:05:28 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I'm really not sure it makes sense to talk about mandatory States (as opposed to mandatory Objects), but, I believe what Bill describes as >2. if the job goes through the state, it must be reported? is what we're striving for. Harry Lewis - IBM Printing Systems From ipp-archive Wed May 28 19:06:19 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA25642 for ipp-outgoing; Wed, 28 May 1997 19:06:16 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 28 May 1997 17:06:13 -0600 From: Scott Isaacson To: rturner@sharplabs.com, rdebry@us.ibm.com Cc: ipp@pwg.org Subject: Re: IPP>PRO - comments on transport mapping document Sender: ipp-owner@pwg.org Precedence: bulk Status: RO >>> Roger K Debry 05/28 3:39 PM >>> > > (7) In section 3.3 you suggest that each SendDocument carries exactly > one document. I thought from the minutes if the San Diego meeting that > this notion was rejected. I thought that there would be one SendDocument > operation and it could carry multiple documents. I'm not saying that I > diagree with you approcah, I actually like it better, but I didn't think this' > was consistent with agreements made last week. I understood that it was one document per send-document. Scott From ipp-archive Wed May 28 19:16:54 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA25933 for ipp-outgoing; Wed, 28 May 1997 19:12:56 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 28 May 1997 17:12:33 -0600 From: Scott Isaacson To: fullman@cp10.es.xerox.com Cc: ipp@pwg.org Subject: Re: IPP> MOD - new model document (QUESTION on Job Templateattr's and TYPOS) Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Thanks for the feedback. >>> Don Fullman 05/27 12:55 PM >>> > Shouldn't the following Job Template attributes for the Printer Object be > "setOf" or "1setOf"? > - job-hold-until-available > - number-up-supported > - number-up-available > - sides-supported > - sides-available > - printer-resolution-available > - print-quality-available > - compression-supported Yes, they should be 1setOf. Just some editing process flaws, nothing more. From ipp-archive Wed May 28 19:31:20 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA26582 for ipp-outgoing; Wed, 28 May 1997 19:27:11 -0400 (EDT) Message-Id: <3.0.1.32.19970528162154.00a93980@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 28 May 1997 16:21:54 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> ADM - Agenda for PWG IPP Phone Conference - May 28 In-Reply-To: <199705282059.QAA20663@uscore.underscore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO At 01:59 PM 5/28/97 PDT, JK Martin wrote: >You're not alone, Jim. Neither myself, Bob Herriot nor Steve Zilles >can get in either. > >I think we'd better plan to reschedule this telecon. The topics to >be discussed today are extremely critical to the progress of IPP. > > ...jay > Sorry about the difficulties with dialing into to today's PWG IPP conference. It seems that some local technical problem caused this. We eventually managed to get everybody, except Steve Zilles, in by using Scott's local conferencing system. 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 May 28 20:56:21 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA27260 for ipp-outgoing; Wed, 28 May 1997 20:52:08 -0400 (EDT) Date: Wed, 28 May 1997 17:53:53 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705290053.RAA07916@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO face-to-face meeting on June 17 X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO There will be a face-to-face meeting at Sun on Tuesday, June 17 from 0930 to 1800. Please let me know if you can come: a) in person b) via telephone From ipp-archive Wed May 28 20:56:22 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA27271 for ipp-outgoing; Wed, 28 May 1997 20:54:29 -0400 (EDT) Date: Wed, 28 May 1997 17:56:13 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705290056.RAA07918@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO teleconference on Mondays during June, starting June 2 X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I have reserved a conference call number all the Monday's in June from 1pm PDT to 3pm. The number is: 415-278-2944 passcode: 3440795 We will decide each week whether to hold the conference call. We will have one on Monday June 2. From ipp-archive Thu May 29 10:46:31 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA29550 for ipp-outgoing; Thu, 29 May 1997 10:43:33 -0400 (EDT) From: Harry Lewis To: Cc: , Subject: IPP> IETF vs PWG Message-Id: <5030100002936719000002L092*@MHS> Date: Thu, 29 May 1997 10:45:34 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I don't believe the IETF is hosting the IPP mailing list, are they? >6. An active PWG group and an active IETF group should not share a >mailing list. It's too easy for the discussions to get confused. Our list is hosted by a COMPANY who DONATES this service on behalf of the PWG *and* IPP (and ultimately the consumer) - taking little or no public credit. The PWG coordinators, officers and participating members also *all* donate their time and effort toward the purpose of creating standards to benefit the general public. If the IETF were to host the IPP mailing list, would there be a charge ($) to the IPP members? If not, perhaps this is the solution to separating PWG-IPP and IETF-IPP mailing lists. Otherwise, I hope the IETF would not attempt to enforce a policy which mandates funds (unto itself) from an otherwise autonomously supported organization. Harry Lewis - Speaking entirely as a private individual... as the IETF would have it. From ipp-archive Thu May 29 11:16:31 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA00453 for ipp-outgoing; Thu, 29 May 1997 11:12:09 -0400 (EDT) Message-Id: <199705291512.LAA01967@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Harry Lewis cc: Moore@cs.utk.edu, ipp@pwg.org, pwg@pwg.org Subject: IPP> Re: IETF vs PWG In-reply-to: Your message of "Thu, 29 May 1997 10:45:34 EDT." <5030100002936719000002L092*@MHS> Date: Thu, 29 May 1997 11:12:24 -0400 Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > I don't believe the IETF is hosting the IPP mailing list, are they? Nope. To my knowledge, IETF doesn't host *any* working group mailing lists -- they're always hosted by interested members of the community who donate the resources needed to support said lists. None of these lists charges a fee to be on the list. However, since the working group mailing lists are where IETF conducts its business, it's important that such business be clearly distinguished from other traffic. An occasional unofficial message of interest to the group doesn't hurt, but it does hurt to have ongoing discussions which aren't apropos to the business of the working group. The working group chairs are expected to keep such discussion to a minimum. If IBM no longer wishes to support the IPP working group in this manner, I'm sure we can find another host for the IPP mailing list. Keith From ipp-archive Thu May 29 12:21:31 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA01691 for ipp-outgoing; Thu, 29 May 1997 12:19:52 -0400 (EDT) Date: Thu, 29 May 1997 09:18:58 -0700 (PDT) From: Patrick Powell Message-Id: <199705291618.JAA18533@dickory.sdsu.edu> To: ipp@pwg.org Subject: IPP> LPD (RFC1179) <-> IPP gateway Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Is anybody else looking at this? If so, could we please compare notes? Patrick Powell Prof. Patrick Powell Dept. Electrical and Computer Engineering, San Diego State University, San Diego, CA 92182-1309 Office (619) 594-7796; Lab (619) 594-7578 FAX (619) 594-7577 email: papowell@sdsu.edu From ipp-archive Thu May 29 12:31:35 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA02161 for ipp-outgoing; Thu, 29 May 1997 12:27:55 -0400 (EDT) Date: Thu, 29 May 1997 09:24:08 -0700 (PDT) From: Patrick Powell Message-Id: <199705291624.JAA18554@dickory.sdsu.edu> To: Angelo_Caruso@wb.xerox.com, jmp@pwg.org Subject: IPP> RE: JMP> HELD vs NEEDS-ATTENTION Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Having thought about this, I realize that I really don't care WHICH form we use, as long as there is ONE form (format) that is common between the JMP and IPP protocols/standards. Note: while I want one set, I wouldn't be opposed to two sets of 'names' with a well defined (i.e. -cast into standard) mapping between the two sets. Patrick Powell From: "Caruso,Angelo" Subject: RE: JMP> HELD vs NEEDS-ATTENTION There seem to be two extremes on this whole issue. On the one side there are those who would like all their favorite states included in one easy to use job state object. On the other side are those who want to keep the job state object ultra simple and have lots of job state reasons. Both points of view have been backed up by many good arguments. Last week at the IPP teleconference it seemed that a reasonable COMPROMISE was reached. Unfortunately, several key JMP folks were not present for that discussion and now we're waffling on the whole issue again. Based on todays mail volume there does not appear to be any end in sight. For the record, here is my position. IPP and JMP should use EXACTLY the same set of job states and the same state reasons (the agreement reached at the last IPP/JMP teleconference seemed reasonable to me). How are we to expect the PWG to be taken seriously if we simultaneously create two specifications with different job models? The rest of the world expects and deserves a consistent set of standards from this working group! Please don't respond again how easy it is to map between the two different state models. I understand the mapping because I have been following the discussions. But the rest of the world will not find the mapping to be so obvious. If we learned anything from the Printer MIB interop testing it is that interpreting ONE model correctly is hard enough. Now, we are on the verge of generating two different models to represent the same thing. It's time to find a compromise. Thanks, Angelo From ipp-archive Thu May 29 14:06:33 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA02930 for ipp-outgoing; Thu, 29 May 1997 14:05:30 -0400 (EDT) From: Roger K Debry To: Subject: IPP>PRO - Print by reference Message-Id: <5030100002947807000002L072*@MHS> Date: Thu, 29 May 1997 14:07:28 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO As I stated in yesterday's telecon, Print by reference is a requirement for Network computers that have limited local storage. I suggested that we discuss this in more detail at the protocol meeting being held at Sun in a couple of weeks, and that we establish a set of assumptions on what the key objectives are for Print by Reference. From yesterday's call it was clear that we each have a different view of what Print by Reference is for. I have what I think is a very straightforward requirement and it does not require anything very complex in IPP. Furthermore, I believe that this represents a major printing application within the enterprise. Finally, I don't think that Print by Reference is Web Printing, and we should probably distinguish the two. Printing Web pages introduces more complexity and gets into a number of issues that I agree with Randy on -- we probably don't want to deal with these in version 1.0 of the protocol. My objective is to meet the following requirement. An enterprise chooses to keep libraries of technical reports, procedures manuals, policies, etc. that are in printable format, e.g. as Postscript files. They want to make these accessible to anyone within their organization (no security requirements). As an employee I want to get a particular report and print it. I'd like to be able to use my web browser (or other GUI) to locate the document and then issue a print request, pointing to the document that I just found. The printer gets the file and prints it. This eliminates the need for me to download the file (In the NC case, I might not have the local storage necessary to hold the file to be printed). This would be ideal in industries like insurance, where the home office keeps the library of current policies, forms, contracts, etc., and when a branch wants to print a copy of something it just points the print request to it. The same could apply to publicly available documents (such as Internet-Drafts) on the Internet. The two conditions required are that the document be in a standard printable format and that the document be publicaly available. Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-archive Thu May 29 15:01:33 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA03520 for ipp-outgoing; Thu, 29 May 1997 15:01:03 -0400 (EDT) From: Roger K Debry To: Subject: IPP>SEC - Security services Message-Id: <5030100002951768000002L082*@MHS> Date: Thu, 29 May 1997 15:03:03 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO As there has been some email on this and we have discussed it in our Security subgroup, I wanted to float a proposal and see what comments you all have. Given last weeks decusion on http, I believe that we now have a small set of choices for IPP security. My view is that an installation can choose to implement whatever of these services they want, as each provides unique capabilities ...at some price... The choices for security are: (1) http basic authentication - not really secure, but probably viable within a trusted environment where security is not an issue. Probably used only for identification, possibly only for accounting purposes. Does not provide any message protection. (2) http digest access authentication - not stong authentication, but viable within a trusted environment where one wants a lightweight solution but does not want passwords sent in the clear as in basic authentication. Would be used when authorization to use resources is required. Does not provide any message protection. (3) SSL or TLS - strong security when operating outside of a trusted environment. Does require more infrastructure to support. Would be required when strong authentication or message protection (privacy, integrity, non-repudiation) is needed. Given this set of choices, it seems that we only need something in the directory that says this Printer requires some authentication to get to it (could be any of (1), (2), or (3). That is, if I want to use this Printer I must be prepared to offer some credentials. A Printer that supports (1) or (2) simply uses the existing http authentication mechanisms. A Printer which uses (3) would advertise a URI that would indicate SSL or TLS was to be used in the http session. Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-archive Thu May 29 15:36:33 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA04139 for ipp-outgoing; Thu, 29 May 1997 15:33:35 -0400 (EDT) Message-Id: <199705291934.PAA00402@devnix.agranat.com> To: Roger K Debry Cc: ipp@pwg.org Subject: Re: IPP>PRO - Print by reference In-reply-to: <5030100002947807000002L072*@MHS> Date: Thu, 29 May 1997 15:34:21 -0400 From: "Scott Lawrence" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO >>>>> "RKD" == Roger K Debry writes: RKD> They want to make these accessible to anyone RKD> within their organization (no security requirements). RKD> [...] The printer gets the file and prints it. RKD> [...] RKD> The two conditions required are that the document be in a RKD> standard printable format and that the document be publicaly RKD> available. It doesn't seem to me that the exemption from ordinary security is really required. It is quite possible to give printers or print servers identities in order to support authentication and authorization functions; the document repository can then just decide whether or not a given document can be printed on the authority of a given printer (that is, the printer has access rights just as a user does). Granted, one would want to look at how secure the printer is before assigning it much access, but that is an issue for those using this model, not for the protocol. While I agree that the protocol should define the mechanism for the sort of print by reference you describe, I don't think that it should be a required part (that is it is a feature that may or may not be available from a conforming IPP server). -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-archive Thu May 29 15:56:43 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA05012 for ipp-outgoing; Thu, 29 May 1997 15:53:31 -0400 (EDT) Message-ID: <338DDFEA.8045B1A7@sharplabs.com> Date: Thu, 29 May 1997 12:58:34 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.0b5 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP>PRO - Print by reference X-Priority: 3 (Normal) References: <199705291934.PAA00402@devnix.agranat.com> Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Precedence: bulk Status: RO The kind of print-by-reference I would like to see would be where I could send the printer a URL, referencing a particular RFC; SendDocument: REF(http://ds.internic.org/pub/rfc/rfc1122.txt) And that way I wouldn't have to suffer the time downloading the file first to my machine, and then PUSHing the document to the printer. For this type of access, I don't think security is needed. For INTRAnet printing, I pretty much agree with Scott L. that it would be possible for printers to authenticate themselves with a document repository, because the domain of usage (departmental or company divisional) would be small enough to deal with. Randy Scott Lawrence wrote: > >>>>> "RKD" == Roger K Debry writes: > > RKD> They want to make these accessible to anyone > RKD> within their organization (no security requirements). > RKD> [...] The printer gets the file and prints it. > > RKD> [...] > RKD> The two conditions required are that the document be in a > RKD> standard printable format and that the document be publicaly > RKD> available. > > It doesn't seem to me that the exemption from ordinary security is > really required. It is quite possible to give printers or print > servers identities in order to support authentication and > authorization functions; the document repository can then just > decide whether or not a given document can be printed on the > authority of a given printer (that is, the printer has access rights > > just as a user does). > > Granted, one would want to look at how secure the printer is before > assigning it much access, but that is an issue for those using this > model, not for the protocol. > > While I agree that the protocol should define the mechanism for the > sort of print by reference you describe, I don't think that it > should be a required part (that is it is a feature that may or may > not be available from a conforming IPP server). > > -- > Scott Lawrence EmWeb Embedded Server > > Agranat Systems, Inc. Engineering > http://www.agranat.com/ From ipp-archive Thu May 29 16:11:37 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA05500 for ipp-outgoing; Thu, 29 May 1997 16:05:56 -0400 (EDT) Message-ID: <338DE1B0.1D10@underscore.com> Date: Thu, 29 May 1997 16:06:08 -0400 From: Jeff Schnitzer Organization: Underscore, Inc. X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: Keith Moore CC: Harry Lewis , ipp@pwg.org, pwg@pwg.org, jkm@uscore.underscore.com Subject: IPP> Re: PWG> Re: IETF vs PWG References: <199705291512.LAA01967@spot.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Keith Moore wrote: > > > I don't believe the IETF is hosting the IPP mailing list, are they? > ...omited portion... > > If IBM no longer wishes to support the IPP working group in this > manner, I'm sure we can find another host for the IPP mailing list. > Keith, For the record: It is Underscore that has donated support and hosts the various PWG and related [ but independent ;-) ] IETF mailing lists, FTP archive and Web(s). /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 May 29 16:26:36 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA06457 for ipp-outgoing; Thu, 29 May 1997 16:18:57 -0400 (EDT) Message-Id: <199705292019.QAA02950@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Jeff Schnitzer cc: Keith Moore , Harry Lewis , ipp@pwg.org, pwg@pwg.org, jkm@uscore.underscore.com Subject: IPP> Re: PWG> Re: IETF vs PWG In-reply-to: Your message of "Thu, 29 May 1997 16:06:08 EDT." <338DE1B0.1D10@underscore.com> Date: Thu, 29 May 1997 16:19:05 -0400 Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > For the record: > It is Underscore that has donated support and hosts the various PWG > and related [ but independent ;-) ] IETF mailing lists, FTP archive > and Web(s). Sorry. I had been aware of that, but I forgot about it when I replied to Harry's message. Thanks for your support! Keith From ipp-archive Thu May 29 17:31:35 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA07649 for ipp-outgoing; Thu, 29 May 1997 17:29:56 -0400 (EDT) Date: Thu, 29 May 1997 17:30:10 -0400 (EDT) From: JK Martin Message-Id: <199705292130.RAA25145@uscore.underscore.com> To: papowell@dickory.sdsu.edu Subject: Re: IPP> LPD (RFC1179) <-> IPP gateway Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Yes, Underscore is definitely looking into an IPP/LPD gateway. What notes do you have to share? ;-) ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- ----- Begin Included Message ----- >From ipp-owner@pwg.org Thu May 29 12:25 EDT 1997 Date: Thu, 29 May 1997 09:18:58 -0700 (PDT) From: Patrick Powell To: ipp@pwg.org Subject: IPP> LPD (RFC1179) <-> IPP gateway Is anybody else looking at this? If so, could we please compare notes? Patrick Powell Prof. Patrick Powell Dept. Electrical and Computer Engineering, San Diego State University, San Diego, CA 92182-1309 Office (619) 594-7796; Lab (619) 594-7578 FAX (619) 594-7577 email: papowell@sdsu.edu ----- End Included Message ----- From ipp-archive Thu May 29 17:41:37 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA08036 for ipp-outgoing; Thu, 29 May 1997 17:37:29 -0400 (EDT) Date: Thu, 29 May 1997 17:37:43 -0400 (EDT) From: JK Martin Message-Id: <199705292137.RAA25484@uscore.underscore.com> To: ipp@pwg.org Subject: Re: IPP>PRO - Print by reference X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO We also readily agree with Roger's belief that print-by-reference should be considered a basic (ie, mandatory) requirement for IPP. Our largest customer has already implemented *exactly* what Roger has described as a motivating scenario for print-by-reference. And, as Randy Turner has pointed out, we don't want to put users in the position of having to first download the (potentially huge) document just to be able to print it. We are also very concerned that the ersatz "IPP Level 1" approach (aka the Microsoft/HP Simple Web Printing proposal) explicitly refrains from embracing this critical requirement. This is Not Good. We hope others on the list will address this situation before we dig ourselves in deep with regard to inter- operability issues surrounding implementations of "Level 1" and "Level 2" for IPP clients and servers. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- ----- Begin Included Message ----- >From ipp-owner@pwg.org Thu May 29 14:11 EDT 1997 From: Roger K Debry To: Subject: IPP>PRO - Print by reference Date: Thu, 29 May 1997 14:07:28 -0400 As I stated in yesterday's telecon, Print by reference is a requirement for Network computers that have limited local storage. I suggested that we discuss this in more detail at the protocol meeting being held at Sun in a couple of weeks, and that we establish a set of assumptions on what the key objectives are for Print by Reference. From yesterday's call it was clear that we each have a different view of what Print by Reference is for. I have what I think is a very straightforward requirement and it does not require anything very complex in IPP. Furthermore, I believe that this represents a major printing application within the enterprise. Finally, I don't think that Print by Reference is Web Printing, and we should probably distinguish the two. Printing Web pages introduces more complexity and gets into a number of issues that I agree with Randy on -- we probably don't want to deal with these in version 1.0 of the protocol. My objective is to meet the following requirement. An enterprise chooses to keep libraries of technical reports, procedures manuals, policies, etc. that are in printable format, e.g. as Postscript files. They want to make these accessible to anyone within their organization (no security requirements). As an employee I want to get a particular report and print it. I'd like to be able to use my web browser (or other GUI) to locate the document and then issue a print request, pointing to the document that I just found. The printer gets the file and prints it. This eliminates the need for me to download the file (In the NC case, I might not have the local storage necessary to hold the file to be printed). This would be ideal in industries like insurance, where the home office keeps the library of current policies, forms, contracts, etc., and when a branch wants to print a copy of something it just points the print request to it. The same could apply to publicly available documents (such as Internet-Drafts) on the Internet. The two conditions required are that the document be in a standard printable format and that the document be publicaly available. Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 ----- End Included Message ----- From ipp-archive Thu May 29 17:41:38 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA08005 for ipp-outgoing; Thu, 29 May 1997 17:37:10 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 29 May 1997 15:27:26 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - document format question Sender: ipp-owner@pwg.org Precedence: bulk Status: RO In working on the Model document, I had several requests to come up with a better format for all of Job Template attributes. I used to have something like the following for each Job Template attribute: ------------------------------------------------------ 1.0 xxx (syntax) 1.1 As a create request attribute: xxx (syntax, OPT/MAND/etc.) 1.2 As a Job object attribute: xxx (syntax, OPT/MAND/etc.) 1.3 As a Printer object attribute 1.3.1 Default Behavior 1.3.2 As a default value ttribute: xxx (syntax, OPT/MAND/etc.) 1.3.3 As a supported attribute : xxx-supported (OPT/MAND/etc.) 1.3.4 As an available attribute : xxx-available (syntax, OPT/MAND/etc.) ------------------------------------------------------ Now I propose something like: (WARNING: requires some non-proportional spaced font) ------------------------------------------------------ 1.0 xxx +----------------------+-------------------+-------------------------+ | Create Request | JOB Object | Printer Supported | | Attribute | Attribute | Attribute | +----------------------+-------------------+-------------------------+ | xxx | xxx | xxx-supported | | syntax | syntax | syntax | | OPT/MAND/etc. | OPT/MAND/etc. | OPT/MAND/etc. | +----------------------+-------------------+-------------------------+ +----------------------+-------------------+ | Printer Default | Printer Available | | Value Attribute | Attribute | +----------------------+-------------------+ | xxx | xxx-available | | syntax | syntax | | OPT/MAND/etc. | OPT/MAND/etc. | +----------------------+-------------------+ Any comments or suggestions? Scott From ipp-archive Thu May 29 18:01:35 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA09241 for ipp-outgoing; Thu, 29 May 1997 18:00:19 -0400 (EDT) Date: Thu, 29 May 1997 18:00:36 -0400 (EDT) From: JK Martin Message-Id: <199705292200.SAA26494@uscore.underscore.com> To: SISAACSON@novell.com Subject: Re: IPP> MOD - document format question Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Scott, If the boxed approach results in describing a single attribute in one "row" in the plain text draft (as opposed to two rows in your example), then perhaps the boxed approach might be an improvement over the existing implementation. If the boxed approach doesn't work, then how about a lean'n'mean tabular approach, such as: 1.0 xxx Description... Forms: Create request: xxx (OPT/MAND/etc) Job object: xxx (OPT/MAND/etc) Printer object: xxx (OPT/MAND/etc) Default value: xxx (OPT/MAND/etc) Supported: xxx-supported (OPT/MAND/etc) Available: xxx-available (OPT/MAND/etc) Just a thought on alternatives here. By the way, the fact that we have all these variations on attributes is a bit scary and makes me wonder if we haven't gone over the top on this part of the model. ;-) ...jay ----- Begin Included Message ----- >From ipp-owner@pwg.org Thu May 29 17:49 EDT 1997 Date: Thu, 29 May 1997 15:27:26 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - document format question In working on the Model document, I had several requests to come up with a better format for all of Job Template attributes. I used to have something like the following for each Job Template attribute: ------------------------------------------------------ 1.0 xxx (syntax) 1.1 As a create request attribute: xxx (syntax, OPT/MAND/etc.) 1.2 As a Job object attribute: xxx (syntax, OPT/MAND/etc.) 1.3 As a Printer object attribute 1.3.1 Default Behavior 1.3.2 As a default value ttribute: xxx (syntax, OPT/MAND/etc.) 1.3.3 As a supported attribute : xxx-supported (OPT/MAND/etc.) 1.3.4 As an available attribute : xxx-available (syntax, OPT/MAND/etc.) ------------------------------------------------------ Now I propose something like: (WARNING: requires some non-proportional spaced font) ------------------------------------------------------ 1.0 xxx +----------------------+-------------------+-------------------------+ | Create Request | JOB Object | Printer Supported | | Attribute | Attribute | Attribute | +----------------------+-------------------+-------------------------+ | xxx | xxx | xxx-supported | | syntax | syntax | syntax | | OPT/MAND/etc. | OPT/MAND/etc. | OPT/MAND/etc. | +----------------------+-------------------+-------------------------+ +----------------------+-------------------+ | Printer Default | Printer Available | | Value Attribute | Attribute | +----------------------+-------------------+ | xxx | xxx-available | | syntax | syntax | | OPT/MAND/etc. | OPT/MAND/etc. | +----------------------+-------------------+ Any comments or suggestions? Scott ----- End Included Message ----- From ipp-archive Thu May 29 18:11:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA09703 for ipp-outgoing; Thu, 29 May 1997 18:10:46 -0400 (EDT) From: Roger K Debry To: Subject: IPP> MOD - document format question Message-Id: <5030100002960284000002L042*@MHS> Date: Thu, 29 May 1997 18:12:43 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO My first reaction is that if we need this many boxes to talk about an attribute, then we still have too much complexity built into the model. Before spending the time to rewrite all of the this into a new format, I'd really like to see the new pages that describe what these variations all are, when each is used, and so on. I think that this section of the document is ultimately an order of magnitude more important than the specific description for each attribute. 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 05/29/97 03:59 PM --------------------------- ipp-owner @ pwg.org 05/29/97 03:51 PM Please respond to ipp-owner@pwg.org @ internet To: ipp @ pwg.org @ internet cc: Subject: IPP> MOD - document format question In working on the Model document, I had several requests to come up with a better format for all of Job Template attributes. I used to have something like the following for each Job Template attribute: ------------------------------------------------------ 1.0 xxx (syntax) 1.1 As a create request attribute: xxx (syntax, OPT/MAND/etc.) 1.2 As a Job object attribute: xxx (syntax, OPT/MAND/etc.) 1.3 As a Printer object attribute 1.3.1 Default Behavior 1.3.2 As a default value ttribute: xxx (syntax, OPT/MAND/etc.) 1.3.3 As a supported attribute : xxx-supported (OPT/MAND/etc.) 1.3.4 As an available attribute : xxx-available (syntax, OPT/MAND/etc.) ------------------------------------------------------ Now I propose something like: (WARNING: requires some non-proportional spaced font) ------------------------------------------------------ 1.0 xxx +----------------------+-------------------+-------------------------+ | Create Request | JOB Object | Printer Supported | | Attribute | Attribute | Attribute | +----------------------+-------------------+-------------------------+ | xxx | xxx | xxx-supported | | syntax | syntax | syntax | | OPT/MAND/etc. | OPT/MAND/etc. | OPT/MAND/etc. | +----------------------+-------------------+-------------------------+ +----------------------+-------------------+ | Printer Default | Printer Available | | Value Attribute | Attribute | +----------------------+-------------------+ | xxx | xxx-available | | syntax | syntax | | OPT/MAND/etc. | OPT/MAND/etc. | +----------------------+-------------------+ Any comments or suggestions? Scott From ipp-archive Fri May 30 08:51:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA12001 for ipp-outgoing; Fri, 30 May 1997 08:47:33 -0400 (EDT) Message-Id: <199705301247.IAA01757@devnix.agranat.com> To: JK Martin Cc: ipp@pwg.org Subject: Re: IPP>PRO - Print by reference In-reply-to: <199705292137.RAA25484@uscore.underscore.com> Date: Fri, 30 May 1997 08:47:53 -0400 From: "Scott Lawrence" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO >>>>> "JK" == JK Martin writes: JK> We also readily agree with Roger's belief that print-by-reference JK> should be considered a basic (ie, mandatory) requirement for IPP. One objection that was raised to the use of HTTP as a 'transport' was that it might require substantial complexity. In response, I among others pointed out that only the 'origin server' requirements of HTTP would apply. If print-by-reference is a MUST, then most of the HTTP client requirements would be equally applicable. As I said before, I believe that specifying how this works if present is a very good idea, but I believe that whether or not to put this feature in any given product should be a choice left to the vendor. This strikes me as an easy feature to describe as a very small set of attributes which describe whether or not print-by-reference is supported and if so what identity the printer is configured to use and any network access restrictions it may have. -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-archive Fri May 30 09:01:45 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA12521 for ipp-outgoing; Fri, 30 May 1997 08:58:55 -0400 (EDT) From: Roger K Debry To: Subject: Re: IPP>PRO - Print by reference Message-Id: <5030100002972688000002L082*@MHS> Date: Fri, 30 May 1997 09:00:50 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO So far we have said (rightly or wrongly) that the actual fetch of the actual fetch of the referenced document was outside the scope of IPP. For example, an implementation might use FTP to retrieve a document. If this were the case, then don't we still get by with just an origin server? Do you thinnk we need to add the fetch to IPP and use HTTP for this? 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 05/30/97 06:52 AM --------------------------- ipp-owner @ pwg.org 05/30/97 06:55 AM Please respond to ipp-owner@pwg.org @ internet To: jkm @ underscore.com @ internet cc: ipp @ pwg.org @ internet Subject: Re: IPP>PRO - Print by reference >>>>> "JK" == JK Martin writes: JK> We also readily agree with Roger's belief that print-by-reference JK> should be considered a basic (ie, mandatory) requirement for IPP. One objection that was raised to the use of HTTP as a 'transport' was that it might require substantial complexity. In response, I among others pointed out that only the 'origin server' requirements of HTTP would apply. If print-by-reference is a MUST, then most of the HTTP client requirements would be equally applicable. As I said before, I believe that specifying how this works if present is a very good idea, but I believe that whether or not to put this feature in any given product should be a choice left to the vendor. This strikes me as an easy feature to describe as a very small set of attributes which describe whether or not print-by-reference is supported and if so what identity the printer is configured to use and any network access restrictions it may have. -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-archive Fri May 30 10:06:45 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA13082 for ipp-outgoing; Fri, 30 May 1997 10:03:05 -0400 (EDT) From: don@lexmark.com Message-Id: <199705301403.AA06434@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Fri, 30 May 1997 09:54:37 -0400 Subject: IPP> May 21st Conference Call Mime-Version: 1.0 Content-Type: multipart/mixed; Boundary="0__=b7lacwyIB0SO1YvPYxOZBDW7WcZzmnPjzxcpFd0tL1YlhNWWt4h46wq2" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO --0__=b7lacwyIB0SO1YvPYxOZBDW7WcZzmnPjzxcpFd0tL1YlhNWWt4h46wq2 Content-type: text/plain; charset=us-ascii (Embedded image moved to file: PIC11844.PCX) To: ipp@pwg.org cc: From: Don Wright @ LEXMARK@LEXMTA Manager, Strategic Alliances Dept C14L, Bldg 035-3 Lexington, Ky 40511 Phone: 606-232-4808 Fax: 606-232-6740 Date: 05/30/97 09:54:37 AM Subject: May 21st Conference Call As I was working on this week's conference call minutes, I noticed I forgot to post last week's, so here they are. I have posted TXT and PDF versions on the server at: ftp://ftp.pwg.org/pub/pwg/ipp/minutes/970521-ipp-conference-call.pdf ftp://ftp.pwg.org/pub/pwg/ipp/minutes/970521-ipp-conference-call.txt The text version is attached. This week's minutes will be later today. --------------------------------- PWG - Internet Printing Project Conference Call - May 21, 1997 The meeting was called to order at 4:10 PM EDT. Attendees: Bob Herriott - Sun Carl-Uno Manros - Xerox Don Wright - Lexmark Tom Hastings - Xerox Lee Farrell - Canon Jeff Copeland - QMS Jay Martin - Underscore Richard Schneider - Epson Steve Gebert - IBM Jim Walker - Dazel Angelo Caruso - Xerox Scott Isaacson - Novell Planned Agenda: - Follow-up on San Diego meeting - Coordination between JMP and IPP San Diego Meeting Follow-up Carl-Uno thought we had agreed to have separate documents covering the encoding of the operations and the mapping of that encoding to a specific transport. There is not a clear agreement among the group because each time one of the documents changes then all the documents that point to it must be updated with new reference information. On the other side, having everything in a single document may be intimidating to the first time reader. If we are going to have review drafts available for the Munich IETF, we should probably have an intermediate draft between now and the IETF draft deadline. The next draft of Paul Moore's document will be called IPP Level 1 rather than SWP. An issue was raised as to whether level 1 conformance would include the validate operation. Since the level 1 implementations will not support the GET_ATTRIBUTES function, the validate operation would provide a way to determine if various attributes are supported. Description on how to do multiple documents per job will not be included in the level one conformance document. This issue will be addressed by the protocol group. The model groups efforts will now move to be comments and discussion on specific text rather than the more free form discussions. There will be a security conference call on May 22nd. Goal for the next draft is to be available within the next two weeks (for internal IPP review.) Asynchronous Notification - currently the model document defines that the notification occurs to a URL which could be a "mailto" or an "http" URL. Coding and messages have not been defined. Reviewers need to read the model document and feedback what needs to be added, clarified, or changed. Coordination between IPP and JMP There are some differences between how JMP and IPP deal with the "job-state" and "job-state-reason" and this information is reported. The group felt some of these difference are far from the norm and should be handled in the simplest possible way and not mandatory for implementations. The group leaned toward having three job states: Aborted, Canceled and Completed. With these states, the importance of "job state reason" would be less. The IPP reasons would be a subset of the JMP reasons. The JMP reasons (especially the new ones) should be reviewed and a determination made as to their inclusion in IPP. A long discussion was held over the various reasons and what they mean. There was a belief that these reasons need be very obvious and clear. Backwards movements from one state to another will not be defined and listed as "unlikely." Changes to Job State Reasons * Job Incomplete - Incoming submission in progress * Reasons that hold a job should have the word HELD in the name * Don't need a generic job hold attribute in IPP * delete aborted by system Tom Hastings will create a "Day in the Life of a Printer" to better describe the various things that can happen when printing. Documents Carl-Uno made a proposal to have 4 transport independent documents: * Model-Semantics * Security * Directory Schema * IPP Syntax and Encoding of Operations and a transport dependent document: * IPP on HTTP Carl-Uno will send this proposal to the Area Directors and to the mailing list. Miscellaneous Model teleconference calls are on hold for right now. Discussions will be on the document and not general design sessions. The meeting adjourned at 6:10PM EDT --------------------------------- Best Regards, Don --0__=b7lacwyIB0SO1YvPYxOZBDW7WcZzmnPjzxcpFd0tL1YlhNWWt4h46wq2 Content-type: application/octet-stream; name="PIC11844.PCX" Content-transfer-encoding: base64 CgMBAQAAAAA4AgMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABSAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADl/9L/yf/F/8L/geUA0gDJAMUAAAGE5QDSAMkAxQAAAcHw5f/S/8n/xf/C /7g= --0__=b7lacwyIB0SO1YvPYxOZBDW7WcZzmnPjzxcpFd0tL1YlhNWWt4h46wq2-- From ipp-archive Fri May 30 10:51:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA13574 for ipp-outgoing; Fri, 30 May 1997 10:48:07 -0400 (EDT) From: Roger K Debry To: Subject: IPP>MOD - attribute description in Model document Message-Id: <5030100002976328000002L082*@MHS> Date: Fri, 30 May 1997 10:50:01 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Scott asked for comments on a proposal to use tables to describe job template attributes in the model document. I've sat here this morning thinking about how to make this attribute stuff comprehensible and have the following proposal: First of all, we should clean up the sections that provide over-all description of attributes. Get these sections crisp, clear and concise. There is some wording in section 4.5.1 of the current model document that suggests that there are several kinds of attributes: Printer attributes, Job attributes, and attributes that go into print requests. Although these have the same names and syntax they are somehow different attributes. I think it would be much simpler if we looked at it from the point of view that attributes are just attributes and by the way I can use them to describe printer capabilities or request specific job instructions. This may seem subtle, but I think would help the words a lot. Secondly, I continue to struggle with the notions of xxx-supported and xxx-available. As we hone in on the actual encoding of this stuff across the wire, I'd like to propose that we go back to Herriot's original notion of adornments. I think that we could very easily adopt an encoding scheme that allowed us to flag default and available attribute values. I'm particularly troubled by the wording in section 6.2 of the current model document (lines 1368-1379) that "there is no general rule for associating "xxx" with "xxx-supported" ..." I believe that adornments will give us a very much simpler model that what we currently have. If we take job priority as an example, on the wire why coudn't I have an encoding something like job-priority : 1-5, 1(D) meaning that job priority must be an integer in the range 1-5 and 1 is the default. Available could likewise be flagged for attributes to which it applies. Finally, if the overview is crisp, we should not have to write unique sections (or entries in a table) for every attribute variation. When I read the current model document most of what's there in the attribute descriptions is just a rehash of how an attribute works. I think it only adds a lot of unnecessary verbage and makes the document hard to read and appear complex. Given a good foundation, I believe that the only unique bit I need for each attribute is the default behaviour and whether or not it supports adornments. For example (compare this to section 6.2.5 of the current model document): 6.2.5 job-priority (integer (1:100)) This attribute specifies a priority for scheduling the print job. Printers that emply a priority based scheduling algorithm must support this attribute. A higher value specifies a higher priority. The value 1 is defined to indicate the lowest priority. Priority is expected to be distributed normally across this range. A Printer shall print all jobs with a priority value of n before printing any jobs with a priority of n-1 for all n. The mapping of vendor defined priority over this range is implementation specific. 6.2.5.1 Default behavior If a Printer does not implement job-priority, the Printer shall treat all jobs as if they had the same priority. 6.2.5.2 Adornments The job-priority attribute supports the "default" adornment.. Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-archive Fri May 30 11:41:48 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA14234 for ipp-outgoing; Fri, 30 May 1997 11:37:16 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 30 May 1997 09:37:08 -0600 From: Scott Isaacson To: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP>MOD - attribute description in Model document Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Thanks for taking the time to read, think, and comment. I did not distribute the whole document so what I distributed was out of context. I agree with most of your suggestions. Here are some of my comments: >>> Roger K Debry 05/30 8:50 AM >>> > Secondly, I continue to struggle with the notions of xxx-supported and > xxx-available. As we hone in on the actual encoding of this stuff > ... I propose that we eliminate all "xxx-available" attributes from the model document for version 1.0. Since it is already in place, and we know where it fits, we know that we can always add it to a later version if necessary. Also, the Model document says that all "supported" attributes are CONDITIONALLY MANDATORY. Also, if the "supported" attribute is implemented, then the default value attribute MUST be implemented as well. This means that since the Model document describes attributes called xxx and xxx-supported, if one is implemented the other must be as well, therefore, there is really no reason why we could not chose to encode them (on-the-wire) as a single structured text field as you suggest. The only problem with that would be added things like xxx-available later on. > Finally, if the overview is crisp, we should not have to write unique > sections (or entries in a table) for every attribute variation. When I > read the current model document most of what's there in the attribute > descriptions is just a rehash of how an attribute works. > ... 100% agreed. This is what we decided at the model meeting in San Diego. We need to describe Job Template attributes once, and then just give a clear, concise description of each attribute under each sub-section. I am thinking that one table at the beginning of the section on Job Templates is sufficient (that is do NOT include a little sub table in each subsection) so that ach subsection on each attribute just needs to be a paragraph or two. In other words, I would simplify your suggestion as follows (remember all syntax, naming, and implementation requirements go in the one table at the whole section). 6.2.5 job-priority This attribute specifies a priority for scheduling the print job. ************* remove this since we aleady describe once what CONDITIONALLY MANDATORY means --> Printers that employ a priority based scheduling algorithm must support this attribute. ******** A higher value specifies a higher priority. The value 1 is defined to indicate the lowest priority. Priority is expected to be distributed normally across this range. A Printer shall print all jobs with a priority value of n before printing any jobs with a priority of n-1 for all n. The mapping of vendor defined priority over this range is implementation specific. **** remove 6.2.5.1 Default behavior If a Printer does not implement job-priority, the Printer shall treat all jobs as if they had the same priority. 6.2.5.2 Adornments The job-priority attribute supports the "default" adornment.. ***** ************************************************************ 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 May 30 12:51:48 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA14749 for ipp-outgoing; Fri, 30 May 1997 12:47:48 -0400 (EDT) Message-Id: <9705301643.AA00723@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, 30 May 1997 09:41:05 PDT To: ipp@pwg.org, Scott Isaacson From: Tom Hastings Subject: Re: IPP> MOD - document format question Cc: JK Martin , SISAACSON@novell.com Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Scott, I think we need a real complete example, before we can give good feedback. I suggest two examples: one with keyword values and one with integer values. I would hope that we could still have our nice proportional spaced font form, and let the IETF suffer with its fixed space format. I've found the solutions to making fixed space from variable spaced in WORD and will be glad to help you. The only concession to the plain text form, should be the typographic convention that attribute name keywords are in double quotes (") and attribute value keywords are in single quotes (') as the document has mostly now. Also tables are good to avoid because they can't have line numbers in WORD. Also tables create more wasted space, making our document longer. And tables break across page boundaries, making the document harder to read. Finally changing from proportionally space to fixed to publish is harder with tables. I like Jay's lean mean approach to just list the forms, one per line and then have one description. Don't use too many features of MS-WORD (except table of contents now, an index later, and maybe cross references later). The defaults, supported, and available should not need specific description. We should be able to specify once up front what defaults, supported, and available means and not have any description for them. Like the first draft. Thanks, Tom At 15:00 05/29/97 PDT, JK Martin wrote: >Scott, > >If the boxed approach results in describing a single attribute in one >"row" in the plain text draft (as opposed to two rows in your example), >then perhaps the boxed approach might be an improvement over the existing >implementation. > >If the boxed approach doesn't work, then how about a lean'n'mean tabular >approach, such as: > > 1.0 xxx > > Description... > > Forms: > > Create request: xxx (OPT/MAND/etc) > Job object: xxx (OPT/MAND/etc) > Printer object: xxx (OPT/MAND/etc) > Default value: xxx (OPT/MAND/etc) > Supported: xxx-supported (OPT/MAND/etc) > Available: xxx-available (OPT/MAND/etc) > > >Just a thought on alternatives here. > >By the way, the fact that we have all these variations on attributes >is a bit scary and makes me wonder if we haven't gone over the top on >this part of the model. ;-) > > ...jay > >----- Begin Included Message ----- > >>From ipp-owner@pwg.org Thu May 29 17:49 EDT 1997 >Date: Thu, 29 May 1997 15:27:26 -0600 >From: Scott Isaacson >To: ipp@pwg.org >Subject: IPP> MOD - document format question > >In working on the Model document, I had several requests to come up with a >better format for all of Job Template attributes. > >I used to have something like the following for each Job Template attribute: >------------------------------------------------------ >1.0 xxx (syntax) >1.1 As a create request attribute: xxx (syntax, OPT/MAND/etc.) >1.2 As a Job object attribute: xxx (syntax, OPT/MAND/etc.) >1.3 As a Printer object attribute >1.3.1 Default Behavior >1.3.2 As a default value ttribute: xxx (syntax, OPT/MAND/etc.) >1.3.3 As a supported attribute : xxx-supported (OPT/MAND/etc.) >1.3.4 As an available attribute : xxx-available (syntax, OPT/MAND/etc.) >------------------------------------------------------ > >Now I propose something like: >(WARNING: requires some non-proportional spaced font) > >------------------------------------------------------ >1.0 xxx > >+----------------------+-------------------+-------------------------+ >| Create Request | JOB Object | Printer Supported | >| Attribute | Attribute | Attribute | >+----------------------+-------------------+-------------------------+ >| xxx | xxx | xxx-supported | >| syntax | syntax | syntax | >| OPT/MAND/etc. | OPT/MAND/etc. | OPT/MAND/etc. | >+----------------------+-------------------+-------------------------+ > >+----------------------+-------------------+ >| Printer Default | Printer Available | >| Value Attribute | Attribute | >+----------------------+-------------------+ >| xxx | xxx-available | >| syntax | syntax | >| OPT/MAND/etc. | OPT/MAND/etc. | >+----------------------+-------------------+ > > > >Any comments or suggestions? >Scott > >----- End Included Message ----- > > > From ipp-archive Fri May 30 13:26:48 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA15242 for ipp-outgoing; Fri, 30 May 1997 13:23:15 -0400 (EDT) Message-Id: <9705301710.AA00736@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, 30 May 1997 10:07:39 PDT To: Roger K Debry From: Tom Hastings Subject: Re: IPP>MOD - attribute description in Model document Cc: Sender: ipp-owner@pwg.org Precedence: bulk Status: RO The problems are only with the "job template" attribtes. I think that we can just describe the semantics of each xxx Job attribute and not the xxx, xxx-supported, and xxx-available Printer attribute, just list the allowed forms (as in Jay's proposal). Then up front we have a single discussion about the semantics of the xxx, xxx-supported, and xxx-available Printer attributes. One possibility that may make things more understandable, is to NOT have the same name for the Job and Printer attribute. For the Printer attribute algorithmically add: "-default". Also I don't want to lose the current data type in the header, so that the table of contents is a simple listing of the attributes. Job template attributes are only listed once as xxx, and the xxx-default, xxx-supported, and xxx-ready don't get listed in the table of contents. I don't think that we need the Mandatory in the header and TOC, since not all corresonding xxx-yyy Printer attributes will wind up in the TOC. I also suggest that the forms should come first, like a program description of procedure calls or UNIX man pages. For forms that aren't allowed, just don't list them. If no default, don't list it, if no available, don't list it. So Jay's suggestion would become (for the job template attributes only): 6.2.1 xxx (type4 keyword) Create request: xxx (type4 keyword) (OPT/MAND/etc) Job object: xxx (type4 keyword) (OPT/MAND/etc) Printer object: xxx-default (type4 keyword) (OPT/MAND/etc) Printer object: xxx-supported (1setOf type4 keyword) (OPT/MAND/etc) Printer object: xxx-available (1setOf type4 keyword) (OPT/MAND/etc) Description... The standard values for named time periods are: 'no-hold': immediately.... 'aaa': blah blah .................................... blah blah 'bbb': blah blah 6.2.2 yyy (integer(1:100)) Create request: yyy (integer(1:100)) (OPT/MAND/etc) Job object: yyy (integer(1:100)) (OPT/MAND/etc) Printer object: yyy-default (integer(1:100)) (OPT/MAND/etc) Printer object: yyy-supported (rangeOf integer(1:100))(OPT/MAND/etc) Description... Then the simpler non-job-template job and printer attributes would simply be: 6.3.1 zzz (type1 keyword) Job object: zzz (type1 keyword) (OPT/MAND/etc) Description... The standard values for job states are: 'no-hold': immediately.... 'aaa': blah blah .................................... blah blah 'bbb': blah blah 6.4.1 mmm (integer(0:2**31-1) Priner object: integer(0:2**31-1) (OPT/MAND/etc Description... At 07:50 05/30/97 PDT, Roger K Debry wrote: >Scott asked for comments on a proposal to use tables to describe >job template attributes in the model document. I've sat here this morning >thinking about how to make this attribute stuff comprehensible and have >the following proposal: > >First of all, we should clean up the sections that provide over-all description >of attributes. Get these sections crisp, clear and concise. There is some >wording in section 4.5.1 of the current model document that suggests that >there are several kinds of attributes: Printer attributes, Job attributes, and >attributes that go into print requests. Although these have the same names >and syntax they are somehow different attributes. I think it would be much >simpler if we looked at it from the point of view that attributes are just >attributes >and by the way I can use them to describe printer capabilities or request >specific job instructions. This may seem subtle, but I think would help the >words a lot. > >Secondly, I continue to struggle with the notions of xxx-supported and >xxx-available. As we hone in on the actual encoding of this stuff >across the wire, I'd like to propose that we go back to Herriot's original >notion of adornments. I think that we could very easily adopt an encoding >scheme that allowed us to flag default and available attribute values. >I'm particularly troubled by the wording in section 6.2 of the current model >document (lines 1368-1379) that "there is no general rule for associating >"xxx" with "xxx-supported" ..." I believe that adornments will give us a >very much simpler model that what we currently have. > >If we take job priority as an example, on the wire why coudn't I have an >encoding something like > > job-priority : 1-5, 1(D) > >meaning that job priority must be an integer in the range 1-5 and 1 is the >default. Available could likewise be flagged for attributes to which it >applies. > >Finally, if the overview is crisp, we should not have to write unique >sections (or entries in a table) for every attribute variation. When I >read the current model document most of what's there in the attribute >descriptions is just a rehash of how an attribute works. I think it only >adds a lot of unnecessary verbage and makes the document >hard to read and appear complex. Given a good foundation, I believe >that the only unique bit I need for each attribute is the default behaviour >and whether or not it supports adornments. > >For example (compare this to section 6.2.5 of the current model document): > >6.2.5 job-priority (integer (1:100)) > >This attribute specifies a priority for scheduling the print job. Printers that >emply a priority based scheduling algorithm must support this attribute. >A higher value specifies a higher priority. The value 1 is defined to indicate >the lowest priority. Priority is expected to be distributed normally across >this range. A Printer shall print all jobs with a priority value of n before >printing any jobs with a priority of n-1 for all n. The mapping of vendor >defined priority over this range is implementation specific. > >6.2.5.1 Default behavior > >If a Printer does not implement job-priority, the Printer shall treat all jobs >as if they had the same priority. > >6.2.5.2 Adornments > >The job-priority attribute supports the "default" adornment.. > > > >Roger K deBry >Senior Techncial Staff Member >Architecture and Technology >IBM Printing Systems >email: rdebry@us.ibm.com >phone: 1-303-924-4080 > > From ipp-archive Fri May 30 13:31:54 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA15295 for ipp-outgoing; Fri, 30 May 1997 13:28:01 -0400 (EDT) Message-ID: <338F06E6.3847@parc.xerox.com> Date: Fri, 30 May 1997 09:57:10 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: Scott Lawrence CC: JK Martin , ipp@pwg.org Subject: Re: IPP>PRO - Print by reference References: <199705301247.IAA01757@devnix.agranat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO The capability of being able to print-by-reference might be thought of as similar to the capability to be able to print any given media type. In fact, print-by-reference might be implemented by sending, instead of application/vnd.adobe.postscript or application/vnd.hp.pcl, sending message/external-body. > This strikes me as an easy feature to describe as a very small set > of attributes which describe whether or not print-by-reference is > supported and if so what identity the printer is configured to use > and any network access restrictions it may have. The difficult issue in print-by-reference is how the sender supplies the credentials if any at all are required. There is no single standard for identity in Internet protocols, and there's no standard encapsulation of credentials. Larry -- http://www.parc.xerox.com/masinter From ipp-archive Fri May 30 13:51:48 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA16206 for ipp-outgoing; Fri, 30 May 1997 13:49:34 -0400 (EDT) Date: Fri, 30 May 1997 13:49:39 -0400 (EDT) From: JK Martin Message-Id: <199705301749.NAA19933@uscore.underscore.com> To: masinter@parc.xerox.com Subject: Re: IPP>PRO - Print by reference Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Good point about passing credentials (or lack thereof) to the printer for print-by-reference. What if we were to implicitly limit print-by-reference to only world- readable documents (ie, no credentials needed)? For the suggested scenarios of enterprise document repositories and general public repositories (eg, IETF drafts), this should work just fine, right? In the case of the enterprise, the repository is assumed to be inside the firewall, anyway, so "public" access is pretty much assumed. ...jay ----- Begin Included Message ----- >From masinter@parc.xerox.com Fri May 30 13:28 EDT 1997 Date: Fri, 30 May 1997 09:57:10 PDT From: Larry Masinter Organization: Xerox PARC To: Scott Lawrence CC: JK Martin , ipp@pwg.org Subject: Re: IPP>PRO - Print by reference Content-Transfer-Encoding: 7bit The capability of being able to print-by-reference might be thought of as similar to the capability to be able to print any given media type. In fact, print-by-reference might be implemented by sending, instead of application/vnd.adobe.postscript or application/vnd.hp.pcl, sending message/external-body. > This strikes me as an easy feature to describe as a very small set > of attributes which describe whether or not print-by-reference is > supported and if so what identity the printer is configured to use > and any network access restrictions it may have. The difficult issue in print-by-reference is how the sender supplies the credentials if any at all are required. There is no single standard for identity in Internet protocols, and there's no standard encapsulation of credentials. Larry -- http://www.parc.xerox.com/masinter ----- End Included Message ----- From ipp-archive Fri May 30 14:16:50 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA17014 for ipp-outgoing; Fri, 30 May 1997 14:15:30 -0400 (EDT) Message-Id: <199705301816.OAA03133@devnix.agranat.com> To: ipp@pwg.org Subject: Re: IPP>PRO - Print by reference In-reply-to: <338F06E6.3847@parc.xerox.com> Date: Fri, 30 May 1997 14:16:13 -0400 From: "Scott Lawrence" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO >>>>> "LM" == Larry Masinter writes: LM> The difficult issue in print-by-reference is how the sender LM> supplies the credentials if any at all are required. There LM> is no single standard for identity in Internet protocols, and LM> there's no standard encapsulation of credentials. Agreed; which, I presume, is why Roger K deBry [RKD] suggested that only 'publicly available' [a question-begging term, IMHO] documents could be printed by reference: RKD> The two conditions required are that the document be in a RKD> standard printable format and that the document be publicaly RKD> available. My answer is to say that no credentials of the user are employed by the printer to obtain the referenced document; instead, whatever credentials of its own the printer has are used. This degenerates to Rogers' model when the printer has no credentials of any kind (but note that the document repository might choose to consider the source IP address or domain name of the printer to be a form of weak but acceptable credential). You might need an extra status or two to communicate the inability of the printer to access the referenced document, but I suspect you need that no matter how you do this. -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-archive Fri May 30 15:01:50 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA17526 for ipp-outgoing; Fri, 30 May 1997 14:58:44 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 30 May 1997 12:57:52 -0600 From: Scott Isaacson To: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP>PRO - Print by reference Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I thought that a "reference" in "print-by-reference" meant a URI. If it is a URI, then the URI determines the method for "fetching". We do not need to do anything to IPP to define a new way to fetch. If it is an HTTP URI, do a GET on the URL If it is an FTP URI, use FTP, etc. I don't see an URI like "ipp://..." being used. I had thought about what Scott L. was suggesting about having an attribute describe the whether the Printer supported print-by-reference or not. What if we made this like "notification-addresses-supported" which is a list of URI schemes that are supported by the Printer.? 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 ************************************************************ >>> Roger K Debry 05/30 7:00 AM >>> So far we have said (rightly or wrongly) that the actual fetch of the actual fetch of the referenced document was outside the scope of IPP. For example, an implementation might use FTP to retrieve a document. If this were the case, then don't we still get by with just an origin server? Do you thinnk we need to add the fetch to IPP and use HTTP for this? 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 05/30/97 06:52 AM --------------------------- ipp-owner @ pwg.org 05/30/97 06:55 AM Please respond to ipp-owner@pwg.org @ internet To: jkm @ underscore.com @ internet cc: ipp @ pwg.org @ internet Subject: Re: IPP>PRO - Print by reference >>>>> "JK" == JK Martin writes: JK> We also readily agree with Roger's belief that print-by-reference JK> should be considered a basic (ie, mandatory) requirement for IPP. One objection that was raised to the use of HTTP as a 'transport' was that it might require substantial complexity. In response, I among others pointed out that only the 'origin server' requirements of HTTP would apply. If print-by-reference is a MUST, then most of the HTTP client requirements would be equally applicable. As I said before, I believe that specifying how this works if present is a very good idea, but I believe that whether or not to put this feature in any given product should be a choice left to the vendor. This strikes me as an easy feature to describe as a very small set of attributes which describe whether or not print-by-reference is supported and if so what identity the printer is configured to use and any network access restrictions it may have. From ipp-archive Fri May 30 15:11:51 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA18004 for ipp-outgoing; Fri, 30 May 1997 15:07:39 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 30 May 1997 13:06:23 -0600 From: Scott Isaacson To: masinter@parc.xerox.com, jkm@underscore.com Cc: ipp@pwg.org Subject: Re: IPP>PRO - Print by reference Sender: ipp-owner@pwg.org Precedence: bulk Status: RO >>> JK Martin 05/30 11:49 AM >>> > What if we were to implicitly limit print-by-reference to only world- > readable documents (ie, no credentials needed)? I agree with this simplification. In Austin, I thought we all agreed that print-by-reference would only include "public" documents. Yes, we all know that that doesn't allow all end users to print all documents that they can get at through a browser, but it does allow for MANY end users to print MANY of the documents that they can get at without any sort of authentication. Let's not throw out a VERY useful feature, just because it does not solve ALL problems EVERYWHERE. Scott From ipp-archive Fri May 30 15:11:52 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA18015 for ipp-outgoing; Fri, 30 May 1997 15:08:12 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 30 May 1997 13:07:51 -0600 From: Scott Isaacson To: lawrence@agranat.com, ipp@pwg.org Subject: Re: IPP>PRO - Print by reference Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Great summary. I agree. >>> "Scott Lawrence" 05/30 12:16 PM >>> >>>>> "LM" == Larry Masinter writes: LM> The difficult issue in print-by-reference is how the sender LM> supplies the credentials if any at all are required. There LM> is no single standard for identity in Internet protocols, and LM> there's no standard encapsulation of credentials. Agreed; which, I presume, is why Roger K deBry [RKD] suggested that only 'publicly available' [a question-begging term, IMHO] documents could be printed by reference: RKD> The two conditions required are that the document be in a RKD> standard printable format and that the document be publicaly RKD> available. My answer is to say that no credentials of the user are employed by the printer to obtain the referenced document; instead, whatever credentials of its own the printer has are used. This degenerates to Rogers' model when the printer has no credentials of any kind (but note that the document repository might choose to consider the source IP address or domain name of the printer to be a form of weak but acceptable credential). You might need an extra status or two to communicate the inability of the printer to access the referenced document, but I suspect you need that no matter how you do this. -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-archive Fri May 30 15:56:51 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA19878 for ipp-outgoing; Fri, 30 May 1997 15:54:50 -0400 (EDT) From: don@lexmark.com Message-Id: <199705301954.AA19483@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Fri, 30 May 1997 15:54:08 -0400 Subject: IPP> May 28th Conference Call Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: bulk Status: RO To: ipp@pwg.org cc: From: Don Wright @ LEXMARK@LEXMTA Date: 05/30/97 03:54:08 PM Subject: May 28th Conference Call I have uploaded the meeting minutes from the May 28th Conference Call to the ftp server in both TXT and PDF formats. They are located at: ftp://ftp.pwg.org/pub/pwg/ipp/minutes/970528-ipp-conference-call.txt ftp://ftp.pwg.org/pub/pwg/ipp/minutes/970528-ipp-conference-call.pdf I have attached a copy of the text version at the bottom of this note. ------------------- PWG - Internet Printing Project Conference Call - May 28, 1997 Attendees: Don Wright - Lexmark Peter Zehler - Xerox Roger DeBry - IBM Scott Isaacson - Novell Carl-Uno Manros - Xerox Tom Hastings - Xerox Ron Bergman - Data Products Randy Turner - Sharp Ira McDonald - Xerox Angelo Caruso - Xerox J.K. Martin - Underscore Bob Herriot - Sun Jim Walker - Dazel Jeff Copeland - QMS Agenda 1) Revised Charter 2) JOB MIB/IPP Harmonization REVISED CHARTER Carl-Uno led the discussion on the updates to the IETF Charter. There have been few comments on the mailing list. An author is needed for the LPR mapping document. Someone with a system background, with LPR experience, etc. would be the ideal author. At this time, no one volunteered. Should the date for prototyping move from July out? The group's opinion is that the July date is not realistic and should be moved out to at least August. The group should plan on a bake-off of some type. The biggest concern is how to actually connect it to the Internet and be able to test the clients and servers in a real Internet environment rather than a more controlled, contrived network. Should we split up the PROTOCOL document into two parts? One part that is actually protocol neutral and the other mapping to a specific protocol? Roger Debry suggested putting the protocol neutral items into the MODEL document rather than creating another document. Roger reminded the group about the difficulty of keeping multiple documents synchronized. A consensus began to form that putting the protocol neutral information into the MODEL document was the right thing to do. At this point Randy Turner expressed his concerns that fully separating the PDU from the transport would make a less efficient solution. Additionally, feedback from the Memphis IETF encouraged the group to put a stake in the ground and specify a complete protocol rather than attempt to be so generic and effectively specify nothing concrete. At the end, the group generally agreed to keep the MODEL document abstract and to create a PROTOCOL document that including encoding as well as the specific HTTP information. A brief discussion on print-by-reference and its importance to the NC (Network Computer) environment was held. This discussion was suspended to allow the Job MIB/IPP harmonization discussion to begin. JOB MIB and IPP Harmonization The discussion centered on the number of job states that should be supported. There are basically three states: before, during and after printing. These three states are then broken down further to provide more information. This is a total of seven states: Pending Pending - Stopped Processing Processing - Stopped Done - Abort Done - Canceled Done - Completed JobState and JobStateReasons will be mandatory. A separate JOB conference call will be scheduled to work on this in more detail. Having harmony between the JOB MIB and IPP is necessary and a strong goal of the two groups. Tom Hastings will write up a new proposal and most it to the mailing lists. PROTOCOL DOCUMENT The discussion on how much information to include in the PROTOCOL document resumed after the JMP discussion. A protocol working group meeting was scheduled for June 17th at SUN in Menlo Park starting at 9:30 AM. Comments on Randy's IPP Protocol Document: 1) Where should the concept of levels of function be included? 2) Should the length fields be binary values or text? Many of the participants on the call thought fixed length ASCII encoded text for length is preferred. At the end, the opinions were still mixed but won't be changed right now. 3) We shouldn't call the OPERATION and attribute but rather keep it at the first of the PDU and call it something besides attribute. 4) A concern was raised over the concept of "unsupported-attributes." 5) What should happen on a GetJobs request? Everything? A specific list asked for by the client? Something else? Resolution: The clients get everything up to a specified limit using a filter provided by the client. This will be specified in the model document. 6) Values are unsigned 7) Names are limited as specified in the model document. Carl-Uno reported on the security work and announced a security conference call will be held on Friday. Bob Herriot will set up a Monday conference call to discuss the protocol document in more detail. The conference call ended at 6:50 PM EDT ------------------- 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 May 30 17:01:51 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA22035 for ipp-outgoing; Fri, 30 May 1997 16:59:32 -0400 (EDT) From: Roger K Debry To: Subject: Re: IPP>MOD - attribute description in Model document Message-Id: <5030100002993155000002L052*@MHS> Date: Fri, 30 May 1997 17:01:25 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Some addiitonal comments follow ....... The problems are only with the "job template" attribtes. I think that we can just describe the semantics of each xxx Job attribute and not the xxx, xxx-supported, and xxx-available Printer attribute, just list the allowed forms (as in Jay's proposal). Then up front we have a single discussion about the semantics of the xxx, xxx-supported, and xxx-available Printer attributes. RKD> I am really hung up on two issues: RKD> The first is just the comprehension issue, which to some RKD> extent can be fixed as suggested above. RKD> The second issue is one that I caught when re-reading RKD> the document for the nth time and thinking about the RKD> code problem in dealing with different attribute names RKD> and trying to correlate them. That's why going back RKD> (atleast on the wire) to a flag or an adornment makes RKD> better sense to me. It would make the client code much RKD> easier to write and much less prone to errors if the RKD> notion of an adornment or flag to the base attributet RKD> were used. One possibility that may make things more understandable, is to NOT have the same name for the Job and Printer attribute. For the Printer attribute algorithmically add: "-default". RKD> Please **NO**. I think that only complicates things. RKD> The biggest problem I have when reading the document RKD> is dealing with all of these different kinds of attributes. RKD> Giving them a different name only makes the problem worse RKD> in my mind. ... snip ... From ipp-archive Fri May 30 17:16:52 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA22986 for ipp-outgoing; Fri, 30 May 1997 17:12:44 -0400 (EDT) Message-ID: <338F369B.35D7@parc.xerox.com> Date: Fri, 30 May 1997 13:20:43 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: Scott Isaacson CC: lawrence@agranat.com, ipp@pwg.org Subject: Re: IPP>PRO - Print by reference References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I think that you might want to allow a 'reference' to be a compound attribute consisting of a URL (the location of the referenced resource) and the credentials (the authority by which the reference is being accessed), but leave the enumeration of possible credential types empty for now; alternatively, you could define a reference to be a URL (the location of a referenced resource) but independently supply URL/credential pairs, as part of the print submit. But adding a protocol element which requires data access for data which is frequently not 'public' without making any accomodation at all for secure transmission of credentials is probably not adequately addressing the security concerns: it will encourage users to make private documents 'public' merely for the capability of printing them; as such, it would countermand the imperative to make the Internet more secure, not less. Let me say this a different way: Don't try to do print-by-reference without doing what's necessary to use it securely. Larry -- http://www.parc.xerox.com/masinter From ipp-archive Fri May 30 17:16:53 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA22991 for ipp-outgoing; Fri, 30 May 1997 17:12:48 -0400 (EDT) Message-Id: <9705301647.AA00727@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, 30 May 1997 09:45:06 PDT To: Roger K Debry From: Tom Hastings Subject: Re: IPP>MOD - attribute description in Model document Cc: Sender: ipp-owner@pwg.org Precedence: bulk Status: RO At 07:50 05/30/97 PDT, Roger K Debry wrote: >Scott asked for comments on a proposal to use tables to describe >job template attributes in the model document. I've sat here this morning >thinking about how to make this attribute stuff comprehensible and have >the following proposal: > >First of all, we should clean up the sections that provide over-all description >of attributes. Get these sections crisp, clear and concise. There is some >wording in section 4.5.1 of the current model document that suggests that >there are several kinds of attributes: Printer attributes, Job attributes, and >attributes that go into print requests. Although these have the same names >and syntax they are somehow different attributes. I think it would be much >simpler if we looked at it from the point of view that attributes are just >attributes >and by the way I can use them to describe printer capabilities or request >specific job instructions. This may seem subtle, but I think would help the >words a lot. > >Secondly, I continue to struggle with the notions of xxx-supported and >xxx-available. As we hone in on the actual encoding of this stuff >across the wire, I'd like to propose that we go back to Herriot's original >notion of adornments. I think that we could very easily adopt an encoding >scheme that allowed us to flag default and available attribute values. >I'm particularly troubled by the wording in section 6.2 of the current model >document (lines 1368-1379) that "there is no general rule for associating >"xxx" with "xxx-supported" ..." We agreed to make the xxx-supported algorighmic, even if the English isn't correct. So we get medium-supported, job-priority-supported, etc. Many of the attributes are plural already, so there isn't any problem with them. > I believe that adornments will give us a >very much simpler model that what we currently have. > >If we take job priority as an example, on the wire why coudn't I have an >encoding something like > > job-priority : 1-5, 1(D) > >meaning that job priority must be an integer in the range 1-5 and 1 is the >default. Available could likewise be flagged for attributes to which it >applies. > >Finally, if the overview is crisp, we should not have to write unique >sections (or entries in a table) for every attribute variation. When I >read the current model document most of what's there in the attribute >descriptions is just a rehash of how an attribute works. I think it only >adds a lot of unnecessary verbage and makes the document >hard to read and appear complex. Given a good foundation, I believe >that the only unique bit I need for each attribute is the default behaviour >and whether or not it supports adornments. > >For example (compare this to section 6.2.5 of the current model document): > >6.2.5 job-priority (integer (1:100)) > >This attribute specifies a priority for scheduling the print job. Printers that >emply a priority based scheduling algorithm must support this attribute. >A higher value specifies a higher priority. The value 1 is defined to indicate >the lowest priority. Priority is expected to be distributed normally across >this range. A Printer shall print all jobs with a priority value of n before >printing any jobs with a priority of n-1 for all n. The mapping of vendor >defined priority over this range is implementation specific. > >6.2.5.1 Default behavior > >If a Printer does not implement job-priority, the Printer shall treat all jobs >as if they had the same priority. > >6.2.5.2 Adornments > >The job-priority attribute supports the "default" adornment.. > > > >Roger K deBry >Senior Techncial Staff Member >Architecture and Technology >IBM Printing Systems >email: rdebry@us.ibm.com >phone: 1-303-924-4080 > > From ipp-archive Fri May 30 17:16:54 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA22992 for ipp-outgoing; Fri, 30 May 1997 17:12:49 -0400 (EDT) Message-Id: <9705301959.AA00826@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, 30 May 1997 12:57:38 PDT To: Scott Isaacson From: Tom Hastings Subject: Re: IPP>MOD - attribute description in Model document Cc: ipp@pwg.org, rdebry@us.ibm.com Sender: ipp-owner@pwg.org Precedence: bulk Status: RO At 08:37 05/30/97 PDT, Scott Isaacson wrote: >Thanks for taking the time to read, think, and comment. > >I did not distribute the whole document so what I distributed was out of >context. I agree with most of your suggestions. Here are some of my >comments: > > >>>> Roger K Debry 05/30 8:50 AM >>> >> Secondly, I continue to struggle with the notions of xxx-supported and >> xxx-available. As we hone in on the actual encoding of this stuff >> ... > >I propose that we eliminate all "xxx-available" attributes from the model >document for version 1.0. Since it is already in place, and we know where >it fits, we know that we can always add it to a later version if necessary. I'm somewhat concerned about removing them from V1.0, because adding them later is a bigger step than just adding yet another attribute. xxx-available introduces the concept of parallel multiple-valued attributes. It may come as a shock to implementors that implemented multiple-valued atributes, say as a bit mask in V1.0, to discover that the values are ordered, not just an unorderd set. However, we might reduce the number from 6 to a smaller number. The current attr-05f.doc file had the following 6 xxx-available attributes: media-available number-up-available sides-available printer-resolution-available print-quality-available finishings-available I'd be happy if that were further reduced to say, just: media-available finishings-available since for the others the supported values are almost always ready. > > >Also, the Model document says that all "supported" attributes are >CONDITIONALLY MANDATORY. Also, if the "supported" attribute is implemented, >then the default value attribute MUST be implemented as well. This means >that since the Model document describes attributes called xxx and >xxx-supported, if one is implemented the other must be as well, therefore, >there is really no reason why we could not chose to encode them >(on-the-wire) as a single structured text field as you suggest. The only >problem with that would be added things like xxx-available later on. Exactly why I'm concerned about removing xxx-available entirely. > > >> Finally, if the overview is crisp, we should not have to write unique >> sections (or entries in a table) for every attribute variation. When I >> read the current model document most of what's there in the attribute >> descriptions is just a rehash of how an attribute works. >> ... > >100% agreed. This is what we decided at the model meeting in San Diego. We >need to describe Job Template attributes once, and then just give a clear, >concise description of each attribute under each sub-section. I am thinking >that one table at the beginning of the section on Job Templates is >sufficient (that is do NOT include a little sub table in each subsection) so >that ach subsection on each attribute just needs to be a paragraph or two. > >In other words, I would simplify your suggestion as follows (remember all >syntax, naming, and implementation requirements go in the one table at the >whole section). > >6.2.5 job-priority > >This attribute specifies a priority for scheduling the print job. > >************* > remove this since we aleady describe once what CONDITIONALLY >MANDATORY means --> Printers that >employ a priority based scheduling algorithm must support this attribute. >******** > >A higher value specifies a higher priority. The value 1 is defined to >indicate >the lowest priority. Priority is expected to be distributed normally across >this range. A Printer shall print all jobs with a priority value of n >before >printing any jobs with a priority of n-1 for all n. The mapping of vendor >defined priority over this range is implementation specific. > >**** remove >6.2.5.1 Default behavior >If a Printer does not implement job-priority, the Printer shall treat all >jobs >as if they had the same priority. >6.2.5.2 Adornments >The job-priority attribute supports the "default" adornment.. >***** Looks like good simplification. Tom >************************************************************ >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 May 30 17:36:58 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA24432 for ipp-outgoing; Fri, 30 May 1997 17:33:15 -0400 (EDT) Date: Fri, 30 May 1997 14:34:41 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705302134.OAA10056@woden.eng.sun.com> To: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP>MOD - attribute description in Model document X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > From rdebry@us.ibm.com Fri May 30 14:08:44 1997 > > RKD> I am really hung up on two issues: > RKD> The first is just the comprehension issue, which to some > RKD> extent can be fixed as suggested above. > RKD> The second issue is one that I caught when re-reading > RKD> the document for the nth time and thinking about the > RKD> code problem in dealing with different attribute names > RKD> and trying to correlate them. That's why going back > RKD> (atleast on the wire) to a flag or an adornment makes > RKD> better sense to me. It would make the client code much > RKD> easier to write and much less prone to errors if the > RKD> notion of an adornment or flag to the base attributet > RKD> were used. > In an earlier email you cited the sentence in the model document (lines 1368-1379) "there is no general rule for associating "xxx" with "xxx-supported" ...". At the San Diego meeting we decided that keyword variants should be built in a regular fashion even if the rules for English were violated. We wanted xxx and xxx-supported always to be related. For example, it is 'media' and 'media-supported' even if it should be 'medium' by the rules of English. This gives us the adornments that you want without putting them in the value. At that meeting we left undetermined whether the variant should be denoted by prefixes or suffixes, though currently we are using suffixes. Bob Herriot From ipp-archive Fri May 30 17:56:52 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA25720 for ipp-outgoing; Fri, 30 May 1997 17:53:13 -0400 (EDT) Date: Fri, 30 May 1997 14:54:55 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705302154.OAA10078@woden.eng.sun.com> To: ipp@pwg.org, don@lexmark.com Subject: Re: IPP> MOD JobState suggestion X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO At the Wednesday meeting we agreed to the following states. In the first two pairs of states there are base states of pending and processing with a variant for each state formed by adding "stopped". In the last triple, there are three variants with suffixes, but there is no "done" state. The states are: pending pending-stopped processing processing-stopped done-aborted done-canceled done-completed I suggest changing the last three states to completed completed-canceled completed-abort Then, as with the first two pairs, the single word represents the normal case, and the suffixed variants are special cases of completion. These single-word states then fit in with the three attributes: time-since-pending time-since-processing time-since-completed Bob Herriot From ipp-archive Fri May 30 18:06:52 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA26492 for ipp-outgoing; Fri, 30 May 1997 18:06:23 -0400 (EDT) Date: Fri, 30 May 1997 15:04:47 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705302204.PAA10092@woden.eng.sun.com> To: SISAACSON@novell.com Subject: Re: IPP> MOD - document format question Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I like Jay's suggestion best for the formatting. I also agree with others about eliminating redundant text. Say it once and say what it applies to. Bob Herriot > From jkm@underscore.com Thu May 29 15:10:12 1997 > > > 1.0 xxx > > Description... > > Forms: > > Create request: xxx (OPT/MAND/etc) > Job object: xxx (OPT/MAND/etc) > Printer object: xxx (OPT/MAND/etc) > Default value: xxx (OPT/MAND/etc) > Supported: xxx-supported (OPT/MAND/etc) > Available: xxx-available (OPT/MAND/etc) > > From ipp-archive Fri May 30 18:11:52 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA26572 for ipp-outgoing; Fri, 30 May 1997 18:09:02 -0400 (EDT) Date: Fri, 30 May 1997 15:10:44 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705302210.PAA10096@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO June 17 meeting X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO The following people have RSVPed for the June 17th face-to-face meeting. If you plan to come and your name is missing, please let me know. in person Randy Turner Bob Herriot Carl-Uno Manros Jeff Copeland (maybe) Jay Martin (maybe) via telephone Peter Zehler Scott Isaacson (for part of the meeting) From ipp-archive Fri May 30 19:41:53 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA28577 for ipp-outgoing; Fri, 30 May 1997 19:40:21 -0400 (EDT) Date: Fri, 30 May 1997 16:42:06 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199705302342.QAA10208@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO teleconference on Monday June 2 X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO The agenda for Monday's teleconference is: 1) finish reviewing Randy's draft that was distributed last Tuesday. The meeting is Monday June 2 from 1pm PDT to 3pm. The number is: 415-278-2944 passcode: 3440795 From ipp-archive Fri May 30 20:31:54 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA29233 for ipp-outgoing; Fri, 30 May 1997 20:31:38 -0400 (EDT) Message-Id: <199705310031.RAA15403@bulletin> To: Robert.Herriot@Eng.Sun.COM (Robert Herriot) cc: ipp@pwg.org Subject: Re: IPP>PRO June 17 meeting In-reply-to: Your message of "Fri, 30 May 1997 15:10:44 PDT." <199705302210.PAA10096@woden.eng.sun.com> Date: Fri, 30 May 1997 17:31:34 PDT From: "Steve Zilles" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO This unfortunately conflicts with the W3C AC Meeting in Japan; but, I will be gone for most of June anyway. Steve From ipp-archive Fri May 30 20:36:54 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA29264 for ipp-outgoing; Fri, 30 May 1997 20:33:58 -0400 (EDT) Message-Id: <199705310033.RAA15462@bulletin> To: Robert.Herriot@Eng.Sun.COM (Robert Herriot) cc: ipp@pwg.org Subject: Re: IPP>PRO teleconference on Mondays during June, starting June 2 In-reply-to: Your message of "Wed, 28 May 1997 17:56:13 PDT." <199705290056.RAA07918@woden.eng.sun.com> Date: Fri, 30 May 1997 17:33:53 PDT From: "Steve Zilles" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO When did we move the Protocol call to Monday afternoon; I thought it was Monday morning. I have conflicts with Monday afternoon. Steve Z.