From ipp-archive Mon Jun 2 09:17:28 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA13272 for ipp-outgoing; Mon, 2 Jun 1997 09:12:46 -0400 (EDT) From: Roger K Debry To: Cc: Subject: IPP>PRO June 17 meeting Message-Id: <5030100003028943000002L032*@MHS> Date: Mon, 2 Jun 1997 09:14:59 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I plan to attend in person. 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 06/02/97 07:09 AM --------------------------- ipp-owner @ pwg.org 05/30/97 04:20 PM Please respond to ipp-owner@pwg.org @ internet To: ipp @ pwg.org @ internet cc: Subject: IPP>PRO June 17 meeting 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 Mon Jun 2 18:07:33 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA15406 for ipp-outgoing; Mon, 2 Jun 1997 18:05:47 -0400 (EDT) From: Harry Lewis To: Cc: Subject: Re: IPP> MOD JobState suggestion Message-Id: <5030100003054899000002L092*@MHS> Date: Mon, 2 Jun 1997 18:07:54 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk I am confused by the notation used in this discussion: >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 I understand PENDING, PROCESSING and COMPLETED states. I thought I was following a thread, somewhere, that PENDING-STOPPED was another way to say HELD and PROCESSING-STOPPED was another way to say NEEDS ATTENTION. Is this what is going on... just some renaming? Or do the "dashes" in these names indicate separation between a state and a reason? I agree with Bob's recommendations, above, to stick with Completed rather than Done. Why change? And, for that matter, why not keep HELD and NEEDS ATTENTION? What are we gaining. I find these discussions frequently go down the "generic language" path until the labels we choose are so vague that, rather than risk misinterpretation, the names end up meaning very little at all. Harry Lewis From ipp-archive Mon Jun 2 18:22:33 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA16182 for ipp-outgoing; Mon, 2 Jun 1997 18:21:52 -0400 (EDT) Date: Mon, 2 Jun 1997 15:23:22 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706022223.PAA12980@woden.eng.sun.com> To: ipp@pwg.org, harryl@us.ibm.com Subject: Re: JMP> Re: IPP> MOD JobState suggestion Cc: jmp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk In one sense we have just renamed some states: held to pending-stopped and needs-attention to processing-stopped. But the renaming regularizes the names to give the impression that there are 3 high level states of pending, processing and completed and 4 additional variant of those states. These regularized states allow us to have other attributes that draw from these names, e.g. time-since-pending time-since-processing and time-since-completed. It also allows the addition of other states, such as completed-with-errors. Bob Herriot > From harryl@us.ibm.com Mon Jun 2 15:09:05 1997 > > I am confused by the notation used in this discussion: > > >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 > > I understand PENDING, PROCESSING and COMPLETED states. I thought I was > following a thread, somewhere, that PENDING-STOPPED was another way to say HELD > and PROCESSING-STOPPED was another way to say NEEDS ATTENTION. Is this what is > going on... just some renaming? Or do the "dashes" in these names indicate > separation between a state and a reason? > > I agree with Bob's recommendations, above, to stick with Completed rather than > Done. Why change? And, for that matter, why not keep HELD and NEEDS ATTENTION? > What are we gaining. I find these discussions frequently go down the "generic > language" path until the labels we choose are so vague that, rather than risk > misinterpretation, the names end up meaning very little at all. > > Harry Lewis > From ipp-archive Mon Jun 2 18:37:35 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA16806 for ipp-outgoing; Mon, 2 Jun 1997 18:35:39 -0400 (EDT) Date: Mon, 2 Jun 1997 18:35:54 -0400 (EDT) From: JK Martin Message-Id: <199706022235.SAA08058@uscore.underscore.com> To: Robert.Herriot@Eng.Sun.COM Subject: Re: JMP> Re: IPP> MOD JobState suggestion Cc: ipp@pwg.org, jmp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk I guess I'm a bit disappointed that we elected to not do the "elegant" thing and simply have 3 states (pending, processing, done), then use a set defined of substates to describe refinements of those states. A rare chance to do something that is both elegant *and* simple. (Sigh...) ...jay ----- Begin Included Message ----- >From ipp-owner@pwg.org Mon Jun 2 18:28 EDT 1997 Date: Mon, 2 Jun 1997 15:23:22 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) To: ipp@pwg.org, harryl@us.ibm.com Subject: Re: JMP> Re: IPP> MOD JobState suggestion Cc: jmp@pwg.org In one sense we have just renamed some states: held to pending-stopped and needs-attention to processing-stopped. But the renaming regularizes the names to give the impression that there are 3 high level states of pending, processing and completed and 4 additional variant of those states. These regularized states allow us to have other attributes that draw from these names, e.g. time-since-pending time-since-processing and time-since-completed. It also allows the addition of other states, such as completed-with-errors. Bob Herriot > From harryl@us.ibm.com Mon Jun 2 15:09:05 1997 > > I am confused by the notation used in this discussion: > > >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 > > I understand PENDING, PROCESSING and COMPLETED states. I thought I was > following a thread, somewhere, that PENDING-STOPPED was another way to say HELD > and PROCESSING-STOPPED was another way to say NEEDS ATTENTION. Is this what is > going on... just some renaming? Or do the "dashes" in these names indicate > separation between a state and a reason? > > I agree with Bob's recommendations, above, to stick with Completed rather than > Done. Why change? And, for that matter, why not keep HELD and NEEDS ATTENTION? > What are we gaining. I find these discussions frequently go down the "generic > language" path until the labels we choose are so vague that, rather than risk > misinterpretation, the names end up meaning very little at all. > > Harry Lewis > ----- End Included Message ----- From ipp-archive Mon Jun 2 19:32:33 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA17476 for ipp-outgoing; Mon, 2 Jun 1997 19:27:58 -0400 (EDT) Message-Id: <3.0.1.32.19970602162232.009bd480@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 2 Jun 1997 16:22:32 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Agenda for PWG IPP Phone Conference on June 4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Agenda for PWG IPP Phone Conference on June 4, 1 - 3:30 PST - Booking of meeting time in Munich (Carl-Uno) - Progress report from the MOD subgroup (Scott) - Progress report from the PRO subgroup (Bob) - Progress report from the SEC subgroup (Roger) - Discussion about issues with operations (there are a number of outstanding issues for which it is not clear which subgroup will resolve them) - Further discussion of the latest protocol draft (Randy) --- Call-in: 1-423-673-6712 Access: 190148 We can just pray and hope that it works better than last week.... ---- 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 Jun 2 20:22:34 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA18371 for ipp-outgoing; Mon, 2 Jun 1997 20:22:21 -0400 (EDT) Message-Id: <9706030022.AA01484@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, 2 Jun 1997 17:20:07 PDT To: ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: IPP> Re: "NEED NOT" is a better negative than "MAY NOT" - from POSIX [and capatalizing conformance words] Sender: ipp-owner@pwg.org Precedence: bulk Scott Bradner replied to my query, but I missed it, on NEED NOT and capitalizing the conformance words. Tom >Return-Path: >Date: Thu, 22 May 1997 04:27:22 PDT >From: Scott Bradner >To: hastings@cp10.es.xerox.com >Subject: Re: "NEED NOT" is a better negative than "MAY NOT" - from POSIX > >Tom, > "need not" would be a good addition. If this rfc comes >up for revision I will add that. > >> Also, are you recommending that we capitalize the words? > >there was quite a bit of argument on that. I think it helps the reader >quite a bit but some other people felt that we did not even >need the rfc since the words should mean what they mean. The compromise >was to just say that the "may" be capitalized. > >Scott > > From ipp-archive Mon Jun 2 21:12:40 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA19078 for ipp-outgoing; Mon, 2 Jun 1997 21:11:58 -0400 (EDT) Message-Id: <9706030111.AA01503@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, 2 Jun 1997 18:09:21 PDT To: Peter Zehler From: Tom Hastings Subject: RE: IPP> Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are Cc: "ipp@pwg.org" , "jmp@pwg.org" , Peter Zehler , JK Martin Sender: ipp-owner@pwg.org Precedence: bulk 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. Then such a printer shall implement the conditionally mandatory pending state. But an implementation that never waited a human perceptible time should not have to implement the 'pending' state. Imagine that you are building a product that is going to be tested against by a testing company. If 'pending' is mandatory and your product doesn't ever show 'pending', that testing company might say you didn't conform to the standard. >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. If we spend much more time discussing this issue, it may be wiser to take your suggestion and make 'pending' mandatory. >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 Tue Jun 3 09:52:42 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA21316 for ipp-outgoing; Tue, 3 Jun 1997 09:50:16 -0400 (EDT) Date: Tue, 3 Jun 1997 06:52:56 PDT From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9706031352.AA25087@snorkel.eso.mc.xerox.com> To: hastings@cp10.es.xerox.com, ipp@pwg.org, jmp@pwg.org Subject: IPP> Re: JMP> Re: "NEED NOT" is a better negative than "MAY NOT" - from POSIX [and capatalizing conformance words] Sender: ipp-owner@pwg.org Precedence: bulk Hi Tom, Note that the POSIX.2 usage of 'need not' as the inverse of 'may' is now ubiquitous in new ISO and IEEE communications standards. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc >From jmp-owner@pwg.org Mon Jun 2 20:30:46 1997 Return-Path: Received: from zombi.eso.mc.xerox.com by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA24966; Mon, 2 Jun 97 20:30:45 EDT Received: from alpha.xerox.com by zombi.eso.mc.xerox.com (4.1/SMI-4.1) id AA07689; Mon, 2 Jun 97 20:27:57 EDT Received: from lists.underscore.com ([199.125.85.30]) by alpha.xerox.com with SMTP id <14603(4)>; Mon, 2 Jun 1997 17:28:10 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA18480 for ; Mon, 2 Jun 1997 20:24:14 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 2 Jun 1997 20:22:53 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA18363 for jmp-outgoing; Mon, 2 Jun 1997 20:22:16 -0400 (EDT) Message-Id: <9706030022.AA01484@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, 2 Jun 1997 17:20:07 PDT To: ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: JMP> Re: "NEED NOT" is a better negative than "MAY NOT" - from POSIX [and capatalizing conformance words] Sender: jmp-owner@pwg.org Status: R Scott Bradner replied to my query, but I missed it, on NEED NOT and capitalizing the conformance words. Tom >Return-Path: >Date: Thu, 22 May 1997 04:27:22 PDT >From: Scott Bradner >To: hastings@cp10.es.xerox.com >Subject: Re: "NEED NOT" is a better negative than "MAY NOT" - from POSIX > >Tom, > "need not" would be a good addition. If this rfc comes >up for revision I will add that. > >> Also, are you recommending that we capitalize the words? > >there was quite a bit of argument on that. I think it helps the reader >quite a bit but some other people felt that we did not even >need the rfc since the words should mean what they mean. The compromise >was to just say that the "may" be capitalized. > >Scott > > From ipp-archive Tue Jun 3 12:42:45 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA24160 for ipp-outgoing; Tue, 3 Jun 1997 12:37:44 -0400 (EDT) Message-Id: <3.0.1.32.19970603093214.009a83e0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 3 Jun 1997 09:32:14 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC - Access Control: What's On The Wire Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Hi, I am forwarding this contribution from the WEBDAV group which apparently is struggling with some of the same security problems that we are. Carl-Uno > >This might just be a more direct way of saying what you are saying. > >I think you will find that the only way to specify that credentials should be sent without restricting the implementation to any particular method (X.509, kerberos...) is to define a "credential cookie" which the client sends to the server. > >Determining which form of credential to send (assuming the client has a choice) would require the client and/or the server to send a list of the supported credential "formats" in order of preference the one being used being the highest commonly supported format (credential handshake). > >This implies that the minimum that this WG is going to have to do is > >1) Decide which schemes we regard as candidates for credentials >2) Determine the extension to HTTP for the credential handshaking explicitly naming the identified credential schemes and such that it can be extended to support other schemes (similar to the MIME-type names) >3) Determine the extension to HTTP for the credential cookie transfer > >Cheers >Dylan > >---------- >From: Fisher Mark[SMTP:FisherM@exch1.indy.tce.com] >Sent: Mittwoch, 28. Mai 1997 22:39 >To: 'w3c-dist-auth' >Subject: Access Control: What's On The Wire > >The big question to me in WebDAV access control is, "What should go over >the wire?". I see 3 things that go from the client to server: > 1) An HTTP method; > 2) Credentials identifying the client; and > 3) One (or more) URIs identifying the resource. >The server then responds with a status code, along with a Reason-Phrase. > >Now, credentials can be several things. The simplest non-null case is a >single ID. If you are in a relatively high-trust situation (like inside >a company Intranet), merely tracking the author by ID may be sufficient. > Or, for somewhat greater security, a one-time ID (like a SecurID >without the PIN), may be adequate in some cases. UserID/passwords are >quite commonly used in multiuser OSes, while X509 certificates and >signed PGP messages both have their advocates. What goes over the wire >from the client to server, however, are HTTP-method + credentials + >URI(s). > >Since WebDAV is an extension for HTTP, any credential-sending mechanism >(authentication method) considered by this group should be via HTTP. >This is not to preclude other authentication methods (CORBA, Kerberos, >etc.) being used, it is just to say that non-HTTP methods are likely out >of this group's scope. This is also not to say that adding >authentication mechanisms to HTTP should not be considered, as work done >on additional authentication mechanisms would benefit Web users as a >whole. > >To make a long story short (too late! :( ), what WebDAV access control >needs to be concerned with are the HTTP authentication methods to >support, the HTTP methods needed for WebDAV, and the HTTP status >responses. Although there will be clients and servers that use DCE, >NTLM/CIFS, etc. for access control, since they are not using HTTP, IMHO >we should not be spending our time on this mailing list considering >these options. >========================================================== >Mark Leighton Fisher Thomson Consumer Electronics >fisherm@indy.tce.com Indianapolis, IN >"ViaCrypt? Vhy not!" > > > > 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 Jun 3 18:07:47 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA26527 for ipp-outgoing; Tue, 3 Jun 1997 18:05:51 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 03 Jun 1997 16:03:49 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - New model doc: draft-ietf-ipp-model-01.txt Sender: ipp-owner@pwg.org Precedence: bulk I have posted a new version of the model document. I have also sent a text version to the IETF as a new Internet-Draft. On the FTP server: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970603-60.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970603-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970603.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970603.txt ipp-model-970603-60.doc is a MS Word 6.0 compatible RTF file ipp-model-970603-rev.pdf has revision marks and line numbers ipp-model-970603.pdf has no revision marks and line numbers ipp-model-970603.txt is a text version (identical to draft-ietf-ipp-model-01.txt) I also posted: ftp://ftp.pwg.org/pub/pwg/ipp/drafts/draft-ietf-ipp-model-01.txt This is the document that I mailed to the IETF. Look for an announcement soon on the IETF mailing list. I have not done many the small clean up items that many have so helpfully given feedback on. I'll try to get to that soon. 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 Jun 4 08:57:58 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA00089 for ipp-outgoing; Wed, 4 Jun 1997 08:56:37 -0400 (EDT) Message-Id: <9706041256.AB02021@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, 4 Jun 1997 05:53:35 PDT To: ipp@pwg.org, jmp@pwg.org, Harry Lewis From: Tom Hastings Subject: Re: JMP> Re: IPP> MOD JobState suggestion Sender: ipp-owner@pwg.org Precedence: bulk At 15:07 06/02/97 PDT, Harry Lewis wrote: snip... >I understand PENDING, PROCESSING and COMPLETED states. I thought I was >following a thread, somewhere, that PENDING-STOPPED was another way to say HELD >and PROCESSING-STOPPED was another way to say NEEDS ATTENTION. Is this what is >going on... just some renaming? Or do the "dashes" in these names indicate >separation between a state and a reason? > >I agree with Bob's recommendations, above, to stick with Completed rather than >Done. Why change? And, for that matter, why not keep HELD and NEEDS ATTENTION? >What are we gaining. I find these discussions frequently go down the "generic >language" path until the labels we choose are so vague that, rather than risk >misinterpretation, the names end up meaning very little at all. > >Harry Lewis I agree with Harry that we should reconsider the name change from 'held' to 'pending-stopped' and go back to 'held'. In looking at the complete spec for job-state and job-state-reasons in IPP and the corresponding jmJobState and jmJobStateReason1 objects in JMP, I discovered a problem with our renaming of 'held' to 'pending-stopped': I've added the following joint IPP/JMP issue to the joint spec: JOINT IPP/JMP ISSUE - Should we go back to the name 'held', instead of 'pending-stopped'? The IPP protocol has a "job-hold-until", so having the name of the state be 'held' aligns with that name better making it clearer to the user the relationship between the attribute and the state. Also some current systems have a 'held' state, so that current practice for system that have such as state is to call that state 'held'. Also the ISO DPA has a 'held' state. Finally, our sub-classing in the names doesn't work for 'completed', since we have 'aborted' and 'canceled', not 'completed-aborted' and 'completed-canceled', so why have it for pending-stopped, which may prove fairly startling to a user, while 'held' is readily understandable. I think that 'processing-stopped' is fine and is clear that it is a sub-state of processing, so I'm not suggesting that we re-open the 'processing-stopped' name change. Comments? Tom From ipp-archive Wed Jun 4 08:58:02 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA00057 for ipp-outgoing; Wed, 4 Jun 1997 08:56:00 -0400 (EDT) Message-Id: <9706041255.AA02021@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, 4 Jun 1997 05:53:28 PDT To: ipp@pwg.org, jmp@pwg.org, JK Martin From: Tom Hastings Subject: Re: JMP> Re: IPP> MOD JobState suggestion Cc: Robert.Herriot@Eng.Sun.COM Sender: ipp-owner@pwg.org Precedence: bulk Gee Jay, You want to add another attribute to IPP: job-sub-state and another object to the JMP jmJobTable: jmJobSubState? This doesn't sound like simplicity and elegance to me. Instead, we've shown the "refinement" of these substates, in the names of the states and not added any more attributes or objects. That seems like the best of both worlds, namely show the refinement but keep the attributes and object simple. Or did you mean to add the sub-states as job-state-reasons which wouldn't add anymore attributes to IPP and objects to JMP? Tom At 15:35 06/02/97 PDT, JK Martin wrote: >I guess I'm a bit disappointed that we elected to not do the "elegant" >thing and simply have 3 states (pending, processing, done), then use >a set defined of substates to describe refinements of those states. > >A rare chance to do something that is both elegant *and* simple. >(Sigh...) > > ...jay > >----- Begin Included Message ----- > >>From ipp-owner@pwg.org Mon Jun 2 18:28 EDT 1997 >Date: Mon, 2 Jun 1997 15:23:22 -0700 >From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) >To: ipp@pwg.org, harryl@us.ibm.com >Subject: Re: JMP> Re: IPP> MOD JobState suggestion >Cc: jmp@pwg.org > >In one sense we have just renamed some states: held to pending-stopped >and needs-attention to processing-stopped. But the renaming regularizes >the names to give the impression that there are 3 high level states >of pending, processing and completed and 4 additional variant of those >states. These regularized states allow us to have other attributes >that draw from these names, e.g. time-since-pending time-since-processing >and time-since-completed. It also allows the addition of other states, >such as completed-with-errors. > > >Bob Herriot > > >> From harryl@us.ibm.com Mon Jun 2 15:09:05 1997 >> >> I am confused by the notation used in this discussion: >> >> >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 >> >> I understand PENDING, PROCESSING and COMPLETED states. I thought I was >> following a thread, somewhere, that PENDING-STOPPED was another way to say HELD >> and PROCESSING-STOPPED was another way to say NEEDS ATTENTION. Is this what is >> going on... just some renaming? Or do the "dashes" in these names indicate >> separation between a state and a reason? >> >> I agree with Bob's recommendations, above, to stick with Completed rather than >> Done. Why change? And, for that matter, why not keep HELD and NEEDS ATTENTION? >> What are we gaining. I find these discussions frequently go down the "generic >> language" path until the labels we choose are so vague that, rather than risk >> misinterpretation, the names end up meaning very little at all. >> >> Harry Lewis >> > > >----- End Included Message ----- > > > From ipp-archive Wed Jun 4 08:58:08 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA00073 for ipp-outgoing; Wed, 4 Jun 1997 08:56:17 -0400 (EDT) Message-Id: <9706041256.AB02021@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, 4 Jun 1997 05:53:39 PDT To: jmp@pwg.org, ipp@pwg.org From: Tom Hastings Subject: IPP> Updated IPP/JMP joint job-state/job-state-reasons specs for IPP telecon today 1:00 PM PDT (4:00 PM EDT) with a few issues Sender: ipp-owner@pwg.org Precedence: bulk JMP people, Pleae call-in today so we can finish the agreements on the IPP/JMP job-state and job-state-reasons attributes. June 4 ------ Call-in: 1-423-673-6712 Access: 190148 All calls are at 4PM EDT (1PM PDT) I've cross-posted (again) 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 89653 Jun 4 12:45 jobstate.pdf -rw-r--r-- 1 pwg pwg 42819 Jun 4 12:02 jobstate.txt -rw-r--r-- 1 pwg pwg 113152 Jun 4 12:03 jobstatr.doc -rw-r--r-- 1 pwg pwg 143298 Jun 4 12:47 jobstatr.pdf -rw-r--r-- 1 pwg pwg 148621 Jun 4 12:48 jobstatr.pdr ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 89653 Jun 4 12:45 jobstate.pdf -rw-r--r-- 1 pwg pwg 42819 Jun 4 12:02 jobstate.txt -rw-r--r-- 1 pwg pwg 113152 Jun 4 12:03 jobstatr.doc -rw-r--r-- 1 pwg pwg 143298 Jun 4 12:47 jobstatr.pdf -rw-r--r-- 1 pwg pwg 148621 Jun 4 12:48 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 28. There is an IPP issue listed below and in the document which Carl-Uno said we could handle on the IPP telecon, tommorrow, Wed, June 4, 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: Thanks, Tom In the JMP jmJobState and jmJobStateReasons1 spec I added explicity conditions for each CONDITIONALLY MANDATORY job state and job state reason. Please read and see if this helps the discussion that JMP has been having around what MANDATORY and CONDITIONALLY MANDATORY means for SNMP agent conformance. Tom Subject: IPP and JMP agreements on job-state and job-state-reasons From: Tom Hastings Date: 5/30/97 File: jobstatr.doc (with revision marks) jobstate.doc (without revisions) This document is the updated IPP "job-state" and "job-state-reasons" attributes and the corresponding JMP jmJobState and jmJobStateReasons1 objects from the IPP telecon, of Wednesday, May 27. There we agreed to having 7 states in common between IPP and JMP: pending, pending-stopped, processing, processing-stopped, canceled, aborted, and completed. The JMP values of the jmJobStateReasons1 object are a superset of the IPP values of the "job-state-reasons" attribute. I've applied revision marks to the specification of 5/25/97 to show the changes, both to the commentary and the specification. There are three joint IPP/JMP issues and one JMP-only issue listed below. 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.) JOINT IPP/JMP ISSUE - Should we go back to the name 'held', instead of 'pending-stopped'? The IPP protocol has a "job-hold-until", so having the name of the state be 'held' aligns with that name better making it clearer to the user the relationship between the attribute and the state. Also some current systems have a 'held' state, so that current practice for system that have such as state is to call that state 'held'. Also the ISO DPA has a 'held' state. Finally, our sub-classing in the names doesn't work for 'completed', since we have 'aborted' and 'canceled', not 'completed-aborted' and 'completed-canceled', so why have it for pending-stopped, which may prove fairly startling to a user, while 'held' is readily understandable. Joint IPP/JMP ISSUE - Should in-coming and out-going jobs be in 'pending' or 'processing' states? In the IPP 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'. In the "job-state" definition, 'job-outgoing' is in the 'processing' state, while the "job-state-reasons" definition says that 'job-outgoing' shall be in the 'pending' state. Which do we want the IPP and JMP spec to say? Joint IPP/JMP ISSUE: Should 'completed-with-warnings' and 'completed-with-errors' be mandatory job-state-reasons values or not? Currently both IPP and JMP specs say they are mandatory reasons. JMP ISSUE - which JmJobStateReasons1TC values are MANDATORY? If none are, the jmJobStateReasons1 object could go back to the jmAttributeTable. 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 'printing' state. 2. Rename the JMP 'held' state to 'pending-stopped' and rename the JMP state 'needsAttention' to 'processingStopped'. 3. In both IPP and JMP add the 'aborted' state and make it a final state. 4. In both IPP and JMP remove the 'aborted-by-system' job-state-reason, since the new 'aborted' state says it all. 5. 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. 6. Since the pending-stopped state has been added, JMP no longer needs a generic jobHeld job state reason. So the simplified state transition diagram for IPP and JMP was agreed to be: 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. From ipp-archive Wed Jun 4 10:07:57 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA02078 for ipp-outgoing; Wed, 4 Jun 1997 10:07:22 -0400 (EDT) From: Harry Lewis To: Cc: , Subject: Re: JMP> Re: IPP> MOD JobState suggestion Message-Id: <5030100003117793000002L032*@MHS> Date: Wed, 4 Jun 1997 10:09:15 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Tom, I support your proposal - >JOINT IPP/JMP ISSUE - Should we go back to the name 'held', instead of >'pending-stopped'? Not only for the many good reasons you listed but simply due to the reduced brain-strain. HELD... I can relate to. But what exactly happens when pending stops? It's obvious, by most of my notes, that I'm not much of a comedian, but I can picture one having fun with some of these genericized brain teasers. >I think that 'processing-stopped' is fine and is clear that it is a >sub-state of processing, so I'm not suggesting that we re-open the >'processing-stopped' name change. I guess processing-stopped is about as clear as needs-attention (I think this was the old name in JMP). No big problem with the name. I'm not sure I really understand your use of the term "sub-state", however. Are you referring to a JobStateReason or are you thinking of a job transition diagram? I THINK you are talking about job transition flow and processing-stopped is really a STATE, not a REASON. I don't think stopped is a very good reason to be processing. Harry From ipp-archive Wed Jun 4 12:28:06 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA02971 for ipp-outgoing; Wed, 4 Jun 1997 12:23:55 -0400 (EDT) Message-Id: <9706041623.AA02114@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" X-Priority: 1 (Highest) Date: Wed, 4 Jun 1997 09:20:56 PDT To: jmp@pwg.org, ipp@pwg.org From: Tom Hastings Subject: IPP> URGENT: JMP/IPP job-state/job-state-reasons: 1:00-1:15 PDT (4:00 PM EDT) on IPP telecon today, 6/4 Sender: ipp-owner@pwg.org Precedence: bulk Carl-Uno said we could have 15 minutes on the joint IPP/JMP job-state and job-state-reasons issues (see attached). JMP people, please call in, so we can put these issues to bed for both IPP and JMP. (NOTE - the entire document is NOT included in the e-mail. You should fetch at least the .pdf file without revison marks (jobstate.pdf) from the ftp server). Thanks, Tom >Date: Wed, 04 Jun 1997 05:53:39 -0700 >To: jmp, ipp >From: Tom Hastings >Subject: Updated IPP/JMP joint job-state/job-state-reasons specs for IPP telecon today 1:00 PM PDT (4:00 PM EDT) with a few issues > >JMP people, > >Pleae call-in today so we can finish the agreements on the IPP/JMP >job-state and job-state-reasons attributes. > >June 4 >------ >Call-in: 1-423-673-6712 >Access: 190148 > >All calls are at 4PM EDT (1PM PDT) > >I've cross-posted (again) 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 89653 Jun 4 12:45 jobstate.pdf >-rw-r--r-- 1 pwg pwg 42819 Jun 4 12:02 jobstate.txt >-rw-r--r-- 1 pwg pwg 113152 Jun 4 12:03 jobstatr.doc >-rw-r--r-- 1 pwg pwg 143298 Jun 4 12:47 jobstatr.pdf >-rw-r--r-- 1 pwg pwg 148621 Jun 4 12:48 jobstatr.pdr > >ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ >-rw-r--r-- 1 pwg pwg 89653 Jun 4 12:45 jobstate.pdf >-rw-r--r-- 1 pwg pwg 42819 Jun 4 12:02 jobstate.txt >-rw-r--r-- 1 pwg pwg 113152 Jun 4 12:03 jobstatr.doc >-rw-r--r-- 1 pwg pwg 143298 Jun 4 12:47 jobstatr.pdf >-rw-r--r-- 1 pwg pwg 148621 Jun 4 12:48 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 28. There is an IPP issue listed below and in the document >which Carl-Uno said we could handle on the IPP telecon, tommorrow, >Wed, June 4, 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: > >Thanks, >Tom > > >In the JMP jmJobState and jmJobStateReasons1 spec I added explicity conditions >for each CONDITIONALLY MANDATORY job state and job state reason. Please read >and see if this helps the discussion that JMP has been having around what >MANDATORY and CONDITIONALLY MANDATORY means for SNMP agent conformance. > >Tom > > >Subject: IPP and JMP agreements on job-state and job-state-reasons >From: Tom Hastings >Date: 5/30/97 >File: jobstatr.doc (with revision marks) jobstate.doc (without revisions) > >This document is the updated IPP "job-state" and "job-state-reasons" attributes and the corresponding JMP jmJobState and jmJobStateReasons1 objects >from the IPP telecon, of Wednesday, May 27. There we agreed to having 7 states in common between IPP and JMP: pending, pending-stopped, processing, processing-stopped, canceled, aborted, and completed. The JMP values of the jmJobStateReasons1 object are a superset of the IPP values of the "job-state-reasons" attribute. > >I've applied revision marks to the specification of 5/25/97 to show the changes, both to the commentary and the specification. > >There are three joint IPP/JMP issues and one JMP-only issue listed below. > >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.) > > > >JOINT IPP/JMP ISSUE - Should we go back to the name 'held', instead of 'pending-stopped'? > >The IPP protocol has a "job-hold-until", so having the name of the state be 'held' aligns with that name better making it clearer to the user the relationship between the attribute and the state. Also some current systems have a 'held' state, so that current practice for system that have such as state is to call that state 'held'. Also the ISO DPA has a 'held' state. >Finally, our sub-classing in the names doesn't work for 'completed', since we have 'aborted' and 'canceled', not 'completed-aborted' and 'completed-canceled', so why have it for pending-stopped, which may prove fairly startling to a user, while 'held' is readily understandable. > > > >Joint IPP/JMP ISSUE - Should in-coming and out-going jobs be in 'pending' or > 'processing' states? > >In the IPP 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'. >In the "job-state" definition, 'job-outgoing' is in the 'processing' state, >while the "job-state-reasons" definition says that 'job-outgoing' shall be in >the 'pending' state. Which do we want the IPP and JMP spec to say? > > > >Joint IPP/JMP ISSUE: Should 'completed-with-warnings' and 'completed-with-errors' be mandatory job-state-reasons values or not? > >Currently both IPP and JMP specs say they are mandatory reasons. > > > > >JMP ISSUE - which JmJobStateReasons1TC values are MANDATORY? >If none are, the jmJobStateReasons1 object could go back to the jmAttributeTable. > > > > 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 'printing' state. > >2. Rename the JMP 'held' state to 'pending-stopped' and rename the JMP state 'needsAttention' to 'processingStopped'. > >3. In both IPP and JMP add the 'aborted' state and make it a final state. > >4. In both IPP and JMP remove the 'aborted-by-system' job-state-reason, >since the new 'aborted' state says it all. > >5. 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. > >6. Since the pending-stopped state has been added, JMP no longer needs a generic jobHeld job state reason. > > >So the simplified state transition diagram for IPP and JMP was agreed to be: > >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. > > From ipp-archive Wed Jun 4 12:38:03 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA03617 for ipp-outgoing; Wed, 4 Jun 1997 12:37:40 -0400 (EDT) Message-Id: <9706041637.AA02128@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, 4 Jun 1997 09:34:42 PDT To: ipp@pwg.org, jmp@pwg.org, Harry Lewis From: Tom Hastings Subject: Re: JMP> Re: IPP> MOD JobState suggestion Sender: ipp-owner@pwg.org Precedence: bulk At 07:09 06/04/97 PDT, Harry Lewis wrote: >Tom, I support your proposal - > >>JOINT IPP/JMP ISSUE - Should we go back to the name 'held', instead of >>'pending-stopped'? > >Not only for the many good reasons you listed but simply due to the reduced >brain-strain. HELD... I can relate to. But what exactly happens when pending >stops? It's obvious, by most of my notes, that I'm not much of a comedian, but >I can picture one having fun with some of these genericized brain teasers. > >>I think that 'processing-stopped' is fine and is clear that it is a >>sub-state of processing, so I'm not suggesting that we re-open the >>'processing-stopped' name change. > >I guess processing-stopped is about as clear as needs-attention (I think >this was the old name in JMP). No big problem with the name. I'm not sure >I really understand your use of the term "sub-state", however. Are you >referring to a JobStateReason or are you thinking of a job transition >diagram? I THINK you are talking about job transition flow and >processing-stopped is really a STATE, not a REASON. I don't think stopped is >a very good reason to be processing. I definitely meant that the 'processing-stopped' state is a separate state that a job gets to from the 'processing' and returns to 'processing' state. Here's the picture in the joint IPP/JMP jobstate.pdf file that I posted for today's IPP telecon: The following JMP figure shows the normal job state transitions: +--> canceled(7) / +---> pending(3) -------> processing(5) --+----> aborted(8) | ^ ^ \ --->+ | | +--> completed(9) | v v +---> pending-stopped(4) processing-stopped(6) <------------- active ------------>|<-- in-active -->| Figure 3 - Normal job state transitions Normally a job progresses only from left to right. Other state transitions are unlikely, but are not forbidden." Changing the name from 'pending-stopped' to 'held' would yield: The following figure shows the normal job state transitions: +--> canceled(7) / +---> pending(3) -------> processing(5) --+----> aborted(8) | ^ ^ \ --->+ | | +--> completed(9) | v v +---> held(4) processing-stopped(6) <-------------- active ------------>|<-- in-active -->| Figure 3 - Normal job state transitions Normally a job progresses only from left to right. Other state transitions are unlikely, but are not forbidden." > >Harry > > From ipp-archive Wed Jun 4 13:13:00 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA04287 for ipp-outgoing; Wed, 4 Jun 1997 13:08:34 -0400 (EDT) Message-Id: <01BC70D7.97504130@hpb19043.boi.hp.com> From: Stephen Holmstead To: "'ipp@pwg.org'" Subject: RE: IPP>PRO - Print by reference Date: Wed, 4 Jun 1997 11:00:26 -0600 Encoding: 22 TEXT Sender: ipp-owner@pwg.org Precedence: bulk Print by reference is REALLY tough for the printer to do. Up until this point, the printer only had to do http server capabilities (which can be implemented fairly easily). However, print by reference now would require the printer to implement http client capabilities (which is HUGE!!, not to mention how unstable the client features are and the fact that the printer most likely won't ever have a flash upgrade). What about all of the embedded graphics files (gif, jpeg, pcx, tiff, etc.)? Does the printer have to have code to convert all of these to printable output? What about other files (.doc, .prz, .ppt, .xls, .mov, .avi, .pdf, etc.)? Does the printer have to have code to handle all of these? What about plug-ins and applets? Does the printer have to have a Java Virtual Machine to run Java applets? The client (i.e. Browser) is quite large and has too many features to be able to support by a printer. I have to strongly protest print by reference as it causes the requirement load on the printer to skyrocket. -- Stephen Holmstead Hewlett Packard Internet Solutions Operation stephen_holmstead@hp.com From ipp-archive Wed Jun 4 14:13:02 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA05007 for ipp-outgoing; Wed, 4 Jun 1997 14:08:42 -0400 (EDT) Date: Wed, 4 Jun 1997 14:09:04 -0400 (EDT) From: JK Martin Message-Id: <199706041809.OAA05226@uscore.underscore.com> To: ipp@pwg.org, jmp@pwg.org Subject: IPP> Re: JMP> URGENT: JMP/IPP job-state/job-state-reasons: 1:00-1:15 PDT (4:00 PM EDT) on IPP telecon today, 6/4 X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk > Carl-Uno said we could have 15 minutes on the joint IPP/JMP job-state > and job-state-reasons issues (see attached). > > JMP people, please call in, so we can put these issues to bed for both > IPP and JMP. Yeah, 15 minutes ought to do it. Particularly when some folks have taken to time to post a big bunch of messages today on this topic. ;-) > (NOTE - the entire document is NOT included in the e-mail. You should > fetch at least the .pdf file without revison marks (jobstate.pdf) from the > ftp server). This document is faulty, as is jobstatr.pdf. Tom has been notified. ...jay From ipp-archive Wed Jun 4 14:18:09 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA05467 for ipp-outgoing; Wed, 4 Jun 1997 14:16:59 -0400 (EDT) Date: Wed, 4 Jun 1997 14:13:30 -0400 (EDT) From: JK Martin Message-Id: <199706041813.OAA05423@uscore.underscore.com> To: hastings@cp10.es.xerox.com Subject: Re: JMP> Re: IPP> MOD JobState suggestion Cc: ipp@pwg.org, jmp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk [I hope this cross-posting ends soon... :-{ ] Tom, Regarding your latest-greatest state transition map: > The following figure shows the normal job state transitions: > > +--> canceled(7) > / > +---> pending(3) -------> processing(5) --+----> aborted(8) > | ^ ^ \ > --->+ | | +--> completed(9) > | v v > +---> held(4) processing-stopped(6) > > <-------------- active ------------>|<-- in-active -->| > > Figure 3 - Normal job state transitions > > Normally a job progresses only from left to right. Other state transitions > are unlikely, but are not forbidden." Are you really sure this diagram is accurate? Say, for example, a job is in the "held" state. An operator or user then cancels the job. According to your diagram, the job transits would then manner: held -> pending pending -> processing processing -> canceled The same kind of mess occurs with the "processing-stopped" state, etc. This certainly must not be what you intend, right? ...jay From ipp-archive Wed Jun 4 14:38:00 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA06310 for ipp-outgoing; Wed, 4 Jun 1997 14:35:16 -0400 (EDT) Message-Id: <3.0.1.32.19970604112622.00910100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 4 Jun 1997 11:26:22 PDT To: Stephen Holmstead , "'ipp@pwg.org'" From: Carl-Uno Manros Subject: RE: IPP>PRO - Print by reference In-Reply-To: <01BC70D7.97504130@hpb19043.boi.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk At 10:00 AM 6/4/97 PDT, Stephen Holmstead wrote: >Print by reference is REALLY tough for the printer to do. Up until this >point, the printer only had to do http server capabilities (which can be >implemented fairly easily). However, print by reference now would require >the printer to implement http client capabilities (which is HUGE!!, not to >mention how unstable the client features are and the fact that the printer >most likely won't ever have a flash upgrade). What about all of the >embedded graphics files (gif, jpeg, pcx, tiff, etc.)? Does the printer >have to have code to convert all of these to printable output? What about >other files (.doc, .prz, .ppt, .xls, .mov, .avi, .pdf, etc.)? Does the >printer have to have code to handle all of these? What about plug-ins and >applets? Does the printer have to have a Java Virtual Machine to run Java >applets? The client (i.e. Browser) is quite large and has too many >features to be able to support by a printer. > >I have to strongly protest print by reference as it causes the requirement >load on the printer to skyrocket. >-- >Stephen Holmstead >Hewlett Packard Internet Solutions Operation >stephen_holmstead@hp.com > Stephen, an assumed restriction in the use of print-by-reference is that it would initially only support the retrieval of documents in print ready formats, such as Postscript or other PDL. Also, like most other features in IPP, a particular printer does not have to support this functionality. However, there is an increasing demand for this feature, (for example in print on demand scenarios) so we certainly want to keep the option in the specification, for people who may want to implement it. The most likely protocol for the actual retrieval is more likely to be FTP rather than HTTP, but we do not see a good reason to put any restrictions in the standard for this. Does this help you? 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 Jun 4 14:43:06 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA06456 for ipp-outgoing; Wed, 4 Jun 1997 14:40:49 -0400 (EDT) Message-Id: <9706041838.AA02229@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, 4 Jun 1997 11:35:58 PDT To: jmp@pwg.org, ipp@pwg.org From: Tom Hastings Subject: IPP> Re: JMP> Updated IPP/JMP joint job-state/job-state-reasons specs for IPP telecon today 1:00 PM PDT (4:00 PM EDT) with a few issues Sender: ipp-owner@pwg.org Precedence: bulk The .pdf files are now fixed in the jmp/contribution/ They had been truncated: ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 89653 Jun 4 18:33 jobstate.pdf -rw-r--r-- 1 pwg pwg 42819 Jun 4 12:29 jobstate.txt -rw-r--r-- 1 pwg pwg 113132 Jun 4 12:30 jobstatr.doc -rw-r--r-- 1 pwg pwg 143298 Jun 4 18:33 jobstatr.pdf -rw-r--r-- 1 pwg pwg 148621 Jun 4 18:33 jobstatr.pdr The ones in ftp::/ftp.pwg.org/pub/pwg/ipp/new_MOD/ were ok as posted Sorry for the problems. Tom >Return-Path: >Date: Wed, 4 Jun 1997 11:04:50 PDT >From: JK Martin >To: hastings@cp10.es.xerox.com >Subject: Re: JMP> Updated IPP/JMP joint job-state/job-state-reasons specs for > IPP telecon today 1:00 PM PDT (4:00 PM EDT) with a few issues >X-Sun-Charset: US-ASCII > >Tom, > >You've got some problems with a couple of your uploaded files: > > jobstate.pdf -- Is empty > jobstatr.pdf -- Is either truncated or otherwise is bad for Acrobat > > ...jay > >----- Begin Included Message ----- > >>From jmp-owner@pwg.org Wed Jun 4 09:00 EDT 1997 >Date: Wed, 4 Jun 1997 05:53:39 PDT >To: jmp@pwg.org, ipp@pwg.org >From: Tom Hastings >Subject: JMP> Updated IPP/JMP joint job-state/job-state-reasons specs for > IPP telecon today 1:00 PM PDT (4:00 PM EDT) with a few issues > >JMP people, > >Pleae call-in today so we can finish the agreements on the IPP/JMP >job-state and job-state-reasons attributes. > >June 4 >------ >Call-in: 1-423-673-6712 >Access: 190148 > >All calls are at 4PM EDT (1PM PDT) > >I've cross-posted (again) 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 89653 Jun 4 12:45 jobstate.pdf >-rw-r--r-- 1 pwg pwg 42819 Jun 4 12:02 jobstate.txt >-rw-r--r-- 1 pwg pwg 113152 Jun 4 12:03 jobstatr.doc >-rw-r--r-- 1 pwg pwg 143298 Jun 4 12:47 jobstatr.pdf >-rw-r--r-- 1 pwg pwg 148621 Jun 4 12:48 jobstatr.pdr > >ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ >-rw-r--r-- 1 pwg pwg 89653 Jun 4 12:45 jobstate.pdf >-rw-r--r-- 1 pwg pwg 42819 Jun 4 12:02 jobstate.txt >-rw-r--r-- 1 pwg pwg 113152 Jun 4 12:03 jobstatr.doc >-rw-r--r-- 1 pwg pwg 143298 Jun 4 12:47 jobstatr.pdf >-rw-r--r-- 1 pwg pwg 148621 Jun 4 12:48 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 28. There is an IPP issue listed below and in the document >which Carl-Uno said we could handle on the IPP telecon, tommorrow, >Wed, June 4, 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: > >Thanks, >Tom > > >In the JMP jmJobState and jmJobStateReasons1 spec I added explicity conditions >for each CONDITIONALLY MANDATORY job state and job state reason. Please read >and see if this helps the discussion that JMP has been having around what >MANDATORY and CONDITIONALLY MANDATORY means for SNMP agent conformance. > >Tom > > >Subject: IPP and JMP agreements on job-state and job-state-reasons >From: Tom Hastings >Date: 5/30/97 >File: jobstatr.doc (with revision marks) jobstate.doc (without revisions) > >This document is the updated IPP "job-state" and "job-state-reasons" >attributes and the corresponding JMP jmJobState and jmJobStateReasons1 objects >from the IPP telecon, of Wednesday, May 27. There we agreed to having 7 >states in common between IPP and JMP: pending, pending-stopped, processing, >processing-stopped, canceled, aborted, and completed. The JMP values of the >jmJobStateReasons1 object are a superset of the IPP values of the >"job-state-reasons" attribute. > >I've applied revision marks to the specification of 5/25/97 to show the >changes, both to the commentary and the specification. > >There are three joint IPP/JMP issues and one JMP-only issue listed below. > >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.) > > > >JOINT IPP/JMP ISSUE - Should we go back to the name 'held', instead of >'pending-stopped'? > >The IPP protocol has a "job-hold-until", so having the name of the state be >'held' aligns with that name better making it clearer to the user the >relationship between the attribute and the state. Also some current systems >have a 'held' state, so that current practice for system that have such as >state is to call that state 'held'. Also the ISO DPA has a 'held' state. >Finally, our sub-classing in the names doesn't work for 'completed', since >we have 'aborted' and 'canceled', not 'completed-aborted' and >'completed-canceled', so why have it for pending-stopped, which may prove >fairly startling to a user, while 'held' is readily understandable. > > > >Joint IPP/JMP ISSUE - Should in-coming and out-going jobs be in 'pending' or > 'processing' states? > >In the IPP 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'. >In the "job-state" definition, 'job-outgoing' is in the 'processing' state, >while the "job-state-reasons" definition says that 'job-outgoing' shall be in >the 'pending' state. Which do we want the IPP and JMP spec to say? > > > >Joint IPP/JMP ISSUE: Should 'completed-with-warnings' and >'completed-with-errors' be mandatory job-state-reasons values or not? > >Currently both IPP and JMP specs say they are mandatory reasons. > > > > >JMP ISSUE - which JmJobStateReasons1TC values are MANDATORY? >If none are, the jmJobStateReasons1 object could go back to the >jmAttributeTable. > > > > 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 'printing' state. > >2. Rename the JMP 'held' state to 'pending-stopped' and rename the JMP state >'needsAttention' to 'processingStopped'. > >3. In both IPP and JMP add the 'aborted' state and make it a final state. > >4. In both IPP and JMP remove the 'aborted-by-system' job-state-reason, >since the new 'aborted' state says it all. > >5. 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. > >6. Since the pending-stopped state has been added, JMP no longer needs a >generic jobHeld job state reason. > > >So the simplified state transition diagram for IPP and JMP was agreed to be: > >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. > > > > >----- End Included Message ----- > > > > From ipp-archive Wed Jun 4 14:59:56 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA06997 for ipp-outgoing; Wed, 4 Jun 1997 14:49:08 -0400 (EDT) Date: Wed, 4 Jun 1997 14:49:20 -0400 (EDT) From: JK Martin Message-Id: <199706041849.OAA07037@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 Stephen Holmstead submitted a fine posting on the pragmatic insights as to why "Print by Reference" is so tough for embedded IPP servers, such as network printers. (See attached message.) I think his posting should cause the IPP project to stop for second and consider exactly which set of solutions we're trying to solve NOW versus the set of all known problems in the universe. The IPP project now faces this situation: 1) Assumption: Print-by-Reference is a highly desirable feature. 2) Printer vendors declare that Print-by-Reference is too difficult or otherwise costly to implement in low-cost embedded devices. Some folks seem to think the obvious conclusion is: Therefore, remove Print-by-Reference as a base requirement. Am I the only person in the IPP world who has a hard time with this conclusion? Or is this one of the not-so-subtle differences between the two conformance levels of "IPP Level 1" and "IPP Level 2"? Or is the base assumption of "Print-by-Reference is a Good Thing" an invalid assumption? I agree with Microsoft's stated belief that print services are best provided by a front-end (host-based) server that "feeds" the printer in a manner consistent with local policy (whatever that may be). The continued drive by printer vendors to be "everything to everyone" will continue to drive DOWN the set of base capabilities for new network printing standards. We will continue to beat our heads against the wall trying to make such standards scale from Enterprise-strength down to simple peer-level printing at the consumer level. If we are unable (or unwilling) to develop parallel sets of standards that deal with scalability in a sane manner (which is very tough and ugly, I'll admit), then why can't we focus on a "top-down" approach that first addresses the Enterprise, then move on to a more consumer- oriented (peer-level) standard? While many folks in the IPP won't admit it, they are very focused on using IPP as the vehicle for the pay-for-print Copy Shop solution. These folks often cite that consumer-level clients will want to take advantage of Copy Shop services via IPP...and this may be very true. However, there is a tremendous difference between consumer-side clients and consumer-side IPP servers. Based on Stephen's posting, it's fair to say that low-end printers fall into the camp of consumer-side IPP servers. The question is, will the typical Copy Shop employ consumer-side IPP servers, or will they more likely use higher-level Enterprise-side IPP servers? My money (pun intended) is on the Enterprise-side for this particular scenario. Enterprise customers, on the other hand, are quickly moving their backbone printing services away from peer-to-peer printing to server-based printing to better manage their printer assets. That is, there is no desire for clients to print directly to the network printer; hence, the need for the printer to perform IPP services in this scenario is also quite weak. I agree with Roger deBry that Print-by-Reference should be a base capability for IPP. I also believe that we are headed for a trip through Interoperability Hell if we continue along the track of supporting multiple levels of IPP conformance, and that we should only focus on a single conformance level at this time. Anyone out there with an opinion on this situation? ...jay PS: Print-by-Reference is not the only instance of this "High-vs-Low" struggle. Similar situations have been repeatedly arisen in the Job Monitoring (JMP) and Printer MIB/MIF (PMP) projects over the course of the last four years. ---------------------------------------------------------------------- -- 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 Jun 4 13:14 EDT 1997 From: Stephen Holmstead To: "'ipp@pwg.org'" Subject: RE: IPP>PRO - Print by reference Date: Wed, 4 Jun 1997 11:00:26 -0600 Encoding: 22 TEXT Print by reference is REALLY tough for the printer to do. Up until this point, the printer only had to do http server capabilities (which can be implemented fairly easily). However, print by reference now would require the printer to implement http client capabilities (which is HUGE!!, not to mention how unstable the client features are and the fact that the printer most likely won't ever have a flash upgrade). What about all of the embedded graphics files (gif, jpeg, pcx, tiff, etc.)? Does the printer have to have code to convert all of these to printable output? What about other files (.doc, .prz, .ppt, .xls, .mov, .avi, .pdf, etc.)? Does the printer have to have code to handle all of these? What about plug-ins and applets? Does the printer have to have a Java Virtual Machine to run Java applets? The client (i.e. Browser) is quite large and has too many features to be able to support by a printer. I have to strongly protest print by reference as it causes the requirement load on the printer to skyrocket. -- Stephen Holmstead Hewlett Packard Internet Solutions Operation stephen_holmstead@hp.com ----- End Included Message ----- From ipp-archive Wed Jun 4 15:02:17 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA07299 for ipp-outgoing; Wed, 4 Jun 1997 14:53:23 -0400 (EDT) Date: Wed, 04 Jun 97 10:37:13 PDT From: "gregory leclair" Message-Id: <9705048654.AA865450278@erc.epson.com> To: ipp@pwg.org, Stephen Holmstead Subject: Re[2]: IPP>PRO - Print by reference Sender: ipp-owner@pwg.org Precedence: bulk IMHO, I think the Print by reference requirement should stay in IPP. The client capabilities are defined by the implementation. An example is the difference in capabilities between browsers, say Lynx (text) vs Navigator or Explorer. A simple printer can define its capabilities and make those known. ------------------------ Greg LeClair EPSON Imaging Technology Center greg@erc.epson.com ______________________________ Reply Separator _________________________________ Subject: RE: IPP>PRO - Print by reference Author: Stephen Holmstead at Internet Date: 6/4/97 10:20 AM Print by reference is REALLY tough for the printer to do. Up until this point, the printer only had to do http server capabilities (which can be implemented fairly easily). However, print by reference now would require the printer to implement http client capabilities (which is HUGE!!, not to mention how unstable the client features are and the fact that the printer most likely won't ever have a flash upgrade). What about all of the embedded graphics files (gif, jpeg, pcx, tiff, etc.)? Does the printer have to have code to convert all of these to printable output? What about other files (.doc, .prz, .ppt, .xls, .mov, .avi, .pdf, etc.)? Does the printer have to have code to handle all of these? What about plug-ins and applets? Does the printer have to have a Java Virtual Machine to run Java applets? The client (i.e. Browser) is quite large and has too many features to be able to support by a printer. I have to strongly protest print by reference as it causes the requirement load on the printer to skyrocket. -- Stephen Holmstead Hewlett Packard Internet Solutions Operation stephen_holmstead@hp.com From ipp-archive Wed Jun 4 15:03:04 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA07493 for ipp-outgoing; Wed, 4 Jun 1997 14:58:51 -0400 (EDT) Message-ID: <3395BB63.4538@powerpage.com> Date: Wed, 04 Jun 1997 15:01:26 -0400 From: "Michael E. Gaines" Reply-To: starman@powerpage.com Organization: Pipeline Assoc., Inc. X-Mailer: Mozilla 3.01Gold (Macintosh; I; PPC) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP>PRO - Print by reference References: <3.0.1.32.19970604112622.00910100@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk > At 10:00 AM 6/4/97 PDT, Stephen Holmstead wrote: >However, print by reference now would require >the printer to implement http client capabilities (which is HUGE!!, >not to mention how unstable the client features are and the fact that >the printer most likely won't ever have a flash upgrade). Why not? If the flash upgrade is kept to a DIFF-type of upgrade, it could work just fine. >What about all of the embedded graphics files (gif, jpeg, pcx, tiff, >etc.)? Does the printer have to have code to convert all of these to >printable output? Absolutely! Having these interpreters in the printer is required if the printer is expected to print HTML pages. Some of the lesser known image types can be avoided. I don't think there are too many documents out there with Atari ST Degas pictures on them :). >What about other files (.doc, .prz, .ppt, .xls, .mov, .avi, .pdf, >etc.)? Does the printer have to have code to handle all of these? Not unless you can watch movies on a piece of paper :) Seriously, there are some data types that shouldn't HAVE to be printed. That's the whole point of a PDF file (which should be handled). >What about plug-ins and applets? Does the printer have to have a Java >Virtual Machine to run Java applets? I'm still waiting for something to show that Java is nothing more than hype at this point anyway. >I have to strongly protest print by reference as it causes the >requirement load on the printer to skyrocket. I can't disagree with you there, but it's an unfortunate requirement at this point. What SHOULD happen is a common data model...but we all know what kind of a pipe dream that is. If IPP takes off, then I believe responsible web masters will place data on pages in a format that will be suited for IPP devices and all will be well. Mike Gaines Internet Imaging Manager Pipeline Assoc. Inc. starman@powerpage.com From ipp-archive Wed Jun 4 15:18:14 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA09021 for ipp-outgoing; Wed, 4 Jun 1997 15:16:11 -0400 (EDT) Date: Wed, 4 Jun 1997 15:12:40 -0400 (EDT) From: JK Martin Message-Id: <199706041912.PAA08117@uscore.underscore.com> To: hastings@cp10.es.xerox.com Subject: Re: JMP> Re: IPP> MOD JobState suggestion Cc: ipp@pwg.org, jmp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Tom, > Gee Jay, > > You want to add another attribute to IPP: job-sub-state > and another object to the JMP jmJobTable: jmJobSubState? > > This doesn't sound like simplicity and elegance to me. > > Instead, we've shown the "refinement" of these substates, in the > names of the states and not added any more attributes or objects. > > That seems like the best of both worlds, namely show the refinement > but keep the attributes and object simple. Someday, once the dust finally settles on the JMP and IPP projects, I'd be really interested in hearing your definitions and metrics relating to "simplicity" and "elegance". Unfortunately, the combined JMP/IPP dust is now swirling around at around 50,000 feet...and is unlikely to settle soon. ;-) > Or did you mean to add the sub-states as job-state-reasons which > wouldn't add anymore attributes to IPP and objects to JMP? Yes, Tom, this is the only natural conclusion here. Better yet, no need to wait until the dust settles to do this. ;-) The really sad situation here is that some folks want to model the job problem/solution to achieve an extremely teenie-weenie minor performance boost. That is, to only get a single MIB object instead of two (either of which can be done by a single SNMP Get message). Sorry, but perhaps the "puritan" nature of my engineering side has surfaced on this topic, and hence my resistance to this kind of bastardization of the IPP/JMP job model in general. A job can be in many, many kinds of "states", depending on the features (and attendant complexities) of the underlying printing system. However, no matter what printing system is involved, all jobs will be in exactly one of the three top-level "meta" states of pending, processing, done. Below these three states, the mgmt application in question will decide on the exact semantics of the job based on some *consistent* refinement of the top-level state. Hence, the simple two-level model I have been suggesting this past week or so. ...jay From ipp-archive Wed Jun 4 15:28:16 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA09414 for ipp-outgoing; Wed, 4 Jun 1997 15:23:45 -0400 (EDT) Date: Wed, 4 Jun 1997 15:24:00 -0400 (EDT) From: JK Martin Message-Id: <199706041924.PAA08607@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 > >What about other files (.doc, .prz, .ppt, .xls, .mov, .avi, .pdf, > >etc.)? Does the printer have to have code to handle all of these? > > Not unless you can watch movies on a piece of paper :) > Seriously, there are some data types that shouldn't HAVE to be printed. > That's the whole point of a PDF file (which should be handled). Hmmm... Interesting thought. (Not about movies on the printer, but being able to handle a wide variety of data types.. ;-) Say I am an IPP client and I tell my friendly IPP server to print a file. In that request I declare the incoming data type to be "crap-from-mars". Of course, the IPP server (only recognizing "crap-from-earth") would reject the request out of hand. In the case of Print-by-Reference, why wouldn't the printer just reject the client request once it has realized that the target URL contains data of an unsupported type? Granted, this assumes the entire printing process is lock-step-sequential, whereby the client remains connected to the server during the print processing, or at least long enough for the server to know whether it can actually print the requested job. If, on the other hand, the IPP server queues the Print-by-Reference request, then wouldn't it seem reasonable for the server implementation to simply print an "error page" in place of the actual print data? In either case the job status information would reflect the actual final outcome. Doesn't seem like that big of a deal. Of course, I don't develop printers for a living... ;-) Just some thoughts. ...jay From ipp-archive Wed Jun 4 15:38:19 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA10329 for ipp-outgoing; Wed, 4 Jun 1997 15:36:46 -0400 (EDT) From: jeff@boulder.qms.com (Jeff Copeland) Message-Id: <9706041936.AA01464@boulder.qms.com> Subject: Re: IPP>PRO - Print by reference To: jkm@underscore.com (JK Martin) Date: Wed, 4 Jun 1997 13:36:27 -0600 (MDT) Cc: ipp@pwg.org In-Reply-To: <199706041849.OAA07037@uscore.underscore.com> from "JK Martin" at Jun 4, 97 02:49:20 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: ipp-owner@pwg.org Precedence: bulk JK Martin wrote, a well-thought-out message about print-by-reference, ending with the question, > Anyone out there with an opinion on this situation? As an employee of a printer company (though speaking for myself :-), I have to agree with Stephen Holmstead's misgivings about IPP getting so bloated that it can't fit into a printer. Jay, you and I are seeing different things: I'm hearing from our marketing folks that people actually *do* want all that functionality in the printer, rather than having to hang printers off of servers. However, that discussion aside --- mostly because I need to think up arguments as well-reasoned as the ones of Jay's to which I'm responding, and beat some more information out of the marketing folks --- I think Jay's statement: > I agree with Roger deBry that Print-by-Reference should be a base > capability for IPP. I also believe that we are headed for a trip > through Interoperability Hell if we continue along the track of > supporting multiple levels of IPP conformance, and that we should only > focus on a single conformance level at this time. is a vitally important point. No matter what we decide on this issue -- or a host of others like it -- if we don't have a single IPP conformance level, we will have simply shot ourselves in the foot. Let's remember this every time one of us mentions multiple conformance levels. -- 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 Wed Jun 4 15:48:12 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA10808 for ipp-outgoing; Wed, 4 Jun 1997 15:44:41 -0400 (EDT) Message-ID: <3395C6D4.689A3678@sharplabs.com> Date: Wed, 04 Jun 1997 12:49:40 -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: Print by Reference X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Precedence: bulk You don't throw the mechanism out. Printers are only capable of handling certain types of jobs. We have attributes that describe the job like pdl-required, or desired-resolution, or duplexing or finishing requirements. Just like these attributes, the URL "schemes" that a particular print server can support can also be discovered. Or, the client can just submit and hope for the best. The ability of a printer to do print-by-reference, and the types of protocol scheme and/or MIME-tags that it can support can be negotiated/discovered, like attributes. Or the printer could just decide not to support the print-by-reference attribute and return an error. IMHO, I think it would be a mistake to propose a new internet printing protocol to be deployed in late 1997 or 1998 that does not contain a document "pull" capability. Randy From ipp-archive Wed Jun 4 15:48:13 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA10858 for ipp-outgoing; Wed, 4 Jun 1997 15:47:43 -0400 (EDT) From: Harry Lewis To: Cc: , Subject: Re: JMP> Re: IPP> MOD JobState suggestion Message-Id: <5030100003135910000002L002*@MHS> Date: Wed, 4 Jun 1997 15:49:20 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk I think there is a problem with the state diagram +--> canceled(7) / +---> pending(3) ----> processing(5) -----+----> aborted(8) | ^ ^ \ --->+ | | +--> completed(9) | v | +---> held(4) processing-stopped(6) In that it does not show the ability to cancel a job from Held or Needs-Attention (processing-stopped) states. It is also quite possible that a job in Needs-Attention state would ultimately abort. I recommend the following changes to the diagram... +--> canceled(7) / +---> pending(3) ----> processing(5) ---+-+----> aborted(8) | ^ ^ | \ --->+ | | | +--> completed(9) | v v | +---> held(4) processing-stopped(6) | | | | +--------------------+---------+ Harry Lewis - IBM Printing Systems From ipp-archive Wed Jun 4 15:48:17 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA10838 for ipp-outgoing; Wed, 4 Jun 1997 15:46:32 -0400 (EDT) Date: Wed, 4 Jun 1997 15:46:37 -0400 (EDT) From: JK Martin Message-Id: <199706041946.PAA09618@uscore.underscore.com> To: jeff@boulder.qms.com Subject: Re: IPP>PRO - Print by reference Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Jeff, You know, your response leads me to say something that may seem like a contradiction to some: If forced to decide on whether to include Print-by-Reference as a base IPP requirements VERSUS having only a single level of IPP conformance, then I would vote for the single level of conformance in a heartbeat. Yeah, that means I'd be willing to give up the highly desired feature of Print-by-Reference if it resulted in a SINGLE level of IPP conformance for the first release of IPP in the marketplace. Interoperability is Number One. All else is subordinate. Hmmm... that's putting the cart before the horse. How about: Pervasive acceptance and deployment is Number One. And this can only be achieved (from industry experience) by pervasive interoperability. Thanks for helping with the prioritization process, Jeff. ...jay PS: Now, about that SWP proposal from Microsoft and Hewlett-Packard... When are the others in the IPP list going to start the discussion on this topic, the very thing that created the "Levels of Conformance" thing in the first place?... ----- Begin Included Message ----- >From jeff@boulder.qms.com Wed Jun 4 15:37 EDT 1997 From: jeff@boulder.qms.com (Jeff Copeland) Subject: Re: IPP>PRO - Print by reference To: jkm@underscore.com (JK Martin) Date: Wed, 4 Jun 1997 13:36:27 -0600 (MDT) Cc: ipp@pwg.org JK Martin wrote, a well-thought-out message about print-by-reference, ending with the question, > Anyone out there with an opinion on this situation? As an employee of a printer company (though speaking for myself :-), I have to agree with Stephen Holmstead's misgivings about IPP getting so bloated that it can't fit into a printer. Jay, you and I are seeing different things: I'm hearing from our marketing folks that people actually *do* want all that functionality in the printer, rather than having to hang printers off of servers. However, that discussion aside --- mostly because I need to think up arguments as well-reasoned as the ones of Jay's to which I'm responding, and beat some more information out of the marketing folks --- I think Jay's statement: > I agree with Roger deBry that Print-by-Reference should be a base > capability for IPP. I also believe that we are headed for a trip > through Interoperability Hell if we continue along the track of > supporting multiple levels of IPP conformance, and that we should only > focus on a single conformance level at this time. is a vitally important point. No matter what we decide on this issue -- or a host of others like it -- if we don't have a single IPP conformance level, we will have simply shot ourselves in the foot. Let's remember this every time one of us mentions multiple conformance levels. -- 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 ----- End Included Message ----- From ipp-archive Wed Jun 4 16:13:03 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA12498 for ipp-outgoing; Wed, 4 Jun 1997 16:12:49 -0400 (EDT) Mime-Version: 1.0 Date: Wed, 4 Jun 1997 16:17:11 -0400 Message-ID: <00018791.1337@digprod.com> From: bwagner@digprod.com (Bill Wagner) Subject: Re[2]: IPP>PRO - Print by reference To: 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 There was, at least at one time, a sense of urgency to the IPP mission. And this was accompanied by the understanding that a simple basic capability had the best chance of rapid approval, implementation and deployment. Indeed, one approach discussed was to provide multiple specifications, each concentrating on one major aspect, with an over-all structure making them compatible. However, IPP appears to reverted to the overall grand document approach which, I believe, will delay and possibly cripple the concept because there will be multiple proprietary, incompatible implementations in the field long before the ultimate IPP. The HP/Microsoft proposal appeared to be a refreshing return to the original concept; but it appears that IPP has simply absorbed it into an increasingly cumbersome mass. Although Carl-Uno suggests that the specific type of print by reference being proposed is optional, Jay and others seem to believe it should be a mandatory part of the base specification. I suggest that this is undesirable, since without proper security, the implementation is useful in some cases but generally flawed. This will produce objections which should and will be worked out; but why put this in the critical path of the very useful basic IPP printing capability? DPI, and I suspect others, do support an HTTP client as well as server in its printer NIC's. That is not the point. The point is that if IPP is to define internet printing successfully, it needs to get something doable, agreeable, and widely useful out soon. IMHO, this will not happen if functionality is increased to the point where separate servers are needed, where IPP is only for limited special internet applications, or where industry opposition is high. Bill Wagner Osicom/DPI ______________________________ Reply Separator _________________________________ Subject: RE: IPP>PRO - Print by reference Author: JK Martin at Internet Date: 6/4/97 2:49 PM Stephen Holmstead submitted a fine posting on the pragmatic insights as to why "Print by Reference" is so tough for embedded IPP servers, such as network printers. (See attached message.) I think his posting should cause the IPP project to stop for second and consider exactly which set of solutions we're trying to solve NOW versus the set of all known problems in the universe. The IPP project now faces this situation: 1) Assumption: Print-by-Reference is a highly desirable feature. 2) Printer vendors declare that Print-by-Reference is too difficult or otherwise costly to implement in low-cost embedded devices. Some folks seem to think the obvious conclusion is: Therefore, remove Print-by-Reference as a base requirement. Am I the only person in the IPP world who has a hard time with this conclusion? Or is this one of the not-so-subtle differences between the two conformance levels of "IPP Level 1" and "IPP Level 2"? Or is the base assumption of "Print-by-Reference is a Good Thing" an invalid assumption? I agree with Microsoft's stated belief that print services are best provided by a front-end (host-based) server that "feeds" the printer in a manner consistent with local policy (whatever that may be). The continued drive by printer vendors to be "everything to everyone" will continue to drive DOWN the set of base capabilities for new network printing standards. We will continue to beat our heads against the wall trying to make such standards scale from Enterprise-strength down to simple peer-level printing at the consumer level. If we are unable (or unwilling) to develop parallel sets of standards that deal with scalability in a sane manner (which is very tough and ugly, I'll admit), then why can't we focus on a "top-down" approach that first addresses the Enterprise, then move on to a more consumer- oriented (peer-level) standard? While many folks in the IPP won't admit it, they are very focused on using IPP as the vehicle for the pay-for-print Copy Shop solution. These folks often cite that consumer-level clients will want to take advantage of Copy Shop services via IPP...and this may be very true. However, there is a tremendous difference between consumer-side clients and consumer-side IPP servers. Based on Stephen's posting, it's fair to say that low-end printers fall into the camp of consumer-side IPP servers. The question is, will the typical Copy Shop employ consumer-side IPP servers, or will they more likely use higher-level Enterprise-side IPP servers? My money (pun intended) is on the Enterprise-side for this particular scenario. Enterprise customers, on the other hand, are quickly moving their backbone printing services away from peer-to-peer printing to server-based printing to better manage their printer assets. That is, there is no desire for clients to print directly to the network printer; hence, the need for the printer to perform IPP services in this scenario is also quite weak. I agree with Roger deBry that Print-by-Reference should be a base capability for IPP. I also believe that we are headed for a trip through Interoperability Hell if we continue along the track of supporting multiple levels of IPP conformance, and that we should only focus on a single conformance level at this time. Anyone out there with an opinion on this situation? ...jay PS: Print-by-Reference is not the only instance of this "High-vs-Low" struggle. Similar situations have been repeatedly arisen in the Job Monitoring (JMP) and Printer MIB/MIF (PMP) projects over the course of the last four years. ---------------------------------------------------------------------- -- 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 Jun 4 13:14 EDT 1997 From: Stephen Holmstead To: "'ipp@pwg.org'" Subject: RE: IPP>PRO - Print by reference Date: Wed, 4 Jun 1997 11:00:26 -0600 Encoding: 22 TEXT Print by reference is REALLY tough for the printer to do. Up until this point, the printer only had to do http server capabilities (which can be implemented fairly easily). However, print by reference now would require the printer to implement http client capabilities (which is HUGE!!, not to mention how unstable the client features are and the fact that the printer most likely won't ever have a flash upgrade). What about all of the embedded graphics files (gif, jpeg, pcx, tiff, etc.)? Does the printer have to have code to convert all of these to printable output? What about other files (.doc, .prz, .ppt, .xls, .mov, .avi, .pdf, etc.)? Does the printer have to have code to handle all of these? What about plug-ins and applets? Does the printer have to have a Java Virtual Machine to run Java applets? The client (i.e. Browser) is quite large and has too many features to be able to support by a printer. I have to strongly protest print by reference as it causes the requirement load on the printer to skyrocket. -- Stephen Holmstead Hewlett Packard Internet Solutions Operation stephen_holmstead@hp.com ----- End Included Message ----- From ipp-archive Wed Jun 4 16:28:15 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA13014 for ipp-outgoing; Wed, 4 Jun 1997 16:24:45 -0400 (EDT) Message-ID: <3395CCA8.5476@parc.xerox.com> Date: Wed, 4 Jun 1997 13:14:32 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: Jeff Copeland CC: JK Martin , ipp@pwg.org Subject: Re: IPP>PRO - Print by reference References: <9706041936.AA01464@boulder.qms.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk A HTTP client is not the same thing as a web browser. One way to simplify the 'footprint' requirement is to assert that any 'reference' that you want to 'print by' must be from, for example, a HTTP server, be directly available without redirection, and only be in a media type that the printer said it already supported. So, the implementation on the printer end would be basically: open a connection to the host in the URL send "GET url HTTP/1.1" and "accept: application/postscript" read the result: if not 200, error read headers: scan for content-type; if type isn't recognized, error read data as print data. close connection Maybe 100 lines of code? Certainly not megabytes. Don't turn a little capability (print by reference) into a big one (printer is a web browser) and then complain that the result is too big. -- http://www.parc.xerox.com/masinter From ipp-archive Wed Jun 4 17:08:06 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA13819 for ipp-outgoing; Wed, 4 Jun 1997 17:05:58 -0400 (EDT) Message-Id: <01BC70F8.C2B196F0@hpb19043.boi.hp.com> From: Stephen Holmstead To: "ipp@pwg.org" Subject: RE: IPP>PRO - Print by reference Date: Wed, 4 Jun 1997 15:05:36 -0600 Encoding: 18 TEXT Sender: ipp-owner@pwg.org Precedence: bulk Michael E. Gaines wrote: >If IPP takes off, then I believe >responsible web masters will place data on pages in a format that will >be suited for IPP devices and all will be well. Right now, web masters don't even put their pages in a format that will be suited for both Internet Explorer AND Netscape! Some do 'frames only' pages. Why do you think this will change? Ok, I did notice that you wrote "responsible web masters", but I don't believe that I have met one yet. :-) -- Stephen Holmstead Hewlett Packard Internet Solutions Operation stephen_holmstead@hp.com From ipp-archive Wed Jun 4 18:08:05 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA14610 for ipp-outgoing; Wed, 4 Jun 1997 18:03:21 -0400 (EDT) From: mabry@rd.qms.com Message-Id: <9706048654.AA865461817@internet-mail.it.qms.com> X-Mailer: ccMail Link to SMTP R8.00.00 Date: Wed, 04 Jun 97 17:01:22 -0600 To: Subject: Re[3]: IPP>PRO - Print by reference Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk To take a brief walk down memory lane..... At the New Orleans meeting (remember back that far) one of the initial "requirements" mentioned was that this should be simple enough to embed. In fact, here is a snippet from the archives on pwg.org. Remember the old charter3.txt? Charter 3.0 11/8/96 Internet Printing Project (ipp) ------------------------------- Chair(s): Carl-Uno Manros Applications Area Director(s): Keith Moore Harald Alvestrand Area Advisor: Mailing lists: General Discussion: ipp@pwg.org To Subscribe: majordomo@pwg.org Archive: ftp://ftp.pwg.org/pub/pwg/ipp Editor Scott Isaacson Description of Working Group: This working group will work to solve the following Internet printing problems. All solutions must be platform independent for maximum effectiveness and deployment. Simple enough for embedding in a network attached printer - A legitimate implementation of this might be able to accept only one < the rest of the stuff snipped> No doubt that things have changed since this early discussion, however I agree with Bill that the "sense of urgency" is lost. The current state of IPP is far from simple, IMHO. Mabry Dozier QMS ______________________________ Reply Separator _________________________________ Subject: Re[2]: IPP>PRO - Print by reference Author: at Internet-Mail Date: 6/4/97 4:17 PM There was, at least at one time, a sense of urgency to the IPP mission. And this was accompanied by the understanding that a simple basic capability had the best chance of rapid approval, implementation and deployment. Indeed, one approach discussed was to provide multiple specifications, each concentrating on one major aspect, with an over-all structure making them compatible. However, IPP appears to reverted to the overall grand document approach which, I believe, will delay and possibly cripple the concept because there will be multiple proprietary, incompatible implementations in the field long before the ultimate IPP. The HP/Microsoft proposal appeared to be a refreshing return to the original concept; but it appears that IPP has simply absorbed it into an increasingly cumbersome mass. Although Carl-Uno suggests that the specific type of print by reference being proposed is optional, Jay and others seem to believe it should be a mandatory part of the base specification. I suggest that this is undesirable, since without proper security, the implementation is useful in some cases but generally flawed. This will produce objections which should and will be worked out; but why put this in the critical path of the very useful basic IPP printing capability? DPI, and I suspect others, do support an HTTP client as well as server in its printer NIC's. That is not the point. The point is that if IPP is to define internet printing successfully, it needs to get something doable, agreeable, and widely useful out soon. IMHO, this will not happen if functionality is increased to the point where separate servers are needed, where IPP is only for limited special internet applications, or where industry opposition is high. Bill Wagner Osicom/DPI ______________________________ Reply Separator _________________________________ Subject: RE: IPP>PRO - Print by reference Author: JK Martin at Internet Date: 6/4/97 2:49 PM Stephen Holmstead submitted a fine posting on the pragmatic insights as to why "Print by Reference" is so tough for embedded IPP servers, such as network printers. (See attached message.) I think his posting should cause the IPP project to stop for second and consider exactly which set of solutions we're trying to solve NOW versus the set of all known problems in the universe. The IPP project now faces this situation: 1) Assumption: Print-by-Reference is a highly desirable feature. 2) Printer vendors declare that Print-by-Reference is too difficult or otherwise costly to implement in low-cost embedded devices. Some folks seem to think the obvious conclusion is: Therefore, remove Print-by-Reference as a base requirement. Am I the only person in the IPP world who has a hard time with this conclusion? Or is this one of the not-so-subtle differences between the two conformance levels of "IPP Level 1" and "IPP Level 2"? Or is the base assumption of "Print-by-Reference is a Good Thing" an invalid assumption? I agree with Microsoft's stated belief that print services are best provided by a front-end (host-based) server that "feeds" the printer in a manner consistent with local policy (whatever that may be). The continued drive by printer vendors to be "everything to everyone" will continue to drive DOWN the set of base capabilities for new network printing standards. We will continue to beat our heads against the wall trying to make such standards scale from Enterprise-strength down to simple peer-level printing at the consumer level. If we are unable (or unwilling) to develop parallel sets of standards that deal with scalability in a sane manner (which is very tough and ugly, I'll admit), then why can't we focus on a "top-down" approach that first addresses the Enterprise, then move on to a more consumer- oriented (peer-level) standard? While many folks in the IPP won't admit it, they are very focused on using IPP as the vehicle for the pay-for-print Copy Shop solution. These folks often cite that consumer-level clients will want to take advantage of Copy Shop services via IPP...and this may be very true. However, there is a tremendous difference between consumer-side clients and consumer-side IPP servers. Based on Stephen's posting, it's fair to say that low-end printers fall into the camp of consumer-side IPP servers. The question is, will the typical Copy Shop employ consumer-side IPP servers, or will they more likely use higher-level Enterprise-side IPP servers? My money (pun intended) is on the Enterprise-side for this particular scenario. Enterprise customers, on the other hand, are quickly moving their backbone printing services away from peer-to-peer printing to server-based printing to better manage their printer assets. That is, there is no desire for clients to print directly to the network printer; hence, the need for the printer to perform IPP services in this scenario is also quite weak. I agree with Roger deBry that Print-by-Reference should be a base capability for IPP. I also believe that we are headed for a trip through Interoperability Hell if we continue along the track of supporting multiple levels of IPP conformance, and that we should only focus on a single conformance level at this time. Anyone out there with an opinion on this situation? ...jay PS: Print-by-Reference is not the only instance of this "High-vs-Low" struggle. Similar situations have been repeatedly arisen in the Job Monitoring (JMP) and Printer MIB/MIF (PMP) projects over the course of the last four years. ---------------------------------------------------------------------- -- 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 Jun 4 13:14 EDT 1997 From: Stephen Holmstead To: "'ipp@pwg.org'" Subject: RE: IPP>PRO - Print by reference Date: Wed, 4 Jun 1997 11:00:26 -0600 Encoding: 22 TEXT Print by reference is REALLY tough for the printer to do. Up until this point, the printer only had to do http server capabilities (which can be implemented fairly easily). However, print by reference now would require the printer to implement http client capabilities (which is HUGE!!, not to mention how unstable the client features are and the fact that the printer most likely won't ever have a flash upgrade). What about all of the embedded graphics files (gif, jpeg, pcx, tiff, etc.)? Does the printer have to have code to convert all of these to printable output? What about other files (.doc, .prz, .ppt, .xls, .mov, .avi, .pdf, etc.)? Does the printer have to have code to handle all of these? What about plug-ins and applets? Does the printer have to have a Java Virtual Machine to run Java applets? The client (i.e. Browser) is quite large and has too many features to be able to support by a printer. I have to strongly protest print by reference as it causes the requirement load on the printer to skyrocket. -- Stephen Holmstead Hewlett Packard Internet Solutions Operation stephen_holmstead@hp.com ----- End Included Message ----- From ipp-archive Wed Jun 4 21:08:07 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA15728 for ipp-outgoing; Wed, 4 Jun 1997 21:07:52 -0400 (EDT) Message-Id: <3.0.1.32.19970604180204.009eeb70@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 4 Jun 1997 18:02:04 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC - PWG Phone Conference on IPP Security - June 5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk PWG Phone Conference on IPP Security - June 5, 1 - 3 PST Agenda Finish review and comment on Roger's latest Security draft text Finish work security attributes that we need to include in the Directory Schema and Protocol documents. 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 Jun 4 22:28:08 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA16549 for ipp-outgoing; Wed, 4 Jun 1997 22:23:52 -0400 (EDT) From: szilles@Adobe.COM (Stephen Zilles) Message-Id: <199706050223.TAA20533@bulletin> To: ipp@pwg.org Subject: IPP> PRO - A value-type field for the Protocol Spec proposal Phone: (408) 536-4766 Fax: (408) 537-4042 Office: W14-504 Cc: szilles@Adobe.COM Date: Wed, 04 Jun 1997 19:23:47 PDT Sender: ipp-owner@pwg.org Precedence: bulk Randy Turner's very good document on an application/ipp format over HTTP 1.1 triggered an important concern on my part. This concern was extensibility. I understand the simplicity of having everything be attribute value pairs with a character attribute name of a given length and a (string) value of a given length. But, I think that this is an over- simplification of the future of IPP. The Problem Statement To avoid vague generalizations, lets consider an example that I believe is likely to arise in the near future. On attribute one might want to add is an "address". For example, one might have an address to which the final output is to be mailed or shipped. One might also have an address to which the bill for reproduction is to be sent. This brings our first problem because, quite often, these two addresses are not the same. That means that we need two different address attributes. The second problem with addresses is that an address is a structured entity. It has things like a mailstop, a street number, a street name, a city sub-region identifier, a city identifier, a state and/or country identifier and, typically, some kind of ZIPcode. These are assembled into an address, but they are assembled in different ways in different cultures and countries. This means that treating the address as a single character string makes it very difficult to accurately recover the information in the address. It makes more sense to store the address as a structured objects with attributes and values for each of the component parts. But, the address (as a whole) is the value of the shipping address or billing address attribute identified above. The current proposal for IPP does not allow a value to be structured. Well, that is not quite true, there is one simple kind of structuring for attributes whose value is a list of values. The elements of the value list are identified by being introduced with a zero length attribute name. This, however, will not help in the address example unless one specifies a fixed order for the component parts. History has shown the positional syntaxes are much more prone to breakage than keyword syntaxes, especially where many of the components are optional (as is the case with addresses). A Proposed Solution The proposed solution to the extensibility problem is to add a type byte (or half word) to the value portion of the value portion of the attribute-value pair. This would change the syntax in Randy's recent draft as follows: attribute = name-length name value-type value-length value ... value-type = one-byte integer ; a registered type value value-length = three-byte integer ; number of octets in value value = octet-string Note that the length was increased to three bytes to allow for larger structured values and was (arbitrarily) made three bytes so that the combination of value-type and value-length takes four bytes. It is proposed that there be a registry of value types. The first two entries in that registry would be (zero is reserved) 1: Unicode string in UTF8 encoding (as specified in the draft) 2: list of values (here the length of the value field determines how many values are present. The length, however, is not the number of value, but the number of bytes consumed by the values. This covers the cases defined in Randy's draft. Possible additions in the future might be to add a type for binary numbers (integers or possibly float in IEEE format) and for "dictionaries" which would be nested sets of attribute-value pairs such as required for the address example above. It is also the case that this scheme immediately provides hierarchy in the value space. For example, in the list of values case, any of the values in the list could be another list, and so forth. I would agree that we may wish to restrict the hierarchy to one level in the first specification, but I believe that we should provide the capability to allow hierarchy in future versions of the IPP protocol specification. Alternative Solutions I will agree that it is not necessary to introduce a value-type to solve the extensibility problem that I posed above. I believe, however, that it is the simplest, most robust way to provide extensibility. Some other solutions are: Claim that it never makes sense to structurally subdivide a value. This would mean that addresses would just be strings and it would be up to the recipient to figure out how to parse the string. One could register rules for parsing strings and associate these rules with attribute names. As noted, the rules for parse an arbitrary address may not be definable, so it might be necessary to structure the attribute name so that it has the rule for how to parse the value; this might be done sort of like the way the URLencode form data is handled, but with substring ranges to be used on the value string in place of the value data. Allow values like addresses to be structured but require the name to have the structuring information. In the example above there would be separate attribute names for billingAddress.mailstop and shippingAddress.mailstop and so forth for all the component part of an address. With this solution one asks whether all the parts of a structured attribute must occur in sequence or may they occur in any order in the attribute list. Recommendation Work with interchange formats such as TIFF, PostScript and PDF have shown the value of having a type identifier for values. It provides extensibility and allows more efficient representations of the data. I, therefore, think that a value-type byte should be built into the application/ipp encoding format. By the way, it does not matter whether the value-type precedes or follows the value-length (as long as it is clear that the value-type is not counted in the value-length). Nor am I sure that a three-byte value-length is the correct value. What is important is having a value-type field at all. From ipp-archive Thu Jun 5 07:38:14 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA19193 for ipp-outgoing; Thu, 5 Jun 1997 07:36:59 -0400 (EDT) From: don@lexmark.com Message-Id: <199706051137.AA18446@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Thu, 5 Jun 1997 07:36:54 -0400 Subject: IPP> June 4th Conference Call Minutes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: bulk To: ipp@pwg.org cc: From: Don Wright @ LEXMARK@LEXMTA Date: 06/05/97 07:36:54 AM Subject: June 4th Conference Call Minutes I have uploaded today's conference call minutes to the ftp server and have attached them to the bottom of this note. The minutes are available as follows: ftp://ftp.pwg.org/pub/pwg/ipp/minutes/970604-ipp-conference-call.txt ftp://ftp.pwg.org/pub/pwg/ipp/minutes/970604-ipp-conference-call.pdf As I will be in Japan for the next two weeks, I trust someone will volunteer to do this job for those conference calls. Don ------------ PWG - Internet Printing Project Conference Call - June 4, 1997 The meeting was called to order at 4:00 PM EDT. Attendees: Bob Herriott - Sun Carl-Uno Manros - Xerox Don Wright - Lexmark Steve Zilles - Adobe Tom Hastings - Xerox Ron Bergman - Data Products Randy Turner - Sharp Lee Farrell - Canon Scott Isaacson - Novell Patrick Powell - UCSD J.K. Martin - Underscore Jeff Copeland - QMS Peter Zehler - Xerox Harry Lewis - IBM Munich Plenary - Plan is to split up the document review into multiple sessions - No MIB meetings to avoid - Should avoid WEBDav, IP over 1394, HTTP, Internet FAX - Should plan on 30-40 people in attendance JOB MIB Discussion on State Names: Three alternatives: - Pending-Stopped - Held - Pending-Held ** This was the name selected A discussion was held on how various fringe conditions could be represented by the various states and which ones are mandatory. An inconsistency was raised concerning incoming and outgoing jobs' states: When the job state reason is "incoming" what should the job state be? ** PENDING or PROCESSING are both valid. Same question for outgoing? ** No resolution was agreed to. The seven JOB-STATES are now: Completed-Aborted Completed-Canceled Completed Processing Processing-Stopped Pending-Held Pending Only the JOB-STATE and JOB-STATE-REASONS attributes are required but none of the enumerated values are mandatory. The discussion on this was cut short due to time constraints; however, almost all the participants did not believe that we needed to provide more than just implementation recommendations as to which JOB-STATES and JOB-STATE-REASONS values are returned by any one implementation. The Model meeting will be on Friday to further discuss the above. MODEL SUB-GROUP New document posted - ready for review. Discussion on need for "level's of conformance" - There were strong feelings by some people that we shouldn't have two levels - Reality of the market says there will be a large number of installations of whatever Microsoft does. - No decision was made. Scott would like comments and questions by commenting on the document by specific line number by June 16th. The goal is to provide another draft before the August IETF meeting. PROTOCOL SUB-GROUP There was a meeting on Monday working and commenting on Randy's Protocol document. Changes will be reflected into the next revision of the document. Steve Zilles has a concern about not including the attribute type in the encoding. He will be writing up this concern and posting it to the mailing list. We will need to register application/IPP as a MIME type either as a separate document or as an appendix to an existing document. There will be a Protocol sub-group meeting on June 17th at Sun in Menlo Park from 9:30 AM until 6 PM. SECURITY SUB-GROUP No report from Roger Debry (he was not on the call.) Carl-Uno reported that progress was being made and a new draft should be issued soon. Randy Turner and Scott Isaacson briefly reviewed the discussion from the last meeting. One of the open issues is the security implications of "print by reference." OPERATIONS Validate is believed by many of the participants that the validate operation is a good one to have. A question was raised as to who, if anyone, was implementing IPP on the Macintosh. White space in data (tab, cr, lf, etc.) is not a delimiter. This will be clarified in the next version of Randy's protocol document. Randy will make his document into an Internet Draft and will send it to Carl-Uno to get it published by the IETF. Rationale for selected HTTP will need to eventually included in the protocol document. Steve Zilles will start working on that document (separate, at least at first.) Don Wright and Steve Zilles will not be on the next two calls. A secretary will be needed for those calls. The meeting adjourned at 6 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 Thu Jun 5 10:28:15 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA19804 for ipp-outgoing; Thu, 5 Jun 1997 10:25:04 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-model-01.txt Date: Thu, 05 Jun 1997 09:59:06 -0400 Message-ID: <9706050959.aa05950@ietf.org> Sender: ipp-owner@pwg.org Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Printing Protocol Working Group of the IETF. Title : Internet Printing Protocol/1.0: Model and Semantics Author(s) : R. Debry, T. Hastings, R. Herriot, S. Isaacson, P. Powell Filename : draft-ietf-ipp-model-01.txt Pages : 82 Date : 06/04/1997 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 using Internet tools and technology. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (ISO/IEC 10175 DPA) standard. Although DPA specifies both end user and administrative features, IPP version 1.0 is focused only on end user functionality. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-model-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-model-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipp-model-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970604174841.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-model-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-model-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970604174841.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-archive Thu Jun 5 10:48:16 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA20311 for ipp-outgoing; Thu, 5 Jun 1997 10:47:10 -0400 (EDT) From: Harry Lewis To: Subject: Re[2]: IPP>PRO - Print by reference Message-Id: <5030100003191867000002L072*@MHS> Date: Thu, 5 Jun 1997 10:48:55 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk I view the Print By Reference thread as a possible catalyst for IPP. Bill has stated concisely (as usual) what many of us have been trying to "flag" for some time... that from 10,000 feet, IPP has lost it's sense of streamline urgency and, although not a perfect solution, SWP appeared to hit the mark with respect to these criteria. > There was, at least at one time, a sense of urgency to the IPP > mission. And this was accompanied by the understanding that a simple > basic capability had the best chance of rapid approval, implementation > and deployment. Indeed, one approach discussed was to provide multiple > specifications, each concentrating on one major aspect, with an > over-all structure making them compatible. > However, IPP appears to reverted to the overall grand document > approach which, I believe, will delay and possibly cripple the concept > because there will be multiple proprietary, incompatible > implementations in the field long before the ultimate IPP. > The HP/Microsoft proposal appeared to be a refreshing return to the > original concept; but it appears that IPP has simply absorbed it into > an increasingly cumbersome mass. Print by reference is not the only conflict (HTTP vs. IPP being the heaviest in my opinion), but it represents an opportunity to renew and exercise our philosophy which will reveal itself either as seeking practical solutions to known problems or striving for architectural perfection. We all feel an obligation to look forward, anticipate and avoid pitfalls in the standards we are developing, but there comes a time when it is wise to heed the "80/20" rule. Stephen warns that print by reference could overwhelm printer based IPP implementations if it means full HTTP client capabilities. This spawned a great debate... one that every printer hardware and software vendor wishes they really knew the answer to ... are customers more interested in Peer-to-Peer or Server based solutions? Jay and Jeff have stated opposite views. If we could gather 105 customers onto the reflector for 3 weeks, I doubt we would obtain a clear cut answer. In my opinion, Larry has offered a convergence point for the Print by Reference discussion: >A HTTP client is not the same thing as a web browser. >One way to simplify the 'footprint' requirement is to >assert that any 'reference' that you want to 'print by' >must be from, for example, a HTTP server, be directly >available without redirection, and only be in a media type >that the printer said it already supported. >So, the implementation on the printer end would be basically: > open a connection to the host in the URL > send "GET url HTTP/1.1" and "accept: application/postscript" > read the result: > if not 200, error > read headers: > scan for content-type; if type isn't recognized, error > read data as print data. > close connection >Maybe 100 lines of code? Certainly not megabytes. >Don't turn a little capability (print by reference) into a big one >(printer is a web browser) and then complain that the result is too big. It may seem inappropriate for me to comment, since I have been so heavily involved in trying to progress (and streamline) the job MIB and have not made any specific detailed contributions to IPP. I haven't been dealing with standards as long as some of you, but long enough to understand (and have been part of) how group behavior among a bunch of "brilliant" thinkers can be very difficult to manage, throttle and maintain control of. On this topic, I just offer that SWP is lacking Print by reference, which many consider a real requirement. It is clear that various participants view the need for IPP to scale from the Enterprise to the device. If kept pragmatic and simple enough, I believe there might be a chance for SWP to embrace Print by reference and satisfy the bulk of this requirement. If not, the debate, and time, will rage on. Harry From ipp-archive Thu Jun 5 11:43:18 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA20866 for ipp-outgoing; Thu, 5 Jun 1997 11:41:21 -0400 (EDT) Message-Id: <9706051541.AB02600@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, 5 Jun 1997 08:38:46 PDT To: Scott_Isaacson@novell.com (Scott Isaacson), ipp@pwg.org From: Tom Hastings Subject: IPP> printer-resolution standard values retrograded Sender: ipp-owner@pwg.org Precedence: bulk The 970512.doc had the following for printer-resolution, but the latest I-D 970603 has reverted to earlier text that didn't have any standard values listed. Did any other attributes retrograde? Tom 6.2.12 printer-resolution (type2 keyword) This job attribute specifies the resolution that the Printer should use. The values are type2 keywords which represent single integers or pair of integers. The latter are to specify the resolution when the x and y dimensions differ. When two integers are specified, the first is in the x direction, i.e., in the direction of the shortest dimension of the medium, so that the value is independent of whether the printer feeds long edge or short edge first. The standard values are: normal res-100 res-200 res-240 res-300 res-600 res-800 res-1200 res-1800 res-100x200 res-300x600 res-600x300 res-400x800 res-800x400 res-600x1200 res-1200x600 res-1800x600 From ipp-archive Thu Jun 5 11:43:25 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA20932 for ipp-outgoing; Thu, 5 Jun 1997 11:42:31 -0400 (EDT) Message-Id: <9706051541.AB02600@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, 5 Jun 1997 08:38:50 PDT To: Harry Lewis From: Tom Hastings Subject: Re: JMP> Re: IPP> MOD JobState suggestion Cc: , Sender: ipp-owner@pwg.org Precedence: bulk I agree that canceled can be entered from any state and that a system might (but need not) abort a stopped job. The definition of the aborted state for IPP and JMP supports your idea with the weasil word "usually" in the definition: aborted: The job has been aborted by the system, usually while the job was in the processing state. So how does this picture look to you for IPP and JMP (IPP wouldn't have the enums and wouldn't have the "active/in-active" line, since it is a JMP-only term). Running arrows from every state to canceled and from stopped to aborted would look like this: >> +--------->----------+------>------+--> canceled(7) >> | | | >> +---> pending(3) -------> processing(5) -------> completed(9) >> | ^ ^ \ | >> --->+ | | +------------> aborted(8) >> | v v / | >> +---> held(4) stopped(6) | | | | +--------->----------+------>------+ >> >> <-------------- active ------------>|<-- in-active -->| >> Is this figure ok? At 12:49 06/04/97 PDT, Harry Lewis wrote: >I think there is a problem with the state diagram > > > +--> canceled(7) > / > +---> pending(3) ----> processing(5) -----+----> aborted(8) > | ^ ^ \ >--->+ | | +--> completed(9) > | v | > +---> held(4) processing-stopped(6) > >In that it does not show the ability to cancel a job from Held or >Needs-Attention (processing-stopped) states. It is also quite possible >that a job in Needs-Attention state would ultimately abort. > >I recommend the following changes to the diagram... > > > +--> canceled(7) > / > +---> pending(3) ----> processing(5) ---+-+----> aborted(8) > | ^ ^ | \ >--->+ | | | +--> completed(9) > | v v | > +---> held(4) processing-stopped(6) | > | | | > +--------------------+---------+ > > > >Harry Lewis - IBM Printing Systems > > From ipp-archive Thu Jun 5 11:43:30 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA20930 for ipp-outgoing; Thu, 5 Jun 1997 11:42:25 -0400 (EDT) Message-Id: <9706051541.AB02600@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, 5 Jun 1997 08:39:02 PDT To: ipp@pwg.org, jmp@pwg.org, Harry Lewis From: Tom Hastings Subject: Re: JMP> Re: IPP> MOD JobState suggestion Sender: ipp-owner@pwg.org Precedence: bulk I agree completely with Harry that we should have seven job states for IPP and JMP. I also happen to like the simpler single word names for the 7 states: pending held processing stopped canceled aborted completed My understanding from the 6/4 telecon is that the JMP jmJobState object will remain in the MANDATORY jmJobTable and that we will use Ron's suggestion for the conformance of the enums as: "All possible enums for this object must be reported if implemented and available to the agent." And then I agree with Harry that JMP implementations can use as many or as few job-state-reasons to embellish these states. My understanding of our agreement yesterday (6/4 telecon) is that JMP will keep jmJobStateReasons1 object MANDATORY, but not say anything about which enums are MANDATORY, which are CONDITIONALLY MANDATORY and which are OPTIONAL. Correct? Or should we include Ron's statement for JMP jmJobStateReasons1 object as well? IPP has job-state-reasons attribute as MANDATORY and has the following job-state-reason values MANDATORY, CONDITIONALLY MANDATORY, and OPTIONAL: MAN none MAN job-incoming OPT outgoing COND job-hold-until-specified OPT job-hold-until-resources-are-ready OPT printer-stopped-partly MAN printer-stopped OPT job-printing MAN-L2 job-canceled-by-user MAN-L2 job-canceled-by-operator OPT logfile-pending OPT logfile-transferring MAN job-completed-successfully MAN job-completed-with-warnings MAN job-completed-with-errors Tom At 14:05 06/04/97 PDT, Harry Lewis wrote: >I also want a small set of meaningful job states. > >>A job can be in many, many kinds of "states", depending on the features >>(and attendant complexities) of the underlying printing system. However, >>no matter what printing system is involved, all jobs will be in exactly >>one of the three top-level "meta" states of pending, processing, done. > >>Below these three states, the mgmt application in question will decide >>on the exact semantics of the job based on some *consistent* refinement >>of the top-level state. Hence, the simple two-level model I have been >>suggesting this past week or so. > >> ...jay > >I tend to get very confused by the 3 separate terminology's however, >those being JobState, JobSubState and JobStateReason. > >I believe there are actually 7 job states that deserve to be called >STATES. We should be welcome to embellish any state with as many (or as >FEW) REASONS as seen fit. Listed in my preferred terminology along with >the current IPP/JMP name-for-a-day in parenthesis, the 7 are: > >Pending >Held (Pending-Held) >Printing (Processing) >Needs_Attention (Processing-Stopped) >Completed >Canceled (Completed-Canceled) >Aborted (Completed-Aborted) > >Yes, the STRAIGHT LINE PATH from submission to marks on paper is >Pending-Printing-Complete, but other significant states are Held, >Needs_Attention, Canceled and Aborted. There are all kinds of reasons >(my favorite being printer-partly-stopped). I would like to suggest, however, >that if we adopt these 7 as the "high level" states then we can eliminate the >idea of "sub-state". > >Harry Lewis - IBM Printing Systems > > From ipp-archive Thu Jun 5 11:43:36 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA20931 for ipp-outgoing; Thu, 5 Jun 1997 11:42:25 -0400 (EDT) Message-Id: <9706051541.AB02600@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, 5 Jun 1997 08:38:48 PDT To: JK Martin From: Tom Hastings Subject: Re: JMP> Re: IPP> MOD JobState suggestion Cc: ipp@pwg.org, jmp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk Yes, you are correct that the canceled state can be entered from any of the active states and could do so in this picture which is intended to be the "normal" implementation. The weasle words around the figure are important, because some systems have transitions from processing to held (system backs a job out of processing due to a resource problem and DPA InterruptJob operation), and from completed to pending (DPA Resubmit). So the picture isn't intended to show all possible transitions, ok? The weasil words are: "The following figure shows the normal job state transitions: ... the diagram... Figure 3 - Normal job state transitions Normally a job progresses only from left to right. Other state transitions are unlikely, but are not forbidden." I could go back to the transtion table that I had originally, but this diagram that Bob drew was so much simpler and more understandable, except for the canceled bug that you point out. Harry also pointed out that some implementations might abort from the stopped state. Running arrows from every state to canceled and from stopped to aborted would look like this: >> +--------->----------+------>------+--> canceled(7) >> | | | >> +---> pending(3) -------> processing(5) -------> completed(9) >> | ^ ^ \ | >> --->+ | | +------------> aborted(8) >> | v v / | >> +---> held(4) stopped(6) | | | | +--------->----------+------>------+ >> >> <-------------- active ------------>|<-- in-active -->| >> Ok for IPP and JMP (IPP would be without the enum numbers and without the "active/in-active" which is termiology in JMP only. Thanks, Tom At 11:13 06/04/97 PDT, JK Martin wrote: >[I hope this cross-posting ends soon... :-{ ] Me too, but we're getting consistency between IPP and JMP this way. > >Tom, > >Regarding your latest-greatest state transition map: > >> The following figure shows the normal job state transitions: >> >> +--> canceled(7) >> / >> +---> pending(3) -------> processing(5) --+----> aborted(8) >> | ^ ^ \ >> --->+ | | +--> completed(9) >> | v v >> +---> held(4) processing-stopped(6) >> >> <-------------- active ------------>|<-- in-active -->| >> >> Figure 3 - Normal job state transitions >> >> Normally a job progresses only from left to right. Other state transitions >> are unlikely, but are not forbidden." > >Are you really sure this diagram is accurate? > >Say, for example, a job is in the "held" state. An operator or user then >cancels the job. According to your diagram, the job transits would then >manner: > > held -> pending > pending -> processing > processing -> canceled > >The same kind of mess occurs with the "processing-stopped" state, etc. > >This certainly must not be what you intend, right? > > ...jay > > From ipp-archive Thu Jun 5 12:58:29 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA23907 for ipp-outgoing; Thu, 5 Jun 1997 12:55:49 -0400 (EDT) From: Harry Lewis To: Cc: , Subject: Re: JMP> Re: IPP> MOD JobState suggestion Message-Id: <5030100003197841000002L012*@MHS> Date: Thu, 5 Jun 1997 12:57:33 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk I don't want to begin making the diagram too complex. >> +--------->----------+------>------+--> canceled(7) >> | | | >> +---> pending(3) -------> processing(5) -------> completed(9) >> | ^ ^ \ | >> --->+ | | +------------> aborted(8) >> | v v / | >> +---> held(4) stopped(6) | | | | +--------->----------+------>------+ I only want to assure that the state diagram does not give the impression that, to cancel or abort a job, the flow has to be back through processing. > +--> canceled(7) > / > +---> pending(3) ----> processing(5) -----+----> aborted(8) > | ^ ^ \ >--->+ | | +--> completed(9) > | v | > +---> held(4) processing-stopped(6) What was wrong with my proposal? > +--> canceled(7) > / > +---> pending(3) ----> processing(5) ---+-+----> aborted(8) > | ^ ^ | \ >--->+ | | | +--> completed(9) > | v v | > +---> held(4) processing-stopped(6) | > | | | > +--------------------+---------+ > >>> Harry <<< From ipp-archive Thu Jun 5 13:03:27 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA24181 for ipp-outgoing; Thu, 5 Jun 1997 12:58:52 -0400 (EDT) Message-Id: <3.0.1.32.19970605095118.00988ca0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 5 Jun 1997 09:51:18 PDT To: Harry Lewis From: Carl-Uno Manros Subject: IPP> PRO - Re: Print by reference Cc: ipp@pwg.org In-Reply-To: <5030100003191867000002L072*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk At 07:48 AM 6/5/97 PDT, you wrote: snip-snip >It may seem inappropriate for me to comment, since I have been >so heavily involved in trying to progress (and streamline) the job MIB >and have not made any specific detailed contributions to IPP. I haven't >been dealing with standards as long as some of you, but long enough to >understand (and have been part of) how group behavior among a bunch >of "brilliant" thinkers can be very difficult to manage, throttle and >maintain control of. > >On this topic, I just offer that SWP is lacking Print by reference, which >many consider a real requirement. It is clear that various participants >view the need for IPP to scale from the Enterprise to the device. If kept >pragmatic and simple enough, I believe there might be a chance for SWP to >embrace Print by reference and satisfy the bulk of this requirement. If >not, the debate, and time, will rage on. > >Harry > Harry, a couple of comments. First I do not know why you did not quote my contribution, in your summary so I will restate some of it. Print-by-reference is an optional feature like most other Printer features, and from a protocol point of view it is not very different from whether a printer can staple or not. It is true that that print-by-reference is more likely to be supported by print-servers rather than by small printers, but so what? When you ask the printer about its capabilities, it will tell you whether it supports print-by-reference or not. Like support for multiple documents in a job, you probably want to find out whether your printer supports it, before blindly submitting a job. The limited functionality of SWP has little or nothing to do with the print-by-reference discussion. The major limitations with SWP lie in the fact that it does not support important functions such as Cancel job and Get attributes, which are much more important. Hope this helps to clarify what we are talking about. 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 Jun 5 13:13:26 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA24348 for ipp-outgoing; Thu, 5 Jun 1997 13:05:05 -0400 (EDT) Date: Thu, 5 Jun 1997 10:05:35 -0700 (PDT) From: Ron Bergman To: Tom Hastings cc: Harry Lewis , ipp@pwg.org, jmp@pwg.org Subject: Re: JMP> Re: IPP> MOD JobState suggestion In-Reply-To: <9706051541.AB02600@zazen.cp10.es.xerox.com> Message-ID: X-X-Sender: rbergma@it.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Tom, I agree that you new revised figure is correct. But it has so many lines and lines crossing that I doubt it is useful. I propose that we keep the original figure, but show the two paths to "Aborted", with the added text: "The Canceled state can be entered from the Pending, Pending-Held, Processing, or Processing-Stopped states." Ron Bergman Dataproducts Corp. On Thu, 5 Jun 1997, Tom Hastings wrote: > I agree that canceled can be entered from any state and that a system > might (but need not) abort a stopped job. > > The definition of the aborted state for IPP and JMP supports your > idea with the weasil word "usually" in the definition: > > aborted: > The job has been aborted by the system, usually while the job was in the > processing state. > > So how does this picture look to you for IPP and JMP (IPP wouldn't > have the enums and wouldn't have the "active/in-active" line, since > it is a JMP-only term). > > Running arrows from every state to canceled and from stopped to > aborted would look like this: > > >> +--------->----------+------>------+--> canceled(7) > >> | | | > >> +---> pending(3) -------> processing(5) -------> completed(9) > >> | ^ ^ \ | > >> --->+ | | +------------> aborted(8) > >> | v v / | > >> +---> held(4) stopped(6) | > | | | > +--------->----------+------>------+ > >> > >> <-------------- active ------------>|<-- in-active -->| > >> > > Is this figure ok? From ipp-archive Thu Jun 5 13:28:26 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA26088 for ipp-outgoing; Thu, 5 Jun 1997 13:25:34 -0400 (EDT) Message-Id: <3.0.1.32.19970605101854.00aed980@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 5 Jun 1997 10:18:54 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - IPP in the News Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Techwire has just put out an article about IPP. The reference is: http://www.techweb.com/wire/news/june/0605print.html 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 Thu Jun 5 15:08:22 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA26834 for ipp-outgoing; Thu, 5 Jun 1997 15:04:51 -0400 (EDT) Date: Thu, 5 Jun 1997 12:05:21 PDT Message-Id: <3.0.16.19970605120237.883f6d2e@cayuga> X-Sender: stanmcc@cayuga X-Mailer: Windows Eudora Pro Version 3.0 (16) To: Tom Hastings , Scott_Isaacson@novell.com (Scott Isaacson), ipp@pwg.org From: Stan McConnell Subject: Re: IPP> printer-resolution standard values retrograded Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk I have a couple of comments about printer-resolution. 1. The list is missing the multiples of 360 that are in fairly common use in ink-jet printers. And most of these printers, if not all, can have a 2-dimensional resolution, e.g., 360x720, ... , 720x1440, 1440x1440. So the list needs to be expanded to cover these. 2. Given the potentially large list of 2d values, there is an mxn problem here, in addition to the need to register every new value with IANA. It seems more straightforward to simply replace the printer-resolution attribute with two attributes, printer-x-resolution and printer-y-resolution, each having an integer type which encodes the actual resolution value. Then there is no need to register the values. We made the mistake in DPA of having only a single value to encode printer resolution. I have submitted a defect report to ISO to correct the problem, and I hope IPP will fix the problem as well. At 08:38 AM 6/5/97 PDT, Tom Hastings wrote: >The 970512.doc had the following for printer-resolution, but the >latest I-D 970603 has reverted to earlier text that didn't have any standard >values listed. > >Did any other attributes retrograde? > >Tom > >6.2.12 printer-resolution (type2 keyword) >This job attribute specifies the resolution that the Printer should use. >The values are type2 keywords which represent single integers or pair of >integers. The latter are to specify the resolution when the x and y >dimensions differ. When two integers are specified, the first is in the x >direction, i.e., in the direction of the shortest dimension of the medium, >so that the value is independent of whether the printer feeds long edge or >short edge first. >The standard values are: >normal >res-100 >res-200 >res-240 >res-300 >res-600 >res-800 >res-1200 >res-1800 >res-100x200 >res-300x600 >res-600x300 >res-400x800 >res-800x400 >res-600x1200 >res-1200x600 >res-1800x600 > > > > From ipp-archive Thu Jun 5 15:23:22 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA27321 for ipp-outgoing; Thu, 5 Jun 1997 15:21:06 -0400 (EDT) Message-Id: <3.0.1.32.19970605121437.00b0f220@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 5 Jun 1997 12:14:37 PDT To: eschuman@cmp.com From: Carl-Uno Manros Subject: IPP> Your IPP article Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Evan, I wasn't too happy with your angle in reporting about IPP. You make it sound like we had insurmountable problems which will prevent us from making progress. I have been involved in a series of international standardization projects over the years, and can assure you that this "conflict" is no worse than a number other ones I have run across. I am confident that we will find a suitable compromise in this case as well. 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 Thu Jun 5 16:33:24 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA27884 for ipp-outgoing; Thu, 5 Jun 1997 16:30:45 -0400 (EDT) From: Harry Lewis To: Cc: Subject: IPP> PRO - Re: Print by reference Message-Id: <5030100003212718000002L082*@MHS> Date: Thu, 5 Jun 1997 16:32:36 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Carl-Uno, my apologies, I did not intend my submission to be a COMPLETE summary of all contributions (I left out many, like Roger deBry's comment that Print-by-Reference should be a base capability in IPP, Jeff Copeland's agreement thereto etc.). I was trying to characterize the status of the topic in a concise manner and suggest a kernel around which consensus might result. Since you reiterated your submission, however, it would be a disservice for me not to take this opportunity to comment further. >Print-by-reference is an optional feature like most other Printer features, >and from a protocol point of view it is not very different from whether a >printer can staple or not. It is true that that print-by-reference is more >likely to be supported by print-servers rather than by small printers, but >so what? When you ask the printer about its capabilities, it will tell you >whether it supports print-by-reference or not. Like support for multiple >documents in a job, you probably want to find out whether your printer >supports it, before blindly submitting a job. You use the word "optional" with some level of assurance, yet I believe this is the crux of the debate. Also, the mechanism for determining capabilities seems to be a bit more in question (query/submit vs. submit/monitor) than your writings would imply. >The limited functionality of SWP has little or nothing to do with the >print-by-reference discussion. The major limitations with SWP lie in the >fact that it does not support important functions such as Cancel job and >Get attributes, which are much more important. I disagree. As I saw it, in SanDiego, the two most significant limitations of SWP were lack of multi-documents per job and print-by-reference. SWP is mainly a submission protocol. There is firm ground to argue that a standard submission protocol should address these two items to some degree. It appeared to me that Paul was actually willing (and even offered a suggestion) to discuss handling multi-doc within the SWP framework, if we did not make it too difficult. (As I recall, his suggestion was to use a "multi-doc" job attribute and a specific URL that was expecting multiple docs per job). As chair, I would like to hear your reasoning as to why the IPP group denies the fact that submission should be your highest priority because there is a Printer MIB available for providing device capabilities and a job MIB for monitoring the job. Does IPP feel that they have failed if they do not provide a complete, end-to-end, all-in-one protocol? Are the Printer and Job MIBs useless in the IPP's eyes? I agree that Cancel is a very important function. I never agreed with the JMP that Cancel should be left out of the Job MIB. I would be glad to see it addressed in either the monitoring or submission protocols. >>> Harry <<< From ipp-archive Thu Jun 5 16:43:26 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA28362 for ipp-outgoing; Thu, 5 Jun 1997 16:42:26 -0400 (EDT) From: don@lexmark.com Message-Id: <199706052042.AA11206@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Thu, 5 Jun 1997 16:42:45 -0400 Subject: IPP> Conference Calls Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: bulk To: ipp@pwg.org cc: From: Don Wright @ LEXMARK@LEXMTA Date: 06/05/97 04:42:45 PM Subject: Conference Calls Here's the details on the conference calls for June 11th and June 18th. The dial-in number and access code are the same for both calls. Note: this is a new dial-in number but the access code is the same as always. It seems that AT&T is going to a new system so all the dial-in numbers are changing. Date: June 11th, June 18th Number: 1-423-523-7162 Time: 4PM EDT (1PM PDT) Callers: 20 caller limit Access Code: 190148 Have fun during my absence!! 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 Thu Jun 5 16:48:25 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA28475 for ipp-outgoing; Thu, 5 Jun 1997 16:47:57 -0400 (EDT) Message-Id: <199706052048.QAA13867@devnix.agranat.com> To: Harry Lewis , ipp@pwg.org Subject: Re: IPP> PRO - Re: Print by reference In-reply-to: <5030100003212718000002L082*@MHS> Date: Thu, 05 Jun 1997 16:48:54 -0400 From: "Scott Lawrence" Sender: ipp-owner@pwg.org Precedence: bulk >>>>> "HL" == Harry Lewis writes: HL> As chair, I would like to hear your reasoning as to why the IPP HL> group denies the fact that submission should be your highest HL> priority because there is a Printer MIB available for providing HL> device capabilities and a job MIB for monitoring the job. Surely you are not suggesting that an IPP client implementation must include SNMP as well as HTTP? If you thought you were getting resistance to layering IPP on HTTP... HL> Does IPP feel that they have failed if they do not provide a HL> complete, end-to-end, all-in-one protocol? For submission, including at least all negotiation required to ensure that the submission is acceptable - yes, certainly; anything less would be a failure. -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-archive Thu Jun 5 16:58:43 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA29119 for ipp-outgoing; Thu, 5 Jun 1997 16:56:48 -0400 (EDT) From: THERESA_RHOADES@HP-Boise-om8.om.hp.com X-Openmail-Hops: 1 Date: Thu, 5 Jun 97 14:52:08 -0600 Message-Id: In-Reply-To: <3.0.1.32.19970604112622.00910100@garfield> Subject: RE: IPP>PRO - Print by reference Mime-Version: 1.0 To: cmanros@cp10.es.xerox.com Cc: stephen_holmstead@hp.com, ipp@pwg.org Content-Type: text/plain; charset=US-ASCII; name="RE:" Content-Disposition: inline; filename="RE:" Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Carl, On 6/5/97 you wrote: >>an assumed restriction in the use of print-by-reference is that it would initially only support the retrieval of documents in print ready formats, such as Postscript or other PDL. What kind of driver requirements will this place on the source? The document provider will need to provide documents in every "print ready" format that may exist at that time- PostScript, PCL, PCL-XL, PDF, to name a few, and it will need to do this for every printer because as we know, practially every printer has a different print region, orientation, color space, etc. for which the specific PDL file will need to be formatted. This is basically why every printer has it's own driver or PPD file in the first place. If the owner of the document is concerned about the fidelity of the document with which they are trying to communicate information, this will place the burden on them for determining what and how many print drivers they will need to use. This is a somewhat exaggerated example but either way, it seems the requirement load for print by reference is going to have to increase (and potentially skyrocket) somewhere, either on the printer, or on the document provider. Theresa Rhoades Hewlett-Packard, Internet Solutions Operation theresa_rhoades@hp.com ______________________________ Reply Separator _________________________________ Subject: RE: IPP>PRO - Print by reference Author: Non-HP-cmanros (cmanros@cp10.es.xerox.com) at HP-Boise,mimegw7 Date: 6/4/97 12:26 PM At 10:00 AM 6/4/97 PDT, Stephen Holmstead wrote: >Print by reference is REALLY tough for the printer to do. Up until this >point, the printer only had to do http server capabilities (which can be >implemented fairly easily). However, print by reference now would require >the printer to implement http client capabilities (which is HUGE!!, not to >mention how unstable the client features are and the fact that the printer >most likely won't ever have a flash upgrade). What about all of the >embedded graphics files (gif, jpeg, pcx, tiff, etc.)? Does the printer >have to have code to convert all of these to printable output? What about >other files (.doc, .prz, .ppt, .xls, .mov, .avi, .pdf, etc.)? Does the >printer have to have code to handle all of these? What about plug-ins and >applets? Does the printer have to have a Java Virtual Machine to run Java >applets? The client (i.e. Browser) is quite large and has too many >features to be able to support by a printer. > >I have to strongly protest print by reference as it causes the requirement >load on the printer to skyrocket. >-- >Stephen Holmstead >Hewlett Packard Internet Solutions Operation >stephen_holmstead@hp.com > Stephen, an assumed restriction in the use of print-by-reference is that it would initially only support the retrieval of documents in print ready formats, such as Postscript or other PDL. Also, like most other features in IPP, a particular printer does not have to support this functionality. However, there is an increasing demand for this feature, (for example in print on demand scenarios) so we certainly want to keep the option in the specification, for people who may want to implement it. The most likely protocol for the actual retrieval is more likely to be FTP rather than HTTP, but we do not see a good reason to put any restrictions in the standard for this. Does this help you? 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 Jun 5 17:18:25 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA29812 for ipp-outgoing; Thu, 5 Jun 1997 17:15:23 -0400 (EDT) Message-Id: <199706052116.RAA13965@devnix.agranat.com> To: ipp@pwg.org Subject: Re: IPP>PRO - Print by reference In-reply-to: Date: Thu, 05 Jun 1997 17:16:35 -0400 From: "Scott Lawrence" Sender: ipp-owner@pwg.org Precedence: bulk >>>>> "TR" == Theresa Rhoades writes: CM> an assumed restriction in the use of print-by-reference is that it CM> would initially only support the retrieval of documents in print ready CM> formats, such as Postscript or other PDL. TR> What kind of driver requirements will this place on the source? The TR> document provider will need to provide documents in every "print TR> ready" format that may exist at that time- PostScript, PCL, PCL-XL, TR> PDF, to name a few, and it will need to do this for every printer TR> because as we know, practially every printer has a different print TR> region, orientation, color space, etc. for which the specific PDL file TR> will need to be formatted. Hmmm... are we beginning to understand why IETF insists that specs be available as flat text? [Sorry, I couldn't resist...] -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-archive Thu Jun 5 17:38:26 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA00338 for ipp-outgoing; Thu, 5 Jun 1997 17:33:28 -0400 (EDT) Message-ID: <339731D4.2CF6AC43@sharplabs.com> Date: Thu, 05 Jun 1997 14:38:29 -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: Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Precedence: bulk If someone makes a document publically available, then the author or person responsible for publishing this document as 'public' will make sure that it is in a form that is generalized in PDL (postscript, pcl, etc.) to print on the widest possible variety of devices. This is no different than what alot of document houses and computer systems vendors are doing by delivering alot of their document in postscript format on CDROM. While its true someone could generate a document using a printer driver with very odd characteristics, but if the author was truly interested in making this a public document, I doubt whether this would be the avenue that the author would choose for publication. Randy THERESA_RHOADES@HP-Boise-om8.om.hp.com wrote: > Carl, > > On 6/5/97 you wrote: > >>an assumed restriction in the use of print-by-reference is that > it > would initially only support the retrieval of documents in print > ready > formats, such as Postscript or other PDL. > > What kind of driver requirements will this place on the source? > The > document provider will need to provide documents in every "print > ready" format that may exist at that time- PostScript, PCL, > PCL-XL, > PDF, to name a few, and it will need to do this for every printer > > because as we know, practially every printer has a different > print > region, orientation, color space, etc. for which the specific PDL > file > will need to be formatted. This is basically why every printer > has > it's own driver or PPD file in the first place. If the owner of > the > document is concerned about the fidelity of the document with > which > they are trying to communicate information, this will place the > burden > on them for determining what and how many print drivers they will > need > to use. > > This is a somewhat exaggerated example but either way, it seems > the > requirement load for print by reference is going to have to > increase > (and potentially skyrocket) somewhere, either on the printer, or > on > the document provider. > > Theresa Rhoades > Hewlett-Packard, Internet Solutions Operation > theresa_rhoades@hp.com > > From ipp-archive Thu Jun 5 18:08:27 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA00909 for ipp-outgoing; Thu, 5 Jun 1997 18:04:54 -0400 (EDT) Message-Id: <9706052204.AA02916@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 5 Jun 1997 15:02:32 PDT To: Harry Lewis From: Tom Hastings Subject: Re: JMP> Re: IPP> MOD JobState suggestion Cc: , Sender: ipp-owner@pwg.org Precedence: bulk At 09:57 06/05/97 PDT, Harry Lewis wrote: >I don't want to begin making the diagram too complex. > >>> +--------->----------+------>------+--> canceled(7) >>> | | | >>> +---> pending(3) -------> processing(5) -------> completed(9) >>> | ^ ^ \ | >>> --->+ | | +------------> aborted(8) >>> | v v / | >>> +---> held(4) stopped(6) | > | | | > +--------->----------+------>------+ > >I only want to assure that the state diagram does not give the impression that, >to cancel or abort a job, the flow has to be back through processing. > >> +--> canceled(7) >> / >> +---> pending(3) ----> processing(5) -----+----> aborted(8) >> | ^ ^ \ >>--->+ | | +--> completed(9) >> | v | >> +---> held(4) processing-stopped(6) > > >What was wrong with my proposal? > >> +--> canceled(7) >> / >> +---> pending(3) ----> processing(5) ---+-+----> aborted(8) >> | ^ ^ | \ >>--->+ | | | +--> completed(9) >> | v v | >> +---> held(4) processing-stopped(6) | >> | | | >> +--------------------+---------+ >> > >>>> Harry <<< > > It shows state transitions that are very unlikely: held -> aborted held -> completed processing-stopped -> completed and it doesn't show pending -> canceled From ipp-archive Thu Jun 5 18:13:29 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA01113 for ipp-outgoing; Thu, 5 Jun 1997 18:11:05 -0400 (EDT) Date: Thu, 5 Jun 1997 15:09:12 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706052209.PAA16663@woden.eng.sun.com> To: hastings@cp10.es.xerox.com, Scott_Isaacson@novell.com, ipp@pwg.org, stanmcc@cp10.es.xerox.com Subject: Re: IPP> printer-resolution standard values retrograded X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk We consciously avoided having both a x and y printer resolution attributes. We didn't want a client or server to deal with all the impossible combinations of x and y. We believed that the number of combinations was sufficiently small that it was better to enumerate them. The supported values is then an accurate list, unlike the x-and-y solution where some combinations may be unsupported. Furthermore, a particular printer is unlikely to support more than a very few. How many do you think there are with current technology? 25? 50? What is the largest number any printer supports? 2? 3? I still think we make the correct choice. Bob Herriot > From stanmcc@cp10.es.xerox.com Thu Jun 5 12:12:50 1997 > > I have a couple of comments about printer-resolution. > > 1. The list is missing the multiples of 360 that are in fairly common use > in ink-jet printers. And most of these printers, if not all, can have a > 2-dimensional resolution, e.g., 360x720, ... , 720x1440, 1440x1440. So the > list needs to be expanded to cover these. > > 2. Given the potentially large list of 2d values, there is an mxn problem > here, in addition to the need to register every new value with IANA. It > seems more straightforward to simply replace the printer-resolution > attribute with two attributes, printer-x-resolution and > printer-y-resolution, each having an integer type which encodes the actual > resolution value. Then there is no need to register the values. > > We made the mistake in DPA of having only a single value to encode printer > resolution. I have submitted a defect report to ISO to correct the > problem, and I hope IPP will fix the problem as well. > > > > At 08:38 AM 6/5/97 PDT, Tom Hastings wrote: > >The 970512.doc had the following for printer-resolution, but the > >latest I-D 970603 has reverted to earlier text that didn't have any standard > >values listed. > > > >Did any other attributes retrograde? > > > >Tom > > > >6.2.12 printer-resolution (type2 keyword) > >This job attribute specifies the resolution that the Printer should use. > >The values are type2 keywords which represent single integers or pair of > >integers. The latter are to specify the resolution when the x and y > >dimensions differ. When two integers are specified, the first is in the x > >direction, i.e., in the direction of the shortest dimension of the medium, > >so that the value is independent of whether the printer feeds long edge or > >short edge first. > >The standard values are: > >normal > >res-100 > >res-200 > >res-240 > >res-300 > >res-600 > >res-800 > >res-1200 > >res-1800 > >res-100x200 > >res-300x600 > >res-600x300 > >res-400x800 > >res-800x400 > >res-600x1200 > >res-1200x600 > >res-1800x600 > > > > > > > > > > From ipp-archive Thu Jun 5 18:28:26 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA02157 for ipp-outgoing; Thu, 5 Jun 1997 18:27:12 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 05 Jun 1997 16:26:54 -0600 From: Scott Isaacson To: eschuman@cmp.com, cmanros@cp10.es.xerox.com Cc: ipp@pwg.org Subject: Re: IPP> Your IPP article Sender: ipp-owner@pwg.org Precedence: bulk Evan, I too share Carl-Uno's concerns about the "angle" of the article, especially the implications of words such as "unravel". As I said on the phone during our interview, I expect the standards process (working group participation and discussion) to yield a consensus decision in a timely manner that results in the best possible standard for Internet Printing. With diligent participation, I have faith in the process. As you correctly represented, I have confidence that we can reach a consensus decision in the time frame outlined in the schedule in the working group's charter. As an example of the controversial nature of your article, you state "A tentative deal worked out with the companies began to fall apart when the participants divided into two factions -- one lead by Microsoft, in Redmond, Wash., and the other by Novell, in Orem, Utah, meeting participants said." I made a strong statement in the discussion that you refer to that a successful standard, "simple" standard, should not have multiple levels of conformance. It is interesting that it can be construed as the "dividing of companies into two factions." Especially since 1) I represent my own personal opinion and not that of my company, and 2) there were no idividuals involved in that immediate phone discussion representing their personal opinions who work for Microsoft. Everyone has their own strong personal positions, but the job is to learn to synergistically resolve issues. A lot has happened since the original printing proposal by Xerox and Novell and the associated Novell sponsored press release back in November. There has been a lot of good input and comment from many participants. I am proud to be a part of the working group and I am happy to take a very active role. In my own mind, it is now an open working group initiative not a company sponsored initiative. I am actually very pleased (and surprised in some ways) as to how far we have come and the many good agreements that have been made to date. Scott Isaacson ************************************************************ Scott A. Isaacson Print Services Consulting Engineer Novell Inc., 122 E 1700 S, Provo, UT 84606 V: (801) 861-7366, (800) 453-1267 x17366 F: (801) 861-4025, E: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ >>> Carl-Uno Manros 06/05 1:14 PM >>> Evan, I wasn't too happy with your angle in reporting about IPP. You make it sound like we had insurmountable problems which will prevent us from making progress. I have been involved in a series of international standardization projects over the years, and can assure you that this "conflict" is no worse than a number other ones I have run across. I am confident that we will find a suitable compromise in this case as well. 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 Thu Jun 5 18:33:26 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA02183 for ipp-outgoing; Thu, 5 Jun 1997 18:29:42 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 05 Jun 1997 16:28:26 -0600 From: Scott Isaacson To: hastings@cp10.es.xerox.com, ipp@pwg.org Subject: IPP> Re: printer-resolution standard values retrograded Sender: ipp-owner@pwg.org Precedence: bulk The draft had a very lengthy list of values for some of the attributes. I thought it was more important at this stage to get out a newly formatted version of the model document rather than take the time to enumerate the all of the values in this version. Read nothing more into their absence as just not included yet rather than excluded with a reason never to be included again. Sorry for the confusion. Scott >>> Tom Hastings 06/05 9:38 AM >>> The 970512.doc had the following for printer-resolution, but the latest I-D 970603 has reverted to earlier text that didn't have any standard values listed. Did any other attributes retrograde? Tom 6.2.12 printer-resolution (type2 keyword) This job attribute specifies the resolution that the Printer should use. The values are type2 keywords which represent single integers or pair of integers. The latter are to specify the resolution when the x and y dimensions differ. When two integers are specified, the first is in the x direction, i.e., in the direction of the shortest dimension of the medium, so that the value is independent of whether the printer feeds long edge or short edge first. The standard values are: normal res-100 res-200 res-240 res-300 res-600 res-800 res-1200 res-1800 res-100x200 res-300x600 res-600x300 res-400x800 res-800x400 res-600x1200 res-1200x600 res-1800x600 From ipp-archive Thu Jun 5 18:44:02 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA02978 for ipp-outgoing; Thu, 5 Jun 1997 18:42:16 -0400 (EDT) Date: Thu, 5 Jun 1997 15:43:36 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706052243.PAA16705@woden.eng.sun.com> To: ipp@pwg.org, szilles@Adobe.COM Subject: Re: IPP> PRO - A value-type field for the Protocol Spec proposal X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk > From szilles@Adobe.COM Wed Jun 4 19:31:54 1997 > > It is proposed that there be a registry of value types. The first two > entries in that registry would be (zero is reserved) > > 1: Unicode string in UTF8 encoding (as specified in the draft) > 2: list of values (here the length of the value field determines how > many values are present. The length, however, is not the number of > value, but the number of bytes consumed by the values. > Do you think that we should specify the encoding of a list of values? For example, it could be zero or more nested values, that is: value-type value-length value Also, are you suggesting that we define some other types, such as integer or date, even if these are represented as a Unicode string in UTF-8. Bob Herriot From ipp-archive Thu Jun 5 19:43:27 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA03656 for ipp-outgoing; Thu, 5 Jun 1997 19:41:02 -0400 (EDT) Message-Id: <199706052351.SAA03254@spica.LaserMaster.Com> Subject: Re: IPP> printer-resolution standard values retrograded Date: Thu, 5 Jun 97 18:40:28 -0500 x-mailer: Claris Emailer 1.1 From: Dave Polaschek To: "Robert Herriot" , , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: ipp-owner@pwg.org Precedence: bulk I'd like to add my comments about printer resolution. I don't have a good solution, and I'm sorry if some of this has been covered before. 1. Any [reasonable] enumerated list is going to be lacking resolutions supported by existing printers. A type3 or type4 keyword is more appropriate than a type2 keyword. 2. Having only a one-dimensional resolution, even with provisions for two-number resolutions spooks me. Having worked for a company that's made many printers with non-square resolution, and gotten burned by far too many applications assuming the wrong thing has made me gun-shy. Specifying resolutions as an integer-pair in all cases tends to prod more people into using both values. 3. Not all printer resolutions are integral. I don't think this is a huge issue, but I mention it lest people forget. 4. I'm a little nervous about the phrase: > When two integers are specified, the first is in the x > direction, i.e., in the direction of the shortest dimension > of the medium, so that the value is independent of whether > the printer feeds long edge or short edge first. which doesn't seem to account for the case of a roll or cut-sheet-fed printer. As an example, take a printer which has different x and y resolutions, and supports cut-sheet media of a size sufficently large that a user can mount a letter page in either of two orientations. When you ask for the resolution of the printer, do you want the answer to change based on which paper orientation is being used? I believe that always specifying two-dimensional resolution is good, and stating that the first resolution is in the direction of head travel, and the second in the direction of paper-travel (or similar wording that's marking-engine-based, and not media-orientation-based) would make for a better description of printer resolution. -DaveP Dave Polaschek -- Mac Guy -- LaserMaster Corp -- davep@leonardo.lmt.com ----------------------------------------------------------------------- >We consciously avoided having both a x and y printer resolution >attributes. We didn't want a client or server to deal with all the >impossible combinations of x and y. We believed that the number of >combinations was sufficiently small that it was better to enumerate >them. The supported values is then an accurate list, unlike the x-and-y >solution where some combinations may be unsupported. Furthermore, a >particular printer is unlikely to support more than a very few. > >How many do you think there are with current technology? 25? 50? >What is the largest number any printer supports? 2? 3? > >I still think we make the correct choice. > >Bob Herriot >> From stanmcc@cp10.es.xerox.com Thu Jun 5 12:12:50 1997 >> >> I have a couple of comments about printer-resolution. >> >> 1. The list is missing the multiples of 360 that are in fairly common use >> in ink-jet printers. And most of these printers, if not all, can have a >> 2-dimensional resolution, e.g., 360x720, ... , 720x1440, 1440x1440. So the >> list needs to be expanded to cover these. >> >> 2. Given the potentially large list of 2d values, there is an mxn problem >> here, in addition to the need to register every new value with IANA. It >> seems more straightforward to simply replace the printer-resolution >> attribute with two attributes, printer-x-resolution and >> printer-y-resolution, each having an integer type which encodes the actual >> resolution value. Then there is no need to register the values. >> >> We made the mistake in DPA of having only a single value to encode printer >> resolution. I have submitted a defect report to ISO to correct the >> problem, and I hope IPP will fix the problem as well. >> >> >> >> At 08:38 AM 6/5/97 PDT, Tom Hastings wrote: >> >The 970512.doc had the following for printer-resolution, but the >> >latest I-D 970603 has reverted to earlier text that didn't have any standard >> >values listed. >> > >> >Did any other attributes retrograde? >> > >> >Tom >> > >> >6.2.12 printer-resolution (type2 keyword) >> >This job attribute specifies the resolution that the Printer should use. >> >The values are type2 keywords which represent single integers or pair of >> >integers. The latter are to specify the resolution when the x and y >> >dimensions differ. When two integers are specified, the first is in the x >> >direction, i.e., in the direction of the shortest dimension of the medium, >> >so that the value is independent of whether the printer feeds long edge or >> >short edge first. From ipp-archive Thu Jun 5 19:58:29 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA04145 for ipp-outgoing; Thu, 5 Jun 1997 19:54:55 -0400 (EDT) Message-Id: <9706052355.AA03022@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 5 Jun 1997 16:52:37 PDT To: Ron Bergman From: Tom Hastings Subject: Re: JMP> Re: IPP> MOD JobState suggestion Cc: Harry Lewis , ipp@pwg.org, jmp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk Sounds simpler. So how is this for JMP: JmJobStateTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The current state of the job (pending, processing, completed, etc.). The following figure shows the normal job state transitions: +--> canceled(7) / +---> pending(3) --------> processing(5) -----+----> completed(9) | ^ ^ \ --->+ | | +--> aborted(8) | v v / +---> pendingHeld(4) processingStopped(6) --+ <--------------- active -----------------> <--- in-active ---> Figure 4 - Normal Job State Transitions Normally a job progresses only from left to right. Other state transitions are unlikely, but are not forbidden. The canceled state can be entered from the pending, pendingHeld, processing, or processingStopped states." -- This is a type 2 enumeration. See Section 7.1 on page 25. SYNTAX INTEGER { other(1), At 10:05 06/05/97 PDT, Ron Bergman wrote: >Tom, > >I agree that you new revised figure is correct. But it has so >many lines and lines crossing that I doubt it is useful. > >I propose that we keep the original figure, but show the two paths >to "Aborted", with the added text: > >"The Canceled state can be entered from the Pending, Pending-Held, >Processing, or Processing-Stopped states." > > > Ron Bergman > Dataproducts Corp. > > >On Thu, 5 Jun 1997, Tom Hastings wrote: > >> I agree that canceled can be entered from any state and that a system >> might (but need not) abort a stopped job. >> >> The definition of the aborted state for IPP and JMP supports your >> idea with the weasil word "usually" in the definition: >> >> aborted: >> The job has been aborted by the system, usually while the job was in the >> processing state. >> >> So how does this picture look to you for IPP and JMP (IPP wouldn't >> have the enums and wouldn't have the "active/in-active" line, since >> it is a JMP-only term). >> >> Running arrows from every state to canceled and from stopped to >> aborted would look like this: >> >> >> +--------->----------+------>------+--> canceled(7) >> >> | | | >> >> +---> pending(3) -------> processing(5) -------> completed(9) >> >> | ^ ^ \ | >> >> --->+ | | +------------> aborted(8) >> >> | v v / | >> >> +---> held(4) stopped(6) | >> | | | >> +--------->----------+------>------+ >> >> >> >> <-------------- active ------------>|<-- in-active -->| >> >> >> >> Is this figure ok? > > > From ipp-archive Thu Jun 5 20:03:31 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA04396 for ipp-outgoing; Thu, 5 Jun 1997 20:01:33 -0400 (EDT) From: Harry Lewis To: Cc: Subject: Re: IPP> PRO - Re: Print by reference Message-Id: <5030100003221276000002L062*@MHS> Date: Thu, 5 Jun 1997 20:03:19 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Scott Lawrance said: > Surely you are not suggesting that an IPP client implementation must > include SNMP as well as HTTP? If you thought you were getting > resistance to layering IPP on HTTP... No, I was suggesting the IPP client would include SNMP as well as IPP. It's everyone trying to squeeze through the same hole in the firewall which is causing HTTP to enter the conversation. If IPP is to layer on HTTP, they why not SNMP. I'm sure it has already been done. >HL> Does IPP feel that they have failed if they do not provide a >HL> complete, end-to-end, all-in-one protocol? > For submission, including at least all negotiation required to > ensure that the submission is acceptable - yes, certainly; anything > less would be a failure. I'm curious why you have not included Job Monitoring and Cancel? >>> Harry Lewis <<< From ipp-archive Thu Jun 5 20:08:29 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA04739 for ipp-outgoing; Thu, 5 Jun 1997 20:06:15 -0400 (EDT) Date: Thu, 5 Jun 1997 20:06:24 -0400 (EDT) From: JK Martin Message-Id: <199706060006.UAA26703@uscore.underscore.com> To: lawrence@agranat.com Subject: Re: IPP> PRO - Re: Print by reference Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk > Surely you are not suggesting that an IPP client implementation must > include SNMP as well as HTTP? If you thought you were getting > resistance to layering IPP on HTTP... Are you suggesting that submitting a job using one protocol--but using a *completely* different protocol to monitor the status--is not a very good thing to do? ...jay From ipp-archive Thu Jun 5 20:33:28 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA05748 for ipp-outgoing; Thu, 5 Jun 1997 20:30:32 -0400 (EDT) Message-Id: <199706060033.RAA17906@scv3.apple.com> Subject: Re: IPP> PRO - A value-type field for the Protocol Spec proposa Date: Thu, 5 Jun 97 17:30:55 -0700 x-sender: brian@mail.apple.com x-mailer: Claris Emailer 1.1 From: Brian Grimshaw To: "Stephen Zilles" cc: , "Brian Grimshaw" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: ipp-owner@pwg.org Precedence: bulk Stephen, To test my understanding of your concern, I summarize the two problems you address in the form of objectives. * The first is to distinguish two attributes that have the same name -- the example you give is "address". * The second is a representation of attributes that consist of multiple pieces of information (sub-attributes) that can be easily distinguished. I think the first goal is best achieved by having meaningful names for attributes. The human readable form of attributes is already a reason for meaningful names and all attributes are specified as having a type. For example, there are attributes for "job-originating-host" and "job-originating-user" which are both 'names'. It is unlikely that both of these (or either of these) would be called "name" and, similarly, it is unlikely that shipping address would be called "address". In this example, "address" is best considered the attribute type and "ship-to" could be an attribute of type 'address'. The second goal seems to be (almost) handled by the sentence in the HTTP 1.1 Transport Mapping document that says "An attribute whose value is a set of n values shall be represented as a sequence of n attributes, where all but the first attribute have a name of zero length." This specific representation could be debated, but if simplified to not have the restriction of zero length attribute names for all but the first attribute, then this would permit an arbitrary hierarchy of attributes. This syntax would be represented as: attribute = name-length name value-length value ... value = octet-string | attribute The implicit type of an attribute is sufficient to know if it has a value of multiple attributes. There IS a goal I can think of (not to suggest this should be a goal) that would justify your proposed solution. If you want to be able to programmatically process (perhaps in a UI application) a set of attributes, you would need the type information to be explicitly represented -- but you would not need to know the attribute names. The meaning of an attribute value would still require a priori knowledge of the attribute name, but much can be done without that. If this is not intended, I see the value-type as redundant. If this is intended, I suggest that all types (as specified in IPP) be represented. Brian Grimshaw Apple Computer, Inc. brian@apple.com >The Problem Statement > >To avoid vague generalizations, lets consider an example that I believe >is likely to arise in the near future. On attribute one might want to >add is an "address". For example, one might have an address to which the >final output is to be mailed or shipped. One might also have an address >to which the bill for reproduction is to be sent. This brings our first >problem because, quite often, these two addresses are not the same. >That means that we need two different address attributes. > >The second problem with addresses is that an address is a structured >entity. It has things like a mailstop, a street number, a street name, a city >sub-region identifier, a city identifier, a state and/or country >identifier and, typically, some kind of ZIPcode. These are assembled >into an address, but they are assembled in different ways in different >cultures and countries. This means that treating the address as a single >character string makes it very difficult to accurately recover the >information in the address. It makes more sense to store the address as >a structured objects with attributes and values for each of the >component parts. But, the address (as a whole) is the value of the >shipping address or billing address attribute identified above. The >current proposal for IPP does not allow a value to be structured. ... >A Proposed Solution > >The proposed solution to the extensibility problem is to add a type byte >(or half word) to the value portion of the value portion of the >attribute-value pair. This would change the syntax in Randy's recent >draft as follows: > >attribute = name-length name value-type value-length value >... >value-type = one-byte integer ; a registered type value >value-length = three-byte integer ; number of octets in value >value = octet-string > >Note that the length was increased to three bytes to allow for larger >structured values and was (arbitrarily) made three bytes so that the >combination of value-type and value-length takes four bytes. > >It is proposed that there be a registry of value types. The first two >entries in that registry would be (zero is reserved) > >1: Unicode string in UTF8 encoding (as specified in the draft) >2: list of values (here the length of the value field determines how > many values are present. The length, however, is not the number of > value, but the number of bytes consumed by the values. From ipp-archive Thu Jun 5 20:48:28 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA06236 for ipp-outgoing; Thu, 5 Jun 1997 20:46:54 -0400 (EDT) Date: Thu, 5 Jun 1997 20:47:13 -0400 (EDT) From: JK Martin Message-Id: <199706060047.UAA28465@uscore.underscore.com> To: ipp@pwg.org Subject: IPP> Common concerns regarding the SWP proposal X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk After many private phone calls and email messages with several IPP participants--including a 1.5 hour phone call with Evan Schuman regarding his "Internet Printing Deal Unravels" article--it was suggested that I be the sacrificial lamb and ask the $64K question: "So what's wrong with the SWP proposal from Microsoft and HP?" The concerns I have heard from multiple IPP participants include the following (in no particular order): 1. Does not support multiple documents 2. Does not support Print-by-Reference 3. Does not support job status queries 4. Does not support job cancellation by the requesting user 5. Uses binary-encoded data for simple information normally encoded in text for HTTP-related transactions There may be more concerns floating around, but these appear to be the Top 5 that consistently arise in conversations. We need to resolve the issue of whether: - The SWP proposal should represent THE final IPP specification, or - The SWP proposal represents "Level 1" conformance to an IPP spec having two conformance levels, or - The SWP proposal is inadequate and should be abandoned in favor of a single conformance level represented by the existing documents The purpose of this message is to get these concerns out on the table NOW so that we can resolve them as quickly as possible. (Please don't flame at me for this message...wait until I state my opinions... ;-) There has been considerable traffic on the list regarding the concern for the lack of Print-by-Reference. Let's get discussion started on the other concerns. Incidentally, more than one participant made a statement to this effect: "If two conformance levels are specified--yet Microsoft only implements the low-end Level 1 spec--then it is pointless for us to work on a Level 2 implementation given current and past market dynamics. "Therefore, we should stop further IPP development and simply bless the SWP proposal and run with it, since it will be the only pervasive implementation in the marketplace, anyway." Your comments to this statement are also encouraged, whether pro or con. ...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 Thu Jun 5 21:08:28 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA06733 for ipp-outgoing; Thu, 5 Jun 1997 21:05:11 -0400 (EDT) Message-ID: <33976247.1B22@parc.xerox.com> Date: Thu, 5 Jun 1997 18:05:11 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: Neil Joffe CC: Dan Wing , MUTZ@hpl.hp.com, MONTULLI@netscape.com, ipp@pwg.org Subject: IPP> Re: draft-mutz-http-attributes-02.txt References: <2.2.32.19970605175933.009361e8@quisp.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk IPP, FAX, and HTTP need to know about resolution of the recipient device; I don't think we need three different ways to deal with it. Why not just be straightforward and specify resolution in two directions as integers or rationals? Larry -- http://www.parc.xerox.com/masinter From ipp-archive Thu Jun 5 21:13:34 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA06953 for ipp-outgoing; Thu, 5 Jun 1997 21:11:45 -0400 (EDT) Date: Thu, 5 Jun 1997 18:12:12 -0700 (PDT) From: Ron Bergman To: Tom Hastings cc: Harry Lewis , ipp@pwg.org, jmp@pwg.org Subject: Re: JMP> Re: IPP> MOD JobState suggestion In-Reply-To: <9706052355.AA03022@zazen.cp10.es.xerox.com> Message-ID: X-X-Sender: rbergma@it.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Tom, Looks good. Any objections from anyone else? Ron Bergman On Thu, 5 Jun 1997, Tom Hastings wrote: > Sounds simpler. So how is this for JMP: > > JmJobStateTC ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "The current state of the job (pending, processing, completed, etc.). > > The following figure shows the normal job state transitions: > > +--> canceled(7) > / > +---> pending(3) --------> processing(5) -----+----> completed(9) > | ^ ^ \ > --->+ | | +--> aborted(8) > | v v / > +---> pendingHeld(4) processingStopped(6) --+ > > <--------------- active -----------------> <--- in-active ---> > Figure 4 - Normal Job State Transitions > > Normally a job progresses only from left to right. Other state transitions > are unlikely, but are not forbidden. The canceled state can be entered from > the pending, pendingHeld, processing, or processingStopped states." > > -- This is a type 2 enumeration. See Section 7.1 on page 25. > SYNTAX INTEGER { > other(1), > > > At 10:05 06/05/97 PDT, Ron Bergman wrote: > >Tom, > > > >I agree that you new revised figure is correct. But it has so > >many lines and lines crossing that I doubt it is useful. > > > >I propose that we keep the original figure, but show the two paths > >to "Aborted", with the added text: > > > >"The Canceled state can be entered from the Pending, Pending-Held, > >Processing, or Processing-Stopped states." > > > > > > Ron Bergman > > Dataproducts Corp. > > > > From ipp-archive Thu Jun 5 22:03:29 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA08137 for ipp-outgoing; Thu, 5 Jun 1997 21:59:21 -0400 (EDT) From: Andy Mutz Message-Id: <199706060201.TAA15013@hplumen.cup.hp.com> Subject: IPP> Re: draft-mutz-http-attributes-02.txt To: masinter@parc.xerox.com (Larry Masinter) Date: Thu, 05 Jun 1997 19:01:49 PDT Cc: njoffe@cisco.com, dwing@cisco.com, MUTZ@hplms26.hpl.hp.com, MONTULLI@netscape.com, ipp@pwg.org In-Reply-To: <33976247.1B22@parc.xerox.com>; from "Larry Masinter" at Jun 5, 97 6:05 pm Reply-to: andy_mutz@hp.com Organization: Hewlett-Packard Laboratories, Palo Alto, California X-Mailer: Elm [revision: 212.2] Sender: ipp-owner@pwg.org Precedence: bulk I prefer not burdening all apps with 2 resolution numbers when most use square resolutions. Once way around this: Specify "res" to mean horizontal resolution and add "res-vert" to indicate vertical resolution. If only res is indicated, then a client could assume square pixels. I think this is sufficiently straightfoward. Comment? Andy > > IPP, FAX, and HTTP need to know about resolution of the recipient > device; I don't think we need three different ways to deal with it. > > Why not just be straightforward and specify resolution in two > directions as integers or rationals? > > Larry > -- > http://www.parc.xerox.com/masinter > -- --------------------------------------------------------------- Andrew Mutz | email: andy_mutz@hp.com Internet Imaging Operation | Phone: +1 408 447 4439 Internet Technology Group | Page: +1 800 607 9639 11000 Wolfe Road 42UO | Cupertino, California, USA. | Radio: KF6FUT --------------------------------------------------------------- From ipp-archive Thu Jun 5 22:28:29 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA08622 for ipp-outgoing; Thu, 5 Jun 1997 22:24:30 -0400 (EDT) Date: Thu, 5 Jun 1997 19:23:32 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706060223.TAA17184@woden.eng.sun.com> To: masinter@parc.xerox.com, andy_mutz@hp.com Subject: Re: IPP> Re: draft-mutz-http-attributes-02.txt Cc: njoffe@cisco.com, dwing@cisco.com, MUTZ@hplms26.hpl.hp.com, MONTULLI@netscape.com, ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk None of these solutions solve the problem of the Printer's resolutions-supported attribute which, hopefully, tells the client exactly what resolutions the Printer supports without any extraneous values and without a complicated structure for the attribute. Bob Herriot > From mutz@hplumen.cup.hp.com Thu Jun 5 19:07:24 1997 > > I prefer not burdening all apps with 2 resolution numbers when most > use square resolutions. > > Once way around this: Specify "res" to mean horizontal resolution and > add "res-vert" to indicate vertical resolution. > > If only res is indicated, then a client could assume square pixels. > > I think this is sufficiently straightfoward. Comment? > > Andy > > > > > > IPP, FAX, and HTTP need to know about resolution of the recipient > > device; I don't think we need three different ways to deal with it. > > > > Why not just be straightforward and specify resolution in two > > directions as integers or rationals? > > > > Larry > > -- > > http://www.parc.xerox.com/masinter > > > > > -- > --------------------------------------------------------------- > Andrew Mutz | email: andy_mutz@hp.com > Internet Imaging Operation | Phone: +1 408 447 4439 > Internet Technology Group | Page: +1 800 607 9639 > 11000 Wolfe Road 42UO | > Cupertino, California, USA. | Radio: KF6FUT > --------------------------------------------------------------- > From ipp-archive Thu Jun 5 22:33:34 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA08879 for ipp-outgoing; Thu, 5 Jun 1997 22:31:15 -0400 (EDT) Message-ID: <33977670.39E7@parc.xerox.com> Date: Thu, 5 Jun 1997 19:31:12 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: Robert Herriot CC: andy_mutz@hp.com, njoffe@cisco.com, dwing@cisco.com, MUTZ@hplms26.hpl.hp.com, MONTULLI@netscape.com, ipp@pwg.org Subject: Re: IPP> Re: draft-mutz-http-attributes-02.txt References: <199706060223.TAA17184@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk > None of these solutions solve the problem of the Printer's > resolutions-supported attribute which, hopefully, tells the > client exactly what resolutions the Printer supports without > any extraneous values and without a complicated structure > for the attribute. I think this is the same problem fax has, though. Why would a list of pairs of integers (x-res/y-res) or integer & ratio (x-res, aspect ratio) have 'extraneous values'? Or be a 'complicated structure'? -- http://www.parc.xerox.com/masinter From ipp-archive Thu Jun 5 22:38:30 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA09111 for ipp-outgoing; Thu, 5 Jun 1997 22:35:11 -0400 (EDT) Message-ID: <33977754.22C4@parc.xerox.com> Date: Thu, 5 Jun 1997 19:35:00 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: Stephen Zilles CC: ipp@pwg.org Subject: Re: IPP> PRO - A value-type field for the Protocol Spec proposal References: <199706050223.TAA20533@bulletin> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk # Alternative Solutions Personally, I think you should consider the following two possible solutions if you want extensibility and the possibility of nested structures: a) use ASN.1. Right now, you're on the verge of reinventing it. b) use XML. It requires a (simple) parser, but it seems to be useful for encoding arbitrary length strings, nested structures, etc. Larry -- http://www.parc.xerox.com/masinter From ipp-archive Fri Jun 6 10:23:37 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA11266 for ipp-outgoing; Fri, 6 Jun 1997 10:21:23 -0400 (EDT) Message-Id: <199706061420.KAA14441@devnix.agranat.com> To: ipp@pwg.org Subject: Re: IPP>PRO - Print by reference In-reply-to: <338F369B.35D7@parc.xerox.com> Date: Fri, 06 Jun 1997 10:20:37 -0400 From: "Scott Lawrence" Sender: ipp-owner@pwg.org Precedence: bulk >>>>> "LM" == Larry Masinter writes: LM> I think that you might want to allow a 'reference' LM> to be a compound attribute consisting of a URL (the LM> location of the referenced resource) and the credentials LM> (the authority by which the reference is being accessed), Without quoting all of it, I agree completely with Larrys suggestion to formulate print-by-reference to allow including 'transferable' credentials (there are security schemes out there that include such things). If there are no credentials supplied, the request degenerates to my suggestion that the printer provide credentials of its own, etc... -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-archive Fri Jun 6 10:23:38 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA11275 for ipp-outgoing; Fri, 6 Jun 1997 10:21:29 -0400 (EDT) Message-Id: <199706061419.KAA14423@devnix.agranat.com> To: ipp@pwg.org Subject: Re: IPP> PRO - Re: Print by reference In-reply-to: <199706060006.UAA26703@uscore.underscore.com> Date: Fri, 06 Jun 1997 10:19:24 -0400 From: "Scott Lawrence" Sender: ipp-owner@pwg.org Precedence: bulk SL> Surely you are not suggesting that an IPP client implementation must SL> include SNMP as well as HTTP? If you thought you were getting SL> resistance to layering IPP on HTTP... >>>>> "JK" == JK Martin : JK> Are you suggesting that submitting a job using one protocol--but using JK> a *completely* different protocol to monitor the status--is not a very JK> good thing to do? >>>>> "HL" == Harry Lewis : HL> No, I was suggesting the IPP client would include SNMP as well as IPP. It's HL> everyone trying to squeeze through the same hole in the firewall which is HL> causing HTTP to enter the conversation. If IPP is to layer HL> on HTTP, they why not SNMP. I'm sure it has already been done. There have been a couple of proposals for layering SNMP over HTTP and/or mapping SNMP operations to URLs. There is no standard for either, however. Perhaps I should have been more explicit: Requiring the use of two protocols to solve one problem, whether or not they are both layered over a third protocol, is a Bad Idea. The essential issue here is one of complexity; I believe that what IPP is attempting to do is define a the operations for submitting and user-level control of print jobs. The MIBs (which I have not studied) should be designed to support _Management_ (the 'M') - which is to say monitoring and control, usually by a third party (neither the printer nor the user of the printer). The requirements for operation and management are different, and I don't think that it helps either effort to combine them. It certainly isn't good design (IMHO) to require both MIME/HTTP parsers and ASN1/SNMP parsers just to submit a job to a printer. -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-archive Fri Jun 6 11:18:37 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA12310 for ipp-outgoing; Fri, 6 Jun 1997 11:17:45 -0400 (EDT) From: jeff@boulder.qms.com (Jeff Copeland) Message-Id: <9706061516.AA05460@boulder.qms.com> Subject: Re: IPP> ADM - IPP in the News To: cmanros@cp10.es.xerox.com (Carl-Uno Manros) Date: Fri, 6 Jun 1997 09:16:31 -0600 (MDT) Cc: ipp@pwg.org In-Reply-To: <3.0.1.32.19970605101854.00aed980@garfield> from "Carl-Uno Manros" at Jun 5, 97 10:18:54 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: ipp-owner@pwg.org Precedence: bulk Carl-Uno Manros wrote, > > Techwire has just put out an article about IPP. > > The reference is: > > http://www.techweb.com/wire/news/june/0605print.html > I'm amused that among it's other faults the Techwire article has Carl-Uno holding the position of "principle engineer", a position I think is somewhat akin to being a lawyer or politician. -- 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 Fri Jun 6 11:43:37 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA12809 for ipp-outgoing; Fri, 6 Jun 1997 11:40:59 -0400 (EDT) Message-Id: <3.0.1.32.19970606083440.00b1d3d0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 6 Jun 1997 08:34:40 PDT To: Scott Isaacson From: Carl-Uno Manros Subject: Re: IPP> Your IPP article 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 At 03:26 PM 6/5/97 PDT, Scott Isaacson wrote: >Evan, > >I too share Carl-Uno's concerns about the "angle" of the article, especially >the implications of words such as "unravel". > >As I said on the phone during our interview, I expect the standards process >(working group participation and discussion) to yield a consensus decision >in a timely manner that results in the best possible standard for Internet >Printing. With diligent participation, I have faith in the process. As you >correctly represented, I have confidence that we can reach a consensus >decision in the time frame outlined in the schedule in the working group's >charter. > >As an example of the controversial nature of your article, you state >"A tentative deal worked out with the companies began to fall apart >when the participants divided into two factions -- one lead by >Microsoft, in Redmond, Wash., and the other by Novell, in Orem, >Utah, meeting participants said." > >I made a strong statement in the discussion that you refer to that a >successful standard, "simple" standard, should not have multiple levels of >conformance. It is interesting that it can be construed as the "dividing of >companies into two factions." Especially since 1) I represent my own >personal opinion and not that of my company, and 2) there were no idividuals >involved in that immediate phone discussion representing their personal >opinions who work for Microsoft. Everyone has their own strong personal >positions, but the job is to learn to synergistically resolve issues. > >A lot has happened since the original printing proposal by Xerox and Novell >and the associated Novell sponsored press release back in November. There >has been a lot of good input and comment from many participants. I am proud >to be a part of the working group and I am happy to take a very active role. > In my own mind, it is now an open working group initiative not a company >sponsored initiative. I am actually very pleased (and surprised in some >ways) as to how far we have come and the many good agreements that have been >made to date. > >Scott Isaacson > Scott, thanks for writing this letter to Evan. I fully agree with it. I sent back the following short reply to him yesterday: Evan, thanks for taking the time to write me, appreciated. You are right that most of the article gave a correct and accurate description of where we are standing, the main trouble I had was with the headline and the hints which seemed to indicate that there was major trouble ahead, which I saw as an exaggeration. 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 Jun 6 12:28:38 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA13380 for ipp-outgoing; Fri, 6 Jun 1997 12:25:30 -0400 (EDT) Message-Id: <2.2.32.19970606162506.0094bb44@quisp.cisco.com> X-Sender: njoffe@quisp.cisco.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 06 Jun 1997 09:25:06 -0700 To: andy_mutz@hp.com, masinter@parc.xerox.com (Larry Masinter) From: Neil Joffe Subject: IPP> Re: draft-mutz-http-attributes-02.txt Cc: dwing@cisco.com, MUTZ@hplms26.hpl.hp.com, MONTULLI@netscape.com, ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk At 07:01 PM 6/5/97 PDT, Andy Mutz wrote: >I prefer not burdening all apps with 2 resolution numbers when most >use square resolutions. > >Once way around this: Specify "res" to mean horizontal resolution and >add "res-vert" to indicate vertical resolution. OK or res-x, res-y so that we have pix-x, pix-y, res-x, res-y > >If only res is indicated, then a client could assume square pixels. > >I think this is sufficiently straightfoward. Comment? OK. btw, there is a slightly different isssue with fax: pix-x will be specified, but pix-y may not. In this case, you cannot assume pix-y and pix-x are equal. Many fax machines are designed to scale the image if you send them images longer than the page they are printing on. > >Andy > > >> >> IPP, FAX, and HTTP need to know about resolution of the recipient >> device; I don't think we need three different ways to deal with it. >> >> Why not just be straightforward and specify resolution in two >> directions as integers or rationals? >> >> Larry >> -- >> http://www.parc.xerox.com/masinter >> > > >-- >--------------------------------------------------------------- >Andrew Mutz | email: andy_mutz@hp.com >Internet Imaging Operation | Phone: +1 408 447 4439 >Internet Technology Group | Page: +1 800 607 9639 >11000 Wolfe Road 42UO | >Cupertino, California, USA. | Radio: KF6FUT >--------------------------------------------------------------- > > ------------------------------------------------------------------------ Neil Joffe Email: njoffe@cisco.com Software Engineer Voice: +1 (408) 527-7957 Voice Technology Engineering Fax: +1 (408) 527-3907 Cisco Systems San Jose ------------------------------------------------------------------------ From ipp-archive Fri Jun 6 12:33:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA13711 for ipp-outgoing; Fri, 6 Jun 1997 12:33:06 -0400 (EDT) From: Andy Mutz Message-Id: <199706061635.JAA15432@hplumen.cup.hp.com> Subject: IPP> Re: draft-mutz-http-attributes-02.txt To: njoffe@cisco.com (Neil Joffe) Date: Fri, 06 Jun 1997 9:35:42 PDT Cc: andy_mutz@hp.com, masinter@parc.xerox.com, dwing@cisco.com, MUTZ@hplms26.hpl.hp.com, MONTULLI@netscape.com, ipp@pwg.org In-Reply-To: <2.2.32.19970606162506.0094bb44@quisp.cisco.com>; from "Neil Joffe" at Jun 06, 97 9:25 am Reply-to: andy_mutz@hp.com Organization: Hewlett-Packard Laboratories, Palo Alto, California X-Mailer: Elm [revision: 212.2] Sender: ipp-owner@pwg.org Precedence: bulk Neil Joffe wrote: > At 07:01 PM 6/5/97 PDT, Andy Mutz wrote: > >I prefer not burdening all apps with 2 resolution numbers when most > >use square resolutions. > > > >Once way around this: Specify "res" to mean horizontal resolution and > >add "res-vert" to indicate vertical resolution. > > OK or res-x, res-y > > so that we have pix-x, pix-y, res-x, res-y I'm satisfied either way; the point was to clarify which res (x or y) to use for square resolutions to avoid having to negotiate over both. This precedence seems clearer with res and res-y than with res-x and res-y. Comments? > > > > >If only res is indicated, then a client could assume square pixels. > > > >I think this is sufficiently straightfoward. Comment? > > OK. > > btw, there is a slightly different isssue with fax: pix-x will be specified, > but pix-y may not. In this case, you cannot assume pix-y and pix-x are > equal. Many fax machines are designed to scale the image if you send them > images longer than the page they are printing on. This is an unrelated issue, but I understand. Since each feature is independently negotiated, there is no problem specifying available values of pix-x and not specifying pix-y. Andy. -- --------------------------------------------------------------- Andrew Mutz | email: andy_mutz@hp.com Internet Imaging Operation | Phone: +1 408 447 4439 Internet Technology Group | Page: +1 800 607 9639 11000 Wolfe Road 42UO | Cupertino, California, USA. | Radio: KF6FUT --------------------------------------------------------------- From ipp-archive Fri Jun 6 12:48:38 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA14364 for ipp-outgoing; Fri, 6 Jun 1997 12:48:28 -0400 (EDT) Message-Id: <3.0.1.32.19970606094212.00b83a50@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 6 Jun 1997 09:42:12 PDT To: Paul Moore From: Carl-Uno Manros Subject: IPP> PRO - Re: Updated document Cc: ipp@pwg.org In-Reply-To: <41135C785691CF11B73B00805FD4D2D702B7CE67@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 Hi, I just a copy from Paul Moore updating the earlier version of SWP, now called IPP Level 1. The document is on our FTP server under new_PRO and is called: ipp-level1-95.rft ipp-level1-95.txt 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 Fri Jun 6 13:13:39 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA15081 for ipp-outgoing; Fri, 6 Jun 1997 13:13:15 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 06 Jun 1997 10:42:28 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - 6/6 Telecon Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk I have made arrangements for a Model subgroup telecon Friday June 6 2:00 pm - 4:00 pm Mountain 800-600-5302 code: 346463 Agenda: 1. Job State and Job State Reasons 2. Presentation of attributes in the Model document - separate doc? - lists of keyword values 3. Run through the remaining issues in the document Scott Isaacson ************************************************************ Scott A. Isaacson Print Services Consulting Engineer Novell Inc., 122 E 1700 S, Provo, UT 84606 V: (801) 861-7366, (800) 453-1267 x17366 F: (801) 861-4025, E: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Fri Jun 6 13:48:39 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA15808 for ipp-outgoing; Fri, 6 Jun 1997 13:44:49 -0400 (EDT) From: Harry Lewis To: Cc: Subject: IPP> Common concerns regarding the SWP proposal Message-Id: <5030100003249286000002L062*@MHS> Date: Fri, 6 Jun 1997 13:46:58 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Jay - thank you for providing the framework that will enable us to FOCUS discussion of SWP as it relates to the IPP goals. I am one, as you mentioned, who encourages this, not because I want a "battle" to ensue, but because I think a *short* concise list of issues will help us visualize, prioritize and respond to the existing proposals. >We need to resolve the issue of whether: > > - The SWP proposal should represent THE final IPP specification, or > > - The SWP proposal represents "Level 1" conformance to an IPP spec > having two conformance levels, or > > - The SWP proposal is inadequate and should be abandoned in favor > of a single conformance level represented by the existing documents This is a good way to represent the choices regarding SWP and IPP. I, personally, recall Microsoft repeatedly saying they do not intend SWP as the "end all" IPP protocol. Rather, my interpretation was that Microsoft was putting some "meat" behind the revolving discussions in IPP regarding use of HTTP, number of URLs, submission methods etc. so, I would favor your middle choice or perhaps a slightly different phrasing ... "Treat SWP as the Simple IPP Submission protocol and document separate methods for query and cancel." Of course, this implies that concerns such as multi-doc and print-by-reference have been adequately resolved. As so frequently occurs, "Simple" is a keyword in the Microsoft proposal, so we should not expect it to solve every possible problem or scenario we can imagine for internet printing. My impression, in SanDiego, was that Microsoft appeared willing to address some of the concerns (endian-ness, compatible proposals for multi-doc etc.) but, like anyone who feels they have a sufficient architecture, were protective of the fundamental design decisions which have allowed them to keep it Simple and make it real. Let's not forget that, in SanDiego, Microsoft presented SWP as an initial, *timely* step toward print job submission via the interent, *not* as the total solution to a complete, robust IPP protocol. >The concerns I have heard from multiple IPP participants include the >following (in no particular order): > > 1. Does not support multiple documents > > 2. Does not support Print-by-Reference > > 3. Does not support job status queries > > 4. Does not support job cancellation by the requesting user > > 5. Uses binary-encoded data for simple information normally encoded > in text for HTTP-related transactions If this list *does* represent the entire scope of *key* issues, then, at least, we know our points of interest, and IPP can decide whether to build the roadmap starting with SWP or take a separate route. Thanks, again, Jay, for setting this "Common Concerns" thread in motion. >>> Harry Lewis <<< From ipp-archive Fri Jun 6 13:58:39 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA16317 for ipp-outgoing; Fri, 6 Jun 1997 13:58:27 -0400 (EDT) Message-Id: <9706061756.AA03301@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, 6 Jun 1997 10:54:07 PDT To: ipp@pwg.org, Brian Grimshaw From: Tom Hastings Subject: Re: IPP> PRO - A value-type field for the Protocol Spec proposa Cc: "Stephen Zilles" Sender: ipp-owner@pwg.org Precedence: bulk I agree with Steve's suggestion to add a data type code to the encoding of attributes in IPP and Brian's feedback. We have concluded an internal review of IPP at Xerox, and adding a data type code was the most important issue raised. We have had a year and a half experience with an ASCII encoded attribute representation that includes the data type. In our implementation, the data type was a keyword too, but a data type code is sufficient for IPP, where each of the data type keywords is assigned a one-octet code. I don't think we need to assign new data type codes for binary integer though. We need to keep the data types as simple and small in number as possible. The main reason that we included the data type is that it makes the implementation of the parser on the recipient much easier while allowing the parser to unmarshall the protocol into the internal representation of the machine and present an internal API that uses the binary machine and programming-langauge dependent data types, rather than keeping everything in string form. Such a parser does not need to keep a list of attribute names and their corresponding data types in order to know how to parse the value. These ideas have been included in the OMG Print Facility submission by Xerox and others date June 2, 1997. We have included the IPP job attributes in the submission, generalized by changing "printer" to "device" in the attribute names, since the OMG Print Facility is intended to be extended to other types of services, such as scan, FAX, and document distribution. The URL for the document: ftp://www.omg.org/pub/docs/cf/97-06-03.doc As Steve and Brian point out, one of the side benefits to adding a data type code, is that one of the types can be "set-of-attributes" meaning that the value is a set of attributes. The length of the top level attribute is the length of the entire attribute set, as usual. Inside that attribute value is the usual syntax for a set of attributes: attribute name data-type value, including multiple values for any individual attribute using the zero-length of the attribute-name field. Then the shipping-address attribute example can be handled using this new data type, and the value is a set of attributes for the fields in the address. With such a data type, it greatly reduces the need to introduce other adhoc explicit data types or structures that contain fields. IPP V2.0 will need the ability to define attributes whose values are sets of attributes to facilitate the administrative specification of the Printer. For example, expressing attribute constraints between attributes is an example of use of the mechanism, such as can't staple transparencies or can't staple more than 50 sheets. Implementations that don't support the attributes that have values that are sets of attributes ignore the attribute entirely as currently and are unaffected by the addition of this one new data type, since the length of the top level value is the entire length and the implementation just ignores the entire (top level) attribute. See explicit comments on Steve's proposal about the data type codes and registry at the end of this message. Thanks, Tom At 17:30 06/05/97 PDT, Brian Grimshaw wrote: >Stephen, > >To test my understanding of your concern, I summarize the two problems >you address in the form of objectives. > >* The first is to distinguish two attributes that have the same name -- >the example you give is "address". > >* The second is a representation of attributes that consist of multiple >pieces of information (sub-attributes) that can be easily distinguished. > >I think the first goal is best achieved by having meaningful names for >attributes. The human readable form of attributes is already a reason >for meaningful names and all attributes are specified as having a type. >For example, there are attributes for "job-originating-host" and >"job-originating-user" which are both 'names'. It is unlikely that both >of these (or either of these) would be called "name" and, similarly, it >is unlikely that shipping address would be called "address". In this >example, "address" is best considered the attribute type and "ship-to" >could be an attribute of type 'address'. > >The second goal seems to be (almost) handled by the sentence in the HTTP >1.1 Transport Mapping document that says "An attribute whose value is a >set of n values shall be represented as a sequence of n attributes, where >all but the first attribute have a name of zero length." This specific >representation could be debated, but if simplified to not have the >restriction of zero length attribute names for all but the first >attribute, then this would permit an arbitrary hierarchy of attributes. >This syntax would be represented as: > >attribute = name-length name value-length value >... >value = octet-string | attribute > >The implicit type of an attribute is sufficient to know if it has a value >of multiple attributes. > > >There IS a goal I can think of (not to suggest this should be a goal) >that would justify your proposed solution. If you want to be able to >programmatically process (perhaps in a UI application) a set of >attributes, you would need the type information to be explicitly >represented -- but you would not need to know the attribute names. The >meaning of an attribute value would still require a priori knowledge of >the attribute name, but much can be done without that. > >If this is not intended, I see the value-type as redundant. If this is >intended, I suggest that all types (as specified in IPP) be represented. > >Brian Grimshaw >Apple Computer, Inc. >brian@apple.com > > >>The Problem Statement >> >>To avoid vague generalizations, lets consider an example that I believe >>is likely to arise in the near future. On attribute one might want to >>add is an "address". For example, one might have an address to which the >>final output is to be mailed or shipped. One might also have an address >>to which the bill for reproduction is to be sent. This brings our first >>problem because, quite often, these two addresses are not the same. >>That means that we need two different address attributes. >> >>The second problem with addresses is that an address is a structured >>entity. It has things like a mailstop, a street number, a street name, a city >>sub-region identifier, a city identifier, a state and/or country >>identifier and, typically, some kind of ZIPcode. These are assembled >>into an address, but they are assembled in different ways in different >>cultures and countries. This means that treating the address as a single >>character string makes it very difficult to accurately recover the >>information in the address. It makes more sense to store the address as >>a structured objects with attributes and values for each of the >>component parts. But, the address (as a whole) is the value of the >>shipping address or billing address attribute identified above. The >>current proposal for IPP does not allow a value to be structured. > >... > >>A Proposed Solution >> >>The proposed solution to the extensibility problem is to add a type byte >>(or half word) to the value portion of the value portion of the >>attribute-value pair. This would change the syntax in Randy's recent >>draft as follows: >> >>attribute = name-length name value-type value-length value >>... >>value-type = one-byte integer ; a registered type value >>value-length = three-byte integer ; number of octets in value >>value = octet-string >> >>Note that the length was increased to three bytes to allow for larger >>structured values and was (arbitrarily) made three bytes so that the >>combination of value-type and value-length takes four bytes. I don't think that we need to increase the length beyond two octets. That is 64K of octets! >> >>It is proposed that there be a registry of value types. The first two >>entries in that registry would be (zero is reserved) >> >>1: Unicode string in UTF8 encoding (as specified in the draft) >>2: list of values (here the length of the value field determines how >> many values are present. The length, however, is not the number of >> value, but the number of bytes consumed by the values. > I would suggest that instead the registry would be the list of current data type keywords (page 31-33 of the line numbered I-D) with one new type: attributeSet: 1: other 2: text 3: name 4: fileName 5: keyword 6: uri 7: uriScheme 8: locale 9: octetString 10: booolean 11: integer 12: dateTime 13: seconds 14: milliseconds 15: integerUnits 16: rangeOfInteger 17: attributeSet The two constructed data types of: 1setOf X rangeOf X need some discussion. I don't think that we need a type code for 1setOf X, since we use the zero-length attribute-name to represent multiple values in a set of values. Currently the number of different X that use rangeOf X from the table on page 36 is only rangeOf int, so I put that one in explicitly. If there are other ranges needed, we can add them explicitly or use the attribute set approach. Tom From ipp-archive Fri Jun 6 14:13:39 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA16860 for ipp-outgoing; Fri, 6 Jun 1997 14:11:06 -0400 (EDT) Message-Id: <9706061811.AA03314@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, 6 Jun 1997 11:08:46 PDT To: ipp@pwg.org, Robert.Herriot@Eng.Sun.COM (Robert Herriot) From: Tom Hastings Subject: Re: IPP> PRO - A value-type field for the Protocol Spec proposal Cc: szilles@Adobe.COM Sender: ipp-owner@pwg.org Precedence: bulk At 15:43 06/05/97 PDT, Robert Herriot wrote: > >> From szilles@Adobe.COM Wed Jun 4 19:31:54 1997 >> >> It is proposed that there be a registry of value types. The first two >> entries in that registry would be (zero is reserved) >> >> 1: Unicode string in UTF8 encoding (as specified in the draft) >> 2: list of values (here the length of the value field determines how >> many values are present. The length, however, is not the number of >> value, but the number of bytes consumed by the values. >> > I think that we should assign data type codes to each of the current IPP Model data type keywrods and then add just one more data type keyword: attributeSet to the Model and assign it a code as well. >Do you think that we should specify the encoding of a list of values? >For example, it could be zero or more nested values, that is: > > value-type value-length value No, lets keep our current agreements on encoding a single multiple-valued attribute, using the zero-length attribute-name approach. We need to build on the agreements we've reach, rather than keep changing them. > >Also, are you suggesting that we define some other types, such as integer >or date, even if these are represented as a Unicode string in UTF-8. I suggest that we don't add redundant represenetations. Lets have only one way to encode each data type. We might want to encode the current Model octetString data type as binary only, but the rest should remain in UTF-8. Having the data type code would let us have a binary representation, but only for the very few data types where there isn't a good UTF-8 representation. We could also choose to encode the current Model dateTime data type as binary, using some existing standard. That might help with the localization of dates and times and the time zone problem. However, if there is a standard for the representation of dates and time in printable form, including time zones, I suggest that we stick with printable dateTime. Lets avoid binary in the procotol as much as possible and use binary only when there isn't a simple and useful UTF-8 representation. BTW - the dateTime data type needs to cite such a standard in either the Model document or at least the protocol document. I perfer the Model document. > >Bob Herriot > > From ipp-archive Fri Jun 6 14:28:39 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA17559 for ipp-outgoing; Fri, 6 Jun 1997 14:27:29 -0400 (EDT) Message-Id: <9706061827.AA03327@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, 6 Jun 1997 11:25:13 PDT To: ipp@pwg.org, JK Martin From: Tom Hastings Subject: Re: IPP> Common concerns regarding the SWP proposal Sender: ipp-owner@pwg.org Precedence: bulk Jay, Thanks for raising the issues about SWP. Here are my comments. Tom At 17:47 06/05/97 PDT, JK Martin wrote: >After many private phone calls and email messages with several IPP >participants--including a 1.5 hour phone call with Evan Schuman >regarding his "Internet Printing Deal Unravels" article--it was >suggested that I be the sacrificial lamb and ask the $64K question: > > "So what's wrong with the SWP proposal from Microsoft and HP?" > >The concerns I have heard from multiple IPP participants include the >following (in no particular order): > > 1. Does not support multiple documents > > 2. Does not support Print-by-Reference > > 3. Does not support job status queries > > 4. Does not support job cancellation by the requesting user No problem with not having any of the above in the lowest level (or in SWP). You don't get any of the above with current Windows printing and it hasn't cause customers to not use Windows. As Babak and Keith said, SWP is only the first step which takes the current Windows printing paradigm and puts it on the Internet. > > 5. Uses binary-encoded data for simple information normally encoded > in text for HTTP-related transactions This decision is perhaps not the best, but its not a show stopper. Lets not use it as a "wedge" issue to abandon the agreements in San Diego. > >There may be more concerns floating around, but these appear to be the >Top 5 that consistently arise in conversations. > >We need to resolve the issue of whether: > > - The SWP proposal should represent THE final IPP specification, or > > - The SWP proposal represents "Level 1" conformance to an IPP spec > having two conformance levels, or > > - The SWP proposal is inadequate and should be abandoned in favor > of a single conformance level represented by the existing documents > >The purpose of this message is to get these concerns out on the table >NOW so that we can resolve them as quickly as possible. (Please don't >flame at me for this message...wait until I state my opinions... ;-) > >There has been considerable traffic on the list regarding the concern >for the lack of Print-by-Reference. Let's get discussion started on >the other concerns. > >Incidentally, more than one participant made a statement to this effect: > > "If two conformance levels are specified--yet Microsoft only implements > the low-end Level 1 spec--then it is pointless for us to work on a > Level 2 implementation given current and past market dynamics. > > "Therefore, we should stop further IPP development and simply bless > the SWP proposal and run with it, since it will be the only pervasive > implementation in the marketplace, anyway." Maybe I'm naive, but I think that Microsoft will support full IPP in their follow on release. Its just a matter of timing. Had we had IPP all done and the NT 5.0 development group had the resources, they would have put full IPP into NT 5.0. Basically, the NT strategy is to keep adding functionality. Why do you think that Microsoft would stop with SWP? Any system that can't cancel a job is not going to be viable in the market place very long. So Microsoft will be forced into doing more in the future by their customer base (and IPP). I look at SWP as being half full, not half empty. SWP makes IPP more real, rather than detracting from IPP. Carl-Uno made the suggestion that maybe SWP could be a separate informational RFC (from Microsoft or from the PWG, TBD), which is a subset of IPP. Then IPP could avoid having two conformance levels, if we cannot agree to have two conformance levels. > >Your comments to this statement are also encouraged, whether pro or con. > > ...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 Jun 6 14:33:42 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA17662 for ipp-outgoing; Fri, 6 Jun 1997 14:33:10 -0400 (EDT) Message-ID: <33985928.B33D3C9A@sharplabs.com> Date: Fri, 06 Jun 1997 11:38:32 -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 - A value-type field for the Protocol Spec X-Priority: 3 (Normal) References: <9706061811.AA03314@zazen.cp10.es.xerox.com> Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Precedence: bulk Prior to the San Diego meeting, I proposed using ASN.1 as a way to specify the protocol. This was to prevent us from having to "re-invent" the wheel with regards to our protocol specification. The nice thing about ASN.1 (and its companion BER) is that extensibility is easily achieved and with more flexibility than what has been proposed so far. I think Larry Masinter brought up the fact that ASN.1 might be a better approach, and if extensibility and clarity of specification is what is driving these recent discussions, then I'm curious why we are striving so hard to reinvent another way to do this. Randy From ipp-archive Fri Jun 6 15:08:40 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA18826 for ipp-outgoing; Fri, 6 Jun 1997 15:06:47 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 06 Jun 1997 13:06:37 -0600 From: Scott Isaacson To: ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP> PRO - A value-type field for the Protocol Spec Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk I am sure that ASN.1 does NOT stand for "A Simple Notation One"?? ;-) And BER, wasn't that "Binary Encoding for computing Resource consumption"?? ASN.1/BER is way too heavy for IPP. If we are too close to reinventing ASN.1 then we are way too heavy for IPP. Much of the discussion recently has been around "simplicity". Has IPP lost it ability to be simple? No, I don't think it has. Is it too convoluted in some areas - YES. There was a discussion a few weeks ago about whether IPP was DPA '97. This reminder was a good wake-up call, and useful in that there seemed to be immediate consensus that IPP is not intended to be too complex like DPA is considered to be. I vote keep it simple. Add value-types only if it is a value or keyword that represents a specific well know syntax as described in the standard (extensible through registration). But don't add arbitrarily extsensible, compound data structures as potential values. And don't use ASN.1 !! Scott >>> Randy Turner 06/06 12:38 PM >>> Prior to the San Diego meeting, I proposed using ASN.1 as a way to specify the protocol. This was to prevent us from having to "re-invent" the wheel with regards to our protocol specification. The nice thing about ASN.1 (and its companion BER) is that extensibility is easily achieved and with more flexibility than what has been proposed so far. I think Larry Masinter brought up the fact that ASN.1 might be a better approach, and if extensibility and clarity of specification is what is driving these recent discussions, then I'm curious why we are striving so hard to reinvent another way to do this. Randy From ipp-archive Fri Jun 6 15:33:50 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA19416 for ipp-outgoing; Fri, 6 Jun 1997 15:30:56 -0400 (EDT) Message-Id: <9706061931.AA03384@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: Fri, 6 Jun 1997 12:28:45 PDT To: jmp@pwg.org, ipp@pwg.org From: Tom Hastings Subject: IPP> Issues and agenda for job-state and job-state-reasons for today's telecon, Fri, 6/6, 1-3pm PDT (4-6 EDT) Sender: ipp-owner@pwg.org Precedence: bulk Agenda for job-state and job-state-reasons part of today's telecon. 1. Is the updated text for IPP and JMP ok? 2. Names of the state agreed? (not exactly as in the minutes)? (can we just simplify the names to the last word in the hyphendated names?) 3. in-coming and out-going issue 4. any other problems with the rest of the specification sent out for the 6/4 telecon: jobstate.pdf. Here is Scott's complete agenda: Friday June 6 2:00 pm - 4:00 pm Mountain 800-600-5302 code: 346463 Agenda: 1. Job State and Job State Reasons 2. Presentation of attributes in the Model document - separate doc? - lists of keyword values 3. Run through the remaining issues in the document Scott Isaacson Joint IPP/JMP ISSUE - Should in-coming and out-going jobs be in 'pending' or 'processing' states? In the IPP 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'. In the "job-state" definition, 'job-outgoing' is in the 'processing' state, while the "job-state-reasons" definition says that 'job-outgoing' shall be in the 'pending' state. Which do we want the IPP and JMP spec to say? Do we agree on the following state transition diagrams: The corresponding IPP text will be: 6.3.2.5 job-state (type1 keyword) This attribute identifies the current state of the job. The Printer may provide additional information about each state value by supplying one or more values of the job's companion "job-state-reasons" attribute depending on implementation. While the job states cannot be added to without impacting deployed clients that take actions upon receiving job state values, it is the intent that additional "job-state-reasons" values can be defined without impacting such deployed clients. In other words, the "job-state-reasons" attribute is intended to be extensible. Standard values are: unknown The job state is not known, or its state is indeterminate. pending The job is a candidate to start processing, but is not yet processing. pending-held The job is not a candidate for processing for any number of reasons and will resume pending as soon as the reasons are no longer present. The job's "job-state-reason" attribute shall indicate why the job is no longer a candidate for processing. processing Either:1. the job is using, or is attempting to use, one or more document transforms which include (1) purely software processes that are interpreting a PDL, and (2) hardware devices that are interpreting a PDL, making marks on a medium, and/or performing finishing, such as stapling OR 2. the server has made the job ready for printing, but the output device is not yet printing it, either because the job hasn't reached the output device or because the job is queued in the output device or some other spooler, awaiting the output device to print it. ISSUE: The "job-state-reasons" specification is that the job is in 'pending' state not 'processing' state.When the job is in the 'processing' state, the entire job state includes the detailed status represented in the printer's "printer-state", "printer-state-reasons", and "printer-state-message attributes.Implementations may include additional values in the job's "job-state-reasons" attribute to indicate the progress of the job, such as adding the 'job-printing' value to indicate when the output device is actually making marks on paper. Most implementations won't bother with this nuance. processing-stopped The job has stopped while processing for any number of reasons and will continue processing as soon as the reasons are no longer present. The job's "job-state-reason" attribute shall indicate why the job has stopped processing.If the output device is stopped, the 'printer-stopped' value shall be included in the job's "job-state-reasons" attribute. When the output device is stopped, the device usually indicates its condition in human readable form locally at the device. A client can obtain more complete device status remotely by querying the printer's "printer-state-reasons" attribute. canceled The job has been canceled by a Cancel-Job operation and is either (1) in the process of terminating or (2) has completed terminating. The job's "job-state-reasons" attribute shall contain either the 'canceled-by-user' or 'canceled-by-operator' value. aborted The job has been aborted by the system, usually while the job was in the 'processing' state. completed The job has completed successfully or with warnings or errors and all of the job media sheets have been properly stacked in the appropriate output tray or bin. The job's "job-state-reasons" attribute shall contain one of: 'completed-successfully', 'completed-with-warnings', or 'completed-with-errors'. The length of time that jobs remain in the 'canceled', 'aborted', and 'completed' states depends on implementation. 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 through three states. Even though the IPP protocol defines seven values for job states, Printers SHALL only implement those states which are appropriate for the particular implementation. For JMP: JmJobStateTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The current state of the job (pending, processing, completed, etc.). The following figure shows the normal job state transitions: +--> canceled(7) / +---> pending(3) --------> processing(5) -----+----> completed(9) | ^ ^ \ --->+ | | +--> aborted(8) | v v / +---> pendingHeld(4) processingStopped(6) --+ <-------------- active -----------------> <-- in-active --> Figure 4 - Normal Job State Transitions Normally a job progresses only from left to right. Other state transitions are unlikely, but are not forbidden. The canceled state can be entered from the pending, pendingHeld, processing, or processingStopped states." -- This is a type 2 enumeration. See Section 7.1 on page 25. SYNTAX INTEGER { other(1), -- The job state is not one of the defined states. unknown(2), ---- The job state is not known, or its state is indeterminate. pending(3), ---- The job is waiting to start processing, but is not yet processing. pendingHeld(4), ---------------------- The job is not yet a candidate for processing for any number of reasons and will resume pending as soon as the reasons are no longer present. The reasons are represented as bits in the jobStateReasons1 object and/or jobStateReasonsn (n=2..4) attribute. Some reasons are used in other states to give added information about the job state. See the JmJobStateReasonsnTC (n=1..4) textual convention for the specification of each reason and in which states the reasons are intended to be used. processing(4), -- -------------------------------------------------------------------- Either: 1. The job is using, or is attempting to use, one or more document transforms which include (1) purely software processes that are interpreting a PDL, and (2) hardware devices that are interpreting a PDL, making marks on a medium, and/or performing finishing, such as stapling OR2. (configuration 2) the server has made the job ready for printing, but the output device is not yet printing it, either because the job hasn't reached the output device or because the job is queued in the output device or some other spooler, awaiting the output device to print it. ISSUE: The definitions of job-outgoing say that the job state is 'pending', not 'processing'. Can we remove paragraph 2 about from the definition of the 'processing' state?When the job is in the processing state, the entire job state includes the detailed status represented in the device MIB indicated by the hrDeviceIndex value of the job's physicalDevice attribute.Implementations MAY, though they NEED NOT, include additional values in the job's jmJobStateReasons1 object to indicate the progress of the job, such as adding the jobPrinting value to indicate when the device is actually making marks on paper. processingStopped(7), -- ------------------------------------ The job has stopped while processing for any number of reasons and will continue processing as soon as the reasons are no longer present. The job's jmJobStateReasons1 object and/or the job's jobStateReasonsn (n=2..4) attributes SHOULD indicate why the job has stopped processing. For example, if the output device is stopped, the deviceStopped value SHOULD be included in the job's jmJobStateReasons1 object. NOTE - When an output device is stopped, the device usually indicate its condition in human readable form locally at the device. The management application can obtain more complete device status remotely by querying the appropriate device MIB using the job's deviceIndex attribute(s). canceled(5), -- ------------ The job is in the process of being terminated by the server or device or has completed terminating the job, because a client canceled the job. The job's jobStateReasons1 attribute SHOULD contain either the canceledByUser or canceledByOperator value. aborted(6) -- ---- The job has been aborted by the system, usually while the job was in the processing state. completed(7) -- ------------ The job has completed successfully or with warnings or errors after processing and all of the media have been successfully stacked in the output bin(s). The job's jobStateReasons1 attribute SHOULD contain one of: completedSuccessfully, completedWithWarnings, or completedWithErrors. } From ipp-archive Fri Jun 6 15:38:52 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA19685 for ipp-outgoing; Fri, 6 Jun 1997 15:37:58 -0400 (EDT) Message-Id: <9706061937.AA03396@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, 6 Jun 1997 12:35:34 PDT To: ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: IPP> Updated IPP state transition diagram Sender: ipp-owner@pwg.org Precedence: bulk I forgot to update the IPP part in my previous message. It should be: 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-held processing-stopped Figure 1 - Normal job state transitions Normally a job progresses only from left to right through three states. The canceled state can be entered from the pending, pendingHeld, processing, or processingStopped states. Even though the IPP protocol defines seven values for job states, Printers SHALL only implement those states which are appropriate for the particular implementation. Tom From ipp-archive Fri Jun 6 15:44:09 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA20078 for ipp-outgoing; Fri, 6 Jun 1997 15:42:35 -0400 (EDT) Date: Fri, 6 Jun 1997 12:42:43 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706061942.MAA17806@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, masinter@parc.xerox.com Subject: Re: IPP> Re: draft-mutz-http-attributes-02.txt Cc: andy_mutz@hp.com, njoffe@cisco.com, dwing@cisco.com, MUTZ@hplms26.hpl.hp.com, MONTULLI@netscape.com, ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk > From masinter@parc.xerox.com Thu Jun 5 19:32:57 1997 > > > None of these solutions solve the problem of the Printer's > > resolutions-supported attribute which, hopefully, tells the > > client exactly what resolutions the Printer supports without > > any extraneous values and without a complicated structure > > for the attribute. > > I think this is the same problem fax has, though. > Why would a list of pairs of integers (x-res/y-res) > or integer & ratio (x-res, aspect ratio) have 'extraneous > values'? Or be a 'complicated structure'? > If there are attributes x-res and y-res, then according to the IPP model, there must be an x-res-supported and a y-res-supported in the Printer. Suppose the printer supports 300 and 300x600 and 600 Then both x-res-supported and y-res-supported have values of 300 and 600. Then x-res and y-res can have any of the following 4 values 300x300, 300x600, 600x600 and 600x300. The last value is not a legitimate value according to my original statement. It may be that resolutions supported by real printers and all future printers can never have this problem. For example if the values are 300 and 300x600, then x-res-supported is 300 and y-res-supported is 300 and 600. No illegal combinations are possible with these values. That's the problem I have with the x-res, y-res solution. If you can show my that this solution cannot lead to unsupported combinations, then I would agree that a pair of integers is possibly a better solution. Bob Herriot From ipp-archive Fri Jun 6 15:48:47 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA20216 for ipp-outgoing; Fri, 6 Jun 1997 15:43:59 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 06 Jun 1997 13:43:05 -0600 From: Scott Isaacson To: ipp@pwg.org, jkm@underscore.com Subject: Re: IPP> Common concerns regarding the SWP proposal Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk Good summary Jay.. ************************************************************ 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 06/05 6:47 PM >>> > 1. Does not support multiple documents No mandatory support for all implementations. Add a simple attribute to the printer that is a boolean "multiple-documents-supported" = True or False. If False, expect an error code back on Create-Job or Send-Document. Maybe even put this in the directroy schema. Do end users want to find printers that can print multiple documents per job? I don't know. > 2. Does not support Print-by-Reference Add s simple attribute to the printer that says "print-by-reference-supported" = True or False. If False, don't expect a URL as document content to work. If True, what gets printed is what gets printed no guarantee and if you send in an FTP URL and the given instance of a Printer does not support it, you get an error message. > 3. Does not support job status queries Has always sounded to me like a basic query to a Printer or a Job is essential. I believe this is fundamental. Sure, you could always do a GET on a url with an accept header of text/html and get back a browser view, but this need not be a requirement. SWP does not mandate that this be a requirement. However, a requirement would be to support an POST with an application/ipp PDU in it. The number of MANDATORY requirements is SO small here, I don't see a problem with supporting the operation for all implemntations given that you have a web server already (doing the GET accepting text/html that is). > 4. Does not support job cancellation by the requesting user Seems fundamental to me. If you support an HTML form version of this, it would be like litterally 10 lines of code to add the POST application/IPP version. > 5. Uses binary-encoded data for simple information normally encoded > in text for HTTP-related transactions In our prototype, we just finished up a Java application that tried to process attributes encoded as: namevalue (case 2) rather than as name ":" value CRLF (case 1) We ran both versions on 3 attributes, 30 attributes, and 300 attributes. The goal was to measure the actuall difference in processing time for a dumb, interpreted java application to do one or the other. The times seem slow (we just did a quick an dirty hack with no optimizations, kept the buffering I/O the same, just modified the algorithm) Encoding 30 attributes (varying name lengths, varying value lenghts), 50 runs, avg. Case 1: .1375 seconds Case 2: .1525 seconds Decoding 30 attributes (varying name lengths, varying value lenghts), 50 runs, avg. Case 1: .0975 seconds Case 2: .0825 seconds Sure enough, case 2 was "quicker" but as been said many times before: "This is printing we are talking about, and at MOST 30 attributes we are talking about" Ease of use and extensibility and portability etc are so much easier with a non-binary encoding of lengths. It just doesn't buy you very much. Interesting node, encoding actually took longer with case 2? You actually have to compute the length in order to encode the length! Looking at both sides (encoder/decoder), it seems to come out a wash with binary encoding or not. The point in posting this data is not to get into a war about "we'll I could do it faster ..." but just to look at the RELATIVELY MINOR overhead of 30 attributes compared to a 4 meg color RIP process!!! Please, let's not have two conformance levels. Let's NOT force everyone to do do everything, but let's not fragement the standard. We have all failed if we do. Scott Isaacson From ipp-archive Fri Jun 6 16:13:42 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA22168 for ipp-outgoing; Fri, 6 Jun 1997 16:09:57 -0400 (EDT) Message-Id: <199706062008.NAA15908@scv2.apple.com> Subject: Re: IPP> PRO - A value-type field for the Protocol Spec Date: Fri, 6 Jun 97 13:10:02 -0700 x-sender: brian@mail.apple.com x-mailer: Claris Emailer 1.1 From: Brian Grimshaw To: , "Randy Turner" cc: "Scott Isaacson" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: ipp-owner@pwg.org Precedence: bulk I agree with Scott... >I am sure that ASN.1 does NOT stand for "A Simple Notation One"?? ;-) >And BER, wasn't that "Binary Encoding for computing Resource consumption"?? > >ASN.1/BER is way too heavy for IPP. If we are too close to reinventing >ASN.1 >then we are way too heavy for IPP. >... > >Scott ...and have an additional observation. I admit I do not know the details of ASN.1 and BER, but are these not just formal mechanisms for describing data objects and how they are to be encoded? What Steve suggested was to define type keywords/codes and include them in the data exchanged between IPP client and server, such that the attribute name/value pairs become name/type/value triplets. This allows for various parsing options that WOULD OTHERWISE require a "dictionary" for all the objects (like that provided by a compiled MIB). I do not see this as reinventing ASN.1 and I do not see how ASN.1 would meet Steve's goal. Brian >>>> Randy Turner 06/06 12:38 PM >>> >Prior to the San Diego meeting, I proposed using ASN.1 as a way to >specify the protocol. This was >to prevent us from having to "re-invent" the wheel with regards to our >protocol specification. The nice >thing about ASN.1 (and its companion BER) is that extensibility is >easily achieved and with more >flexibility than what has been proposed so far. I think Larry Masinter >brought up the fact that ASN.1 >might be a better approach, and if extensibility and clarity of >specification is what is driving these >recent discussions, then I'm curious why we are striving so hard to >reinvent another way to do this. > >Randy Brian Grimshaw Apple Computer, Inc. brian@apple.com From ipp-archive Fri Jun 6 16:48:41 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA22831 for ipp-outgoing; Fri, 6 Jun 1997 16:44:44 -0400 (EDT) Message-Id: <2.2.32.19970606204420.0096cc7c@quisp.cisco.com> X-Sender: njoffe@quisp.cisco.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 06 Jun 1997 13:44:20 -0700 To: Robert.Herriot@Eng.Sun.COM (Robert Herriot), Robert.Herriot@Eng.Sun.COM, masinter@parc.xerox.com From: Neil Joffe Subject: Re: IPP> Re: draft-mutz-http-attributes-02.txt Cc: andy_mutz@hp.com, dwing@cisco.com, MUTZ@hplms26.hpl.hp.com, MONTULLI@netscape.com, ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk At 12:42 PM 6/6/97 -0700, Robert Herriot wrote: > >> From masinter@parc.xerox.com Thu Jun 5 19:32:57 1997 >> >> > None of these solutions solve the problem of the Printer's >> > resolutions-supported attribute which, hopefully, tells the >> > client exactly what resolutions the Printer supports without >> > any extraneous values and without a complicated structure >> > for the attribute. >> >> I think this is the same problem fax has, though. >> Why would a list of pairs of integers (x-res/y-res) >> or integer & ratio (x-res, aspect ratio) have 'extraneous >> values'? Or be a 'complicated structure'? >> > >If there are attributes x-res and y-res, then according to the IPP >model, there must be an x-res-supported and a y-res-supported in the >Printer. Suppose the printer supports 300 and 300x600 and 600 Then >both x-res-supported and y-res-supported have values of 300 and 600. >Then x-res and y-res can have any of the following 4 values 300x300, >300x600, 600x600 and 600x300. The last value is not a legitimate value >according to my original statement. > >It may be that resolutions supported by real printers and all future >printers can never have this problem. For example if the values are 300 >and 300x600, then x-res-supported is 300 and y-res-supported is 300 and >600. No illegal combinations are possible with these values. > >That's the problem I have with the x-res, y-res solution. If you can >show my that this solution cannot lead to unsupported combinations, >then I would agree that a pair of integers is possibly a better solution. You will need to specify the following pairs: x-res=300, y-res=300 x-res=300, y-res=600 x-res=600, y-res=600 or maybe x-res=600, y-res=600 x-res=300, y-res>=xres > >Bob Herriot > > > ------------------------------------------------------------------------ Neil Joffe Email: njoffe@cisco.com Software Engineer Voice: +1 (408) 527-7957 Voice Technology Engineering Fax: +1 (408) 527-3907 Cisco Systems San Jose ------------------------------------------------------------------------ From ipp-archive Fri Jun 6 17:33:42 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA23894 for ipp-outgoing; Fri, 6 Jun 1997 17:30:07 -0400 (EDT) Message-Id: <199706062129.OAA15632@scv2.apple.com> Subject: Re: IPP> Common concerns regarding the SWP proposal Date: Fri, 6 Jun 97 14:30:31 -0700 x-sender: brian@mail.apple.com x-mailer: Claris Emailer 1.1 From: Brian Grimshaw To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: ipp-owner@pwg.org Precedence: bulk I believe the features (intentionally) missing in SWP are essential to IPP if it is to become widely adopted. Scott did an excellent job explaining how simple it is to address the concerns that have been voiced over these features. I encourage the IPP WG to work out the final details and keep IPP on track as a robust and single conformance level protocol. Brian > Add a simple attribute to the printer that is a boolean > "multiple-documents-supported" = True or False. ... > Add s simple attribute to the printer that says > "print-by-reference-supported" = True or False. ... > Has always sounded to me like a basic query to a Printer or a Job is > essential. I believe this is fundamental. ... > > 4. Does not support job cancellation by the requesting user > Seems fundamental to me. ... > Please, let's not have two conformance levels. Let's NOT force everyone > to do do everything, but let's not fragement the standard. We have > all failed if we do. > > Scott Isaacson Brian Grimshaw Apple Computer, Inc. brian@apple.com From ipp-archive Fri Jun 6 17:43:42 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA24403 for ipp-outgoing; Fri, 6 Jun 1997 17:39:13 -0400 (EDT) Message-ID: <339884C8.76916E01@sharplabs.com> Date: Fri, 06 Jun 1997 14:44:40 -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 - A value-type field for the Protocol Spec X-Priority: 3 (Normal) References: Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Precedence: bulk If we are mixing binary and ASCII values within our encoding and require extensibility with regard to names, types, and values, then this is the kind of thing ASN.1/BER was designed for. I suggested that we just stick with ABNF as our specification and I would have been happy with that. However, when we're talking about a more complete, extensible, protocol, in which registries come into play, I think ASN.1/BER would be a better solution. It adapts much better to varying length TLV (type, length, value) pair operations and allows implementations (later versions) of a protocol to adapt easier. (i.e., no version eschange or negotiation). Randy Scott Isaacson wrote: > I am sure that ASN.1 does NOT stand for "A Simple Notation One"?? ;-) > > And BER, wasn't that "Binary Encoding for computing Resource > consumption"?? > > ASN.1/BER is way too heavy for IPP. If we are too close to > reinventing > ASN.1 > then we are way too heavy for IPP. > > Much of the discussion recently has been around "simplicity". Has > IPP lost it ability to be simple? No, I don't think it has. Is it > too > convoluted in some areas - YES. > > There was a discussion a few weeks ago about whether IPP was DPA '97. > This > reminder was a good wake-up call, and useful in that there seemed to > be > immediate consensus that IPP is not intended to be too complex like > DPA is > considered to be. > > I vote keep it simple. Add value-types only if it is a value or > keyword > that represents a specific well know syntax as described in the > standard > (extensible through registration). But don't add arbitrarily > extsensible, > compound data structures as potential values. And don't use ASN.1 !! > > Scott > > >>> Randy Turner 06/06 12:38 PM >>> > Prior to the San Diego meeting, I proposed using ASN.1 as a way to > specify the protocol. This was > to prevent us from having to "re-invent" the wheel with regards to our > > protocol specification. The nice > thing about ASN.1 (and its companion BER) is that extensibility is > easily achieved and with more > flexibility than what has been proposed so far. I think Larry Masinter > > brought up the fact that ASN.1 > might be a better approach, and if extensibility and clarity of > specification is what is driving these > recent discussions, then I'm curious why we are striving so hard to > reinvent another way to do this. > > Randy > > > > > > > > > > > > > > > > > > > > > > From ipp-archive Fri Jun 6 18:08:43 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA25161 for ipp-outgoing; Fri, 6 Jun 1997 18:03:50 -0400 (EDT) Date: Fri, 6 Jun 1997 15:04:14 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706062204.PAA17966@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, masinter@parc.xerox.com, njoffe@cisco.com Subject: Re: IPP> Re: draft-mutz-http-attributes-02.txt Cc: andy_mutz@hp.com, dwing@cisco.com, MUTZ@hplms26.hpl.hp.com, MONTULLI@netscape.com, ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Your solution below requires new, more complicated mechanisms for relating pairs of attributes. All this is just for solving a problem for one attribute. We have tried to keep the rules for attributes simple. I think it is simpler to have resolution be a set of keywords, than to have some complex mechanism for relating two attributes or to add some new value syntax for integerOrPairOfIntegers. Bob Herriot > From njoffe@cisco.com Fri Jun 6 13:45:40 1997 > > At 12:42 PM 6/6/97 -0700, Robert Herriot wrote: > > > >> From masinter@parc.xerox.com Thu Jun 5 19:32:57 1997 > >> > >> > None of these solutions solve the problem of the Printer's > >> > resolutions-supported attribute which, hopefully, tells the > >> > client exactly what resolutions the Printer supports without > >> > any extraneous values and without a complicated structure > >> > for the attribute. > >> > >> I think this is the same problem fax has, though. > >> Why would a list of pairs of integers (x-res/y-res) > >> or integer & ratio (x-res, aspect ratio) have 'extraneous > >> values'? Or be a 'complicated structure'? > >> > > > >If there are attributes x-res and y-res, then according to the IPP > >model, there must be an x-res-supported and a y-res-supported in the > >Printer. Suppose the printer supports 300 and 300x600 and 600 Then > >both x-res-supported and y-res-supported have values of 300 and 600. > >Then x-res and y-res can have any of the following 4 values 300x300, > >300x600, 600x600 and 600x300. The last value is not a legitimate value > >according to my original statement. > > > >It may be that resolutions supported by real printers and all future > >printers can never have this problem. For example if the values are 300 > >and 300x600, then x-res-supported is 300 and y-res-supported is 300 and > >600. No illegal combinations are possible with these values. > > > >That's the problem I have with the x-res, y-res solution. If you can > >show my that this solution cannot lead to unsupported combinations, > >then I would agree that a pair of integers is possibly a better solution. > > You will need to specify the following pairs: > x-res=300, y-res=300 > x-res=300, y-res=600 > x-res=600, y-res=600 > > or maybe > > x-res=600, y-res=600 > x-res=300, y-res>=xres > > > > > >Bob Herriot > > > > > > > > ------------------------------------------------------------------------ > Neil Joffe Email: njoffe@cisco.com > Software Engineer Voice: +1 (408) 527-7957 > Voice Technology Engineering Fax: +1 (408) 527-3907 > Cisco Systems > San Jose > ------------------------------------------------------------------------ > > From ipp-archive Fri Jun 6 18:18:42 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA25707 for ipp-outgoing; Fri, 6 Jun 1997 18:15:53 -0400 (EDT) Message-ID: <33988D60.FF078D1@sharplabs.com> Date: Fri, 06 Jun 1997 15:21:20 -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: PMP> prtAlertTime issue X-Priority: 3 (Normal) References: <5030100003264793000002L032*@MHS> Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Precedence: bulk The problem with using "0" is that it would be impossible to tell whether an alert was created at startup time, or that the alert time was unknown. This is why there are no "alternate" values for the TimeTicks type of object. Using "0" would be a loose agreement between members of the WG, but would not be kosher for the purist' view (IETF) of how the TimeTicks type is to be used. Randy Harry Lewis wrote: > Guess I'd like to *strongly* recommend that every device with the > printer MIB > supports sysUpTime. > I recall, rather vividly, the reason we chose sysUp was to acknowledge > that > many (most?) printers would not have a "real time" clock. But, the > premise has > always been that all printers could count ticks. > > I can see where there could be problems associated with sysUpTime, one > that > comes to mind is printers might not be real consistent (among vendors) > as to > how they treat sysUpTime on power cycles, remote resets, local resets > etc. But, > I thought the notion of synching with the printers sysUpTime on the > PowerUp > trap was a rather fundamental notion. > > Now, what if there *is no* sysUpTime (the original question)? Well, if > there is > no meaningful value, I guess 0 is about as good as any. > > >>> Harry Lewis <<< > > ------- Forwarded by Harry Lewis/Boulder/IBM on 06/06/97 03:14 PM > -------- > > pmp-owner@pwg.org > 06/06/97 01:54 PM > Please respond to rturner@sharplabs.com @ internet > > To: pmp@pwg.org @ internet > cc: > Subject: PMP> prtAlertTime issue > > Lloyd referenced an earlier mail message by Bob Pentecost reflecting a > > request by Bob as to > what value should be returned by a GET for prtAlertTime if the printer > > didn't know the time. > Values for INTEGER types have (other) and (unknown) as possible > values. > The 'TimeTicks' > object has no such equivalents. prtAlertTime is now mandatory, and is > based on sysUpTime > from MIB-II. If someone performs a GET on prtAlertTime (according the > curent definition), > then it MUST return a valid value. There are no alternative 'other' or > > 'unknown' scenarios > for an object like prtAlertTime, with type 'TimeTicks' that is based > on > MIB-II sysUpTime. > > Randy From ipp-archive Fri Jun 6 19:23:43 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA26870 for ipp-outgoing; Fri, 6 Jun 1997 19:23:13 -0400 (EDT) Message-Id: <3.0.1.32.19970606161704.00b3d570@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 6 Jun 1997 16:17:04 PDT To: Neil Joffe From: Carl-Uno Manros Subject: Re: IPP> Resolutions Cc: ipp@pwg.org In-Reply-To: <2.2.32.19970606204420.0096cc7c@quisp.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk At 01:44 PM 6/6/97 PDT, Neil Joffe wrote: >You will need to specify the following pairs: >x-res=300, y-res=300 >x-res=300, y-res=600 >x-res=600, y-res=600 > >or maybe > >x-res=600, y-res=600 >x-res=300, y-res>=xres Maybe I am too simplistic here, but it seems that everybody in this discussion is assuming that the values have to be numeric and hence we have to a x-value and a y-value. Why not stay with a simple approach of using ASCII text strings, and just define ONE attribute with the value for the attribute being a simple text string allowing values like: "300x300" "300x600" "600x600" etc with an additional rule that what comes before the "x" is the x-value and what comes after it is the y-value. This could also allow for cases like: "300" which would be semantically equivalent to: "300x300" Comments? Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-archive Fri Jun 6 19:23:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA26859 for ipp-outgoing; Fri, 6 Jun 1997 19:22:15 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 06 Jun 1997 16:16:11 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - 6/6 telecon minutes Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk There was a Model group telecon held 6/6/97. 2-4 pm Mountain 800-600-5302 code: 346463 Attendees: Bob H. Scott I. Tom H. Carl-Uno M. Jay M. Peter Z. Note taker: Scott I. Notes: 1. Seems to finally be consensus on job-state and job-state-reasons. Tom will do the final write up for IPP model and JMP MIB. - Make job-state-reasons optional - Make job-state values as defined in recent e-mails (see Tom's write up) - Keep names like pending-held, processing-stopped as keywords in the model doc, but programs can put up any UI strings as they see fit (Angelo's email seemed like what a reasonable UI would do). - Make all job-state-reason values purely optional and just describe the semantics of the keyword, don't force a relationship with a given state. 2, Keep attributes in the Model document. Move lengthy lists of values for some of the attributes to an appendix (makes the text flow better). 2.5 Discussed and agreed that the Model needs to be concise and straight forward. We need to focus on model concepts more that nit-picky IFs, ANDs, BUTs, SHALLs, etc. at this point. Lengthy issue-after-issue-after-issue emails one more trivial items causes the working group participants to loose interest and diminishes participation. 2.6 Reviewed differences between SWP model and IPP model. Differences are summarized by Jay M in an email on the discussion list. Scott added that there are some fairly straightforward "supported" type attributes that could be added to not force multiple conformance levels. This is a specific proposal on what Carl-Uno has been suggesting (stapling supported analogy). Discussed possible need "multi valued supported" attributes for operations and print-by-reference schemes.... Seemed like it could grow in this direction as needed later, for now a simple boolean ought to suffice. Print by reference could be scaled down to just HTTP URLs. 3. Please look at sections 2.2.7 and 2.2.8 on "implements" and "supports" . Any help here would be greatly appreciated (by the editor) 4. Bob H to look at rewritting section 4.5.2 as needed 5. Need to remove all "ignored attributes" response parameters and remove the idea that a Printer ignores unimplemented/unsupported attributes that come across in a create request. This conflicts with SWP. 6. 5.1.1.2 talks of "ignored attributes", "unsupported attributes" and "bad attributes" This will change to just "unsupported attributes" and "unsupported attribute values" (both being a list of attributes names) 7. Reference RFC 1766 when defining "locale" syntax type (this includes both language and country EN-US) Character set is UTF-8 across the board. 8. For dateTime reference RFC 1123 (updating 822) which is referenced by 2068. 9. Remove the attribute "printer-speed". This allows us to remove the attribute syntax "integerUnits". 10. Remove all notion of "xxx-available". 11. Change the syntax of "output-device-assigned" from uri to name 12. Clarify that type 4 keyword can be extended using any of the registration mechanisms described for type 1, 2, 3, or 4. Type 3 can use type 1, 2, or 3 registration mechanism, but not type 4. That is if someone wants to extend a type 4 keyword set attribute, they can lobby to rev the standard (type 1), have PWG recognize it (type 2), have IANA simply register it, or add it to their sites set of accepted values. Clarify that type 4 includes almost anyone and is not restricted to just SAs. 13. printer-state-reasons also goes to optional. Allow for -error, -warning, or -report to be added to any of the standard keywords. If missing, assume ERROR, 14. 6.5.2.7 keep make-and-model as a single attribute (text) supports filtered search etc. 15. Section 7 still need lots of work. Section 7.2: No, there are no mandatory attributes in a create request. 16. Remove the change history from the Model document. It would be nice to keep this in a separate doc online, but there is no guarantees from the editor that this will happen 15. Ended at 3:30 Mountain time. Note taker's personal observation: Very good meeting. Model has finally stablized!! There are some tweeks yet, but good solid foundation. 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 Jun 6 19:28:43 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA26902 for ipp-outgoing; Fri, 6 Jun 1997 19:23:59 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 06 Jun 1997 16:21:35 -0600 From: Scott Isaacson To: ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP> PRO - A value-type field for the Protocol Spec Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk Randy, Yes, let's just stick with ABNF. >>> Randy Turner 06/06 3:44 PM >>> > If we are mixing binary and ASCII values within our encoding ... See my earlier posting measurements we did of our prototype where we encoded both ways "(binary length)name(binary length)value" and then just "name:valueCRLF" Not a lot of difference in our timing measurements. In fact it takes more time to encode using binary lengths. Doesn't seem worth it to me to skip a great legacy and ease extensibility and reduce risk of interoperability for almost no processing gain on a portion that is only very minimally involved in the overall end-to-end processing time required from application-to-paper. Scott From ipp-archive Fri Jun 6 19:48:45 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA28121 for ipp-outgoing; Fri, 6 Jun 1997 19:44:35 -0400 (EDT) Message-Id: <3.0.1.32.19970606163755.00a21d40@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 6 Jun 1997 16:37:55 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Goals of the IPP Working Group Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk All, I know it is a long time back (6 - 8 months) since we discussed the scope of the project, but I would encourage everybody who want to debate the SWP vs. full IPP issue to go back and read what the charter for this group states. It is referenced from the IPP web page, if you do not know where to find it. In particular, I would like to call your attention to this piece of text from our IETF charter: "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" This is what we promised to deliver at the beginning of the project, and this what we have been working to provide so far. Some of the discussion on the DL lately seem to question the scope of the whole project, which I find very disturbing. 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 Jun 6 20:13:43 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA29086 for ipp-outgoing; Fri, 6 Jun 1997 20:08:55 -0400 (EDT) Date: Fri, 6 Jun 1997 17:06:30 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706070006.RAA18211@woden.eng.sun.com> To: njoffe@cisco.com, cmanros@cp10.es.xerox.com Subject: Re: IPP> Resolutions Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk The IPP solution using keywords is nearly the same as the text solution you are proposing. Since the protocol implements keywords as character strings, the only difference between your text proposal and the current IPP solution is that someone has to register each new resolution as a type2 keyword. Perhaps, what you are saying tacitly is that because the format for such keywords is Int or IntxInt where each Int value has a well defined meaning, we could just as well define resolution as a new syntax type and allow printer vendors to use new values of Int without the need to register them. Comments? Bob Herriot > From cmanros@cp10.es.xerox.com Fri Jun 6 16:42:36 1997 > > At 01:44 PM 6/6/97 PDT, Neil Joffe wrote: > >You will need to specify the following pairs: > >x-res=300, y-res=300 > >x-res=300, y-res=600 > >x-res=600, y-res=600 > > > >or maybe > > > >x-res=600, y-res=600 > >x-res=300, y-res>=xres > > > Maybe I am too simplistic here, but it seems that everybody in this > discussion is assuming that the values have to be numeric and hence we have > to a x-value and a y-value. > > Why not stay with a simple approach of using ASCII text strings, and just > define ONE attribute with the value for the attribute being a simple text > string allowing values like: > > "300x300" > "300x600" > "600x600" etc > > with an additional rule that what comes before the "x" is the x-value and > what comes after it is the y-value. > > This could also allow for cases like: > > "300" > > which would be semantically equivalent to: > > "300x300" > > Comments? > > Carl-Uno > > > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com > From ipp-archive Fri Jun 6 20:48:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA29850 for ipp-outgoing; Fri, 6 Jun 1997 20:44:01 -0400 (EDT) Message-Id: <3.0.1.32.19970606173746.00a65100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 6 Jun 1997 17:37:46 PDT To: Robert.Herriot@Eng.Sun.COM (Robert Herriot), njoffe@cisco.com, cmanros@cp10.es.xerox.com From: Carl-Uno Manros Subject: Re: IPP> Resolutions Cc: ipp@pwg.org In-Reply-To: <199706070006.RAA18211@woden.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk At 05:06 PM 6/6/97 PDT, Robert Herriot wrote: >The IPP solution using keywords is nearly the same as the text solution >you are proposing. Since the protocol implements keywords as character >strings, the only difference between your text proposal and the current >IPP solution is that someone has to register each new resolution as a >type2 keyword. > >Perhaps, what you are saying tacitly is that because the format for >such keywords is Int or IntxInt where each Int value has a well defined >meaning, we could just as well define resolution as a new syntax type and >allow printer vendors to use new values of Int without the need to >register them. > I was thinking about the latter case, that there should not be necessary to go and register every value before you can use it. The alternative would be to define a list containing all the values that we are aware of now, and let vendors with odd values register their own later, but that is definately more messy. Defining a separate syntax seems the simpler way to solve this. Also, an XxY syntax may well come in handy for other attributes in the future. 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 Jun 6 22:03:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA00629 for ipp-outgoing; Fri, 6 Jun 1997 21:59:39 -0400 (EDT) Date: Fri, 6 Jun 1997 21:59:54 -0400 (EDT) From: JK Martin Message-Id: <199706070159.VAA09897@uscore.underscore.com> To: lawrence@agranat.com Subject: Re: IPP> PRO - Re: Print by reference Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Scott, > It certainly isn't good design (IMHO) to require both MIME/HTTP parsers > and ASN1/SNMP parsers just to submit a job to a printer. Does this mean you are _not_ in favor of having IPP header attributes encoded as binary data? ...jay From ipp-archive Fri Jun 6 22:03:45 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA00634 for ipp-outgoing; Fri, 6 Jun 1997 21:59:43 -0400 (EDT) Date: Fri, 6 Jun 1997 21:56:07 -0400 (EDT) From: JK Martin Message-Id: <199706070156.VAA09706@uscore.underscore.com> To: cmanros@cp10.es.xerox.com Subject: Re: IPP> ADM - Goals of the IPP Working Group Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk I read your message three times, but still come away confused about exactly what disturbs you regarding recent discussions. Can you be a bit more explicit, please? ...jay ----- Begin Included Message ----- >From ipp-owner@pwg.org Fri Jun 6 19:53 EDT 1997 Date: Fri, 6 Jun 1997 16:37:55 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Goals of the IPP Working Group All, I know it is a long time back (6 - 8 months) since we discussed the scope of the project, but I would encourage everybody who want to debate the SWP vs. full IPP issue to go back and read what the charter for this group states. It is referenced from the IPP web page, if you do not know where to find it. In particular, I would like to call your attention to this piece of text from our IETF charter: "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" This is what we promised to deliver at the beginning of the project, and this what we have been working to provide so far. Some of the discussion on the DL lately seem to question the scope of the whole project, which I find very disturbing. 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 Jun 6 22:33:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA01652 for ipp-outgoing; Fri, 6 Jun 1997 22:32:09 -0400 (EDT) Date: Fri, 6 Jun 1997 22:28:44 -0400 (EDT) From: JK Martin Message-Id: <199706070228.WAA11121@uscore.underscore.com> To: hastings@cp10.es.xerox.com Subject: Re: IPP> Common concerns regarding the SWP proposal Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Tom, Some comments on your comments: > >The concerns I have heard from multiple IPP participants include the > >following (in no particular order): > > > > 1. Does not support multiple documents > > > > 2. Does not support Print-by-Reference > > > > 3. Does not support job status queries > > > > 4. Does not support job cancellation by the requesting user > > No problem with not having any of the above in the lowest level (or in SWP). > You don't get any of the above with current Windows printing and it hasn't > cause customers to not use Windows. As Babak and Keith said, SWP is > only the first step which takes the current Windows printing paradigm > and puts it on the Internet. This is fine for Windows. (I guess.) But what about other environments? (I can just hear Don Wright's all-too-frequent exclamation now... "Unix is a niche market, so don't bother with it!") IPP is not just for Windows. However some folks seem to contend that Windows is the only environment worth satisfying in the IPP effort. By the way, are you saying that a Windows user has no way to observe the current status of his/her submitted job? Nor that the user is able to cancel a previously submitted job? I find this a bit hard to believe. > > 5. Uses binary-encoded data for simple information normally encoded > > in text for HTTP-related transactions > > This decision is perhaps not the best, but its not a show stopper. > Lets not use it as a "wedge" issue to abandon the agreements in San Diego. And let's not say these kinds to put the wrong spin on stated concerns. There are those in the IPP group who believe the group did not have sufficient time to fully evaluate SWP in San Diego, given the document was not published until a couple of days before the meeting. It's should come as no surprise, then, that once we started comparing the SWP proposal against the IPP charter, it fell quite a bit short. > Maybe I'm naive, but I think that Microsoft will support full IPP in their > follow on release. Its just a matter of timing. Had we had IPP all done > and the NT 5.0 development group had the resources, they would have put > full IPP into NT 5.0. Basically, the NT strategy is to keep adding > functionality. Why do you think that Microsoft would stop with SWP? Ummm... Because they don't want to expose anymore of their printing system for external augmentation by other vendors? (Sorry, but was that a trick question?) If Microsoft and HP had taken the time to discuss their ideas and objections on the IPP list all along, we--and they--would have had more time to develop a singular conformance level to the betterment of all. Why didn't Microsoft and HP participate in the open forum for this standards effort, anyway? In most working groups, the people who make a particular proposal are usually the ones to defend it, yet we have heard nothing from either the Microsoft nor HP camp. > Any system that can't cancel a job is not going to be viable in the market > place very long. So Microsoft will be forced into doing more in the > future by their customer base (and IPP). Hmmm... I thought you said Windows users can't cancel print jobs today? > I look at SWP as being half full, not half empty. SWP makes IPP more real, > rather than detracting from IPP. SWP makes IPP more real??? (Sorry, a rhetorical question, at best) > Carl-Uno made the suggestion that maybe SWP could be a separate informational > RFC (from Microsoft or from the PWG, TBD), which is a subset of IPP. > Then IPP could avoid having two conformance levels, if we cannot agree > to have two conformance levels. Anyone can publish an I-D at anytime (with some constraints now, I guess). But calling SWP an "I-D" so as to avoid a two-level conformance situation is just a thinly disguised veneer of a second conformance level, IMHO. ...jay From ipp-archive Fri Jun 6 22:43:47 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA01935 for ipp-outgoing; Fri, 6 Jun 1997 22:39:06 -0400 (EDT) Date: Fri, 6 Jun 1997 19:40:32 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706070240.TAA00498@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO Monday teleconference X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk The agenda for Monday's teleconference is: 1) comments on Microsoft IPP document. 2) comments on Randy's latest draft that will hopefully be available by conference time. The meeting is Monday June 9 from 1pm PDT to 3pm. The number is: 415-278-2944 passcode: 3440795 From ipp-archive Fri Jun 6 22:58:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA02675 for ipp-outgoing; Fri, 6 Jun 1997 22:57:43 -0400 (EDT) Date: Fri, 6 Jun 1997 19:59:16 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706070259.TAA00511@woden.eng.sun.com> To: paulmo@microsoft.com, ipp@pwg.org Subject: IPP>MOD PRO Comments on Microsofts IPP document X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk I have comments about a few parts which differ from the IPP documents. I hope that we can resolve these differences to keep compatibility. Section 2.4. You state that you don't support print by reference, but your Rationale suggests you would do it the same we have proposed, namely with a job attribute which contains the document URI. Am I missing something? So, do you plan to support print by reference with a client supplied URI? Section 7.4. I would suggest that you look at the new wording for defining the characters allowed for an attribute name. The document should be posted by Monday. It limits names to the ASCII letters, ASCII digits, ASCII hyphen and ASCII underscore. Section 8. You define several different representations for attribute values: text, binary integers, binary boolean, binary keywords. But you don't include a field for value's type. This makes is hard for a client to know how to interpret and unknown attribute. I think the right solution is to keep the IPP solution where all values are text. Alternatively, we could all agree to add a one byte type field just before the value's length field. Section 8 (Setof): We decided at the San Diego meeting that a set of values would be represented by a sequence of attributes in which all but the first attribute name would be of 0 length. Your description omits the statement about 0 length. From ipp-archive Sat Jun 7 02:13:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA04182 for ipp-outgoing; Sat, 7 Jun 1997 02:12:02 -0400 (EDT) Message-ID: <3398FC2B.5180@sharplabs.com> Date: Fri, 06 Jun 1997 23:14:03 -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> ADM - Goals of the IPP Working Group References: <199706070156.VAA09706@uscore.underscore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk I think Carl-Uno was talking about that some recent mail messages have tended towards possibly scaling back IPP to be just SWP. And since the original SWP document (not the latest doc from Paul Moore) only met one of several requirements in the charter, that discussing scaling back was potentially damaging and counter- productive to the original intent of the working group. At this point, I don't think we have any business wasting precious (i.e., market-driven) time by stepping back to the 10000, 25000, 50000, or pick your favorite altitude and looking at too abstract a big picture. I think what is solidifying at the moment (meaning what we have agreed to so far) with the set of documents we have is very close to meeting the original requirements. And given that this working group has only been chartered for 4 months, I think the progress is very good (independent of what the trade rags might have us believe). I suggest we go ahead with what we have decided on so far and proceed from there. I think we're too close to start reconsidering major components of IPP that we have already decided on. We should stay focused and finish the remainder of our work, including but not limited to the following: 1. A recommendation for secure IPP transactions from the security sub-group in the form of an internet-draft. 2. Finalize a language and encoding for IPP attributes using HTTP. We need to reach closure on this very quickly so we can start prototyping to make sure we have experimental verification that we've "done the right thing". 3. A short internet draft (possibly informational) on potential directory schemas for IPP services. 4. Cleaning up any model issues and possibly moving the attributes section of the model document into a separate draft, just to make the model document easier to "swallow". The last few weeks on my schedule have been quite hectic, with alot of document generation on top of my usual job. I would have liked to have had more prototyping experience by now but I appreciate Scott and his colleagues for publishing their initial experience with encodings for attribute information. This is just the kind of feedback and analysis we need to justify our decisions (and to possibly defend our decisions before the IETF). Randy JK Martin wrote: > > I read your message three times, but still come away confused > about exactly what disturbs you regarding recent discussions. > > Can you be a bit more explicit, please? > > ...jay > > ----- Begin Included Message ----- > > >From ipp-owner@pwg.org Fri Jun 6 19:53 EDT 1997 > Date: Fri, 6 Jun 1997 16:37:55 PDT > To: ipp@pwg.org > From: Carl-Uno Manros > Subject: IPP> ADM - Goals of the IPP Working Group > > All, > > I know it is a long time back (6 - 8 months) since we discussed the scope > of the project, but I would encourage everybody who want to debate the SWP > vs. full IPP issue to go back and read what the charter for this group states. > It is referenced from the IPP web page, if you do not know where to find it. > > In particular, I would like to call your attention to this piece of text > from our IETF charter: > > "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" > > This is what we promised to deliver at the beginning of the project, and > this what we have been working to provide so far. Some of the discussion on > the DL lately seem to question the scope of the whole project, which I find > very disturbing. > > 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 Sun Jun 8 20:29:11 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA15477 for ipp-outgoing; Sun, 8 Jun 1997 20:26:31 -0400 (EDT) Message-ID: <41135C785691CF11B73B00805FD4D2D702B7CE81@RED-17-MSG.dns.microsoft.com> From: Paul Moore To: "'Robert.Herriot@Eng.Sun.COM'" , ipp@pwg.org Subject: RE: IPP>MOD PRO Comments on Microsofts IPP document Date: Sun, 8 Jun 1997 17:26:46 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.30) Sender: ipp-owner@pwg.org Precedence: bulk By Reference: I do not think that all the issues of print by reference have been thought out yet. You are right that an attribute could be added, but this is fundamentally different from the existing print operation - I would make it a separate operation. A print server can ignore any attribute and still be able to print, this is not the case for a document URL attribute. I would have "PrintThis" and "PrintThat" as two distinct operations that a server may or may not implement. Attribute names: Whatever seems correct to the group.(I was merely advising against calling something 'Job&%Copies#*@') Type byte: This was suggested to me already. I am neutral on the subject. I did not make the change becuase it was not discussed in San Diego. There are a few question I have on it which I would like to see discussed before finalising. SetOf: I remember the discussion - I was not sure what was agreed. I am neutral on the topic - whatever the consensus is, I will put in. > -----Original Message----- > From: Robert.Herriot@Eng.Sun.COM [SMTP:Robert.Herriot@Eng.Sun.COM] > Sent: Friday, June 06, 1997 7:59 PM > To: Paul Moore; ipp@pwg.org > Subject: IPP>MOD PRO Comments on Microsofts IPP document > > > I have comments about a few parts which differ from the IPP documents. > I hope that we can resolve these differences to keep compatibility. > > Section 2.4. You state that you don't support print by reference, but > your Rationale suggests you would do it the same we have proposed, > namely > with a job attribute which contains the document URI. Am I missing > something? So, do you plan to support print by reference with a > client > supplied URI? > > Section 7.4. I would suggest that you look at the new wording for > defining the characters allowed for an attribute name. The document > should be posted by Monday. It limits names to the ASCII letters, > ASCII digits, ASCII hyphen and ASCII underscore. > > Section 8. You define several different representations for attribute > values: text, binary integers, binary boolean, binary keywords. But > you don't include a field for value's type. This makes is hard for > a client to know how to interpret and unknown attribute. I think > the right solution is to keep the IPP solution where all values are > text. Alternatively, we could all agree to add a one byte type field > > just before the value's length field. > > Section 8 (Setof): We decided at the San Diego meeting that a set of > values would be represented by a sequence of attributes in which > all but the first attribute name would be of 0 length. Your > description > omits the statement about 0 length. From ipp-archive Mon Jun 9 10:34:20 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA17357 for ipp-outgoing; Mon, 9 Jun 1997 10:29:38 -0400 (EDT) From: Harry Lewis To: Subject: Re: IPP> Re: draft-mutz-http-attributes-02.txt Message-Id: <5030100003319996000002L062*@MHS> Date: Mon, 9 Jun 1997 10:31:47 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk I know this must be an area of "clash" between DPA and the Printer MIB, but wouldn't it be a good idea to establish a convention which is compatible with RFC1759 regarding Feed and CrossFeed marker addressability? >>> Harry Lewis <<< ------- Forwarded by Harry Lewis/Boulder/IBM on 06/09/97 08:23 AM ------ ipp-owner@pwg.org 06/06/97 08:19 PM Please respond to ipp-owner@pwg.org @ internet To: njoffe@cisco.com @ internet, masinter@parc.xerox.com @ internet, Robert.Herriot@Eng.Sun.COM @ internet cc: ipp@pwg.org @ internet, MONTULLI@netscape.com @ internet, MUTZ@hplms26.hpl.hp.com @ internet, dwing@cisco.com @ internet, andy_mutz@hp.com @ internet Subject: Re: IPP> Re: draft-mutz-http-attributes-02.txt Your solution below requires new, more complicated mechanisms for relating pairs of attributes. All this is just for solving a problem for one attribute. We have tried to keep the rules for attributes simple. I think it is simpler to have resolution be a set of keywords, than to have some complex mechanism for relating two attributes or to add some new value syntax for integerOrPairOfIntegers. Bob Herriot > From njoffe@cisco.com Fri Jun 6 13:45:40 1997 > > At 12:42 PM 6/6/97 -0700, Robert Herriot wrote: > > > >> From masinter@parc.xerox.com Thu Jun 5 19:32:57 1997 > >> > >> > None of these solutions solve the problem of the Printer's > >> > resolutions-supported attribute which, hopefully, tells the > >> > client exactly what resolutions the Printer supports without > >> > any extraneous values and without a complicated structure > >> > for the attribute. > >> > >> I think this is the same problem fax has, though. > >> Why would a list of pairs of integers (x-res/y-res) > >> or integer & ratio (x-res, aspect ratio) have 'extraneous > >> values'? Or be a 'complicated structure'? > >> > > > >If there are attributes x-res and y-res, then according to the IPP > >model, there must be an x-res-supported and a y-res-supported in the > >Printer. Suppose the printer supports 300 and 300x600 and 600 Then > >both x-res-supported and y-res-supported have values of 300 and 600. > >Then x-res and y-res can have any of the following 4 values 300x300, > >300x600, 600x600 and 600x300. The last value is not a legitimate value > >according to my original statement. > > > >It may be that resolutions supported by real printers and all future > >printers can never have this problem. For example if the values are 300 > >and 300x600, then x-res-supported is 300 and y-res-supported is 300 and > >600. No illegal combinations are possible with these values. > > > >That's the problem I have with the x-res, y-res solution. If you can > >show my that this solution cannot lead to unsupported combinations, > >then I would agree that a pair of integers is possibly a better solution. > > You will need to specify the following pairs: > x-res=300, y-res=300 > x-res=300, y-res=600 > x-res=600, y-res=600 > > or maybe > > x-res=600, y-res=600 > x-res=300, y-res>=xres > > > > > >Bob Herriot > > > > > > > > ------------------------------------------------------------------------ > Neil Joffe Email: njoffe@cisco.com > Software Engineer Voice: +1 (408) 527-7957 > Voice Technology Engineering Fax: +1 (408) 527-3907 > Cisco Systems > San Jose > ------------------------------------------------------------------------ > > From ipp-archive Mon Jun 9 10:59:20 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA17855 for ipp-outgoing; Mon, 9 Jun 1997 10:59:17 -0400 (EDT) Message-Id: <199706091447.KAA16192@devnix.agranat.com> To: Tom Hastings cc: ipp@pwg.org, Robert.Herriot@Eng.Sun.COM (Robert Herriot), szilles@Adobe.COM Subject: Re: IPP> PRO - A value-type field for the Protocol Spec proposal In-reply-to: <9706061811.AA03314@zazen.cp10.es.xerox.com> Date: Mon, 09 Jun 1997 10:47:07 -0400 From: "Scott Lawrence" Sender: ipp-owner@pwg.org Precedence: bulk >>>>> "TH" == Tom Hastings writes: TH> We could also choose to encode the current Model dateTime data type TH> as binary, using some existing standard. That might help with the TH> localization of dates and times and the time zone problem. However, TH> if there is a standard for the representation of dates and time TH> in printable form, including time zones, I suggest that we stick TH> with printable dateTime. There is a very good ISO spec for representing date/time: ISO 8601; there is a page about it at: http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-archive Mon Jun 9 11:04:20 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA17875 for ipp-outgoing; Mon, 9 Jun 1997 11:02:49 -0400 (EDT) From: Harry Lewis To: Subject: Re: IPP> PRO - A value-type field for the Protocol Spec Message-Id: <5030100003321556000002L062*@MHS> Date: Mon, 9 Jun 1997 11:04:53 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk I vote to keep IPP simple, but disagree that ASN.1 is a culprit. > ASN.1/BER is way too heavy for IPP. If we are too close to > reinventing ASN.1 then we are way too heavy for IPP. The IETF Printer MIB has the support of 9 or 10 vendors, today, with software on many diverse platforms and in 6 or 7 vendors embedded controller product lines. I keep hearing we shouldn't "strangle" IPP with embedded controller limitations. How then, can we claim ASN.1/BER is too "heavy" for IPP? I find lack of compatibility with existing IETF standards (the debate over "x,y resolution" for example), and the resulting redundancy, one of the "heaviest" things about IPP. >>> Harry Lewis <<< --------- Forwarded by Harry Lewis/Boulder/IBM on 06/09/97 08:28 AM --------- ipp-owner@pwg.org 06/06/97 08:17 PM Please respond to rturner@sharplabs.com @ internet To: ipp@pwg.org @ internet cc: Subject: Re: IPP> PRO - A value-type field for the Protocol Spec If we are mixing binary and ASCII values within our encoding and require extensibility with regard to names, types, and values, then this is the kind of thing ASN.1/BER was designed for. I suggested that we just stick with ABNF as our specification and I would have been happy with that. However, when we're talking about a more complete, extensible, protocol, in which registries come into play, I think ASN.1/BER would be a better solution. It adapts much better to varying length TLV (type, length, value) pair operations and allows implementations (later versions) of a protocol to adapt easier. (i.e., no version eschange or negotiation). Randy Scott Isaacson wrote: > I am sure that ASN.1 does NOT stand for "A Simple Notation One"?? ;-) > > And BER, wasn't that "Binary Encoding for computing Resource > consumption"?? > > > Much of the discussion recently has been around "simplicity". Has > IPP lost it ability to be simple? No, I don't think it has. Is it > too > convoluted in some areas - YES. > > There was a discussion a few weeks ago about whether IPP was DPA '97. > This > reminder was a good wake-up call, and useful in that there seemed to > be > immediate consensus that IPP is not intended to be too complex like > DPA is > considered to be. > > I vote keep it simple. Add value-types only if it is a value or > keyword > that represents a specific well know syntax as described in the > standard > (extensible through registration). But don't add arbitrarily > extsensible, > compound data structures as potential values. And don't use ASN.1 !! > > Scott > > >>> Randy Turner 06/06 12:38 PM >>> > Prior to the San Diego meeting, I proposed using ASN.1 as a way to > specify the protocol. This was > to prevent us from having to "re-invent" the wheel with regards to our > > protocol specification. The nice > thing about ASN.1 (and its companion BER) is that extensibility is > easily achieved and with more > flexibility than what has been proposed so far. I think Larry Masinter > > brought up the fact that ASN.1 > might be a better approach, and if extensibility and clarity of > specification is what is driving these > recent discussions, then I'm curious why we are striving so hard to > reinvent another way to do this. > > Randy > > > > > > > > > > > > > > > > > > > > > > From ipp-archive Mon Jun 9 13:14:21 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA19438 for ipp-outgoing; Mon, 9 Jun 1997 13:09:43 -0400 (EDT) Mime-Version: 1.0 Date: Mon, 9 Jun 1997 13:15:13 -0400 Message-ID: <0001900C.1337@digprod.com> From: bwagner@digprod.com (Bill Wagner) Subject: Re[2]: IPP> Common concerns regarding the SWP proposal To: 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 Carl-Unos and Scott appear to suggest the that IPP standard should include all the features the group feels are desirable; and that specific implementations may have "null" implementations of these features. Aside from the time necessary to properly define this complete set of features, and the time necessary to get approval, the following message on the IETF-FAX list (in response to perhaps a similar situation in internet fax) points out a potential problem to this approach which sould be addressed. It might be appropriate for the IPP's IETF guides to comment on this. Bill Wagner, Osicom/DPI ______________________________ Forward Header _____________________________ Subject: Re: JWK and Wordcraft support for legacy fax machines - UniB Author: Ned Freed at Internet Date: 6/9/97 9:13 AM >Confusion of standards and implementations again. Standards define the set >of functions, implementations may opt for a sub-set.The key is to define a >full set to start with and then let people do their own thing in terms of >the sub-set they select. I agree that this is how the ISO and ITU standards process works.It is not, however, how the IETF standards process works. IETF standards attempt to standardize the minimum amount of stuff needed to get the job done and no more. And if subsequent implementation experience shows that some features end up being unimplemented and hence don't interoperate they will be removed from the standard as it proceeds down the standards path. At the heart of all this is the IETF requirement that each feature of a standard has to be shown to (1) interoperate between multiple implementations and (2) not have any known interoperability problems before the standard can advance in grade. Fine,you say,but why does this rule preclude me from writing a standard with lots of stuff in it and then trimming the stuff that sees insufficient implementation later on? The answer is that while the process may formally allow this, the long-time participants in the process have a strong bias against it, and you will have the devil's own job getting rough consensus on documents that are written this way. The "rough consensus and running code" line often sounds silly to people who hail from the ISO or ITU communities (I used to be such a person, BTW) but here these are words to live by. When MIME was first designed there were no less than three separate implementations of every feature in the standard (one by me, one by Marshall Rose, and one by Nathaniel Borenstein) that were done as the standard was being written and were kept up to date as the standard changed. And even though we effectively met the implementation requirements for a move to full standard status before RFC1341 even came out, we've still have to trim any number of features out of MIME, and I suspect that several more will have to go before we are allowed to move it to full standard. Ned ______________________________ Reply Separator _________________________________ Subject: Re: IPP> Common concerns regarding the SWP proposal Author: Scott Isaacson at Internet Date: 6/6/97 1:43 PM Good summary Jay.. ************************************************************ 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 06/05 6:47 PM >>> > 1. Does not support multiple documents No mandatory support for all implementations. Add a simple attribute to the printer that is a boolean "multiple-documents-supported" = True or False. If False, expect an error code back on Create-Job or Send-Document. Maybe even put this in the directroy schema. Do end users want to find printers that can print multiple documents per job? I don't know. > 2. Does not support Print-by-Reference Add s simple attribute to the printer that says "print-by-reference-supported" = True or False. If False, don't expect a URL as document content to work. If True, what gets printed is what gets printed no guarantee and if you send in an FTP URL and the given instance of a Printer does not support it, you get an error message. > 3. Does not support job status queries Has always sounded to me like a basic query to a Printer or a Job is essential. I believe this is fundamental. Sure, you could always do a GET on a url with an accept header of text/html and get back a browser view, but this need not be a requirement. SWP does not mandate that this be a requirement. However, a requirement would be to support an POST with an application/ipp PDU in it. The number of MANDATORY requirements is SO small here, I don't see a problem with supporting the operation for all implemntations given that you have a web server already (doing the GET accepting text/html that is). > 4. Does not support job cancellation by the requesting user Seems fundamental to me. If you support an HTML form version of this, it would be like litterally 10 lines of code to add the POST application/IPP version. > 5. Uses binary-encoded data for simple information normally encoded > in text for HTTP-related transactions In our prototype, we just finished up a Java application that tried to process attributes encoded as: namevalue (case 2) rather than as name ":" value CRLF (case 1) We ran both versions on 3 attributes, 30 attributes, and 300 attributes. The goal was to measure the actuall difference in processing time for a dumb, interpreted java application to do one or the other. The times seem slow (we just did a quick an dirty hack with no optimizations, kept the buffering I/O the same, just modified the algorithm) Encoding 30 attributes (varying name lengths, varying value lenghts), 50 runs, avg. Case 1: .1375 seconds Case 2: .1525 seconds Decoding 30 attributes (varying name lengths, varying value lenghts), 50 runs, avg. Case 1: .0975 seconds Case 2: .0825 seconds Sure enough, case 2 was "quicker" but as been said many times before: "This is printing we are talking about, and at MOST 30 attributes we are talking about" Ease of use and extensibility and portability etc are so much easier with a non-binary encoding of lengths. It just doesn't buy you very much. Interesting node, encoding actually took longer with case 2? You actually have to compute the length in order to encode the length! Looking at both sides (encoder/decoder), it seems to come out a wash with binary encoding or not. The point in posting this data is not to get into a war about "we'll I could do it faster ..." but just to look at the RELATIVELY MINOR overhead of 30 attributes compared to a 4 meg color RIP process!!! Please, let's not have two conformance levels. Let's NOT force everyone to do do everything, but let's not fragement the standard. We have all failed if we do. Scott Isaacson From ipp-archive Mon Jun 9 14:14:22 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA20657 for ipp-outgoing; Mon, 9 Jun 1997 14:11:57 -0400 (EDT) Date: Mon, 9 Jun 1997 14:12:12 -0400 (EDT) From: JK Martin Message-Id: <199706091812.OAA26351@uscore.underscore.com> To: paulmo@microsoft.com Subject: RE: IPP>MOD PRO Comments on Microsofts IPP document Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Paul, Thanks for responding to Bob Herriot's questions. > By Reference: > I do not think that all the issues of print by reference have been > thought out yet. Can you shed some light on those issues not yet thought out? Are there other considerations/constraints that have not yet been presented on this list that we should discuss? > Type byte: > This was suggested to me already. I am neutral on the subject. I did not > make the change becuase it was not discussed in San Diego. There are a > few question I have on it which I would like to see discussed before > finalising. What are the questions you have about typing as it has been proposed? We should start discussing those questions immediately, given the current date of this effort. Whatever you and your colleagues at Microsoft can do to help further the development of this standard would be greatly appreciated by all the IPP participants. ...jay From ipp-archive Mon Jun 9 14:54:26 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA21189 for ipp-outgoing; Mon, 9 Jun 1997 14:50:54 -0400 (EDT) Message-Id: <9706091841.AA03929@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, 9 Jun 1997 11:38:59 PDT To: jmp@pwg.org, ipp@pwg.org, Harry Lewis From: Tom Hastings Subject: IPP> Re: JMP> documentFormatIndex Sender: ipp-owner@pwg.org Precedence: bulk I would agree. The JMP documentFormatIndex is whatever the Printer MIB Index is, which includes control languages, as well as page description languages. The JMP value is the index into the Printer MIB. BTW, IPP is using the MIME type name as the value of its document-format attribute, not the PWG enums symbol names with the "lang" prefix removed. (At least the Model document says that the protocol is using the MIME types to identify document formats.). So I added the OCTETS form to the documentFormatType attribute (and removed the Type suffix) as we agreed for other attributes in San Diego that an agent can represent as an integer or a string or both. So an agent has a number of choices for representing the document format: 1. If implementing the Printer MIB, the agent can use the documentFormatIndex attribute with the same value as the Printer MIB. 2. Any agent can use the documentFormat attribute with either: the Printer MIB enum the MIME type name or both Ok? Tom At 10:07 06/09/97 PDT, Harry Lewis wrote: >We have documentFormat as one of our Job Attributes. It points to >prtInterpreterLanguageFamily TC in the printer MIB. I want to clarify that this >job MIB Attribute may relate to a job control language as well as a page >description language. Do you agree, Tom? Does anyone disagree? > >>>> Harry Lewis <<< > > From ipp-archive Mon Jun 9 14:54:27 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA21188 for ipp-outgoing; Mon, 9 Jun 1997 14:50:53 -0400 (EDT) Message-Id: <3.0.1.32.19970609105926.00ad48e0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 9 Jun 1997 10:59:26 PDT To: JK Martin , cmanros@cp10.es.xerox.com From: Carl-Uno Manros Subject: Re: IPP> ADM - Goals of the IPP Working Group Cc: ipp@pwg.org In-Reply-To: <199706070156.VAA09706@uscore.underscore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk At 06:56 PM 6/6/97 PDT, JK Martin wrote: >I read your message three times, but still come away confused >about exactly what disturbs you regarding recent discussions. > >Can you be a bit more explicit, please? > > ...jay > Jay, I think that Randy has already given the answer, but here I go again to make sure I am not viewed as talking in riddles: >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 above passage from the charter describes 4 sets of functions as "core functionality" for IPP. Let us examine these in relation to the SWP aka Level 1 functionality: 1) for a user to find out about a printer's capabilities This is supplied by the Get Attributes operation. The Validate operation, with a stretch of imagination, could be seen as delivering a subset, but you would have to go through a number of trial-and-error attempts using Validate in order to find out the total capabilities of a Printer. 2) for a user to submit print jobs to a printer The simple Print-Job operation does deliver this, the combination of Create-Job and Send-Document offers additional optional features. 3) for a user to find out the status of a printer or a print job This is supplied by the Get-Attributes and Get-Jobs operations. 4) for a user to cancel a previously submitted job This is supplied by the Cancel-Job operation. If Conformance Level 1 was to support only the Validate and the Print-Job operations, it is obvious that we would not deliver all of the "core functionality" required in the charter. Hence: First, we definately cannot limit the standard to only require the Validate and Print-Job operations. Secondly, I am sure that the IETF management would look unfavourably on a solution that includes less than what is describes as "core" in the charter. We can leave out some of the goodies, like multi-document jobs and print-by-reference, from the subset that MUST be supported by a conformant implementation, but I see some definate problems with leaving out the Get-Attributes and Cancel-Job operations. Thirdly, the IETF is not likely to by happy over a printing standard that has several conformance levels in general. I may be playing the devil's advocate on this, but I think this is better than for us to have a rude awakening later, when we try to get the documents through the IETF standardization process. 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 Jun 9 15:14:24 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA22279 for ipp-outgoing; Mon, 9 Jun 1997 15:08:09 -0400 (EDT) Date: Mon, 9 Jun 1997 12:09:35 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706091909.MAA01981@woden.eng.sun.com> To: ipp@pwg.org, harryl@us.ibm.com Subject: Re: IPP> PRO - A value-type field for the Protocol Spec X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Part of the reaction is the ASN.1/BER is far more complex than simple text or XDR. In addition, DPA implementations use full ASN.1/BER and the BER libraries have made significant contributions to their very large size. I don't know how much BER contributes to the size of SNMP implementations, but SNMP uses a subset of BER. Bob Herriot > From harryl@us.ibm.com Mon Jun 9 08:16:39 1997 > > I vote to keep IPP simple, but disagree that ASN.1 is a culprit. > > > ASN.1/BER is way too heavy for IPP. If we are too close to > > reinventing ASN.1 then we are way too heavy for IPP. > > The IETF Printer MIB has the support of 9 or 10 vendors, today, with > software on many diverse platforms and in 6 or 7 vendors embedded > controller product lines. I keep hearing we shouldn't "strangle" IPP > with embedded controller limitations. How then, can we claim ASN.1/BER > is too "heavy" for IPP? > > I find lack of compatibility with existing IETF standards (the debate > over "x,y resolution" for example), and the resulting redundancy, one > of the "heaviest" things about IPP. > > > >>> Harry Lewis <<< > > > --------- Forwarded by Harry Lewis/Boulder/IBM on 06/09/97 08:28 AM --------- > > ipp-owner@pwg.org > 06/06/97 08:17 PM > Please respond to rturner@sharplabs.com @ internet > > > To: ipp@pwg.org @ internet > cc: > Subject: Re: IPP> PRO - A value-type field for the Protocol Spec > > If we are mixing binary and ASCII values within our encoding and require > extensibility with regard to > names, types, and values, then this is the kind of thing ASN.1/BER was > designed for. I suggested > that we just stick with ABNF as our specification and I would have been > happy with that. However, > when we're talking about a more complete, extensible, protocol, in which > registries come into play, > I think ASN.1/BER would be a better solution. It adapts much better to > varying length TLV > (type, length, value) pair operations and allows implementations (later > versions) of a protocol to > adapt easier. (i.e., no version eschange or negotiation). > > Randy > > Scott Isaacson wrote: > > > I am sure that ASN.1 does NOT stand for "A Simple Notation One"?? ;-) > > > > And BER, wasn't that "Binary Encoding for computing Resource > > consumption"?? > > > > > > > Much of the discussion recently has been around "simplicity". Has > > IPP lost it ability to be simple? No, I don't think it has. Is it > > too > > convoluted in some areas - YES. > > > > There was a discussion a few weeks ago about whether IPP was DPA '97. > > This > > reminder was a good wake-up call, and useful in that there seemed to > > be > > immediate consensus that IPP is not intended to be too complex like > > DPA is > > considered to be. > > > > I vote keep it simple. Add value-types only if it is a value or > > keyword > > that represents a specific well know syntax as described in the > > standard > > (extensible through registration). But don't add arbitrarily > > extsensible, > > compound data structures as potential values. And don't use ASN.1 !! > > > > Scott > > > > >>> Randy Turner 06/06 12:38 PM >>> > > Prior to the San Diego meeting, I proposed using ASN.1 as a way to > > specify the protocol. This was > > to prevent us from having to "re-invent" the wheel with regards to our > > > > protocol specification. The nice > > thing about ASN.1 (and its companion BER) is that extensibility is > > easily achieved and with more > > flexibility than what has been proposed so far. I think Larry Masinter > > > > brought up the fact that ASN.1 > > might be a better approach, and if extensibility and clarity of > > specification is what is driving these > > recent discussions, then I'm curious why we are striving so hard to > > reinvent another way to do this. > > > > Randy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From ipp-archive Mon Jun 9 15:34:22 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA22814 for ipp-outgoing; Mon, 9 Jun 1997 15:30:36 -0400 (EDT) Date: Mon, 9 Jun 1997 12:32:01 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706091932.MAA01992@woden.eng.sun.com> To: ipp@pwg.org, paulmo@microsoft.com Subject: RE: IPP>MOD PRO Comments on Microsofts IPP document X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk I forgot to mention one other difference in your IPP document. In Section 8.2, you state that "a server may ignore those attributes that it does not support". The IPP group decided at the San Diego meeting that a server must reject a job if it contains an attribute that it does not recognize or if it contains an attribute value that it does not support. We wanted to make sure that a client would get what what was requested with no surprises. What do you think? Bob Herriot > From paulmo@microsoft.com Sun Jun 8 17:28:15 1997 > From: Paul Moore > To: "'Robert.Herriot@Eng.Sun.COM'" , ipp@pwg.org > Subject: RE: IPP>MOD PRO Comments on Microsofts IPP document > Date: Sun, 8 Jun 1997 17:26:46 -0700 > X-Priority: 3 > X-Mailer: Internet Mail Service (5.0.1458.30) > Content-Length: 2688 > X-Lines: 60 > > By Reference: > I do not think that all the issues of print by reference have been > thought out yet. You are right that an attribute could be added, but > this is fundamentally different from the existing print operation - I > would make it a separate operation. A print server can ignore any > attribute and still be able to print, this is not the case for a > document URL attribute. I would have "PrintThis" and "PrintThat" as two > distinct operations that a server may or may not implement. > > Attribute names: > Whatever seems correct to the group.(I was merely advising against > calling something 'Job&%Copies#*@') > > Type byte: > This was suggested to me already. I am neutral on the subject. I did not > make the change becuase it was not discussed in San Diego. There are a > few question I have on it which I would like to see discussed before > finalising. > > SetOf: > I remember the discussion - I was not sure what was agreed. I am neutral > on the topic - whatever the consensus is, I will put in. > > > -----Original Message----- > > From: Robert.Herriot@Eng.Sun.COM [SMTP:Robert.Herriot@Eng.Sun.COM] > > Sent: Friday, June 06, 1997 7:59 PM > > To: Paul Moore; ipp@pwg.org > > Subject: IPP>MOD PRO Comments on Microsofts IPP document > > > > > > I have comments about a few parts which differ from the IPP documents. > > I hope that we can resolve these differences to keep compatibility. > > > > Section 2.4. You state that you don't support print by reference, but > > your Rationale suggests you would do it the same we have proposed, > > namely > > with a job attribute which contains the document URI. Am I missing > > something? So, do you plan to support print by reference with a > > client > > supplied URI? > > > > Section 7.4. I would suggest that you look at the new wording for > > defining the characters allowed for an attribute name. The document > > should be posted by Monday. It limits names to the ASCII letters, > > ASCII digits, ASCII hyphen and ASCII underscore. > > > > Section 8. You define several different representations for attribute > > values: text, binary integers, binary boolean, binary keywords. But > > you don't include a field for value's type. This makes is hard for > > a client to know how to interpret and unknown attribute. I think > > the right solution is to keep the IPP solution where all values are > > text. Alternatively, we could all agree to add a one byte type field > > > > just before the value's length field. > > > > Section 8 (Setof): We decided at the San Diego meeting that a set of > > values would be represented by a sequence of attributes in which > > all but the first attribute name would be of 0 length. Your > > description > > omits the statement about 0 length. > From ipp-archive Mon Jun 9 15:44:25 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA23288 for ipp-outgoing; Mon, 9 Jun 1997 15:42:02 -0400 (EDT) Date: Mon, 9 Jun 1997 12:43:29 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706091943.MAA02007@woden.eng.sun.com> To: ipp@pwg.org, harryl@us.ibm.com, hastings@cp10.es.xerox.com Subject: IPP>MOD Re: "Held" is not Active [Ok if I don't include pendingHeld in "active" jobs?] X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk The email from the JobMIB group about the pending-held state made me realize that getJobs works differently depending on whether pending-held is a true state or just a sub-state of pending. GetJobs has a parameter for specifying the states of jobs to be returned and the order of these states determines the order of returned jobs. If pending-held is a sub-state, then a getJobs of jobs in the pending state will return all pending jobs whether held or not and they will be in the returned in order of printing. Thus, for example, if it is 4:50pm, a job that is held until 5pm may come before a job that is pending. If pending-held is a true state, then the parameter for getJobs must specify both pending and pending-held to get such jobs and the client must specify an order. If processing-stopped is a true state, then a client must specify both processing and processing-stopped to get processing jobs, because it doesn't know whether such jobs are stopped. Bob Herriot > From hastings@cp10.es.xerox.com Mon Jun 9 08:13:48 1997 > X-Sender: hastings@zazen > X-Mailer: Windows Eudora Pro Version 2.1.2 > Mime-Version: 1.0 > X-Priority: 2 (High) > Date: Mon, 9 Jun 1997 08:07:15 PDT > To: jmp@pwg.org, Harry Lewis > From: Tom Hastings > Subject: Re: JMP> Re: "Held" is not Active [Ok if I don't include > pendingHeld in "active" jobs?] > Sender: jmp-owner@pwg.org > X-Lines: 148 > > I agree that the jmGeneralNumberOfActiveJobs shouldn't count jobs > in the pendingHeld state so that the user gets a better idea of how > busy the printer is from the value of jmGeneralNumberOfActiveJobs. > > However, what about our two indexes which also include > the active jobs. Here is isn't so clear whether the > jmGeneralOldestActiveJobIndex should or should not include the pendingHeld > jobs. The advantage of not including them, is that they tend to get "stuck" > amongst a lot of completed jobs in the table, so that an application would > have to skip over a growing number of completed jobs. > > >jmGeneralNumberOfActiveJobs Integer32(0..2147483647), > >jmGeneralOldestActiveJobIndex Integer32(0..2147483647), > >jmGeneralNewestActiveJobIndex Integer32(0..2147483647), > > For example, at 10:00Am when I submit the job that is held until 5:00 pm > the table might look like: > > jmJobIndex State > 200 completed > 201 completed > 202 completed > ... > 330 completed > 331 processing <-- jmGeneralOldestActiveJobIndex > 332 pending > 333 pending > 334 pendingHeld - my job <-- jmGeneralNewestActiveJobIndex > > At 12:00 AM the table might look like: > > 334 pendingHeld <-- jmGeneralOldestActiveJobIndex > 450 completed > 451 completed > 452 completed > ... > 597 completed > 598 processing > 599 pending > 600 pending > 601 pending <-- jmGeneralNewestActiveJobIndex > > So the applications would have to skip over the 150 or so completed jobs. > > If we define active as no including pendingHeld, then we get: > > At 12:00 AM the table might look like: > > 334 pendingHeld > 450 completed > 451 completed > 452 completed > ... > 597 completed > 598 processing <-- jmGeneralOldestActiveJobIndex > 599 pending > 600 pending > 601 pending <-- jmGeneralNewestActiveJobIndex > > This is better for most applications. An application that wants to show > the entire queue to an operator will have to search through all the > jobs looking for pendingHeld jobs. But maybe that is a good tradeoff. > Such an application is likely to be keeping a copy of the table anyway. > > Note that at 5:00 pm, the agent has to cause the jmGeneralOldestActiveJobIndex > to be set back to 334, when my job changes from pendingHeld to pending. > > Also note that an implementation that moves pending jobs to pendingHeld > when the resources are changed on the device will have to fiddle with > jmGeneralOldestActiveJobIndex as well, to keep it pointing at the oldest > active job. > > So I'll change the definition of active to not include pendingHeld. > (and remove the active in-active from the picture, since it doesn't > cleanly divide. > > > At 14:02 06/06/97 PDT, Harry Lewis wrote: > >The problem I have with held meaning active is that is messes up the concept of > >"number of intervening jobs". If I'm testing the waters at 9am for a printer > >with least number of intervening jobs, I will get a false impression if the > >printer tells me about all the jobs which are held until midnight. > > > >I think held jobs are, indeed, inactive. > > > >>>> Harry Lewis <<< > > > > > >------ Forwarded by Harry Lewis/Boulder/IBM on 06/06/97 02:43 PM ------ > > > > jmp-owner@pwg.org > > 06/05/97 07:00 PM > >Please respond to jmp-owner@pwg.org @ internet > > > > > >To: Harry Lewis/Boulder/IBM@IBMUS > >cc: jmp@pwg.org @ internet > >Subject: JMP> Re: "Held" is not Active > > > >I don't remember the discussion. > > > >The definition of which job states include "active" has affect on the > >following objects: > > > >jmGeneralNumberOfActiveJobs Integer32(0..2147483647), > >jmGeneralOldestActiveJobIndex Integer32(0..2147483647), > >jmGeneralNewestActiveJobIndex Integer32(0..2147483647), > > > >I had assumed that the fact that a job was in the 'held' state still > >meant that it would be included in the jmGeneralNumberOfActiveJobs, > >since 'held' is just a variant of the 'pending' state > >(though you could make an argument that a held job isn't as likely > >to be processed as other jobs that are pending and so shouldn't be included > >in the count of active jobs which is an indication of the business of the > >printer). > > > >On the other hand, an application that is using the OldestActiveJobIndex > >might not want to miss jobs that are in the 'held' state. Similarly, > >when an idle printer accepts a job that is in the 'held' state, I don't think > >we want the agent to keep the NewestActiveJobIndex at 0. > > > >So I thought it was simpler to include 'held' jobs as active. So all the > >states on the left of the picture are the "active" states, and the > >three terminal states on the right of the picture are in-active states. > > > >Ok? > > > >Tom > > > >At 10:16 06/05/97 PDT, Harry Lewis wrote: > >>Tom, > >> > >>>So how does this picture look to you for IPP and JMP (IPP wouldn't > >>>have the enums and wouldn't have the "active/in-active" line, since > >>>it is a JMP-only term). > >> > >>I thought we agreed, in Austin, that Held was not Active. > >> > >>Harry Lewis - IBM Printing Systems > >> > >> > > > > > > > > > > > > > > From ipp-archive Mon Jun 9 15:54:24 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA23770 for ipp-outgoing; Mon, 9 Jun 1997 15:51:09 -0400 (EDT) Mime-Version: 1.0 Date: Mon, 9 Jun 1997 16:35:32 -0400 Message-ID: <000190AC.1337@digprod.com> From: cgordon@digprod.com (Charles Gordon) Subject: Re[2]: IPP> PRO - A value-type field for the Protocol Spec To: 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 ASN.1 and BER are designed to handle any conceivable data type. However, that flexibility comes at a high price. I have happen to have been working on code to encode and decode SNMP packets the last few weeks. So, I can tell you from personal experience that BER encoding is very inefficient and also more than a little bit complex. I doubt that we really need to use BER for the stuff we are doing with IPP. As someone who is actually writing code that deals with BER, IMHO BER is not worth the price in complexity (bugs). A agree with Scott Isaacson that if we get to the point where BER encoding 'makes sense', then IPP is in deep trouble. Perhaps instead of trying to come up with encoding schemes to handle more and more complexity, we should try to take a step backwards and make the system simpler. In my experience, complexity is usually a sign of a bad design. --- Charles ______________________________ Reply Separator _________________________________ Subject: Re: IPP> PRO - A value-type field for the Protocol Spec Author: Robert.Herriot@Eng.Sun.COM (Robert Herriot) at Internet Date: 6/9/97 12:09 PM Part of the reaction is the ASN.1/BER is far more complex than simple text or XDR. In addition, DPA implementations use full ASN.1/BER and the BER libraries have made significant contributions to their very large size. I don't know how much BER contributes to the size of SNMP implementations, but SNMP uses a subset of BER. Bob Herriot > From harryl@us.ibm.com Mon Jun 9 08:16:39 1997 > > I vote to keep IPP simple, but disagree that ASN.1 is a culprit. > > > ASN.1/BER is way too heavy for IPP. If we are too close to > > reinventing ASN.1 then we are way too heavy for IPP. > > The IETF Printer MIB has the support of 9 or 10 vendors, today, with > software on many diverse platforms and in 6 or 7 vendors embedded > controller product lines. I keep hearing we shouldn't "strangle" IPP > with embedded controller limitations. How then, can we claim ASN.1/BER > is too "heavy" for IPP? > > I find lack of compatibility with existing IETF standards (the debate > over "x,y resolution" for example), and the resulting redundancy, one > of the "heaviest" things about IPP. > > > >>> Harry Lewis <<< > > > --------- Forwarded by Harry Lewis/Boulder/IBM on 06/09/97 08:28 AM --------- > > ipp-owner@pwg.org > 06/06/97 08:17 PM > Please respond to rturner@sharplabs.com @ internet > > > To: ipp@pwg.org @ internet > cc: > Subject: Re: IPP> PRO - A value-type field for the Protocol Spec > > If we are mixing binary and ASCII values within our encoding and require > extensibility with regard to > names, types, and values, then this is the kind of thing ASN.1/BER was > designed for. I suggested > that we just stick with ABNF as our specification and I would have been > happy with that. However, > when we're talking about a more complete, extensible, protocol, in which > registries come into play, > I think ASN.1/BER would be a better solution. It adapts much better to > varying length TLV > (type, length, value) pair operations and allows implementations (later > versions) of a protocol to > adapt easier. (i.e., no version eschange or negotiation). > > Randy > > Scott Isaacson wrote: > > > I am sure that ASN.1 does NOT stand for "A Simple Notation One"?? ;-) > > > > And BER, wasn't that "Binary Encoding for computing Resource > > consumption"?? > > > > > > > Much of the discussion recently has been around "simplicity". Has > > IPP lost it ability to be simple? No, I don't think it has. Is it > > too > > convoluted in some areas - YES. > > > > There was a discussion a few weeks ago about whether IPP was DPA '97. > > This > > reminder was a good wake-up call, and useful in that there seemed to > > be > > immediate consensus that IPP is not intended to be too complex like > > DPA is > > considered to be. > > > > I vote keep it simple. Add value-types only if it is a value or > > keyword > > that represents a specific well know syntax as described in the > > standard > > (extensible through registration). But don't add arbitrarily > > extsensible, > > compound data structures as potential values. And don't use ASN.1 !! > > > > Scott > > > > >>> Randy Turner 06/06 12:38 PM >>> > > Prior to the San Diego meeting, I proposed using ASN.1 as a way to > > specify the protocol. This was > > to prevent us from having to "re-invent" the wheel with regards to our > > > > protocol specification. The nice > > thing about ASN.1 (and its companion BER) is that extensibility is > > easily achieved and with more > > flexibility than what has been proposed so far. I think Larry Masinter > > > > brought up the fact that ASN.1 > > might be a better approach, and if extensibility and clarity of > > specification is what is driving these > > recent discussions, then I'm curious why we are striving so hard to > > reinvent another way to do this. > > > > Randy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From ipp-archive Mon Jun 9 15:59:24 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA23797 for ipp-outgoing; Mon, 9 Jun 1997 15:55:21 -0400 (EDT) Message-ID: <41135C785691CF11B73B00805FD4D2D702B7CE88@RED-17-MSG.dns.microsoft.com> From: Paul Moore To: "'JK Martin'" Cc: ipp@pwg.org Subject: RE: IPP>MOD PRO Comments on Microsofts IPP document Date: Mon, 9 Jun 1997 12:55:22 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.30) Sender: ipp-owner@pwg.org Precedence: bulk Main By reference issues: 1. Some servers may not want to do it (memory overhead in prnter for example) 2. Security - how does the server gain access to the resources. NT can do it with impersonation but that is not a generic solution. Type Byte: 1 having a type byte implies that any attribute can have any format - in the original design an attribute had a defined format. THis made it simple for a server. What happens if an attribute has a type that the server does not expect? Or should we define a set of allowed types for each attribute. 2. The main discussion seemed to be around allowing structured types (address). What are these structured types? > -----Original Message----- > From: JK Martin [SMTP:jkm@underscore.com] > Sent: Monday, June 09, 1997 11:12 AM > To: Paul Moore > Cc: ipp@pwg.org > Subject: RE: IPP>MOD PRO Comments on Microsofts IPP document > > Paul, > > Thanks for responding to Bob Herriot's questions. > > > By Reference: > > I do not think that all the issues of print by reference have been > > thought out yet. > > Can you shed some light on those issues not yet thought out? Are > there > other considerations/constraints that have not yet been presented on > this list that we should discuss? > > > > Type byte: > > This was suggested to me already. I am neutral on the subject. I did > not > > make the change becuase it was not discussed in San Diego. There are > a > > few question I have on it which I would like to see discussed before > > finalising. > > What are the questions you have about typing as it has been proposed? > We should start discussing those questions immediately, given the > current date of this effort. > > Whatever you and your colleagues at Microsoft can do to help further > the development of this standard would be greatly appreciated by all > the IPP participants. > > ...jay From ipp-archive Mon Jun 9 16:15:00 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA24668 for ipp-outgoing; Mon, 9 Jun 1997 16:08:09 -0400 (EDT) From: Roger K Debry To: Subject: Re[2]: IPP> Common concerns regarding the SWP proposal Message-Id: <5030100003338186000002L062*@MHS> Date: Mon, 9 Jun 1997 16:10:12 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Isn't this what our Mandatory and conditionally mandatory attributes are all about? 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 06/09/97 02:04 PM --------------------------- ipp-owner @ pwg.org 06/09/97 11:19 AM Please respond to ipp-owner@pwg.org @ internet To: ipp @ pwg.org @ internet cc: Subject: Re[2]: IPP> Common concerns regarding the SWP proposal Carl-Unos and Scott appear to suggest the that IPP standard should include all the features the group feels are desirable; and that specific implementations may have "null" implementations of these features. Aside from the time necessary to properly define this complete set of features, and the time necessary to get approval, the following message on the IETF-FAX list (in response to perhaps a similar situation in internet fax) points out a potential problem to this approach which sould be addressed. It might be appropriate for the IPP's IETF guides to comment on this. Bill Wagner, Osicom/DPI ______________________________ Forward Header _____________________________ Subject: Re: JWK and Wordcraft support for legacy fax machines - UniB Author: Ned Freed at Internet Date: 6/9/97 9:13 AM >Confusion of standards and implementations again. Standards define the set >of functions, implementations may opt for a sub-set.The key is to define a >full set to start with and then let people do their own thing in terms of >the sub-set they select. I agree that this is how the ISO and ITU standards process works.It is not, however, how the IETF standards process works. IETF standards attempt to standardize the minimum amount of stuff needed to get the job done and no more. And if subsequent implementation experience shows that some features end up being unimplemented and hence don't interoperate they will be removed from the standard as it proceeds down the standards path. At the heart of all this is the IETF requirement that each feature of a standard has to be shown to (1) interoperate between multiple implementations and (2) not have any known interoperability problems before the standard can advance in grade. Fine,you say,but why does this rule preclude me from writing a standard with lots of stuff in it and then trimming the stuff that sees insufficient implementation later on? The answer is that while the process may formally allow this, the long-time participants in the process have a strong bias against it, and you will have the devil's own job getting rough consensus on documents that are written this way. The "rough consensus and running code" line often sounds silly to people who hail from the ISO or ITU communities (I used to be such a person, BTW) but here these are words to live by. When MIME was first designed there were no less than three separate implementations of every feature in the standard (one by me, one by Marshall Rose, and one by Nathaniel Borenstein) that were done as the standard was being written and were kept up to date as the standard changed. And even though we effectively met the implementation requirements for a move to full standard status before RFC1341 even came out, we've still have to trim any number of features out of MIME, and I suspect that several more will have to go before we are allowed to move it to full standard. Ned ______________________________ Reply Separator _________________________________ Subject: Re: IPP> Common concerns regarding the SWP proposal Author: Scott Isaacson at Internet Date: 6/6/97 1:43 PM Good summary Jay.. ************************************************************ 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 06/05 6:47 PM >>> > 1. Does not support multiple documents No mandatory support for all implementations. Add a simple attribute to the printer that is a boolean "multiple-documents-supported" = True or False. If False, expect an error code back on Create-Job or Send-Document. Maybe even put this in the directroy schema. Do end users want to find printers that can print multiple documents per job? I don't know. > 2. Does not support Print-by-Reference Add s simple attribute to the printer that says "print-by-reference-supported" = True or False. If False, don't expect a URL as document content to work. If True, what gets printed is what gets printed no guarantee and if you send in an FTP URL and the given instance of a Printer does not support it, you get an error message. > 3. Does not support job status queries Has always sounded to me like a basic query to a Printer or a Job is essential. I believe this is fundamental. Sure, you could always do a GET on a url with an accept header of text/html and get back a browser view, but this need not be a requirement. SWP does not mandate that this be a requirement. However, a requirement would be to support an POST with an application/ipp PDU in it. The number of MANDATORY requirements is SO small here, I don't see a problem with supporting the operation for all implemntations given that you have a web server already (doing the GET accepting text/html that is). > 4. Does not support job cancellation by the requesting user Seems fundamental to me. If you support an HTML form version of this, it would be like litterally 10 lines of code to add the POST application/IPP version. > 5. Uses binary-encoded data for simple information normally encoded > in text for HTTP-related transactions In our prototype, we just finished up a Java application that tried to process attributes encoded as: namevalue (case 2) rather than as name ":" value CRLF (case 1) We ran both versions on 3 attributes, 30 attributes, and 300 attributes. The goal was to measure the actuall difference in processing time for a dumb, interpreted java application to do one or the other. The times seem slow (we just did a quick an dirty hack with no optimizations, kept the buffering I/O the same, just modified the algorithm) Encoding 30 attributes (varying name lengths, varying value lenghts), 50 runs, avg. Case 1: .1375 seconds Case 2: .1525 seconds Decoding 30 attributes (varying name lengths, varying value lenghts), 50 runs, avg. Case 1: .0975 seconds Case 2: .0825 seconds Sure enough, case 2 was "quicker" but as been said many times before: "This is printing we are talking about, and at MOST 30 attributes we are talking about" Ease of use and extensibility and portability etc are so much easier with a non-binary encoding of lengths. It just doesn't buy you very much. Interesting node, encoding actually took longer with case 2? You actually have to compute the length in order to encode the length! Looking at both sides (encoder/decoder), it seems to come out a wash with binary encoding or not. The point in posting this data is not to get into a war about "we'll I could do it faster ..." but just to look at the RELATIVELY MINOR overhead of 30 attributes compared to a 4 meg color RIP process!!! Please, let's not have two conformance levels. Let's NOT force everyone to do do everything, but let's not fragement the standard. We have all failed if we do. Scott Isaacson From ipp-archive Mon Jun 9 17:39:24 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA26084 for ipp-outgoing; Mon, 9 Jun 1997 17:35:30 -0400 (EDT) Message-ID: <339C6343.F67@parc.xerox.com> Date: Mon, 9 Jun 1997 13:10:43 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> extensibility Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk For good extensibility and interoperability, you need both manditory parameters ("reject this job if you don't understand this parameter") and optional ones ("if you don't understand this, just ignore it"). A recipient must be able to tell just by examining the attribute which class it is in. I thought this was part of the whole job/PDL parameter override issue, but it looks like I must have missed something. Larry From ipp-archive Mon Jun 9 17:39:25 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA26090 for ipp-outgoing; Mon, 9 Jun 1997 17:35:34 -0400 (EDT) Message-ID: <339C6829.101@parc.xerox.com> Date: Mon, 9 Jun 1997 13:31:37 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> Re: PP> PRO - A value-type field for the Protocol Spec References: <01BC74D4.146E6840@bronze> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Just to clarify, since someone said: > > I think Larry Masinter > > brought up the fact that ASN.1 > > might be a better approach ... I did not intend to assert that "ASN.1 might be a better approach" out of context. I would like to assert that if you continue to add complexity to what was originally a simple attribute/value representation, that you would wind up with something with all the complexity of ASN.1 and none of the compatibility. However, if you want to go back to an ASCII protocol, the "name: value" syntax has a number of difficulties with extended values and structures that make it actually more complex to deal with in the long run. The simple test of namevalue vs name: value parsing doesn't really test the issue: what if there are values that are really long? Or have some structure in them? Or 'continuation lines'? Is it always line oriented? What about values that are themselves name-value pairs? So, if you want an ASCII protocol, consider something like XML, which is set up to deal with nesting. Larry -- http://www.parc.xerox.com/masinter From ipp-archive Mon Jun 9 18:34:25 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA27445 for ipp-outgoing; Mon, 9 Jun 1997 18:30:41 -0400 (EDT) Date: Mon, 9 Jun 1997 15:31:53 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706092231.PAA02204@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, ipp@pwg.org, paulmo@microsoft.com Subject: RE: IPP>MOD PRO Comments on Microsofts IPP document X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk You said that you are neutral on the subject of a type byte. Does that mean that if we have no type byte that you are willing to have all values be represented by text? Currently, some of your attributes are text and others are binary. That is a problem if there is no type byte. It seems to me that having no type byte and having all values be represented by text is the simplest solution. Bob Herriot > From paulmo@microsoft.com Sun Jun 8 17:28:15 1997 > > > Type byte: > This was suggested to me already. I am neutral on the subject. I did not > make the change becuase it was not discussed in San Diego. There are a > few question I have on it which I would like to see discussed before > finalising. > > > > > Section 8. You define several different representations for attribute > > values: text, binary integers, binary boolean, binary keywords. But > > you don't include a field for value's type. This makes is hard for > > a client to know how to interpret and unknown attribute. I think > > the right solution is to keep the IPP solution where all values are > > text. Alternatively, we could all agree to add a one byte type field > > just before the value's length field. > > From ipp-archive Mon Jun 9 19:29:25 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA27987 for ipp-outgoing; Mon, 9 Jun 1997 19:25:24 -0400 (EDT) Message-Id: <3.0.1.32.19970609161848.00a82410@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 9 Jun 1997 16:18:48 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Agenda for PWG IPP Phone Conference on June 11, 1 - 3:30 PST Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Agenda for PWG IPP Phone Conference on June 11, 1 - 3:30 PST - Discussion about conformance subsets: How many subsets: Zero, One, or Two? Scope of subset(s), if more than Zero? How many protocol mapping documents: One or Two? - Subgroup reports, in particular when can we expect to see more IETF I-Ds? - Plan agendas for Protocol meeting on June 17 and IPP meeting on June 25-26 --- Number: 1-423-523-7162 Access Code: 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 Mon Jun 9 20:14:26 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA28505 for ipp-outgoing; Mon, 9 Jun 1997 20:10:09 -0400 (EDT) Date: Mon, 9 Jun 1997 17:11:35 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706100011.RAA02373@woden.eng.sun.com> To: ipp@pwg.org Subject: RE: IPP>MOD PRO Comments on Microsofts IPP document X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk > From paulmo@microsoft.com Mon Jun 9 16:49:30 1997 > > I don't think having all values as text helps. Somebody said that they > wanted to support structured types, a string does not do that. Also > having things as text requires more specifications (are leading > /trailing spaces allowed on a number for example?) The IPP text representation doesn't have structured values, but it does prescribe the representation for various types, such as integer, date and text. Issues like leading/trailing spaces are a lot easier to deal with than having a client try to figure out whether to interpret the octets of an unknown attribute as text or binary. I believe that we need to deal with extensibility where a client may need to display attributes that it doesn't understand. Bob Herriot > > > -----Original Message----- > > From: Robert.Herriot@Eng.Sun.COM [SMTP:Robert.Herriot@Eng.Sun.COM] > > Sent: Monday, June 09, 1997 3:32 PM > > To: Robert.Herriot@Eng.Sun.COM; ipp@pwg.org; Paul Moore > > Subject: RE: IPP>MOD PRO Comments on Microsofts IPP document > > > > You said that you are neutral on the subject of a type byte. Does > > that mean that if we have no type byte that you are willing to > > have all values be represented by text? Currently, some of your > > attributes are text and others are binary. That is a problem if > > there is no type byte. > > > > It seems to me that having no type byte and having all values be > > represented > > by text is the simplest solution. > > > > Bob Herriot > > > > > From paulmo@microsoft.com Sun Jun 8 17:28:15 1997 > > > > > > > > > > > Type byte: > > > This was suggested to me already. I am neutral on the subject. I did > > not > > > make the change becuase it was not discussed in San Diego. There are > > a > > > few question I have on it which I would like to see discussed before > > > finalising. > > > > > > > > > > > Section 8. You define several different representations for > > attribute > > > > values: text, binary integers, binary boolean, binary keywords. > > But > > > > you don't include a field for value's type. This makes is hard > > for > > > > a client to know how to interpret and unknown attribute. I > > think > > > > the right solution is to keep the IPP solution where all values > > are > > > > text. Alternatively, we could all agree to add a one byte type > > field > > > > just before the value's length field. > > > > > From ipp-archive Mon Jun 9 20:29:32 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA28980 for ipp-outgoing; Mon, 9 Jun 1997 20:23:26 -0400 (EDT) Message-ID: <339C9FC2.61BA9D2@sharplabs.com> Date: Mon, 09 Jun 1997 17:28:50 -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> Protocol minutes - 6/9/97 X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Precedence: bulk A brief summary of topics discussed at the 6/9 protocol teleconference: Attendees: Carl-Uno Manros Scott Isaacson Peter Zehler Harry Lewis Tom Hastings Randy Turner Keith Carter Roger DeBry * Steve Zilles' proposal for adding an attribute data type field was discussed. The call participants agreed that it was possible to achieve the same level of extensibility by having an external registry (possibly IANA) to catalog attribute names and attribute types, but the group felt that including the attribute type in the actual wire encoding served no benefit. * A couple of problem issues with the latest IPP draft by Paul Moore were discussed. One was the fact that one of the attribute names (Job-Originator) was named differently than the equivalent attribute in the model document. The other was the fact that the 'document-format' attribute used PDL enumerations from RFC 1759, unlike the model document which specifies MIME tags. One other issue concerning this draft was the fact that the document self-references itself as IPP1, or IPP level 1. This could be misconstrued by readers of this document as version 1 of the IPP protocol, given that a version 1 and version 2 of IPP are mentioned by the IPP model document. Someone reading the model document, followed by the SWP/IPP document by assume that IPP1 documents version 1 of the protocol. Overall, it was hoped that the document would be rolled into a single IPP-over-HTTP document to be delivered to the IETF as a proposed standard. As a result of the last IETF plenary meeting in San Diego, it was felt that any more than one protocol document submitted would not be favorably received. * There was some brief discussion on reconciling the IPP model document with the model and semantics of both the Job MIB and the Printer MIB. Since these are all products of the PWG, ideally they should speak from the same model and give basically the same 'message' to the printing industry. * Also, several other IETF standards-track protocols are being co-developed with a companion MIB document that identifies manageable objects that can be remotely configured via SNMP. At a minimum, we should try to identify manageable objects that administrators might want to access for a IPP server for configuration and monitoring of an IPP service. No volunteers stepped forward when a query was made to check interest (big surprise, huh?) Randy From ipp-archive Mon Jun 9 20:54:26 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA29506 for ipp-outgoing; Mon, 9 Jun 1997 20:54:02 -0400 (EDT) Message-Id: <3.0.1.32.19970609174724.00a75df0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 9 Jun 1997 17:47:24 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - New version of the IPP FAQ document Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Hi, I have just gone over and updated our IPP FAQ document. You can get it either from our web page or from the charter folder on the FTP server. It is called charter.txt, there are no other formats. If you have any comments, please let me know. 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 Jun 10 17:54:39 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA02703 for ipp-outgoing; Tue, 10 Jun 1997 17:54:30 -0400 (EDT) Message-Id: <3.0.1.32.19970610144728.00ab9380@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 10 Jun 1997 14:47:28 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Munich IETF Meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk The first draft agenda for Munich is now available from: ftp://ftp.ietf.org/ietf/0mtg-agenda.txt None of the Application area meetings are yet scheduled, so we still don't have a clue when our IPP time slots will happen. 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 Jun 10 19:29:40 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA05396 for ipp-outgoing; Tue, 10 Jun 1997 19:28:00 -0400 (EDT) Message-Id: <3.0.1.32.19970610162111.00ab9e30@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 10 Jun 1997 16:21:11 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC - PWG Phone Conference on IPP Security - June 12, 1 - 3 PST Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk We did not have enough participants to make last week's SEC phone conference happen. Here we go again, with the same agenda as last week: ----- PWG Phone Conference on IPP Security - June 12, 1 - 3 PST Agenda Finish review and comment on Roger's latest Security draft text (look out for a new draft text on Wednesday) Finish work on security attributes that we need to include in the Directory Schema and Protocol documents. 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 Jun 11 04:14:49 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA07186 for ipp-outgoing; Wed, 11 Jun 1997 04:12:24 -0400 (EDT) Message-Id: <9706110812.AA04474@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, 11 Jun 1997 01:09:59 PDT To: ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: IPP> Final IPP/JMP job-state and job-state-reasons Sender: ipp-owner@pwg.org Precedence: bulk I've cross posted the final updates IPP and JMP job-state and job-state-reasons specifications with the final agreements reached on the June 6 telecon. I've incorporated the JMP specifications into the MIB. Scott will integrate the IPP specifications into the Model document. ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 57826 Jun 11 07:45 jobstate.pdf -rw-r--r-- 1 pwg pwg 41694 Jun 11 07:45 jobstate.txt -rw-r--r-- 1 pwg pwg 92160 Jun 11 07:46 jobstatr.doc -rw-r--r-- 1 pwg pwg 109555 Jun 11 07:48 jobstatr.pdf -rw-r--r-- 1 pwg pwg 114072 Jun 11 07:49 jobstatr.pdr ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ -rw-r--r-- 1 pwg pwg 57856 Jun 11 07:55 jobstate.doc -rw-r--r-- 1 pwg pwg 57826 Jun 11 07:55 jobstate.pdf -rw-r--r-- 1 pwg pwg 41694 Jun 11 07:56 jobstate.txt -rw-r--r-- 1 pwg pwg 92160 Jun 11 07:57 jobstatr.doc -rw-r--r-- 1 pwg pwg 109555 Jun 11 07:58 jobstatr.pdf -rw-r--r-- 1 pwg pwg 114072 Jun 11 07:59 jobstatr.pdr jobstatr.doc is the revision marks from the last Internet-Drafts of each. jobstatr.pdr is red revision marks jobstatr.pdf is black revision marks jobstate.doc is without revision marks jobstate.pdf is without revision marks Here is the beginning of the jobstate.doc file that list the changes: Subject: IPP and JMP agreements on job-state and job-state-reasons From: Tom Hastings Date: 6/6/97 File: jobstatr.doc (with revision marks) jobstate.doc (without revisions) This document is the final updated IPP "job-state" and "job-state-reasons" attributes and the corresponding JMP jmJobState and jmJobStateReasons1 objects from the IPP telecon, of Friday, June 6. 1. We agreed to the following states for IPP and JMP: IPP JMP other(1) 'unknown' unknown(2) 'pending' pending(3) 'pending-held' pendingHeld(4) 'processing' processing(5) 'processing-stopped' proessingStopped(6) 'canceled' canceled(7) 'aborted' aborted(8) 'completed' completed(9) 2. We agreed on the simplified job state transition diagram sentence at the end explaining the transitions into the canceled state that are not shown: For JMP: The following figure shows the normal job state transitions: +----> canceled(7) / +----> pending(3) ---------> processing(5) -------+------> completed(9) | ^ ^ \ --->+ | | +----> aborted(8) | v v / +----> pendingHeld(4) processingStopped(6) ----+ Figure 1 - Normal Job State Transitions Normally a job progresses only from left to right. Other state transitions are unlikely, but are not forbidden. Not shown are the transitions to the canceled state from the pending, pendingHeld, processing, and processingStopped states. Jobs in the pending, processing, and processingStopped states are called 'active', while jobs in the pendingHeld, canceled, aborted, and completed states are called 'in-active'." For IPP: The following figure shows the normal job state transitions: +--> canceled / +---> pending --------> processing ---------+-----> completed | ^ ^ \ --->+ | | +---> aborted | v v / +---> pending-held processing-stopped ----+ Figure 2 - Normal Job State Transitions Normally a job progresses only from left to right. Other state transitions are unlikely, but are not forbidden. Not shown are the transitions to the 'canceled' state from the 'pending', 'pending-held', 'processing', and 'processing-stopped' states." 3. Conformance: we agreed that no job states are MANDATORY. For JMP the sentence proposed by Ron will be added: All possible enums for this object SHALL be reported if implemented by the device and available to the agent. The corresponding sentence for IPP will be: All possible job states SHALL be returned by the Printer object if implemented by the output device and available to the Printer object implementation. 4. We agreed to not specify which job state reasons go with which states. An implementation can use the reasons with any state for which the reason makes sense. The following JMP sentence will be included in the JmJobStateReasons1TC textual-convention: The following standard values are defined (in hexadecimal) as powers of two, since multiple values may be used at the same time. These values MAY be used with any job state for which the reason makes sense. The corresponding IPP "job-state-reasons" attribute sentence is: The following standard values are defined and MAY be used with any job state for which the reason makes sense. 5. We agreed that job-state-reasons are all OPTIONAL. The following JMP sentence will be included in the JmJobStateReasons1TC textual-convention: Implementation of these values is OPTIONAL, i.e., an agent NEED NOT implement them, even if the device supports the functionality represented by the reason and is available to the agent. The corresponding IPP "job-state-reasons" attribute sentence is: Implementation of these values is OPTIONAL, i.e., the Printer object NEED NOT return them, even if the output device supports the functionality represented by the reason and is available to the Printer object software. The following are the changes from the previous IPP and JMP published Internet-Draft specifications: 1. In JMP remove the 'printing' state. 2. Add the 'pending-held' and 'processing-stopped' states to IPP. 3. Rename the JMP 'held' state to 'pendingHeld' and rename the JMP state 'needsAttention' to 'processingStopped'. 4. In both IPP and JMP add the 'aborted' state and make it a final state. 5. In both IPP and JMP remove the 'aborted-by-system' job-state-reason, since the new 'aborted' state says it all. 6. 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. 7. Since the pendingHeld state has been added, JMP no longer needs a generic jobHeld job state reason. 8. No job states are MANDATORY in IPP and JMP. However, those that are implemented in the device and are available to the Printer/agent shall be returned. 9. Job state reasons are OPTIONAL in IPP and JMP. From ipp-archive Wed Jun 11 09:19:49 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA08406 for ipp-outgoing; Wed, 11 Jun 1997 09:18:41 -0400 (EDT) From: Roger K Debry To: Subject: IPP> New Security draft Message-Id: <5030100003411281000002L012*@MHS> Date: Wed, 11 Jun 1997 09:20:39 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk I have posted a new draft of the security document on the PWG site. Unless there are significant comments this will be the version that will be posted as an updated Internet-Draft. We will discuss the document during the security telecon on thursday. Email comments are also welcome. If possible, please use the line numbers in the .pdf version for your comments. The document is at: ftp.pwg.org/pub/pwg/ipp/new_SEC/sec4.doc ftp.pwg.org/pub/pwg/ipp/new_SEC/sec4.ps ftp.pwg.org/pub/pwg/ipp/new_SEC.pdf 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 Jun 11 09:54:49 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA08929 for ipp-outgoing; Wed, 11 Jun 1997 09:52:50 -0400 (EDT) From: Roger K Debry To: Subject: IPP>MOD - Print by reference Message-Id: <5030100003412469000002L092*@MHS> Date: Wed, 11 Jun 1997 09:54:47 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk There has been quite a storm of email on the print by reference subject lately. Let me once again define what I believe to be a very significant customer requirement that print by reference can satisfy. In very carefully fencing this requirement it is important to say what it is not. It is NOT printing web pages. Much of the concern I have seen expressed in recent email, especially from HP, has to do with printing web pages. I agree that chasing links and dealing with the multitude of data types on the web is very complex and could potentially bloat a Printer implementation. It is NOT printing documents that require some security mechanism to access them. In particular it does not deal with the printing of documents where the right to print a copy of the document must be purchased. As Larry Masinter has suggested, the protocol may reserve some "space" to encode credentials for such transactions, but I do not want to complicate the model nor hold up approval of IPP as a standard trying to architect and get approval of these security mechanisms. There are at least two examples of what I think print by reference is for version one of IPP: First, consider the case of documents, such as Internet-Drafts, or those documents which we have on the PWG ftp site which are accessible by anonymous ftp, i.e. they are "publically accessible". Print by reference is a powerful tool for printing such documents. Documents are in some print-ready format, such as Postscript. Second, consider the case where an enterprise keeps a library of documents (standards, reports, procedures, etc) on a central repository that is accessible by anyone within the enterprise firewall. It would probably be on a private internal network. Print by reference is again a very powerful tool for printing such documents which are in some print-ready format. To summarize, this simple version of print-by-reference only requires that the documents to be fetched are already formatted for printing. The Printer does not deal with links, it does not format pages, it does not deal with dynamic web formats, etc. 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 Jun 11 10:14:49 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA09444 for ipp-outgoing; Wed, 11 Jun 1997 10:12:34 -0400 (EDT) From: don@lexmark.com Message-Id: <199706111412.AA17940@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Wed, 11 Jun 1997 10:03:13 -0400 Subject: Re: IPP>MOD - Print by reference Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: bulk I have been listening to this discussion for a long time and I recognize the need for a human being to be able to print by reference. This function can be easily provided with HTML, etc on a Web page hosted by an IPP print server (actually IPP is not even needed for this solution.) Is the need as pressing for this to be done programmatically? The bottom line is can this function be provided outside the scope of the IPP protocol? If the programmatic need is strong, is it sufficient to standardize the way this is done with HTML so that once the URL of a print by reference page is know, a print by reference job can be submitted to it under program control? This could just be part of a multi-pronged standard approach. Instead of defining an all encompassing IPP standard, maybe we should look at this from a difference perspective. Do we really need: 1) An IPP Job Submission protocol -and- 2) An IPP Print by Reference standard -and- 3) An IPP Job Management protocol -and- 4) An IPP Print Capability Discovery protocol etc, etc, etc. I know "compliance levels" and print by reference are not strictly related but I would like to be able to define all these functions in a standard way without requiring "compliance levels" or burdening the lowest implementation with too much baggage. ... all right... fire away!! Don From ipp-archive Wed Jun 11 10:29:50 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA10118 for ipp-outgoing; Wed, 11 Jun 1997 10:29:14 -0400 (EDT) From: Roger K Debry To: Subject: Re: IPP>MOD - Print by reference Message-Id: <5030100003414313000002L032*@MHS> Date: Wed, 11 Jun 1997 10:31:11 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Don, I got lost trying to follow your first paragraph. Perhaps you can provide more details. Maybe its just to early in the morning for me! :-) In all of the discussions we have had on this subject, we have agreed that IPP only defines the way a reference is included in the print request. It does not define the mechanism by which the Printer actually fetches the document. If the document reference is a URI, then I assume the Printer would use the method inferred by the URI, e.g. ftp or http. 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 06/11/97 08:22 AM --------------------------- ipp-owner @ pwg.org 06/11/97 08:23 AM Please respond to ipp-owner@pwg.org @ internet To: ipp @ pwg.org @ internet cc: Subject: Re: IPP>MOD - Print by reference I have been listening to this discussion for a long time and I recognize the need for a human being to be able to print by reference. This function can be easily provided with HTML, etc on a Web page hosted by an IPP print server (actually IPP is not even needed for this solution.) Is the need as pressing for this to be done programmatically? The bottom line is can this function be provided outside the scope of the IPP protocol? If the programmatic need is strong, is it sufficient to standardize the way this is done with HTML so that once the URL of a print by reference page is know, a print by reference job can be submitted to it under program control? This could just be part of a multi-pronged standard approach. Instead of defining an all encompassing IPP standard, maybe we should look at this from a difference perspective. Do we really need: 1) An IPP Job Submission protocol -and- 2) An IPP Print by Reference standard -and- 3) An IPP Job Management protocol -and- 4) An IPP Print Capability Discovery protocol etc, etc, etc. I know "compliance levels" and print by reference are not strictly related but I would like to be able to define all these functions in a standard way without requiring "compliance levels" or burdening the lowest implementation with too much baggage. ... all right... fire away!! Don From ipp-archive Wed Jun 11 11:09:53 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA10879 for ipp-outgoing; Wed, 11 Jun 1997 11:07:27 -0400 (EDT) Date: Wed, 11 Jun 1997 09:00:07 PDT From: "Caruso,Angelo" Subject: IPP> RE: JMP> Final IPP/JMP job-state and job-state-reasons To: ipp@pwg.org, jmp@pwg.org Message-id: <1CBE9E3381262D791CBE9E3381262D79#064#x-wb-0311-ms1.xerox@SMF> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Posting-date: Wed, 11 Jun 1997 11:16:40 -0400 Priority: normal Hop-count: 3 Sender: ipp-owner@pwg.org Precedence: bulk Tom wrote: > 5. We agreed that job-state-reasons are all OPTIONAL. > > The following JMP sentence will be included in the JmJobStateReasons1TC > textual-convention: > > Implementation of these values is OPTIONAL, i.e., an agent NEED NOT > implement them, even if the device supports the functionality represented by > the reason and is available to the agent. The last part of the last sentence here, "i.e., an agent NEED NOT implement them, even if the device supports the functionality represented by the reason and is available to the agent", is pratically encouraging implementors NOT to implement the job state reasons. Why not just say "they're optional", PERIOD? I suggest the wording be shortened to, "Implementation of these values is OPTIONAL." for both JMP and IPP. Thanks, Angelo From ipp-archive Wed Jun 11 12:59:51 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA11811 for ipp-outgoing; Wed, 11 Jun 1997 12:57:24 -0400 (EDT) Mime-Version: 1.0 Date: Wed, 11 Jun 1997 13:00:44 -0400 Message-ID: <00019506.1337@digprod.com> From: bwagner@digprod.com (Bill Wagner) Subject: Re[2]: IPP>MOD - Print by reference To: 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 Don, I certainly agree that the approach should be pursued, although perhaps the actual division might be somewhat different. Indeed, as I may have inadequately indicated before, I thought Carl-Uno had suggested that something like this may be necessary a long time ago. The key, and perhaps the difficult part, is to ensure that the various related but independently specified IPP services, are compatible with each other so that a device could support all services in a cohesive way. Bill Wagner, Osicom/DPI ______________________________ Reply Separator _________________________________ Subject: Re: IPP>MOD - Print by reference Author: don@lexmark.com at Internet Date: 6/11/97 10:03 AM I have been listening to this discussion for a long time and I recognize the need for a human being to be able to print by reference. This function can be easily provided with HTML, etc on a Web page hosted by an IPP print server (actually IPP is not even needed for this solution.) Is the need as pressing for this to be done programmatically? The bottom line is can this function be provided outside the scope of the IPP protocol? If the programmatic need is strong, is it sufficient to standardize the way this is done with HTML so that once the URL of a print by reference page is know, a print by reference job can be submitted to it under program control? This could just be part of a multi-pronged standard approach. Instead of defining an all encompassing IPP standard, maybe we should look at this from a difference perspective. Do we really need: 1) An IPP Job Submission protocol -and- 2) An IPP Print by Reference standard -and- 3) An IPP Job Management protocol -and- 4) An IPP Print Capability Discovery protocol etc, etc, etc. I know "compliance levels" and print by reference are not strictly related but I would like to be able to define all these functions in a standard way without requiring "compliance levels" or burdening the lowest implementation with too much baggage. ... all right... fire away!! Don From ipp-archive Wed Jun 11 14:39:52 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA12658 for ipp-outgoing; Wed, 11 Jun 1997 14:35:15 -0400 (EDT) Message-ID: <339EF128.7D6DFE55@sharplabs.com> Date: Wed, 11 Jun 1997 11:40:40 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> IPP implementation question X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk I have a general question regarding implementation of IPP. Should the protocol mapping document contain all information necessary to implement IPP over HTTP, or does an implementer have to have copies of both the encoding document, and the model document to implement? In the protocol mapping document, I have to fully specify everything that goes on the "wire" for IPP messages. If I do this, then there will be some overlap of mapping document to model document. Randy From ipp-archive Wed Jun 11 14:59:52 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA13163 for ipp-outgoing; Wed, 11 Jun 1997 14:58:27 -0400 (EDT) From: Roger K Debry To: Subject: IPP> IPP implementation question Message-Id: <5030100003429388000002L082*@MHS> Date: Wed, 11 Jun 1997 15:00:19 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk An implementor would always need the model document anyway in order to implement the proper semantics. Clearly there will have to be some duplication to make the protocol document usable. 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 06/11/97 12:44 PM --------------------------- ipp-owner @ pwg.org 06/11/97 12:45 PM Please respond to rturner@sharplabs.com @ internet To: ipp @ pwg.org @ internet cc: Subject: IPP> IPP implementation question I have a general question regarding implementation of IPP. Should the protocol mapping document contain all information necessary to implement IPP over HTTP, or does an implementer have to have copies of both the encoding document, and the model document to implement? In the protocol mapping document, I have to fully specify everything that goes on the "wire" for IPP messages. If I do this, then there will be some overlap of mapping document to model document. Randy From ipp-archive Wed Jun 11 17:24:53 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA13865 for ipp-outgoing; Wed, 11 Jun 1997 17:23:29 -0400 (EDT) Message-ID: <339F1892.76FE88EF@sharplabs.com> Date: Wed, 11 Jun 1997 14:28:50 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> ABNF syntax document X-Priority: 3 (Normal) Content-Type: multipart/mixed; boundary="------------472B8ABEC07CEBA1E9CECF69" Sender: ipp-owner@pwg.org Precedence: bulk This is a multi-part message in MIME format. --------------472B8ABEC07CEBA1E9CECF69 Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --------------472B8ABEC07CEBA1E9CECF69 Content-Type: text/plain; charset=us-ascii; name="draft-ietf-drums-abnf-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-drums-abnf-02.txt" Network Working Group D. Crocker (editor) Internet-Draft Internet Mail Consortium Paul Overell Expiration <7/97> Demon Internet Ltd Augmented BNF for Syntax Specifications: ABNF STATUS OF THIS MEMO This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). TABLE OF CONTENTS 1. INTRODUCTION 2. RULE DEFINITION 2.1 Rule Naming 2.2 Rule Form 2.3 End-of-Rule 2.4 Terminal Values 2.5 External Encodings 3. OPERATORS 3.1 Concatenation: Rule1 Rule2 3.2 Alternatives: Rule1 / Rule2 3.3 Incremental Alternatives: Rule1 =/ Rule2 3.4 Sequence Group: (Rule1 Rule2) 3.5 Set Group: {Rule 1 Rule2} 3.6 Variable Repetition: *Rule 3.7 Specific Repetition: nRule 3.8 Optional Sequence: [RULE] 3.9 Lists: #Rule 3.10 Value Ranges: a..b 3.11 ; Comment 3.12 Operator Precedence 4. ABNF DEFINITION OF ABNF... 5. APPENDIX A - CORE 6. ACKNOWLEDGEMENTS 7. REFERENCES 8. CONTACT 1. INTRODUCTION Internet technical specifications often need to define a format syntax and are free to employ whatever notation their authors deem useful. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. It balances compactness and simplicity, with reasonable representational power. In the early days of the Arpanet, each specification contained its own definition of ABNF. This included the email specifications, RFC733 and then RFC822 which have come to be the common citations for defining ABNF. The current document separates out that definition, to permit selective reference. Predictably, it also provides some enhancements. The differences between standard BNF and the ABNF defined here involve naming rules, repetition, alternatives, and order-independence, and rules that add alternatives to existing rules, lists, and value ranges. Appendix A (Core) supplies rule definitions for a core lexical analyzer, of the type common to several Internet specifications. It is provided as a convenience and is otherwise separate from the meta language defined in the body of this document, and its formal status. 2. RULE DEFINITION 2.1 Rule Naming The name of a rule is simply the name itself; that is, a sequence of characters, not beginning with a digit, with an asterisk ("*"), or with a number (pound) sign ("#"). (This avoids ambiguity with the various repetition mechanisms, defined below.) Rule names are case-INsensitive. The names , , and all refer to the same rule. Unlike original BNF, angle brackets ("<", ">") are not required. However, angle brackets may used around a rule reference whenever their presence will facilitate discerning the use of a rule name. This is typically restricted to rule name references in free-form prose, or to distinguish partial rules that combine into a string not separated by linear white space, such as shown in the discussion about repetition, below. 2.2 Rule Form A rule is defined by the following sequence: name = elements where is the name of the rule and is one or more rules or terminal specifications. The equal sign separates the name from the definition of the rule. The elements are a sequence of one or more rule names and/or value definitions, combined according to the various operators, defined in this document, such as alternative and repetition. 2.3 End-of-Rule Formally the grammar requires a one-token look-ahead to find the "=" token, which indicates that the previous token is the name of a new rule. For visual ease, rules should start in column 1, with rule continuation indicated by blank (linear white space) in column 1. In some documentation, "column 1" might be virtual, with a consistent indentation from the left margin, for all rules. 2.4 Terminal Values Rules resolve into a string of terminal values, sometimes called characters. Values within ABNF are represented as decimal numbers. Hence, an ABNF parser processes a sequence of characters. Each character is represented as a decimal number. A string of values is in "network byte order" with the higher-valued bytes represented on the left-hand side and begin sent over the network first.. Terminals are specified by one or more numerica characters with the base interpretation of those characters indicated explicitly. The following bases are currently defined: b = binary d = decimal x = hexadecimal Hence: CR = %d13 CR = %x0D respectively specify the decimal and hexadecimal representation of [US-ASCII] for carriage return. A string of such values is specified compactly, using a period (".") to indicate separation of characters within that value. Hence: CRLF = %d13.10 For a sequence of values which can be represented as simple, graphical characters (letters), they may be specified as a string of literals, enclosed in quotation-marks. Hence: rule = "rule-name = rule-value" specifies the rule "rule" which contains the characters of an ABNF rule specification. ABNF STRINGS ARE CASE-INSENSITIVE AND THE CHARACTER SET FOR THESE STRINGS IS US- ASCII. Hence: rulename = "abc" will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", and "ABC". To specify a rule which IS case SENSITIVE, specify the characters individually. For example: rulename = %d97 %d9 %d99 or rulename = %d97.98.99 will match only the string which comprises only lowercased characters, abc. 2.5 External Encodings External representations of these characters will vary according to constraints in the storage or transmission environment. Hence, the same ABNF-based grammar may have multiple external encodings, such as one for a 7-bit US-ASCII environment, another for a binary octet environment and still a different one when 16-bit Unicode is used. Encoding details are beyond the scope of ABNF, although Appendix A (Core) provides definitions for a 7-bit US-ASCII environment as has been common to much of the Internet. By separating external encoding from the syntax, it is intended that alternate encoding environments can be used for the same syntax. 3. OPERATORS 3.1 Concatenation: Rule1 Rule2 A rule can define a simple, ordered string of values -- i.e., a concatenation of contiguous characters -- by listing a sequence of rule names. For example: foo = %x61 ; a bar = %x62 ; b mumble = foo bar foo So that the rule defines the lower-case string "aba". LINEAR WHITE SPACE: Concatenation is at the core of the ABNF parsing model. A string of contiguous characters (values) is parsed according to the rules defined in ABNF. For Internet specifications, there is some history of permitting linear white space (space and horizontal tab) to be freely-and implicitly-interspered around major constructs, such as delimiting special characters or atomic strings. THIS SPECIFICATION FOR ABNF DOES NOT PROVIDE FOR IMPLICIT SPECIFICATION OF LINEAR WHITE SPACE. Any grammar which wishes to permit linear white space around delimiters or string segments must specify it explicitly. It is often useful to provide for such white space in "core" rules that are then used variously among higher-level rules. The "core" rules might be formed into a lexical analyzer or simply be part of the main ruleset. 3.2 Alternatives: Rule1 / Rule2 Elements separated by forward slash ("/") are alternatives. Therefore, foo / bar will accept or . 3.3 Incremental Alternatives: Rule1 =/ Rule2 It is sometimes convenient to specify a list of alternatives in fragments. That is, an initial rule may define one or more alternatives, with later rule definitions adding to the set of alternatives. This is particularly useful for otherwise-independent specifications which derive from the same parent rule set, such as often occurs with parameter lists. ABNF permits this incremental definition through the construct: oldrule =/ additional-alternatives So that the rule set ruleset = alt1 / alt2 ruleset =/ alt3 ruleset =/ alt4 / alt5 is the same as specifying ruleset = alt1 / alt2 / alt3 / alt4 / alt5 3.4 Sequence Group: (Rule1 Rule2) Elements enclosed in parentheses are treated as a single element, whose contents are STRICTLY ORDERED. Thus, (elem foo) / (bar blat) elem allows the token sequences (elem foo elem) and (bar blat elem). Without the grouping, the rule: elem foo / bar elem would match (elem foo elem) or (elem bar elem). The local grouping notation is also used within free text to set off an element sequence from the prose. 3.5 Set Group: {Rule 1 Rule2} Elements enclosed in braces (squiggly brackets) are treated as a single, UNORDERED element. Its contents may occur in any order. Hence: {elem foo} bar would match (elem foo bar) and (foo elem bar). NOTE: Specifying alternatives is quite different from specifying set grouping. Alternatives indicate the matching of exactly one (sub-)rule out of the total grouping. The set mechanism indicates the matching of a string which contains all of the elements within the group; however the elements may occur in any order. 3.6 Variable Repetition: *Rule The operator "*" preceding an element indicates repetition. The full form is: *element where and are optional decimal values, indicating at least and at most occurrences of element. Default values are 0 and infinity so that <*element> allows any number, including zero; <1*element> requires at least one; <3*3element> allows exactly 3 and <1*2element> allows one or two. 3.7 Specific Repetition: nRule A rule of the form: element is equivalent to *element That is, exactly occurrences of . Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three alphabetic characters. 3.8 Optional Sequence: [RULE] Square brackets enclose an optional element sequence: [foo bar] is equivalent to *1(foo bar). 3.9 Lists: #Rule A construct "#" is defined as being similar to "*", for a list sequence: #element indicates at least and at most elements, each separated by one or more commas (","). This makes the usual form of lists very easy; a rule such as: element *("," element) can therefore be shown as 1#element Wherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is, element,,element is permitted, but counts as only two elements. Therefore, where at least one element is required, at least one non- null element must be present. Default values are 0 and infinity so that <#element> allows any number, including zero; <1#element> requires at least one; and <1#2element> allows one or two. 3.10 Value Ranges: a..b Values separated by double periods ("..") specify a range of values from the lowest, on the left-hand side, to the highest on the right-hand side. Values may be specifiednumericallyl or with rule references. The form: %d12..%d15 or %d12..15 represents a value in the range 12 to 15, inclusively. When the values are specified using rules rather than explicit decimal numbers, the rules must reduce to single, decimal values. Hence: CR = %d12 LF = %d15 smallrange = LF..CR is valid and indicates the decimal value range 12 to 15. 3.11 ; Comment A semi-colon starts a comment that continues to the end of line. This is a simple way of including useful notes in parallel with the specifications. 3.12 Operator Precedence The various mechanisms described above have the following precedence, from highest (binding tightest) at the top, to lowest and loosest at the bottom: Comment Value range Repetition, List Grouping, Optional Concatenation Alternative Use of the alternative operator, freely mixed with concatenations can be confusing. It is STRONGLY recommended that the grouping operator be used to make explicit concatenation groups. 4. ABNF DEFINITION OF ABNF... This syntax uses the rules provided in Appendix A (Core). rule = rulename *WSP ("=" / "=/") value [comment] *WSP CRLF ; continues if next line starts with white space ; basic rules definition and incremental alternatives bin-val = "b" 1*("0".."1") [ 1*("." 1*("0".."1")) / (".." 1*("0".."1")) ] comment = *WSP ";" *(WSP / %x21..%x7E) dec-val = "d" 1*DIGIT [ 1*("." 1*DIGIT) / (".." 1*DIGIT) ] el-component = rulename / set / group / option / num-val / lit-val / prose-val element = [repeat] el-component group = *WSP "(" value *WSP ")" hex-val = "x" 1*(DIGIT / "A".."F") [ 1*("." 1*(DIGIT / "A".."F")) / (".." 1*(DIGIT / "A".."F")) ] lit-val = *WSP <"> *PCHAR <"> num-val = *WSP "%" (bin-val / dec-val / hex-val) option = *WSP "[" value *WSP "] prose-val = *WSP "<" ">" set = *WSP "{" 2*element *WSP "}" ; elements in any order range = value *WSP ".." value ; values must reduce to single decimal values repeat = repeat-num / [repeat-num] *WSP ("*" / "#") [repeat-num] repeat-num = *WSP 1*DIGIT rulename = *WSP ALPHA *( ALPHA / DIGIT / "-" ) value = 1*element *(*WSP "/" 1*element) 5. APPENDIX A - CORE This Appendix is provided as a convenient core for specific grammars. The definitions may be used as a core set of rules. Certain basic rules are in uppercase, such as SPACE, TAB, CRLF, DIGIT, ALPHA, etc. ALPHA = "A".."Z" ; case not significant CHAR = %x00..7F ; us-ascii CR = %d13 CRLF = CR LF CTL = %d0..31 / %d127 DIGIT = "0".."9" HTAB = %d9 LF = %d10 LWSP = SP / HTAB SPACE = " " PCHAR = %x20..7E WSP = LWSP / CRLF LWSP Externally, data are represented as "network virtual ASCII", namely 7-bit US-ASCII in an 8th bit field, with the high (8th) bit set to zero. 6. ACKNOWLEDGEMENTS The syntax for ABNF was originally specified in RFC #733. Ken L. Harrenstien, of SRI International, was responsible for re-coding the BNF into an augmented BNF that makes the representation smaller and easier to understand. The current round of specification was part of the DRUMS working group, with significant contributions from Bill McQuillan, Keith Moore, Pete Resnick, Jerome Abela and Chris Newman. 7. REFERENCES [US-ASCII] Coded Character Set--7-Bit American Standard Code for Information Interchange, ANSI X3.4-1986. 8. CONTACT David H. Crocker Paul Overell Demon Internet Ltd Internet Mail Consortium Dorking Business Park 675 Spruce Dr. Dorking Sunnyvale, CA 94086 USA Surrey, RH4 1HN UK Phone: +1 408 246 8253 Fax: +1 408 249 6205 --------------472B8ABEC07CEBA1E9CECF69-- From ipp-archive Wed Jun 11 17:49:54 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA15125 for ipp-outgoing; Wed, 11 Jun 1997 17:48:21 -0400 (EDT) From: don@lexmark.com Message-Id: <199706112148.AA05376@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: rdebry@us.ibm.com Cc: ipp@pwg.org Date: Wed, 11 Jun 1997 17:37:56 -0400 Subject: Re: IPP>MOD - Print by reference Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: bulk Roger Debry said: > Don, I got lost trying to follow your first paragraph. Perhaps you can > provide more details. Maybe its just to early in the morning for me! :-) It is very easy to create a "fill in the blank" form that allows the user to tell the server where the document is located, e.g. provide the URL. This filled out form can then kick off a CGI script or whatever other means is available to execute a program of some kind to go off, fetch the requested file, and then add it to the server's job queue. Alternatively, this process could be done on a different server and submitted via IPP to the desired print server. The who issue with this concept is that doing it is easy for the human being but much more difficult to do programmatically. Is my explanation a little better? Don From ipp-archive Wed Jun 11 17:49:54 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA15114 for ipp-outgoing; Wed, 11 Jun 1997 17:48:03 -0400 (EDT) Message-Id: <01BC767E.C6071100@hpb19043.boi.hp.com> From: Stephen Holmstead To: "ipp@pwg.org" Subject: RE: IPP>MOD - Print by reference Date: Wed, 11 Jun 1997 15:47:30 -0600 Encoding: 74 TEXT Sender: ipp-owner@pwg.org Precedence: bulk Good summary of requirements. I think that when you narrow print-by-reference to this scoping, that is possible in a printer. I do think that there may still be some issues that we need to work through. For example, you will give the printer a URL. Somehow the printer has to be able to distinguish the content of this URL as pre-formatted IPP material versus generic web pages. This might be covered in the content description fields. Also, the printer needs to know if there is a pre-formatted type that it can handle (can the printer do postscript?). This might also be covered in the content description. -- Stephen Holmstead Hewlett Packard Internet Solutions Operation stephen_holmstead@hp.com -----Original Message----- From: Roger K Debry [SMTP:rdebry@us.ibm.com] Sent: Wednesday, June 11, 1997 7:55 AM To: ipp@pwg.org Subject: IPP>MOD - Print by reference There has been quite a storm of email on the print by reference subject lately. Let me once again define what I believe to be a very significant customer requirement that print by reference can satisfy. In very carefully fencing this requirement it is important to say what it is not. It is NOT printing web pages. Much of the concern I have seen expressed in recent email, especially from HP, has to do with printing web pages. I agree that chasing links and dealing with the multitude of data types on the web is very complex and could potentially bloat a Printer implementation. It is NOT printing documents that require some security mechanism to access them. In particular it does not deal with the printing of documents where the right to print a copy of the document must be purchased. As Larry Masinter has suggested, the protocol may reserve some "space" to encode credentials for such transactions, but I do not want to complicate the model nor hold up approval of IPP as a standard trying to architect and get approval of these security mechanisms. There are at least two examples of what I think print by reference is for version one of IPP: First, consider the case of documents, such as Internet-Drafts, or those documents which we have on the PWG ftp site which are accessible by anonymous ftp, i.e. they are "publically accessible". Print by reference is a powerful tool for printing such documents. Documents are in some print-ready format, such as Postscript. Second, consider the case where an enterprise keeps a library of documents (standards, reports, procedures, etc) on a central repository that is accessible by anyone within the enterprise firewall. It would probably be on a private internal network. Print by reference is again a very powerful tool for printing such documents which are in some print-ready format. To summarize, this simple version of print-by-reference only requires that the documents to be fetched are already formatted for printing. The Printer does not deal with links, it does not format pages, it does not deal with dynamic web formats, etc. 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 Jun 11 19:14:55 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA16676 for ipp-outgoing; Wed, 11 Jun 1997 19:10:52 -0400 (EDT) Message-Id: <3.0.1.32.19970611160346.00be4270@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 11 Jun 1997 16:03:46 PDT To: Stephen Holmstead , "ipp@pwg.org" From: Carl-Uno Manros Subject: RE: IPP>MOD - Print by reference In-Reply-To: <01BC767E.C6071100@hpb19043.boi.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Stephen and others interested in the print-by-reference discussion, In our PWG IPP phone conference today, the following proposal was brought up: It is suggested that we create two new "shadow-operations" for print-by-reference, one that looks like the Print-Job operation called Print-URI, which is like Print-Job, but has an attribute containing a URI instead of the print-data. Similarly one that looks like the Send-Document but called Send-URI. It will then be crystal clear whether an implementation supports print-by-reference, by examining whether one or both of these operations are supported. The Validate operation will return an attribute containing information about which operations are supported. This proposal does not suggest adding additional attributes for security. I support keeping print-by-reference in our solution as described above, and meeting the requirements described by Roger deBry (which do not require security). Carl-Uno At 02:47 PM 6/11/97 PDT, Stephen Holmstead wrote: >Good summary of requirements. I think that when you narrow >print-by-reference to this scoping, that is possible in a printer. I do >think that there may still be some issues that we need to work through. > For example, you will give the printer a URL. Somehow the printer has to >be able to distinguish the content of this URL as pre-formatted IPP >material versus generic web pages. This might be covered in the content >description fields. Also, the printer needs to know if there is a >pre-formatted type that it can handle (can the printer do postscript?). > This might also be covered in the content description. >-- >Stephen Holmstead >Hewlett Packard Internet Solutions Operation >stephen_holmstead@hp.com > > >-----Original Message----- >From: Roger K Debry [SMTP:rdebry@us.ibm.com] >Sent: Wednesday, June 11, 1997 7:55 AM >To: ipp@pwg.org >Subject: IPP>MOD - Print by reference > >There has been quite a storm of email on the print by reference subject >lately. >Let me once again define what I believe to be a very significant customer >requirement that print by reference can satisfy. In very carefully fencing >this requirement it is important to say what it is not. > >It is NOT printing web pages. Much of the concern I have seen expressed in >recent email, especially from HP, has to do with printing web pages. I >agree >that chasing links and dealing with the multitude of data types on the web >is >very complex and could potentially bloat a Printer implementation. > >It is NOT printing documents that require some security mechanism to >access them. In particular it does not deal with the printing of documents >where the right to print a copy of the document must be purchased. As >Larry Masinter has suggested, the protocol may reserve some "space" >to encode credentials for such transactions, but I do not want to >complicate >the model nor hold up approval of IPP as a standard trying to architect and >get approval of these security mechanisms. > >There are at least two examples of what I think print by reference is for >version one of IPP: > >First, consider the case of documents, such as Internet-Drafts, or those >documents which we have on the PWG ftp site which are accessible >by anonymous ftp, i.e. they are "publically accessible". Print by >reference is a powerful tool for printing such documents. Documents >are in some print-ready format, such as Postscript. > >Second, consider the case where an enterprise keeps a library of >documents (standards, reports, procedures, etc) on a central >repository that is accessible by anyone within the enterprise >firewall. It would probably be on a private internal network. Print >by reference is again a very powerful tool for printing such >documents which are in some print-ready format. > >To summarize, this simple version of print-by-reference only >requires that the documents to be fetched are already >formatted for printing. The Printer does not deal with links, >it does not format pages, it does not deal with dynamic web >formats, etc. > > > > >Roger K deBry >Senior Techncial Staff Member >Architecture and Technology >IBM Printing Systems >email: rdebry@us.ibm.com >phone: 1-303-924-4080 > > > Carl-Uno 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 Jun 11 19:39:55 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA17175 for ipp-outgoing; Wed, 11 Jun 1997 19:36:33 -0400 (EDT) From: Harry Lewis To: Subject: Re[2]: IPP>MOD - Print by reference Message-Id: <5030100003442109000002L092*@MHS> Date: Wed, 11 Jun 1997 19:38:27 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Don, your question is crucial. >Do we really need: > >1) An IPP Job Submission protocol >-and- >2) An IPP Print by Reference standard >-and- >3) An IPP Job Management protocol >-and- >4) An IPP Print Capability Discovery protocol >etc, etc, etc? I've tried to indicate similar feelings and been laughed out of the room (figuratively) for suggesting 3 and 4 could be handled via the Job and Printer MIBs. I'm drawing a conclusion that much of the churn on these issues relates to the separate worlds that Jay described so well in a previous note to the JMP (which I am including here, out of context). >Seriously, some of us firmly believe in the importance of "out of band" >job monitors (ie, processes monitoring job progression without being >intrinsically part of the printing process, a la Unix and VMS). The >only consistent way to indentify jobs is through jobOwner, and hence, >this data must be available for as long as the job entry exists in the >agent. > >Those who will be using the Job MIB as an intrinsic part of the >printing process are lucky (eg, Windows, OS/2, etc). (We envy you, >believe us!) If someone can state a justifiable case for being able to >monitor jobs with jobOwner, then great! (And please do so soon!) >Otherwise, we need that data for the duration of the job entry. The point is, those who feel more comfortable with IPP as a "web based submission protocol", by my observation, relate strongly with the intrinsic, integrated print frameworks provided by Windows, OS/2 and similar operating systems. In these environments, an end-to-end, all encompassing print protocol is unnecessary because there is a query and status API (if you will) to facilitate communication with the printer via some means other than the submission protocol. I think the desire for IPP to be all encompassing - query, submit, monitor, control - stems from platforms which do not supply a "robust" print framework as part of the native OS, today. Here, a robust replacement for LPR/LPD would, appropriately, include everything. I don't want to ignore or prioritize any one platform (or family) but, if my distinction is at all accurate, I think it would be a good idea to develop IPP components that can work together in an end-to-end solution but also may operate separately (at least the submission piece) in environments that do not need or warrant a full solution. >>> Harry Lewis <<< From ipp-archive Wed Jun 11 20:24:55 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA17702 for ipp-outgoing; Wed, 11 Jun 1997 20:23:48 -0400 (EDT) Message-Id: <3.0.1.32.19970611171651.00c1a760@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 11 Jun 1997 17:16:51 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Minutes from PWG IPP Phone Conference on June 11, 1997 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Minutes from PWG IPP Phone Conference on June 11, 1997 Attending: Carl-Uno Manros, chair and minute taker Tom Hastings Peter Zehler Paul Moore Babak Jahromi Roger deBry Bob Herriot Randy Turner Jeff Copeland Jay Martin (Don Wright and Steve Zilles are currently in Japan and couldn't make it, and Scott Isaacson had a last minute conflict and couldn't make it). Main discussion point was how to fit in the latest proposal from Paul Moore with the rest of the IPP documentation, in particular with the Model and Protocol documents. It was agreed that we should only have one Protocol mapping document. It was further agreed that we should only have a minimum set of Operations that need to be supported, with the remaining ones being optional for the time being. This will mean some rewording in the Model document. We will not talk about conformance levels, but indicate in the text that we plan to introduce such during the progression of our documents from Proposed to Draft standards. The only two operations that would be mandatory for all implementations initially are the Validate and Print-Job operations, and implementations will direct how many of the remaining operations will be "promoted" to mandatory later on. The Validate operation will need to return an attribute which lists the operations that a are supported by the Printer. The main usage of the Validate operation will otherwise be to establish whether authentication will be required for subsequent operations. The description of many Mandatory attributes in the Model document will need to reflect that they are now Conditionally Mandatory dependent on whether the operation is supported or not. The set of truly Mandatory attributes is expected to be very small (for further discussion). It was also discussed what to do with print-by-reference. It was suggested that we create two new "shadow-operations" for print-by-reference, one that looks like the Print-Job operation called Print-URI, which is like Print-Job, but has an attribute containing a URI instead of the print-data. Similarly one that looks like the Send-Document but called Send-URI. It will then be crystal clear whether an implementation supports print-by-reference, by examining whether one or both of these operations are supported. This proposal does not suggest adding additional attributes for security. Some general discussion was held about a few inconsistencies between the latest proposal from Paul Moore and the current Model and emerging Protocol documents. In particular, the proposed mixing if binary and text encoding was controversial. It was felt that we should continue working on a solution based on ABNF, which assumes text-based encoding. There was still some discussion about whether we need lengths for values or use some special character to mark the end of a value. Further discussion of this on the DL and we hope to resolve this in the June 17 PWG Protocol meeting. Some further discussion about the Operations as described the Model document is that they need further work, to make clear what comes back when an operation has succeeded vs. when it failed. We also need to get more error descriptions included. Randy has already given proposals to Scott for how to fix much of this. Randy expects to have a new internal draft of the Protocol mapping in time to review at the June 17 meeting and we will hopefully be ready to issue a I-D shortly afterwards. Roger announced that we can expect to see a new Directory Schema I-D shortly, and probably also soon a Security draft that can go out as an I-D. Carl-Uno suggested that everybody now read the Model I-D and give feedback to the editor and to the DL for anything that needs further discussion. Carl-Uno has sent a message to Patrick about his role in producing the IPP/RFC 1179 mapping, but is still waiting for a reply. It was felt that the mapping could be done from the Model document and that there was no need to wait for the Protocool document in order to get started. The agenda for the June 17 meeting will be to review Randy's new Protocol mapping draft, which by then should have integrated suitable parts from Paul Moore's draft. Carl-Uno indicated that he would like to spend some time on all our documents during the June 25-26 meeting of the PWG IPP group in Nassau, NH. This would also include the Requirements and IPP/RFC 1179 Mappings. However, the majority of the time will probably be spent on making sure that the Model and Protocol document are now synchronized and complete. We will have our next PWG IPP phone conference as usual on Wednesdayt next week, even though many of us will meet on Tuesday in the Protocol meeting. ------ Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-archive Thu Jun 12 01:34:58 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA18692 for ipp-outgoing; Thu, 12 Jun 1997 01:33:49 -0400 (EDT) Message-ID: <339F8882.5F49@parc.xerox.com> Date: Wed, 11 Jun 1997 22:26:26 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> RE: JMP> Final IPP/JMP job-state and job-state-reasons References: <1CBE9E3381262D791CBE9E3381262D79#064#x-wb-0311-ms1.xerox@SMF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk I haven't been following this discussion carefully, but I think there's a problem with a protocol standard attempts to dictate what must or must not be 'implemented'. If you just talk about what has to be sent in order to achieve interoperability, then you'll get into less of these kinds of arguments. IF you want to tell clients about the status of the job, THEN send the following job-state-reasons. Conformance then becomes a non-issue. -- http://www.parc.xerox.com/masinter From ipp-archive Thu Jun 12 08:15:02 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA19559 for ipp-outgoing; Thu, 12 Jun 1997 08:12:23 -0400 (EDT) From: Roger K Debry To: Subject: Re[2]: IPP>MOD - Print by reference Message-Id: <5030100003462032000002L022*@MHS> Date: Thu, 12 Jun 1997 08:14:09 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Harry Lewis Wrote ... The point is, those who feel more comfortable with IPP as a "web based submission protocol", by my observation, relate strongly with the intrinsic, integrated print frameworks provided by Windows, OS/2 and similar operating systems. In these environments, an end-to-end, all encompassing print protocol is unnecessary because there is a query and status API (if you will) to facilitate communication with the printer via some means other than the submission protocol. I think the desire for IPP to be all encompassing - query, submit, monitor, control - stems from platforms which do not supply a "robust" print framework as part of the native OS, today. Here, a robust replacement for LPR/LPD would, appropriately, include everything. I don't think this is necessarily the case. I believe there are some (at least one) who believe that a single protocol is just simpler and more elegant that a set of different, but related intefaces. From ipp-archive Thu Jun 12 11:35:03 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA21154 for ipp-outgoing; Thu, 12 Jun 1997 11:33:25 -0400 (EDT) Message-Id: <3.0.1.32.19970612082701.0095da70@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 12 Jun 1997 08:27:01 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> Re: ABNF Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk FYI, I sent a message to Dave Crocker about the plan to finish the ABNF spec. It looks like we will be able to reference a finished ABNF document by August or September. If we run into any problems when trying to use it, there still seems to be a chance to get it corrected. Carl-Uno >To: Carl-Uno Manros >From: Dave Crocker >Subject: Re: ABNF > >In reply to your message stating: >>At what point do you expect the current draft to become a formal document >>on the standards track so that we can reference it? > > the chair of the working group is pressuring me to finish it up. >we think there's only one more round to go. > >d/ > >-------------------- >Dave Crocker, Director +1 408 246 8253 >Internet Mail Consortium (f) +1 408 249 6205 >675 Spruce Dr. dcrocker@imc.org >Sunnyvale, CA 94086 USA info@imc.org , http://www.imc.org > > > > 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 Jun 12 11:54:54 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA21672 for ipp-outgoing; Thu, 12 Jun 1997 11:48:43 -0400 (EDT) From: don@lexmark.com Message-Id: <199706121548.AA27330@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: pwg@pwg.org, IPP@pwg.org, jmp@pwg.org, sense@pwg.org, upd@pwg.org, pmp@pwg.org, p1394@pwg.org Date: Wed, 11 Jun 1997 20:43:15 -0400 Subject: IPP> August Printer Working Group Meetings Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: bulk The August Printer Working Group meeting will be held at Microsoft in Redmond. The current schedule is as follows: August 4th, 5th 9AM - 6PM 1394 Printing Working Group August 6th, 7th 8:30 AM - 6PM IPP Work Group August 8th 8:30 AM - 6PM JMP, etc. as required Each of you is on your own for hotel reservations. Recommendations for hotels are as follows: Double Tree (was Red Lion) Bellvue 425-455-1300 Hyatt Bellvue 425-462-1234 Hilton Bellvue 425-455-3330 Ask for the Microsoft rate at these hotels. Maps, directions, buildings and rooms will be distributed in a later note. If you have any concerns about the above schedule (other than the times which are fixed by room availability at Microsoft) please let me know ASAP so people can make their travel plans. 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 * ************************************************************* From ipp-archive Thu Jun 12 12:00:20 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA22358 for ipp-outgoing; Thu, 12 Jun 1997 11:55:14 -0400 (EDT) Message-Id: <3.0.1.32.19970612084844.00c0a520@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 12 Jun 1997 08:48:44 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Munich Agenda Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Harald is working on the Munich Agenda. Still no allocated timeslot for IPP, but the message is that WGs will only be given at most a 2 hour slot. We want to have some six documents reviewed... It looks like we will need to rethink the number of documents to be discussed in Munich and simply leave out the less important ones. The Application Area agenda slots will be announced on Harald's IETF web pages at: http://www.apps.ietf.org/track-munich.html 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 Thu Jun 12 17:20:06 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA25821 for ipp-outgoing; Thu, 12 Jun 1997 17:17:33 -0400 (EDT) Date: Thu, 12 Jun 1997 14:16:25 -0700 (PDT) From: Patrick Powell Message-Id: <199706122116.OAA06912@dickory.sdsu.edu> To: ipp@pwg.org Subject: IPP> vacation Sender: ipp-owner@pwg.org Precedence: bulk I will be on vacation and travelling until 7 July, 1997. I will periodically read email and try to comment on the IPP Model and protocol documents and discussions. Patrick Powell From ipp-archive Thu Jun 12 17:30:09 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA26463 for ipp-outgoing; Thu, 12 Jun 1997 17:28:15 -0400 (EDT) Message-Id: <3.0.1.32.19970612142207.00b47800@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 12 Jun 1997 14:22:07 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC & MOD - Get-Attributes operation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk We have just finished our SEC conference call for today and feel confident that we now have all the important stuff that we expect to provide in the document and will issue a new I-D shortly. We expect to discuss with the Protocol group on Tuesday, what they might still need from us to go into their document. One issue that came up, was related to the Get-Attributes operation. It is quite possible that a particular Job on a printer has different security requirements than getting information about the Printer itself. The Job security level is often determined by the job owner, while the Printer security level is determined by the printer administrator. This seems to be a good reason to split up the Get-Attributes into a Get-Job-Attributes and a Get-Printer-Attributes operation. (Remember we created two new ones yesterday, so we are on the roll here :-) I know that we have had this kind of discussion previously, but this is a new argument that has now come up in support of making a split. As far as I can remember from last time we discussed this, there are situations in which you want to get back both Printer attributes and Job attributes in a response (e.g. printer status, when you ask about job status), but is that really a strong enough reason to only have one Get-Attributes operation, or should we rather consider making some special rules for things like status information? Comments? Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-archive Thu Jun 12 17:45:13 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA27145 for ipp-outgoing; Thu, 12 Jun 1997 17:43:18 -0400 (EDT) Date: Thu, 12 Jun 1997 17:40:10 -0400 (EDT) From: JK Martin Message-Id: <199706122140.RAA25050@uscore.underscore.com> To: cmanros@cp10.es.xerox.com Subject: Re: IPP> SEC & MOD - Get-Attributes operation Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk I agree entirely with the need to have separate "Get Attributes" operations for Job(s) and Printer, particularly given security considerations. ...jay ----- Begin Included Message ----- >From ipp-owner@pwg.org Thu Jun 12 17:34 EDT 1997 Date: Thu, 12 Jun 1997 14:22:07 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC & MOD - Get-Attributes operation We have just finished our SEC conference call for today and feel confident that we now have all the important stuff that we expect to provide in the document and will issue a new I-D shortly. We expect to discuss with the Protocol group on Tuesday, what they might still need from us to go into their document. One issue that came up, was related to the Get-Attributes operation. It is quite possible that a particular Job on a printer has different security requirements than getting information about the Printer itself. The Job security level is often determined by the job owner, while the Printer security level is determined by the printer administrator. This seems to be a good reason to split up the Get-Attributes into a Get-Job-Attributes and a Get-Printer-Attributes operation. (Remember we created two new ones yesterday, so we are on the roll here :-) I know that we have had this kind of discussion previously, but this is a new argument that has now come up in support of making a split. As far as I can remember from last time we discussed this, there are situations in which you want to get back both Printer attributes and Job attributes in a response (e.g. printer status, when you ask about job status), but is that really a strong enough reason to only have one Get-Attributes operation, or should we rather consider making some special rules for things like status information? Comments? Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com ----- End Included Message ----- From ipp-archive Thu Jun 12 18:10:07 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA28047 for ipp-outgoing; Thu, 12 Jun 1997 18:06:43 -0400 (EDT) Date: Thu, 12 Jun 1997 15:04:14 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706122204.PAA05175@woden.eng.sun.com> To: cmanros@cp10.es.xerox.com, jkm@underscore.com Subject: Re: IPP> SEC & MOD - Get-Attributes operation Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk I don't understand why having two separate GetAttribute operations are needed if the security requirements differ for a job and a printer. The job and printer should have different URIs. Is this different from two printers with different URIs having different security requirements with the same GetAttributes operation? By the way, the model as currently defined, returns only job attributes or printer attributes for the GetAttributes and GetJobs operations. Bob Herriot > From jkm@underscore.com Thu Jun 12 14:52:39 1997 > > I agree entirely with the need to have separate "Get Attributes" > operations for Job(s) and Printer, particularly given security > considerations. > > ...jay > > ----- Begin Included Message ----- > > From ipp-owner@pwg.org Thu Jun 12 17:34 EDT 1997 > Date: Thu, 12 Jun 1997 14:22:07 PDT > To: ipp@pwg.org > From: Carl-Uno Manros > Subject: IPP> SEC & MOD - Get-Attributes operation > > We have just finished our SEC conference call for today and feel confident > that we now have all the important stuff that we expect to provide in the > document and will issue a new I-D shortly. We expect to discuss with the > Protocol group on Tuesday, what they might still need from us to go into > their document. > > One issue that came up, was related to the Get-Attributes operation. > > It is quite possible that a particular Job on a printer has different > security requirements than getting information about the Printer itself. > The Job security level is often determined by the job owner, while the > Printer security level is determined by the printer administrator. > > This seems to be a good reason to split up the Get-Attributes into a > Get-Job-Attributes and a Get-Printer-Attributes operation. > (Remember we created two new ones yesterday, so we are on the roll here :-) > > I know that we have had this kind of discussion previously, but this is a > new argument that has now come up in support of making a split. > > As far as I can remember from last time we discussed this, there are > situations in which you want to get back both Printer attributes and Job > attributes in a response (e.g. printer status, when you ask about job > status), but is that really a strong enough reason to only have one > Get-Attributes operation, or should we rather consider making some special > rules for things like status information? > > Comments? > > Carl-Uno > > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com > > > ----- End Included Message ----- > > > From ipp-archive Thu Jun 12 19:05:08 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA28579 for ipp-outgoing; Thu, 12 Jun 1997 19:02:18 -0400 (EDT) Message-Id: <199706122301.QAA14708@scv4.apple.com> Subject: Re: IPP> SEC & MOD - Get-Attributes operation Date: Thu, 12 Jun 97 16:01:43 -0700 x-sender: brian@mail.apple.com x-mailer: Claris Emailer 1.1 From: Brian Grimshaw To: "Carl-Uno Manros" cc: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: ipp-owner@pwg.org Precedence: bulk How does this relate to the statements in the IPP/1.0 Model document: "... 5.1.5 The Get-Attributes operation allows client to obtain information from a Printer or Job object. ... 5.1.5.1 ... The client shall submit the Get-Attributes request to a Job URI or Printer URI. ..." Does this not handle the needed separation of job and printer attributes? Brian >From ipp-owner@pwg.org Thu Jun 12 17:34 EDT 1997 >Date: Thu, 12 Jun 1997 14:22:07 PDT >To: ipp@pwg.org >From: Carl-Uno Manros >Subject: IPP> SEC & MOD - Get-Attributes operation > >We have just finished our SEC conference call for today and feel confident >that we now have all the important stuff that we expect to provide in the >document and will issue a new I-D shortly. We expect to discuss with the >Protocol group on Tuesday, what they might still need from us to go into >their document. > >One issue that came up, was related to the Get-Attributes operation. > >It is quite possible that a particular Job on a printer has different >security requirements than getting information about the Printer itself. >The Job security level is often determined by the job owner, while the >Printer security level is determined by the printer administrator. > >This seems to be a good reason to split up the Get-Attributes into a >Get-Job-Attributes and a Get-Printer-Attributes operation. >(Remember we created two new ones yesterday, so we are on the roll here :-) > >I know that we have had this kind of discussion previously, but this is a >new argument that has now come up in support of making a split. > >As far as I can remember from last time we discussed this, there are >situations in which you want to get back both Printer attributes and Job >attributes in a response (e.g. printer status, when you ask about job >status), but is that really a strong enough reason to only have one >Get-Attributes operation, or should we rather consider making some special >rules for things like status information? > >Comments? > >Carl-Uno Brian Grimshaw Apple Computer, Inc. brian@apple.com From ipp-archive Thu Jun 12 19:05:09 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA28590 for ipp-outgoing; Thu, 12 Jun 1997 19:03:27 -0400 (EDT) Date: Thu, 12 Jun 1997 19:03:40 -0400 (EDT) From: JK Martin Message-Id: <199706122303.TAA15251@uscore.underscore.com> To: Robert.Herriot@Eng.Sun.COM Subject: Re: IPP> SEC & MOD - Get-Attributes operation Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk You're absolutely right, Bob. I completely forgot about the fact that any given IPP operation is targeted to a specific URL, and hence, can have different semantics based on the target. Only one "Get Attributes" operation is necessary as long as we stay with a model that revolves around operations targeted to specific URLs. ...jay ----- Begin Included Message ----- >From Robert.Herriot@Eng.Sun.COM Thu Jun 12 18:07 EDT 1997 Date: Thu, 12 Jun 1997 15:04:14 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) To: cmanros@cp10.es.xerox.com, jkm@underscore.com Subject: Re: IPP> SEC & MOD - Get-Attributes operation Cc: ipp@pwg.org I don't understand why having two separate GetAttribute operations are needed if the security requirements differ for a job and a printer. The job and printer should have different URIs. Is this different from two printers with different URIs having different security requirements with the same GetAttributes operation? By the way, the model as currently defined, returns only job attributes or printer attributes for the GetAttributes and GetJobs operations. Bob Herriot > From jkm@underscore.com Thu Jun 12 14:52:39 1997 > > I agree entirely with the need to have separate "Get Attributes" > operations for Job(s) and Printer, particularly given security > considerations. > > ...jay > > ----- Begin Included Message ----- > > From ipp-owner@pwg.org Thu Jun 12 17:34 EDT 1997 > Date: Thu, 12 Jun 1997 14:22:07 PDT > To: ipp@pwg.org > From: Carl-Uno Manros > Subject: IPP> SEC & MOD - Get-Attributes operation > > We have just finished our SEC conference call for today and feel confident > that we now have all the important stuff that we expect to provide in the > document and will issue a new I-D shortly. We expect to discuss with the > Protocol group on Tuesday, what they might still need from us to go into > their document. > > One issue that came up, was related to the Get-Attributes operation. > > It is quite possible that a particular Job on a printer has different > security requirements than getting information about the Printer itself. > The Job security level is often determined by the job owner, while the > Printer security level is determined by the printer administrator. > > This seems to be a good reason to split up the Get-Attributes into a > Get-Job-Attributes and a Get-Printer-Attributes operation. > (Remember we created two new ones yesterday, so we are on the roll here :-) > > I know that we have had this kind of discussion previously, but this is a > new argument that has now come up in support of making a split. > > As far as I can remember from last time we discussed this, there are > situations in which you want to get back both Printer attributes and Job > attributes in a response (e.g. printer status, when you ask about job > status), but is that really a strong enough reason to only have one > Get-Attributes operation, or should we rather consider making some special > rules for things like status information? > > Comments? > > Carl-Uno > > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com > > > ----- End Included Message ----- > > > ----- End Included Message ----- From ipp-archive Thu Jun 12 19:50:08 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA29574 for ipp-outgoing; Thu, 12 Jun 1997 19:49:09 -0400 (EDT) Message-ID: <33A08C32.8D69C056@sharplabs.com> Date: Thu, 12 Jun 1997 16:54:26 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> IPP Error codes X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Can someone point me to the latest document published on proposed error status codes for IPP requests? I think it was Keith Carter's document but I can't remember. Thanks! Randy From ipp-archive Thu Jun 12 20:10:09 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA00079 for ipp-outgoing; Thu, 12 Jun 1997 20:05:19 -0400 (EDT) Message-ID: <33A09002.87BEBC15@sharplabs.com> Date: Thu, 12 Jun 1997 17:10:42 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> create job IPP operation X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk In our current document we have a CREATE-JOB operation that specifies up front how many documents we have. Is this an unrealistic requirement for future IPP clients (or drivers) ? Will they always know how many documents are coming when they first do the CREATE-JOB? My feeling is that the clients might not know how many documents will be sent, and if that is the case, we need a mechanism for SEND-DOCUMENT to indicate to the server that this is the last document for the job. There are at least 3 ways to do this off the top of my head: 1. Have a specific SEND-DOCUMENT attribute or parameter that flags a particular request as the last document for the job. 2. Since we are using HTTP 1.1 with persistent connections, just close the TCP connection from client to host indicating the end of the job stream (or last document). 3. Have another IPP operation called END-JOB or CLOSE-JOB that unambiguously encapsulates the job stream within a CREATE-JOB/END-JOB pair. Comments? Randy From ipp-archive Thu Jun 12 20:20:21 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA00603 for ipp-outgoing; Thu, 12 Jun 1997 20:18:12 -0400 (EDT) Message-Id: <9706130018.AA05438@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Jun 1997 17:16:03 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> PRO - Comments on IPP Level 1 (formerly SWP) document Sender: ipp-owner@pwg.org Precedence: bulk I've posted some comments on the IPP Level 1 (formerly SWP) ipp-level1-95.* document: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ -rw-r--r-- 1 pwg pwg 15360 Jun 13 00:04 lev1-tnh.doc -rw-r--r-- 1 pwg pwg 6564 Jun 13 00:05 lev1-tnh.txt The .txt file is just the relevant paragraphs followed by my comments. I've copied the .txt into the remainder of this message. The .doc file is the same as the .txt file, but with revision marks turned= =20 on for my comments. I hope that we can cover these comments at the upcoming IPP protocol meeting, Tuesday, June 17, in San Jose. The form of the comments is comparing the document with the current Model and Protocol documents. Thanks, Tom File: lev1-tnh.txt: -------------------------------------------------------------------- I have a number of concerns about the encoding presented in this document. There are many differences between this document and the encoding that is in the current IPP Model and Semantics document and the corresponding protocol document. The text from the IPP Level 1 document is indented followed by my comments at the left margin. Tom 1. Page 5, section 1.1 Terminology: =20 Printer: The logical endpoint for data submitted via IPP1 =96 this may really be a printer. Alternatively it could be storage, an I suggest using the term "output device" in the definition, as in the Model document, so that the definition is circular. 2. Page 5, Section 2 Job submission: =20 The major part of IPP1 is the protocol that allows a client to submit a print job via HTTP. In keeping with its name this protocol is very simple:- not SWP anymore 3. Page 7, Section 3.1 200 OK =20 The URI is encoded in UTF8. Does the RFC for URI allow UTF8? (I hope so, but we need to check). Also need to site the source for UTF8. 4. Page 8, Section 5. Monitoring and management =20 Allowing the user to cancel their job, whilst queued and once delivery has started Does "delivery" mean printing? 5. Page 11, 7.1 Protocol Version =20 This is a 16 bit value giving the version number of the protocol encoing of this job. For version 1 it must be =20 X=920100=92 We discussed the concept of major and minor version number in San Diego. Need to add this here. Presumably the high order octet is the major version number (1) and the low order octet is the minor version number (0). 6. Page 11, Section 7.4 Attribute-n =20 Name is a US-ASCII string identifying the Attribute. The string is case insensitive. The protocol permits the use of Do we really want case-insensitive, so that a provider has to convert to one case for comparison? All the keywords in the Model document are all lower case with hyphens, except acronyms, such as URI. Even the first character is lower case. If we have lengths for efficiency on the provider side, why not also require correct case too? 7. Page 11, Section 7.4 Attribute-n =20 any characters, however it is recommended that specialbe avoided (=91+=92,=92_=92,=92 =91, etc.) We need to specifically allow ASCII HYPHEN-MINUS (-). 8. Page 12, Section 7.4 Attribute-n =20 Value-Length is a 16-bit binary value identifying the length of the value that follows. The NameType, Name-Length, and Value-Length fields are not included in this length. The Value-Llength specifies the number of octets that the value occupies, not its logical length. For example a text string may have 5 characters in it but occupy 10 octets (and hence have a length of 10) if the entity is using non ASCII characters. Need to correct the field names throughout the above paragraph. 9. Page 13, Section 8 Attributes =20 =91SetOfX=92 attributes (ones that have more than one value =96 example =91finishing=92) are represented by repeating the attribute triplet sequence for as many occurrences as required. The occurrences must be contiguous in the header. In the case where there is a default value then it must be the first value. In San Diego, we agreed that multiple values has all but the first with a Name-Length field of 0. This forces the additional values to be associated with the proper attribute. An example of multiple values would be good to include, as well. 10. Page 13, Section 8 Attributes Also need a statement of what happens if the same attribute appears more than once. Possibilities: syntax error, last occcurrence wins, first occurrence wins? 11. Page 14, 8.1.3 Boolean =20 Shall be represented by one octet. X=9200=92 meaning =91false=92 and X=92FF=92 meaning =91true=92. Model document has these values as 'false' and 'true', i.e., text string. 12. Page 14, 8.1.4 Integer =20 Shall be represented by a 32-bit signed integer . Includes IntegerSeconds, IntegerPoints, IntegerUnits. The IPP Model and Protocol documents have these as ASCII digits. 13. Page 14, 8.1.5 DateTime =20 Shall be encoded in RFC1123 format (e.g. =91Mon, 28 Apr 1997 09:00:00). IPP Model document should clarify this same way as printable text strings. 14. Page 14, 8.1.6 Keywords =20 Shall be represented by a 16-bit unsigned integer. Each set of allowable value for a keyword shall be assigned its own enumeration. This is specified for each Attribute that takes a keyword value. Where [ISO] defines a set of values for an attribute (=91medium=92 for example) then the OIDs specified are used. The Model document has keywrods as text strings of up to 255 characters in length. 15. Page 14, 8.2 Attributes =20 All job and document attributes defined in [IPP] may be included in the IPP1 header. =20 A server may ignore those attributes that it does not support. Model spec says that the Printer shall reject a CreateJob or PrintJob if the requester supplied any attributes that are not implemented, any values that are not supported, or any values with bad syntax. 16. Page 14, 8.2 Attributes =20 There are no mandatory attributes. Except the "operation" pseudo attribute. 17. Page 14, 8.2.1 Job-name =20 Syntax: Text (1 to 4096 characters) Model document has the 'name' data type as being 255 max length. 18. Page 15, Section 8.2.2 Job-originator =20 Meaning: A client assigned user name. NFS for the server =96 treated What is "NFS"? 19. Page 15, Section 8.2.3 Document-format =20 Syntax: Keyword =96 values taken from [RFC 1759] Model document has document-format attribute value as the enum symbol with the "lang" removed and the Protocol document has it as the MIME type, i.e., a text string name, not a binary code. 20. Page 15, Section 8.2.4 Operation =20 Syntax : Keyword =20 PrintJob =3D 1 =20 Validate =3D 2 Should be text string keywords: "PrintJob" and "Validate". 21. Page 16, 8.2.5 Examples =20 Strings are shown as characters to improve readability, it should be understood that =91a=92 means hex 21 What is =91a=92? EXCLAMATION POINT (!) is ASCII hex 21. From ipp-archive Thu Jun 12 21:55:09 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA01568 for ipp-outgoing; Thu, 12 Jun 1997 21:52:46 -0400 (EDT) Date: Thu, 12 Jun 1997 18:54:13 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706130154.SAA05460@woden.eng.sun.com> To: ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP> create job IPP operation X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Option 1 (flag for last document) is the best and only reasonable solution. Option 3 (end job operation) can be accomplished with Option 1 by allowing a document of length zero and the last flag on for clients that cannot figure out they are done when they send the last document. Bob Herriot > From rturner@sharplabs.com Thu Jun 12 17:13:25 1997. > > In our current document we have a CREATE-JOB operation that specifies up > front > how many documents we have. Is this an unrealistic requirement for > future IPP > clients (or drivers) ? Will they always know how many documents are > coming when > they first do the CREATE-JOB? > > My feeling is that the clients might not know how many documents will be > sent, and > if that is the case, we need a mechanism for SEND-DOCUMENT to indicate > to > the server that this is the last document for the job. There are at > least 3 ways to do > this off the top of my head: > > 1. Have a specific SEND-DOCUMENT attribute or parameter that flags a > particular > request as the last document for the job. > > 2. Since we are using HTTP 1.1 with persistent connections, just close > the TCP > connection from client to host indicating the end of the job stream > (or last document). > > 3. Have another IPP operation called END-JOB or CLOSE-JOB that > unambiguously > encapsulates the job stream within a CREATE-JOB/END-JOB pair. > > Comments? > > Randy > > > From ipp-archive Thu Jun 12 22:20:10 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA02087 for ipp-outgoing; Thu, 12 Jun 1997 22:16:07 -0400 (EDT) Date: Thu, 12 Jun 1997 19:17:34 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706130217.TAA05493@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO lengths versus delimiting characters X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk I was asked to write the rules for delimiting characters in different encodings. But after thinking some more and talking to another protocol expert, I believe that using binary lengths is a better solution than having delimiting characters because it avoids the escape-character problem. The escape-character problem has simple solutions, but length is even simpler. He also looked at the hybrid solution where the name is delimited by a colon and the value is determined by a length field prefix. He agreed with me that this is a strange solution that doesn't seem right. I think that we need to think of the application/ipp entity as a binary encoding that has nothing to do with HTTP headers. So it need not have headers that look like HTTP headers. Bob Herriot From ipp-archive Thu Jun 12 22:35:10 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA02576 for ipp-outgoing; Thu, 12 Jun 1997 22:32:52 -0400 (EDT) Date: Thu, 12 Jun 1997 19:34:19 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706130234.TAA05511@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD more new operations? X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk At the moment we have two ways to print jobs, one that does it one operation and one that does it in pieces. But when I look at this from the simple API point of view, I realize that both of these solutions take the "batch" point of view for print job submission. In the batch model the client submits a collection of attributes and the printer either says "yes" or "no" with a collection of attributes that caused it to say no. An alternate "interactive" model is for the client initially to ask the printer to create a job without specifying any attributes (CreateJobStub below). The printer returns a job URI and job template attributes to display on a GUI. When a user changes a value in a GUI, the client performs an operation (ChangeJobStub below) with the job URI that changes the attribute on the printer. With each change, the printer says yes or no. Thus the client knows before accepting the GUI whether the print job is OK. The SendDocument operation terminates the sequence of change operations. The new operations would be: CreateJobStub (to a Printer URI): the printer creates a job stub with each job attribute set to the Printer's default value. The Printer then returns a job URI and all the jobTemplate attributes (i.e. those which specify the printer default values and their potential values). ChangeJobStub (to a Job URI): the printer receives one attribute (name and value). If the change is allowed, the printer performs the change and returns success; otherwise it doesn't make the change and returns failure. Issue: should more than one attribute be allowed for this operation. If so do all have to succeed for any change to occur? Comments? Bob Herriot From ipp-archive Thu Jun 12 23:05:10 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA03089 for ipp-outgoing; Thu, 12 Jun 1997 23:04:30 -0400 (EDT) Message-ID: <33A0B95C.60DD@sharplabs.com> Date: Thu, 12 Jun 1997 20:07:08 -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>MOD more new operations? References: <199706130234.TAA05511@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk I think its an interesting idea, something akin to what I was thinking about when I was using multiple URLs and create-job was just a very simple object creation thing. But given where we are right now, I don't think there's enough advantage in doing this to fatten up the protocol with more operations. We just added two, which on reflection we probably could have used attributes to accomplish but I understand the rationale. I think at this point we should just flesh out what we have and if what we have doesn't cut it with the overall IPP requirements then we start fattening it up some more or re-think our requirements. Its not that what you're proposing couldn't be accomplished with our current set of operations, it would just be a little more bulky to pull it off. And ultimately, I'm not sure if the future IPP world will be interactive or batch-driven. All I can do is look at how systems work today (batch) and attempt to model them. Randy Robert Herriot wrote: > > At the moment we have two ways to print jobs, one that does it one operation > and one that does it in pieces. > > But when I look at this from the simple API point of view, I realize that both > of these solutions take the "batch" point of view for print job submission. > In the batch model the client submits a collection of attributes and the > printer either says "yes" or "no" with a collection of attributes that > caused it to say no. > > An alternate "interactive" model is for the client initially to ask the > printer to create a job without specifying any attributes > (CreateJobStub below). The printer returns a job URI and job template > attributes to display on a GUI. When a user changes a value in a GUI, > the client performs an operation (ChangeJobStub below) with the job URI > that changes the attribute on the printer. With each change, the > printer says yes or no. Thus the client knows before accepting the GUI > whether the print job is OK. The SendDocument operation terminates the > sequence of change operations. > > The new operations would be: > > CreateJobStub (to a Printer URI): the printer creates a job stub with > each job attribute set to the Printer's default value. The Printer then > returns a job URI and all the jobTemplate attributes (i.e. those which > specify the printer default values and their potential values). > > ChangeJobStub (to a Job URI): the printer receives one attribute (name > and value). If the change is allowed, the printer performs the change > and returns success; otherwise it doesn't make the change and returns > failure. Issue: should more than one attribute be allowed for this > operation. If so do all have to succeed for any change to occur? > > Comments? > > Bob Herriot > From ipp-archive Fri Jun 13 07:40:15 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA04351 for ipp-outgoing; Fri, 13 Jun 1997 07:36:58 -0400 (EDT) From: Roger K Debry To: Subject: IPP>MOD more new operations? Message-Id: <5030100003507247000002L072*@MHS> Date: Fri, 13 Jun 1997 07:38:38 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk I believe that we should try as hard as we can to hold the line on any new invention on IPP and press on to get what we have done crisply written, agreed upon and through the standards process. If the interactive operations Bob proposes have some value then we can add them to version 2, but I'd rather not spend the energy debating that issue when we there are more pressng problems to be agreed upon. 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 06/13/97 05:30 AM --------------------------- ipp-owner @ pwg.org 06/12/97 08:42 PM Please respond to ipp-owner@pwg.org @ internet To: ipp @ pwg.org @ internet cc: Subject: IPP>MOD more new operations? At the moment we have two ways to print jobs, one that does it one operation and one that does it in pieces. But when I look at this from the simple API point of view, I realize that both of these solutions take the "batch" point of view for print job submission. In the batch model the client submits a collection of attributes and the printer either says "yes" or "no" with a collection of attributes that caused it to say no. An alternate "interactive" model is for the client initially to ask the printer to create a job without specifying any attributes (CreateJobStub below). The printer returns a job URI and job template attributes to display on a GUI. When a user changes a value in a GUI, the client performs an operation (ChangeJobStub below) with the job URI that changes the attribute on the printer. With each change, the printer says yes or no. Thus the client knows before accepting the GUI whether the print job is OK. The SendDocument operation terminates the sequence of change operations. The new operations would be: CreateJobStub (to a Printer URI): the printer creates a job stub with each job attribute set to the Printer's default value. The Printer then returns a job URI and all the jobTemplate attributes (i.e. those which specify the printer default values and their potential values). ChangeJobStub (to a Job URI): the printer receives one attribute (name and value). If the change is allowed, the printer performs the change and returns success; otherwise it doesn't make the change and returns failure. Issue: should more than one attribute be allowed for this operation. If so do all have to succeed for any change to occur? Comments? Bob Herriot From ipp-archive Fri Jun 13 07:45:18 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA04537 for ipp-outgoing; Fri, 13 Jun 1997 07:44:27 -0400 (EDT) From: Roger K Debry To: Subject: IPP>PRO lengths versus delimiting characters Message-Id: <5030100003507354000002L042*@MHS> Date: Fri, 13 Jun 1997 07:46:12 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk In IBM's IPDS data stream we have used what we call "triplets" for over a decade in encoding infomation in the data stream. A triplet is a structure of the form: length - 2 bytes id - 2 bytes data - n bytes, where n is defined by the length field. All IDs are registered and define the type of data and associated semantic if any of the content. 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 06/13/97 05:37 AM --------------------------- ipp-owner @ pwg.org 06/12/97 08:25 PM Please respond to ipp-owner@pwg.org @ internet To: ipp @ pwg.org @ internet cc: Subject: IPP>PRO lengths versus delimiting characters I was asked to write the rules for delimiting characters in different encodings. But after thinking some more and talking to another protocol expert, I believe that using binary lengths is a better solution than having delimiting characters because it avoids the escape-character problem. The escape-character problem has simple solutions, but length is even simpler. He also looked at the hybrid solution where the name is delimited by a colon and the value is determined by a length field prefix. He agreed with me that this is a strange solution that doesn't seem right. I think that we need to think of the application/ipp entity as a binary encoding that has nothing to do with HTTP headers. So it need not have headers that look like HTTP headers. Bob Herriot From ipp-archive Fri Jun 13 07:50:20 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA04626 for ipp-outgoing; Fri, 13 Jun 1997 07:45:46 -0400 (EDT) From: Roger K Debry To: Subject: Re: IPP> create job IPP operation Message-Id: <5030100003507393000002L032*@MHS> Date: Fri, 13 Jun 1997 07:47:24 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk I thought at one time we had agreed on sending an empty Send-Document? The proposal that Keith Carter and I had made included an EndJob, but was rejected. 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 06/13/97 05:41 AM --------------------------- ipp-owner @ pwg.org 06/12/97 08:02 PM Please respond to ipp-owner@pwg.org @ internet To: rturner @ sharplabs.com @ internet, ipp @ pwg.org @ internet cc: Subject: Re: IPP> create job IPP operation Option 1 (flag for last document) is the best and only reasonable solution. Option 3 (end job operation) can be accomplished with Option 1 by allowing a document of length zero and the last flag on for clients that cannot figure out they are done when they send the last document. Bob Herriot > From rturner@sharplabs.com Thu Jun 12 17:13:25 1997. > > In our current document we have a CREATE-JOB operation that specifies up > front > how many documents we have. Is this an unrealistic requirement for > future IPP > clients (or drivers) ? Will they always know how many documents are > coming when > they first do the CREATE-JOB? > > My feeling is that the clients might not know how many documents will be > sent, and > if that is the case, we need a mechanism for SEND-DOCUMENT to indicate > to > the server that this is the last document for the job. There are at > least 3 ways to do > this off the top of my head: > > 1. Have a specific SEND-DOCUMENT attribute or parameter that flags a > particular > request as the last document for the job. > > 2. Since we are using HTTP 1.1 with persistent connections, just close > the TCP > connection from client to host indicating the end of the job stream > (or last document). > > 3. Have another IPP operation called END-JOB or CLOSE-JOB that > unambiguously > encapsulates the job stream within a CREATE-JOB/END-JOB pair. > > Comments? > > Randy > > > From ipp-archive Fri Jun 13 08:15:16 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA05842 for ipp-outgoing; Fri, 13 Jun 1997 08:10:56 -0400 (EDT) From: Roger K Debry To: Cc: Keith Carter Subject: IPP>DIR - New Internet drafts Message-Id: <5030100003508017000002L072*@MHS> Date: Fri, 13 Jun 1997 08:12:40 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk I have just posted four new documents to the pwg site for Keith. These are ftp.pwg.org/pub/pwg/ipp/new_SEC/ipp-dir-schema-21.doc ftp.pwg.org/pub/pwg/ipp/new_SEC/ipp-dir-schema-21.pdf ftp.pwg.org/pub/pwg/ipp/new_SEC/directory-issues.doc ftp.pwg.org/pub/pwg/ipp/new_SEC/directory-issues.pdf 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 Jun 13 10:55:17 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA06610 for ipp-outgoing; Fri, 13 Jun 1997 10:50:47 -0400 (EDT) From: Roger K Debry To: Subject: IPP>SEC - new Internet Drafts Message-Id: <5030100003513319000002L092*@MHS> Date: Fri, 13 Jun 1997 10:52:31 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk I have posted the following new Internet Drafts ftp.pwg.org/pub/pwg/ipp/new_SEC/draft-ietf-ipp-security-00.txt ftp.pwg.org/pub/pwg/ipp/new_SEC/draft-ietf-ipp-security-00.pdf ftp.pwg.org/pub/pwg/ipp/new_SEC/draft-ietf-ipp-security-00.doc The .doc and .pdf files have line numbers which I would appreciate your using if you have specific comments to make on the document. Carl-Uno and I also request that everyone coming to the meeting at Sun next week please read the security I-D so that we can all have the same level of understanding of security issues as we discuss the protocol. 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 Jun 13 11:20:18 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA07136 for ipp-outgoing; Fri, 13 Jun 1997 11:18:54 -0400 (EDT) From: Roger K Debry To: Subject: IPP>SEC, IPP>MOD, IPP>DIR - Security attributes Message-Id: <5030100003514868000002L082*@MHS> Date: Fri, 13 Jun 1997 11:20:37 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk As you read the new security internet-draft you will see that four common usage scenarios are described. These are: o no security o message protection o client authentication and authorization o mutual authentication, authorization, and message protection In order to let a person who is searching a directory know what to expect in terms of security, we need some Printer attributes that would be stored in the directory to help indicate this. For example, when I search a directory, I want to know which printers require authentication. There are undoutbedly many ways to do this. I would appreciate your comments on the following proposal as a way to get some discussion going on this ... New Printer Attributes: Message Protection values are none, supported or required Authentication/Authorization values are none, supported, or required Supported means that the Printer is capable of supporting this security feature, but it is does not require the client to use it. For example, if message protection is supported, it means that a client can encrypt a message if privacy is required, but does not have to. Required means that the Printer is capable of supporting this privacy feature, and the client is required to use it. For example, if authentication/authorization is required, then the client must be authenticated before using the Printer. Alternatives include listing each security protocol supported as an attribute with values as above, or having one attribute called security with the names of the supported protocols as values. Comments??? 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 Jun 13 12:40:18 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA07737 for ipp-outgoing; Fri, 13 Jun 1997 12:37:43 -0400 (EDT) Message-Id: <3.0.1.32.19970613092134.00adb660@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 13 Jun 1997 09:21:34 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - We now have a slot in Munich Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk In today's version of Harald's schedule there is now one slot allocated for the IPP. It is on Monday, August 11, 3:30 to 5:30 pm local time in Germany. We will all still be a bit jetlagged I suppose... 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 Fri Jun 13 13:09:16 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA08307 for ipp-outgoing; Fri, 13 Jun 1997 12:50:54 -0400 (EDT) Message-ID: <33A17BA4.996FA768@sharplabs.com> Date: Fri, 13 Jun 1997 09:56:04 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: [Fwd: IPP> create job IPP operation] X-Priority: 3 (Normal) Content-Type: multipart/mixed; boundary="------------B4F6B6D5C03139084775F05F" Sender: ipp-owner@pwg.org Precedence: bulk This is a multi-part message in MIME format. --------------B4F6B6D5C03139084775F05F Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --------------B4F6B6D5C03139084775F05F Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <33A179B0.1907D7FA@sharplabs.com> Date: Fri, 13 Jun 1997 09:47:44 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: Robert Herriot Subject: Re: IPP> create job IPP operation X-Priority: 3 (Normal) References: <199706130154.SAA05460@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I liked option #1 myself but then I started wondering if the IPP client would know if the document it has is the last document there will be. If it is continually receiving documents to send from some other source (like a windows print driver), then whatever protocol or API is being used to deliver the documents to the IPP client for delivery would also have to have a LAST-DOCUMENT flag built into the protocol or API. If not, then the IPP client (port driver, redirector, or whatever) would not know to set the LAST-DOCUMENT attribute in the SEND-DOCUMENT request. Rather, some time later it would be notified that the job stream is closed and then it would either have to send something like a CLOSE-JOB or a SEND-DOCUMENT with a zero length data field, or something other extra message. Or, it could just use option #2 and close the connection. Randy Robert Herriot wrote: > Option 1 (flag for last document) is the best and only reasonable > solution. > > Option 3 (end job operation) can be accomplished with Option 1 by > allowing a document of length zero and the last flag on for clients > that cannot figure out they are done when they send the last document. > > Bob Herriot > > > From rturner@sharplabs.com Thu Jun 12 17:13:25 1997. > > > > > In our current document we have a CREATE-JOB operation that > specifies up > > front > > how many documents we have. Is this an unrealistic requirement for > > future IPP > > clients (or drivers) ? Will they always know how many documents are > > coming when > > they first do the CREATE-JOB? > > > > My feeling is that the clients might not know how many documents > will be > > sent, and > > if that is the case, we need a mechanism for SEND-DOCUMENT to > indicate > > to > > the server that this is the last document for the job. There are at > > least 3 ways to do > > this off the top of my head: > > > > 1. Have a specific SEND-DOCUMENT attribute or parameter that flags a > > > particular > > request as the last document for the job. > > > > 2. Since we are using HTTP 1.1 with persistent connections, just > close > > the TCP > > connection from client to host indicating the end of the job > stream > > (or last document). > > > > 3. Have another IPP operation called END-JOB or CLOSE-JOB that > > unambiguously > > encapsulates the job stream within a CREATE-JOB/END-JOB pair. > > > > Comments? > > > > Randy > > > > > > --------------B4F6B6D5C03139084775F05F-- From ipp-archive Fri Jun 13 13:25:19 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA09099 for ipp-outgoing; Fri, 13 Jun 1997 13:20:51 -0400 (EDT) Message-Id: <199706131721.NAA10215@devnix.agranat.com> To: ipp@pwg.org Subject: Re: IPP> create job IPP operation In-reply-to: <33A09002.87BEBC15@sharplabs.com> Date: Fri, 13 Jun 1997 13:21:02 -0400 From: "Scott Lawrence" Sender: ipp-owner@pwg.org Precedence: bulk >>>>> "RT" == Randy Turner writes: RT> ...we need a mechanism for SEND-DOCUMENT to indicate to the server RT> that this is the last document for the job. There are at least 3 RT> ways to do this off the top of my head: RT> ... RT> 2. Since we are using HTTP 1.1 with persistent connections, just RT> close the TCP connection from client to host indicating the end of RT> the job stream (or last document). Don't throw away the advantage of persistent connections by repeating the HTTP{0.9|1.0} mistake of using the connection close as a normal signalling mechanism. For example, I expect that many implementors will want to follow up a submit-job with an immediate status query (my own alias for invoking lpr includes an lpq). -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-archive Fri Jun 13 15:00:20 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA09756 for ipp-outgoing; Fri, 13 Jun 1997 14:59:49 -0400 (EDT) Message-ID: <33A199E7.78A0BDB4@sharplabs.com> Date: Fri, 13 Jun 1997 12:05:11 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> New draft available X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk I have posted versions of the latest protocol draft on the PWG FTP server ftp::/ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-061397.pdf and ftp::/ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-061397.txt This draft reflects alot of the text-based protocol discussions we have had at the last protocol teleconference and general IPP teleconference sessions... Randy From ipp-archive Fri Jun 13 17:55:24 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA10597 for ipp-outgoing; Fri, 13 Jun 1997 17:50:50 -0400 (EDT) Date: Fri, 13 Jun 1997 14:52:12 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706132152.OAA06253@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO !!LOCATION CHANGE!! directions and agenda for June 17th meeting at Sun X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk I have finally gotten a room for the Protocol meeting at Sun on Tuesday June 17th. The two available rooms on the Menlo Park campus were both too small for the group. NOTE!! The LOCATION HAS CHANGED to Mountain View from Menlo Park. This location is 3 exits and 4 miles further south than the Menlo Park campus. The meeting is in the Boardroom conference room in MTV-05 (Building 5 on the Mountain View campus. Since the MTV-05 lobby is locked, please go to the MTV-01 (Building 1) lobby. The address is 2550 Garcia in Mountain View. The phone number of the Boardroom conference room is 415-336-4861. The database also lists 415-336-1241, but I'm not sure it is works. I have not arrangement for a conference service because it appears that we will only have 1 or 2 people most of the time. I have put a map at ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/SunMTVMap.ps If you are coming from San Francisco, take the San Antonio exit East. If you miss it, take the next exit (Amphitheatre Pkwy) and follow the directions in the next paragraph. Turn right at the first light and proceed along the frontage road. Take first left (which is Garcia). After about 1 1/2 blocks, turn left when you see the blue and white sign for Sun building 1 (MTV-01). Intuit signs will be on the right side of the road. If you are coming from San Jose, take the Amphitheatre Pkwy exit (only East). If you miss it, take the next exit (San Antonio) and follow the directions in the preceding paragraph. Turn left at first light and then proceed down Garcia until you see the blue and white sign for Sun building 1 (MTV-01) on the right. Intuit signs will be on the left side of the road. ------------------------------------------------ Agenda: Discuss the following topics: lengths versus delimiters representation of values, text versus binary Randy's document other issues. The following people have RSVPed in person Randy Turner Bob Herriot Carl-Uno Manros Roger deBry Jeff Copeland Tom Hastings Brian Grimshaw Keith Carter Sylvan Butler telephone Peter Zehler Jay Martin Scott Isaacson (a few hours) From ipp-archive Fri Jun 13 21:00:25 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA11968 for ipp-outgoing; Fri, 13 Jun 1997 20:59:15 -0400 (EDT) Date: Fri, 13 Jun 1997 18:00:44 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706140100.SAA06446@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO Update to Randy's document X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk I have just downloaded a 3 page document: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-061397-rgh.doc and ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-061397-rgh.txt This document contains the binary encoding of the protocol that Randy left out of his document. He has a text encoding instead. I also corrected the raw TCP/IP encoding in his document. The .doc version has pictures of the encodings that are not in the text version. We will discuss this document at the Tuesday meeting. Bob Herriot From ipp-archive Mon Jun 16 13:39:04 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA00965 for ipp-outgoing; Mon, 16 Jun 1997 13:36:18 -0400 (EDT) Date: Mon, 16 Jun 1997 13:36:19 -0400 (EDT) From: JK Martin Message-Id: <199706161736.NAA04481@uscore.underscore.com> To: pwg@pwg.org Subject: IPP> Please RSVP to the June Meetings if you have not already done so Cc: p1394@pwg.org, ipp@pwg.org, jmp@pwg.org, pmp@pwg.org, sense@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk [Sorry for the cross-posting, but this message must get out to *everyone* as soon as possible...] The hotel is asking that we have a firm attendance count by Wednesday, June 18 (that is, the day after tomorrow) for the series of PWG meetings to be held Monday thru Friday, June 23-27 (ie, NEXT WEEK). If you have not already sent me a message with the dates of the meetings you plan to attend--OR IF YOU HAVE CHANGED YOUR PLANS since sending me a message--then please send me (jkm@underscore.com) a message BEFORE NOON EDT on Wednesday, June 18. Following are the lists of people who claim to be attending the various PWG meetings scheduled for next week. If you have already sent an RSVP (aka "ping") message, then please be sure your name is listed under the appropriate meeting(s): P1394 (Monday-Tuesday, June 23-24) Alan Berkema Brian Batchelder Danny Mitchell Don Wright Frank Zhao Fumio Nagasaka Greg LeClair Hamid Shenavai Jeff Rackowitz Larry Stein Richard Andrade Shigeru Ueda IPP (Wednesday-Thursday, June 25-26) Angelo Caruso Bob Pentecost Carl-Uno Manros Charles Gordon Chuck Adams Don Wright Frank Zhao Greg LeClair (Wed only) Jasper Wong Jay Martin Jeff Copeland Jeff Rackowitz Lloyd Young (Thurs only) Richard Landau Richard Schneider Robert Herriot Scott Isaacson Shigeru Ueda Stuart Rowley Tom Hastings JMP (Thursday nite, Friday, June 26-27) Angelo Caruso Bob Pentecost Chuck Adams Don Wright Jeff Rackowitz Lloyd Young Richard Landau Stuart Rowley Tom Hastings Folks, we really need to have ACCURATE counts of attendees, so if you're planning to attend one or more of next week's meetings, then by all means please send me a message NOW if you haven't already done so. Similarly, if your plans have changed such that you will not be attending one or more meetings (or if I have you down for the wrong meetings), please let me know ASAP. Thanks for your cooperation. ...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 Jun 16 15:14:02 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA02928 for ipp-outgoing; Mon, 16 Jun 1997 15:10:16 -0400 (EDT) Date: Mon, 16 Jun 1997 12:11:17 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706161911.MAA07758@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO Enclosed: Update to Randy's document Content-Type: X-sun-attachment Sender: ipp-owner@pwg.org Precedence: bulk ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 6 Because the pwg server is down today, I have enclosed the MS Word and text version of the files that I downloaded on Friday. This document will be part of tomorrow's discussions. Bob Herriot ---------- X-Sun-Data-Type: default-app X-Sun-Data-Description: default X-Sun-Data-Name: ipp-pro-061397-rgh.doc X-Sun-Encoding-Info: uuencode X-Sun-Content-Lines: 1027 begin 600 ipp-pro-061397-rgh.doc MT,\1X*&Q&N$ /@ # /[_"0 & ! M " $ #0 $ #^____ D #_____________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M______________________]2 &\ ;P!T " 10!N '0 <@!Y 0 0 M6P !4 !@!4 #P ! %@ "4! !P %@ % ?______ M____ 0 X-I>E%QXO & RWB47'B\ 1 M # "@ !@ %< ;P!R &0 1 !O &, =0!M &4 ;@!T 3 !PT$P 0SI< M<')I;G1I;F=<:7!P7&YE=U]04D\ = $ * ! : (! @ , #_____ M !8 "* 0 0@$ !4 !@!4 00 ! "P )8@ !5 M 0 3P!B &H 90!C '0 4 !O &\ ; M0$ 'X! 5 8 5 $X M 0 !8 #* 0 ?0$ !8 0'__________P4 M .#:7I1<>+P!X-I>E%QXO $6 ]0$ -0! % %, M=0!M &T 80!R 'D 20!N &8 ;P!R &T 80!T &D ;P!N @ ( M * " ?____\$ _____P BP$ )H! M 0 "\ 0 *S PG0X #]____ P M 0 % !@ < * ___________^____4 /__________ M&@ /[___\1 '@ /______________________________________ M____&P !P = _O___RT @ (0 "( C ) "4 M F )P "@ I *@ "L L _O___S@ O , M #$ R ,P #0 U -@ #< #^____1@ #H [ M/ #T ^ /P $ !! 0@ $, !$ 10 /[____^ M____2 $D !* 2P $P !- 3@ $\ #^____40 %( M !3 5 %4 !6 5P %@ " ____________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M________#@ < @ 0!+ \ !H $#Q_P( &@ &3F]R;6%L ( # M &$)! N % 0 " 2X "4AE861I;F<@,0 "@ ! @!%? %CP "P!5@5T" M &,< &L< L ) 0 " 2P "4AE861I;F<@,@ "@ " @!%? %CP "@!5 M@5:!70( 8Q@ * #0 $ @$H E(96%D:6YG(#, H P ( 17P !8\ 8 M70( 8Q@ (@!!0/+_H0 B !9$969A=6QT(%!A2!497AT % ! %G@ )@!#0 $ $@$F !!";V1Y M(%1E>'0@26YD96YT @ $0 1: $6> %H ,$ ! "(!6@ +3&ES="!"=6QL M970 $ $@ -"Q%H 1.8_@PT_P$ " 0 $ : $ "W M 7 V0 $ ,@%< U,:7-T($)U M;&QE=" R ! !, #0L1T (3F/X,-/\! @ $ ! &@! MP M %P -T ! $(!7 -3&ES M="!"=6QL970@,P 0 4 T+$3@$$YC^##3_ 0 ( ! 0!H 0 M +< D $1 0!2 20 M#4QI "8 14 ! &(!)@ /3&ES="!# M;VYT:6YU92 R ( !8 $= "%G@ F $9 0!R 28 #TQIB93)6A!0 ! $ $ ( @ ! %@" #" M 0 9 #__P __\ /__ #__P __\ /__ #__P M__\ M M M M M M M M /__0W5S=&]M('!A9V4@,0 M D$( )!" M0W5S=&]M('!A9V4@,@ M D$( )!" 0W5S=&]M('!A9V4@ M,P M D$( )!" !L=P M $ P24 +@"'V< $ 0#J"F\(9 ! < + $! M $ + $# @ M !@"0 Y P $ 0 ( S"[* MTQ'HF4R5H04 0 ! ! " ( 0!8 @ P@$ &0 M __\ /__ #__P __\ /__ #__P __\ /__ M M M M M M M M #_ M_T-U0 $ $ M %L 5 8 5 \ 0 !8 E 0 < !8 !0'_____ M_____P$ "0( , !& .#:7I1<>+P!@,MXE%QXO $0 M 0 L 8 !7 &\ <@!D $0 ;P!C '4 ;0!E &X = $P <-!, $,Z M7'!R:6YT:6YG7&EP<%QN97=?4%)/ '0! "@ 0 &@ " 0( # ____ M_P 6 B@$ $(! 5 8 5 $$ 0 L "6( M50$ $\ 8@!J &4 8P!T % ;P!O &P +4! !^ 0 %0 & %0!. M $ 6 R@$ 'T! 6 $!%0 /____\% M #@VEZ47'B\ >#:7I1<>+P!%@ /4! #4 0 !0!3 M '4 ;0!M &$ <@!Y $D ;@!F &\ <@!M &$ = !I &\ ;@ ( " M "@ @'_____! /____\ (L! ": M 0 $ O $ "LP,)W__________P, M $ !0 8 ' "@ X #]_____O___U #^_____O__ M_QH #_____$0 !X #^____________________________________ M_____QL < # /____\M ( "$ B (P "0 E M )@ "< H *0 "H K + /[___\X +P # M Q ,@ #, T -0 #8 W _O___Q( Z .P M #P ] /@ #\ ! 00 $( !# 1 $4 #^____ M_____T@ !) 2@ $L !, 30 $X !/ _O___U$ !2 M 4P %0 !5 5@ %< !8 @ /__________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_________P( &@! &]L%J9O;!:F $ )$! #O" P $ M ! "#$!, , 0 $ T0( 20 (4,Z M7$U33V9F:6-E7%1E;7!L871E"AL1KA M #X P#^_PD !@ 0 ! \ ! M_O___P ! ____________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M________________________________W*5H &/@"00 90 M , -8- "6( -8* M 4 >! !0 !X$ >& M !X8 'A@ >& !X8 4 :!@ !H& M &@8 :!@ !H& &@8 * M]1\ %@ !-( 20 ,0? !X8 M JA@ < " ! ( JA@ "J& M "J& *H8 Q!\ #,& !X8 M 'A@ "J& ""& # $\ M8@!J $D ;@!F &\ #_________________________________________ M____________________$@ " /__________________________________ M________ !L $ _____P$ 0P!O &T < !/ M &( :@ /__________________________________________________ M__________\2 ( __________________________________________\ M *P &H #_____________________________ M____________________________________________________________ M_P #_____________________________________________________ M____________________________________________________________ M____________________________________________________ /__ M____________________________________________________________ M_________________P$ " P /[___\% !@ < ( M"0 H #^_____O___PT . #P /[___\1 $@ !, 4 M %0 !8 #^____& /[___\: _O____[___\= '@ !\ M #^____(0 "( C ) "4 F _O___R@ #^____*@ M /[___\L _O______________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M________________________________________!0!$ &\ 8P!U &T 90!N M '0 4P!U &T ;0!A '( >0!) &X 9@!O '( ;0!A '0 :0!O &X MS*2$@C@ @#_______________\ /(!_@@ M W !? #D ,@ W #< ,@ W #, ,@ R M___^____ /_____^____ /_____^____ /_____^____%@ ! M ?____\& #P $) @ P $8 X-I>E%QXO &@ FB4 M7'B\ 0$ 0 " /U_: %\ .0 R #< -P R #@ -0 R #8 #]?_@% !( M1OU_ " $ #X!0 0 $ 0P 6 $ ________ M__\( 0D" # 1@ "@ FB47'B\ : ":)1<>+P!+@ M\/#7_'\2 /U_ P!0 $D 0P #,I(2" #^____ MP@)_@@ 4TH2"?0$ H H @'_______________\8 M %$ ) _____P 9 3 (C1 MA((! @ , #^____!0 8 ' " D * _O__ M__[___\- #@ \ #^____$0 !( 3 % !4 6 M_O___Q@ #^____&@ /[____^____'0 !X ? _O___R$ B M (P "0 E )@ /[___\H _O___RH #^____________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M__________________________[_ $ ( $ M "USV3 ", 0 $@ $ "8 @ * # N 0 #$ M !0 - & W < #H " /P ) " $ !( M 4 0 "@ #P! + 2 $ P !4 0 #0 & ! . ; $ M \ !T 0 $ 'P! 3 A $ ( #D! '@ \ !)3E1% M4DY%5"U$4D%&5 '@ $ .FD0'@ 0 !B;V( '@ $ M "@'@ $ =', '@ P !D969A=6QT+F1O= > ! &)O M8@ > @ #$ 1@ > '@ $UI8W)O+P! M0 #:L7=<>+P! P , # D0$ , #O" P #0 MSQ'@ # -#/$>"AL1KA #X P#^_PD !@ M 0 P ! /[_ $ ( M $ "U"AL1KA #X P#^_PD M!@ 0 P ! /[_ PH /____\ "0( , M !&& $UI8W)O"!F2 Q#6]P97)A=&EO;BUM:6YO2P@:6YI=&EA;&QY(# -;W!E#=F+F9F+F9F+F9F(" [(&YU;6)E# P+C P+BXE>#=F+F9F(" [(&YU;6)E9)S($%P<&5N9&EX($$@6YT87@@:71E;7,@=&AA="!A0UT M# P+C P+C P+C P("XN("5X-V8N9F8N9F8N M9F8@.R!N=6UB97(@;V8@;V-T971S(&9O# P+C P+C P+C P("XN("5X M-V8N9F8N9F8N9F8@(#L@;G5M8F5R(&]F(&]C=&5TSV3 " 0 $@ $ M "8 @ * # K 0 "X !0 ,0 & T M < #< " / ) _ !( ( 0 "@ # ! + M/ $ P !( 0 #0 %0! . 8 $ \ !H 0 $ ' ! 3 M > $ ( #D! '@ $ ;V( '@ $ '@ 0 M !B;V( '@ $ ]T4 '@ $ 0 #'@ L !.;W)M86PN M9&]T > ! &)O8@ > @ #( > '@ $UI8W)O+P!0 #:L7=<>+P! P $ # P , M 3 P #0SQ'@H;$:X0 0#^_P,* #_____ 0D" M # 1A< !-:6-R;W-O9G0@5V]R9"!0:6-T=7)E H !- M4U=O+P!VA( @ #B$@ #@ &H2 M:A( !J$@ &H2 [A, #^$P /X3 M _A, M M @(" @(" @(" @(" @(" @(" @(" @(#71H92!C:'5N:W,@9F]R M;2!T:&4@;W!E0T-=F%L=64@;&5N9W1H#0UN86UE(&QE;F=T: T-;F%M90T-=F%L=64-#3(@ M8GET97,-#3(@8GET97,-#84@:7,@9F]R(&UOJ90>J@ R $!!C ($* $ M(EDNU!6' 0 4 ____ /___P #( 0$,, M @0H .DA32K>!( M!( C0P@F! )01"" @X M P $!!# $ )@"B(0,J0PBW 0 !""+8! @X M !T $! # 9:@!X&$ F)0FQ 0, P F J E"0D! M @X ____ "!"@ M@, !T"AP$ % M /___P#___\ " $. I/\ '0 0$!, M !EJ '@8]B!B])"4)(0(# , )@ M )0DA @ (. /___P @0H &H!20#K!H912' 0 4 ____ M /___P (" 0$", !GX >LIKR,$#P@(" "!"@ M20% !*X'AP$ % /___P#___\ !EJ . F M">P! P # "8 "4)ZP$ "#@ #___\ ($ M* !) 1P K@>' 0 4 ____ /___P ( 0X %=89 MW "D_P 9:@ "X")@GL 0, P F E">L! @X M____ "!"@ F0(< /T#AP$ % /___P#___\ M " $. !76(]H I/\# "8 E!"4)ZP$ "#@ M #___\ 9:@ !L&)@GL 0, P F E">L! M @X ____ "!"@ [0(< /T#AP$ % /__ M_P#___\ " $. !76-M8 I/\"!"@ )0H -X$AP$ M % /___P#___\ @0H -$)0 3>!( I,!_@ /X >4$DP'^ _@ !X 23 ?X #^ '" M"),!_@ /X 3L(DP'^ _@ !'@*3 ?X #^ 'P!I,! M_@ /X ? &DP'^ _@ !6 B3 ?X #^ 'H I,!_@ M /X 1X%DP'^ _@ !:Q23 ?X #^ &U!Y,!_@ M /X ;4'DP'^ _@ ! P23 ?X #^ '^ Y,!_@ /X M > $DP'^ _@ !Y023 ?X #^ $[%),!_@ /X M #^ &R(? 0 +0X #P ( $ 2P / : ! \?\" M !H !DYO 8 $ J@8 V@8 M"@< .@< $ K@< $ (@@ $ E@@ Q@@ $ ^ @ $ ; D M $ X D $ $@H 8 % P $ !@ \ 0 !P ' /] ;'< 1DE, M13H 4%-#4DE05 !L=P!L=P M $ P24 +@"'V< $ 0#J"F\(9 ! < + $! $ + $# M @ !@"0 Y P $ M 0 ( S"[*TQ'HF4R5H04 0 ! M ! " ( 0!8 @ P@$ &0 __\ /__ #_ M_P __\ /__ #__P __\ /__ M M M M M M M M #__T-U"AL1KA M #X P#^_PD !@ 0 P , T,\1X*&Q&N$ M /@ # /[_"0 & ! # M$ _O\ 0 @ 0 +5S=6<+AL0DY<( "LL M^:XP H @ ! 2 \ !0 ! %P % 9 M 8 !L "P '0 0 ? P "$ @ .0$ > M! '-U;@ # #H , ! P $ + L M #! ( > 0 # -#/$>"AL1KA M #X P#^_PD !@ 0 @ =SL6'P 0 ) M #G D @ 1 % "8&#P > /____\$ !0 !7;W)D#@!-:6-R M;W-O9G0@5V]R9 4 + @ % # *L P8'#0 /L" M ! P$ +0$ 0 " 0$ %0 /L"UO\ "0 0 M $ 25&EM97,@3F5W(%)O;6%N !$ ! "T! 0 % "0( ! M (! 0 $ @$! X F!@\ $@#_____ ( A@4 &@& ' M_ (! 0 M 0( "0 /H" # B( ! "T! P ' M &P1L %,"!0!J D #Z @ B 0 M 00 ! / ! M P ' _ ( /___P 0 M 0, ! (! 0 # '@ ' %@1= M !<""@ & 00 " 0$ %0 /L"N?\ "0 0 $ 25&EM97,@ M3F5W(%)O;6%N !D ! "T!!0 6 ,@H- 8!!P $ &!ZP#=F5R M M < 6!#L!00+I (0 ! (! 0 $ +0$% " R"NP A . 0 M 8'K -O<&5R86YD(&QE;F=T:", ) ? !@ ( C ", $@ 4 !\ (P C M !0 (P $ @$! 0 G ?__! (! 0 . )@8/ !( _____P M" (8% S!P ! "T! @ ) ^@( , "(@ $ +0$& M < ;!,D 4P)J &H ! "T!! $ \ $& 0 M 0, ! (! M 0 # '@ ' %@3$ +L!<@ @ 00 " 0$ ! "T!!0 0 ,@IU M " ! P $ &!ZP#6$E$ #, %P S 0 " 0$ ! " < 6!"\#2 += G4 ! (! 0 $ +0$% "( R"N " M=0 / 0 8'K -O<&5R871I;VX@8VAU;FL (P D !\ & @ !0 % C M ", $@ @ ", (P C "0 ! (! 0 $ )P'__P0 " 0$ ! (! M 0 # '@ ' %@1= ,@&"@"' @0 " 0$ ! "T!!0! ,@H- M (<"(P $ &!ZP#,B!B>71EP($ @$! M 0 M 04 %@ #(*=P![ @< ! !@>L S0@8GET97, ) 2 "0 M(@ 4 !\ ' $ @$! 0 G ?__! (! 0 $ +0$" D #Z M @4 P (B 0 M 08 "0 /H" # B( ! "T! M!P , )0,$ &D Y@ ! .8 0!E D< 90($ +0$$ 0 #P 08 ! M / !!P $ +0$# 0 " 0$ ! (! 0 ' _ ( ( 0 M M 08 "0 /H"!0 ! ____ "( ! "T!!P , ) ,$ $( <@)( M &0"0@!6 F\ 9 ($ +0$$ 0 #P 0< ! "T! P $ \ $& 0 M " 0$ ! (! 0 . )@8/ !( _____P " ( % "1"0 ! M "T! @ ) ^@( , "(@ $ +0$& < ;!/0!4 *\ 6< M! "T!! $ \ $& 0 M 0, ! (! 0 # '@ ' %@3K M 9X!F0$M 00 " 0$ ! "T!!0 0 ,@J< 2T! P $ &!ZP# M+BXN !( $@ 2 0 " 0$ ! " < 6!%8") (# K( ! (! 0 $ +0$% !D R"@8"L@ ) M 0 8'K -O<&5R86YD(&X (P D !\ & @ ", (P 2 ", ! (! M 0 $ )P'__P0 " 0$ "@ "8&#P * /____\! $ @$! M 0 " 0$ #@ "8&#P 2 /____\ @ #%# ?P@ 0 " 0$ M P !X !P !8$10+I!?,!3@0$ @$! 0 M 04 '0 #(*]@%. M! P ! !@>L W9A;'5E(&QE;F=T:"( ( 4 ", 'P 2 !0 'P C ", M% C 0 " 0$ ! " < 6!'0!Z04B 4X$! (! 0 $ +0$% !P R"B4! M3@0+ 0 8'K -N86UE(&QE;F=T: C " -@ ? !( % ? ", (P 4 M ", ! (! 0 $ )P'__P0 " 0$ "@ "8&#P * /____\! M . )@8/ !( _____P " H$ "$ 0 ! "T! @ ) ^@( M , "(@ $ +0$& < ;!.L!\@6$ 0H$! "T!! $ M\ $& 0 M 0, ! (! 0 # '@ ' %@3< 6H%B@&4! 0 " M 0$ ! "T!!0 1 ,@J- 90$! $ &!ZP#;F%M92, ( V !\ M! (! 0 $ )P'__P0 " 0$ "@ "8&#P * /____\! $ M +0$" D #Z @ P (B 0 M 08 !P !L$5 +R!>T! M"@0$ +0$$ 0 #P 08 ! "T! P . )@8/ !( _____P " M H$ !6 @ ! "T! @ ) ^@( , "(@ $ +0$& < M ;!+T"\@56 @H$! "T!! $ \ $& 0 M 0, ! (! 0 # M '@ ' %@2N GL%7 *F! 0 " 0$ ! "T!!0 3 ,@I? J8$ M!0 $ &!ZP#=F%L=64 (@ @ !0 (P ? 0 " 0$ ! "71E

L S(@8GET97, ) 2 "0 (@ 4 !\ M' $ @$! 0 G ?__! (! 0 * )@8/ H _____P$ M 0 " 0$ ! (! 0 ) ^@( , "(@ $ +0$& 4 M 4 O < 6!$L#\P;X KP"! (! 0 $ +0$% #L R"OL" MO (@ 0 8'K .%(&ES(&9O < 6!)L#\09) V0"! (! 0 $ +0$% $0 M R"DP#9 (F 0 8'K -T:&4@8VAU;FMS(&9OL S0@8GET97, ) 2 "0 (@ 4 M !\ ' $ @$! 0 G ?__! (! 0 $ +0$" D #Z @ M P (B 0 M 08 !P !L$PP), F0"9 $ +0$$ 0 #P M 08 ! "T! P $ @$! 0 " 0$ ! (! 0 # '@ ' M%@2^ C@"; *! 0 " 0$ ! "T!!0 = ,@IO H$ # $ & M!ZP#8VAU;FL@;&5N9W1H( C ", (P D !( % ? ", (P 4 ", ! (! M 0 $ )P'__P0 " 0$ #@ "8&#P 2 /____\ @ !Z!0 D@P M 0 M 0( "0 /H" # B( ! "T!!@ ' &P1T TP" M/ -D 0 M 00 ! / !!@ $ +0$# 0 " 0$ P !X !P M !8$; .; 1D#*@$$ @$! 0 M 04 $ #(*' ,J 0, ! M!@>L RXN+@ 2 !( $@ $ @$! 0 G ?__! (! 0 * )@8/ M H _____P$ 0 " 0$ ! (! 0 $ @$! , > < M 6!,,"8P-Q E\"! (! 0 $ +0$% !8 R"G0"7P(' 0 M 8'K ,T(&)Y=&5S "0 $@ D "( % ? !P ! (! 0 $ )P'__P0 M M 0 P T,\1X*&Q&N$ /@ # /[_"0 & M ! # $ #P $ #^____ T M #_________________________________________________________ M____________________________________________________________ M_________________________________O\ 0 @ M 0 ."%G_+Y3V@0JY$( "LGL]DP @ $ !( ! F ( M "@ P *P $ N 4 #$ !@ - ' W M @ #P "0 /P 2 " $ H P 0 "P #P! , M2 $ T !4 0 #@ & ! / : $ ! !P 0 $P '@! " M Y 0 !X ! %%* !X ! %A* !X $ 8F]B !X M ! !88AX ! $ !X + 3F]R;6%L+F1O= '@ M 0 !B;V( '@ ( R '@ !X !-:6-R;W-O9G0@5V]R9"!F M;W(@5VEN9&]W0T--"!B>71E$# @X ____ "!"@ M! )O &0&AP$ % /___P#___\ @0H # )F M!(L! @X ____ "!"@ M20$< *X'AP$ % /___P#___\ " $. !76&=P M I/\ &6H N B8)[ $# , )@ )0GK 0 (. /__ M_P @0H )D"' #] XL! @X M____ &6H ;!B8)[ $# , )@ )0GK 0 (. M /___P @0H .T"' #] X!(4$DP'^ _@ !M0>3 M ?X #^ &U!Y,!_@ /X 0,$DP'^ _@ !_@.3 ?X M #^ '@!),!_@ /X >4$DP'^ _@ !.Q23 ?X M #^ $K$I,!_@ /X #^ &R(? M ! I#@ / M @ 0!+ \ !H $#Q_P( &@ &3F]R;6%L ( # &$)! M B $% \O^A "( %D1E9F%U;'0@4&%R86=R87!H($9O M;G0 + $ !L E *P #0 _ M1P %( !W @ (X "; H0 *@ "Q N@ .$ " M 0 !0$ 8 0 #P 8! #_____ 0 $(/__ 0 & $ M # !#"P !@ P & 0 < $ " P 0 % M !@ < ( "0 H + # T . #P ! M 1 $@ !@! O! !?! "/! "_! #O! 0!C M!0 0#7!0 ;!@ !?!@ 0#3!@ 0 %!P 0 W!P 0"K!P M @!'" 0!Y" 0"K" 0#=" !@#?"@ 0 1"P 0 % M !D! ' < _T!L=P!&24Q%.@!04T-225!4 &QW &QW M 0#!)0 N (?9P 0 ! .H*;PAD $ !P L M 0$ 0 L 0, M" & ) #D# 0 ! @ #, M+LK3$>B93)6A!0 ! $ $ ( @ ! %@" #" 0 M9 #__P __\ /__ #__P __\ /__ #__P __\ M M M M M M M M M /__0W5S=&]M('!A9V4@,0 M D$( )!" 0W5S=&]M('!A M9V4@,@ M D$( )!" 0W5S=&]M('!A9V4@,P M MD$( )!" !L=P M $ P24 +@"'V< $ 0#J"F\(9 ! < + $! $ + $# M @ !@"0 Y P M $ 0 ( S"[*TQ'HF4R5H04 M 0 ! ! " ( 0!8 @ P@$ &0 __\ M /__ #__P __\ /__ #__P __\ /__ M M M M M M M M #__T-U"AL1KA M #X P#^_PD !@ 0 P ! \ ! M_O___P - ____________________________________________ M____________________________________________________________ M_________________________________________________V1$;V, #P M %=O < 6!%T %P(* 8!! (! 0 5 ^P*Y_P M ) ! 0 !)4:6UEL T]P97)A M=&EO;@ S "0 'P 8 " % 4 ", (P $ @$! 0 G ?__! (! M 0 $ @$! , > < 6!"H!]@'8 H!! (! 0 $ +0$% M !0 R"ML "@$& 0 8'K -L96YG=&@4 !\ (P C !0 (P $ M @$! 0 G ?__! (! 0 * )@8/ H _____P$ 0 " M 0$ ! (! 0 $ +0$" D #Z @ P (B 0 M 08 M!P !L$O0%3 C\!:@ $ +0$$ 0 #P 08 ! "T! P $ @$! M 0 " 0$ ! (! 0 # '@ ' %@2H 4 "5@'2 0 " 0$ M! "T!!0 9 ,@I9 =( "0 $ &!ZP#3W!E < 6!#\#2 +M N, ! (! 0 $ +0$% !< R"O "XP ( M 0 8'K -$;V-U;65N=#, (P @ ", -@ ? ", % $ @$! 0 M G ?__! (! 0 $ @$! , > < 6!),#[P% S,!! M (! 0 $ +0$% !$ R"D,#,P$$ 0 8'K -$871A,P @ !0 M( $ @$! 0 G ?__! (! 0 $ @$! , > < 6 M!%T R 8* (<"! (! 0 $ +0$% $ R"@T AP(C 0 8' MK ,R(&)Y=&5S+"!M86IO0 D !( ) B M !0 'P < !( $@ V " % C !@ % V !0 (P C !@ $@ D ", % C !( M% C !( ) 4 ", ( 8 "( ! (! 0 $ )P'__P0 " 0$ ! M (! 0 # '@ ' %@3H (P#E@"' @0 " 0$ ! "T!!0 6 M,@J9 (<"!P $ &!ZP#-"!B>71E

< 6!%P"H@$* C !! (! M 0 $ +0$% ! R"@T", $# 0 8'K ,N+BX $@ 2 !( ! M (! 0 $ )P'__P0 " 0$ "@ "8&#P * /____\! $ M @$! 0 " 0$ #@ "8&#P 2 /____\ @ "&!0 *0L 0 M M 0( "0 /H" # B( ! "T!!@ ' &P37 E,"90)J 0 M M 00 ! / !!@ $ +0$# 0 " 0$ P !X !P !8$Q@(G M G0"M@ $ @$! 0 M 04 &0 #(*=P*V D ! !@>L T]P M97)A;F0@;@ S "0 'P 8 " (P C !( (P $ @$! 0 G ?__! M (! 0 * )@8/ H _____P$ 0 " 0$ ! (! 0 . M)@8/ !( _____P " ,4, !_" ! (! 0 # '@ ' %@1% M ND%\P%.! 0 " 0$ ! "T!!0 = ,@KV 4X$# $ &!ZP# M=F%L=64@;&5N9W1H(@ @ !0 (P ? !( % ? ", (P 4 ", ! (! 0 $ M )P'__P0 " 0$ #@ "8&#P 2 /____\ @ *! ' $ 0 M M 0( "0 /H" # B( ! "T!!@ ' &P2# ?(%' $* M! 0 M 00 ! / !!@ $ +0$# 0 " 0$ P !X !P !8$ M= 'I!2(!3@0$ @$! 0 M 04 ' #(*)0%.! L ! !@>L M VYA;64@;&5N9W1H ", ( V !\ $@ 4 !\ (P C !0 (P $ @$! 0 M G ?__! (! 0 * )@8/ H _____P$ X F!@\ $@#_ M____ ( "@0 (0! $ +0$" D #Z @ P (B 0 M M 08 !P !L$ZP'R!80!"@0$ +0$$ 0 #P 08 ! "T! P $ M @$! , > < 6!-P!:@6* 90$! (! 0 $ +0$% !$ M R"HT!E 0$ 0 8'K -N86UE(P @ #8 'P $ @$! 0 G M ?__! (! 0 * )@8/ H _____P$ 0 M 0( "0 /H" M # B( ! "T!!@ ' &P14 O(%[0$*! 0 M 00 ! M / !!@ $ +0$# X F!@\ $@#_____ ( "@0 %8" $ M+0$" D #Z @ P (B 0 M 08 !P !L$O0+R!58""@0$ M +0$$ 0 #P 08 ! "T! P $ @$! , > < 6!*X" M>P5< J8$! (! 0 $ +0$% !, R"E\"I@0% 0 8'K -V M86QU90 B " % C !\ ! (! 0 $ )P'__P0 " 0$ "@ "8& M#P * /____\! $ @$! , > < 6!&(!*P<0 2<&! M (! 0 $ +0$% !8 R"A,!)P8' 0 8'K ,R(&)Y=&5S "0 M$@ D "( % ? !P ! (! 0 $ )P'__P0 " 0$ ! (! 0 # M '@ ' %@1% AH'\P$5!@0 " 0$ ! "T!!0 6 ,@KV 14& M!P $ &!ZP#,B!B>71E

L M TYO=&4Z(&%L;"!L96YG=&AS(&%R92!B:6YA < 6!)X#A09, [P"! (! 0 $ +0$% M #H R"D\#O (? 0 8'K -S<&5C:69Y:6YG('1H92!N=6UB97(@ M;V8@;V-T971S !P ) ? " % 8 "( % C ", $@ 4 ", 'P 2 ", (P V M "0 'P 8 !( (P 8 !( (P @ !0 'P 4 !P ! (! 0 $ )P'__P0 M " 0$ #@ "8&#P 2 /____\ @ "&!0 UPD 0 M 0( "0 M /H" # B( ! "T!!@ ' &P0N E,"O %J 0 M 00 M! / !!@ $ +0$# 0 " 0$ P !X !P !8$'0(G LL!M@ $ M @$! 0 M 04 &0 #(*S@&V D ! !@>L T]P97)A;F0@ M,0 S "0 'P 8 " (P C !( ) $ @$! 0 G ?__! (! 0 * M )@8/ H _____P$ 0 " 0$ ! "T! # H-#/ M$>"AL1KA #X P#^_PD !@ 0 M P ! \ ! _O___P - ________________ M____________________________________________________________ M____________________________________ #,& ,P8 MS!@ "J& (@ !X8 JA@ >& *H8 M ^!@ (#+>)1<>+P!,A@ !0 !&& (@ !X8 M 'A@ >& !X8 JA@ #X& M ,P8 L S!@ M M T-24Y415).150M1%)!1E0-#4A45% @,2XQ(%1R86YS M<&]R="!-87!P:6YG(&9O2!W2!V97)S:6]N('1H870@=V4@:&%D('!R979I;W5S;'D@86=R965D('1O M+B @22!E>'!E8W1E9"!T:&4@;VQD('9E7,I+@UO M<&5R871I;VXM96YC;V1I;F<@/2 @;W!E# P+BXE>#=&(" @.R!M86IO2P@:6YI=&EA;&QY(#$-;W!E# P+BXE>#=&(" [(&UI;F]R('9E# P+C P M+C P+C P("XN("5X-V8N9F8N9F8N9F8@(#L@;G5M8F5R(&]F(&]C=&5T# P+C P+BXE>#=F M+F9F.R!N=6UB97(@;V8@;V-T971S(&]F('1H92!N86UE(&EN(&)I;F%R>2 - M=F%L=64@/2!/0U1%5"U35%))3D<-;W!E"!I=&5M2!B#=F+F9F+F9F+F9F(#L@=')A;G-A8W1I;VX@:60@:6X@8FEN87)Y M#71R86YS<&]R="UO<&5R86YD0UT P G @ )T( "T" M0@ +8( "W" M T +4- #,#0 S0T M ,X- #/#0 U@T /D- _0#X /#J^ #X .+<^ #: M M M M M M M M )U 0 *=0%$!(X#3#=+ 0 /=0%$ M!(X#3#=A 1V 4L!"G4!1 3:_DLW2P$ #W4!1 3:_DLW80 $=@%+ 0AU 40$ M- < #8QP ! P 0, (# 1 P $@, % # !> P 7P, $H$ M !Y! >@0 (L$ ":! K 0 ,$$ #"! $P4 &@% "I!0 [04 M #L& "(!@ MP8 !D' !*!P > < ,$' #P!P .0@ $X( !L" M;0@ )H( ";" G @ +@( "Y" N@@ +L( "1"0 ? H - * 4 M"P 7PL /X < A&P'\ ' (? ^@ !P"%+ ?P < A2P'Z ' (4L!]0 ! MP"%+ ?P < A\ #\ / (? ^@ !P"'P /H < A\ #S ' (? \P !P"'P M /, < A\ #S ' (? ^@ !P"'P /P < A\ #\ ' (? \P !P"'P /, M < A\ #S ' (? \P !P"'P /, < A\ #S ' (? \P !P"'P /, < A M\ #S ' (? \P !P"'P /, < A\ #S ' (? \P !P"'P /, < A\ #\ M ' (? _ !P"'P /P < A\ #\ ' (: 1_ !P"'P /P < A\ #\ ' M(? _ #P"'P /P \ A\ #S ' (? \P !P"'P /, < A\ M !$0 !! $: %$] " $ !$ 0, *U\+ "J"P ZPL !@, !W M# Q0P /P, !=#0 >PT 'P- !]#0 LPT +0- #0#0 T0T -(- M #3#0 U T -4- #6#0 _@ !P"'P /X < A\ #^ ' (? _@ !P"'P M /X < A\ #^ ' (? _@ !P"'P /X < A\ #^ ' (? _ !P"'P /P M < A\ #\ ' (? _ !P"&@$?P < A\ #\ ' (? _ !P"'P /P < A M\ #\ ' (? _ !P"'P M M M M M M $0 !$0 3 end ---------- X-Sun-Data-Type: default-app X-Sun-Data-Description: default X-Sun-Data-Name: ipp-pro-061397-rgh.txt X-Sun-Charset: us-ascii X-Sun-Content-Lines: 62 INTERNET-DRAFT HTTP 1.1 Transport Mapping for the Internet Printing Protocol Missing parts When Randy wrote the protocol document, he changed to syntax from the binary version that we had previously agreed to. I expected the old version to be in the document as an alternate solution, but it is not. I am including it here. The following protocol primitives are defined: DIGIT = "0".."9" ALPHA = "A..Z" BYTE = %d0..%d255 OCTET-STRING = *BYTE The following ABNF specification describes the encoding of an IPP message (PDU): (We may want to state that string values are case sensitive, unlike what ABNF says). operation-encoding = operation-version operation operation-data operation-version = operation-major-version operation-minor-version operation-major-version = %x00..%x7F ; major version in binary, initially 1 operation-minor-version = %x00..%x7F ; minor version in binary, initially 0 operation = operation-length operator *operand operation-length = %x00.00.00.00 .. %x7f.ff.ff.ff ; number of octets for the operation in binary operator = %d0.9 "operation" value-length value operand = name-length name value-length value name-length = %x00.00..%x7f.ff ; number of octets of the name in binary name = = ALPHA *( ALPHA / DIGIT / "_" / "-" ) value-length = %x00.00..%x7f.ff; number of octets of the name in binary value = OCTET-STRING operation-data = OCTET-STRING The following is a picture of this encoding: The transport encoding in Randy's Appendix A references syntax items that aren't in his document. Here is the new version of the transport encoding for raw TCP/IP that reference items in the operation-encoding. The idea behind this is that the transport encoding does the work of HTTP. It encodes HTTP header information in the transport-operands. It encodes the application/ipp entity body in the transport-operation by breaking it into chunks. transport-encoding = transport-version XID transport-operands transport-operation transport-version = transport-major-version transport-minor-version transport-major-version = %x00..%x7F; major version in binary, initially 1 transport-minor-version = %x00..%x7F; minor version in binary, initially 0 XID = %x00.00.00.00 .. %x7f.ff.ff.ff ; transaction id in binary transport-operands = operand-length *operand operand-length = %x00.00.00.00 .. %x7f.ff.ff.ff ; number of octets for the operands in binary transport-operation = 1*transport-chunk ; the chunked operation-encoding data transport-chunk = transport-data-length transport-data transport-data-length = %x00.00.00.00 .. %x7f.ff.ff.ff ; number of octets of the data in binary transport-data = OCTET-STRING The following is a picture of the transport encoding: From ipp-archive Mon Jun 16 17:54:05 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA03607 for ipp-outgoing; Mon, 16 Jun 1997 17:49:22 -0400 (EDT) Date: Mon, 16 Jun 1997 17:49:40 -0400 (EDT) From: JK Martin Message-Id: <199706162149.RAA18385@uscore.underscore.com> To: ipp@pwg.org Subject: Re: IPP>PRO Enclosed: Update to Randy's document X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Perhaps when Bob first tried to upload his document the PWG ftp server was down. This is no longer the case, and hopefully Bob will have a chance to upload his document. Since Bob's document is so small, and since folks should want to see this asap, I have attached the text form of the document below. It's not terribly readable in this form (Bob also has a Word .doc file available), but it should give some folks an idea of what's going on. I've done just a touch of reformatting so some mail agents won't complain, etc. ...jay ----- Begin Included Message ----- >From ipp-owner@pwg.org Mon Jun 16 15:17 EDT 1997 Date: Mon, 16 Jun 1997 12:11:17 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) To: ipp@pwg.org Subject: IPP>PRO Enclosed: Update to Randy's document Because the pwg server is down today, I have enclosed the MS Word and text version of the files that I downloaded on Friday. This document will be part of tomorrow's discussions. Bob Herriot ----- End Included Message ----- ------------------------------------------------------------------------------ INTERNET-DRAFT HTTP 1.1 Transport Mapping for the Internet Printing Protocol Missing parts When Randy wrote the protocol document, he changed to syntax from the binary version that we had previously agreed to. I expected the old version to be in the document as an alternate solution, but it is not. I am including it here. The following protocol primitives are defined: DIGIT = "0".."9" ALPHA = "A..Z" BYTE = %d0..%d255 OCTET-STRING = *BYTE The following ABNF specification describes the encoding of an IPP message (PDU): (We may want to state that string values are case sensitive, unlike what ABNF says). operation-encoding = operation-version operation operation-data operation-version = operation-major-version operation-minor-version operation-major-version = %x00..%x7F ; major version in binary, initially 1 operation-minor-version = %x00..%x7F ; minor version in binary, initially 0 operation = operation-length operator *operand operation-length = %x00.00.00.00 .. %x7f.ff.ff.ff ; number of octets for the operation in binary operator = %d0.9 "operation" value-length value operand = name-length name value-length value name-length = %x00.00..%x7f.ff ; number of octets of the name in binary name = = ALPHA *( ALPHA / DIGIT / "_" / "-" ) value-length = %x00.00..%x7f.ff; number of octets of the name in binary value = OCTET-STRING operation-data = OCTET-STRING The following is a picture of this encoding: [Diagram not available in the text version] The transport encoding in Randy's Appendix A references syntax items that aren't in his document. Here is the new version of the transport encoding for raw TCP/IP that reference items in the operation-encoding. The idea behind this is that the transport encoding does the work of HTTP. It encodes HTTP header information in the transport-operands. It encodes the application/ipp entity body in the transport-operation by breaking it into chunks. transport-encoding = transport-version XID transport-operands transport-operation transport-version = transport-major-version transport-minor-version transport-major-version = %x00..%x7F; major version in binary, initially 1 transport-minor-version = %x00..%x7F; minor version in binary, initially 0 XID = %x00.00.00.00 .. %x7f.ff.ff.ff ; transaction id in binary transport-operands = operand-length *operand operand-length = %x00.00.00.00 .. %x7f.ff.ff.ff ; number of octets for the operands in binary transport-operation = 1*transport-chunk ; the chunked operation-encoding data transport-chunk = transport-data-length transport-data transport-data-length = %x00.00.00.00 .. %x7f.ff.ff.ff ; number of octets of the data in binary transport-data = OCTET-STRING The following is a picture of the transport encoding: [Diagram not available in the text version] From ipp-archive Mon Jun 16 19:34:06 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA04380 for ipp-outgoing; Mon, 16 Jun 1997 19:32:28 -0400 (EDT) Message-Id: <9706162332.AA06344@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, 16 Jun 1997 16:30:16 PDT To: jmp@pwg.org, ipp@pwg.org From: Tom Hastings Subject: IPP> Comparison of JMP and IPP and some issues for each Sender: ipp-owner@pwg.org Precedence: bulk I added the mapping of the IPP subsubmissionn protocol to the JMP Job Monitoring MIB as an assignment and did that one first. I've posted the comparison of the JMP Job Monitoring MIB (6/9/97, V0.82) with IPP 6/3/97 at: ftp://ftp.pwg.org/pub/pwg/jmp/protomap/ -rw-r--r-- 1 pwg pwg 28160 Jun 16 23:28 ietf-ipp.doc -rw-r--r-- 1 pwg pwg 37229 Jun 16 23:24 ietf-ipp.pdf There are several issues, some for IPP and some for JMP. They are indicated in the NOTES column of the comparison. I've also included them in the e-mail message. The first column in the JMP object or attribute, the second column in the page number in the JMP V0.82 jmp-mibv.pdf, the third column is the IPP attribute and the fourth column is the issue. 1. jmGeneralNumberOfActiveJobs 57 queued-job-count IPP ISSUE: Should/does "queued-job-count" include pendingHeld or not? I suggest that, like JMP, the attribute NOT include jobs in the 'pending-held' state, since they are unlikely to be processed soon. The purpose of the attribute should be to show how busy the Printer is, not how may jobs are queued. In fact a Printer that is processing a job should have a different count than a Printer that is idle. So lets rename the IPP attribute to agree with JMP: "number-of-active-jobs" and define it to include jobs in the 'pending', 'processing', and 'processing-stopped' states (but not in the 'pending-held', 'canceled', 'aborted', and 'completed' states). 2. jmJobSetIndex 61 job-URI? The JMP agent MAY need to convert from a URI to a jmJobSetIndex. JMP ISSUE: should we add a jobIdentifier attribute to the attribute table that is the job submissio procotol format for a job identifer assigned by the server or device that accepts jobs? I suggest yes. 3. numberOfDocuments 39 IPP ISSUE: should have read-only "number-of-documents" set by Printer. 4. fileName 39 document-URI JMP ISSUE: clarify that the fileName attribute could be a URI 5. There are three JMP attributes that have enums for which IPP has keywords. While the mapping is one-to-one, should we also allow the JMP agent to return the Octets text representation? The three attributes are: finishing 41 finishings same values, but map IPP keywords to JMP enums. Both can be MULTI-VALUED JMP ISSUE: also allow Octets as supplement? printQualityRequested 42 print-quality same values, but map IPP keywords to JMP enums JMP ISSUE: also allow Octets as supplement? printerResolutionRequested 42 printer-resolution same values, but map IPP keywords to JMP enums JMP ISSUE: also allow Octets as supplement? I suggest yes. Also allow just the octets when the enum isn't known to the agent. 6. timeSinceJobWasSubmittedToDevice 47 time-since-submission JMP ISSUE: Should timeSinceJobWasSubmittedToDevice be seconds or like IPP milliseconds? I suggest we use milliseconds, like IPP From ipp-archive Mon Jun 16 20:09:06 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA05146 for ipp-outgoing; Mon, 16 Jun 1997 20:04:17 -0400 (EDT) Message-Id: <9706170004.AA06363@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, 16 Jun 1997 17:02:06 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD/PRO - What are MIME types for IPP document-format attribute? Sender: ipp-owner@pwg.org Precedence: bulk I went to IANA to see what MIME types are registered, since IPP Model and Protocol are considering using the "MIME types", instead of the Printer MIB assigned enums for the values of the document-format attribute. I'd like to discuss this tommorrow at the IPP Protocol meeting. What I found was the following under "Media Types": The "media-types" directory contains a subdirectory for each content type and each of those directories contains a file for each content subtype. |-application- |-audio------- |-image------- |-media-types-|-message----- |-model------- |-multipart--- |-text-------- |-video------- URL = ftp://ftp.isi.edu/in-notes/iana/assignments/media-types The three registered media types that seem of interest to IPP that have some corresondence to the Printer MIB enum registry (also kept by IANA as printer-languages) are: application/postscript application/vnd.hp-PCL application/pdf Even though pdf doesn't have an IANA printer-language enum assignment (no Printer MIB PrtInterpreterLangFamilyTC). So I went to each of the sub-directories for the 3 above to find out about them: application/postscript had the following: See RFC 1341. application/vnd.hp-PCL had the following: >From bpenteco@boi.hp.com Fri Feb 28 09:09:03 1997 To: "'IANA@isi.edu'" Subject: Registration of new MIME content-type/subtype Date: Fri, 28 Feb 1997 16:09:03 -0700 MIME type name: application MIME subtype name: vnd.hp-PCL Required parameters: none Optional parameters: none Encoding considerations: PCL files may contain long lines or binary data such as images and should be encoded using Content-Transfer-Encoding: binary. Security considerations: Delivery of this format to a printer which is not capable of parsing the format may result in poor printer behavior. Published specification: PCL-PJL Technical Reference Manual Documentation Package HP Part No. 5012-0330 Company Contact: Customer Service Center Hewlett-Packard Co. (208)323-2551 application/pdf had the following: To: postel@ISI.EDU Cc: szilles@mv.us.adobe.com Subject: Registration of MIME type: application/pdf Date: Tue, 06 Sep 1994 15:56:11 PDT From: "Steve Zilles" To: IANA@isi.edu Subject: Registration of new MIME content-type/subtype MIME type name: application (If the above is not an existing top-level MIME type, please explain why an existing type cannot be used.) MIME subtype name: pdf A Content-Type of "application/pdf" indicates a document in Portable Document Format. Currently there are two variants of the PDF language: the original level 1 variant is described in [PDF] and the more recent level 1.1 variant is described in an Adobe Systems Application Note that is an addendum to [PDF]. Required parameters: none Optional parameters: none Encoding considerations: PDF files may contain binary data (either in strings or in streams (which are used to represent images among other things). Security considerations: There are two levels of viewer for PDF files: The first level of viewer is completely self contained and is capable of displaying or printing the PDF file and maybe capable of changing the file and writing out a revised file. (Here "file" stands for the MIME content portion that is in PDF form.) The second level of viewer is capable of supporting plug-in modules that extend the functionality of the viewer and may be able to perform any operation that is legal in the process/thread in which the viewer is running. Message-sending software should not make use of arbitrary plug-ins; they are likely to be missing from some implementations. Message-receiving and -displaying software should make sure that any nonstandard viewer plug-ins are secure and don't present any kind of threat. Published specification: [PDF](Version 1.0): Portable Document Format Reference Manual, Adobe Systems, Inc, Addison-Wesley Publishing Co. ISBN 0-201-62628-4, 1993. Version 1.1: An Adobe Systems, Inc Technical Note (The published specification must be an Internet RFC or RFC-to-be if a new top-level type is being defined, and must be a publicly available specification in any case.) Person & email address to contact for further information: Tim Bienz Adobe System Inc. 1585 Charleston Rd. Mountain View, CA 94039-7900 USA tbienz@adobe.com or Stephen Zilles Adobe System Inc. 1585 Charleston Rd. Mountain View, CA 94039-7900 USA szilles@adobe.com [] Here is the file media-types which is all of the media types: MEDIA TYPES [RFC1521] specifies that Content Types, Content Subtypes, Character Sets, Access Types, and Conversion values for MIME mail will be assigned and listed by the IANA. Content Types and Subtypes -------------------------- Type Subtype Description Reference ---- ------- ----------- --------- text plain [RFC1521,Borenstein] richtext [RFC1521,Borenstein] enriched [RFC1896] tab-separated-values [Paul Lindner] html [RFC1866] sgml [RFC1874] vnd.latex-z [Lubos] vnd.fmi.flexstor [Hurtta] multipart mixed [RFC1521,Borenstein] alternative [RFC1521,Borenstein] digest [RFC1521,Borenstein] parallel [RFC1521,Borenstein] appledouble [MacMime,Patrik Faltstrom] header-set [Dave Crocker] form-data [RFC1867] related [RFC2112] report [RFC1892] voice-message [RFC1911] signed [RFC1847] encrypted [RFC1847] byteranges [RFC2068] message rfc822 [RFC1521,Borenstein] partial [RFC1521,Borenstein] external-body [RFC1521,Borenstein] news [RFC 1036, Henry Spencer] http [RFC2068] application octet-stream [RFC1521,Borenstein] postscript [RFC1521,Borenstein] oda [RFC1521,Borenstein] atomicmail [atomicmail,Borenstein] andrew-inset [andrew-inset,Borenstein] slate [slate,terry crowley] wita [Wang Info Transfer,Larry Campbell] dec-dx [Digital Doc Trans, Larry Campbell] dca-rft [IBM Doc Content Arch, Larry Campbell] activemessage [Ehud Shapiro] rtf [Paul Lindner] applefile [MacMime,Patrik Faltstrom] mac-binhex40 [MacMime,Patrik Faltstrom] news-message-id [RFC1036, Henry Spencer] news-transmission [RFC1036, Henry Spencer] wordperfect5.1 [Paul Lindner] pdf [Paul Lindner] zip [Paul Lindner] macwriteii [Paul Lindner] msword [Paul Lindner] remote-printing [RFC1486,Rose] mathematica [Van Nostern] cybercash [Eastlake] commonground [Glazer] iges [Parks] riscos [Smith] eshop [Katz] x400-bp [RFC1494] sgml [RFC1874] cals-1840 [RFC1895] pgp-encrypted [RFC2015] pgp-signature [RFC2015] pgp-keys [RFC2015] vnd.framemaker [Wexler] vnd.mif [Wexler] vnd.ms-excel [Gill] vnd.ms-powerpoint [Gill] vnd.ms-project [Gill] vnd.ms-works [Gill] vnd.ms-tnef [Gill] vnd.svd [Becker] vnd.music-niff [Butler] vnd.ms-artgalry [Slawson] vnd.truedoc [Chase] vnd.koan [Cole] vnd.street-stream [Levitt] vnd.fdf [Zilles] set-payment-initiation [Korver] set-payment [Korver] set-registration-initiation [Korver] set-registration [Korver] vnd.seemail [Webb] vnd.businessobjects [Imoucha] vnd.meridian-slingshot [Wedel] vnd.xara [Matthewman] sgml-open-catalog [Grosso] vnd.rapid [Szekely] vnd.enliven [Santinelli] vnd.japannet-registration-wakeup [Fujii] vnd.japannet-verification-wakeup [Fujii] vnd.japannet-payment-wakeup [Fujii] vnd.japannet-directory-service [Fujii] vnd.intertrust.digibox [Tomasello] vnd.intertrust.nncp [Tomasello] prs.alvestrand.titrax-sheet [Alvestrand] vnd.noblenet-web [Solomon] vnd.noblenet-sealer [Solomon] vnd.noblenet-directory [Solomon] prs.nprend [Doggett] vnd.webturbo [Rehem] hyperstudio [Domino] vnd.shana.informed.formtemplate [Selzler] vnd.shana.informed.formdata [Selzler] vnd.shana.informed.package [Selzler] vnd.shana.informed.interchange [Selzler] vnd.$commerce_battelle [Applebaum] vnd.osa.netdeploy [Klos] vnd.ibm.MiniPay [Herzberg] vnd.japannet-jpnstore-wakeup [Yoshitake] vnd.japannet-setstore-wakeup [Yoshitake] vnd.japannet-verification [Yoshitake] vnd.japannet-registration [Yoshitake] vnd.hp-HPGL [Pentecost] vnd.hp-PCL [Pentecost] vnd.hp-PCLXL [Pentecost] vnd.musician [Adams] vnd.FloGraphIt [Floersch] vnd.intercon.formnet [Gurak] vemmi [RFC2122] vnd.ms-asf [Fleischman] vnd.ecdis-update [Buettgenbach] vnd.powerbuilder6 [Guy] vnd.powerbuilder6-s [Guy] vnd.lotus-wordpro [Wattenberger] vnd.lotus-approach [Wattenberger] vnd.lotus-1-2-3 [Wattenberger] vnd.lotus-organizer [Wattenberger] vnd.lotus-screencam [Wattenberger] vnd.lotus-freelance [Wattenberger] vnd.fujitsu.oasys [Togashi] vnd.fujitsu.oasys2 [Togashi] vnd.swiftview-ics [Widener] image jpeg [RFC1521,Borenstein] gif [RFC1521,Borenstein] ief Image Exchange Format [RFC1314] g3fax [RFC1494] tiff Tag Image File Format [Rose] cgm Computer Graphics Metafile [Francis] naplps [Ferber] vnd.dwg [Moline] vnd.svf [Moline] vnd.dxf [Moline] png [Randers-Pehrson] vnd.fpx [Spencer] vnd.net-fpx [Spencer] audio basic [RFC1521,Borenstein] 32kadpcm [RFC1911] vnd.qcelp [Lundblade] video mpeg [RFC1521,Borenstein] quicktime [Paul Lindner] vnd.vivo [Wolfe] vnd.motorola.video [McGinty] vnd.motorola.videop [McGinty] model [RFC2077] iges [Parks] vrml [RFC2077] mesh [RFC2077] The "media-types" directory contains a subdirectory for each content type and each of those directories contains a file for each content subtype. |-application- |-audio------- |-image------- |-media-types-|-message----- |-model------- |-multipart--- |-text-------- |-video------- URL = ftp://ftp.isi.edu/in-notes/iana/assignments/media-types Character Sets -------------- All of the character sets listed the section on Character Sets are registered for use with MIME as MIME Character Sets. The correspondance between the few character sets listed in the MIME specification [RFC1521] and the list in that section are: Type Description Reference ---- ----------- --------- US-ASCII see ANSI_X3.4-1968 below [RFC1521,Borenstein] ISO-8859-1 see ISO_8859-1:1987 below [RFC1521,Borenstein] ISO-8859-2 see ISO_8859-2:1987 below [RFC1521,Borenstein] ISO-8859-3 see ISO_8859-3:1988 below [RFC1521,Borenstein] ISO-8859-4 see ISO_8859-4:1988 below [RFC1521,Borenstein] ISO-8859-5 see ISO_8859-5:1988 below [RFC1521,Borenstein] ISO-8859-6 see ISO_8859-6:1987 below [RFC1521,Borenstein] ISO-8859-7 see ISO_8859-7:1987 below [RFC1521,Borenstein] ISO-8859-8 see ISO_8859-8:1988 below [RFC1521,Borenstein] ISO-8859-9 see ISO_8859-9:1989 below [RFC1521,Borenstein] Access Types ------------ Type Description Reference ---- ----------- --------- FTP [RFC1521,Borenstein] ANON-FTP [RFC1521,Borenstein] TFTP [RFC1521,Borenstein] AFS [RFC1521,Borenstein] LOCAL-FILE [RFC1521,Borenstein] MAIL-SERVER [RFC1521,Borenstein] content-id [RFC1873] Conversion Values ----------------- Conversion values or Content Transfer Encodings. Type Description Reference ---- ----------- --------- 7BIT [RFC1521,Borenstein] 8BIT [RFC1521,Borenstein] BASE64 [RFC1521,Borenstein] BINARY [RFC1521,Borenstein] QUOTED-PRINTABLE [RFC1521,Borenstein] MIME / X.400 MAPPING TABLES MIME to X.400 Table MIME content-type X.400 Body Part Reference ----------------- ------------------ --------- text/plain charset=us-ascii ia5-text [RFC1494] charset=iso-8859-x EBP - GeneralText [RFC1494] text/richtext no mapping defined [RFC1494] application/oda EBP - ODA [RFC1494] application/octet-stream bilaterally-defined [RFC1494] application/postscript EBP - mime-postscript-body [RFC1494] image/g3fax g3-facsimile [RFC1494] image/jpeg EBP - mime-jpeg-body [RFC1494] image/gif EBP - mime-gif-body [RFC1494] audio/basic no mapping defined [RFC1494] video/mpeg no mapping defined [RFC1494] Abbreviation: EBP - Extended Body Part X.400 to MIME Table Basic Body Parts X.400 Basic Body Part MIME content-type Reference --------------------- -------------------- --------- ia5-text text/plain;charset=us-ascii [RFC1494] voice No Mapping Defined [RFC1494] g3-facsimile image/g3fax [RFC1494] g4-class1 no mapping defined [RFC1494] teletex no mapping defined [RFC1494] videotex no mapping defined [RFC1494] encrypted no mapping defined [RFC1494] bilaterally-defined application/octet-stream [RFC1494] nationally-defined no mapping defined [RFC1494] externally-defined See Extended Body Parts [RFC1494] X.400 Extended Body Part MIME content-type Reference ------------------------- -------------------- --------- GeneralText text/plain;charset=iso-8859-x[RFC1494] ODA application/oda [RFC1494] mime-postscript-body application/postscript [RFC1494] mime-jpeg-body image/jpeg [RFC1494] mime-gif-body image/gif [RFC1494] REFERENCES [MacMime] Work in Progress. [RFC1036] Horton, M., and R. Adams, "Standard for Interchange of USENET Messages", RFC 1036, AT&T Bell Laboratories, Center for Seismic Studies, December 1987. [RFC1494] Alvestrand, H., and S. Thompson, "Equivalences between 1988 X.400 and RFC-822 Message Bodies", RFC 1494, SINTEF DELAB, Soft*Switch, Inc., August 1993. [RFC1521] Borenstien, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September 1993. [RFC1563] Borenstien, N., "The text/enriched MIME content-type". RFC 1563, Bellcore, January 1994. [RFC1866] Berners-Lee, T., and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, MIT/W3C, November 1995. [RFC1867] Nebel, E., L. Masinter, "Form-based File Upload in HTML", RFC 1867, Xerox Corporation, November 1995. [RFC1873] Levinson, E., "Message/External-Body Content-ID Access Type", RFC 1873, Accurate Information Systems, Inc. December 1995. [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, Accurate Information Systems, Inc. December 1995. [RFC1895] Levinson, E., "The Application/CALS-1840 Content Type", RFC 1895, Accurate Information Systems, February 1996. [RFC1896] Resnick, P., and A. Walker, "The Text/Enriched MIME Content Type", RFC 1896, Qualcomm, Intercon, February 1996. [RFC1911] Vaudreuil, G., "Voice Profile for Internet Mail", RFC 1911, Octel Network Services, February 1996. [RFC1945] Berners-Lee, Y., R. Feilding, and H.Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945. MIT/LCS, UC Irvine, MIT/LCS, May 1996. [RFC2077] Nelson, S., C. Parks, and Mitra, "The Model Primary Content Type for Multipurpose Internet Mail Extensions", RFC 2077, LLNL, NIST, WorldMaker, January 1997. [RFC2112] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2112, XIson Inc, February 1997. [RFC2122] Mavrakis, D., Layec, H., and K. Kartmann, "VEMMI URL Specification", RFC 2122, Monaco Telematique MC-TEL, ETSI, Telecommunication+Multimedia, March 1997. PEOPLE [Adams] Greg Adams , March 1997. [Alvestrand] Harald T. Alvestrand , January 1997. [Applebaum] David Applebaum , February 1997. [Becker] Scott Becker, , April 1996. [Berners-Lee] Tim Berners-Lee, , May 1996. [Borenstein] Nathaniel Borenstein, , April 1994. [Buettgenbach] Gert Buettgenbach, , May 1997. [Butler] Tim Butler, , April 1996. [Larry Campbell] [Chase] Brad Chase, , May 1996. [Cole] Pete Cole, , June 1996. [Dave Crocker] Dave Crocker [Terry Crowley] [Doggett] Jay Doggett, , February 1997. [Domino] Michael Domino, , February 1997. [Eastlake] Donald E. Eastlake 3rd, dee@cybercash.com, April 1995. [Faltstrom] Patrik Faltstrom [Fleischman] Eric Fleischman , April 1997. [Floersch] Dick Floersch , March 1997. [Francis] Alan Francis, A.H.Francis@open.ac.uk, December 1995. [Fujii] Kiyofusa Fujii , February 1997. [Gill] Sukvinder S. Gill, , April 1996. [Glazer] David Glazer, , April 1995. [Gurak] Tom Gurak, , March 1997. [Guy] David Guy, , June 1997. [Herzberg] Amir Herzberg, , February 1997. [Hurtta] Kari E. Hurtta [Imoucha] Philippe Imoucha , October 1996. [Katz] Steve Katz, , June 1995. [Klos] Steven Klos, , February 1997. [Korver] Brian Korver , October 1996. [Levitt] Glenn Levitt , October 1996. [Lubos] Mikusiak Lubos , October 1996. [Lundblade] Laurence Lundblade , October 1996. [Matthewman] David Matthewman , October 1996. [McGinty] Tom McGinty [Moline] Jodi Moline, , Aprol 1996. [Paul Lindner] [Parks] Curtis Parks, , April 1995. [Pentecost] Bob Pentecost, , March 1997. [Randers-Pehrson] Glenn Randers-Pehrson , October 1996. [Rehem] Yaser Rehem, , February 1997. [Rose] Marshall Rose, , April 1995. [Santinelli] Paul Santinelli, Jr. , October 1996. [Shapiro] Ehud Shapiro [Slawson] Dean Slawson, , May 1996. [Smith] Nick Smith, , June 1995. [Solomon] Monty Solomon, , February 1997. [Spencer] Marc Douglas Spencer , October 1996. [Henry Spencer] [Szekely] Etay Szekely , October 1996. [Togashi] Nobukazu Togashi , June 1997. [Tomasello] Luke Tomasello [Wattenberger] Paul Wattenberger , June 1997. [Webb] Steve Webb , October 1996. [Wedel] Eric Wedel , October 1996. [Wexler] Mike Wexler, , April 1996. [Widener] Glenn Widener , June 1997. [Wolfe] John Wolfe, , April 1996. [Van Nostern] Gene C. Van Nostern , February 1995. [Yoshitake] Jun Yoshitake, , February 1997. [Zilles] Steve Zilles , October 1996. [] From ipp-archive Tue Jun 17 02:04:09 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA06772 for ipp-outgoing; Tue, 17 Jun 1997 02:01:03 -0400 (EDT) Message-Id: <9706170601.AA06432@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: Mon, 16 Jun 1997 22:58:46 PDT To: Robert.Herriot@Eng.Sun.COM (Robert Herriot) From: Tom Hastings Subject: Re: IPP> PRO - A value-type field for the Protocol Spec Cc: ipp@pwg.org, harryl@us.ibm.com Sender: ipp-owner@pwg.org Precedence: bulk SNMP uses a very simple subset of ASN.1/BER, so that SNMP implementation is no where near as complex as general ASN.1/BER. Tom At 12:09 06/09/97 PDT, Robert Herriot wrote: >Part of the reaction is the ASN.1/BER is far more complex than simple >text or XDR. In addition, DPA implementations use full ASN.1/BER and >the BER libraries have made significant contributions to their very large >size. I don't know how much BER contributes to the size of SNMP >implementations, but SNMP uses a subset of BER. > >Bob Herriot > >> From harryl@us.ibm.com Mon Jun 9 08:16:39 1997 >> >> I vote to keep IPP simple, but disagree that ASN.1 is a culprit. >> >> > ASN.1/BER is way too heavy for IPP. If we are too close to >> > reinventing ASN.1 then we are way too heavy for IPP. >> >> The IETF Printer MIB has the support of 9 or 10 vendors, today, with >> software on many diverse platforms and in 6 or 7 vendors embedded >> controller product lines. I keep hearing we shouldn't "strangle" IPP >> with embedded controller limitations. How then, can we claim ASN.1/BER >> is too "heavy" for IPP? >> >> I find lack of compatibility with existing IETF standards (the debate >> over "x,y resolution" for example), and the resulting redundancy, one >> of the "heaviest" things about IPP. >> >> >> >>> Harry Lewis <<< >> >> >> --------- Forwarded by Harry Lewis/Boulder/IBM on 06/09/97 08:28 AM --------- >> >> ipp-owner@pwg.org >> 06/06/97 08:17 PM >> Please respond to rturner@sharplabs.com @ internet >> >> >> To: ipp@pwg.org @ internet >> cc: >> Subject: Re: IPP> PRO - A value-type field for the Protocol Spec >> >> If we are mixing binary and ASCII values within our encoding and require >> extensibility with regard to >> names, types, and values, then this is the kind of thing ASN.1/BER was >> designed for. I suggested >> that we just stick with ABNF as our specification and I would have been >> happy with that. However, >> when we're talking about a more complete, extensible, protocol, in which >> registries come into play, >> I think ASN.1/BER would be a better solution. It adapts much better to >> varying length TLV >> (type, length, value) pair operations and allows implementations (later >> versions) of a protocol to >> adapt easier. (i.e., no version eschange or negotiation). >> >> Randy >> >> Scott Isaacson wrote: >> >> > I am sure that ASN.1 does NOT stand for "A Simple Notation One"?? ;-) >> > >> > And BER, wasn't that "Binary Encoding for computing Resource >> > consumption"?? >> > >> >> > >> > Much of the discussion recently has been around "simplicity". Has >> > IPP lost it ability to be simple? No, I don't think it has. Is it >> > too >> > convoluted in some areas - YES. >> > >> > There was a discussion a few weeks ago about whether IPP was DPA '97. >> > This >> > reminder was a good wake-up call, and useful in that there seemed to >> > be >> > immediate consensus that IPP is not intended to be too complex like >> > DPA is >> > considered to be. >> > >> > I vote keep it simple. Add value-types only if it is a value or >> > keyword >> > that represents a specific well know syntax as described in the >> > standard >> > (extensible through registration). But don't add arbitrarily >> > extsensible, >> > compound data structures as potential values. And don't use ASN.1 !! >> > >> > Scott >> > >> > >>> Randy Turner 06/06 12:38 PM >>> >> > Prior to the San Diego meeting, I proposed using ASN.1 as a way to >> > specify the protocol. This was >> > to prevent us from having to "re-invent" the wheel with regards to our >> > >> > protocol specification. The nice >> > thing about ASN.1 (and its companion BER) is that extensibility is >> > easily achieved and with more >> > flexibility than what has been proposed so far. I think Larry Masinter >> > >> > brought up the fact that ASN.1 >> > might be a better approach, and if extensibility and clarity of >> > specification is what is driving these >> > recent discussions, then I'm curious why we are striving so hard to >> > reinvent another way to do this. >> > >> > Randy >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> >> >> >> >> >> > > From ipp-archive Tue Jun 17 02:54:09 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA07377 for ipp-outgoing; Tue, 17 Jun 1997 02:50:21 -0400 (EDT) Message-Id: <9706170650.AA06443@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: Mon, 16 Jun 1997 23:47:59 PDT To: ipp@pwg.org From: Tom Hastings Subject: Re: IPP> PRO - A value-type field for the Protocol Spec proposa Cc: Brian Grimshaw , "Stephen Zilles" Sender: ipp-owner@pwg.org Precedence: bulk This mail is a summary of the advantages of adding a data type code to our encoding is listed here. This proposal assumes that we are still using UTF8 for representing all attribute values, even if we have a type code. Each advantage is a small gain, but putting all the advantages together makes a significant enough gain to make it worth including in IPP. Advantages: 1. Makes it easier to separate the protocol parser from the code that takes action on each attribute received. 2. True for client parsing a response, as well as a serve parsing a request. 3. The parser need only know about the data types, not about which attributes are supported. 4. Much easier to make an adaptable client that queries a new Printer and displays the user's choices for attributes that the client has never seen before (only the data type code need by recognized). 5. The parser should be faster and smaller, since it only has to know about the data types, not all the attributes. The parser the provides a "framework" into which an implementor can plug in an action routine for each attribute. 6. Instead of having several attributes that differ only in data type, a single attribute can be defined that takes several data types. For example, there could be a dateAndTime data type and just a Time data type. Only one attribute need be defined that supports both data types. Another example would be inches and millimeters. Or the IPP "printer-speed" attribute which has five built-in units. Or an attribute that can either take a value or be a URI to the value. The actual data type code in the attribute instance would indicate whether the data type was, say, text or URI. 7. One data type can be a "setOfAttributes". An implmentation that doesn't implement this data type, could still skip over the entire value. Then we don't need to keep inventing ad hoc data types for attributes whose values are structures. The "setOfAttributes" data type will suffice for all such structures. IPP 2.0 and future registrations will need such a grouping mechanism for some attributes. 8. Another data type can be an "indirect pointer" to the value of another attribute when it is important that two attributes keep the same value. This feature is probably more important for IPP V2.0 for administrative functions, where the adinistrator wants several attributes to share the same values. Tom At 10:54 06/06/97 PDT, Tom Hastings wrote: >I agree with Steve's suggestion to add a data type code to the encoding >of attributes in IPP and Brian's feedback. > >We have concluded an internal review of IPP at Xerox, and adding a >data type code was the most important issue raised. We have had >a year and a half experience with an ASCII encoded attribute representation >that includes the data type. In our implementation, the data type >was a keyword too, but a data type code is sufficient for IPP, where >each of the data type keywords is assigned a one-octet code. > >I don't think we need to assign new data type codes for binary integer >though. We need to keep the data types as simple and small in number >as possible. > >The main reason that we included the data type is that it makes the >implementation of the parser on the recipient much easier while allowing >the parser to unmarshall the protocol into the internal representation >of the machine and present an internal API that uses the binary >machine and programming-langauge dependent data types, rather than keeping >everything in string form. Such a parser does not need to keep a list of >attribute names and their corresponding data types in order to know how >to parse the value. > >These ideas have been included in the OMG Print Facility submission >by Xerox and others date June 2, 1997. We have included the IPP >job attributes in the submission, generalized by changing "printer" >to "device" in the attribute names, since the OMG Print Facility is >intended to be extended to other types of services, such as scan, FAX, >and document distribution. The URL for the document: > > ftp://www.omg.org/pub/docs/cf/97-06-03.doc > > >As Steve and Brian point out, one of the side benefits to adding a >data type code, is that one of the types can be "set-of-attributes" >meaning that the value is a set of attributes. The length of the >top level attribute is the length of the entire attribute set, as usual. >Inside that attribute value is the usual syntax for a set of attributes: >attribute name data-type value, including multiple values for any >individual attribute using the zero-length of the attribute-name field. > >Then the shipping-address attribute example can be handled using this >new data type, and the value is a set of attributes for the fields in >the address. > >With such a data type, it greatly reduces the need to introduce other >adhoc explicit data types or structures that contain fields. > >IPP V2.0 will need the ability to define attributes whose values are >sets of attributes to facilitate the administrative specification of the >Printer. For example, expressing attribute constraints between attributes >is an example of use of the mechanism, such as can't staple transparencies >or can't staple more than 50 sheets. > >Implementations that don't support the attributes that have values >that are sets of attributes ignore the attribute entirely as currently >and are unaffected by the addition of this one new data type, since >the length of the top level value is the entire length and the implementation >just ignores the entire (top level) attribute. > >See explicit comments on Steve's proposal about the data type codes >and registry at the end of this message. > >Thanks, >Tom > > >At 17:30 06/05/97 PDT, Brian Grimshaw wrote: >>Stephen, >> >>To test my understanding of your concern, I summarize the two problems >>you address in the form of objectives. >> >>* The first is to distinguish two attributes that have the same name -- >>the example you give is "address". >> >>* The second is a representation of attributes that consist of multiple >>pieces of information (sub-attributes) that can be easily distinguished. >> >>I think the first goal is best achieved by having meaningful names for >>attributes. The human readable form of attributes is already a reason >>for meaningful names and all attributes are specified as having a type. >>For example, there are attributes for "job-originating-host" and >>"job-originating-user" which are both 'names'. It is unlikely that both >>of these (or either of these) would be called "name" and, similarly, it >>is unlikely that shipping address would be called "address". In this >>example, "address" is best considered the attribute type and "ship-to" >>could be an attribute of type 'address'. >> >>The second goal seems to be (almost) handled by the sentence in the HTTP >>1.1 Transport Mapping document that says "An attribute whose value is a >>set of n values shall be represented as a sequence of n attributes, where >>all but the first attribute have a name of zero length." This specific >>representation could be debated, but if simplified to not have the >>restriction of zero length attribute names for all but the first >>attribute, then this would permit an arbitrary hierarchy of attributes. >>This syntax would be represented as: >> >>attribute = name-length name value-length value >>... >>value = octet-string | attribute >> >>The implicit type of an attribute is sufficient to know if it has a value >>of multiple attributes. >> >> >>There IS a goal I can think of (not to suggest this should be a goal) >>that would justify your proposed solution. If you want to be able to >>programmatically process (perhaps in a UI application) a set of >>attributes, you would need the type information to be explicitly >>represented -- but you would not need to know the attribute names. The >>meaning of an attribute value would still require a priori knowledge of >>the attribute name, but much can be done without that. >> >>If this is not intended, I see the value-type as redundant. If this is >>intended, I suggest that all types (as specified in IPP) be represented. >> >>Brian Grimshaw >>Apple Computer, Inc. >>brian@apple.com >> >> >>>The Problem Statement >>> >>>To avoid vague generalizations, lets consider an example that I believe >>>is likely to arise in the near future. On attribute one might want to >>>add is an "address". For example, one might have an address to which the >>>final output is to be mailed or shipped. One might also have an address >>>to which the bill for reproduction is to be sent. This brings our first >>>problem because, quite often, these two addresses are not the same. >>>That means that we need two different address attributes. >>> >>>The second problem with addresses is that an address is a structured >>>entity. It has things like a mailstop, a street number, a street name, a city >>>sub-region identifier, a city identifier, a state and/or country >>>identifier and, typically, some kind of ZIPcode. These are assembled >>>into an address, but they are assembled in different ways in different >>>cultures and countries. This means that treating the address as a single >>>character string makes it very difficult to accurately recover the >>>information in the address. It makes more sense to store the address as >>>a structured objects with attributes and values for each of the >>>component parts. But, the address (as a whole) is the value of the >>>shipping address or billing address attribute identified above. The >>>current proposal for IPP does not allow a value to be structured. >> >>... >> >>>A Proposed Solution >>> >>>The proposed solution to the extensibility problem is to add a type byte >>>(or half word) to the value portion of the value portion of the >>>attribute-value pair. This would change the syntax in Randy's recent >>>draft as follows: >>> >>>attribute = name-length name value-type value-length value >>>... >>>value-type = one-byte integer ; a registered type value >>>value-length = three-byte integer ; number of octets in value >>>value = octet-string >>> >>>Note that the length was increased to three bytes to allow for larger >>>structured values and was (arbitrarily) made three bytes so that the >>>combination of value-type and value-length takes four bytes. > >I don't think that we need to increase the length beyond two octets. >That is 64K of octets! > >>> >>>It is proposed that there be a registry of value types. The first two >>>entries in that registry would be (zero is reserved) >>> >>>1: Unicode string in UTF8 encoding (as specified in the draft) >>>2: list of values (here the length of the value field determines how >>> many values are present. The length, however, is not the number of >>> value, but the number of bytes consumed by the values. >> > >I would suggest that instead the registry would be the list of current >data type keywords (page 31-33 of the line numbered I-D) with one new type: >attributeSet: > >1: other >2: text >3: name >4: fileName >5: keyword >6: uri >7: uriScheme >8: locale >9: octetString >10: booolean >11: integer >12: dateTime >13: seconds >14: milliseconds >15: integerUnits >16: rangeOfInteger >17: attributeSet > >The two constructed data types of: >1setOf X >rangeOf X >need some discussion. > >I don't think that we need a type code for 1setOf X, since we use the >zero-length attribute-name to represent multiple values in a set of >values. > >Currently the number of different X that use rangeOf X from the table >on page 36 is only rangeOf int, so I put that one in explicitly. > >If there are other ranges needed, we can add them explicitly or use the >attribute set approach. > >Tom > > > > > > > > From ipp-archive Tue Jun 17 08:04:12 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA08919 for ipp-outgoing; Tue, 17 Jun 1997 07:59:44 -0400 (EDT) Message-Id: <1.5.4.32.19970617115717.00692018@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: Tue, 17 Jun 1997 04:57:17 -0700 To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> Agenda for PWG IPP Phone Conference on June 18, 1 - 3:30 PST Sender: ipp-owner@pwg.org Precedence: bulk Agenda for PWG IPP Phone Conference on June 18, 1 - 3:30 PST - Summarize discussions and outcome of the PRO meeting at Sun on June 17 (Bob Herriot) - Status of feedback on latest MOD draft (Scott Isaacson) - Other subgroup reports and activities --- Number: 1-423-523-7162 Access Code: 190148 ---- Carl-Uno From ipp-archive Wed Jun 18 04:09:22 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA12945 for ipp-outgoing; Wed, 18 Jun 1997 04:08:19 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 18 Jun 1997 01:59:23 -0600 From: Scott Isaacson To: ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP> IPP Error codes Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk It was Keith's document. I am putting that document in as an appendix to the model document for the next rev. I hope to have the next rev out by the end of this week. I want to make sure that we have a new doc to review for the IPP meetings next week in NH. Scott >>> Randy Turner 06/12/97 05:54PM >>> Can someone point me to the latest document published on proposed error status codes for IPP requests? I think it was Keith Carter's document but I can't remember. Thanks! Randy From ipp-archive Wed Jun 18 04:09:24 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA12940 for ipp-outgoing; Wed, 18 Jun 1997 04:08:15 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 18 Jun 1997 02:04:53 -0600 From: Scott Isaacson To: ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP> create job IPP operation Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk Randy, >>> Randy Turner 06/12/97 06:10PM >>> > In our current document we have a CREATE-JOB operation that specifies up > front > how many documents we have. Is this an unrealistic requirement for > future IPP > clients (or drivers) ? Will they always know how many documents are >coming when >they first do the CREATE-JOB? The model document shows this (number-of-documents) as an optional attribute in the Create. If it is there, it better be correct. If not, it is up to the implementation to handle as many Documents as might be thrown its way (I claim that it might fail after some N+1 documents). Why include it at all if it is optional? It might help some implementations with resource management. As other mail has indicated, we need a flag in the Send-Document that says this is the last document. Scott From ipp-archive Wed Jun 18 04:09:26 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA12939 for ipp-outgoing; Wed, 18 Jun 1997 04:08:12 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 18 Jun 1997 01:46:37 -0600 From: Scott Isaacson To: Robert.Herriot@Eng.Sun.COM, ipp@pwg.org Subject: Re: IPP>MOD more new operations? Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk I tend to agree with Roger. This can be added later. We already have agreed that "Modify-Job" is a later operation. You have just described a scenario where "Modify-Job" is really useful, but let's leave it to later. Scott >>> Robert Herriot 06/12/97 08:34PM >>> At the moment we have two ways to print jobs, one that does it one operation and one that does it in pieces. But when I look at this from the simple API point of view, I realize that both of these solutions take the "batch" point of view for print job submission. In the batch model the client submits a collection of attributes and the printer either says "yes" or "no" with a collection of attributes that caused it to say no. An alternate "interactive" model is for the client initially to ask the printer to create a job without specifying any attributes (CreateJobStub below). The printer returns a job URI and job template attributes to display on a GUI. When a user changes a value in a GUI, the client performs an operation (ChangeJobStub below) with the job URI that changes the attribute on the printer. With each change, the printer says yes or no. Thus the client knows before accepting the GUI whether the print job is OK. The SendDocument operation terminates the sequence of change operations. The new operations would be: CreateJobStub (to a Printer URI): the printer creates a job stub with each job attribute set to the Printer's default value. The Printer then returns a job URI and all the jobTemplate attributes (i.e. those which specify the printer default values and their potential values). ChangeJobStub (to a Job URI): the printer receives one attribute (name and value). If the change is allowed, the printer performs the change and returns success; otherwise it doesn't make the change and returns failure. Issue: should more than one attribute be allowed for this operation. If so do all have to succeed for any change to occur? Comments? Bob Herriot From ipp-archive Wed Jun 18 04:09:27 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA12929 for ipp-outgoing; Wed, 18 Jun 1997 04:08:09 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 18 Jun 1997 01:43:30 -0600 From: Scott Isaacson To: Robert.Herriot@Eng.Sun.COM, ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP> create job IPP operation Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk In the Model document, there is language about a "zero length document" in a Send-Document operation that is the "flag". I suppose we do need a flag since you might know the document you are sending is the last document and it would not be efficient to require another empty Send-Document. But we must allow for an empty Send-Document for the case that Bob points out where the client does not know it is the end until there are no more documents. Scott >>> Robert Herriot 06/12/97 07:54PM >>> Option 1 (flag for last document) is the best and only reasonable solution. Option 3 (end job operation) can be accomplished with Option 1 by allowing a document of length zero and the last flag on for clients that cannot figure out they are done when they send the last document. Bob Herriot > From rturner@sharplabs.com Thu Jun 12 17:13:25 1997. > > In our current document we have a CREATE-JOB operation that specifies up > front > how many documents we have. Is this an unrealistic requirement for > future IPP > clients (or drivers) ? Will they always know how many documents are > coming when > they first do the CREATE-JOB? > > My feeling is that the clients might not know how many documents will be > sent, and > if that is the case, we need a mechanism for SEND-DOCUMENT to indicate > to > the server that this is the last document for the job. There are at > least 3 ways to do > this off the top of my head: > > 1. Have a specific SEND-DOCUMENT attribute or parameter that flags a > particular > request as the last document for the job. > > 2. Since we are using HTTP 1.1 with persistent connections, just close > the TCP > connection from client to host indicating the end of the job stream > (or last document). > > 3. Have another IPP operation called END-JOB or CLOSE-JOB that > unambiguously > encapsulates the job stream within a CREATE-JOB/END-JOB pair. > > Comments? > > Randy > > > From ipp-archive Wed Jun 18 17:14:30 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA16070 for ipp-outgoing; Wed, 18 Jun 1997 17:09:54 -0400 (EDT) Message-Id: <9706182002.AA06925@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, 18 Jun 1997 13:00:07 PDT To: Scott Isaacson From: Tom Hastings Subject: MOD - Re: IPP> create job IPP operation Cc: Robert.Herriot@Eng.Sun.COM, ipp@pwg.org, rturner@sharplabs.com Sender: ipp-owner@pwg.org Precedence: bulk At the PRO meeting yesterday, we review Randy's protocol document which has lots of operation semantics, which we agreed should be moved to the Model document. Amongst these was a Boolean "end-document-stream" input parameter which we also agreed would become a job attribute, so that you could do a GetAttributes and see if the job stream was still open or not. BTW, we also agreed to call things in the request, 'parameters', not 'attributes'. Most input parameters of Create-Job and Print-Job wind up as attributes on the job object. Parameters are passes in a request or a response, and attributes exist on an object. Tom At 00:43 06/18/97 PDT, Scott Isaacson wrote: >In the Model document, there is language about a "zero length document" in a > >Send-Document operation that is the "flag". I suppose we do need a flag >since you might know the document you are sending is the last document and >it would not be efficient to require another empty Send-Document. But we >must >allow for an empty Send-Document for the case that Bob points out where >the client does not know it is the end until there are no more documents. > >Scott > > >>>> Robert Herriot 06/12/97 07:54PM >>> >Option 1 (flag for last document) is the best and only reasonable solution. > >Option 3 (end job operation) can be accomplished with Option 1 by >allowing a document of length zero and the last flag on for clients >that cannot figure out they are done when they send the last document. > >Bob Herriot > >> From rturner@sharplabs.com Thu Jun 12 17:13:25 1997. > >> >> In our current document we have a CREATE-JOB operation that specifies up >> front >> how many documents we have. Is this an unrealistic requirement for >> future IPP >> clients (or drivers) ? Will they always know how many documents are >> coming when >> they first do the CREATE-JOB? >> >> My feeling is that the clients might not know how many documents will be >> sent, and >> if that is the case, we need a mechanism for SEND-DOCUMENT to indicate >> to >> the server that this is the last document for the job. There are at >> least 3 ways to do >> this off the top of my head: >> >> 1. Have a specific SEND-DOCUMENT attribute or parameter that flags a >> particular >> request as the last document for the job. >> >> 2. Since we are using HTTP 1.1 with persistent connections, just close >> the TCP >> connection from client to host indicating the end of the job stream >> (or last document). >> >> 3. Have another IPP operation called END-JOB or CLOSE-JOB that >> unambiguously >> encapsulates the job stream within a CREATE-JOB/END-JOB pair. >> >> Comments? >> >> Randy >> >> >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From ipp-archive Wed Jun 18 18:09:30 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA16615 for ipp-outgoing; Wed, 18 Jun 1997 18:06:14 -0400 (EDT) Message-Id: <9706182147.AA06956@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, 18 Jun 1997 14:45:08 PDT To: Scott Isaacson From: Tom Hastings Subject: Re: IPP> create job IPP operation Cc: ipp@pwg.org, rturner@sharplabs.com Sender: ipp-owner@pwg.org Precedence: bulk At 01:04 06/18/97 PDT, Scott Isaacson wrote: >Randy, > >>>> Randy Turner 06/12/97 06:10PM >>> >> In our current document we have a CREATE-JOB operation that specifies up >> front >> how many documents we have. Is this an unrealistic requirement for >> future IPP >> clients (or drivers) ? Will they always know how many documents are >>coming when >>they first do the CREATE-JOB? > >The model document shows this (number-of-documents) as an optional attribute >in >the Create. If it is there, it better be correct. If not, it is up to the >implementation >to handle as many Documents as might be thrown its way (I claim that it >might fail >after some N+1 documents). Why include it at all if it is optional? It >might help some >implementations with resource management. In order to avoid another error condition and a requirement for the server to check for the proper number of documents, lets delete the "number-of-documents" input parameter. However, we still need a read-only job attribute that the IPP server SHALL increment by 1 with each Send-Document operation. If we can't agree to delete the "number-of-documents" input parameter from Create-Job, then lets at least change the name to something like: "expected-number-of-documents", so that it is not confused with the read-only "number-of-documents" job status attribute which the IPP printer increments as each Send-Document is received. But I don't see the need for such an input-parameter. Lets wait to see if implementations find a need for such an input-parameter and it can be registered later. Ok? > >As other mail has indicated, we need a flag in the Send-Document >that says this is the last document. Also from the PRO disussion yesterday, a requester must be able to issue a Send-Document with no document data and just the flag set to TRUE, since the requester might not have know that it was the last document when the requester did the Send-Document with the data. This flag is both an input-parameter of the Send-Document operation that also sets the corresponding job attribute of the same name. Randy's protocol document had the input parameter named as an imperitive verb: "end-document-stream", but that isn't such a good name for the corresonding job attribute. How about the ISO DPA name: "job-submission-complete" for both the input parameter and the read-only job status attribute. Tom > >Scott > > > > > > > > > > > > > > > > > > > > > > > > > > > From ipp-archive Wed Jun 18 19:59:31 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA17187 for ipp-outgoing; Wed, 18 Jun 1997 19:56:22 -0400 (EDT) Date: Wed, 18 Jun 1997 16:53:56 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706182353.QAA09488@woden.eng.sun.com> To: SISAACSON@novell.com, hastings@cp10.es.xerox.com Subject: Re: IPP> create job IPP operation Cc: ipp@pwg.org, rturner@sharplabs.com X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk I agree with Tom that we should delete "number-of-documents" because we have added a new parameter to Send-Document called (I propose) "last-document" which is Boolean. I don't agree with Tom's suggestion of to have a number-of-documents that the Printer increments. I would rather allow the user to query document-name and get back a set of n document names. Bob Herriot Tom's proposal of adding > From hastings@cp10.es.xerox.com Wed Jun 18 15:14:53 1997 > > At 01:04 06/18/97 PDT, Scott Isaacson wrote: > >Randy, > > > >>>> Randy Turner 06/12/97 06:10PM >>> > >> In our current document we have a CREATE-JOB operation that specifies up > >> front > >> how many documents we have. Is this an unrealistic requirement for > >> future IPP > >> clients (or drivers) ? Will they always know how many documents are > >>coming when > >>they first do the CREATE-JOB? > > > >The model document shows this (number-of-documents) as an optional attribute > >in > >the Create. If it is there, it better be correct. If not, it is up to the > >implementation > >to handle as many Documents as might be thrown its way (I claim that it > >might fail > >after some N+1 documents). Why include it at all if it is optional? It > >might help some > >implementations with resource management. > > In order to avoid another error condition and a requirement for the > server to check for the proper number of documents, lets delete the > "number-of-documents" input parameter. > > However, we still need a read-only job attribute that the IPP server > SHALL increment by 1 with each Send-Document operation. > > If we can't agree to delete the "number-of-documents" input parameter > from Create-Job, then lets at least change the name to something like: > "expected-number-of-documents", so that it is not confused with the > read-only "number-of-documents" job status attribute which the IPP printer > increments as each Send-Document is received. But I don't see the > need for such an input-parameter. Lets wait to see if implementations > find a need for such an input-parameter and it can be registered later. > > Ok? > > > > >As other mail has indicated, we need a flag in the Send-Document > >that says this is the last document. > > Also from the PRO disussion yesterday, a requester must be able to > issue a Send-Document with no document data and just the flag set > to TRUE, since the requester might not have know that it was the > last document when the requester did the Send-Document with the data. > > This flag is both an input-parameter of the Send-Document operation > that also sets the corresponding job attribute of the same name. > > Randy's protocol document had the input parameter named as an imperitive verb: > "end-document-stream", but that isn't such a good name for the > corresonding job attribute. How about the ISO DPA name: > "job-submission-complete" for both the input parameter and the read-only > job status attribute. > > Tom > > > > >Scott > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From ipp-archive Wed Jun 18 20:14:32 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA17706 for ipp-outgoing; Wed, 18 Jun 1997 20:10:50 -0400 (EDT) Date: Wed, 18 Jun 1997 17:12:07 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706190012.RAA09539@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO Minutes of June 17th meeting X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Minutes of IPP Protocol Meeting The protocol group held a face-to-face meeting on June 17 from 0930 to 1800 at Sun Microsystem in Mountain View. The people attending were: Brian Grimshaw Apple Roger Debry IBM Keith Carter IBM Jeff Copeland QMS Sylvan Butler HP Tom Hastings Xerox Carl-Uno Manros Xerox Bob Herriot Sun Microsystems Randy Turner Sharp (via telephone) NOTE: this document contains the new syntax for protocol. The group first discussed whether the encoding rules should use length or a delimiter to terminate values and other items. We considered three alternatives for representing an attribute: Description Syntax The binary proposal from San Diego binary-length name binary-length value Randy's hybrid name 1*%x20 ascii-length 1*%x20 value CRLF HTTP-like name ":" value CRLF After much discussion and looking at various pros and cons we decided on Randy's hybrid with some modifications. We decided that we didn't want to deal with escaping characters in the value and we didn't want to have binary values. We then decided it was as hard to scan for the end of an ascii integer as to scan for the end of an attribute name. The following is the syntax that we decided on. name %x20 1*4 digit %x20 value We talked about whether we should add a type identifier to specify the type of each attribute value. We decided not to do so because such information is only part of what a client needs to present an unknown attribute. Such information includes type, localization strings and presentation in the GUI. We decided that a client should either hard code (v1) or get such information from a server (later version). For representation of values we decided: Attribute values are all in UTF-8. Integer: only digits 1*10DIGIT Boolean: ascii "0" for false and "1" for true Range is represented by a set of 2 values Set of n elements is represented by a series of n attributes with a 0 length name for attributes 2 through n. date: ISSUE: should we use ISO 8601 vs rfc 1123: Examples: RFC 1123: Wed, 18 Jun 1997 15:20:03 GMT ISO 8601: 1997-06-18 15:20:03Z We changed the version number to be 4 ascii digits, 2 for major version and 2 for the minor version. So the syntax for a request is 4*DIGIT operation-name CRLF *parameters CRLF [ document-data ] The syntax for a response is: 4*DIGIT operation-response-name %x20 ipp-status CRLF * parameters CRLF [response-data] where ipp-status is 6 DIGIT where the first 3 digits are the HTTP status. We decided on all keywords to be case sensitive and follow model document names. Can only register key-words whose letters are all lower case. That is the syntax of a key word is LOWER-ALPHA *( LOWER_ALPHA / DIGIT / "-" / "_" ) Operations are mixed case with hyphens between words. If a Print-Job, Print-URI Create-Job, Send-Document or Send-URI operation has repeated attributes, the last one supersedes any earlier ones. The following is an example of a Print-Job request "0100Print-Job" CRLF "job-name 3 foocopies 1 2document-format 22 application/postscript" "finishings 5 staple 5 punch" CRLF "%!PS" ... The following is an example of a Print-Job response "0100Print-Job-Resp 200000" CRLF "reason-phrase 2 OK job-state 7 pending CRLF A response may have multiple CRLF to separate groups. For example, each CRLF for Get-Jobs separates a job object. ISSUE: is there a CRLF at the end? And do some operations support a back channel within the end of a response? The text in the document should use "attribute" to refer to attributes of an object, even when one is in an operation, but should use the word "parameter" for the other name-value pairs in an operation. Special values such as version have no general name. That is, the field containing the version is called the version. Add Get-Operations which is mandatory and returns all operations supported. Three mandatory operations Print-Job, Validate-Job, Get-Operations. The Printer may return attributes requested via Get-Attributes and Get-Jobs in any order and they need not be in the order requested via the operation. If a client requests an attribute twice in a Get-Attributes or Get-Jobs operation, the server may send it back once or twice and in the latter case the two occurrence may have different values. ISSUE: the group needs to revisit the notion of "do best effort" because of lack of Get-Attributes support in some implementations. It may not be possible for a client to determine what a Printer supports. We did decide that when Print-Job, Create-Job or Validate-Job reject a job, they MUST return at least one attribute that caused the rejection. They should return all attributes that caused a rejection. Such attributes appears as parameters such that the parameter name is the attribute name and the parameter value is the attribute value. If an attribute value is unsupported, its value is the same as the client submitted, and if an attribute name is unsupported, its value is "unsupported". We recognized that that an attribute with the value of "unsupported" would look the same, but we didn't want to fix this problem. The following is the syntax of the protocol that we have agreed on. This is my design of the syntax which should reflect what we agreed on. The following protocol primitives are defined: DIGIT = "0".."9" CRLF = %d13.10 ALPHA = "a..z" BYTE = %d0..%d255 OCTET-STRING = *BYTE The following ABNF specification describes the encoding of an IPP message (PDU): ipp-message = ipp-request / ipp-response ipp-request = version operation CRLF *parameter CRLF [ operation-data ] ipp-response = version operation-resp %x20 status CRLF *parameter CRLF [ response-data ] version = major-version minor-version major-version = 2DIGIT minor-version = 2DIGIT status = 6DIGIT operation = operation-resp = operation "-resp" parameter = name 1*( %x20 value-length %x20 value ) name = ALPHA *(ALPHA / DIGIT / "_" / "-" ) value-length = 1*4DIGIT value = OCTET-STRING operation-data = OCTET-STRING response-data = OCTET-STRING ISSUE: does the protocol support response data? We then reviewed Randy's document and produced the following observations and conclusions. The was a general comment that all semantics should move to the model document and that Randy's document should contain mappings and HTTP information only. We added new attributes job-URI-user and printer-URI-user which are URIs that a browser can use to get information about a job or printer. The job-URI-user is an optional result of a Print-Job and Create-Job operation. We added a parameter to Send-Document and Send-URI called "last-document" (or something like that) which is mandatory and is false for all but the last document to be sent. The document-data for the last document may be empty. We decided that a document-name could be a parameter in a Send-URI or Print-URI operation with document-URI specifying where the document is and document-name specifying a name to identify the document, perhaps on a banner page. Randy proposed that Cancel-Job return various job-state information. There was some question about whether Cancel-Job should have an option that allows a client to choose whether to receive such information. This was left as an ISSUE: We decided that Get-Attributes and Get-Jobs will not return unsupported attributes. We decided that Get-Jobs should not support the filtering mechanism (job-state and job-owner) parameters. We discussed the ordering of job that are pending and pending-held. We concluded that pending-held should appear in their position as if they were pending. Otherwise, a user might be deceived by jobs that move from pending-held to pending an seem to jump ahead in the queue. From ipp-archive Thu Jun 19 14:29:43 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA19937 for ipp-outgoing; Thu, 19 Jun 1997 14:29:02 -0400 (EDT) Message-Id: <9706191743.AA00367@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Jun 1997 10:41:20 PDT To: Robert.Herriot@Eng.Sun.COM (Robert Herriot) From: Tom Hastings Subject: Re: IPP> create job IPP operation Cc: SISAACSON@novell.com, ipp@pwg.org, rturner@sharplabs.com Sender: ipp-owner@pwg.org Precedence: bulk At 16:53 06/18/97 PDT, Robert Herriot wrote: >I agree with Tom that we should delete "number-of-documents" because >we have added a new parameter to Send-Document called (I propose) >"last-document" which is Boolean. The problem with "last-document" as a name for the input-parameter, is that the corresponding job attribute would have to be different, say, "job-submission-complete". I think that as a principle, the names of the input parameters and the names of the job attributes that the input parameters set should be the same. Using the same names for input parameters as the corresponding job attributes (when there are both) will also make the encoding more understandable, since we don't have any separate buckets for input parameters in the encoding, but have just a single set of attribute representations as input parameters. Or were you prosing that we don't need a Boolean job attribute that indicates whether the job is complete or not? Since we have the "job-state-reasons" 'job-incoming' value, perhaps that is enough to indicate to a requester in a Get-Attrbutes request that the job is not yet complete? If we don't also need a "job-submission-complete" job attribute, then the input-parameter name "last-document" Boolean is fine. Not having the "job-submission-complete" job attribute makes it more mandatory that an implementation that supports Create-Job and Send-Document also support the 'job-incoming' reason in the "job-state-reasons" attribute. > >I don't agree with Tom's suggestion of to have a number-of-documents >that the Printer increments. I would rather allow the user to query >document-name and get back a set of n document names. I can agree that we don't really need a "number-of-documents" job attribute, since the requester can find the number of documents by requesting a document attribute, such as "document-name" But that brings up the need for a clarification of how the Get-Attributes operation returns document attributes. The Get-Attributes operation for document attributes needs a lot of clarification. Currently the model document has only 3 document attribtes: "document-name", "document-format", and "document-uri". I had thought that the document attributes would come back in groups, one group for each document if and only if the requester requests a document attribute, such as "document-name". I thought this, because the document has been made an object (but with no operations on it). Bob might be suggesting that the Printer returns a single multi-valued attribute "document-format", with a separate value for each document. If a requester supplies: Create-Job(...) Send-Document( "document-format" = 'application/postscript' "document-name" = 'Monthly Slides' ) Send-Document( "document-format" = 'application/vnd.hp-PCL' "document-name" = 'Monthly Report' Get-Attributes with "requested-attributes" = 'document-format', 'document-name'; input parameter would return: Result Attributes: "document-format" = 'application/postscript', 'application/vnd.hp-PCL' "document-name" = 'Monthly Slides', 'Monthly Report' I had assumed that the result would group document attributes with some specified document attribute as the indicator that the next set of document attributes were following. Either we pick "document-name" or make up a new read-only status attribute, say, "document-sequence-number" (as in DPA) that is set by the Printer. I prefer the latter: Result Attributes: "document-sequence-number" = '1' "document-format" = 'application/postscript' "document-name" = 'Monthly Slides' "document-sequence-number" = '2' "document-format" = 'application/vnd.hp-PCL' "document-name" = 'Monthly Report' Comments? Tom > >Bob Herriot > >Tom's proposal of adding >> From hastings@cp10.es.xerox.com Wed Jun 18 15:14:53 1997 > >> >> At 01:04 06/18/97 PDT, Scott Isaacson wrote: >> >Randy, >> > >> >>>> Randy Turner 06/12/97 06:10PM >>> >> >> In our current document we have a CREATE-JOB operation that specifies up >> >> front >> >> how many documents we have. Is this an unrealistic requirement for >> >> future IPP >> >> clients (or drivers) ? Will they always know how many documents are >> >>coming when >> >>they first do the CREATE-JOB? >> > >> >The model document shows this (number-of-documents) as an optional attribute >> >in >> >the Create. If it is there, it better be correct. If not, it is up to the >> >implementation >> >to handle as many Documents as might be thrown its way (I claim that it >> >might fail >> >after some N+1 documents). Why include it at all if it is optional? It >> >might help some >> >implementations with resource management. >> >> In order to avoid another error condition and a requirement for the >> server to check for the proper number of documents, lets delete the >> "number-of-documents" input parameter. >> >> However, we still need a read-only job attribute that the IPP server >> SHALL increment by 1 with each Send-Document operation. >> >> If we can't agree to delete the "number-of-documents" input parameter >> from Create-Job, then lets at least change the name to something like: >> "expected-number-of-documents", so that it is not confused with the >> read-only "number-of-documents" job status attribute which the IPP printer >> increments as each Send-Document is received. But I don't see the >> need for such an input-parameter. Lets wait to see if implementations >> find a need for such an input-parameter and it can be registered later. >> >> Ok? >> >> > >> >As other mail has indicated, we need a flag in the Send-Document >> >that says this is the last document. >> >> Also from the PRO disussion yesterday, a requester must be able to >> issue a Send-Document with no document data and just the flag set >> to TRUE, since the requester might not have know that it was the >> last document when the requester did the Send-Document with the data. >> >> This flag is both an input-parameter of the Send-Document operation >> that also sets the corresponding job attribute of the same name. >> >> Randy's protocol document had the input parameter named as an imperitive verb: >> "end-document-stream", but that isn't such a good name for the >> corresonding job attribute. How about the ISO DPA name: >> "job-submission-complete" for both the input parameter and the read-only >> job status attribute. >> >> Tom >> >> > >> >Scott >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> >> > > From ipp-archive Thu Jun 19 15:04:43 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA20806 for ipp-outgoing; Thu, 19 Jun 1997 15:03:04 -0400 (EDT) Message-Id: <9706191823.AA00384@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Jun 1997 11:21:31 PDT To: Larry Masinter From: Tom Hastings Subject: Re: IPP> extensibility Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk Larry, Could you elaborate on why you think that the requester needs to be able to flag each supplied attribute as to whether it is a compulsory (what you call mandatory) or is non-compulsory (what you call optional) in order to achieve extensibility. IPP has dropped the idea of allowing the requester to be able to indicate. Now IPP requires the provider to reject the request if there are any values that the provider doesn't understand. The requester then needs to fix up the request until the provider can accept all values. The requester can query the provider to determine all supported values of all attributes that the requester can supply. Thanks, Tom At 13:10 06/09/97 PDT, Larry Masinter wrote: >For good extensibility and interoperability, you need both >manditory parameters ("reject this job if you don't understand >this parameter") and optional ones ("if you don't understand >this, just ignore it"). > >A recipient must be able to tell just by examining the >attribute which class it is in. > >I thought this was part of the whole job/PDL parameter override >issue, but it looks like I must have missed something. > >Larry > > From ipp-archive Thu Jun 19 15:09:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA20861 for ipp-outgoing; Thu, 19 Jun 1997 15:05:59 -0400 (EDT) Message-Id: <9706191836.AA00389@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Jun 1997 11:34:09 PDT To: Harry Lewis From: Tom Hastings Subject: Re: IPP> Re: draft-mutz-http-attributes-02.txt Cc: Sender: ipp-owner@pwg.org Precedence: bulk At 07:31 06/09/97 PDT, Harry Lewis wrote: >I know this must be an area of "clash" between DPA and the Printer MIB, but >wouldn't it be a good idea to establish a convention which is compatible with >RFC1759 regarding Feed and CrossFeed marker addressability? The problem with having an IPP attribute that is so physical that relates to the feed direction, is that some printers feed long edge first and some feed short edge first (and some do either depending on how the input tray is set up). The requester should not have to know how the printer is currently configured, but should be able to specify attributes in a more printer independent and configuration independent manner. Tom > >>>> Harry Lewis <<< > > >------- Forwarded by Harry Lewis/Boulder/IBM on 06/09/97 08:23 AM ------ > > ipp-owner@pwg.org > 06/06/97 08:19 PM >Please respond to ipp-owner@pwg.org @ internet > > >To: njoffe@cisco.com @ internet, masinter@parc.xerox.com @ internet, >Robert.Herriot@Eng.Sun.COM @ internet >cc: ipp@pwg.org @ internet, MONTULLI@netscape.com @ internet, >MUTZ@hplms26.hpl.hp.com @ internet, dwing@cisco.com @ internet, >andy_mutz@hp.com @ internet >Subject: Re: IPP> Re: draft-mutz-http-attributes-02.txt > >Your solution below requires new, more complicated mechanisms for relating >pairs of attributes. All this is just for solving a problem for one >attribute. We have tried to keep the rules for attributes simple. > >I think it is simpler to have resolution be a set of keywords, than to >have some complex mechanism for relating two attributes or to add some >new value syntax for integerOrPairOfIntegers. > >Bob Herriot > > >> From njoffe@cisco.com Fri Jun 6 13:45:40 1997 >> >> At 12:42 PM 6/6/97 -0700, Robert Herriot wrote: >> > >> >> From masinter@parc.xerox.com Thu Jun 5 19:32:57 1997 >> >> >> >> > None of these solutions solve the problem of the Printer's >> >> > resolutions-supported attribute which, hopefully, tells the >> >> > client exactly what resolutions the Printer supports without >> >> > any extraneous values and without a complicated structure >> >> > for the attribute. >> >> >> >> I think this is the same problem fax has, though. >> >> Why would a list of pairs of integers (x-res/y-res) >> >> or integer & ratio (x-res, aspect ratio) have 'extraneous >> >> values'? Or be a 'complicated structure'? >> >> >> > >> >If there are attributes x-res and y-res, then according to the IPP >> >model, there must be an x-res-supported and a y-res-supported in the >> >Printer. Suppose the printer supports 300 and 300x600 and 600 Then >> >both x-res-supported and y-res-supported have values of 300 and 600. >> >Then x-res and y-res can have any of the following 4 values 300x300, >> >300x600, 600x600 and 600x300. The last value is not a legitimate value >> >according to my original statement. >> > >> >It may be that resolutions supported by real printers and all future >> >printers can never have this problem. For example if the values are 300 >> >and 300x600, then x-res-supported is 300 and y-res-supported is 300 and >> >600. No illegal combinations are possible with these values. >> > >> >That's the problem I have with the x-res, y-res solution. If you can >> >show my that this solution cannot lead to unsupported combinations, >> >then I would agree that a pair of integers is possibly a better solution. >> >> You will need to specify the following pairs: >> x-res=300, y-res=300 >> x-res=300, y-res=600 >> x-res=600, y-res=600 >> >> or maybe >> >> x-res=600, y-res=600 >> x-res=300, y-res>=xres >> >> >> > >> >Bob Herriot >> > >> > >> > >> >> ------------------------------------------------------------------------ >> Neil Joffe Email: njoffe@cisco.com >> Software Engineer Voice: +1 (408) 527-7957 >> Voice Technology Engineering Fax: +1 (408) 527-3907 >> Cisco Systems >> San Jose >> ------------------------------------------------------------------------ >> >> > > > > > From ipp-archive Thu Jun 19 15:09:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA20867 for ipp-outgoing; Thu, 19 Jun 1997 15:06:05 -0400 (EDT) Message-Id: <9706191812.AA00379@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Jun 1997 11:09:57 PDT To: ipp@pwg.org From: Tom Hastings Subject: Re: IPP> Re: draft-mutz-http-attributes-02.txt [ISSUE: resolution as a pair of integers] Sender: ipp-owner@pwg.org Precedence: bulk Larry is suggesting that FAX, IPP, and scanning all need resolutions in x and y that might differ, though usually they are the same. Having integers, instead of enums, gets us out of the registration business, but slighlty complicates the attribute representation into needing a way to represent pairs of integers as an attribute value. If we wanted IPP to represent resolution as a pair of integers, what would the structure and encoding be? We already have to be able to represent a range of integers, which is a pair of integers. With Larry's proposalwe would need to be able to represent a 1SetOf RangeOf Integer. One crude way to do it would be to make resolution a multi-valued attribute that the requester can supply one or two integer values and no more. If one value, x and y are the same. If two values, x and y could be different. For the corresponding "resolutions-supported" Printer attribute, we could have a multi-valued integer in which the values come in pairs (really crude!). I.e., "printer-supported" = '300' '300' '300' '600' '600' '600' for a printer that supports the three pairs: 300x300, 300x600, and 600x600. If the printer supports 600x300 (x by y), then it would have to add a two more values: '600' '300'. A more elegant solution requires some more structure to representing pairs of integer values. One way is to introduce the notation of an attribute whose values are themselves attributes: So the "resolution" attribute could have as values the attrbutes: "x-resolution" and "y-resolution". The "resolution-supported" attribute would be multi-valued, where each value is an attribute set containing "x-resolution" and "y-resolution". The encoding techinque with a length for the outer value (and each inner value) means that a recipient that doesn't support this attribute would still be able to step over the entire value to look at the next attribute supplied by the requester. Remember that a client requesting all attributes of a Printer might get back such an attribute that the client doesn't recognize/support. Pictorally the encoding would be something like: "resolution" "x-resolution" '300' "y-resolution" '600' and "resolution-supported "x-resolution" '300' "y-resolution" '300' "" "x-resolution" '300' "y-resolution" '600' "" '600' "y-resolution" '600' At 19:31 06/05/97 PDT, Larry Masinter wrote: >> None of these solutions solve the problem of the Printer's >> resolutions-supported attribute which, hopefully, tells the >> client exactly what resolutions the Printer supports without >> any extraneous values and without a complicated structure >> for the attribute. > >I think this is the same problem fax has, though. >Why would a list of pairs of integers (x-res/y-res) >or integer & ratio (x-res, aspect ratio) have 'extraneous >values'? Or be a 'complicated structure'? > >-- >http://www.parc.xerox.com/masinter > > >Return-Path: >Date: Thu, 5 Jun 1997 19:31:12 PDT >From: Larry Masinter >Organization: Xerox PARC >To: Robert Herriot >Cc: andy_mutz@hp.com, njoffe@cisco.com, dwing@cisco.com, > MUTZ@hplms26.hpl.hp.com, MONTULLI@netscape.com, ipp@pwg.org >Subject: Re: IPP> Re: draft-mutz-http-attributes-02.txt >References: <199706060223.TAA17184@woden.eng.sun.com> >Sender: ipp-owner@pwg.org > >> None of these solutions solve the problem of the Printer's >> resolutions-supported attribute which, hopefully, tells the >> client exactly what resolutions the Printer supports without >> any extraneous values and without a complicated structure >> for the attribute. > >I think this is the same problem fax has, though. >Why would a list of pairs of integers (x-res/y-res) >or integer & ratio (x-res, aspect ratio) have 'extraneous >values'? Or be a 'complicated structure'? > >-- >http://www.parc.xerox.com/masinter > > From ipp-archive Thu Jun 19 15:49:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA22840 for ipp-outgoing; Thu, 19 Jun 1997 15:47:46 -0400 (EDT) Date: Thu, 19 Jun 1997 12:41:58 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706191941.MAA10099@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, hastings@cp10.es.xerox.com Subject: Re: IPP> create job IPP operation Cc: SISAACSON@novell.com, ipp@pwg.org, rturner@sharplabs.com X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk I was proposing that "last-document" be an operation parameter with no corresponding concept in the job object. Therefore, I infer that you agree with the name of "last-document". For Get-Attributes and GetJobs of document attributes, such as document-name, I was trying to keep things simple by saying that in a job with 2 or more documents, the value of each such attribute is a set of the document values. For example, if I submit a job with two documents whose document-name attributes are "foo" and "bar", then Get-Attributes with document-name requested shall return in protocol syntax "document-name 3 foo 3 bar" This is the syntax for a set of values for document-name. This solution does not solve the problem of document-attributes that are multi-valued, but we don't have any yet. So we can defer the solution. Bob Herriot > From hastings@cp10.es.xerox.com Thu Jun 19 11:31:30 1997 > > At 16:53 06/18/97 PDT, Robert Herriot wrote: > >I agree with Tom that we should delete "number-of-documents" because > >we have added a new parameter to Send-Document called (I propose) > >"last-document" which is Boolean. > > The problem with "last-document" as a name for the input-parameter, > is that the corresponding job attribute would have to be different, > say, "job-submission-complete". I think that as a principle, the > names of the input parameters and the names of the job attributes > that the input parameters set should be the same. > > Using the same names for input parameters as the corresponding job > attributes (when there are both) will also make the encoding more > understandable, since we don't have any separate buckets for input > parameters in the encoding, but have just a single set of attribute > representations as input parameters. > > Or were you prosing that we don't need a Boolean job attribute > that indicates whether the job is complete or not? Since we have > the "job-state-reasons" 'job-incoming' value, perhaps that is enough to indicate > to a requester in a Get-Attrbutes request that the job is not yet > complete? If we don't also need a "job-submission-complete" job attribute, > then the input-parameter name "last-document" Boolean is fine. > Not having the "job-submission-complete" job attribute makes it more > mandatory that an implementation that supports Create-Job and Send-Document > also support the 'job-incoming' reason in the "job-state-reasons" attribute. > > > > > >I don't agree with Tom's suggestion of to have a number-of-documents > >that the Printer increments. I would rather allow the user to query > >document-name and get back a set of n document names. > > I can agree that we don't really need a "number-of-documents" job > attribute, since the requester can find the number of documents by > requesting a document attribute, such as "document-name" > > But that brings up the need for a clarification of how the Get-Attributes > operation returns document attributes. > > The Get-Attributes operation for document attributes needs a lot of > clarification. Currently the model document has only 3 document attribtes: > "document-name", "document-format", and "document-uri". > > I had thought that the document attributes would come back in groups, > one group for each document if and only if the requester requests a > document attribute, such as "document-name". I thought this, because the > document has been made an object (but with no operations on it). > > Bob might be suggesting that the Printer returns a single multi-valued > attribute "document-format", with a separate value for each document. > > If a requester supplies: > Create-Job(...) > Send-Document( > "document-format" = 'application/postscript' > "document-name" = 'Monthly Slides' ) > Send-Document( > "document-format" = 'application/vnd.hp-PCL' > "document-name" = 'Monthly Report' > > Get-Attributes with "requested-attributes" = 'document-format', 'document-name'; > input parameter would return: > > Result Attributes: > "document-format" = 'application/postscript', 'application/vnd.hp-PCL' > "document-name" = 'Monthly Slides', 'Monthly Report' > > I had assumed that the result would group document attributes with some > specified document attribute as the indicator that the next set of > document attributes were following. Either we pick "document-name" > or make up a new read-only status attribute, say, "document-sequence-number" > (as in DPA) that is set by the Printer. I prefer the latter: > > Result Attributes: > "document-sequence-number" = '1' > "document-format" = 'application/postscript' > "document-name" = 'Monthly Slides' > "document-sequence-number" = '2' > "document-format" = 'application/vnd.hp-PCL' > "document-name" = 'Monthly Report' > > Comments? > > Tom > > > > > > > >Bob Herriot > > > >Tom's proposal of adding > >> From hastings@cp10.es.xerox.com Wed Jun 18 15:14:53 1997 > > > >> > >> At 01:04 06/18/97 PDT, Scott Isaacson wrote: > >> >Randy, > >> > > >> >>>> Randy Turner 06/12/97 06:10PM >>> > >> >> In our current document we have a CREATE-JOB operation that specifies up > >> >> front > >> >> how many documents we have. Is this an unrealistic requirement for > >> >> future IPP > >> >> clients (or drivers) ? Will they always know how many documents are > >> >>coming when > >> >>they first do the CREATE-JOB? > >> > > >> >The model document shows this (number-of-documents) as an optional attribute > >> >in > >> >the Create. If it is there, it better be correct. If not, it is up to the > >> >implementation > >> >to handle as many Documents as might be thrown its way (I claim that it > >> >might fail > >> >after some N+1 documents). Why include it at all if it is optional? It > >> >might help some > >> >implementations with resource management. > >> > >> In order to avoid another error condition and a requirement for the > >> server to check for the proper number of documents, lets delete the > >> "number-of-documents" input parameter. > >> > >> However, we still need a read-only job attribute that the IPP server > >> SHALL increment by 1 with each Send-Document operation. > >> > >> If we can't agree to delete the "number-of-documents" input parameter > >> from Create-Job, then lets at least change the name to something like: > >> "expected-number-of-documents", so that it is not confused with the > >> read-only "number-of-documents" job status attribute which the IPP printer > >> increments as each Send-Document is received. But I don't see the > >> need for such an input-parameter. Lets wait to see if implementations > >> find a need for such an input-parameter and it can be registered later. > >> > >> Ok? > >> > >> > > >> >As other mail has indicated, we need a flag in the Send-Document > >> >that says this is the last document. > >> > >> Also from the PRO disussion yesterday, a requester must be able to > >> issue a Send-Document with no document data and just the flag set > >> to TRUE, since the requester might not have know that it was the > >> last document when the requester did the Send-Document with the data. > >> > >> This flag is both an input-parameter of the Send-Document operation > >> that also sets the corresponding job attribute of the same name. > >> > >> Randy's protocol document had the input parameter named as an imperitive > verb: > >> "end-document-stream", but that isn't such a good name for the > >> corresonding job attribute. How about the ISO DPA name: > >> "job-submission-complete" for both the input parameter and the read-only > >> job status attribute. > >> > >> Tom > >> > >> > > >> >Scott > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > >> > > > > > > From ipp-archive Thu Jun 19 19:34:47 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA23984 for ipp-outgoing; Thu, 19 Jun 1997 19:32:51 -0400 (EDT) Message-Id: <9706192332.AA00580@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Jun 1997 16:30:20 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Lets use integer pairs in the "printer-resolution" attribute Sender: ipp-owner@pwg.org Precedence: bulk >From the PRO 6/17 meeting and minutes we've agreed that a range is encoded as a multi-valued attribute with two values. Presumably a SetOf RangeOf X would be encoded as a multi-valued attribute in which each pair of values is interpreted as a range. So we are now in a position to reconsider the "printer-resolution" job template attribute in the Model document. We had decided to use enums with explicit combinations (which could be added to by going to the registration process), so that there wouldn't be a complicated structure for encoding pairs. But now that we have a simple encoding, namely a multi-valued attribute, we can reconsider using integers for resolution. Using pairs of integers will get us out of the registration business for resolution and may help IPP converge with the FAX folks. I propose the following for the table on page 37: printer-resolution(1SetOf Integer) printer-resolution(1SetOf Integer) printer-resolution-supported(1SetOf Integer) I propose the following specification for "printer-resolution": 6.2.12 printer-resolution (1SetOf Integer) This job attribute specifies the resolution in dots per inch that the Printer SHALL use. The value SHALL be a single integer or a pair of integers. The latter are to specify the resolution when the x and y dimensions differ. When two integers are specified, the first is in the x direction, i.e., in the direction of the shortest dimension of the medium, so that the value is independent of whether the printer feeds long edge or short edge first. The "printer-resolution-supported" Printer attribute SHALL always contain pairs of integers for the various combinations of x and y direction resolutions that are supported, whether the x and y values differ or not. Comments? Tom From ipp-archive Thu Jun 19 19:59:48 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA24659 for ipp-outgoing; Thu, 19 Jun 1997 19:57:37 -0400 (EDT) Message-Id: <9706192357.AA00599@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Jun 1997 16:55:30 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - The Get-Jobs operation and completed/canceled/aborted jobs Sender: ipp-owner@pwg.org Precedence: bulk Bob Herriot and I were talking about the agreement at the 6/17 PRO meeting to remove the filter from the Get-Jobs operation. We think that the order that jobs are returned should be specified as something like: The order of jobs in the Get-Jobs Response SHALL be the oldest to newest with respect to completion time (either actual or expected), irrespective of job state. The problem that remains, is that this means that the 'completed' jobs come back first, which are usually the least interesting, though valuable to obtain in some cases. A good GUI interface should scroll off most of the completed jobs and show a few of the recently completed jobs followed by the processing and pending jobs. However, that is a fair amount of work. If we leave the specification as always returning all jobs, some providers will discover that clients aren't doing anything user-friendly with the results when the provider keeps a lot of completed jobs around for status or tracking. Then these providers will abandon keeping completed jobs around, so that they don't look bad to users using clients that don't do good things with the completed jobs that come back first. So we propose to add a "return-completed-jobs" input parameter to Get-Jobs with the following values: 'first' - return 'completed', 'canceled', and 'aborted' jobs in order of actual completion followed by 'pending', 'pending-held', 'processing', and 'processing-stopped' jobs in order of expected completion. 'last' - return 'pending', 'pending-held', 'processing', and 'processing-stopped' jobs in order of expected completion followed by 'completed', 'canceled', and 'aborted' jobs in order of actual completion. 'never' - do not return 'completed', 'canceled', and 'aborted' jobs at all. The default value for this input-parameter SHALL be 'never'. Comments? Tom and Bob From ipp-archive Thu Jun 19 20:44:48 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA25185 for ipp-outgoing; Thu, 19 Jun 1997 20:41:38 -0400 (EDT) Message-ID: From: "Sylvan Butler" X-Real-Sender: SYLVAN Organization: Hewlett-Packard, Boise To: ipp@pwg.org Date: Thu, 19 Jun 1997 18:41:08 -0700 Subject: IPP>PRO: sorry, but binary is better Priority: normal X-mailer: Pegasus Mail v3.31 Sender: ipp-owner@pwg.org Precedence: bulk I'm sorry for the length of this missive (about 150 lines plus headers...) but it seems necessary. Last night I revised Paul's document to indicate what we had concluded on the 17th, and this morning I woke up way too early... Or perhaps it was way too late, depending on your perspective. A binary encoding is MUCH simpler. Even if limited to just the lengths. For example, with 16-bit binary lengths (FAIRLY COMPLETE CODE): // assumes enough incoming buffer to hold entire name and ValLen fields // requires external help to deal with long or multiple values int GrabAttr(ATTR *pAttr) { nLength=ntohs((unsigned short)*(U16 *)pBuf); pBuf+=2; pAttr->nNameLength=nLength; pAttr->pName=pBuf; pBuf+=nLength; nLength=ntohs((unsigned short)*(U16 *)pBuf); pBuf+=2; pAttr->nValLen=nLength; pAttr->pVal=pBuf; pBuf+=nLength; return ERROR_OK; } vs. a n-digit ASCII length (NOT CODE, not even pseudo-c): // assumes enough incoming buffer to hold entire name and ValLen fields // requires external help to deal with long or multiple values int GrabAttr(ATTR *pAttr) { // str functions don't work because we aren't null-terminated so we normalize all input buffers? (null terminate ... ?) // or just write our own strtok? strtok(ON A COPY of the string) // so we can remember the terminating char, either or ... pAttr->pName=pToken; pBuf+=strlen(pToken)+1; strtok() pBuf+=strlen(pToken)+1; nLength=private_atoi (because leading 0's would assume octal) pAttr->nValLen=nLength; pAttr->pVal=pBuf; pBuf+=nLength; return pBuf; } int private_atoi(char *) { do it } void normalize() // or private_strtok { do it } Both of these examples will require a bunch of strncmp's in order to actually do anything, because what I've drawn up isn't even as binary as Paul and I had in the SWP documents (even June 6). If you reduce Operation and Attribute names to an enum'd set then all those strcmp's go away and become a simple '==' or even a switch (YES!). I think we need to face reality here... Binary requires significantly less code to deal with, which means less bugs and less testing, which means more solid implementations sooner. (Anybody ever run into a web site that used atoi and interpreted numbers as octal? I was just reading about one last week...). What do we get with ASCII? My list of "pros" from the meeting is really short. The biggest I've been able to identify is vendor extensibility. For extensibility we could reserve the upper 0x8000 (or maybe fewer). In fact, for attributes we could assign the "all ones" enum and have the vendor use the first 4+ bytes of the value as their unique attribute name/ID in order to minimize collisions. Unless someone has parsing for ASCII all worked out and can illustrate that it really isn't much more code, I have to be in the binary camp. IBM's triplets anyone? (Roger?) The following three examples show an encoding of a Print-Job operation with attributes job-name=="Spec" job-originator=="Sylvan", and (a multi-value vendor specific hypothetical attribute) vendorHWP-BLD-ID=="Alpha",32766 In all examples the bytes on the wire are specified in hex (two characters) or ASCII (one character). The spaces between bytes and the line wrapping are not transmitted. {print data} is the actual data for the job and the literal phrase is not transmitted. ----------- Example 1, ASCII (June17): 0 1 0 0 P r i n t - J o b 0d 0a j o b - n a m e 20 4 20 S p e c j o b - o r i g i n a t o r 20 6 20 S y l v a n H W P - B L D - I D 20 5 20 A l p h a 20 5 20 3 2 7 6 6 0d 0a {print data} ----------- Example 2, ASCII with binary (version is fixed) lengths: 0 1 0 0 00 09 P r i n t - J o b 00 08 j o b - n a m e 00 04 S p e c 00 0e j o b - o r i g i n a t o r 00 06 S y l v a n 00 0a H W P - B L D - I D 00 05 A l p h a 00 00 00 05 3 2 7 6 6 {print data} ----------- Example 3, binary (SWP, IBM's triplets...) (extra spaces, line wraps, and comments added for clarity): 00 01 00 00 ; version 01.00 00 01 ; Print-Job 00 01 ; job-name 00 04 S p e c ; length and value 00 02 ; job-originator 00 06 S y l v a n ; length and value ff ff ; vendor--see 4+ bytes of value 00 0a H W P - B L D - I D ; length and value1 00 00 ; additional value for prev attribute 00 05 A l p h a ; length and value2 00 00 ; additional value 00 02 7f fe ; length and value3 {print data} ----------- Going from example1 to example2 eliminates scanning and tokenizing. Going from example2 to example3 eliminates strcmp's to match names of attributes and operations. I vote to go all binary, eg. #3. (Note though, that I encoded the HP attribute name in ASCII whereas in real life I'd probably pick more like: H W P xx yy zz where hex yyzz would increment but the rest would remain static for all the attributes that I create. I probably wouldn't do the multi-valued attribute either, rather I'd just append onto the first value since the prefix length is fixed.) I apologize for having to do this, but evidently my implementor hat wasn't fitting very well on June 17th. Thanks for your attention, sdb | Sylvan Butler | sbutler@boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 | From ipp-archive Thu Jun 19 21:44:49 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA25900 for ipp-outgoing; Thu, 19 Jun 1997 21:44:18 -0400 (EDT) Date: Thu, 19 Jun 1997 18:38:55 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706200138.SAA10522@woden.eng.sun.com> To: SBUTLER@hpbs2024.boi.hp.com Subject: Re: IPP>PRO: sorry, but binary is better Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Here is my version of GrabAttr for the protocol we chose on June 17th. I think that it is competitive with the function you defined for the binary protocol. Also, my ANSI C book states that atoi assumes decimal, but recommends using strtol as I have done below. int GrabAttr(ATTR *pAttr) { char * pNext; int length; pNext = strchr(pBuf,' '); pAttr->nNameLength = pNext-pBuf; pAttr->pName = pBuf pBuf = pNext + 1; length = strtol(pBuf,&pNext,10); /* ANSI C function */ pAttr->nValLen = length; pNext++; pAttr->pVal = pNext; pBuf = pNext + length; return ERROR_OK } As for wanting integer tokens for internal processing of keywords, I would expect than an implementation might have a keywordToInt function which would map keywords to integers that in turn could be used in switch statements. So the strncmp/hashing issues would be kept in the keywordToInt function. Comments? Bob Herriot > From SBUTLER@hpbs2024.boi.hp.com Thu Jun 19 18:06:36 1997 > > I just sent this to the IPP reflector, but forgot to put the CC in to > you folk. It appears customery to address changes to the most > recent active participants, and I thought you deserved a heads-up. > > I believe I gathered correct e-mail addresses for all attendees on > June17th, please forward on to anyone that should see it directly > rather than the reflector copy. > > ------- Forwarded Message Follows ------- > > I'm sorry for the length of this missive (about 150 lines plus > headers...) but it seems necessary. > > Last night I revised Paul's document to indicate what we had concluded > on the 17th, and this morning I woke up way too early... Or perhaps it > was way too late, depending on your perspective. > > A binary encoding is MUCH simpler. Even if limited to just the lengths. > For example, with 16-bit binary lengths (FAIRLY COMPLETE CODE): > > // assumes enough incoming buffer to hold entire name and ValLen fields > // requires external help to deal with long or multiple values > int GrabAttr(ATTR *pAttr) > { > nLength=ntohs((unsigned short)*(U16 *)pBuf); > pBuf+=2; > pAttr->nNameLength=nLength; > pAttr->pName=pBuf; > pBuf+=nLength; > nLength=ntohs((unsigned short)*(U16 *)pBuf); > pBuf+=2; > pAttr->nValLen=nLength; > pAttr->pVal=pBuf; > pBuf+=nLength; > return ERROR_OK; > } > > vs. a n-digit ASCII length (NOT CODE, not even pseudo-c): > > // assumes enough incoming buffer to hold entire name and ValLen fields > // requires external help to deal with long or multiple values > int GrabAttr(ATTR *pAttr) > { > // str functions don't work because we aren't null-terminated > so we normalize all input buffers? (null terminate ... ?) > // or just write our own strtok? > strtok(ON A COPY of the string) > // so we can remember the terminating char, either or ... > pAttr->pName=pToken; > pBuf+=strlen(pToken)+1; > strtok() > pBuf+=strlen(pToken)+1; > nLength=private_atoi (because leading 0's would assume octal) > pAttr->nValLen=nLength; > pAttr->pVal=pBuf; > pBuf+=nLength; > return pBuf; > } > int private_atoi(char *) > { > do it > } > void normalize() // or private_strtok > { > do it > } > > Both of these examples will require a bunch of strncmp's in order to > actually do anything, because what I've drawn up isn't even as binary > as Paul and I had in the SWP documents (even June 6). If you reduce > Operation and Attribute names to an enum'd set then all those strcmp's > go away and become a simple '==' or even a switch (YES!). > > I think we need to face reality here... Binary requires significantly > less code to deal with, which means less bugs and less testing, which > means more solid implementations sooner. (Anybody ever run into a web > site that used atoi and interpreted numbers as octal? I was just reading > about one last week...). What do we get with ASCII? My list of "pros" > from the meeting is really short. The biggest I've been able to > identify is vendor extensibility. > > For extensibility we could reserve the upper 0x8000 (or maybe fewer). > In fact, for attributes we could assign the "all ones" enum and have the > vendor use the first 4+ bytes of the value as their unique attribute > name/ID in order to minimize collisions. > > Unless someone has parsing for ASCII all worked out and can illustrate > that it really isn't much more code, I have to be in the binary camp. > IBM's triplets anyone? (Roger?) > > The following three examples show an encoding of a > Print-Job operation with attributes > job-name=="Spec" > job-originator=="Sylvan", and > (a multi-value vendor specific hypothetical attribute) > vendorHWP-BLD-ID=="Alpha",32766 > > In all examples the bytes on the wire are specified in hex (two > characters) or ASCII (one character). The spaces between bytes and the > line wrapping are not transmitted. {print data} is the actual data for > the job and the literal phrase is not transmitted. > > ----------- > Example 1, ASCII (June17): > > 0 1 0 0 P r i n t - J o b 0d 0a > j o b - n a m e 20 4 20 S p e c j o b - o r i g i n a > t o r 20 6 20 S y l v a n H W P - B L D - I D 20 5 20 A > l p h a 20 5 20 3 2 7 6 6 0d 0a > {print data} > > ----------- > Example 2, ASCII with binary (version is fixed) lengths: > > 0 1 0 0 00 09 P r i n t - J o b 00 08 > j o b - n a m e 00 04 S p e c 00 0e j o b - o r i g i n > a t o r 00 06 S y l v a n 00 0a H W P - B L D - I D 00 05 > A l p h a 00 00 00 05 3 2 7 6 6 > {print data} > > ----------- > Example 3, binary (SWP, IBM's triplets...) > (extra spaces, line wraps, and comments added for clarity): > > 00 01 00 00 ; version 01.00 > 00 01 ; Print-Job > 00 01 ; job-name > 00 04 S p e c ; length and value > 00 02 ; job-originator > 00 06 S y l v a n ; length and value > ff ff ; vendor--see 4+ bytes of value > 00 0a H W P - B L D - I D ; length and value1 > 00 00 ; additional value for prev attribute > 00 05 A l p h a ; length and value2 > 00 00 ; additional value > 00 02 7f fe ; length and value3 > {print data} > > ----------- > > Going from example1 to example2 eliminates scanning and tokenizing. > > Going from example2 to example3 eliminates strcmp's to match names > of attributes and operations. > > I vote to go all binary, eg. #3. (Note though, that I encoded the HP > attribute name in ASCII whereas in real life I'd probably pick more like: > H W P xx yy zz > where hex yyzz would increment but the rest would remain static for all > the attributes that I create. I probably wouldn't do the multi-valued > attribute either, rather I'd just append onto the first value since the > prefix length is fixed.) > > I apologize for having to do this, but evidently my implementor hat > wasn't fitting very well on June 17th. > > Thanks for your attention, > > sdb > > | Sylvan Butler | sbutler@boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 | > From ipp-archive Thu Jun 19 23:04:49 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA26611 for ipp-outgoing; Thu, 19 Jun 1997 23:04:37 -0400 (EDT) Message-ID: <33A9F498.5A33D6B@sharplabs.com> Date: Thu, 19 Jun 1997 20:10:16 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP>PRO: sorry, binary is better (?) X-Priority: 3 (Normal) References: <199706200138.SAA10522@woden.eng.sun.com> Content-Type: multipart/mixed; boundary="------------60E2218BCDA1D1AA31F6DF91" Sender: ipp-owner@pwg.org Precedence: bulk This is a multi-part message in MIME format. --------------60E2218BCDA1D1AA31F6DF91 Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The attached code will handle free-form input of the tokens wherein you can have as much whitespace between tokens as you want (not limited to just 1 space character between tokens.). And I'm not even using any runtime library routines, just the 'isspace' macro from ctype.h. And I provided a null character at the end of the attribute name for doing subsequent string handling functions on the attribute name if you need to. This stuff is really too easy and we shouldn't worry about the differences between ASCII and binary at this point. The code difference is trivial. I thought we have already made this decision? Randy Robert Herriot wrote: > Here is my version of GrabAttr for the protocol we chose on June 17th. > > I think that it is competitive with the function you defined for the > binary protocol. Also, my ANSI C book states that atoi assumes > decimal, but > recommends using strtol as I have done below. > > int GrabAttr(ATTR *pAttr) > { > char * pNext; > int length; > > pNext = strchr(pBuf,' '); > pAttr->nNameLength = pNext-pBuf; > pAttr->pName = pBuf > pBuf = pNext + 1; > > length = strtol(pBuf,&pNext,10); /* ANSI C function */ > pAttr->nValLen = length; > pNext++; > pAttr->pVal = pNext; > pBuf = pNext + length; > return ERROR_OK > } > > As for wanting integer tokens for internal processing of keywords, I > would expect than an implementation might have a keywordToInt function > > which would map keywords to integers that in turn could be used in > switch statements. So the strncmp/hashing issues would be kept in > the keywordToInt function. > > Comments? > > Bob Herriot > > > From SBUTLER@hpbs2024.boi.hp.com Thu Jun 19 18:06:36 1997 > > > > I just sent this to the IPP reflector, but forgot to put the CC in > to > > you folk. It appears customery to address changes to the most > > recent active participants, and I thought you deserved a heads-up. > > > > I believe I gathered correct e-mail addresses for all attendees on > > June17th, please forward on to anyone that should see it directly > > rather than the reflector copy. > > > > ------- Forwarded Message Follows ------- > > > > I'm sorry for the length of this missive (about 150 lines plus > > headers...) but it seems necessary. > > > > Last night I revised Paul's document to indicate what we had > concluded > > on the 17th, and this morning I woke up way too early... Or perhaps > it > > was way too late, depending on your perspective. > > > > A binary encoding is MUCH simpler. Even if limited to just the > lengths. > > For example, with 16-bit binary lengths (FAIRLY COMPLETE CODE): > > > > // assumes enough incoming buffer to hold entire name and ValLen > fields > > // requires external help to deal with long or multiple values > > int GrabAttr(ATTR *pAttr) > > { > > nLength=ntohs((unsigned short)*(U16 *)pBuf); > > pBuf+=2; > > pAttr->nNameLength=nLength; > > pAttr->pName=pBuf; > > pBuf+=nLength; > > nLength=ntohs((unsigned short)*(U16 *)pBuf); > > pBuf+=2; > > pAttr->nValLen=nLength; > > pAttr->pVal=pBuf; > > pBuf+=nLength; > > return ERROR_OK; > > } > > > > vs. a n-digit ASCII length (NOT CODE, not even pseudo-c): > > > > // assumes enough incoming buffer to hold entire name and ValLen > fields > > // requires external help to deal with long or multiple values > > int GrabAttr(ATTR *pAttr) > > { > > // str functions don't work because we aren't null-terminated > > so we normalize all input buffers? (null terminate ... ?) > > // or just write our own strtok? > > strtok(ON A COPY of the string) > > // so we can remember the terminating char, either or > ... > > pAttr->pName=pToken; > > pBuf+=strlen(pToken)+1; > > strtok() > > pBuf+=strlen(pToken)+1; > > nLength=private_atoi (because leading 0's would assume octal) > > pAttr->nValLen=nLength; > > pAttr->pVal=pBuf; > > pBuf+=nLength; > > return pBuf; > > } > > int private_atoi(char *) > > { > > do it > > } > > void normalize() // or private_strtok > > { > > do it > > } > > > > Both of these examples will require a bunch of strncmp's in order to > > > actually do anything, because what I've drawn up isn't even as > binary > > as Paul and I had in the SWP documents (even June 6). If you reduce > > > Operation and Attribute names to an enum'd set then all those > strcmp's > > go away and become a simple '==' or even a switch (YES!). > > > > I think we need to face reality here... Binary requires > significantly > > less code to deal with, which means less bugs and less testing, > which > > means more solid implementations sooner. (Anybody ever run into a > web > > site that used atoi and interpreted numbers as octal? I was just > reading > > about one last week...). What do we get with ASCII? My list of > "pros" > > from the meeting is really short. The biggest I've been able to > > identify is vendor extensibility. > > > > For extensibility we could reserve the upper 0x8000 (or maybe > fewer). > > In fact, for attributes we could assign the "all ones" enum and have > the > > vendor use the first 4+ bytes of the value as their unique attribute > > > name/ID in order to minimize collisions. > > > > Unless someone has parsing for ASCII all worked out and can > illustrate > > that it really isn't much more code, I have to be in the binary > camp. > > IBM's triplets anyone? (Roger?) > > > > The following three examples show an encoding of a > > Print-Job operation with attributes > > job-name=="Spec" > > job-originator=="Sylvan", and > > (a multi-value vendor specific hypothetical attribute) > > vendorHWP-BLD-ID=="Alpha",32766 > > > > In all examples the bytes on the wire are specified in hex (two > > characters) or ASCII (one character). The spaces between bytes and > the > > line wrapping are not transmitted. {print data} is the actual data > for > > the job and the literal phrase is not transmitted. > > > > ----------- > > Example 1, ASCII (June17): > > > > 0 1 0 0 P r i n t - J o b 0d 0a > > j o b - n a m e 20 4 20 S p e c j o b - o r i > g i n a > > t o r 20 6 20 S y l v a n H W P - B L D - I D > 20 5 20 A > > l p h a 20 5 20 3 2 7 6 6 0d 0a > > {print data} > > > > ----------- > > Example 2, ASCII with binary (version is fixed) lengths: > > > > 0 1 0 0 00 09 P r i n t - J o b 00 08 > > j o b - n a m e 00 04 S p e c 00 0e j o b - o r > i g i n > > a t o r 00 06 S y l v a n 00 0a H W P - B L D - > I D 00 05 > > A l p h a 00 00 00 05 3 2 7 6 6 > > {print data} > > > > ----------- > > Example 3, binary (SWP, IBM's triplets...) > > (extra spaces, line wraps, and comments added for clarity): > > > > 00 01 00 00 ; version 01.00 > > 00 01 ; Print-Job > > 00 01 ; job-name > > 00 04 S p e c ; length and value > > 00 02 ; job-originator > > 00 06 S y l v a n ; length and value > > ff ff ; vendor--see 4+ bytes of > value > > 00 0a H W P - B L D - I D ; length and value1 > > 00 00 ; additional value for prev > attribute > > 00 05 A l p h a ; length and value2 > > 00 00 ; additional value > > 00 02 7f fe ; length and value3 > > {print data} > > > > ----------- > > > > Going from example1 to example2 eliminates scanning and tokenizing. > > > > Going from example2 to example3 eliminates strcmp's to match names > > of attributes and operations. > > > > I vote to go all binary, eg. #3. (Note though, that I encoded the > HP > > attribute name in ASCII whereas in real life I'd probably pick more > like: > > H W P xx yy zz > > where hex yyzz would increment but the rest would remain static for > all > > the attributes that I create. I probably wouldn't do the > multi-valued > > attribute either, rather I'd just append onto the first value since > the > > prefix length is fixed.) > > > > I apologize for having to do this, but evidently my implementor hat > > wasn't fitting very well on June 17th. > > > > Thanks for your attention, > > > > sdb > > > > | Sylvan Butler | sbutler@boi.hp.com | AreaCode 208 Phone/TelNet > 396-2282 | > > --------------60E2218BCDA1D1AA31F6DF91 Content-Type: text/plain; charset=us-ascii; name="ippexam.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ippexam.txt" You have to have tokenizing capability in an implementation anyway, to support the HTTP headers and chunking... typedef struct { char *attrName; int attrLength; char *attrValue; } ATTR; /* Most optimizing compilers would attempt to inline the next_delim/next_token functions for performance */ char *next_delim(char *stream) { while (!isspace(*stream)) ++stream; return(stream); } char *next_token(char *stream) { while (isspace(*stream)) ++ stream; return(stream); } /* This routine assumes that the current position in the input or buffer stream is placed at the first character of the attribute name */ int GrabAttr(ATTR *pAttr, char *inpstream) { int sts = OK; pAttr->attrName = inpstream; inpstream = next_delim(inpstream); *inpstream++ = '\0'; inpstream = next_token(inpstream); for (pAttr->attrLength = 0; (isdigit(*inpstream)); inpstream++) pAttr->attrLength = (pAttr->pAttrLength * 10) + (*inpstream -'0'); pAttr->attrValue = next_token(inpstream); return(sts); } --------------60E2218BCDA1D1AA31F6DF91-- From ipp-archive Fri Jun 20 11:09:57 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA28145 for ipp-outgoing; Fri, 20 Jun 1997 11:08:15 -0400 (EDT) Date: Fri, 20 Jun 1997 11:04:32 -0400 (EDT) From: JK Martin Message-Id: <199706201504.LAA04580@uscore.underscore.com> To: hastings@cp10.es.xerox.com Subject: Re: IPP> MOD - The Get-Jobs operation and completed/canceled/aborted jobs Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk This is the kind of request that makes some people believe IPP is "too fat", IMHO, and that IPP tends to represent "DPA Lite". Microsoft and others repeatedly stated that GUI application issues such as viewing job status should be handled via standard web page interfaces, where the designer of the web page decides what information and options to provide the user. Also, after reading your message, I now know why Harry Lewis is so upset about the apparent disregard for the Job MIB and Printer MIBs in the overall IPP universe. If a GUI application wants a multi-programmatic way to acquire a list of jobs, why not just use the Job MIB? If instead you want a job listing "over the Internet", why don't you just point your browser to the appropriate URL and click away? ...jay ----- Begin Included Message ----- >From ipp-owner@pwg.org Thu Jun 19 20:04 EDT 1997 Date: Thu, 19 Jun 1997 16:55:30 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - The Get-Jobs operation and completed/canceled/aborted jobs Bob Herriot and I were talking about the agreement at the 6/17 PRO meeting to remove the filter from the Get-Jobs operation. We think that the order that jobs are returned should be specified as something like: The order of jobs in the Get-Jobs Response SHALL be the oldest to newest with respect to completion time (either actual or expected), irrespective of job state. The problem that remains, is that this means that the 'completed' jobs come back first, which are usually the least interesting, though valuable to obtain in some cases. A good GUI interface should scroll off most of the completed jobs and show a few of the recently completed jobs followed by the processing and pending jobs. However, that is a fair amount of work. If we leave the specification as always returning all jobs, some providers will discover that clients aren't doing anything user-friendly with the results when the provider keeps a lot of completed jobs around for status or tracking. Then these providers will abandon keeping completed jobs around, so that they don't look bad to users using clients that don't do good things with the completed jobs that come back first. So we propose to add a "return-completed-jobs" input parameter to Get-Jobs with the following values: 'first' - return 'completed', 'canceled', and 'aborted' jobs in order of actual completion followed by 'pending', 'pending-held', 'processing', and 'processing-stopped' jobs in order of expected completion. 'last' - return 'pending', 'pending-held', 'processing', and 'processing-stopped' jobs in order of expected completion followed by 'completed', 'canceled', and 'aborted' jobs in order of actual completion. 'never' - do not return 'completed', 'canceled', and 'aborted' jobs at all. The default value for this input-parameter SHALL be 'never'. Comments? Tom and Bob ----- End Included Message ----- From ipp-archive Fri Jun 20 11:49:57 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA28672 for ipp-outgoing; Fri, 20 Jun 1997 11:49:41 -0400 (EDT) Message-ID: From: "Sylvan Butler" X-Real-Sender: SYLVAN Organization: Hewlett-Packard, Boise To: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Date: Fri, 20 Jun 1997 09:49:24 -0700 Subject: Re: IPP>PRO: sorry, but binary is better CC: ipp@pwg.org Priority: normal X-mailer: Pegasus Mail v3.31 Sender: ipp-owner@pwg.org Precedence: bulk Bob Herriot wrote: >binary protocol. Also, my ANSI C book states that atoi assumes decimal, but >recommends using strtol as I have done below. Ahh, yes. How did I miss that... >int GrabAttr(ATTR *pAttr) >{ > char * pNext; > int length; > > pNext = strchr(pBuf,' '); Probably safe given my initial assumption that the buffer would hold the entire name... But hard for the upper layer to validate. > pAttr->nNameLength = pNext-pBuf; > pAttr->pName = pBuf > pBuf = pNext + 1; > > length = strtol(pBuf,&pNext,10); /* ANSI C function */ Doh! Hardcoding the base. I missed that one. Again, we have the potentially hard to verify issue of searching forward. > pAttr->nValLen = length; > pNext++; > pAttr->pVal = pNext; > pBuf = pNext + length; > return ERROR_OK >} Looks good, better than I expected. I am concerned with how the upper layer can validate the assumption that the delimiters will be in the buffer for this lower layer. A "pure" text (with max line lengths defined, CRLF endings, etc) can read until it gets the entire line (or declare an error when the line is found to be too long) and know it has the whole thing. With unknown line lengths it is risky to assume that without verification. With the binary lengths the GrabAttr doesn't loop searching for anything and the layer above can compare lengths with the len of data in the buffer to verify that all is well. >would expect than an implementation might have a keywordToInt function >which would map keywords to integers that in turn could be used in Of course, but remind me again, what does an implementation gain by having such a function as opposed to just communicating in binary? >> From SBUTLER@hpbs2024.boi.hp.com Thu Jun 19 18:06:36 1997 ... >> What do we get with ASCII? My list of "pros" >> from the meeting is really short. The biggest I've been able to >> identify is vendor extensibility. [proposal, examples, etc. deleted] sdb | Sylvan Butler | sbutler@boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 | From ipp-archive Fri Jun 20 11:54:57 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA28687 for ipp-outgoing; Fri, 20 Jun 1997 11:50:49 -0400 (EDT) Message-ID: From: "Sylvan Butler" X-Real-Sender: SYLVAN Organization: Hewlett-Packard, Boise To: ipp@pwg.org Date: Fri, 20 Jun 1997 09:50:40 -0700 Subject: Re: IPP>PRO: sorry, but binary is better Priority: normal X-mailer: Pegasus Mail v3.31 Sender: ipp-owner@pwg.org Precedence: bulk Bob Herriot wrote: >binary protocol. Also, my ANSI C book states that atoi assumes decimal, but >recommends using strtol as I have done below. Ahh, yes. How did I miss that... >int GrabAttr(ATTR *pAttr) >{ > char * pNext; > int length; > > pNext = strchr(pBuf,' '); Probably safe given my initial assumption that the buffer would hold the entire name... But hard for the upper layer to validate. > pAttr->nNameLength = pNext-pBuf; > pAttr->pName = pBuf > pBuf = pNext + 1; > > length = strtol(pBuf,&pNext,10); /* ANSI C function */ Doh! Hardcoding the base. I missed that one. Again, we have the potentially hard to verify issue of searching forward. > pAttr->nValLen = length; > pNext++; > pAttr->pVal = pNext; > pBuf = pNext + length; > return ERROR_OK >} Looks good, better than I expected. I am concerned with how the upper layer can validate the assumption that the delimiters will be in the buffer for this lower layer. A "pure" text (with max line lengths defined, CRLF endings, etc) can read until it gets the entire line (or declare an error when the line is found to be too long) and know it has the whole thing. With unknown line lengths it is risky to assume that without verification. With the binary lengths the GrabAttr doesn't loop searching for anything and the layer above can compare lengths with the len of data in the buffer to verify that all is well. >would expect than an implementation might have a keywordToInt function >which would map keywords to integers that in turn could be used in Of course, but remind me again, what does an implementation gain by having such a function as opposed to just communicating in binary? >> From SBUTLER@hpbs2024.boi.hp.com Thu Jun 19 18:06:36 1997 ... >> What do we get with ASCII? My list of "pros" >> from the meeting is really short. The biggest I've been able to >> identify is vendor extensibility. [proposal, examples, etc. deleted] sdb | Sylvan Butler | sbutler@boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 | From ipp-archive Fri Jun 20 12:19:58 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA29703 for ipp-outgoing; Fri, 20 Jun 1997 12:19:04 -0400 (EDT) Message-ID: From: "Sylvan Butler" X-Real-Sender: SYLVAN Organization: Hewlett-Packard, Boise To: ipp@pwg.org Date: Fri, 20 Jun 1997 10:18:59 -0700 Subject: Re: IPP>PRO: sorry, binary is better (?) Priority: normal X-mailer: Pegasus Mail v3.31 Sender: ipp-owner@pwg.org Precedence: bulk >This stuff is really too easy and we shouldn't worry about the >differences between >ASCII and binary at this point. The code difference is trivial. That is what I was thinking on Tuesday 6/17, but actually doing something with it and covering all the possibilities with ASCII seems noticably more complex to implement and to test, and for no apparent benefit. >I thought we have already made this decision? Those at the meeting, including myself, had arrived at a recommendation for the group. That is why I said "sorry" for opening the issue again. >You have to have tokenizing capability in an implementation anyway, >to support the HTTP headers and chunking... Somewhat different constraints, and conceivably a significantly different part of the system. >typedef struct { > char *attrName; > int attrLength; > char *attrValue; > } ATTR; > >/* Most optimizing compilers would attempt to inline the next_delim/next_token functions for performance */ >char *next_delim(char *stream) >{ > while (!isspace(*stream)) ++stream; > > return(stream); >} > >char *next_token(char *stream) >{ > while (isspace(*stream)) ++ stream; > > return(stream); >} > >/* This routine assumes that the current position in the input or buffer stream is placed at the first character of the attribute name */ > >int GrabAttr(ATTR *pAttr, char *inpstream) >{ > int sts = OK; > > pAttr->attrName = inpstream; > inpstream = next_delim(inpstream); > *inpstream++ = '\0'; > inpstream = next_token(inpstream); I don't think we want to do that. We defined it as one , skipping more will throw us off. Just removing next_token should be fine. > for (pAttr->attrLength = 0; (isdigit(*inpstream)); inpstream++) > pAttr->attrLength = (pAttr->pAttrLength * 10) + (*inpstream -'0'); > pAttr->attrValue = next_token(inpstream); Again. > > return(sts); >} I like that. Very clean. It does have the same concern that Bob's raised, that of validating the assumptions of the buffer containing the next delimiter. It appears much easier to fix in this version however... Like the binary solution, just quit making the assumption. With no library routines then each loop also checks for the end of the data (by count). Both text parsers leave us with the need for doing strcmp's, etc. to match keywords. And for what? sdb | Sylvan Butler | sbutler@boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 | From ipp-archive Fri Jun 20 12:30:01 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA29987 for ipp-outgoing; Fri, 20 Jun 1997 12:26:53 -0400 (EDT) Message-Id: <9706201615.AA00884@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, 20 Jun 1997 09:12:44 PDT To: Robert.Herriot@Eng.Sun.COM (Robert Herriot) From: Tom Hastings Subject: Re: IPP>PRO Minutes of June 17th meeting Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk Great set of minutes! Concise and complete. I have one editorial suggestion for the Protocol document. I like the example that Bob put in the minutes and think that it should be included in the protocol spec. However, we need to make clear that the example is written in ABNF. Then I think we should also show the same example as how it would be printed, since it is printable. We don't want people to think that the double quotes are included on the wire. Also we want people to understand that there are long lines. So I suggest something like: The following is an example of a Print-Job request in ABNF: "0100Print-Job" CRLF "job-name 3 foocopies 1 2document-format 22 application/postscript" "finishings 5 staple 5 punch" CRLF "%!PS" ... The same example printed is (long line is shown wrapped, but there SHALL be no CRLF inserted in the protocol): 0100Print-Job job-name 3 foocopies 1 2document-format 22 application/postscriptfinishings 5 staple 5 punch %!PS" ... The following is an example of a Print-Job response in ABNF: "0100Print-Job-Resp 200000" CRLF "reason-phrase 2 OK job-state 7 pending CRLF The same example printed is: 0100Print-Job-Resp 200000 reason-phrase 2 OK job-state 7 pending Tom From ipp-archive Fri Jun 20 12:39:59 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA00632 for ipp-outgoing; Fri, 20 Jun 1997 12:36:23 -0400 (EDT) From: Keith Carter To: Subject: IPP> PRO and MOD - UPDATE ON STATUS CODE KEYWORDS IN THE MODEL Message-Id: <5040300002420119000002L092*@MHS> Date: Fri, 20 Jun 1997 12:37:36 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk Dear all, This note contains the following: I. Status Keyword Section for IPP Model Document II. Mapping of HTTP 1.1 Status Codes to IPP Status Keywords III. Status Keywords for IPP Operations IV. Action Items from IPP Protocol Meeting on June 17 V. Issues I believe the most efficient process is to schedule an item on the agenda at the IPP Model meeting on June 25 to review the status keywords, discuss the issues, and make the appropriate changes at that time. Scott, Please add "Review IPP Status Keywords" to the agenda for the IPP Model meeting on June 25. Thanks. Keith I. Status Keywords Section for IPP Model Document -------------------------------------------------- This section contains the status keywords as defined on May 21 with the following changes: 1. Removed successful-attribute-ignored per previous email. 2. Removed server-error-too-many-documents per previous email. 3. Marked status codes defined in the IPP Level 1 doc as (IPPL1). 4. Marked new status keywords as (NEW). 4.3 Status and Message The Status keyword 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 (IPPL1) The request has succeeded. NOTE TO REVIEWERS: IPPL1 only includes OK. IPPL1 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.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 (IPPL1) 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. 4.4.4.4 client-error-forbidden (IPPL1) 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. 4.4.4.6 client-error-timeout (NEW) The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time. 4.4.4.7 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.8 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.9 client-error-request-entity-too-large (IPPL1) 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.10 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.11 client-error-unsupported-media-type (IPPL1) 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.12 client-error-attribute-value-not-supported 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-timeout (NEW) The server did not produce a response within the time that the client was prepared to wait. The client MAY repeat the request without modifications at any later time. 4.4.5.5 server-error-HTTP-version-not-supported (NEW) The server does not support, or refuses to support, the HTTP 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 the version is not supported and what other protocols are supported by that server. 4.4.5.6 server-error-IPP-version-not-supported 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.5.7 server-error-printer-error A printer error, such as a paper jam, occurs while the IPP Printer processes a Print or Send 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.5.8 server-error-write-fault 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 or Send operation. II. Mapping of HTTP 1.1 Status Codes to IPP Status Keywords ----------------------------------------------------------- HTTP 1.1 Status IPP Keyword --------------- ----------- 100 Continue none 101 Switching Protocols none 200 OK successful-OK 201 Created successful-OK 202 Accepted successful-OK 203 Non-Authoritive Information successful-OK 204 No Content successful-OK 205 Reset Content none 206 Partial Content (GET) none 300 Multiple Choices none 301 Moved Permanently none 302 Moved Temporarily none 303 See Other none 304 Not Modified (GET) none 305 Use Proxy none 400 Bad Request client-error-bad-request 401 Unauthorized client-error-unauthorized 402 Payment Required client-error-payment-required 403 Forbidden client-error-forbidden 404 Not Found client-error-not-found 405 Method Not Allowed client-error-method-not-allowed 406 Not Acceptable client-error-bad-request 407 Proxy Authentication Required client-error-unauthorized 408 Request Timeout client-error-timeout 409 Conflict (most likely PUT) client-error-bad-request 410 Gone client-error-gone 411 Length Required client-error-bad-request 412 Precondition Failed client-error-bad-request 413 Request Entity Too Large client-error-request-entity-too-large 414 Request-URI Too Long client-error-request-URI-too-long 415 Unsupported Media Type client-error-unsupported-media-type none client-error-attribute-value-not-supported 500 Internal Server Error server-error-internal-server-error 501 Not Implemented server-error-not-implemented 502 Bad Gateway server-error-internal-server-error 503 Service Unavailable server-error-service-unavailable 504 Gateway Timeout server-error-timeout 505 HTTP Version Not Supported server-error-HTTP-version-not-supported none server-error-IPP-version-not-supported none server-error-printer-error none server-error-write-fault III. Status Keywords for IPP Operations --------------------------------------- PJ = Print-Job, PU = Print-URI, CJ = Create-Job, SD = Send-Document SU = Send-URI, V = Validate, GA = Get-Attributes, GJ = Get-Jobs GO = Get-Operations, C = Cancel-Job IPP Operations IPP Status Keyword PJ PU CJ SD SU V GA GJ GO C ------------------ -- -- -- -- -- - -- -- -- - successful-OK x x x x x x x x x x client-error-bad-request x x x x x x x x x x client-error-unauthorized x x x x x x x x x x client-error-payment-required x x x x x x client-error-forbidden x x x x x x x x x x client-error-not-found x x x x x x x x x x client-error-method-not-allowed x x x x x x x x x x client-error-timeout x x x x x x x x x x client-error-gone x x x x x x x x x x client-error-request-entity-too-large x x client-error-request-URI-too-long x x x x x x x x x x client-error-unsupported-media-type x x x x client-error-attribute-value-not-supported x x x x server-error-internal-server-error x x x x x x x x x x server-error-service-unavailable x x x x x x x x x x server-error-timeout x x x x x x x x x x server-error-HTTP-version-not-supported x x x x x x x x x x server-error-IPP-version-not-supported x x x x x x x x x x server-error-printer-error x x x x x server-error-write-fault x x x x x IV. Action Items from IPP Protocol Meeting on June 17 ------------------------------------------------------ During the protocol meeting on June 17, I took the action item to check the following error conditions: 1. An end-user tries to cancel a job that does not exist. Status code client-error-not-found covers this condition in a Cancel response. 2. An end-user tries to cancel a job which they do not have authority to cancel. Status code client-error-unauthorized covers this condition in a Cancel response. Status client-error-forbidden might also be a possibility (see Issues). 3. An invalid URI syntax is specified on a Print-URI or Send-URI request. Status code client-error-not-found and status code client-error-request-URI-too-long cover this condition. If a server sees that the syntax of the URI is incorrect, the server can return client-error-not-found since that will be the case when an actual "pull" occurs on the URI. I could not find a specific HTTP 1.1 status code for "invalid URI syntax". V. Issues ---------- Let's discuss these issues at the IPP Model meeting on June 25. I listed the issues based on the archive of email on this topic. For each issue, I included who opened the issue by name: and the related comments verbatim (hopefully correctly) of the person listed in () prior to each comment. 1. Bob: Should server-error-printer-error be a defined status? (Bob) I'm not sure if this is a useful error, or even likely to happen. 2. Bob: Should server-error-write-fault be a defined status? (Bob) 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. (Scott) 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. (Bob) Maybe once we have the protocol better defined we will know whether this is a possibility, but I would expect the printer (to) 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. (Tom) 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' on a non-spooled, non-queuing Printer. The Printer shall just temporarily hang the data transfer until the condition gets cleared up. (NOTE: RPC-time out problems, if IPP is ever layered on RPC). 3. Tom: Should we add a value to the "printer-state-reasons" attribute: 'spool-space-full' so that a smart client could tell on a Get-Attributes operation (before it attempts to Print/Send data to a Printer)? 4. Tom: 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. 5. Keith: HTTP 1.1 designates "402 Payment Required" as reserved for future use. Should IPP do the same? 6. Keith: For "405 Method Not Allowed", HTTP 1.1 further states : "The Reponse MUST include an Allow header containing a list of valid methods for the requested resource." Should IPP over HTTP 1.1 support this? 7. Keith: Must decide if client-error-unauthorized or client-error-forbidden should be returned when an end-user tries to cancel a Job that they do not own. 7. Keith: If we re-instate "best-effort", what, if any, changes are required? Reference minutes from IPP Protocol meeting on June 16. 8. Keith: Are there other HTTP 1.1 status codes that should have IPP status keywords? Some candidates are "301 Moved Permanently" and "302 Moved Temporarily" since both require end-user action to approve the redirected URI in the response. See RFC 2068 for more information. **** End of Note **** From ipp-archive Fri Jun 20 12:59:59 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA01276 for ipp-outgoing; Fri, 20 Jun 1997 12:57:49 -0400 (EDT) Date: Fri, 20 Jun 1997 12:51:15 -0400 (EDT) From: JK Martin Message-Id: <199706201651.MAA14930@uscore.underscore.com> To: SBUTLER@hpbs2024.boi.hp.com Subject: Re: IPP>PRO: sorry, binary is better (?) Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk > >This stuff is really too easy and we shouldn't worry about the > >differences between > >ASCII and binary at this point. The code difference is trivial. > > That is what I was thinking on Tuesday 6/17, but actually doing > something with it and covering all the possibilities with ASCII seems > noticably more complex to implement and to test, and for no apparent > benefit. There are many of us (most of us??) who do not believe the statement that "ASCII seems noticably more complex to implement and to test". Furthermore, we do not believe the statement of "for no apparent benefit". Again I must ask: what are we doing in IPP that is fundamentally different than other web-oriented transactions utilizing HTTP? Others have not found a need to degenerate to binary encodings, so why should we? IPP is just printing. It is *not* high volume transaction processing. Staying in a text-only domain leverages the many text-based development tools prevalent in today's web-centric environments that span the entire set of applicable platforms. (Read: fundamentally the same regardless of Wintel vs. Unix) Let's stay with text-only encodings for IPP. ...jay From ipp-archive Fri Jun 20 13:10:24 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA01908 for ipp-outgoing; Fri, 20 Jun 1997 13:08:09 -0400 (EDT) Message-Id: <199706201708.NAA01293@devnix.agranat.com> To: ipp@pwg.org Subject: Re: IPP>PRO: sorry, binary is better (?) In-reply-to: Date: Fri, 20 Jun 1997 13:08:17 -0400 From: "Scott Lawrence" Sender: ipp-owner@pwg.org Precedence: bulk >>>>> "SB" == "Sylvan Butler" writes: SB> That is what I was thinking on Tuesday 6/17, but actually doing SB> something with it and covering all the possibilities with ASCII seems SB> noticably more complex to implement and to test, and for no apparent SB> benefit. I'm sure that the complexity won't be overwhelming :). The benefit is that the protocol is human-readable. Don't discount this too much; you are not going to quickly get vendors of network monitoring equipment deploying versions of thier products that will decode IPP (not until long after you're done, if history is any guide). The first step in debugging any distributed operation is finding out what went over the wire so you can determine who did what (and using the opinion of one end of the wire for this is a good way to go down a lot of dead ends). One other note: when developing any protocol, one always discovers that things you thought would be easy aren't, and often the reverse too. If these discoveries always justify reopening early and fundamental design decisions (good or not so good), then you can end up with a process that goes on for a long long time... -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-archive Fri Jun 20 13:24:59 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA02458 for ipp-outgoing; Fri, 20 Jun 1997 13:24:21 -0400 (EDT) Message-ID: <41135C785691CF11B73B00805FD4D2D702E33190@RED-17-MSG.dns.microsoft.com> From: Paul Moore To: ipp@pwg.org Subject: IPP> Not on mailing list Date: Fri, 20 Jun 1997 09:47:24 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.30) Sender: ipp-owner@pwg.org Precedence: bulk I have just discovered than I am no longer on this mailing list (I have not been for about a month) - I thought it had gone very quiet. I am only getting things explicity cc'd ot 'to' me. How do I get back on? From ipp-archive Fri Jun 20 13:39:59 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA02950 for ipp-outgoing; Fri, 20 Jun 1997 13:35:26 -0400 (EDT) Date: Fri, 20 Jun 1997 13:35:41 -0400 (EDT) From: JK Martin Message-Id: <199706201735.NAA18618@uscore.underscore.com> To: paulmo@microsoft.com Subject: Re: IPP> Not on mailing list Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Paul, We'll add you to the IPP mailing list immediately. If there are any other folks that should added, please let us know. ...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 Fri Jun 20 13:31 EDT 1997 From: Paul Moore To: ipp@pwg.org Subject: IPP> Not on mailing list Date: Fri, 20 Jun 1997 09:47:24 -0700 I have just discovered than I am no longer on this mailing list (I have not been for about a month) - I thought it had gone very quiet. I am only getting things explicity cc'd ot 'to' me. How do I get back on? ----- End Included Message ----- From ipp-archive Fri Jun 20 14:14:59 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA03508 for ipp-outgoing; Fri, 20 Jun 1997 14:13:31 -0400 (EDT) Message-ID: From: "Sylvan Butler" X-Real-Sender: SYLVAN Organization: Hewlett-Packard, Boise To: ipp@pwg.org Date: Fri, 20 Jun 1997 12:13:31 -0700 Subject: Re: IPP>PRO: sorry, binary is better (?) Priority: normal X-mailer: Pegasus Mail v3.31 Sender: ipp-owner@pwg.org Precedence: bulk >"Scott Lawrence" wrote: >Sylvan Butler wrote: >SB> That is what I was thinking on Tuesday 6/17, but actually doing >SB> something with it and covering all the possibilities with ASCII seems >SB> noticably more complex to implement and to test, and for no apparent >SB> benefit. > > I'm sure that the complexity won't be overwhelming :). :) > The benefit is that the protocol is human-readable. Don't discount > this too much; you are not going to quickly get vendors of network > monitoring equipment deploying versions of thier products that will > decode IPP (not until long after you're done, if history is any Probably not. OTOH, when debugging a protocol I usually end up staring at the hex-dump even when ASCII is interspersed. The "readable" dump hides too much information that may be of import. That is probably why there are HTTP servers on the Internet today that don't have the specified line endings. Or maybe this is all just because I spent too much of my early programming years working in binary and hex. :) I generally want the sniffer to decode all the parts that surround what I am developing, but leave my part alone so I see all of what's there and nothing that isn't there, including spaces, nulls, linefeeds, etc. I guess what I am saying, is I haven't found that "human readable" to be very important, and I have seen too many problems caused by trusting "human readable" instead of what the computer sees. ... > One other note: when developing any protocol, one always discovers > that things you thought would be easy aren't, and often the reverse > too. If these discoveries always justify reopening early and > fundamental design decisions (good or not so good), then you can end > up with a process that goes on for a long long time... That's for sure. Though I'd hardly call this one of our "early and fundamental design decisions." The group has been debating this for a very long time. I think the closest we have been to a decision was the minutes from 6/17, or only three days ago. sdb | Sylvan Butler | sbutler@boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 | From ipp-archive Fri Jun 20 14:15:00 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA03519 for ipp-outgoing; Fri, 20 Jun 1997 14:14:54 -0400 (EDT) Message-Id: <9706201812.AA00978@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, 20 Jun 1997 11:09:56 PDT To: JK Martin From: Tom Hastings Subject: Re: IPP> MOD - The Get-Jobs operation and completed/canceled/aborted jobs Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk At 08:04 06/20/97 PDT, JK Martin wrote: >This is the kind of request that makes some people believe IPP is >"too fat", IMHO, and that IPP tends to represent "DPA Lite". Jay, We had agreed at the protocol meeting to remove a lot of fat from Get-Jobs: we removed all filters (see pages 28-29 of IPP Model). So the Job Owner and Job States input parameters are gone. The requester now gets all jobs in all states. This request was to put back the most important capability, namely whether to return completed jobs or not. Yes, a user can get back a list of jobs by getting an HTML page back, but a program can't process HTML. Perhaps you are suggesting that IPP never return completed/canceled/ aborted jobs, and that a program use the Job Monitoring MIB to get back completed/canceled/aborted jobs? By the way, having two protocols (IPP and SNMP Job Monitoring MIB) that get at the same information is not as harmful as you seem to suggest. It gives two views into the same implementation. As long as we make sure there is harmonization of syntax and semantics between the two, then we are giving the application writer the choice of which protocols to use. For example, a driver that uses IPP to submit and cancel, should also be able to use IPP to show the status, instead of being forced to also implement SNMP and the Job Monitoring MIB. Finally, we clarified that the protocol meeting that the IETF needs a MIB for managing the IPP network protocol, e.g., the number of octets passed, the number of octets returned, the number of job acceptances, the number of job rejections, etc., but is not mandating a MIB for the service, such as the Job Monitoring MIB. Tom > >Microsoft and others repeatedly stated that GUI application >issues such as viewing job status should be handled via standard >web page interfaces, where the designer of the web page decides >what information and options to provide the user. > >Also, after reading your message, I now know why Harry Lewis is >so upset about the apparent disregard for the Job MIB and Printer >MIBs in the overall IPP universe. > >If a GUI application wants a multi-programmatic way to acquire a >list of jobs, why not just use the Job MIB? If instead you want >a job listing "over the Internet", why don't you just point your >browser to the appropriate URL and click away? > > ...jay > >----- Begin Included Message ----- > >>From ipp-owner@pwg.org Thu Jun 19 20:04 EDT 1997 >Date: Thu, 19 Jun 1997 16:55:30 PDT >To: ipp@pwg.org >From: Tom Hastings >Subject: IPP> MOD - The Get-Jobs operation and completed/canceled/aborted > jobs > >Bob Herriot and I were talking about the agreement at the 6/17 PRO meeting >to remove the filter from the Get-Jobs operation. We think that the order >that jobs are returned should be specified as something like: > > The order of jobs in the Get-Jobs Response SHALL be the oldest to > newest with respect to completion time (either actual or expected), > irrespective of job state. > >The problem that remains, is that this means that the 'completed' jobs >come back first, which are usually the least interesting, though valuable >to obtain in some cases. A good GUI interface should scroll off most of >the completed jobs and show a few of the recently completed jobs followed >by the processing and pending jobs. However, that is a fair amount of >work. > >If we leave the specification as always returning all jobs, some >providers will discover that clients aren't doing anything user-friendly >with the results when the provider keeps a lot of completed jobs around >for status or tracking. Then these providers will abandon keeping completed >jobs around, so that they don't look bad to users using clients that >don't do good things with the completed jobs that come back first. > >So we propose to add a "return-completed-jobs" input parameter to Get-Jobs with >the following values: > > 'first' - return 'completed', 'canceled', and 'aborted' jobs in order > of actual completion followed by 'pending', 'pending-held', > 'processing', and 'processing-stopped' jobs in order of expected > completion. > 'last' - return 'pending', 'pending-held', 'processing', and > 'processing-stopped' jobs in order of expected completion > followed by 'completed', 'canceled', and 'aborted' jobs in order > of actual completion. > 'never' - do not return 'completed', 'canceled', and 'aborted' jobs at all. > >The default value for this input-parameter SHALL be 'never'. > >Comments? > >Tom and Bob > > > >----- End Included Message ----- > > > From ipp-archive Fri Jun 20 14:19:59 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA03538 for ipp-outgoing; Fri, 20 Jun 1997 14:17:46 -0400 (EDT) Message-Id: <199706201817.OAA03533@lists.underscore.com> Date: Fri, 20 Jun 97 12:13:43 MDT From: "steve gebert Dept:ecg SN:579517 Div:ISM Ext" To: ipp@pwg.org Subject: IPP> Encoding Sender: ipp-owner@pwg.org Precedence: bulk I agree with Scott and Jay regarding the use of text-only encoding. Steve Gebert From ipp-archive Fri Jun 20 14:50:00 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA05214 for ipp-outgoing; Fri, 20 Jun 1997 14:46:45 -0400 (EDT) Date: Fri, 20 Jun 1997 14:43:34 -0400 (EDT) From: JK Martin Message-Id: <199706201843.OAA24026@uscore.underscore.com> To: hastings@cp10.es.xerox.com Subject: Re: IPP> MOD - The Get-Jobs operation and completed/canceled/aborted jobs Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Tom, > Yes, a user can get back a list of jobs by getting an HTML page back, > but a program can't process HTML. I can see you've missed my point entirely. (Sigh) A strong contingent within the IPP group (namely, Microsoft, HP, Lexmark and others) have long claimed that IPP should be maximally used with browser-based techniques, and not native platform GUI applications. In other words, those folks don't want to focus the use of IPP with native GUI apps, but rather leverage HTML and web pages pointing to Internet-capable "printers". I don't really wish to dwell on this issue, Tom. If you still don't understand what I mean, then let's discuss it offline. > By the way, having two protocols (IPP and SNMP Job Monitoring MIB) that > get at the same information is not as harmful as you seem to suggest. Harmful??? Again, you miss the point. 'Nuff said. ...jay From ipp-archive Fri Jun 20 15:20:00 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA05758 for ipp-outgoing; Fri, 20 Jun 1997 15:18:15 -0400 (EDT) From: jeff@boulder.qms.com (Jeff Copeland) Message-Id: <9706201918.AA04636@boulder.qms.com> Subject: IPP> ADM - Web pages To: ipp@pwg.org Date: Fri, 20 Jun 1997 13:18:31 -0600 (MDT) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: ipp-owner@pwg.org Precedence: bulk At the protocol meeting on Tuesday, Sylvan Butler observed that he was having trouble finding the Simple Web Printing document from the Web page. I'm at a loss about how to fix this: I can see it, but that doesn't mean anything because I put the pages together. On the expectation that if one person is having problems, others are too, I'm soliciting suggestions about how to re-arrange the main IPP web page so that our working documents are more obvious. As tempting as it may be, we can't do something as obvious as putting a blinking "Microsoft" label next to the SWP item, lest we run afoul of the IETF rules on company names. Feel free to buttonhole me in Nashua next week to give me suggestions, or send me private e-mail. -- 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 Fri Jun 20 15:50:01 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA06671 for ipp-outgoing; Fri, 20 Jun 1997 15:49:56 -0400 (EDT) Message-Id: <199706201948.MAA13764@scv2.apple.com> Subject: Re: IPP> Encoding Date: Fri, 20 Jun 97 12:50:10 -0700 x-sender: brian@mail.apple.com x-mailer: Claris Emailer 1.1 From: Brian Grimshaw To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: ipp-owner@pwg.org Precedence: bulk I also prefer the proposed text encoding. I do not see anything new in this post June 17 discussion -- just a repeat of previous issues and opinions. What I've extracted from the recent mail is: 1) Parsing text encoding difficult and error prone. - ascii to binary conversion - string compares to interpret attribute names I don't see text encoding as difficult or risky. Any product I'm planning IPP support for already does these things. 2) Text encoding has no apparent benefit. I think this is just an opinion that the text encoding benefits offered are not compelling to everyone. In itself, this is not a benefit of binary encoding. 3) Text encoding makes for easier client/server debug. I agree that this is a --small-- benefit. 4) Text based encoding leverages tools of HTTP solutions. I think this is a fairly neutral statement. It simply justifies the position that handling ascii encoding is not difficult nor uncommon. And from June 17: 5) No endian issues with text encoding. I see this as another --small-- benefit. I would add to the list: 6) Text encoding of attributes simplifies management of extensions -- both vendor extensions and future IPP versions. This eliminates the maintenance of a mapping of names to numbers. Unless there is a problem caused by text encoding, which I do not see, I prefer it and the associated few benefits. I am more concerned that the proposed protocol (whether binary or text encoded) does not seem to allow representing a set of attributes, or a hierarchy of attributes -- without a parser having knowledge of all attributes. While encoding the type in the protocol has been raised as a solution to this, I think types do not model sets very well and this should be treated as a separate issue. This could be handled in the protocol and, minimally, there should an accommodation for future extensions that may allow this without breaking parsers of IPP 1.0. If I am wrong about this, can someone tell me how to do it with the proposed protocol or where in the various documents this is described? Brian -------------------- Brian Grimshaw Apple Computer, Inc. brian@apple.com From ipp-archive Fri Jun 20 16:05:01 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA07160 for ipp-outgoing; Fri, 20 Jun 1997 16:00:03 -0400 (EDT) Message-ID: From: "Sylvan Butler" X-Real-Sender: SYLVAN Organization: Hewlett-Packard, Boise To: JK Martin Date: Fri, 20 Jun 1997 14:00:01 -0700 Subject: Re: IPP>PRO: sorry, binary is better (?) CC: ipp@pwg.org Priority: normal X-mailer: Pegasus Mail v3.31 Sender: ipp-owner@pwg.org Precedence: bulk >> That is what I was thinking on Tuesday 6/17, but actually doing >> something with it and covering all the possibilities with ASCII seems >> noticably more complex to implement and to test, and for no apparent >> benefit. > >There are many of us (most of us??) who do not believe the statement >that "ASCII seems noticably more complex to implement and to test". When there is more code containing more loops and more conditionals the testing of that code is more complex. >Furthermore, we do not believe the statement of "for no apparent >benefit". Let's discuss these benefits. I suggest a thread with "benefits of ASCII" in the subject line, but this thread will probably suffice. >Again I must ask: what are we doing in IPP that is fundamentally >different than other web-oriented transactions utilizing HTTP? Others HTTP is used to transfer a lot of binary material (primarily, according to the stats on a small proxy cache I run). We are primarily binary material. >have not found a need to degenerate to binary encodings, so why should "degenerate"? What is the term for that rhetorical technique... >Staying in a text-only domain leverages the many text-based development >tools prevalent in today's web-centric environments that span the Good. I like that benefit. I can see how it might be important. Will those tools deal with precise delimiters in specific quantities, combined with length-preceded chunks of binary data which may contain various delimiters (as defined by 6/17)? And those same tools are unable to deal with binary encodings? sdb | Sylvan Butler | sbutler@boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 | From ipp-archive Fri Jun 20 16:15:01 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA07659 for ipp-outgoing; Fri, 20 Jun 1997 16:10:50 -0400 (EDT) Date: Fri, 20 Jun 1997 13:12:04 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706202012.NAA11487@woden.eng.sun.com> To: ipp@pwg.org, brian@apple.com Subject: Re: IPP> Encoding X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Sets of n values are represented by a sequence of parameters whose parameter name is omitted for parameters 2 through n. In the example in the minutes: "0100Print-Job" CRLF "job-name 3 foocopies 1 2document-format 22 application/postscript" "finishings 5 staple 5 punch" CRLF "%!PS finishings is a set consisting of "staple" and "punch". I hope this example helps. Bob Herriot > From brian@apple.com Fri Jun 20 12:58:19 1997 > I am more concerned that the proposed protocol (whether binary or text > encoded) does not seem to allow representing a set of attributes, or a > hierarchy of attributes -- without a parser having knowledge of all > attributes. While encoding the type in the protocol has been raised as a > solution to this, I think types do not model sets very well and this > should be treated as a separate issue. This could be handled in the > protocol and, minimally, there should an accommodation for future > extensions that may allow this without breaking parsers of IPP 1.0. > > If I am wrong about this, can someone tell me how to do it with the > proposed protocol or where in the various documents this is described? > From ipp-archive Fri Jun 20 17:10:22 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA08255 for ipp-outgoing; Fri, 20 Jun 1997 17:06:14 -0400 (EDT) Message-Id: <199706202106.OAA17758@scv4.apple.com> Subject: Re: IPP> Encoding Date: Fri, 20 Jun 97 14:06:27 -0700 x-sender: brian@mail.apple.com x-mailer: Claris Emailer 1.1 From: Brian Grimshaw To: "Robert Herriot" , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: ipp-owner@pwg.org Precedence: bulk Bob, I think I was unclear in my question. The proposed protocol allows for multiple values to be associated with an attribute (as in your finishings example) which is, indeed, a "set". I am asking for the ability to represent a grouping of attributes, as in a much earlier example of two addresses, like "job owner address" and "delivery address". Another example may be grouping of communications parameters. If a server knows these attributes, that's OK -- it then knows to parse the opaque value as an ipp-attribute set. If it doesn't know the attribute, then it's unable to parse the "contained" attributes -- street, city, zip, etc. I'm looking for this capability without the explicit encoding of types and without requiring the parser to know all the attributes. I think this is much simpler than a complete solution to type encoding and, while types COULD be leveraged to solve this problem, they are primarily an orthogonal concept. Brian >Sets of n values are represented by a sequence of parameters whose >parameter name is omitted for parameters 2 through n. > >In the example in the minutes: > > "0100Print-Job" CRLF > "job-name 3 foocopies 1 2document-format 22 application/postscript" > "finishings 5 staple 5 punch" CRLF > "%!PS > >finishings is a set consisting of "staple" and "punch". > >I hope this example helps. > >Bob Herriot > >> From brian@apple.com Fri Jun 20 12:58:19 1997 >> I am more concerned that the proposed protocol (whether binary or text >> encoded) does not seem to allow representing a set of attributes, or a >> hierarchy of attributes -- without a parser having knowledge of all >> attributes. While encoding the type in the protocol has been raised as a >> solution to this, I think types do not model sets very well and this >> should be treated as a separate issue. This could be handled in the >> protocol and, minimally, there should an accommodation for future >> extensions that may allow this without breaking parsers of IPP 1.0. >> >> If I am wrong about this, can someone tell me how to do it with the >> proposed protocol or where in the various documents this is described? >> From ipp-archive Fri Jun 20 17:45:02 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA08928 for ipp-outgoing; Fri, 20 Jun 1997 17:44:25 -0400 (EDT) Date: Fri, 20 Jun 1997 14:38:54 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706202138.OAA11535@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, SBUTLER@hpbs2024.boi.hp.com Subject: Re: IPP>PRO: sorry, but binary is better Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk You raise an important issue about a buffer that may contain only a partial parameter (attribute) but I come to a very different conclusion as I explain below. I think that the 'name ":" value CRLF' may again be the simplest solution from an implementation stand point, even though we keep rejecting it. The reason lies with the way the buffers align with parameters (attributes). This buffer problem exists for both the current IPP proposal and for the previous binary proposal that you prefer. The two byte binary integer could span buffers and a parameter name or value buffer could span buffers. Similar spans could occur with the current IPP protocol proposal. The code to deal with processing an attribute that spans two buffers seems rather messy to me because the break can occur during any element. It sees like a good place to generate lots of occasional bugs. You observed that with the two-byte lengths in the binary proposal, it is easy to determine if the buffer ends in the middle of the string. It is also easy in the current proposal to get the same information by putting a " " (space character) just after the last character in the buffer to stop the scan-for-space algorithm. You also observed that with CRLF and a maximum line length, it is easy to ensure that a buffer has a full unit because functions, such as fgets read upto the next CRLF. Perhaps we need to revisit the solution that uses CRLF, namely the one where each parameter has the syntax name ":" value CRLF . The syntax for such a solution would be parameter = single-value / set-of / continued-value single-value = parameter-name ":" value CRLF set-of = parameter-name 2*( ":" value CRLF) continued-value = " " value CRLF from a raw level the syntax for a parameter is: parameter = 1*998 BYTE CRLF BYTE = %x00..%x09 / %x0B / %x0C / %x0E..%xFF ; any value except CR or LF CR in a value is represented by =0C LF in a value is represented by =0A = in a value is represented by =3D The following is the GrabAttr function is designed along the lines of your function except that it returns the type of the parameter (attribute). It assumes that the buffer holds at least 1000 bytes and ends with a "CRLF" so there are no partial parameter issues to deal with in the GrabATTR function. I am assuming that the caller of GrabAttr copies the strings referenced by pAttr and for the value it translates an =xx to the actual character. I am also assuming that it used the value returned (attrType) to determine how to use the attribute just read. int GrabAttr(ATTR *pAttr) { char * pNext; int length; int attrType; switch (*pBuf) { case ' ': /* contination line /* attrType = CONTINUED_VALUE; pBuf++; break; case ':': / another member of a set */ attrType = SET_OF; pBuf++; break; default: attrType = SINGLE_VALUE; pNext = strchr(pBuf,':'); pAttr->nNameLength = pNext-pBuf; /* this works now */ pAttr->pName = pBuf; pBuf = pNext + 1; } pNext = strchr(pBuf,'\r'); pAttr->nValLen = pNext-pBuf; /* this works now */ pAttr->pVal = pBuf; pBuf = pNext + 2; /* skip CRLF */ return attrType; } Perhaps this pure textual solution is easier to program once you consider the buffer problem. Comments? Bob Herriot > From SBUTLER@hpbs2024.boi.hp.com Fri Jun 20 08:51:08 1997 > > Bob Herriot wrote: > > >binary protocol. Also, my ANSI C book states that atoi assumes decimal, but > >recommends using strtol as I have done below. > > Ahh, yes. How did I miss that... > > >int GrabAttr(ATTR *pAttr) > >{ > > char * pNext; > > int length; > > > > pNext = strchr(pBuf,' '); > > Probably safe given my initial assumption that the buffer would hold > the entire name... But hard for the upper layer to validate. > > > pAttr->nNameLength = pNext-pBuf; > > pAttr->pName = pBuf > > pBuf = pNext + 1; > > > > length = strtol(pBuf,&pNext,10); /* ANSI C function */ > > Doh! Hardcoding the base. I missed that one. > > Again, we have the potentially hard to verify issue of searching > forward. > > > pAttr->nValLen = length; > > pNext++; > > pAttr->pVal = pNext; > > pBuf = pNext + length; > > return ERROR_OK > >} > > Looks good, better than I expected. > > I am concerned with how the upper layer can validate the assumption > that the delimiters will be in the buffer for this lower layer. A > "pure" text (with max line lengths defined, CRLF endings, etc) can > read until it gets the entire line (or declare an error when the > line is found to be too long) and know it has the whole thing. With > unknown line lengths it is risky to assume that without verification. > > With the binary lengths the GrabAttr doesn't loop searching for > anything and the layer above can compare lengths with the len of data > in the buffer to verify that all is well. > > >would expect than an implementation might have a keywordToInt function > >which would map keywords to integers that in turn could be used in > > Of course, but remind me again, what does an implementation gain by > having such a function as opposed to just communicating in binary? > > >> From SBUTLER@hpbs2024.boi.hp.com Thu Jun 19 18:06:36 1997 > ... > >> What do we get with ASCII? My list of "pros" > >> from the meeting is really short. The biggest I've been able to > >> identify is vendor extensibility. > > [proposal, examples, etc. deleted] > > sdb > > | Sylvan Butler | sbutler@boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 | > From ipp-archive Fri Jun 20 21:35:04 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA10150 for ipp-outgoing; Fri, 20 Jun 1997 21:30:26 -0400 (EDT) Message-Id: <9706210130.AA00502@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, 20 Jun 1997 18:28:13 PDT To: Brian Grimshaw From: Tom Hastings Subject: Re: IPP> Encoding Cc: Sender: ipp-owner@pwg.org Precedence: bulk At 12:50 06/20/97 PDT, Brian Grimshaw wrote: snip... >I am more concerned that the proposed protocol (whether binary or text >encoded) does not seem to allow representing a set of attributes, or a >hierarchy of attributes -- without a parser having knowledge of all >attributes. While encoding the type in the protocol has been raised as a >solution to this, I think types do not model sets very well and this >should be treated as a separate issue. This could be handled in the >protocol and, minimally, there should an accommodation for future >extensions that may allow this without breaking parsers of IPP 1.0. I'm not exactly sure what you mean by a set. If you mean a set of values of the same type, then the current multi-valued encoding works just fine for a set. In the example in the minutes, there were a set of 2 values for the "finishing" attribute: The following is an example of a Print-Job request "0100Print-Job" CRLF "job-name 3 foocopies 1 2document-format 22 application/postscript" "finishings 5 staple 5 punch" CRLF "%!PS" ... If you mean a set of attributes then that is another matter. One way to handle a set of attributes is to have a new data type that is a single attribute (name and value). When such an attribute has multiple attributes as values, use the multi-valued mechanism of IPP, one value for each attribute. In this approach, each (sub-)attribute can only be single-valued. An example of an "address" attribute whose value consists of attributes: "name", "apartment-number", "street", "city", "state", "zip", "country" would be in ABNF: "address 15 name 8 John Doe 17 street 8 123 Main 9 city 2 LA 10 state 2 CA" A second approach is to define the new data type as a set of attributes. In the above example, the value of the "address" is single valued. But it could be multi-values, providing multiple addesses. "address 52 name 8 John Doestreet 8 123 Maincity 2 LA state 2 CA" With either scheme in order to group a set of attributes, you need to define an attribute with the new data type. But since Printer MUST reject any attribute that they don't understand, a client can only successfully submit a new attribute with a new data type to a Printer that supports the new data type. Is this what you mean by a set? If so, I think we can have sets in the future with the current encoding and extensibility rules. Tom > >If I am wrong about this, can someone tell me how to do it with the >proposed protocol or where in the various documents this is described? > >Brian > > >-------------------- >Brian Grimshaw >Apple Computer, Inc. >brian@apple.com > > From ipp-archive Fri Jun 20 22:00:04 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA10676 for ipp-outgoing; Fri, 20 Jun 1997 21:59:31 -0400 (EDT) Date: Fri, 20 Jun 1997 18:57:26 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706210157.SAA11748@woden.eng.sun.com> To: brian@apple.com, hastings@cp10.es.xerox.com Subject: Re: IPP> Encoding Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk I think what you and Brian are trying to define is a set of values where each value has a name associated with it. As long these names are fixed, this is just a new data type with implicit names associated with each member of the set. Since we have said that a client either has this information hardwired (version 1) or can get typing information from a server ( a later version), there is no need for the parameter representation to store the names of individual members. This problem is much like the compiling of a C struct. If you are looking for an attribute to contain a list of attributes where the name is unknown in advance and where each is single valued, then there could be a datatype which is a set of 2-tuple where each 2-tuple is a name and a value. We talked about this solution for a set of integer ranges. The hard case is for attributes that are multivalued. The point of all this is that our current protocol representation for sets gives use a 95% solution and that is simple and good enough for now. Bob Herriot > From hastings@cp10.es.xerox.com Fri Jun 20 18:39:13 1997 > > At 12:50 06/20/97 PDT, Brian Grimshaw wrote: > > An example of an "address" attribute whose value consists of attributes: > "name", "apartment-number", "street", "city", "state", "zip", "country" > would be in ABNF: > > "address 15 name 8 John Doe 17 street 8 123 Main 9 city 2 LA 10 state 2 CA" > > From ipp-archive Sat Jun 21 13:15:11 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA12112 for ipp-outgoing; Sat, 21 Jun 1997 13:12:08 -0400 (EDT) Message-Id: <9706211712.AA00602@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, 21 Jun 1997 10:09:47 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - ISSUE: "document-format" data type: keyword vs name? Sender: ipp-owner@pwg.org Precedence: bulk Page 54, line 415: "document-format" data type is keyword. Should it be changed to name? Both Printer MIB lang enum symbols and MIME type/sub-types have mixed case and MIME types/sub-types have illegal characters for keywords: "/" and ".". For example, the MIME type/sub-type name for PCL is: application/vnd.hp-PCL Since the IPP Model document doesn't control the registry for either of these, I suggest that we simply change the data type to 'name'. Alternatively, we could define a tranformation for the MIME type/sub-type names to keyword syntax: a. down case the names b. remove the "/" to make them legal keywords (or don't include 'application/' at all, just use the sub-type name?) c. map the "." to something (or add "." to the list of allowed keyword characters?). If we change data type to name, the Model document needs to clarify the case of the values: mixed case, case insensitive, what for purposes of matching? I suggest that case insensitive be required, since these are names, not keywords. Need to add examples: Printer enum symbols (without 'lang' prefix): 'PS', 'PCL' 'SimpleText' (what corresponding MIME type/sub-type?) MIME type/sub-type names: 'application/postscript', 'application/vnd.hp-PCL', and 'application/pdf' (no corresponding lang enum). From ipp-archive Sat Jun 21 13:15:13 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA12101 for ipp-outgoing; Sat, 21 Jun 1997 13:11:54 -0400 (EDT) Message-Id: <9706211712.AA00599@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, 21 Jun 1997 10:09:34 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - ISSUE: values of "document-format" should be the same for model and protocol? Sender: ipp-owner@pwg.org Precedence: bulk Page 54, lines 422-427: "document-format" attribute. Values should be the same in the Model and Protocol. Mapping from the Printer enum symbols (without the 'lang' prefix in the Model) to MIME type/sub-type names (in the protocol) is not going to be very consistent between implementations. Problems with mapping from Printer MIB enum symbol keywords to MIME type/sub-type names: What does "SimpleText" enum symbol map to MIME type/sub-type name? MIME type/sub-type application/pdf has no enum symbol. Both are mixed case, so mapping between is even more variable. Most of the 50 Printer MIB enums do not have MIME type/sub-type names registered. Is it ok if the printer vendors go register those 50 with IANA? Should the PWG re-register the 50 enum symbols (IANA calls them printer languages) as MIME type/sub-types, e.g., application/langSimpleText, application/langPS, application/langPCL? Alternatives for Model and Protocol specs: 1. Both use Printer MIB enum symbols without the "lang" prefix (registered by IANA as "Printer Languages") 2. Both use MIME type/sub-type names (registered by IANA as "Media Types"). 3. Both use either. ISSUE: If we use MIME type/sub-type names, is the 'application/' necessary, or could we just use the sub-type name? The values of the "document-format" attribute are the "heart-land" of the PWG. We have to make sure that this attribute is interoperable between implementations. I suggest that whichever approach we use, that we add an appendix which lists the current values with the proper case and indicate that it is just a "snap shot" of current IANA registry. Comments? Tom From ipp-archive Sat Jun 21 13:15:15 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA12090 for ipp-outgoing; Sat, 21 Jun 1997 13:11:44 -0400 (EDT) Message-Id: <9706211711.AA00596@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, 21 Jun 1997 10:09:15 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - ISSUE: is "best-effort" job template attribute useful? Sender: ipp-owner@pwg.org Precedence: bulk I still question the value of having a single job template attribute that specifies "best-effort" (or more aptly named: "attribute-precedance" or something.) that applies to ALL attributes supplied by the client. My understanding of the xxx-supported attributes is that a Printer SHALL return the values that the Printer supports in the protocol. For each xxx attribute, there are 3 alternatives for a conforming Printer: a. only supports the values in the protocol, not in the PDL b. supports the values in both the protocol and the PDL, but if both are supplied, the PDL takes precedance. c. supports the values in both the protocol and the PDL, but if both are supplied, the protocol takes precedance. If a printer supports an attribute value only in the PDL, the Printer SHALL NOT return that value in the "xxx-supported" attribute. As we have agreed most current implementations do not support the protocol overriding what is in the PDL, yet we agree that is what we want to get to long term. I suspect that vendors are going to implement overriding gradually, a few attributes at a time, not all or nothing. TRUE? And different vendors will support overriding for different attributes. Therefore, having a *single* attribute that allows the client to choose between: a. ALL attributes that the client supplies MUST override the PDL, else the Printer MUST reject the job OR b. its ok if SOME or ALL of the attributes that the client supplies do not override the PDL, in case the attribute is also in the PDL Instead, I propose that we follow the same strategy that got us to delete the compulsory/non-compulsory concept, namely that the client has to get it right and specify only attributes that override the PDL or the Printer shall reject the job. a. So delete the "best-effort" job template attribute. b. Instead, let the Printer attributes specify what the Printer supports in the protocol and in the PDL and with what precedance. Therefor, introduce a parallel set of Printer attributes to the "xxx-supported" attributes called "xxx-precedance". Each "xxx-precedance" Printer attribute is single-valued. The values are: 'ipp-only' the corresponding "xxx" job attribute is supported in the IPP protocol only [This value isn't strictly necessary, but might be informative] 'ipp-over-pdl' the corresponding "xxx" job attribute is supported in both the IPP protocol and in the PDL, but if supplied in both, the IPP protocol takes precedance 'pdl-over-ipp' the corresponding "xxx" job attribute is supported in both the IPP protocol and in the PDL, but if supplied in both, the PDL takes precedance [We definitely don't want a 'pdl-only' value, since the purpose of "xxx-supported" is to show what is possible for a client to supply in the protocol] While this proposal adds more Printer attributes, they only go in the IPP spec as a column in the job template table, replacing the column that we deleted on availablilty. Also these attributes are specified only in Get-Attributes for a Printer, not in Create-Job/Print-Job, so we are simplifying the job submission part of IPP. If we want to allow the client to specify an attribute to be used, in case the PDL doesn't specify, we could add an "xxx-default" column to the job template table that a client could supply. If we do that, we could even change the names of the "xxx" Printer attribute to "xxx-default", since they would have the same semantics, namely, the value is applied only if the PDL does not supply a value. Comments? Tom From ipp-archive Sat Jun 21 13:25:13 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA12148 for ipp-outgoing; Sat, 21 Jun 1997 13:22:43 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Sat, 21 Jun 1997 11:01:08 -0600 From: Scott Isaacson To: hastings@cp10.es.xerox.com, jkm@underscore.com Cc: ipp@pwg.org Subject: Re: IPP> MOD - The Get-Jobs operation andcompleted/canceled/aborted jobs Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk I like the following idea: > Perhaps you are suggesting that IPP never return completed/canceled/ > aborted jobs, and that a program use the Job Monitoring MIB to get > back completed/canceled/aborted jobs? Yes, let's say IPP never returns completed/canceled/aborted jobs. Use the JMP MIB for that. 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 Sat Jun 21 13:25:15 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA12149 for ipp-outgoing; Sat, 21 Jun 1997 13:22:46 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Sat, 21 Jun 1997 11:20:18 -0600 From: Scott Isaacson To: ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP>PRO: sorry, binary is better (?) Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk I sure agree with Randy: >>> Randy Turner 06/19/97 09:10PM >>> > This stuff is really too easy and we shouldn't worry about the > differences between > ASCII and binary at this point. The code difference is trivial. > I thought we have already made this decision? We seem to reach reasonable conclusions and then keep opening them up again. I have reviewed several of the long postings on code and it is clear that the code and performance differences are TRIVIAL!!!!!! Brain, Scott L, Jay, Bob, myself, and many others have pointed out many benefits of the ASCII version. There was a fundamental decision made LONG ago that an ASCII protocol should be used over a binary protocol. It was not re-opened until the SWP proposal in San Diego. We SHOULD NOT (oops, I had my I-D editors keyborad turned on there) remove the benefits of an ASCII protocol unless there is a "preponderance of evidence" and I just don't see it. In reviewing - the 6/17 meeting minutes, - the recent e-mail postings, and - the minutes from almost ALL of the weekly teleconference calls over that past 5 months (which have been open to anyone) the overwhelming number of participants have expressed support for the ABNF based ASCII protocol. It is not what I personally supported initially, but I wanted to make progress and listen to the group. I know that this is not a "majority" vote situation, but if I were an objective outside observer, it would be clear to me that we are close to consensus on the ASCII based protocol based on what is posted and reported by most of the participants. Scott Isaacson From ipp-archive Sun Jun 22 15:30:26 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA16472 for ipp-outgoing; Sun, 22 Jun 1997 15:26:57 -0400 (EDT) Message-ID: <41135C785691CF11B73B00805FD4D2D702E331AA@RED-17-MSG.dns.microsoft.com> From: Paul Moore To: "'Scott Isaacson'" , ipp@pwg.org, rturner@sharplabs.com Subject: RE: IPP>PRO: sorry, binary is better (?) Date: Sun, 22 Jun 1997 12:27:18 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: ipp-owner@pwg.org Precedence: bulk I have a genuine confusion over something - fundamentally I agree that the encoding is trivial. BUT I question the reason for insisting on ASCII - this is a much more interesting question "If its trivial why do we care either way?", why not just choose the simplest to implement. I think we have a fundamental disjunction of requirements here. The idea of IPP is to develop a strong program to program protocol for clients to talk to servers. Yet the major reason for the ASCII encoding is so that the client does not have to understand the semantics of the protocol - i.e. the intention is to allow it to be just displayed on the screen (after some syntactic munging). This seems to be a pair of requirements in direct conflict with each other - A client server protocol that the client does not need to understand. This is just a display protocol , of which we already have a perfectly good one - HTML. Everything you are talking about doing can be done using web pages and an exisiting browser. Example:- -If the protocol is going to be read by a program then the encodings are just 'magic numbers' regardless of text or binary. We could choose the number '42' to mean 'copies' or we could choose numbers 'COPIES' to mean copies just so long as we (the implementors) all agree. -If the protocol is going to be read by a human then we might say "Enter the number of copies" (in their native language) or even "How many copies do you want" We cannot have both. I think this mixed mode is being used to persuade ourselves that we have solved a profound problem that, in fact, we have not - the problem of attribute extensibility at a programmatic level. My fear is that we will end up with a mess and programs trying to extract meaning from "Combien de copies voulez-vous?" - which is exactly where we don't want to be. I don't know - maybe I am missing something. What is it? > -----Original Message----- > From: Scott Isaacson [SMTP:SISAACSON@novell.com] > Sent: Saturday, June 21, 1997 10:20 AM > To: ipp@pwg.org; rturner@sharplabs.com > Subject: Re: IPP>PRO: sorry, binary is better (?) > > I sure agree with Randy: > > >>> Randy Turner 06/19/97 09:10PM >>> > > This stuff is really too easy and we shouldn't worry about the > > differences between > > ASCII and binary at this point. The code difference is trivial. > > I thought we have already made this decision? > > We seem to reach reasonable conclusions and then keep opening them up > again. > I have > reviewed several of the long postings on code and it is clear that the > code and performance differences are TRIVIAL!!!!!! Brain, Scott L, > Jay, > Bob, myself, and > many others have pointed out many benefits of the ASCII version. > There was > a fundamental decision made LONG ago that an ASCII protocol should be > used > over a binary protocol. > It was not re-opened until the SWP proposal in San Diego. > > We SHOULD NOT (oops, I had my I-D editors keyborad turned on there) > remove > the benefits of an ASCII protocol unless there is a "preponderance of > evidence" and I > just don't see it. > > In reviewing > - the 6/17 meeting minutes, > - the recent e-mail postings, and > - the minutes from almost ALL of the weekly teleconference calls > over > that past 5 months > (which have been open to anyone) > the overwhelming number of participants have expressed support for the > ABNF based ASCII protocol. It is not what I personally supported > initially, but I wanted to make > progress and listen to the group. I know that this is not a > "majority" vote > situation, but if I were > an objective outside observer, it would be clear to me that we are > close to > consensus on > the ASCII based protocol based on what is posted and reported by most > of the > participants. > > Scott Isaacson > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From ipp-archive Mon Jun 23 12:05:39 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA18077 for ipp-outgoing; Mon, 23 Jun 1997 12:02:56 -0400 (EDT) Message-ID: From: "Sylvan Butler" X-Real-Sender: SYLVAN Organization: Hewlett-Packard, Boise To: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Date: Mon, 23 Jun 1997 10:02:48 -0700 Subject: Re: IPP>PRO: sorry, but binary is better CC: ipp@pwg.org Priority: normal X-mailer: Pegasus Mail v3.31 Sender: ipp-owner@pwg.org Precedence: bulk >This buffer problem exists for both the current IPP proposal and for >the previous binary proposal that you prefer. The two byte binary >integer could span buffers and a parameter name or value buffer could The upper layer can trivially ensure that the buffer contains X bytes of data, where X is large enough to hold at least a two byte attribute name and a two byte value length. Once the lengths are known then the proper amount for values is easy to collect. With an ASCII encoding the upper layer has to guess, or check for proper terminators. >buffers seems rather messy to me because the break can occur during any >element. It sees like a good place to generate lots of occasional bugs. Yes, except with binary it is not messy at all. >putting a " " (space character) just after the last character in the >buffer to stop the scan-for-space algorithm. That would work, if you must scan. >You also observed that with CRLF and a maximum line length, it is easy >to ensure that a buffer has a full unit because functions, such as fgets >read upto the next CRLF. Perhaps we need to revisit the solution that Unless you have to interoperate with implementations that visually checked (instead of looking at a sniffer hex dump) for "lines". Like with HTTP servers today, even though the spec reads CRLF you still find CR (from mac?), LF (from unix?) and the desired CRLF (I wouldn't be suprised to find some LFCR's out there). > CR in a value is represented by =0C > LF in a value is represented by =0A > = in a value is represented by =3D You will probably need to escape anything less than %x20 and perhaps anything greater than %x7E. In fact, instead of developing our own escape rules we should, as you probably did, just pick one. This is just so ugly, considering the purpose is for two computers to talk to each other over a link that is 8-bit clean. >Perhaps this pure textual solution is easier to program once you consider >the buffer problem. I don't find it so. sdb | Sylvan Butler | sbutler@boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 | From ipp-archive Mon Jun 23 12:40:39 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA18625 for ipp-outgoing; Mon, 23 Jun 1997 12:36:15 -0400 (EDT) Message-ID: <33AEA360.5F7A@parc.xerox.com> Date: Mon, 23 Jun 1997 09:25:04 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: Tom Hastings CC: ipp@pwg.org Subject: Re: IPP> extensibility References: <9706191823.AA00384@zazen.cp10.es.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk > Could you elaborate on why you think that the requester needs to be > able to flag each supplied attribute as to whether it is a > compulsory (what you call mandatory) or is non-compulsory (what you > call optional) in order to achieve extensibility. HTTP has had the notion of 'ignore any header you don't understand' as its extensibility mechanism. It's allowed lots of extensions while also allowing older implementations to interoperate. However, there've been cases where that kind of extensibility has gotten in the way. > IPP has dropped the idea of allowing the requester to be able to > indicate. Now IPP requires the provider to reject the request if there > are any values that the provider doesn't understand. > The requester > then needs to fix up the request until the provider can accept all > values. The requester can query the provider to determine all supported > values of all attributes that the requester can supply. If the provider MUST reject any values it doesn't understand, requestors will likely NOT include any extensions in requests, lest it pay the cost of mainly having its initial requests rejected. The problem with prospective discovery (remember from the past whether this provider understands this extension) is that it is fragile: provider's capabilities can change, but the timeout of cached capabilities isn't explicit; a single virtual provider might front for several actual providers, but the capabilties might be variable. This is mainly an issue for HTTP-NG, I think, but IPP is a good example of the kind of extensible protocol we'd like to support in the NG effort. Larry -- http://www.parc.xerox.com/masinter From ipp-archive Mon Jun 23 13:40:40 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA19202 for ipp-outgoing; Mon, 23 Jun 1997 13:37:26 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 23 Jun 1997 11:15:28 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - new 970623 model document and Internet-Draft Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk I have posted a new verion of the Model document and I have sent a text version of the same to the IETF as "draft-ietf-ipp-model-02.txt" Look in: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970623-rev.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970623-rev-ms6.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970623-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970623.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970623-ms6.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970623.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970623.txt ipp-model-970623-rev.doc Is the MSWord97 version with revision marks ipp-model-970623-rev-ms6.doc Is the MSWord6.0 version with rev marks ipp-model-970623-rev.pdf Is the PDF version with rev marks ipp-model-970623.doc Is the MSWord97 version (no rev marks) ipp-model-970623-ms6.doc Is the MSWord6.0 version (no rev marks) ipp-model-970623.pdf Is the PDF version (no rev marks) ipp-model-970623.txt Is the same as draft-ietf-ipp-model-02.txt When commenting on this version, you can use ipp-model-970623.pdf which has line numbers. I will be bringing about 20 paper copies of this to the June 25-26 meetings. I have also posted the list of issues we need to review: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/model-issues-970623.pdf I will bring paper copies of this as well. ************************************************************ Scott A. Isaacson Print Services Consulting Engineer Novell Inc., 122 E 1700 S, Provo, UT 84606 V: (801) 861-7366, (800) 453-1267 x17366 F: (801) 861-4025, E: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Mon Jun 23 14:30:40 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA19775 for ipp-outgoing; Mon, 23 Jun 1997 14:30:03 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 23 Jun 1997 12:29:51 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> DIR - new 970612 directory document and Internet-Draft Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk I have posted a new verion of the Directory Schema document and I have sent a text version of the same to the IETF as "draft-ietf-ipp-dir-schema-01.txt" Look in: ftp://ftp.pwg.org/pub/pwg/ipp/new_DIR/ipp-directory-970612-ms6.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_DIR/ipp-directory-970612.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_DIR/ipp-directory-970612.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DIR/ipp-directory-970612.txt ipp-directory-970612-ms6.doc Is the MSWord6.0 version (no rev marks) ipp-directory-970612.doc Is the MSWord97 version (no rev marks) ipp-directory-970612.pdf Is the PDF version (no rev marks) ipp-directory-970612.txt Is the same as draft-ietf-ipp-dir-schema-01.txt When commenting on this version, you can use ipp-directory-970612.pdf which has line numbers. I will be bringing about 20 paper copies of this to the June 25-26 meetings. ************************************************************ Scott A. Isaacson Print Services Consulting Engineer Novell Inc., 122 E 1700 S, Provo, UT 84606 V: (801) 861-7366, (800) 453-1267 x17366 F: (801) 861-4025, E: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Mon Jun 23 17:45:42 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA20468 for ipp-outgoing; Mon, 23 Jun 1997 17:43:28 -0400 (EDT) Date: Mon, 23 Jun 1997 14:37:51 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199706232137.OAA13612@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, SBUTLER@hpbs2024.boi.hp.com Subject: IPP>PRO: protocol problem, WAS: sorry, but binary is better Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk After thinking about the partial buffer problem with respect to the three possible encodings, the ONLY ENCODING THAT SEEMS TO HAVE A PROBLEM IS THE ONE WE CHOSE. That is why we need to continue the discussion. In my last email I described the algorithm for the HTTP-like version which fills a buffer upto CRLF, thus avoiding buffer overlap issues. With the binary encoding, I would expect that it would fread the two byte length (call it n) and then fread n bytes of name/value in order to avoid messy buffer overlaps. It would do this twice for each parameter. So the reading of bytes would be intimately associated with the parsing. But Sylvan's GrabAttr seems to assume a buffer that already has the name and the attribute. How does Sylvan do this without parsing the two lengths at the high level and in GrabAttr. Sylvan, could you give more details about how you handle the buffer overlap problem with binary encoding? I have suggested a method above, but you seem to have some other way. Bob Herriot > From SBUTLER@hpbs2024.boi.hp.com Mon Jun 23 09:04:34 1997 > From: "Sylvan Butler" > X-Real-Sender: SYLVAN > Organization: Hewlett-Packard, Boise > To: Robert.Herriot@Eng (Robert Herriot) > Date: Mon, 23 Jun 1997 10:02:48 -0700 > Subject: Re: IPP>PRO: sorry, but binary is better > CC: ipp@pwg.org > Priority: normal > X-mailer: Pegasus Mail v3.31 > Content-Length: 2098 > X-Lines: 53 > > >This buffer problem exists for both the current IPP proposal and for > >the previous binary proposal that you prefer. The two byte binary > >integer could span buffers and a parameter name or value buffer could > > The upper layer can trivially ensure that the buffer contains X bytes > of data, where X is large enough to hold at least a two byte attribute > name and a two byte value length. Once the lengths are known then > the proper amount for values is easy to collect. > > With an ASCII encoding the upper layer has to guess, or check for > proper terminators. > > >buffers seems rather messy to me because the break can occur during any > >element. It sees like a good place to generate lots of occasional bugs. > > Yes, except with binary it is not messy at all. > > >putting a " " (space character) just after the last character in the > >buffer to stop the scan-for-space algorithm. > > That would work, if you must scan. > > >You also observed that with CRLF and a maximum line length, it is easy > >to ensure that a buffer has a full unit because functions, such as fgets > >read upto the next CRLF. Perhaps we need to revisit the solution that > > Unless you have to interoperate with implementations that visually > checked (instead of looking at a sniffer hex dump) for "lines". Like > with HTTP servers today, even though the spec reads CRLF you still > find CR (from mac?), LF (from unix?) and the desired CRLF (I wouldn't > be suprised to find some LFCR's out there). > > > CR in a value is represented by =0C > > LF in a value is represented by =0A > > = in a value is represented by =3D > > You will probably need to escape anything less than %x20 and perhaps > anything greater than %x7E. > > In fact, instead of developing our own escape rules we should, as you > probably did, just pick one. > > This is just so ugly, considering the purpose is for two computers to > talk to each other over a link that is 8-bit clean. > > >Perhaps this pure textual solution is easier to program once you consider > >the buffer problem. > > I don't find it so. > > sdb > > | Sylvan Butler | sbutler@boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 | > From ipp-archive Mon Jun 23 18:10:42 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA20990 for ipp-outgoing; Mon, 23 Jun 1997 18:06:03 -0400 (EDT) Message-ID: <33AEF14D.446B9B3D@sharplabs.com> Date: Mon, 23 Jun 1997 14:57:33 -0700 From: Randy Turner Organization: Sharp Laboratories of America X-Mailer: Mozilla 3.01 (X11; I; SunOS 4.1.4 sun4m) MIME-Version: 1.0 To: Robert Herriot CC: SBUTLER@hpbs2024.boi.hp.com, ipp@pwg.org Subject: Re: IPP>PRO: protocol problem, WAS: sorry, but binary is better References: <199706232137.OAA13612@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk I don't see any partial buffer problems in the encoding we have chosen. In fact, with respect to a byte-stream delivery interface (TCP) and using 8-bit clean I/O calls (no fgets), IMHO, the term "partial buffer" doesn't even have any meaning. Randy Robert Herriot wrote: > > After thinking about the partial buffer problem with respect to the > three possible encodings, the ONLY ENCODING THAT SEEMS TO HAVE A PROBLEM > IS THE ONE WE CHOSE. That is why we need to continue the discussion. > > In my last email I described the algorithm for the HTTP-like version > which fills a buffer upto CRLF, thus avoiding buffer overlap issues. > > With the binary encoding, I would expect that it would fread the two > byte length (call it n) and then fread n bytes of name/value in order > to avoid messy buffer overlaps. It would do this twice for each > parameter. So the reading of bytes would be intimately associated with > the parsing. But Sylvan's GrabAttr seems to assume a buffer that > already has the name and the attribute. How does Sylvan do this > without parsing the two lengths at the high level and in GrabAttr. > > Sylvan, could you give more details about how you handle the buffer > overlap problem with binary encoding? I have suggested a method > above, but you seem to have some other way. > > Bob Herriot > > > From SBUTLER@hpbs2024.boi.hp.com Mon Jun 23 09:04:34 1997 > > From: "Sylvan Butler" > > X-Real-Sender: SYLVAN > > Organization: Hewlett-Packard, Boise > > To: Robert.Herriot@Eng (Robert Herriot) > > Date: Mon, 23 Jun 1997 10:02:48 -0700 > > Subject: Re: IPP>PRO: sorry, but binary is better > > CC: ipp@pwg.org > > Priority: normal > > X-mailer: Pegasus Mail v3.31 > > Content-Length: 2098 > > X-Lines: 53 > > > > >This buffer problem exists for both the current IPP proposal and for > > >the previous binary proposal that you prefer. The two byte binary > > >integer could span buffers and a parameter name or value buffer could > > > > The upper layer can trivially ensure that the buffer contains X bytes > > of data, where X is large enough to hold at least a two byte attribute > > name and a two byte value length. Once the lengths are known then > > the proper amount for values is easy to collect. > > > > With an ASCII encoding the upper layer has to guess, or check for > > proper terminators. > > > > >buffers seems rather messy to me because the break can occur during any > > >element. It sees like a good place to generate lots of occasional bugs. > > > > Yes, except with binary it is not messy at all. > > > > >putting a " " (space character) just after the last character in the > > >buffer to stop the scan-for-space algorithm. > > > > That would work, if you must scan. > > > > >You also observed that with CRLF and a maximum line length, it is easy > > >to ensure that a buffer has a full unit because functions, such as fgets > > >read upto the next CRLF. Perhaps we need to revisit the solution that > > > > Unless you have to interoperate with implementations that visually > > checked (instead of looking at a sniffer hex dump) for "lines". Like > > with HTTP servers today, even though the spec reads CRLF you still > > find CR (from mac?), LF (from unix?) and the desired CRLF (I wouldn't > > be suprised to find some LFCR's out there). > > > > > CR in a value is represented by =0C > > > LF in a value is represented by =0A > > > = in a value is represented by =3D > > > > You will probably need to escape anything less than %x20 and perhaps > > anything greater than %x7E. > > > > In fact, instead of developing our own escape rules we should, as you > > probably did, just pick one. > > > > This is just so ugly, considering the purpose is for two computers to > > talk to each other over a link that is 8-bit clean. > > > > >Perhaps this pure textual solution is easier to program once you consider > > >the buffer problem. > > > > I don't find it so. > > > > sdb > > > > | Sylvan Butler | sbutler@boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 | > > -- Randy Turner From ipp-archive Mon Jun 23 19:45:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA21572 for ipp-outgoing; Mon, 23 Jun 1997 19:45:42 -0400 (EDT) From: Harry Lewis To: Subject: RE: IPP>PRO: sorry, binary is better (?) Message-Id: <5030100003887931000002L012*@MHS> Date: Mon, 23 Jun 1997 19:47:33 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk I've gone back and reviewed this thread before commenting. It seems mostly like a "religious" discussion based on programming style and preference. I don't buy that extensibility is easier via text. This is only true if you don't believe a central body will continue to exist to review and "issue" new extensions. If we end up without a central body, then we have "free-for-all" vendor extension via text and interoperability degrades, anyway. I don't buy the network sniffer argument. Network sniffers decode wire protocols and present them in a more friendly fashion. The one thing that may be overlooked or un-stated in the discussion is that the IPP Server may well reside on an embedded controller within a printer where the effect of storing and parsing strings *can* have a significant effect and where "programmatic" issues should be favored over human readability. >>>Harry Lewis<<< ---------- Forwarded by Harry Lewis/Boulder/IBM on 06/23/97 05:17 PM --------- ipp-owner@pwg.org 06/22/97 01:39 PM Please respond to ipp-owner@pwg.org @ internet To: rturner@sharplabs.com @ internet, ipp@pwg.org @ internet, SISAACSON@novell.com @ internet cc: Subject: RE: IPP>PRO: sorry, binary is better (?) I have a genuine confusion over something - fundamentally I agree that the encoding is trivial. BUT I question the reason for insisting on ASCII - this is a much more interesting question "If its trivial why do we care either way?", why not just choose the simplest to implement. I think we have a fundamental disjunction of requirements here. The idea of IPP is to develop a strong program to program protocol for clients to talk to servers. Yet the major reason for the ASCII encoding is so that the client does not have to understand the semantics of the protocol - i.e. the intention is to allow it to be just displayed on the screen (after some syntactic munging). This seems to be a pair of requirements in direct conflict with each other - A client server protocol that the client does not need to understand. This is just a display protocol , of which we already have a perfectly good one - HTML. Everything you are talking about doing can be done using web pages and an exisiting browser. Example:- -If the protocol is going to be read by a program then the encodings are just 'magic numbers' regardless of text or binary. We could choose the number '42' to mean 'copies' or we could choose numbers 'COPIES' to mean copies just so long as we (the implementors) all agree. -If the protocol is going to be read by a human then we might say "Enter the number of copies" (in their native language) or even "How many copies do you want" We cannot have both. I think this mixed mode is being used to persuade ourselves that we have solved a profound problem that, in fact, we have not - the problem of attribute extensibility at a programmatic level. My fear is that we will end up with a mess and programs trying to extract meaning from "Combien de copies voulez-vous?" - which is exactly where we don't want to be. I don't know - maybe I am missing something. What is it? > -----Original Message----- > From: Scott Isaacson [SMTP:SISAACSON@novell.com] > Sent: Saturday, June 21, 1997 10:20 AM > To: ipp@pwg.org; rturner@sharplabs.com > Subject: Re: IPP>PRO: sorry, binary is better (?) > > I sure agree with Randy: > > >>> Randy Turner 06/19/97 09:10PM >>> > > This stuff is really too easy and we shouldn't worry about the > > differences between > > ASCII and binary at this point. The code difference is trivial. > > I thought we have already made this decision? > > We seem to reach reasonable conclusions and then keep opening them up > again. > I have > reviewed several of the long postings on code and it is clear that the > code and performance differences are TRIVIAL!!!!!! Brain, Scott L, > Jay, > Bob, myself, and > many others have pointed out many benefits of the ASCII version. > There was > a fundamental decision made LONG ago that an ASCII protocol should be > used > over a binary protocol. > It was not re-opened until the SWP proposal in San Diego. > > We SHOULD NOT (oops, I had my I-D editors keyborad turned on there) > remove > the benefits of an ASCII protocol unless there is a "preponderance of > evidence" and I > just don't see it. > > In reviewing > - the 6/17 meeting minutes, > - the recent e-mail postings, and > - the minutes from almost ALL of the weekly teleconference calls > over > that past 5 months > (which have been open to anyone) > the overwhelming number of participants have expressed support for the > ABNF based ASCII protocol. It is not what I personally supported > initially, but I wanted to make > progress and listen to the group. I know that this is not a > "majority" vote > situation, but if I were > an objective outside observer, it would be clear to me that we are > close to > consensus on > the ASCII based protocol based on what is posted and reported by most > of the > participants. > > Scott Isaacson > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From ipp-archive Mon Jun 23 20:00:45 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA22071 for ipp-outgoing; Mon, 23 Jun 1997 19:59:31 -0400 (EDT) Date: Mon, 23 Jun 1997 16:50:29 PDT From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9706232350.AA04799@snorkel.eso.mc.xerox.com> To: Robert.Herriot@Eng.Sun.COM, SBUTLER@hpbs2024.boi.hp.com Subject: Re: IPP>PRO: sorry, but binary is better Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk Hi Stuart, I'm just a guest here, but I agree with you. The 'code fragment wars' are all very amusing, but miss the point of reliability of implementations entirely. The current state of HTTP stuff with 'CRLF' just reinforces this view. If you use an 8-bit clean channel and then coerce your attribute names (identifiers) and lengths to 7-bit 'printable' ASCII, all you gain is that the long-term hope of good quality localization support for other languages and other code sets is lost irretrievably. It simply won't get realized, because it's too much hassle for the implementors. Justifying the protocol attribute encoding because the first transport is HTTP is nearsighted and an argument that the IETF area directors certainly won't sympathize with. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 From ipp-archive Mon Jun 23 20:00:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA22072 for ipp-outgoing; Mon, 23 Jun 1997 19:59:32 -0400 (EDT) Message-Id: <3.0.1.32.19970623165101.00ad2c00@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 23 Jun 1997 16:51:01 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> PRO - Binary vs. ASCII Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Hi, I have checked today with the people working on our prototype implementation. They claim that both solutions are really trivial, as we are using Java rather than C. Hence, we do not really care, but we would like to come to a conclusion, so we can get on with the prototyping effort. Please dig out your very last arguments for or against the solution that you like or dislike NOW, and post them to the DL so we can make a decision and move on to greener pastures. I expect to have a resolution out of this week's meeting in Nassua. Should we try to organize a phone session so that people not present in Nassau can also have a last say? With an 800 number ... 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 Jun 23 20:35:45 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA23112 for ipp-outgoing; Mon, 23 Jun 1997 20:31:55 -0400 (EDT) Message-ID: <33AF1569.5874@parc.xerox.com> Date: Mon, 23 Jun 1997 17:31:37 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: Paul Moore CC: "'Scott Isaacson'" , ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP>PRO: sorry, binary is better (?) References: <41135C785691CF11B73B00805FD4D2D702E331AA@RED-17-MSG.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk > -If the protocol is going to be read by a program then the encodings are > just 'magic numbers' regardless of text or binary. We could choose the > number '42' to mean 'copies' or we could choose numbers 'COPIES' to mean > copies just so long as we (the implementors) all agree. > One of the things that is affected by this choice is the extension mechanism. Suppose I want to try out a new feature. I'll do it privately, and then I want to register it and make it public. If I just pick a number, '43', I'm likely to hit someone else's number. So maybe I'll use a number out of the private extension space, e.g., '123451'. But then when I change from 'private extension' to 'public', I have to go back and recompile all my test code. With strings, I can pick a string that isn't used by anyone now, and most likely won't have to change it by the time I register it. This sounds pretty sloppy, but it's mainly what's done now for many protocols and it's much more robust than numbers. The protocol strings aren't human-language, they're just close enough to language to believe that they're extensible in a more distributed fashion. In addition, the debugging and testing aspects shouldn't be ignored; it's useful to be able to write a test program in a scripting language or even to telnet to port 80 at a host and just type "GET url HTTP/1.0" without having to count bytes. Larry -- http://www.parc.xerox.com/masinter From ipp-archive Mon Jun 23 20:45:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA23622 for ipp-outgoing; Mon, 23 Jun 1997 20:42:59 -0400 (EDT) Message-Id: <3.0.1.32.19970623173526.00aca390@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 23 Jun 1997 17:35:26 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Agenda for PWG IPP Meeting in Nassua NH Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Here is my latest attempt at getting together an Agenda for Nassua: Agenda for PWG IPP Meeting in Nassua, NH ======================================== Wednesday June 25 8:30 am to 6:00 pm Review Model draft from 970623 and remaining issues (Scott Isaacson) Review Directory Schema document from 970612 and remaining issues (Scott Isaacson & Keith Carter) Note: If we run out of things to do, we will start on Thurday's agenda Thursday June 26 8:30 am to 6:00 pm Review latest Protocol draft (still to be delivered - 970624?) Resolution of encoding and any other remaining issues (Bob Herriot & Randy Turner) Review Security draft from 970612 (Carl-Uno Manros) Review old I-D Requirements draft to determine if it needs updating (Don Wright & Carl-Uno Manros) Discussion about what needs to go into our IPP to RFC 1179 document (Volonteers?) Note: What will we do with points that do not get resolved? Plan for Munich IPP Meeting - Agenda, Preparation of Presentations ----- 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 Jun 23 21:30:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA24380 for ipp-outgoing; Mon, 23 Jun 1997 21:28:42 -0400 (EDT) Message-Id: <3.0.1.32.19970623182107.00af75a0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 23 Jun 1997 18:21:07 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - We meet in NASHUA Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Contrary to my recent messages, this week's meetings is in the city of "Nashua", not "Nassua" (or "Nassau"). Although the Bahamas might have been a nicer place, you better cancel that last minute ticket change you just made earlier today :-[ Sorry for any confusion :-] 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 Jun 23 21:50:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA24904 for ipp-outgoing; Mon, 23 Jun 1997 21:49:04 -0400 (EDT) Message-ID: <33AF28F9.EF038B4E@sharplabs.com> Date: Mon, 23 Jun 1997 18:55:06 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.01 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> New protocol doc available X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk A new revision of the IPP over HTTP document is available on the PWG FTP server: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-062397-rt.doc This document contains most (if not all) of the changes we covered at the protocol meeting on 6/17. I say most changes, because my notes were a little scrambled after the meeting but I think I got all of them down. FYI, I may not be at the meeting in Nashua this week, but I will try and make it. If I'm not there, maybe Jay Martin could provide some hardcopy versions of this document available since I'm posting this while some folks might be on the road... Thanks in advance, Jay. Hope to you in Nashua Randy From ipp-archive Mon Jun 23 22:10:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA25443 for ipp-outgoing; Mon, 23 Jun 1997 22:06:57 -0400 (EDT) Message-ID: <33AF2D1F.F5C4CB30@sharplabs.com> Date: Mon, 23 Jun 1997 19:12:47 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.01 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> New document available (PS) X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk I have also placed a Postscript version of the protocol draft at: ftp://ftp.pwg.org/pub/pwg/new_PRO/ipp-pro-062397-rt.ps Randy From ipp-archive Mon Jun 23 22:25:47 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA25949 for ipp-outgoing; Mon, 23 Jun 1997 22:22:32 -0400 (EDT) Message-ID: <41135C785691CF11B73B00805FD4D2D702E331B0@RED-17-MSG.dns.microsoft.com> From: Paul Moore To: "'Larry Masinter'" Cc: "'Scott Isaacson'" , ipp@pwg.org, rturner@sharplabs.com Subject: RE: IPP>PRO: sorry, binary is better (?) Date: Mon, 23 Jun 1997 19:22:24 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.30) Sender: ipp-owner@pwg.org Precedence: bulk The extensibility argument was why we changed in the first re-rev from 32-bit numbers to length prefaced Strings. > -----Original Message----- > From: Larry Masinter [SMTP:masinter@parc.xerox.com] > Sent: Monday, June 23, 1997 5:32 PM > To: Paul Moore > Cc: 'Scott Isaacson'; ipp@pwg.org; rturner@sharplabs.com > Subject: Re: IPP>PRO: sorry, binary is better (?) > > > -If the protocol is going to be read by a program then the encodings > are > > just 'magic numbers' regardless of text or binary. We could choose > the > > number '42' to mean 'copies' or we could choose numbers 'COPIES' to > mean > > copies just so long as we (the implementors) all agree. > > > > One of the things that is affected by this choice is the extension > mechanism. Suppose I want to try out a new feature. I'll do it > privately, and then I want to register it and make it public. If > I just pick a number, '43', I'm likely to hit someone else's number. > So maybe I'll use a number out of the private extension space, e.g., > '123451'. But then when I change from 'private extension' to > 'public', I have to go back and recompile all my test code. > > With strings, I can pick a string that isn't used by anyone now, > and most likely won't have to change it by the time I register it. > > This sounds pretty sloppy, but it's mainly what's done now for > many protocols and it's much more robust than numbers. > > The protocol strings aren't human-language, they're just close enough > to > language to believe that they're extensible in a more distributed > fashion. > > In addition, the debugging and testing aspects shouldn't be ignored; > it's useful to be able to write a test program in a scripting language > or even to telnet to port 80 at a host and just type "GET url > HTTP/1.0" > without having to count bytes. > > Larry > > -- > http://www.parc.xerox.com/masinter From ipp-archive Mon Jun 23 22:30:50 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA26128 for ipp-outgoing; Mon, 23 Jun 1997 22:29:40 -0400 (EDT) Message-ID: <33AF3111.39B9@parc.xerox.com> Date: Mon, 23 Jun 1997 19:29:37 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: Paul Moore CC: "'Scott Isaacson'" , ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP>PRO: sorry, binary is better (?) References: <41135C785691CF11B73B00805FD4D2D702E331B0@RED-17-MSG.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk > The extensibility argument was why we changed in the first re-rev from > 32-bit numbers to length prefaced Strings. Right, so the question isn't 'text vs. binary', it's 'length-prefaced strings' vs. 'delimited strings', and if length-prefaced, whether it is ascii-decimal-length or binary-length and if delimited, whether it's escaped delimiters or encoded delimiters The argument against length-prefaced is that there might be some errors if some of the characters might be accidentally transformed (e.g., space & tab, CR & LF & CRLF). The argument against delimited strings is that it takes more time to scan or parse. (You have to parse if the delimiters are escaped when not used as a delimiter, and scan and decode if the delimiters are encoded.) HTTP is mainly delimited (by CRLF) and escaped (for comment strings) but sometimes encoded (e.g., in URLs). Larry From ipp-archive Tue Jun 24 09:50:54 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA27955 for ipp-outgoing; Tue, 24 Jun 1997 09:46:59 -0400 (EDT) Date: Tue, 24 Jun 1997 09:47:01 -0400 (EDT) From: JK Martin Message-Id: <199706241347.JAA06776@uscore.underscore.com> To: rturner@sharplabs.com Subject: Re: IPP> New protocol doc available Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Randy, I'll be more than happy to bring hardcopies of the new document. Based on the RSVP attendance list, 30 copies should be sufficient. By the way, if anyone else would like Underscore to print copies of any documents for any of the PWG meetings this week, please don't hesitate to tell us. Since our offices are about 5 miles from the hotel, we can do these kinds of things on very short notice. ...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 Mon Jun 23 21:56 EDT 1997 Date: Mon, 23 Jun 1997 18:55:06 -0700 From: Randy Turner Organization: Sharp Labs of America To: ipp@pwg.org Subject: IPP> New protocol doc available Content-Transfer-Encoding: 7bit A new revision of the IPP over HTTP document is available on the PWG FTP server: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-062397-rt.doc This document contains most (if not all) of the changes we covered at the protocol meeting on 6/17. I say most changes, because my notes were a little scrambled after the meeting but I think I got all of them down. FYI, I may not be at the meeting in Nashua this week, but I will try and make it. If I'm not there, maybe Jay Martin could provide some hardcopy versions of this document available since I'm posting this while some folks might be on the road... Thanks in advance, Jay. Hope to you in Nashua Randy ----- End Included Message ----- From ipp-archive Tue Jun 24 10:25:55 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA28491 for ipp-outgoing; Tue, 24 Jun 1997 10:24:11 -0400 (EDT) Date: Tue, 24 Jun 1997 07:27:10 PDT From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9706241427.AA04986@snorkel.eso.mc.xerox.com> To: cmanros@cp10.es.xerox.com, ipp@pwg.org Subject: Re: IPP> PRO - Binary vs. ASCII Sender: ipp-owner@pwg.org Precedence: bulk Hi Carl-Uno It would be much appreciated by those of us who can't travel to Nashua if there was a 2 to 3 hour phone session in the course of the IPP meetings. I would certainly call in. I expect that others who were unable to travel or have conflicting meetings in other cities would to. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc 906-494-2434 From ipp-archive Wed Jun 25 01:56:04 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA00857 for ipp-outgoing; Wed, 25 Jun 1997 01:52:59 -0400 (EDT) Message-Id: <9706250553.AA01324@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, 24 Jun 1997 22:50:40 PDT To: Robert.Herriot@Eng.Sun.COM (Robert Herriot) From: Tom Hastings Subject: Re: IPP> Encoding Cc: brian@apple.com, ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk Bob, I think that we are in agreement that there are at least three ways that the current encoding could be used to represent an attribute whose value(s) are attributes. None of these approaches would require any change to the current encoding scheme. Such attributes could be regestered after V1.0 is a proposed standard, even though the new attribute has a new data type that is not in V1.0. The key is that we have agreed to a general mechanism using a *length* to represent an attribute value. The contents of the value are opaque to any recipient that doesn't recognize and support the attribute as indentified by the attribute-name. Any recipient (Printer receiving a request or client receiving a response) that doesn't understand that new attribute at least knows how to skip over the value (or values if the attribute has multiple values) in order to examine the next attribute. [BTW - we need some conformance requirement that requires recipients (Printers and clients) to skip over attributes they don't understand, rather than erroring out.] This mail message shows the importance of keeping the length mechanism in our encoding approach in order to achieve future extensibility with no impact on V1.0. The three ways are (each with a new data type): 1. A multi-valued data type with each value representing an attribute and a value 2. A multi-valued data type with each value representing a set of attributes 3. A multi-valued data type with each pair of values representing the attribute name and the attribute value (your suggestion). The example encodings of each of the three methods is as follows for the case of an "address" attribute whose value consists of OPTIONAL attributes: "name", "apartment-number", "street", "city", "state", "zip", "country": Method 1: the new data type that is a *single* attribute (name and value). When such an attribute has multiple attributes as values, use the multi-valued mechanism of IPP, one value for each attribute. In this approach, each (sub-)attribute can only be single-valued. "address 15 name 8 John Doe 17 street 8 123 Main 9 city 2 LA 10 state 2 CA" Method 2: the new data type is a *set* of attributes. In the above example, the value of the "address" is single valued. But it could be multi-values, providing multiple addesses. "address 52 name 8 John Doestreet 8 123 Maincity 2 LA state 2 CA" Method 3: the new data type is pairs of attribute-name attribuet-value The attribute-value must be single-valued (same restriction as method 1). "address 4 name 8 John Doe 6 street 8 123 Main 4 city 2 LA 5 state 2 CA" Method 3 is perhaps the easiest to parse. Tom At 18:57 06/20/97 PDT, Robert Herriot wrote: >I think what you and Brian are trying to define is a set of values where >each value has a name associated with it. > >As long these names are fixed, this is just a new data type with implicit >names associated with each member of the set. > >Since we have said that a client either has this information hardwired >(version 1) or can get typing information from a server ( a later version), >there is no need for the parameter representation to store the names >of individual members. This problem is much like the compiling of >a C struct. > >If you are looking for an attribute to contain a list of attributes >where the name is unknown in advance and where each is single valued, >then there could be a datatype which is a set of 2-tuple where each >2-tuple is a name and a value. We talked about this solution for a set >of integer ranges. The hard case is for attributes that are >multivalued. > >The point of all this is that our current protocol representation for >sets gives use a 95% solution and that is simple and good enough for now. > >Bob Herriot > > >> From hastings@cp10.es.xerox.com Fri Jun 20 18:39:13 1997 >> >> At 12:50 06/20/97 PDT, Brian Grimshaw wrote: >> >> An example of an "address" attribute whose value consists of attributes: >> "name", "apartment-number", "street", "city", "state", "zip", "country" >> would be in ABNF: >> >> "address 15 name 8 John Doe 17 street 8 123 Main 9 city 2 LA 10 state 2 CA" >> >> > > > From ipp-archive Wed Jun 25 02:26:05 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA01378 for ipp-outgoing; Wed, 25 Jun 1997 02:24:43 -0400 (EDT) Message-Id: <9706250625.AA01332@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, 24 Jun 1997 23:22:28 PDT To: rturner@sharplabs.com From: Tom Hastings Subject: Re: IPP> New protocol doc available Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk I converted the .doc file to a .pdf file with line numbers, page numbers, and headers and footers and posted: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ -rw-r--r-- 1 pwg pwg 57856 Jun 24 01:45 ipp-pro-062397-rt.doc -rw-r--r-- 1 pwg pwg 40937 Jun 25 06:22 ipp-pro-062397-rt.pdf -rw-r--r-- 1 pwg pwg 62505 Jun 24 02:05 ipp-pro-062397-rt.ps Tom At 18:55 06/23/97 PDT, Randy Turner wrote: >A new revision of the IPP over HTTP document is available on the PWG FTP >server: > >ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-062397-rt.doc > >This document contains most (if not all) of the changes we covered at >the protocol >meeting on 6/17. I say most changes, because my notes were a little >scrambled after >the meeting but I think I got all of them down. > >FYI, I may not be at the meeting in Nashua this week, but I will try and >make it. If I'm >not there, maybe Jay Martin could provide some hardcopy versions of this >document >available since I'm posting this while some folks might be on the >road... > >Thanks in advance, Jay. > >Hope to you in Nashua > >Randy > > > > From ipp-archive Wed Jun 25 03:46:05 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA02398 for ipp-outgoing; Wed, 25 Jun 1997 03:45:28 -0400 (EDT) Message-Id: <9706250745.AA01381@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, 25 Jun 1997 00:43:10 PDT To: Larry Masinter From: Tom Hastings Subject: Re: IPP> extensibility Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk At 09:25 06/23/97 PDT, Larry Masinter wrote: >> Could you elaborate on why you think that the requester needs to be >> able to flag each supplied attribute as to whether it is a >> compulsory (what you call mandatory) or is non-compulsory (what you >> call optional) in order to achieve extensibility. > >HTTP has had the notion of 'ignore any header you don't understand' >as its extensibility mechanism. It's allowed lots of extensions >while also allowing older implementations to interoperate. However, >there've been cases where that kind of extensibility has gotten >in the way. > >> IPP has dropped the idea of allowing the requester to be able to >> indicate. Now IPP requires the provider to reject the request if there >> are any values that the provider doesn't understand. > > >> The requester >> then needs to fix up the request until the provider can accept all >> values. The requester can query the provider to determine all supported >> values of all attributes that the requester can supply. > >If the provider MUST reject any values it doesn't understand, requestors >will likely NOT include any extensions in requests, lest it pay >the cost of mainly having its initial requests rejected. The >problem with prospective discovery (remember from the past whether >this provider understands this extension) is that it is fragile: >provider's capabilities can change, but the timeout of cached >capabilities isn't explicit; a single virtual provider might front >for several actual providers, but the capabilties might be variable. I think that there are several important differences with printing from browsing: 1. Clients are less likely to remember capabilities of previously accessed Printers, since the performance gain in such caching is not as great as with browsing. They may do a Get-Attributes anyway before submitting. And if they don't an immediate rejection could be the trigger for a client that doea cache to invaidate that cache and do a rediscovery Get-Attributes. 2. Administrators are less likely to take away capabilities of Printers, since it will impact users (no matter what we do in the protocol). 3. If a single virtual provider is fronting for several actual providers, and gets an attribute that is supported by one but not by another, the virtual provider MUST forward the job to the actual provider that can handle the job. So the bottom line of requiring an IPP Printer to reject an operation, rather than ignore an unsupported (or unrecognized) attribute, is simplicity of the protocol. With discovery, a client can still use an extension (though we may need some more discovery meta-attributes in order for a client to "understand" a new attribute). Such meta-attributes are NOT for version 1.0 of IPP. We can add them later as extensions themselves. On the other hand, a client must ignore attributes its gets from a Printer, that the client doesn't understand (or maybe dump them out as not recognized ASCII), rather than refusing to understand the rest of the response from the Printer, or else we will have real trouble extensing IPP. > >This is mainly an issue for HTTP-NG, I think, but IPP is a good >example of the kind of extensible protocol we'd like to support in the >NG effort. > >Larry >-- >http://www.parc.xerox.com/masinter > > > > From ipp-archive Wed Jun 25 04:11:06 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA02946 for ipp-outgoing; Wed, 25 Jun 1997 04:08:24 -0400 (EDT) Message-Id: <9706250808.AA01413@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, 25 Jun 1997 01:06:06 PDT To: Robert.Herriot@Eng.Sun.COM (Robert Herriot) From: Tom Hastings Subject: Re: IPP>PRO: protocol problem, WAS: sorry, but binary is better Cc: SBUTLER@hpbs2024.boi.hp.com, ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk It seems to me that trying to parse the data out of a buffer is too unreliable and/or forces us to put CRLF (with all its variations, and/or tranformations that might invalidate the length in length-prefixed strings) to be considered a robust way to program IPP. The number of attributes and the speed requirements are not sufficient to justify attempting such a risky optimization. And the performance improvement couldn't possibly measured with respect to a single POST, let alone that document data. Printers can't print jobs any faster than they can print pages. Even a 240 page per minute printer, can't be accepting jobs any faster than 4 per second! And the faster the printer, the longer the jobs. We've probably spend more human time on this issue that will be saved by all the implementations of IPP. Simply copy characters from the buffer and form proper tokens. If a token crosses a buffer boundary, advance to the next buffer and continue copying characters to form the token. The advantages of text tokens have been expressed by Larry (promoting private to public attributes, and debugging) and the advantages of length-prefixed strings is in extensibility to more complex data types, such as sets of attributes, without impacting V1.0 spec and V1.0 implementations. Lets keep text and length-prefixed strings and don't attempt to parse buffers. Tom At 14:37 06/23/97 PDT, Robert Herriot wrote: >After thinking about the partial buffer problem with respect to the >three possible encodings, the ONLY ENCODING THAT SEEMS TO HAVE A PROBLEM >IS THE ONE WE CHOSE. That is why we need to continue the discussion. > >In my last email I described the algorithm for the HTTP-like version >which fills a buffer upto CRLF, thus avoiding buffer overlap issues. > >With the binary encoding, I would expect that it would fread the two >byte length (call it n) and then fread n bytes of name/value in order >to avoid messy buffer overlaps. It would do this twice for each >parameter. So the reading of bytes would be intimately associated with >the parsing. But Sylvan's GrabAttr seems to assume a buffer that >already has the name and the attribute. How does Sylvan do this >without parsing the two lengths at the high level and in GrabAttr. > >Sylvan, could you give more details about how you handle the buffer >overlap problem with binary encoding? I have suggested a method >above, but you seem to have some other way. > >Bob Herriot > >> From SBUTLER@hpbs2024.boi.hp.com Mon Jun 23 09:04:34 1997 >> From: "Sylvan Butler" >> X-Real-Sender: SYLVAN >> Organization: Hewlett-Packard, Boise >> To: Robert.Herriot@Eng (Robert Herriot) >> Date: Mon, 23 Jun 1997 10:02:48 -0700 >> Subject: Re: IPP>PRO: sorry, but binary is better >> CC: ipp@pwg.org >> Priority: normal >> X-mailer: Pegasus Mail v3.31 >> Content-Length: 2098 >> X-Lines: 53 >> >> >This buffer problem exists for both the current IPP proposal and for >> >the previous binary proposal that you prefer. The two byte binary >> >integer could span buffers and a parameter name or value buffer could >> >> The upper layer can trivially ensure that the buffer contains X bytes >> of data, where X is large enough to hold at least a two byte attribute >> name and a two byte value length. Once the lengths are known then >> the proper amount for values is easy to collect. >> >> With an ASCII encoding the upper layer has to guess, or check for >> proper terminators. >> >> >buffers seems rather messy to me because the break can occur during any >> >element. It sees like a good place to generate lots of occasional bugs. >> >> Yes, except with binary it is not messy at all. >> >> >putting a " " (space character) just after the last character in the >> >buffer to stop the scan-for-space algorithm. >> >> That would work, if you must scan. >> >> >You also observed that with CRLF and a maximum line length, it is easy >> >to ensure that a buffer has a full unit because functions, such as fgets >> >read upto the next CRLF. Perhaps we need to revisit the solution that >> >> Unless you have to interoperate with implementations that visually >> checked (instead of looking at a sniffer hex dump) for "lines". Like >> with HTTP servers today, even though the spec reads CRLF you still >> find CR (from mac?), LF (from unix?) and the desired CRLF (I wouldn't >> be suprised to find some LFCR's out there). >> >> > CR in a value is represented by =0C >> > LF in a value is represented by =0A >> > = in a value is represented by =3D >> >> You will probably need to escape anything less than %x20 and perhaps >> anything greater than %x7E. >> >> In fact, instead of developing our own escape rules we should, as you >> probably did, just pick one. >> >> This is just so ugly, considering the purpose is for two computers to >> talk to each other over a link that is 8-bit clean. >> >> >Perhaps this pure textual solution is easier to program once you consider >> >the buffer problem. >> >> I don't find it so. >> >> sdb >> >> | Sylvan Butler | sbutler@boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 | >> > > From ipp-archive Wed Jun 25 10:06:09 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA03995 for ipp-outgoing; Wed, 25 Jun 1997 10:01:50 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-dir-schema-01.txt Date: Wed, 25 Jun 1997 10:06:02 -0400 Message-ID: <9706251006.aa07395@ietf.org> Sender: ipp-owner@pwg.org Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Printing Protocol Working Group of the IETF. Title : Internet Printing Protocol/1.0: Directory Schema Author(s) : K. Carter, S. Isaacson Filename : draft-ietf-ipp-dir-schema-01.txt Pages : 8 Date : 06/24/1997 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 using Internet tools and technology. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (ISO/IEC 10175 DPA) standard. Although DPA specifies both end user and administrative features, IPP version 1.0 is focused on end user functionality. Although DPA specifies both end user and administrative features, IPP version 1.0 is focused only on end user functionality. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-dir-schema-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-dir-schema-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipp-dir-schema-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970624142717.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-dir-schema-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-dir-schema-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970624142717.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-archive Wed Jun 25 10:19:27 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA04235 for ipp-outgoing; Wed, 25 Jun 1997 10:13:45 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-model-02.txt Date: Wed, 25 Jun 1997 10:05:57 -0400 Message-ID: <9706251005.aa07370@ietf.org> Sender: ipp-owner@pwg.org Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Printing Protocol Working Group of the IETF. Title : Internet Printing Protocol/1.0: Model and Semantics Author(s) : R. Debry, T. Hastings, R. Herriot, S. Isaacson, P. Powell Filename : draft-ietf-ipp-model-02.txt Pages : 85 Date : 06/24/1997 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 using Internet tools and technology. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (ISO/IEC 10175 DPA) standard. Although DPA specifies both end user and administrative features, IPP version 1.0 is focused only on end user functionality. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-model-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-model-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipp-model-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970624142323.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-model-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-model-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970624142323.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-archive Wed Jun 25 10:36:10 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA05024 for ipp-outgoing; Wed, 25 Jun 1997 10:31:25 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Old-To: IETF-Announce@ietf.org Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-model-02.txt Date: Wed, 25 Jun 1997 10:05:57 -0400 X-Orig-Sender: cclark@ietf.org Message-Id: <9706251005.aa07370@ietf.org> X-Loop: forwarded by kamrang@hiva.com To: kghane@intermec.com Sender: ipp-owner@pwg.org Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Printing Protocol Working Group of the IETF. Title : Internet Printing Protocol/1.0: Model and Semantics Author(s) : R. Debry, T. Hastings, R. Herriot, S. Isaacson, P. Powell Filename : draft-ietf-ipp-model-02.txt Pages : 85 Date : 06/24/1997 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 using Internet tools and technology. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (ISO/IEC 10175 DPA) standard. Although DPA specifies both end user and administrative features, IPP version 1.0 is focused only on end user functionality. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-model-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-model-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipp-model-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970624142323.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-model-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-model-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970624142323.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-archive Wed Jun 25 11:51:10 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA05618 for ipp-outgoing; Wed, 25 Jun 1997 11:46:46 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Old-To: IETF-Announce@ietf.org Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-dir-schema-01.txt Date: Wed, 25 Jun 1997 10:06:02 -0400 X-Orig-Sender: cclark@ietf.org Message-Id: <9706251006.aa07395@ietf.org> X-Loop: forwarded by kamrang@hiva.com To: kghane@intermec.com Sender: ipp-owner@pwg.org Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Printing Protocol Working Group of the IETF. Title : Internet Printing Protocol/1.0: Directory Schema Author(s) : K. Carter, S. Isaacson Filename : draft-ietf-ipp-dir-schema-01.txt Pages : 8 Date : 06/24/1997 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 using Internet tools and technology. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (ISO/IEC 10175 DPA) standard. Although DPA specifies both end user and administrative features, IPP version 1.0 is focused on end user functionality. Although DPA specifies both end user and administrative features, IPP version 1.0 is focused only on end user functionality. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-dir-schema-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-dir-schema-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipp-dir-schema-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970624142717.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-dir-schema-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-dir-schema-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970624142717.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-archive Wed Jun 25 19:01:16 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA07057 for ipp-outgoing; Wed, 25 Jun 1997 18:56:27 -0400 (EDT) Message-Id: <3.0.1.32.19970625100926.00aa4920@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 25 Jun 1997 10:09:26 PDT To: ipp@pwg.org, paulmo@microsoft.com, BUTLER@hpbs2024.boi.hp.com, szilles@adove.com From: Carl-Uno Manros Subject: IPP> PRO - PWG Phone Conference TOMORROW Cc: lisa@cp10.es.xerox.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk PWG Phone Conference on IPP Protocol - June 26, 1 - 3 pm EST (10 -12 PST) Due to the fact that several experts interested in the protocol encoding issue are not present in the current meeting in Nashua, NM we will hold a combined face-to-to-face and phone conference tomorrow. Here are the numbers to dial in. Dial-in number: 1-800-857 5607 Passcode: cmanros DO PHONE IN IF YOU ARE INTERESTED IN THIS SUBJECT I expect to here from Andy, Paul and Sylvan in particular. Hearing from our co-chair would also be nice... 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 Wed Jun 25 21:41:18 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA07661 for ipp-outgoing; Wed, 25 Jun 1997 21:36:47 -0400 (EDT) Message-Id: <3.0.1.32.19970625161144.00acead0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 25 Jun 1997 16:11:44 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> URGENT - PLEASE CALL IN THURSDAY Cc: szilles@adobe.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk PWG Phone Conference on IPP Protocol - June 26, 1 - 3 pm EST (10 -12 PST) Due to the fact that several experts interested in the protocol encoding issue are not present in the current meeting in Nashua, NM we will hold a combined face-to-to-face and phone conference tomorrow. Here are the numbers to dial in. Dial-in number: 1-800-857 5607 Passcode: cmanros DO PHONE IN IF YOU ARE INTERESTED IN THIS SUBJECT I expect to here from Andy, Paul and Sylvan in particular. Hearing from our co-chair would also be nice... 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 Wed Jun 25 21:41:19 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA07660 for ipp-outgoing; Wed, 25 Jun 1997 21:36:47 -0400 (EDT) Message-Id: <3.0.1.32.19970625161550.00907100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 25 Jun 1997 16:15:50 PDT To: Cynthia Clark , ipp@pwg.org From: Carl-Uno Manros Subject: IPP> Re: New I-Ds from the IPP WG - RESENT DUE TO NON-REPLY Cc: cclark@ietf.org, szilles@adobe.com, Harald.T.Alvestrand@uninett.no, Keith Moore In-Reply-To: <9706231617.aa12916@ietf.org> Illegal-Object: Syntax error in References: value found on alpha.xerox.com: References: ^-illegal end of message identification Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_867305750==_" Sender: ipp-owner@pwg.org Precedence: bulk --=====================_867305750==_ Content-Type: text/plain; charset="us-ascii" At 01:17 PM 6/23/97 PDT, Cynthia Clark wrote: > >hi carl-uno, > >please excuse me for the delay as i've just >returned here from a vacation. > >these filenames are fine. > >later > >cynthia > Cynthia, thanks, attached is the IPP Security document. Regards, Carl-Uno Co-chair IETF WG for IPP --=====================_867305750==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="draft-ietf-ipp-security-00.txt" INTERNET-DRAFT Roger deBry IBM Corporation Jerry Hadsell IBM Corporation Daniel Manchala Xerox Corporation Xavier Riley Xerox Corporation John Wenn Xerox Corporation June 12, 1997 Internet Printing Protocol/1.0: Security draft-ietf-ipp-security-00.txt Status of this memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 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 DeBry, Hadsell, Manchala, Riley, Wenn [Page 1] Expires December 12, 1997 INTERNET-DRAFT IPP/1.0: Security June 12, 1997 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 Internet Printing Protocol/1.0: Directory Schema This documentis the `Internet Printing Protocol/1.0: Security' document. DeBry, Hadsell, Manchala, Riley, Wenn [Page 2] Expires December 12, 1997 INTERNET-DRAFT IPP/1.0: Security June 12, 1997 Table of Contents 1.0 Introduction .........................................4 2.0 Security Threats and Attacks .........................4 2.1 Threats ...........................................5 2.2 Methods of Attack .................................5 3.0 Internet Printing ....................................6 3.1 Printer and Client in the Same Security Domain ....7 3.2 Printer and client in Different Security Domains ..7 3.3 Print-by-Reference ................................7 3.3.1 Unprotected Documents ........................8 3.3.2 Protected Documents ..........................8 3.4 Common Security Scenarios .........................8 3.4.1 No Security ..................................8 3.4.2 Message Protection During Transmission .......8 3.4.3 Client Authentication and Authorization ......9 3.4.4 Mutual Authentication, Authorization and Message Protection ...................................9 4.0 Security Services ....................................9 5.0 Applying security to IPP operations .................10 5.1 Create-Job .......................................11 5.2 Send-Document ....................................11 5.3 Print-Job ........................................11 5.4 Cancel-Job .......................................11 5.5 Validate .........................................12 5.6 Get-Jobs .........................................12 5.7 Get-Attributes ...................................12 5.8 Print-URI ........................................12 5.9 Send-URI .........................................12 6.0 Comments on Existing Security Technologies ..........12 6.1 Recommended Security Mechanisms ..................14 7.0 Appendix - Specific Features of Various Technologies 15 7.1 S/MIME: (Secure/Multipurpose Internet Mail Ext.)..15 7.2 Transport Layer Security 1.0 (TLS) ...............15 7.3 SASL (Simple Authentication and Security Layer) ..16 7.4 Digest Access Authentication .....................17 8.0 References ..........................................20 9.0 Authors' Addresses ..................................21 DeBry, Hadsell, Manchala, Riley, Wenn [Page 3] Expires December 12, 1997 INTERNET-DRAFT IPP/1.0: Security June 12, 1997 1.0 Introduction The purpose of this document is to describe security considerations for the Internet Printing Protocol (IPP). Internet Printing is the application of Internet technology to network printing. Using Internet technology, users want to be able to locate printers, install and configure printer software, query printers for capabilities and status, and submit and track print jobs. The Internet Printing Protocol defines the network interface for many of these functions. 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 Transport Layer Security (TLS)[draft-tls] and Digest Access Authentication [rfc2069]in HTTP. 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 not to 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, would 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. 2.0 Security Threats and Attacks DeBry, Hadsell, Manchala, Riley, Wenn [Page 4] Expires December 12, 1997 INTERNET-DRAFT IPP/1.0: Security June 12, 1997 Before discussing security services specifically as they relate to IPP, it will be useful to quickly discuss and categorize security threats in a general way and discuss the means by which these threats are carried out. 2.1 Threats Security threats fall into the following broad categories: Resource stealing: The unauthorized use of facilities, such as printers, specific printer features, media, fonts, or logos etc. resulting in some value to the perpetrator. Vandalism: Similar to resource stealing, but usually without gain to the perpetrator. Often results in denial of service to other authorized users. Leakage: The acquisition of information by unauthorized interceptors during transmission. Tampering: The interception and altering of information during transmission. 2.2 Methods of Attack The methods by which security violations can be perpetrated depend upon obtaining access to existing communication channels or establishing channels that masquerade as connections to a user with some desired authority. These methods are: Masquerading: Submission of print jobs or performing other IPP operations using the identity and password of another user without their authority, or by using an access token or capability after the authorization to use it has expired. Eavesdropping: Obtaining copies of documents and job instructions without authority, either directly from the network or by examining information that is inadequately protected in storage. Document tampering: Intercepting documents or other print job related information and altering their contents before passing them on to the printer or print server. DeBry, Hadsell, Manchala, Riley, Wenn [Page 5] Expires December 12, 1997 INTERNET-DRAFT IPP/1.0: Security June 12, 1997 Replaying: Intercepting and storing print jobs or documents, and have them submitted again later. Example: Stock Certificate Printing. Protection against replaying requires the use of a nonce and/or time stamp. Spamming: Sending irrelevant or nonsensical print jobs or other IPP operations to a printer or print server with the objective of overloading the system and preventing legal users from getting service. Malicious Document Content Code: Sending documents that contain malicious code which will bring the printer software into a loop or even ruin hardware components in the print device. Example: Using PostScript as a programming language to run the printer into an infinite loop. 3.0 Internet Printing Environments It is now important to understand how the threats and attacks we have discussed above apply to the various environments in which IPP will operate. The IPP Model encapsulates the important elements required for printing into three simple objects, the Printer, the Job, and the Document. The Printer represents the functions associated with a physical output device along with the spooling, scheduling, and multiple output device management often associated with a print server. An IPP client uses the IPP protocol to invoke operations on IPP objects on other network nodes. The initial security needs of IPP are derived from two primary considerations. First, the printing environments described in this document take into account the fact that the client, the Printer, and the document to be printed may all exist in different security domains. When objects are in different security domains the requirements for authentication and message protection are much stronger than when they are in the same domain. Secondly, the sensitivity and value of the content being printed will vary. For example, a publicly available document does not require the same level of privacy that a payroll document requires. There are at least two parties that have an interest in the value of the information being printed, the person asking to have the information printed and the person who originated the DeBry, Hadsell, Manchala, Riley, Wenn [Page 6] Expires December 12, 1997 INTERNET-DRAFT IPP/1.0: Security June 12, 1997 information. This brings into the picture the need to worry about copyrights and protection of the content. Security attacks are now described for the following IPP environments. Where examples are provided they should be considered illustrative of the environment and not an exhaustive set. Not all of these environments will necessarily be addressed in initial implementations of IPP. 3.1 Client and Printer in the Same Security Domain This environment is typical of internal networks where traditional office workers print the output of personal productivity applications on shared work-group printers, or where batch applications print their output on large production printers. Although the identity of the user may be trusted in this environment, a user might want to protect the content of a document against such attacks as eavesdropping, replaying or tampering. 3.2 Client and Printer in Different Security Domains Examples of this environment include printing a document created by the client on a publicly available printer, such as at a commercial print shop; or printing a document remotely on a business partner's printer. This latter operation is functionally equivalent to sending the document to the business partner as a facsimile. Printing sensitive information on a Printer in a different security domain requires strong security measures. In this environment authentication of the printer is required as well as protection against unauthorized use of print resources. Since the document crosses security domains, protection against eavesdropping and document tampering are also required. It will also be important in this environment to protect Printers against spamming and malicious document content code. 3.3 Print by Reference When the document is not stored on the client, printing can be done by reference. That is, the print request can contain a reference, or pointer, to the document instead of the actual document itself. If the client physically gets the document before it prints it, then this defaults to one of the previous cases. DeBry, Hadsell, Manchala, Riley, Wenn [Page 7] Expires December 12, 1997 INTERNET-DRAFT IPP/1.0: Security June 12, 1997 3.3.1 Unprotected Documents In many cases, documents to be printed are literally available to anyone. Documents, such as this Internet Draft which are stored on anonymous FTP sites, are good examples of this. No security mechanisms are required to protect access to these document. 3.3.2 Protected Documents Clearly, there are cases where the nature of a document requires that access to it be protected by some authentication and/or authorization mechanism, or where the right to print the document must be paid for. This would be the case for sensitive or confidential information, or where documents are copyrighted or sold for profit. Unauthorized access to content is a major concern in this environment. Protection against eavesdropping, document tampering and unauthorized access to the document are also concerns if the content is sensitive. 3.4 Common Security Scenarios As discussed earlier in this document,we cannot anticipate the security levels or the specific threats that any given IPP print administrator may be concerned with. Security policies might vary from very strong, to very weak, to none at all, and corresponding security mechanisms will be required. In this section we will describe what we believe to be four common usage scenarios. 1) No security at all 2) Message protection during transmission 3) Client authentication and authorization 4) Mutual authentication, authorization, and message protection 3.4.1 No Security If the server requires no authorization and the client wants no message protection the client can send the print job, i.e., the job content and the job attributes without invoking any security mechanisms. The printer will print the job for the client. Print by reference also works well in this environment as long no security mechanisms are required to access the documents to be printed. 3.4.2 Message Protection During Transmission DeBry, Hadsell, Manchala, Riley, Wenn [Page 8] Expires December 12, 1997 INTERNET-DRAFT IPP/1.0: Security June 12, 1997 There are two types of security that could be used to provide message protection. These are channel security and object security. In the first case, the transport medium must be made secure by mutual authentication. Then everything between the client and server is encrypted by the transport medium. The transport medium can be either of the following: transport layer security (TLS) or network layer security (IPSec). In the 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. The most widely used object security mechanisms are S/MIME [draft-smime], S-HTTP and PGP/MIME. 3.4.3 Client Authentication and Authorization This scenario requires client authentication which may also be used for authorization. A user ID and password may be used for authorization purposes, and may be encrypted by the lower security layer. S/MIME and TLS are good examples of this. TLS supports both one sided and mutual authentication and can also be used in this scenario. 3.4.4 Mutual Authentication, Authorization and Message Protection This scenario requires mutual authentication and message protection. TLS and Secure Sockets Layer version 3 (SSL3) are good channel level security providers in this category. 4.0 Security Services Now that we have decribed the security threats that exist in the various environments in which IPP may operate, we will discuss the security services that are generally available to counter these threats. Security in general encompasses the software and hardware functionality to deliver the following services: Authorization: Only authorized users should be able to gain access to systems, applications, data or services. Authorization may be based on authenticated identity, location, time of day, role, possession of a physical device or token, or other criterion. Authentication: Authentication is the process of proving who a user or system is, and may apply to individual identities, roles, DeBry, Hadsell, Manchala, Riley, Wenn [Page 9] Expires December 12, 1997 INTERNET-DRAFT IPP/1.0: Security June 12, 1997 or groups. Authentication may be done with traditional methods such as passwords or challenge-response mechansisms, or with publicly recognized methods such as certificates. Message Protection: Access control protects data when it is within a secure system environment. However, when data must travel outside of a secure system, such as across a public network, it needs to be protected. Message protection includes the following: Data origin authentication guarantees that the data originates from an identified source. Privacy protection guarantees that the data cannot be observed except by authorized parties. Integrity protection guarantees that the data cannot be undetectably modified except by authorized parties. Non-repudiation protection guarantees that actions taken on data cannot be denied by the subjects performing those actions. Liability: Responsibility of the user for the printed content. This holds the user accountable for making payments, usage of special resources like transparencies, color printing, etc. The printer is also responsible for the services performed and will be held responsible for it. Provability of Service: The printer should be able to prove that it performed correctly according to the job attributes which the client/user had indeed issued. Example: The printer should be able to prove that the job request was indeed a monochrome when the user claims it issued a color copy. Provability of service requires non-repudiation. Payment and Accounting System: The Printer should insure that the wong person is not charged when someone issues a print request. 5.0 Applying Security to IPP Operations An IPP client uses the IPP protocol to invoke operations on remote Printer and Job objects. We now need to understand which security services are required for the various IPP operations. The IPP Operations are: DeBry, Hadsell, Manchala, Riley, Wenn [Page 10] Expires December 12, 1997 INTERNET-DRAFT IPP/1.0: Security June 12, 1997 Create-Job - Create an instance of a Job object Send-Document - Append enclosed data to a Job object Print-Job - Print the enclosed job, with attributes Cancel-Job - Cancel a previously submitted print job Validate - Validate attributes for a specific object Get-Jobs - Return job queue information for a Printer object Get-Attributes - Return attribute information for a Printer or Job object Print-URI - Print a document by reference Send-URI - Append enclosed document reference to a Job object Every time a new connection with a Printer Object or with a Job Object is opened a new security context must established. An administrator may set up different security requirements for different operations, i.e. a user may be able to query a printer, but not submit a job. Once a Job is created, the same (or greater) level of security will be required to perform additional operations on that job. 5.1 Create-Job When creating a print job, authentication of the client and the Printer are primary security considerations. Client authentication, along with authorization, protects against unauthorized use of print resources. Printer authentication guarantees the identitity of the remote Printer. 5.2 Send-Document When sending document content to the Printer, message protection is the primary security service required. 5.3 Print-Job PrintJob combines the functions of CreateJob and SendDocument, therefore authentication, authorization, and message protection are all required. 5.4 Cancel-Job Cancel-Job is only used to cancel a job. An end user may only be allowed to cancel his or her own print jobs. Therefore authentication is required to protection against unauthorized cancellation of a job. DeBry, Hadsell, Manchala, Riley, Wenn [Page 11] Expires December 12, 1997 INTERNET-DRAFT IPP/1.0: Security June 12, 1997 5.5 Validate Validate is used to validate the attributes of a remote object. Administrators may choose to restrict the ability for certain end users to see the attributes of a Printer, so authentication and authorization are required services. 5.6 Get-Jobs The level of security associated with the GetJobs operation depends on the policy set by an administrator. One common policy is for the complete job queue to be returned to anyone who asks. This policy requires no security. For more secure Printers, a common policy is to list details only on the print jobs owned by the end user, while giving little or no details about other jobs. This policy requires client authentication and authorization to match the client to the print jobs. 5.7 Get-Attributes An administrator should be able to establish the level of security associated with getting the attributes of a printer. 5.8 Print-URI Print-URI is like Print-Job except that only a reference to the document to be printed is sent in the request. Thus the Printer must fetch the document from the given URI in order to print the job. In IPP version 1.0 we only allow unprotected (see section 3.3.1) documents to be printed by reference. Additional, as yet undefined security mechanisms are required to print a protected document by reference. 5.9 Send-URI Send-URI is like send-Document except that only a reference to the document to be printed is sent in the request. This operation has the same security concerns as Print-URI. Issue: Does asynchronous notification require any security? 6.0 Comments on existing security technologies DeBry, Hadsell, Manchala, Riley, Wenn [Page 12] Expires December 12, 1997 INTERNET-DRAFT IPP/1.0: Security June 12, 1997 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. TLS Provides channel level security. SSL 2 and SSL 3 - Secure Socket Layer: Proprietary solution initially by Netscape, but TLS is very close. Provides channel level security. 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. PGP/MIME provides object level security. 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. S/MIME provides object level security. 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 for IPP. HTTP 1.1 Digest Access Authentication, RFC 2069: This provides some limited security services, mainly only client side authentication. It transmits a cryptographic digest derived from the user name, password, and a server generated challenge. 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. PEM - Privacy Enhanced Mail. Specified in IEF RFCs 1421-1424. It was an early standard for securing email that specified a message format and a hierarchy structure for certification authorities (CAs). MOSS - MIME Object Security Services. Offers the same functionality as PEM, but does not force a single trust model, and allows the identification of users by names that don't have any relationship to X.500, such as E-mail addresses. DeBry, Hadsell, Manchala, Riley, Wenn [Page 13] Expires December 12, 1997 INTERNET-DRAFT IPP/1.0: Security June 12, 1997 IPSec - IP Security is an IETF standards track protocol for security on the IP layer. It consists of two separate mechanisms. The IP Authentication Header (AH) and the IP Encapsulating Security Payload (ESP). They can be used together or separately. The IP Authentication header provides integrity and authentication of IP datagrams. The IP Encapsulating Security Payload provides integrity, authentication and privacy. IPSec allows for either host keys or user keys to be used in security. IPSec can satisfy the IPP requirements for integrity and privacy. IPP Authentication, however, would require both IPSec use user keys and that the IPP application request use their own IPSec security association. Both requirements are recommended by IPSec but are not required. 6.1 Recommended Security Mechanisms In order to provide security for the four common usage scenarios defined earlier, we recommend that implementations provide the following, which are suitable for use with HTTP 1.1. - No Security - nothing is required - Message Protection during transmission - TLS - IPSec - Client authentication and authorization - HTTP 1.1 Digest access authentication - TLS - Mutual authentication, authorization and message protection - TLS The security protocol used by a particular IPP operation will depend upon the security services provided by the Printer and the selection made by the client. This requires that the right handshake messages be passed. These are described in more detail in the Appendix. Directory and Printer attributes are required so that an end user can query the level of security supported, but these are yet to be defined. DeBry, Hadsell, Manchala, Riley, Wenn [Page 14] Expires December 12, 1997 INTERNET-DRAFT IPP/1.0: Security June 12, 1997 7.0 Appendix - Specific Features of various technologies 7.1 S/MIME: (Secure/Multipurpose Internet Mail Extensions) Security services and features offered: 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. Privacy (using encryption). Integrity is achieved by using hashing to detect message tampering. Provides anonymity by using anonymous e-mailers and gateways. The digital signature and the original message are placed in an encrypted digital envelope. Supports DES, Triple-DES, RC2. X.509 digital certificates supported. Supports PKCS #7(cryptographic message formatting, architecture for certificate-based key management) and #10(message for certification request). Usage, implementation and interoperability: Used to securely transmit e-mail messages in MIME format. Public domain mailer RIPEM available. 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. Any two packages that implement S/MIME can communicate securely. Compatible with IMAP (Internet Message Access Protocol - RFC 1730). S/MIME works both on the Internet or any other e-mail environment. 7.2 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: DeBry, Hadsell, Manchala, Riley, Wenn [Page 15] Expires December 12, 1997 INTERNET-DRAFT IPP/1.0: Security June 12, 1997 Privacy: (optional). Uses symmetric keys. Encryption done by the TLS Record Protocol. The keys are generated for each connection by the TLS Handshake Protocol. Integrity: Using keyed MAC. Hash functions (SHA, MD5) are used for MAC computations. Authentication (Both one-sided and Mutual): The TLS Handshake Protocol uses public key cryptography. Encryption algorithms are negotiated. Usage, implementation and interoperability: Interoperability: Independent applications can be developed utilizing TLS and successfully exchange cryptographic parameters without knowledge of each others code. Cannot inter-operate with SSL 3.0 Extensibility: New encryption methods can be incorporated as necessary. Efficiency: To reduce the number of sessions that need to be established from scratch, TLS provides session caching scheme. Other operations: Compression, fragmentation is done by the TLS Record Protocol. Handshake protocol steps: Exchange hello messages to agree on algorithms, exchange random values, and check for session resumption. Exchange the necessary cryptographic parameters to allow the client and server to agree on a premaster secret. Exchange certificates and cryptographic information to allow the client and server to authenticate themselves. Generate a master secret from the premaster secret and exchanged random values. Provide security parameters to the record layer. 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. Note: The https protocol uses port 443 regardless of which security protocol version (TLS, SSL2, SSL3) it is using. Star (*) indicates optional messages. 7.3 SASL (Simple Authentication and Security Layer) SASL provides a method for adding authentication support to connection-based protocols. A command for identifying and authenticating a user and for (optionally) negotiating a security DeBry, Hadsell, Manchala, Riley, Wenn [Page 16] Expires December 12, 1997 INTERNET-DRAFT IPP/1.0: Security June 12, 1997 layer for subsequent protocol interactions is included with a protocol. Security services and features offered: (These are layers that SASL would call. One of these could be selected.) No security Integrity Privacy Security mechanisms: Kerberos GSS-API S/Key Handshaking protocol: 1. Client sends data 2. Server returns success* with additional data (challenge). Multiple authentication (s)* (Only one - the latest security layer exists during multiple authentication). 4. Registration procedures.* Note: SASL is not relevant for HTTP based protocols, but could be relevant to IPP, if IPP decides to later define an IPP specific protocol. 7.4 Digest Access Authentication [rfc2069] Digest Access Authentication is a proposed standard for weak authentication in HTTP 1.1. It is intended as a replacement for Basic Access Authentication found in HTTP 1.0. While Digest authentication is on the weak end of the security spectrum, it is a considerable improvement over the completely insecure Basic authentication. Security services and features offered: a. Client Authentication is provided for by a client username/password pair. A hash of the username/password (and other information) is sent from the client to the server. How the username/password is created is outside the protocol. b. Integrity (optional) is provided for by a hash of the entity body, username/password, selected entity headers (and other information). This can be done on either messages from the client or from the server. DeBry, Hadsell, Manchala, Riley, Wenn [Page 17] Expires December 12, 1997 INTERNET-DRAFT IPP/1.0: Security June 12, 1997 c. By default, the hash uses MD5. However, there are provisions for other algorithms. d. Digest authentication is vulnerable to replay attacks, man- in-the-middle attacks, server spoofing, and attacks on the stored password on the server. Well chosen implementations can minimize, but not eliminate the vulnerability. Usage, implementation and interoperability: a. This is used by web servers and clients to pass authentication information. b. This is a proposed feature addition to HTTP 1.1. As such, it is limited to HTTP 1.1 implementations (currently a small number). c. Different implementations have proven interoperable. Handshake protocol steps: a. Client asks for an access-protected object and an acceptable Authorization header is not sent. b. The Server responds with a "401 Unauthorized" status code, and a WWW-Authenticate header. The header has the fields: * realm - a string indicating the context for the authorization * domain [optional] - a list of URIs the authentication is used for * nonce - a data string used in authentication * opaque [optional] - a data string supplied by the server * stale [optional] - a flag indicating the previous effort used a stale nonce * algorithm [optional] - a token indicating the hash algorithm to use c. The Client then asks the User for the username/password (if needed). It then calculates the needed information and retries the request with a Authorization header. The header has the fields: * username - the string supplied by the user * realm - the value supplied by the server * nonce - the value supplied by the server * uri - the URI requested * response - the response hash (see below) * digest [optional] - the digest hash (see below), used for integrity checking * algorithm [optional] - the algorithm used * opaque - the value supplied by the server d. If authorization is granted, the Server responds with result of query, DeBry, Hadsell, Manchala, Riley, Wenn [Page 18] Expires December 12, 1997 INTERNET-DRAFT IPP/1.0: Security June 12, 1997 optionally including a AuthenticationInfo header. The header has the fields: * nextnonce [optional] - the nonce the client should use for the next request * digest [optional] - the digest hash (see below) used for integrity checking. Calculation of hashes The response hash uses the values of username, realm, password, nonce, HTTP method, and URI. It is calculated by: response = Hash(Hash(A1) ":" nonce ":" Hash(A2)) A1 = username ":" realm ":" password A2 = method ":" URI The digest hash uses the values of username, realm, password, nonce, HTTP method, date, URI, content-type, content-length, content-encoding, last-modified, expires, and the entity body. The values of content-type, content-length, content-encoding, last-modified and expires are all taken from the HTTP headers, and are blank if not defined. The digest hash can be sent.by either the client or the server. The digest hash is calculated by: digest = Hash(Hash(A1) ":" nonce ":" method ":" date ":" entity-info ":"Hash(entity-body)) entity-info = Hash(URI ":" content-type ":" content-length ":" content-encoding ":" last-modified ":" expires) DeBry, Hadsell, Manchala, Riley, Wenn [Page 19] Expires December 12, 1997 INTERNET-DRAFT IPP/1.0: Security June 12, 1997 8.0 References: [rfc2069] J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, E. Sink, L. Stewart, _An Extension to HTTP: Digest Access Authentication_, RFC-2069, Jan 1997. [draft-smime] S. Dusse, _S/MIME Message Specification_, , April 1997. [draft-tsl] T. Dierks, C. Allen, _The TLS Protocol_, , March 24, 1997. DeBry, Hadsell, Manchala, Riley, Wenn [Page 20] Expires December 12, 1997 INTERNET-DRAFT IPP/1.0: Security June 12, 1997 9.0 Authors' Addresses Roger deBry HUC/003G IBM Corporation P.O. Box 1900 Boulder, CO 80301-9191 rdebry@us.ibm.com Jerry Hadsell 1130 IBM Corporation Rt. 100 Somers, N.Y. 10589 hadsell@us.ibm.com Daniel Manchala Xerox Corporation 701 Aviation Blvd. El Segundo, CA 90245 manchala@cp10.es.xerox.com Xavier Riley Xerox Corporation 701 Aviation Blvd. El Segundo, CA 90245 xriley@cp10.es.xerox.com John Wenn Xerox Corporation 701 Aviation Blvd. El Segundo, CA 90245 jwenn@cp10.es.xerox.com Other Contributors Scott Isaacson, Novell Carl-Uno Manros, Xerox DeBry, Hadsell, Manchala, Riley, Wenn [Page 21] Expires December 12, 1997 --=====================_867305750==_ Content-Type: text/plain; charset="us-ascii" 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 --=====================_867305750==_-- From ipp-archive Thu Jun 26 01:06:21 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA09694 for ipp-outgoing; Thu, 26 Jun 1997 01:01:58 -0400 (EDT) Message-Id: <9706260502.AA01768@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, 25 Jun 1997 21:59:40 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> First draft Mapping of LPR/LPD to IPP in I-D format Sender: ipp-owner@pwg.org Precedence: bulk I've posted a first draft for an Internet Draft of the Mapping from LPR/LPD as specfied in RFC 1179 to IPP in: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ -rw-r--r-- 1 pwg pwg 30208 Jun 26 04:57 lpd-ipp.doc -rw-r--r-- 1 pwg pwg 18680 Jun 26 04:57 lpd-ipp.pdf -rw-r--r-- 1 pwg pwg 14245 Jun 26 04:58 lpd-ipp.txt The .pdf file has line numbers and Times Roman font. The .txt file is in I-D plain text format (though there are some 79 character lines for some reason). We will cover this Thursday, during IPP meeting. Tom From ipp-archive Thu Jun 26 12:51:27 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA11017 for ipp-outgoing; Thu, 26 Jun 1997 12:50:20 -0400 (EDT) Message-ID: From: "Sylvan Butler" X-Real-Sender: SYLVAN Organization: Hewlett-Packard, Boise To: Larry Masinter Date: Thu, 26 Jun 1997 10:49:51 -0700 Subject: Re: IPP>PRO: sorry, binary is better (?) CC: "'Scott Isaacson'" , ipp@pwg.org, rturner@sharplabs.com Priority: normal X-mailer: Pegasus Mail v3.31 Sender: ipp-owner@pwg.org Precedence: bulk >From: Larry Masinter >One of the things that is affected by this choice is the extension >mechanism. Suppose I want to try out a new feature. I'll do it >privately, and then I want to register it and make it public. If >I just pick a number, '43', I'm likely to hit someone else's number. >So maybe I'll use a number out of the private extension space, e.g., >'123451'. But then when I change from 'private extension' to >'public', I have to go back and recompile all my test code. Being able to run the same code both with a private extension and after the extension is formalized seems like a stretch. MIME types, for example, map all extensions to x-* and if/when a type becomes public, it is moved to the normal range. For private testing you can pick any extension you want. You chance of running into someone elses is minimal, because you are just testing. As I alluded in an earlier posting, I would propose extensibility for an all-binary encoding by creating a "vendor extension" attribute whose first at least four bytes of value must be checked by the vendor to determine if it is there extension. This won't help your code recompile issues, in fact, it is a little bit more complicated than just picking a range of IDs for vendor extensions. The advantage is that the range is virtually unlimited and the chances of collision are reduced. >This sounds pretty sloppy, but it's mainly what's done now for >many protocols and it's much more robust than numbers. Many (most?) protocols require all vendor extensions to start with a particular prefix, such as X- (MIME, SMTP/NNTP, ???). This is to ensure that the standardization process does not stomp on a vendor extension, and does not have to worry about such. >The protocol strings aren't human-language, they're just close enough to >language to believe that they're extensible in a more distributed >fashion. Perhaps to mistakenly believe... >In addition, the debugging and testing aspects shouldn't be ignored; >it's useful to be able to write a test program in a scripting language >or even to telnet to port 80 at a host and just type "GET url HTTP/1.0" >without having to count bytes. Which is quite unrealistic for what we are trying to accomplish, IMO. We are, after all, trying to send binary print job data. What is a few more binary bytes prepended to that binary stream? sdb | Sylvan Butler | sbutler@boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 | From ipp-archive Thu Jun 26 15:06:29 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA12151 for ipp-outgoing; Thu, 26 Jun 1997 15:02:03 -0400 (EDT) Message-ID: <33B2BCBD.1547@underscore.com> Date: Thu, 26 Jun 1997 15:02:21 -0400 From: Jeff Schnitzer Organization: Underscore, Inc. X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> RETRY: list mandatory vs optional operations 19970626 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk The following message from Sylvan Butler was rejected by the majordomo list software (I'm not sure why). /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: "Sylvan Butler" To: ipp@pwg.org Date: Thu, 26 Jun 1997 12:35:40 -0700 Subject: list mandatory vs optional operations 19970626 Mandatory operations on a printer: get operations (probably redundent with get attributes / operations???) print job validate job get jobs get attributes Mandatory operations on a job: cancel job get attributes Optional operations: print uri (printer) create job (printer) send document (job) send uri (job) sdb | Sylvan Butler | sbutler@boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 | From ipp-archive Fri Jun 27 10:36:40 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA15434 for ipp-outgoing; Fri, 27 Jun 1997 10:34:22 -0400 (EDT) Mime-Version: 1.0 Date: Fri, 27 Jun 1997 11:30:02 -0400 Message-ID: <0001BBBB.1337@digprod.com> From: cgordon@digprod.com (Charles Gordon) Subject: IPP> Suggestion for timed delay error code. To: 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 I think there is a potential problem with the Print-Job and Send-Document operations. The problem occurs when a printer receives a Print-Job or Send-Document request which it cannot accept because it is busy. When a client receives the busy response, it's natural action will be to try again. As far as I know, we have not defined a delay interval between retries of the Print-Job and Send-Document operations. So, there is no reason (in IPP as it is currently defined) why a client cannot simply retry immediately. Given the desire to print as soon as possible, it is quite likely that clients will be written to retry immediately, or after a very short delay. The problem occurs when many clients are trying to print to the same printer and all of them are retrying. At the very least, this will generate extra traffic. In addition, all of the retries may stress some of the light weight implementations of IP used in embedded systems. IPP should try to reduce unnecessary traffic when possible. The retry situation will happen all the time on low end printers which do not have a disk drive and therefore can only accept a single job at a time. Since they can only print one job at a time, if 10 clients are trying to print, 9 will get a busy indication and start retrying. It can also happen on higher end printers when they run out of spooling space, or if more clients try to establish connections than the printer is capable of handling similtaniously. I believe that this problem should be handled at the IPP level. There are some IPP operations which should be supported even if the printer cannot accept Print-Job and Send-Document requests. For example, client should be able to use the Validate-Job and Get-Attributes operations even if they cannot actually send jobs. This implies that the HTTP layer should not be the one to reject the connection request when the printer can no long accept more jobs. Instead, the request should be passed onto IPP which should either process it if it is able to, or reject it with an appropiate error code. At the last IPP meeting we defined an error code which indicates that the printer is not able to perform the indicated operation because of a lack of resources and that the problem is temporary. I suggest an additional parameter be passed back with this code which tells the client how long it should wait before it retries the operation. This will allow the printer to throttle down the clients if it starts to get overwhelmed with requests it cannot accept. Since the printer specifies the delay, it can change the delay to deal with the particular problem. For example, if the printer cannot print because it is out of paper, it could specify a delay of 5 minutes if this is typically how long it takes an operator to load more paper into the printer. If, on the other hande, the printer cannot accept jobs because its fuser has burned out, it may want to specify a much larger retry interval. The printer can also vary the delay according to how many clients are attempting to send jobs. The other alternative would be for the IPP protocol to specify a fixed delay the client must wait before retrying after it gets the out of resources error code from the printer. I suggest making the delay a variable interval under the control of the printer since this is more flexible. --- Charles From ipp-archive Fri Jun 27 19:26:45 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA16327 for ipp-outgoing; Fri, 27 Jun 1997 19:22:41 -0400 (EDT) Message-Id: <3.0.1.32.19970627161534.00ab5100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 27 Jun 1997 16:15:34 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - No PWG IPP Phone Conference on July 2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Hi, considering that many of us have just spent two full days together and that we are now all waiting for the outcome to be documented, plus the fact that the upcoming holiday will mean that many may not be around anyway, I have determined to cancel our weekly phone conference this coming week. The next PWG IP Phone Conference will be held on July 9, by which time we can expect to have documentated the Nashua, NH discussions. I wish you all a nice holiday! 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 Jun 27 20:26:45 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA16867 for ipp-outgoing; Fri, 27 Jun 1997 20:24:49 -0400 (EDT) Date: Fri, 27 Jun 1997 20:25:02 -0400 (EDT) From: JK Martin Message-Id: <199706280025.UAA09266@uscore.underscore.com> To: cgordon@digprod.com Subject: Re: IPP> Suggestion for timed delay error code. Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk This sounds like a great idea, Charles. Were you thinking perhaps that the IPP server would return a (new) error code, and that the response would include one or more (new) parameters that "suggest" to the client when it should attempt reconnection? I wish more service-oriented protocols had this kind of feature. ...jay ----- Begin Included Message ----- >From ipp-owner@pwg.org Fri Jun 27 10:42 EDT 1997 Date: Fri, 27 Jun 1997 11:30:02 -0400 From: cgordon@digprod.com (Charles Gordon) Subject: IPP> Suggestion for timed delay error code. To: ipp@pwg.org Content-Transfer-Encoding: 7bit I think there is a potential problem with the Print-Job and Send-Document operations. The problem occurs when a printer receives a Print-Job or Send-Document request which it cannot accept because it is busy. When a client receives the busy response, it's natural action will be to try again. As far as I know, we have not defined a delay interval between retries of the Print-Job and Send-Document operations. So, there is no reason (in IPP as it is currently defined) why a client cannot simply retry immediately. Given the desire to print as soon as possible, it is quite likely that clients will be written to retry immediately, or after a very short delay. The problem occurs when many clients are trying to print to the same printer and all of them are retrying. At the very least, this will generate extra traffic. In addition, all of the retries may stress some of the light weight implementations of IP used in embedded systems. IPP should try to reduce unnecessary traffic when possible. The retry situation will happen all the time on low end printers which do not have a disk drive and therefore can only accept a single job at a time. Since they can only print one job at a time, if 10 clients are trying to print, 9 will get a busy indication and start retrying. It can also happen on higher end printers when they run out of spooling space, or if more clients try to establish connections than the printer is capable of handling similtaniously. I believe that this problem should be handled at the IPP level. There are some IPP operations which should be supported even if the printer cannot accept Print-Job and Send-Document requests. For example, client should be able to use the Validate-Job and Get-Attributes operations even if they cannot actually send jobs. This implies that the HTTP layer should not be the one to reject the connection request when the printer can no long accept more jobs. Instead, the request should be passed onto IPP which should either process it if it is able to, or reject it with an appropiate error code. At the last IPP meeting we defined an error code which indicates that the printer is not able to perform the indicated operation because of a lack of resources and that the problem is temporary. I suggest an additional parameter be passed back with this code which tells the client how long it should wait before it retries the operation. This will allow the printer to throttle down the clients if it starts to get overwhelmed with requests it cannot accept. Since the printer specifies the delay, it can change the delay to deal with the particular problem. For example, if the printer cannot print because it is out of paper, it could specify a delay of 5 minutes if this is typically how long it takes an operator to load more paper into the printer. If, on the other hande, the printer cannot accept jobs because its fuser has burned out, it may want to specify a much larger retry interval. The printer can also vary the delay according to how many clients are attempting to send jobs. The other alternative would be for the IPP protocol to specify a fixed delay the client must wait before retrying after it gets the out of resources error code from the printer. I suggest making the delay a variable interval under the control of the printer since this is more flexible. --- Charles ----- End Included Message ----- From ipp-archive Sun Jun 29 02:42:05 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA19142 for ipp-outgoing; Sun, 29 Jun 1997 02:40:48 -0400 (EDT) Message-ID: <33B6036E.3FE6@parc.xerox.com> Date: Sat, 28 Jun 1997 23:40:46 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: Sylvan Butler CC: "'Scott Isaacson'" , ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP>PRO: sorry, binary is better (?) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk > Being able to run the same code both with a private extension and > after the extension is formalized seems like a stretch. MIME types, > for example, map all extensions to x-* and if/when a type becomes > public, it is moved to the normal range. a) it isn't a stretch, it's the real world. There is no single fixed point in time when 'the extension is formalized', extensions go through several stages of formalization, and there's no easy way to deploy code that can be replaced instantaneously even if it could. b) MIME types originally had the theory that they could map to x- and then move, but in fact, it's never worked that way. Either people started out without the x- prefix, or else they wound up keeping it (application/x-url-encoded) because changing would be too painful or just not worth it. The latest MIME registration draft, instead, recommends registering 'vnd....' as soon as possible, but of course, you can use it before the registration's been accepted, etc. > As I alluded in an earlier posting, I would propose extensibility for > an all-binary encoding by creating a "vendor extension" attribute > whose first at least four bytes of value must be checked by the > vendor to determine if it is there extension. Yes, this is similar to the proposal just to use OIDs, and is workable, but four bytes is not enough. (Witness the Macintosh four byte file type & creator fields, which wind up with some duplicates for file creators.) > Many (most?) protocols require all vendor extensions to start with a > particular prefix, such as X- (MIME, SMTP/NNTP, ???). This is to > ensure that the standardization process does not stomp on a vendor > extension, and does not have to worry about such. They may have originally been written that way, but that's not how they work in practice or in the most recent revisions. > >In addition, the debugging and testing aspects shouldn't be ignored; > >it's useful to be able to write a test program in a scripting language > >or even to telnet to port 80 at a host and just type "GET url HTTP/1.0" > >without having to count bytes. > > Which is quite unrealistic for what we are trying to accomplish, IMO. > We are, after all, trying to send binary print job data. What is a > few more binary bytes prepended to that binary stream? > > sdb If all you were doing was print job submission (which you're not) and if all of the PDLs you were submitting were binary (which they're not), then you'd have an argument. Larry From ipp-archive Sun Jun 29 19:57:15 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA20953 for ipp-outgoing; Sun, 29 Jun 1997 19:57:00 -0400 (EDT) Message-ID: <33B68884.71E0@byas.com> Date: Sun, 29 Jun 1997 16:08:36 +0000 From: AlBrahme X-Mailer: Mozilla 3.0 (Win95; U) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> tiff-f format & ipp1 References: <9706170004.AA06363@zazen.cp10.es.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk The ipp1 (formerly swp) protocol says that the attribute Document-Format values are taken from RFC 1759. RFC 1759 has the langTIFF listed but not TIFF-F format used by fax community. I would like ipp1 to include specifically TIFF-F format also so that ipp1 fax servers can be implemented easily by accepting only TIFF-F formats. We can reserve the value of 47 for TIFF-F in this case. thanks /al From ipp-archive Mon Jun 30 08:42:23 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA22212 for ipp-outgoing; Mon, 30 Jun 1997 08:40:09 -0400 (EDT) Mime-Version: 1.0 Date: Mon, 30 Jun 1997 09:36:39 -0400 Message-ID: <0001BE1C.1337@digprod.com> From: cgordon@digprod.com (Charles Gordon) Subject: Re[2]: IPP> Suggestion for timed delay error code. To: JK Martin 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 At the last week's IPP conference an error code which indicates the printer is temporarily out of a resource was defined. We could add a new delay attribute to that error code, or we could create a new error code and attribute. --- Charles ______________________________ Reply Separator _________________________________ Subject: Re: IPP> Suggestion for timed delay error code. Author: JK Martin at Internet Date: 6/27/97 8:25 PM This sounds like a great idea, Charles. Were you thinking perhaps that the IPP server would return a (new) error code, and that the response would include one or more (new) parameters that "suggest" to the client when it should attempt reconnection? I wish more service-oriented protocols had this kind of feature. ...jay ----- Begin Included Message ----- >From ipp-owner@pwg.org Fri Jun 27 10:42 EDT 1997 Date: Fri, 27 Jun 1997 11:30:02 -0400 From: cgordon@digprod.com (Charles Gordon) Subject: IPP> Suggestion for timed delay error code. To: ipp@pwg.org Content-Transfer-Encoding: 7bit I think there is a potential problem with the Print-Job and Send-Document operations. The problem occurs when a printer receives a Print-Job or Send-Document request which it cannot accept because it is busy. When a client receives the busy response, it's natural action will be to try again. As far as I know, we have not defined a delay interval between retries of the Print-Job and Send-Document operations. So, there is no reason (in IPP as it is currently defined) why a client cannot simply retry immediately. Given the desire to print as soon as possible, it is quite likely that clients will be written to retry immediately, or after a very short delay. The problem occurs when many clients are trying to print to the same printer and all of them are retrying. At the very least, this will generate extra traffic. In addition, all of the retries may stress some of the light weight implementations of IP used in embedded systems. IPP should try to reduce unnecessary traffic when possible. The retry situation will happen all the time on low end printers which do not have a disk drive and therefore can only accept a single job at a time. Since they can only print one job at a time, if 10 clients are trying to print, 9 will get a busy indication and start retrying. It can also happen on higher end printers when they run out of spooling space, or if more clients try to establish connections than the printer is capable of handling similtaniously. I believe that this problem should be handled at the IPP level. There are some IPP operations which should be supported even if the printer cannot accept Print-Job and Send-Document requests. For example, client should be able to use the Validate-Job and Get-Attributes operations even if they cannot actually send jobs. This implies that the HTTP layer should not be the one to reject the connection request when the printer can no long accept more jobs. Instead, the request should be passed onto IPP which should either process it if it is able to, or reject it with an appropiate error code. At the last IPP meeting we defined an error code which indicates that the printer is not able to perform the indicated operation because of a lack of resources and that the problem is temporary. I suggest an additional parameter be passed back with this code which tells the client how long it should wait before it retries the operation. This will allow the printer to throttle down the clients if it starts to get overwhelmed with requests it cannot accept. Since the printer specifies the delay, it can change the delay to deal with the particular problem. For example, if the printer cannot print because it is out of paper, it could specify a delay of 5 minutes if this is typically how long it takes an operator to load more paper into the printer. If, on the other hande, the printer cannot accept jobs because its fuser has burned out, it may want to specify a much larger retry interval. The printer can also vary the delay according to how many clients are attempting to send jobs. The other alternative would be for the IPP protocol to specify a fixed delay the client must wait before retrying after it gets the out of resources error code from the printer. I suggest making the delay a variable interval under the control of the printer since this is more flexible. --- Charles ----- End Included Message ----- From ipp-archive Mon Jun 30 10:42:25 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA22794 for ipp-outgoing; Mon, 30 Jun 1997 10:41:38 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-security-00.txt (resend) Date: Mon, 30 Jun 1997 10:12:08 -0400 Message-ID: <9706301012.aa07831@ietf.org> Sender: ipp-owner@pwg.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Printing Protocol Working Group of the IETF. Title : Internet Printing Protocol/1.0: Security Author(s) : R. deBry, J. Hadsell, D. Manchala, X. Riley, J. Wenn Filename : draft-ietf-ipp-security-00.txt Pages : 21 Date : 06/26/1997 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 Internet Printing Protocol/1.0: Directory Schema This documentis the `Internet Printing Protocol/1.0: Security' document. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-security-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-security-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-ietf-ipp-security-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. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970626100700.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-security-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-security-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970626100700.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-archive Mon Jun 30 17:02:29 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA23656 for ipp-outgoing; Mon, 30 Jun 1997 17:02:11 -0400 (EDT) Message-Id: <3.0.1.32.19970630105701.0098b100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 30 Jun 1997 10:57:01 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC - IPP and firewalls Cc: philip@raptor.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk While I was still in the Boston area last week I had the opportunity to discuss IPP and firewalls with Philip Gladstone who works for Raptor, a company that specializes in firewalls and other security products for major corporations. They are at: http://www.raptor.com Philip pointed out that firewalls mostly play the role of enforcing corporate security policies even if the individual servers, in our case the IPP server, is not configured correctly. This means that the IPP Printer can actually report back features in the response to an Get-Attributes operation which works fine when you operate behind the firewall, but which may not be allowed if you try to access it from a client outside the firewall. The firewall would act as a proxy for all IPP Printers behind the firewall and hence intercept all incoming HTTP Posts from the outside. The firewall software would probably need to be able to understand the semantics of the IPP request and either generate IPP error responses as if it were an IPP Printer, or alternatively just break off the connection, if the request is in conflict with the security policy. Otherwise the request would be passed on to the IPP Printer. Likewise, the IPP Printer responses would be filtered by the firewall software, before it is passed back to the external IPP Client. The kind of restrictions that a firewall might impose include: - Only requests from a set of known TCP/IP address ranges - Only one copy of each document - Only black & white printing - Only documents up to a certain size - No multiple document jobs - No print-by-reference jobs I expect that it is unlikely that the firewall software would be able to check for features specified in the actual document content (e.g. as specified in a Postscript statement). We also discussed whether there were any security features in preparation that would provide security for print-by-reference. The answer is NO. Finally, I asked about whether a separate port for IPP might be useful. The answer to that is also NO. Comments? Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-archive Mon Jun 30 17:27:29 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA24183 for ipp-outgoing; Mon, 30 Jun 1997 17:27:00 -0400 (EDT) Message-Id: <33B824DF.66E43AA5@rd.qms.com> Date: Mon, 30 Jun 1997 16:27:59 -0500 From: "Michael W. Bringmann" Organization: QMS,Inc. X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.27 i686) Mime-Version: 1.0 To: Carl-Uno Manros Cc: ipp@pwg.org, philip@raptor.com Subject: Re: IPP> SEC - IPP and firewalls References: <3.0.1.32.19970630105701.0098b100@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk [snip] > The kind of restrictions that a firewall might impose include: > > - Only requests from a set of known TCP/IP address ranges > - Only one copy of each document Why would a firewall restrict the number of copies of a document? Would the firewall scan the data stream for the IPP 'copies' attribute and abort the document if it were present? > - Only black & white printing Why and how would a firewall restrict an image to black & white? This implies examination of the actual document content to me, something which you later state is probably not going to occur. Jobs might be limited to black & white due to document size constraints, but not just because they are color. > - Only documents up to a certain size > - No multiple document jobs > - No print-by-reference jobs > > I expect that it is unlikely that the firewall software would be able to > check for features specified in the actual document content (e.g. as > specified in a Postscript statement). [snip] Thanks. ---------------------------------------------------------------------- Michael W. Bringmann EMail: michael@rd.qms.com Senior MTS Web: http://www.qms.com Mail: QMS Incorporated Phone: (334) 633-4300 x1765 Mobile, AL, 36688, USA ---------------------------------------------------------------------- From ipp-archive Mon Jun 30 18:02:29 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA24705 for ipp-outgoing; Mon, 30 Jun 1997 18:01:48 -0400 (EDT) From: philip@raptor.com Message-Id: <9706308677.AA867708108@internet-mail.it.qms.com> X-Mailer: ccMail Link to SMTP R8.00.00 Date: Mon, 30 Jun 97 18:01:27 -0600 To: Cc: , Subject: Re: IPP> SEC - IPP and firewalls Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Sender: ipp-owner@pwg.org Precedence: bulk --simple boundary Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Michael W. Bringmann wrote: > > [snip] > > The kind of restrictions that a firewall might impose include: > > > > - Only requests from a set of known TCP/IP address ranges > > - Only one copy of each document > > Why would a firewall restrict the number of copies of a document? > Would the firewall scan the data stream for the IPP 'copies' attribute > and abort the document if it were present? The general principal is that the firewall (or choke point) is the one place where corporate policy can be enforced. If the scenario of having a a printer which behaves like a fax machine (for receiving inbound messages), then it may be that the firewall would want to ensure that documents received from the outside are 'well behaved'. In the ideal world, this would merely be a configuration issue for the print server, but we see (in the real world) that not every implementation is adequate. For example (in the browser area), corporate policy might be that each user must be running a 'safe' version of a browser in order to get external access. The firewall can enforce this by checking the User-agent header field in each request to ensure that this rule is being obeyed. [In the ideal world, the browsers would not be buggy!] If you have a large number of individual destinations (or sources) then it may be easier to apply control at the choke point, rather than hope that all the end systems are configured correctly, and the appropriate set of patches applied. > > > - Only black & white printing I would like to be able to enforce any restrictions by performing very simple manipulation of the data. Inserting/removing fields at the front of the document is nice (read: easy). Philip -- Philip Gladstone +1 617 487 7700 Raptor Systems, Waltham, MA http://www.raptor.com/ --simple boundary-- From ipp-archive Mon Jun 30 18:02:30 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA24694 for ipp-outgoing; Mon, 30 Jun 1997 18:01:18 -0400 (EDT) Message-ID: <33B82CB7.5608@raptor.com> Date: Mon, 30 Jun 1997 18:01:27 -0400 From: Philip Gladstone Organization: Raptor Systems X-Mailer: Mozilla 3.01 (WinNT; I) MIME-Version: 1.0 To: "Michael W. Bringmann" CC: Carl-Uno Manros , ipp@pwg.org Subject: Re: IPP> SEC - IPP and firewalls References: <3.0.1.32.19970630105701.0098b100@garfield> <33B824DF.66E43AA5@rd.qms.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Michael W. Bringmann wrote: > > [snip] > > The kind of restrictions that a firewall might impose include: > > > > - Only requests from a set of known TCP/IP address ranges > > - Only one copy of each document > > Why would a firewall restrict the number of copies of a document? > Would the firewall scan the data stream for the IPP 'copies' attribute > and abort the document if it were present? The general principal is that the firewall (or choke point) is the one place where corporate policy can be enforced. If the scenario of having a a printer which behaves like a fax machine (for receiving inbound messages), then it may be that the firewall would want to ensure that documents received from the outside are 'well behaved'. In the ideal world, this would merely be a configuration issue for the print server, but we see (in the real world) that not every implementation is adequate. For example (in the browser area), corporate policy might be that each user must be running a 'safe' version of a browser in order to get external access. The firewall can enforce this by checking the User-agent header field in each request to ensure that this rule is being obeyed. [In the ideal world, the browsers would not be buggy!] If you have a large number of individual destinations (or sources) then it may be easier to apply control at the choke point, rather than hope that all the end systems are configured correctly, and the appropriate set of patches applied. > > > - Only black & white printing I would like to be able to enforce any restrictions by performing very simple manipulation of the data. Inserting/removing fields at the front of the document is nice (read: easy). Philip -- Philip Gladstone +1 617 487 7700 Raptor Systems, Waltham, MA http://www.raptor.com/