Received: from cnri by ietf.org id aa11257; 2 Jul 97 13:19 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA24835 for ; Wed, 2 Jul 1997 13:18:23 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA03178 for ; Wed, 2 Jul 1997 13:14:44 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 2 Jul 1997 13:07:53 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA02585 for ipp-outgoing; Wed, 2 Jul 1997 13:01:13 -0400 (EDT) From: Peter Zehler To: "Redirector IPP (E-mail)" Subject: IPP> TES: Who is planning on prototyping IPP? Date: Wed, 2 Jul 1997 10:02:30 PDT X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Message-Id: <97Jul2.100126pdt."15266(5)"@alpha.xerox.com> Sender: ipp-owner@pwg.org All, Per a request made at the Nashua meeting, here is the list I have of "individuals" that have indicated they will be working on an IPP prototype. Bob Chansler (Adobe) Lee Farrell (Cannon) Steve Gebert (IBM) Ted Tronson (Novell) Randy Turner (Sharp) Rick Yardumian (Xerox) Peter Zehler (Xerox) If I have missed anybody could you send me a ping? Anyone on the current list that does not belong there send me a ping and I will correct the list. I will post the updated list the week of July 14. I am also curious about how the TES members intend to demonstrate and test their prototypes. I have been looking in to what it would take to put an IPP prototype printer on the public side of our firewall. It is difficult. I believe it can be done(given enough time to handle the red tape). Is there any interest in the TES group to conducting initial trials this way? Regardless of how the initial demonstrations are held does anyone have a clue to when to tentatively schedule this event? Right now I am trying to guess when planning will have to start in earnest. I am also interested in collecting issues uncovered during prototyping to feed back into the other IPP groups. As people get rolling please post issues and we will track them and get them resolved. Pete __________________________________ Email: pzehler@channels.mc.xerox.com US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. Webster NY, 14580-9701 Voice: (716) 265-8755 FAX: (716)265-8792 __________________________________ "I always wanted to be somebody, but I should have been more specific." Lily Tomlin __________________________________   Received: from cnri by ietf.org id aa11708; 2 Jul 97 13:42 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA24896 for ; Wed, 2 Jul 1997 13:41:46 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA03692 for ; Wed, 2 Jul 1997 13:38:07 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 2 Jul 1997 13:34:09 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA03254 for ipp-outgoing; Wed, 2 Jul 1997 13:28:10 -0400 (EDT) From: Peter Zehler To: "Carl-Uno Manros (E-mail)" Cc: "Redirector IPP (E-mail)" Subject: IPP> REQ document comments Date: Wed, 2 Jul 1997 10:29:58 PDT X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Message-Id: <97Jul2.102826pdt."15262(2)"@alpha.xerox.com> Sender: ipp-owner@pwg.org Carl-Uno, You wanted to refresh the REQ ID and asked me to review the document. I read through the requirements document and did not find much to comment on. Here is what I found. 1) section 2.1.4 I found the following paragraph confusing Print jobs will also be submitted by background or batch applications without human intervention. Any application level Internet printing application must support this type of printing. 2) section 2.2.1 and 2.2.2 Should it be stated that these are not addressed in V1.0 3) section 3.1 Should the characteristics that might be considered when locating a printer be brought in line with the DIR document. 4) section 3.5 Is end-user notification a V1.0 requirement? 5) section 3.6 Should cancel job and modify job be lumped together? 6) section 4.3 The first bulleted item still refers to tags for attributes and attribute values. 7)section 6 Email address corrections Tom Hastings: hastings@cp10.es.xerox.com and Peter Zehler: pzehler@channels.mc.xerox.com 8) Throughout scenarios replace job id = #12345 with job uri = http://pwg.org/printer/job12345 9) Throughout scenarios adjust returns from print operations to bring in line with MOD doc. 10) section 3.1 and Throughout scenarios remove references to "cost". Pete __________________________________ Email: pzehler@channels.mc.xerox.com US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. Webster NY, 14580-9701 Voice: (716) 265-8755 FAX: (716)265-8792 __________________________________ "I always wanted to be somebody, but I should have been more specific." Lily Tomlin __________________________________   Received: from cnri by ietf.org id aa19290; 2 Jul 97 18:57 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid SAA26152 for ; Wed, 2 Jul 1997 18:56:00 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA06517 for ; Wed, 2 Jul 1997 18:52:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 2 Jul 1997 18:44:56 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA06061 for ipp-outgoing; Wed, 2 Jul 1997 18:38:51 -0400 (EDT) From: Daniel Cogswell To: ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: IPP> Connection Maintenance in IPP Message-Id: <5030100004305913000002L032*@MHS> Date: Wed, 2 Jul 1997 18:40:35 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org I've been working on a prototype that uses the IPP and I have run into a question which I would be interested in hearing some comments on. I think of HTTP as not being a connection oriented protocol. I know I'm using the term loosely here, but, as I understand it, when you open up a connection using http you can write and then you can read once. You can't do the read/write read/write kind of activity. There is, however, the CreatePrintJob command in IPP which wants to maintain a connection. That is, it wants this read/write read/write connection. How does IPP plan to maintain the connection when it begins to append documents to the job? Dan Cogswell http://swan.penn.boulder.ibm.com   Received: from cnri by ietf.org id aa19486; 2 Jul 97 19:09 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid TAA26198 for ; Wed, 2 Jul 1997 19:08:28 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA07277 for ; Wed, 2 Jul 1997 19:04:49 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 2 Jul 1997 19:01:22 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA06575 for ipp-outgoing; Wed, 2 Jul 1997 18:53:20 -0400 (EDT) Message-ID: <33BADA6D.FF6D5DF@sharplabs.com> Date: Wed, 02 Jul 1997 15:47:09 -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: Daniel Cogswell CC: ipp@pwg.org Subject: Re: IPP> Connection Maintenance in IPP References: <5030100004305913000002L032*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org In its current incarnation, IPP relies on HTTP 1.1, which by default maintains persistent TCP connections between HTTP client and HTTP server. The client and/or server keeps a cache of open connections between clients and servers for a period of time, so they can be reused for subsequent requests. The cache lifetime for TCP connections, as well as the total number of concurrent TCP connections maintained, is implementation dependent. With persistent connections a client can make as many requests and receive as many responses as it wishes prior to the closing the connection. NOTE: the server or the client may elect to close a connection so both client and server should be prepared to handle an unexpected connection close operation. Randy Daniel Cogswell wrote: > > I've been working on a prototype that uses the IPP and I have run into a > question which I would be interested in hearing some comments on. > > I think of HTTP as not being a connection oriented protocol. I know I'm using > the term loosely here, but, as I understand it, when you open up a connection > using http you can write and then you can read once. You can't do the > read/write read/write kind of activity. There is, however, the CreatePrintJob > command in IPP which wants to maintain a connection. That is, it wants this > read/write read/write connection. How does IPP plan to maintain the connection > when it begins to append documents to the job? > > Dan Cogswell > http://swan.penn.boulder.ibm.com -- Randy Turner   Received: from cnri by ietf.org id aa20002; 2 Jul 97 19:47 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid TAA26223 for ; Wed, 2 Jul 1997 19:46:40 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA08617 for ; Wed, 2 Jul 1997 19:43:01 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 2 Jul 1997 19:39:58 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA08139 for ipp-outgoing; Wed, 2 Jul 1997 19:33:40 -0400 (EDT) Message-Id: <3.0.1.32.19970702162614.009e19c0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 2 Jul 1997 16:26:14 PDT To: Daniel Cogswell , ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org From: Carl-Uno Manros Subject: Re: IPP> Connection Maintenance in IPP In-Reply-To: <5030100004305913000002L032*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 03:40 PM 7/2/97 PDT, Daniel Cogswell wrote: >I've been working on a prototype that uses the IPP and I have run into a >question which I would be interested in hearing some comments on. > >I think of HTTP as not being a connection oriented protocol. I know I'm using >the term loosely here, but, as I understand it, when you open up a connection >using http you can write and then you can read once. You can't do the >read/write read/write kind of activity. There is, however, the CreatePrintJob >command in IPP which wants to maintain a connection. That is, it wants this >read/write read/write connection. How does IPP plan to maintain the connection >when it begins to append documents to the job? > > >Dan Cogswell >http://swan.penn.boulder.ibm.com > Dan, this is an addition to the reply you already got back from Randy about HTTP 1.1. The Create-Job operation, if successful, always returns a job URI. You will use that URI to post any further documents (Send-Document) or print-by-reference URIs (Send-URI) that belong to that job, even if you do it in a new HTTP connection. In effect you will probably have to make it in a new connection as the job URI is different from the Printer URI, that you use for the Create-Job. 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   Received: from cnri by ietf.org id aa29638; 3 Jul 97 0:07 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid AAA26577 for ; Thu, 3 Jul 1997 00:06:27 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA10589 for ; Thu, 3 Jul 1997 00:02:50 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 2 Jul 1997 23:59:39 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA10156 for ipp-outgoing; Wed, 2 Jul 1997 23:53:36 -0400 (EDT) Date: Wed, 2 Jul 1997 20:54:40 -0700 From: Robert Herriot Message-Id: <199707030354.UAA22143@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO latest protocol document available X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I have just downloaded the protocol document to: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp970702.doc and ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp970702.ps It is only 14 pages. This document has the changes that we agreed to at last week's meeting in Nashua. Note that the protocol is now easy to extend to work in a raw TCP/IP environment (Appendix A). Please note that this is a first draft. I may have forgotten a few things, but my intention was to repeat nothing that is in any of the referenced documents. Please read this document and send comments to ipp via email so I can get out a new version next week. I would like to forward that revised version to the IETF as a first draft. Bob Herriot   Received: from cnri by ietf.org id aa06123; 3 Jul 97 8:56 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid IAA27232 for ; Thu, 3 Jul 1997 08:55:40 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA12581 for ; Thu, 3 Jul 1997 08:52:01 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 3 Jul 1997 08:44:57 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA12110 for ipp-outgoing; Thu, 3 Jul 1997 08:38:55 -0400 (EDT) Message-Id: <199707031239.IAA10747@devnix.agranat.com> To: ipp@pwg.org Subject: Re: IPP> Connection Maintenance in IPP In-reply-to: <33BADA6D.FF6D5DF@sharplabs.com> Date: Thu, 03 Jul 1997 08:39:34 -0400 From: Scott Lawrence Sender: ipp-owner@pwg.org >>>>> "RT" == Randy Turner writes: RT> In its current incarnation, IPP relies on HTTP 1.1, which by default RT> maintains persistent TCP connections between HTTP client and HTTP RT> server. RT> With persistent connections a client can make as many requests and RT> receive as many responses as it wishes prior to the closing the RT> connection. NOTE: the server or the client may elect to close a RT> connection so both client and server should be prepared to handle RT> an unexpected connection close operation. To expand on that just a little... Either side may indicate that a connection is closing so that the close need not be unexpected. The client may send Connection: close in a request to indicate that the server should close the connection after sending the response, or the server may send the same header in a response to indicate that the connection will be closed after this response and so may not be used for the next request. In the absence of the 'Connection: close' header, the connection should remain open (though if idle it may be closed by either side after some timeout). HTTP/1.1 shouldn't maintain lots of connections to the same server (and there is little or no benefit in doing so as a rule); from the spec: Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD maintain AT MOST 2 connections with any server or proxy. -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/   Received: from cnri by ietf.org id aa26593; 3 Jul 97 22:03 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid WAA29612 for ; Thu, 3 Jul 1997 22:02:51 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA16155 for ; Thu, 3 Jul 1997 21:59:12 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 3 Jul 1997 21:54:48 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA15707 for ipp-outgoing; Thu, 3 Jul 1997 21:48:35 -0400 (EDT) Date: Thu, 3 Jul 1997 18:51:45 PDT From: Ira Mcdonald x10962 Message-Id: <9707040151.AA09104@snorkel.eso.mc.xerox.com> To: imcdonal@eso.mc.xerox.com, ipp@pwg.org Subject: Re: IPP>PRO latest protocol document available Sender: ipp-owner@pwg.org Bob Herriot and IPP folks, Thursday (3 July 1997) Here are my comments on Bob's new draft (ipp970702.doc) of the IPP/1.0 Protocol Encoding. I hope they're helpful. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 PS - While I could sort of review this document with the MS-Word Viewer, it wasn't easy - please post IPP documents in '.pdf' and NOT just '.ps' for those of us who don't have access to hardcopy (or MS-Word) - also, please use relatively large fonts (eg, 12 point) to ease screen viewing (eg, on laptops w/ VGA 640x480 resolution) - tables are especially tricky to view. ------------------ Comments on 'ipp970702.doc' ------------------------- 1) Global - conformance keywords - change 'MUST' and 'must' to 'SHALL' - use of both is obscure - 'NEED NOT' is defined in POSIX.2 (ISO 9945-2) and NOT in RFC 2119 2) Global - references - use symbolic references (eg, '[RFC-2068]') rather than numeric ones (eg, '[1]') - more accessible and safer for proof-reading (and one of David Perkins' recent comments on Job Mon MIB draft) - add reference to '[US-ASCII]' (ANSI X.3-4:1986) for name strings (note that 'US-ASCII' is a 7-bit code set, NOT an 8-bit set!!) - add reference to '[POSIX.2]' (ISO 9945-2) for conformance keywords (with explanation of relationship to POSIX.3-4 IEEE 1387.4) - add reference to '[RFC-1766]' for language tags (and clarify whether unregistered extensions are permissible) 3) Global - response formats - most robust protocols include the operation code in their response formats and do NOT depend on correlators (eg, xid's) - I would suggest encoding the 'status' as a named parameter which SHALL be included in responses - in my experience, this makes debugging much easier, at a very modest cost - it also would make future extensions for asynchronous responses and/or notifications much easier 4) Page 5 - Section 3.4 - please number the IPP operation codes from '1' and NOT from '0' - else, a future IPP statistics MIB can't have rows indexed by the operation code (indices SHALL be positive/non-zero, per SMIv2) - we've run into this one repeatedly at Xerox w/ the DPA standard (often, we moved the DPA enums up by 3, so that 'other(1)' and 'unknown(2)' were also possible) 5) Page 6 - Section 3.7 - clarify what 'human-readable text' means in this document (eg, in the 'locale' of the corresponding request??) - clarify what 'locale' means throughout the IPP document set (I would suggest a reference to POSIX.2) 6) Page 7 - Section 3.9 - 'text' is specified as consisting of UTF-8 (which is NOT a coded character set!!) - a CCS (coded character set) per RFC 2130 is a 'mapping from a set of abstract characters to a set of integers' (eg, UCS-2 in ISO 10646) - a CES (character encoding scheme) per RFC 2130 is a 'mapping from a CCS to a set of octets' (eg, UTF-8 in ISO 10646) - a TES (transfer encoding syntax) per RFC 2130 is a 'transformation applied to character data encoded using a CCS and possibly CES to allow it to be transmitted' (eg, Base64 in RFC 2045) - All new Internet protocol standards SHOULD specify (and LABEL 'over-the-wire') their base CCS, CES, and TES per RFC 2130 (note HTTP uses ISO 8859-1 as its base CCS and NOT US-ASCII!!) - All new Internet protocol standards SHOULD specify ISO 10646 as their base CCS (coded character set) per RFC 2130 (but RFC 2130 does NOT specify UCS-2 versus UCS-4!!) - All new Internet protocol standards SHOULD specify UTF-8 as their base CES (character encoding scheme) per RFC 2130 (but with the UCS-2/UCS-4 amibiguity, this is not rigorous) - All new Internet protocol standards SHOULD specify 'something' as their base TES (transfer encoding syntax) per RFC 2130 (and SHOULD use '8-bit clean' transports, if possible) 7) Page 7 - Section 3.9 - 'locale' is never referenced elsewhere in this document - it SHOULD be part of the protocol encoding (per RFC 2130) 8) Page 8 - Section 3.10 - by 'encoding' do you mean the TES (transfer encoding syntax)?? 9) Page 11 - Section 6 - Appendix - see RFC 2126 (ISO Transport over TCP/IP), which updates RFC 1006, for an example of encoding discrete packets (w/ length) in TCP 10) Page 15 - Other Participants - please add 'Angelo Caruso - Xerox' - please do NOT add 'Ira McDonald' (my observer role in IPP is out of personal interest and NOT one of my main 'tasks' for Xerox) - I would suggest referencing ONE participants list in whatever is deemed the 'top level' IPP document (although this is a problem with separately published and updated RFCs)   Received: from cnri by ietf.org id aa10011; 5 Jul 97 16:44 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA01185 for ; Sat, 5 Jul 1997 16:42:57 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA20655 for ; Sat, 5 Jul 1997 16:39:20 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 5 Jul 1997 16:33:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA20229 for ipp-outgoing; Sat, 5 Jul 1997 16:27:05 -0400 (EDT) Date: Sat, 5 Jul 1997 16:23:44 -0400 (EDT) From: JK Martin Message-Id: <199707052023.QAA19908@uscore.underscore.com> To: hastings@cp10.es.xerox.com Subject: IPP> Comments on your IPP/LPD mapping document Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Tom, I've started going thru your mapping document but find I have so many comments and suggestions that it would be best for me to post a new version (using your .doc file as the starting point). Does anyone have any objections to my posting a new version with my comments? (This is essentially the approach Patrick Powell used when he posted his comments on the IPP Model document.) ...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 -- ----------------------------------------------------------------------   Received: from cnri by ietf.org id aa10779; 5 Jul 97 17:44 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA01242 for ; Sat, 5 Jul 1997 17:43:40 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA21194 for ; Sat, 5 Jul 1997 17:40:01 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 5 Jul 1997 17:36:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA20776 for ipp-outgoing; Sat, 5 Jul 1997 17:30:10 -0400 (EDT) Message-Id: <1.5.4.32.19970705212627.00695670@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: Sat, 05 Jul 1997 14:26:27 -0700 To: JK Martin , hastings@cp10.es.xerox.com From: Carl-Uno Manros Subject: Re: IPP> Comments on your IPP/LPD mapping document Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Jay,, no problem. Contributions on this subject in any form are highly appreciated. Remeber though that we are still trying to get something to send to the IETF within the next two weeks, so we should also start worrying about getting something formatted as an I-D in .TXT format. Carl-Uno At 04:23 PM 7/5/97 -0400, JK Martin wrote: >Tom, > >I've started going thru your mapping document but find I have so many >comments and suggestions that it would be best for me to post a new >version (using your .doc file as the starting point). > >Does anyone have any objections to my posting a new version with my >comments? (This is essentially the approach Patrick Powell used when >he posted his comments on the IPP Model document.) > > ...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 -- >---------------------------------------------------------------------- > >   Received: from cnri by ietf.org id aa12347; 6 Jul 97 18:27 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid SAA01979 for ; Sun, 6 Jul 1997 18:26:00 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA24008 for ; Sun, 6 Jul 1997 18:22:22 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sun, 6 Jul 1997 18:15:53 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA23556 for ipp-outgoing; Sun, 6 Jul 1997 18:09:50 -0400 (EDT) Message-Id: <9707062210.AB03964@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen (Unverified) X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 6 Jul 1997 15:07:20 PDT To: JK Martin From: Tom Hastings Subject: Re: IPP> Comments on your IPP/LPD mapping document Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Jay, Go ahead and edit the .doc file. I just posted the updates that we agreed to at the meeting with revision marks turned on: -rw-r--r-- 1 pwg pwg 33792 Jul 6 21:56 lpd-ipp.doc -rw-r--r-- 1 pwg pwg 24631 Jul 6 21:54 lpd-ipp.pdf -rw-r--r-- 1 pwg pwg 16181 Jul 6 21:55 lpd-ipp.txt so you should start with that version. First accept all revisions before editing. Also please make sure that revision marks are turned on while you edit. I'm curious about all your changes though, since I think we agreed that the purpose of the document is to relate what is said in 1179 to IPP, rather than to relate what is actual practice to IPP. I did take Bob Herriot's suggestion to put into an appendix the few most flagrant differences between 1179 and current practice. As far as Carl-Uno's concern about producing .txt for the IETF, I've also posted the .txt file that I can automatically (well all-mosot) from the .doc file, so don't worry about that. The .txt file that I posted has a few 79-character lines that I'll fix before we publish to not exceed 72 characters. I've added you and Bob as authors already. Tom At 13:23 07/05/97 PDT, JK Martin wrote: >Tom, > >I've started going thru your mapping document but find I have so many >comments and suggestions that it would be best for me to post a new >version (using your .doc file as the starting point). > >Does anyone have any objections to my posting a new version with my >comments? (This is essentially the approach Patrick Powell used when >he posted his comments on the IPP Model document.) > > ...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 -- >---------------------------------------------------------------------- > >   Received: from cnri by ietf.org id aa14039; 6 Jul 97 20:31 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid UAA02049 for ; Sun, 6 Jul 1997 20:30:10 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA24576 for ; Sun, 6 Jul 1997 20:26:33 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sun, 6 Jul 1997 20:23:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA24130 for ipp-outgoing; Sun, 6 Jul 1997 20:17:14 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Sun, 06 Jul 1997 18:07:28 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> PRO - txt and pdf versions of the 970702 document Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org I posted ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp970702.txt ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp970702.pdf which are text and PDF versions of Bob's protocol document. Hope they help. 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 ************************************************************   Received: from cnri by ietf.org id aa17107; 7 Jul 97 16:11 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA04321 for ; Mon, 7 Jul 1997 16:10:44 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA27143 for ; Mon, 7 Jul 1997 16:06:54 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 7 Jul 1997 15:59:19 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA26695 for ipp-outgoing; Mon, 7 Jul 1997 15:53:14 -0400 (EDT) Date: Mon, 7 Jul 1997 07:46:02 PDT From: Ira Mcdonald x10962 Message-Id: <9707071446.AA09834@snorkel.eso.mc.xerox.com> To: SISAACSON@novell.com, ipp@pwg.org Subject: Re: IPP> PRO - txt and pdf versions of the 970702 document Sender: ipp-owner@pwg.org Hi Scott, Many thanks from the computationally impaired... - Ira McDonald   Received: from cnri by ietf.org id aa20429; 7 Jul 97 18:51 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid SAA04768 for ; Mon, 7 Jul 1997 18:50:36 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA27802 for ; Mon, 7 Jul 1997 18:46:41 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 7 Jul 1997 18:43:00 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA27360 for ipp-outgoing; Mon, 7 Jul 1997 18:36:58 -0400 (EDT) Message-Id: <3.0.1.32.19970707152502.00b88e50@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 7 Jul 1997 15:25:02 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - PWG IPP Phone Conference - July 9, 1997 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Agenda - PWG IPP Phone Conference - July 9, 1997 1:00 - 3:00 PST Although some people are still on vacation this week (Don Wright and Scott Isaacson), we will hold a phone conference this week as usual. Main agenda point is to get reactions and comments on Bob Herriot's new Protocol draft from last week. Goal is to have the document ready as an I-D by the end of this week. We should also check on how the mapping document is progressing. We will also need to make sure that the various other home work assignments from Nashua are progressing as planned. We will also discuss a little about the formal procedures that we need to perform over the next few weeks to make sure that we strictly adhere to all the IETF rules. Steve Zilles is back and will be in on the call to help discuss this. I am still waiting for a confirmation from Don that he has actually set up the phone conference for this week. If I do not hear from him by tomorrow afternoon, I will set it up myself, so please stay tuned for the actual number to use. 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   Received: from cnri by ietf.org id aa22456; 7 Jul 97 21:16 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid VAA05003 for ; Mon, 7 Jul 1997 21:15:31 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA28511 for ; Mon, 7 Jul 1997 21:11:53 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 7 Jul 1997 21:08:47 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA28059 for ipp-outgoing; Mon, 7 Jul 1997 21:02:45 -0400 (EDT) Message-Id: <3.0.1.32.19970707104142.00b899d0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 7 Jul 1997 10:41:42 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Muich Meeting Deadlines Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Some more information about the Munich meeting is now available at: ftp://ftp.ietf.org/ietf/0mtg-cutoff-dates-97aug.txt The more important of these deadlines is the date July 30 as the latest date to submit input to the meeting. This is a few more days than I had expected, but we should not take it as an excuse to slow down the drafts that we are working on. 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   Received: from cnri by ietf.org id aa22990; 7 Jul 97 22:08 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid WAA05049 for ; Mon, 7 Jul 1997 22:07:43 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA29042 for ; Mon, 7 Jul 1997 22:04:06 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 7 Jul 1997 22:01:01 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA28610 for ipp-outgoing; Mon, 7 Jul 1997 21:54:57 -0400 (EDT) From: lpyoung@lexmark.com Message-Id: <199707080155.AA29499@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Mon, 7 Jul 1997 21:55:04 -0400 Subject: IPP> ADM - IPP Phone Conference July 9 & 16, 1997 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org To: ipp@pwg.org cc: From: Lloyd Young Date: 07/07/97 09:55:04 PM Subject: ADM - IPP Phone Conference July 9 & 16, 1997 Details for the IPP phone conference calls on Wednesday July 9th and Wednesday July 16th are as follows: Time: 4:00 PM EDT Phone number: 1-423-523-7162 Access code: 190148 Lloyd Young Lexmark International, Inc. Senior Program Manager Dept. C14L/Bldg. 035-3 Strategic Alliances 740 New Circle Road NW internet: lpyoung@lexmark.com Lexington, KY 40550 Phone: (606) 232-5150 Fax: (606) 232-6740   Received: from cnri by ietf.org id aa10179; 8 Jul 97 11:37 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid LAA06862 for ; Tue, 8 Jul 1997 11:36:05 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA00587 for ; Tue, 8 Jul 1997 11:32:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 8 Jul 1997 11:24:33 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA00112 for ipp-outgoing; Tue, 8 Jul 1997 11:18:29 -0400 (EDT) Message-Id: <199707081518.LAA00107@lists.underscore.com> Date: Tue, 8 Jul 97 09:09:29 MDT From: "deBry, Roger K." To: ipp@pwg.org Subject: IPP>MOD - coding mechanism for parameters Sender: ipp-owner@pwg.org My normal mail system is down this morning, so I'm sending this from (groan) PROFS on the mainframe. I have read through Bob's new document. I apologize for not being in on the discussions in Nashua. It looks like a great deal of progress was made. However, looking at Bob's document and Sylvan's recent email on this subject, I would like to make a proposal. As you recall, I mentioned the notion of "triplets" that we use in IPDS. We also have used the notion of reserved code points for implementation specific function outside of the standard. Based on these ideas, I'd suggest the following scheme: parameter = length ID flag-byte parameter-value - length is a two byte field, defines the length of the triplet - ID is a 6 byte field, defined as follows: - 0x000000 through 0x00FFFF are standard defined parameters - 0x010000 through 0x0FFFFF are reserved for implementation specific extensions - 0x100000 through 0xFFFFFF are reserved for installation specific extensions - flag-byte - 0b00000001 - this is a repeating parameter - 0b00000010 - this is the last parameter - parameter-value is as defined in Bob's document This encoding scheme has been used in IPDS for over ten years and we have not run into any implementation or extension issues. It provides simple fixed length parameter identifiers to trigger processing on the server side, it does not depend upon delimiters (I guess you could claim that the flag-bytes are sort of delimiters, but the parsing rules are simpler since every parameter has a flag byte. The flags I've shown provde the same function as Bob's x'FF' and x'FE'. Actually, in IPDS we encapsulate repeating parameters or parameter groups in another triplet outside of the group, but It does require a little more processing to keep track of outer lengths. I know that it is always hard to back away from an agreement that has been hammered out over much sweat and tears, but I do think this approach is significantly easier to understand and to implement (I had to read Bob's document several times to understand his use of unusual "length" fields. Such overloading of length fields makes the encoding difficult to understand). I'd appreciate some debate on this issue. I know everyone wants to close on this issue and move on, but let's be sure we have the best possible solution!   Received: from cnri by ietf.org id aa17571; 8 Jul 97 17:02 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA08081 for ; Tue, 8 Jul 1997 17:01:50 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA02783 for ; Tue, 8 Jul 1997 16:58:11 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 8 Jul 1997 16:54:48 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA02346 for ipp-outgoing; Tue, 8 Jul 1997 16:48:44 -0400 (EDT) Date: Tue, 8 Jul 1997 13:49:40 -0700 From: Robert Herriot Message-Id: <199707082049.NAA26144@woden.eng.sun.com> To: ipp@pwg.org, rdebry@vnet.ibm.com Subject: Re: IPP>MOD - coding mechanism for parameters X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I agree that the IPDS triplets and the proposed IPP encoding have some similarities, but they also have some differences that have led to the encoding we have selected. First, we have had much debate about whether parameter-names should be integers or text. Most of us still prefer the text solution. Some of the reasons I have heard expressed are that text names seem to offer a better path for extension and text names make debugging easier. I hope that this issue is closed and doesn't get re-opened again. Note, we re-introduced the notion of enums into the model so that we could distinguish between those names that should be encoded as text and those that should be encoded as integers. We chose to keep attribute/ parameter names as keywords. Second, we are overloading the length field by using negative lengths. They have a similar function to your flag byte. We could have a flag byte just before each name-length field, but I not sure what we would gain. The following is the correspondence between the special IPP lengths and IPDS flags: IPP length IPDS flag > 0 no flags 0 0b00000001 - this is a repeating parameter Roger, is this for 2 through n as in IPP or 1 through n? -1 0b00000010 - this is the last parameter -2 no such concept in IPDS Note, for IPP, -1 follows the last parameter, but for IPDS it is within the last parameter. (Did I understand this correctly Roger?) I actually think that the code for generating and parsing IPP is simpler because the special ending marks (the negative numbers) occur after a parameter rather than within a parameter, so the parameter logic does not have to deal with end-of-parameter logic. If we were to add the concept of a flag-byte, then I think that it should precede the 2-byte name-length field and we would support the following values: o normal -- name-value pair follows o another value -- value follows without a name because it is part of a multi-valued parameter o parameters end -- data follows o parameter-group ends -- another parameter group follows These four cases are the same as those described in the IPP/IPDS table above and correspond to the name-lengths of >0, 0, -1 and -2. Although we may want to do some minor tweaking, I think that we should stay with something very close to what we agreed to in Nashua. I think that we are at a point of uneasy equilibrium in group. Everyone or nearly everyone is reasonably happy with our solution. Many have certain parts they don't like, but are willing to live with those parts. If we change too much of this agreement, we may again find many who don't like enough of the solution to back it, and we'll be back to square one. I will fix the language in the protocol document so that the overloading concept is clearer. Bob Herriot > From rdebry@VNET.IBM.COM Tue Jul 8 08:27:22 1997 > > My normal mail system is down this morning, so I'm sending this from (groan) > PROFS on the mainframe. I have read through Bob's new document. I apologize > for not being in on the discussions in Nashua. It looks like a great deal > of progress was made. However, looking at Bob's document and Sylvan's recent > email on this subject, I would like to make a proposal. > > As you recall, I mentioned the notion of "triplets" that we use in IPDS. We > also have used the notion of reserved code points for implementation specific > function outside of the standard. Based on these ideas, I'd suggest the > following scheme: > > > parameter = length ID flag-byte parameter-value > > - length is a two byte field, defines the length of the triplet > - ID is a 6 byte field, defined as follows: > - 0x000000 through 0x00FFFF are standard defined parameters > - 0x010000 through 0x0FFFFF are reserved for implementation > specific extensions > - 0x100000 through 0xFFFFFF are reserved for installation > specific extensions > - flag-byte > - 0b00000001 - this is a repeating parameter > - 0b00000010 - this is the last parameter > - parameter-value is as defined in Bob's document > > > This encoding scheme has been used in IPDS for over ten years and we have > not run into any implementation or extension issues. It provides simple fixed > length parameter identifiers to trigger processing on the server side, it does > not depend upon delimiters (I guess you could claim that the flag-bytes are > sort of delimiters, but the parsing rules are simpler since every parameter > has a flag byte. The flags I've shown provde the same function as Bob's > x'FF' and x'FE'. Actually, in IPDS we encapsulate repeating parameters or > parameter groups in another triplet outside of the group, but It does require > a little more processing to keep track of outer lengths. > > I know that it is always hard to back away from an agreement that has been > hammered out over much sweat and tears, but I do think this approach is > significantly easier to understand and to implement (I had to read Bob's > document several times to understand his use of unusual "length" fields. > Such overloading of length fields makes the encoding difficult > to understand). > > > I'd appreciate some debate on this issue. I know everyone wants to close on > this issue and move on, but let's be sure we have the best possible solution! > >   Received: from cnri by ietf.org id aa19525; 8 Jul 97 18:55 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid SAA08471 for ; Tue, 8 Jul 1997 18:54:26 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA03394 for ; Tue, 8 Jul 1997 18:50:48 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 8 Jul 1997 18:47:29 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA02979 for ipp-outgoing; Tue, 8 Jul 1997 18:41:24 -0400 (EDT) Message-Id: <3.0.32.19970708113050.00698710@13.240.96.62> X-Sender: rick@13.240.96.62 X-Mailer: Windows Eudora Pro Version 3.0 (32) X-Priority: 2 (High) Date: Tue, 8 Jul 1997 11:30:52 PDT To: ipp@pwg.org From: Rick Yardumian Subject: IPP> Questions on IPP Model and Protocol Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Hi, I've finished reading the lastest IPP Protocol spec (2Jul97) and the last model spec (model-issues-970623.pdf). I need feedback on the following questions so that we can continue with our prototype implementation. I know that the Model spec may be updated soon but I don't expect it to change significantly beyond what operations are mandatory versus optional. Model lines 766-780, section 5.1.2.1: I don't understand what these two paragraphs (cases 5 and 6) are saying. What does this sentence mean? "The client does not supply a Job Template attribute, but the Printer supports the attribute." "The client does not supply an attribute and the Printer does not support the attribute." What attribute are we talking about? Who is specifying it? Model line 784, section 5.1.2.2: The Print-Job response returns a job URI. My understanding is that the job URI is returned as a parameter where the parameter name is job-URI and its value is the URI. Furthermore, from the encoding spec, all parameters must be the first parameter group in the message. Is my understandig correct? Model line 803, section 5.1.2.2: In the Print-Job response, I'm confused about the encoding of the "Unsupported Attributes" and the "Unsupported Attribute Values". Are the following assumptions correct? - Are these two groups considered parameters which contain lists of attributes? - I'm assuming that "Unsupported Attributes" contains a list of unsupported job template attribute names without values. Is this a parameter group or a single parameter name, e.g. unsupported-attributes with a list of attribute names as values? - I'm assuming that the "Unsupported Attribute Values" must contain a list of unsupported job template values preceded by their attribute names, i.e. attribute name-value pairs. How is this information mapped to the protocol encoding? Model line 813, section 5.1.2.2: The Print-Job Response status is encoded in the operation field of the Protocol spec's line 139. Is this correct? Model line 863, section 5.1.4.2: Why does the Validate-Job Response contain a job identifier? Since a job object is not created, there should not be a job identifier. Is the Model spec in error? Model line 923, section 5.1.6.1: How is the "Last Document Flag" encoded? I'm assuming that it is a parameter which needs an official (no spaces) parameter name. Model line 995, section 5.1.9 and 5.1.10: Is my assumption correct that the Get-Attributes (applied to a job URI) and the Get-Jobs operations return job-template attribute name/value pairs that were originally sent by the client or if not sent by the client, the default values set by the Printer? Model line 098, section 5.1.10.2: The Get-Jobs Response description returns "objects". Are these job objects encoded as parameter groups? Model line 241, section 6.2: As part of the job template attributes, the Model spec states that "if the Printer supports the "xxx-supported" attribute, the Printer must support the corresponding default value attribute and vice versa." This appears incorrect in that the Model contains a job template table that lists several attributes with no defaults but a supported attribute, e.g. notify-addresses, compression, job-k-octets, job-impressions and job-media-sheets. How should the Model spec be corrected? Model line 737, section 6.4.3: Where is the "document-number" attribute defined? Rick   Received: from cnri by ietf.org id aa20953; 8 Jul 97 20:30 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid UAA08666 for ; Tue, 8 Jul 1997 20:29:38 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA04576 for ; Tue, 8 Jul 1997 20:25:58 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 8 Jul 1997 20:19:34 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA03752 for ipp-outgoing; Tue, 8 Jul 1997 20:07:56 -0400 (EDT) Date: Tue, 8 Jul 1997 20:08:14 -0400 (EDT) From: JK Martin Message-Id: <199707090008.UAA07275@uscore.underscore.com> To: ipp@pwg.org Subject: Re: IPP>MOD - coding mechanism for parameters X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Bob Herriot has made an excellent observation that should really be our guiding principle in moving IPP towards final consensus: > Although we may want to do some minor tweaking, I think that we should > stay with something very close to what we agreed to in Nashua. I think > that we are at a point of uneasy equilibrium in group. Everyone or > nearly everyone is reasonably happy with our solution. Many have > certain parts they don't like, but are willing to live with those > parts. If we change too much of this agreement, we may again find many > who don't like enough of the solution to back it, and we'll be back to > square one. For those who were able to attend the Nashua meetings, you know exactly what Bob is talking about here. For those unable to attend those meetings--but have been actively participating on the IPP list all along--then you would quickly understand how easy it would be for IPP to "be back to square one" if we start rocking the boat at this point. The meetings in Nashua produced the first real agreement between IPP and SWP camps. Anything that might jeopardize that agreement should be absolutely compelling, and not just a "tweak", IMHO. ...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 -- ----------------------------------------------------------------------   Received: from cnri by ietf.org id aa20963; 8 Jul 97 20:31 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid UAA08672 for ; Tue, 8 Jul 1997 20:30:10 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA04639 for ; Tue, 8 Jul 1997 20:26:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 8 Jul 1997 20:19:58 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA03763 for ipp-outgoing; Tue, 8 Jul 1997 20:08:57 -0400 (EDT) From: don@lexmark.com Message-Id: <199707090009.AA01159@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Tue, 8 Jul 1997 19:58:06 -0400 Subject: IPP> Nahsua Meeting Minutes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Attached are the text versions for the meeting minutes. These and a PDF version will be uploaded to the server this evening. They will be located in the pub/pwg/ipp/minutes directory as ipp-0697.pdf and .txt. Don ---------- Internet Printing Project Meeting Minutes June 25-26, 1997 Nashua, NH The meeting started on June 25, 1997 at 8:50 AM led by Carl-Uno Manros. These minutes were recorded by Don Wright. The attendees were: * Lee Farrell - Canon * Don Wright - Lexmark * Scott Isaacson - Novell * Jeff Copeland - QMS * Bob Pentecost - HP * Tom Hastings - Xerox * Harry Lewis - IBM * Carl-Uno Manros - Xerox * Stuart Rowley - Kyocera * Peter Zehler - Xerox * J.K. Martin - Underscore * Greg LeClair - Epson * Chuck Adams - Tektronix * Rick Landau - Digital * Angelo Caruso - Xerox * Bob Von Andel - Allego Software * Rick Lomicka - Digital * Jasper Wong - Xionics * Charles Gordon - Osicom * Shigern Ueda - Canon * Frank Zhao - Panasonic * Richard Hart - Digital * Sue Gleeson - Digital * David Kellerman - Northlake Software * Lloyd Young - Lexmark * Jeff Rackowitz - Intermec Corp Carl-Uno Manros reviewed the agenda for the two days. We will have a conference call available on Thursday afternoon to discuss protocol encodings. Scott Isaacson started off the meeting discussion on the Model document. Scott reviewed the major updates that were made in the latest version of the Model document. The following issues from Scott Isaacson's issues list available from the PWG ftp server at ftp://ftp.pwg.org/pub/ipp/new_MOD/model-issues-970623.pdf were then reviewed: 1) Cancel a job that does not exist - response is client-error-not-found - CLOSED 2) Cancel a job without authority - response is client-error-unauthorized or client-error-forbidden or in a very secured environment client-error-not-found - CLOSED 3) Invalid URI print-uri/send-uri - response is client-error-not found - CLOSED 4) New status code -> server-error-printer-error - leave in document - CLOSED 5) New status code -> server-error-write-fault - leave in document - CLOSED 6) Add "spool-space-full" to printer state reasons - Yes - CLOSED 7) Add printer attribute "spooling-space-available" - No - CLOSED 8) HTTP/1.1 has "402 Payment Required", should IPP do the same? - No - CLOSED 9) HTTP/1.1 405 Method Not Allowed returns an Allow header indicating what is allowed. Should we do something similar for invalid IPP operations. - No - CLOSED 10) See #2 above. 11) Should we put "best-efforts" for IPP attributes concept back into the model? - CLOSED Change existing name of "Best-Efforts" to "pdl-override" and make it a printer description rather than a job-template attribute "allow-substitutions" becomes a Boolean in the TRUE - print anyway even if the attributes can't be supported FALSE - print only if all attributes can be honored 12) Do we need something like 301 Moved Permanently and 302 Move Temporarily? - No - CLOSED 13) printer-resolution - Leave as keywords, everyone should input other resolutions that should be in the list. Change SHOULD to SHALL. User interface may have to parse and translate resolution into localized units. Add units to resolution. - CLOSED 14) Get-Jobs response: Jobs are returned oldest to newest for process and pending jobs and newest to oldest for completed, aborted and canceled jobs. - CLOSED 15) See #11. 16) MIME types for document-format - We will register these with IANA in the form of "application/vnd.Lexmark-PPDS" and change these from type KEYWORD to type NAME. Tom Hastings will investigate the correct format with IANA - CLOSED 17) See #16. - CLOSED 18) No action by the group required - CLOSED 19) Are attribute group names MANDATORY - YES - CLOSED 20) "Printers" shouldn't return a default value that is does not support. - CLOSED 20-New: Do we need to define a value for default that is "undefined" - Dave Kellerman will investigate. 21) Parameters on an operation may be omitted by the client but must be supported by the printer. Scott will clarify action by the printer if the parameter is omitted. - CLOSED 22) Which error codes are MANDATORY for a printer to support? - No need to specify this in the spec.; this is just basic good design - CLOSED 22-New: Scott is going to remove the HTTP codes from the Model document. More work still needs to be done on error codes will be done in the Protocol document. 23) Change text ANY and name ANY to UTF8 - No - CLOSED 24) Only allow lower-case letters in keywords - YES - CLOSED 25) Suggested syntax for private keywords - We will allow whatever is allowed in domain names so vendors can uniquely identify their new keywords. - CLOSED 26) Add job-aborted as an event to agree with the job-states - YES - CLOSED 27) Does printer-problem include when the job is in "pending-held." - YES, but not when the job is completed, canceled or aborted - CLOSED 28) How should "multiple-documents-are" treat the concatenation of multiple files, should a new page be forced? "Single documents" should be concatenated; "multiple documents" are not. Comments and suggestions for content and name should be posted to the mailing list - CLOSED (but not locked) 29) Change SHOULD to SHALL for "printer-resolution" and "printer-quality" -- yes, see #13 - CLOSED 30) Localization - Scott will develop a list of the text that should be localized - OPEN - Carl-Uno suggestion: Add a new section that identifies the information that will be returned for asynchronous notification. - Scott agreed to add this. Break for lunch at 12:50; resumed at 2:30 PM. 31) Too many "shalls" - Replace them with "is" in the terminology section. Any others should be identified to the mailing list. Our conformance statements are probably too stringent; we should probably relax them. - Scott will re-examine whether they are all needed. - CLOSED 32) What is the definition of CONDITIONALLY MANDATORY and what is the "condition" that makes it mandatory? Generally if a feature or operation is implemented in a product then the CONDITIONALLY MANDATORY attribute, etc. shall be implemented. Tom Hastings will review for exceptions to the above. - CLOSED 33) Should we remove the sentence in 4.4 that prevents fan-in? - YES - CLOSED 34) What attributes could be returned in a Print-Job response? Randy has proposed a longer list than what is in the current model document. Only job- name and job-state are to be returned. Everything else can be retrieved using a GET-ATTRIBUTES for that job. 35) Unsupported Attributes and Unsupported Attributes Values will be merged into a single entity. If the Attribute is not supported the response will be "unsupported"; if a particular attribute value is unsupported, the response will be the unsupported value. 36) Cancel-Job response - add job-state and job-name - CLOSED 37) Should we break the write-up of GET ATTRIBUTES into a section on it for Printer and a section for Job. - YES - CLOSED 38) In section 5.1.10.2, there is a security issue over how much information is returned about other user's jobs. - Leave as is; could also apply to printer attributes as well - CLOSED 39) Section 6.2.3 - Should the "job completion" event include completed without errors, aborted and canceled - YES - CLOSED 40) See #28 41) See #11 42) See #11 43) See #13 44) Name of job-k-octets-completed was changed to job-k-octets-processed - CLOSED 45) Should document-uri be returned in the query? Yes and NONE is the response for a document that had real content. - CLOSED 46) Should we use "partly" and "mostly" in section 6.5.11. -- NO. The adornments need to be changed to be a suffix rather than a prefix. -- CLOSED. 47) Issue on whether all attributes can be categorized as MANDATORY, CONDITIONALLY MANDATORY, etc. For example does a printer that knows about duplexing but doesn't have that feature installed report DUPLEX:NONE rather than not reporting duplex at all - YES - Tom Hastings and Scott will look at where these apply. - CLOSED. 48) Section 7.4 wording needs to be updated with information from the security document. - OPEN 49) Job-state and job-state-reason as posted need to be posted into the model document - Scott will do this - CLOSED 50) Should we call things that are passed in requests and responses that are not associated with attributes "parameters." -- We will generically call things passed back and forth as parameters including things that are or are not attributes/values -- Scott will update the model document. - CLOSED 51) How do default values attributes get associated with a new Job object? -- They are never associated with the job because we don't want the default values to override the PDL. - CLOSED 52) Conformance statements for other operations, i.e. the non-mandatory one, in the model document -- We will omit these until we have implementation experience.-- CLOSED 53) Security Attributes - How do we report/determine the security available/supported/required? Roger Debry has written this up. -- Scott will include Roger's proposal in the next Model document -- CLOSED. The group reviewed the status codes section of Appendix A of the model document. - Add an error code "client-error-not-possible" which can be used in the case where someone tries to cancel a job that has already completed. - Change "client-error-unauthorized" to "client-error-not-authenticated" - Keep "client-error-forbidden" as the catch-all which can be used in very secure environments to hide information. - Add "client-error-not-authorized" - Remove "client-error-method-not-allowed" - "entity-too-large" can also apply to the attributes not just the print data - "client-error-unsupported-media-type" should be removed - Change "server-error-operation-not-implemented" to "server-error-operation- not-supported" - remove "server-error-timeout" (This is handled by the protocol by dropping the connection) - remove "server-error-HTTP-version-not-supported" - change name of "server-error-IPP-version-not-supported" to "server-error- version-not-supported" whether the problem can be with either the major version or the minor version. The client has the responsibility to find the highest compatible version between the client and the server. - change name of "server-error-printer-error" to "server-error-device-error" - change "server-error-write-fault" to "server-error-temporary" - We need to make sure the description of all the errors make a statement about possible ways to recover from the error condition. - A general review needs to be made of the operations and determine what kinds of errors might occur. These should be reported to the mailing list and added to the model document. Additionally, error conditions discovered during prototyping need to be added to this list as well. David Kellerman will review the DPA errors to see what might apply. The meeting adjourned at 6 PM. The meeting resumed at 8:40 AM on June 26, 1997. Directory Schema ---------------- Issues: 1) Is information that is as variable as Media Ready stored in the directory? - NO - Additionally an object named something like "media available" that would like what could be put in the printer would be placed in the directory. - CLOSED 2) Printer Driver Installer is not in the directory schema - YES, keep it that way. The printer-more info-site or printer-more-info-manufacturer could point to WEB pages that have information about driver installer. Scott will make sure the text for these two objects is correct in both the model document and the directory schema. - CLOSED 3) Cost per page attribute is not in the schema. - Correct. This information should be made available from the printer-more-info-site URI. - CLOSED 4) How is "near my hotel" done? The attribute printer-location is available and could be used to find the "near my hotel" criteria. - CLOSED 5) Should Device ID be in the schema. No, since we don't have the driver installer attribute. - CLOSED 6) What security attributes should be in the schema? Waiting for security sub- group input and this will be inserted in the document -- CLOSED. 7) How does the schema deal with X.500 and similar directory's inheritance. -- The schema will not discuss this since it is implementation specific. -- CLOSED 8) The Directory Schema document should explicitly call out the attribute types and potential values as being those defined in and contained in the model document. - CLOSED 9) Section 2.1 - removed the SHALL; change to "is." -- CLOSED Security -------- Carl-Uno reviewed the status and work in progress of the security document. This document was recently published as an IETF draft. Most of the document is an overview of security scenarios and available solution. Section 6.2 contains the current set of recommendations. Issues: 1. Does asynchronous notification require security? -- OPEN 2. The current model document does not yet include some kind of "security- attribute" for the printer which the printer would populate with the types of security it supports -- OPEN Protocol -------- Primary topics that need to be included in the protocol document. 1) Operation encoding 2) Status Code mapping 3) Table of HTTP Headers 4) Examples Operation encoding - three options on the table: 1) Binary encoding bin-length name bin-length value a) "value" is binary or text depending upon the context of "name" b) "value" is always text c) "value" is text or an enumerated value 2) Randy encoding name sp 1-4digits sp value 3) HTTP-like encoding name ":" value CRLF escape special characters inside value (= hex hex) cr is =0D lf is =0A = is =3D A religious discussion ensued. At this point, the group was fairly well split between #1 and #3 above with no support for #2. The group decided that in all cases the "name" are text and not integers. Additionally, the "value" is encoded as text and not integers. A discussion ensued as to whether we should map keywords to enumerations. This could affect how "value" is encoded in either #1 or #3 above. Break for lunch at 11:35AM. Meeting resumed at 1PM. The following people called into the conference call to join the meeting for the discussion of the encoding: Stan McConnell Ira MacDonald Sylvan Butler Scott Lawrence Dan Codswell Randy Turner Issues discussed: 1. Is there a value from an internationalization perspective in having the binary length encoding? After some discussion the group at the meeting took a straw vote that with a strong majority (in fact consensus) in favor of a binary length encoding rather then an HTTP-like, delimiter based encoding. Keyword values currently in the model document will be mapped to enums when well known enums already exist (from the printer MIB, from the JOB MIB, from IANA, etc.) but this group will not go off and create new lists of enums for other attribute values. We also decided that the following IPP operations are now mandatory and the model document will be updated by Scott to include this. For a printer object: 1. Get-Operations 2. Print-Job 3. Validate-Job 4. Get-Jobs 5. Get-Attributes For a Job Object: 1. Cancel-Job 2. Get Attributes Details of the Request format: Byte Major Version Byte Minor Version 2Byte Operation -- repeat 2Byte Length of parameters var parameters -- endrepeat (the last chunk has a length of 0) var data Details of the Response format: Byte Major Version Byte Minor Version 2Byte Status (error codes) -- repeat 2Byte Length of parameters var parameters -- endrepeat (the last chunk has a length of 0) var data (If this data is present, there is an attribute "response-format" that says what this data is. This needs to be added to the model document.) The protocol will operate in a synchronous, lock-step way which means that an application sends a request, then waits for a response before issuing the next request. We will not have transaction ids in the IPP protocol. Issue: Do "ignored" attributes sent to a server with a job "hang around" if the job is queried. -- OPEN Work to be done by the protocol group: 1) Finish Operation encoding 2) status code mapping 3) table of HTTP headers (how does IPP uses these) 4) Examples Review of IPP-LPR mapping document ---------------------------------- There is no intent for anyone to implement a gateway between IPP and LPR. This document is simply informational so that someone that is used to LPR can understand how equivalent functions can be done with IPP. Tom Hastings went through his new document and discussed it and the issues he identified. Those interested in this area should review and send their comments to the distribution list Requirements Document --------------------- Reviewers for the requirement document will include: Carl-Uno Manros Peter Zehler Roger Debry Others are encouraged to feed comments to the mailing list. The goal is to have a new version of the document for the Munich IETF meeting. Why HTTP -------- Steve Zilles will write an informational RFC about why the group chose to map IPP to HTTP. Mapping document to LDAP ------------------------ As a lower priority effort, the group would like to start on an LDAP mapping for the directory schema. Returned to the protocol encoding discussion --- Bob Herriot made a last suggestion to use the special value of the length of an attribute name being -1 means there are no more attributes in the list. Bob will write this up in the protocol document. The meeting adjourned at 5:36PM. ----------   Received: from cnri by ietf.org id aa28864; 8 Jul 97 23:24 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid XAA08895 for ; Tue, 8 Jul 1997 23:23:22 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA05759 for ; Tue, 8 Jul 1997 23:19:44 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 8 Jul 1997 23:16:45 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA05336 for ipp-outgoing; Tue, 8 Jul 1997 23:10:33 -0400 (EDT) Date: Tue, 8 Jul 1997 20:10:28 -0700 From: Robert Herriot Message-Id: <199707090310.UAA26466@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO new version of protocol doc for Wed meeting X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I have made a few revisions to the IPP protocol document based on feedback. The protocol has not changed -- only the explanation has. Hopefully it is clearer now. The documents that I have downloaded are: Without revision marks: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp970708.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp970708.ps With revision marks relative to the July 2 version. ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp970708-rev.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp970708-rev.ps Hopefully, enough of you will have looked over the changes that we can review the new one without revisions marks. If someone can produce a pdf or txt version, I would appreciate it. BTW, I forgot to change the date in the document. It still says July 2. Bob Herriot   Received: from cnri by ietf.org id aa02125; 9 Jul 97 4:39 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid EAA09370 for ; Wed, 9 Jul 1997 04:38:30 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id EAA06788 for ; Wed, 9 Jul 1997 04:34:51 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 9 Jul 1997 04:31:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA06369 for ipp-outgoing; Wed, 9 Jul 1997 04:24:59 -0400 (EDT) Message-Id: <3.0.1.32.19970708151246.009192a0@xmicro.cp10.es.xerox.com> X-Sender: xriley@xmicro.cp10.es.xerox.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 8 Jul 1997 07:12:46 PDT To: ipp@pwg.org From: "Xavier D. Riley" Subject: IPP> MOD - Questions on IPP Model and Protocol Document (model-issues-970623.pdf) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org all, Clarification on the following would be appreciated. I'm trying to tie the new Protocol document (ipp970702.doc) to the Model document. My comments are preceded by "XDR>". 319 2.2.2 Parameters 323 attributes, some do not. All parameters are defined in section 5. XDR> Its not clear to me what are "parameters" in section 5. There are XDR> not explicitly identified. The protocol document mentions XDR> "parameter groups" which are not mentioned in the Model document. 723 5.1.2.1 Print Job Request XDR> It is stated that the "document-name" is MANDATORY. Line 735 states XDR> that the simplest Print-Job request consists of just the Document XDR> Content and nothing else. Is this a conflict? 974 5.1.8 Cancel Job Operation XDR> It is stated that only the job originator can cancel the job. How much XDR> credibility are you placing in the validity of the XDR> "job-originating-user" value. This validity should be tied into the XDR> different security methods used and the differences should be stated. XDR> In order to truly accomplish this, the user has to be authenticated, XDR> which leads you down the path to talking about security issues. Question, XDR> should this be moved to the IPP Security document? 1043 "The requested attributes of the object with their current valuesSHALL" XDR> I'm not sure you meant to have "SHALL" at the end of this sentence. 1051 A Printer MAY be configured, for security reasons, not to return all attributes that a client requests. It may 1052 even return none of the requested attributes. In such cases, the status returned is the same as if the Printer 1053 had returned all requested attributes. The client cannot tell by such a response whether the requested 1054 attribute was present or absent on the Printer. XDR> What is the rationale behind this policy of not XDR> guaranteeing a return? It would be nice to guarantee this XDR> return so the client could dynamically build the UI querying XDR> for all of the supported attributed on a printer. 1068 4. If the client supplies an attribute group keyword that is not unsupported, ... XDR> Did you really mean to use "not unsupported" ? 1248 ... the "printer-job-template" group in order to get the XDR> Should "printer-job-template" be printer "job-template" ? ______________________________________________________________________ Xavier Riley Xerox Corp. Voice: 310-333-8329 / 8*823-8329 Corp. Research & Tech. Fax: 310-333-6618 / 8*823-6618 701 S. Aviation Blvd ESAE-231 Email: xriley@cp10.es.xerox.com El Segundo, California 90245 http://www.cp10.es.xerox.com/~xriley ______________________________________________________________________   Received: from cnri by ietf.org id aa09033; 9 Jul 97 11:36 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid LAA10733 for ; Wed, 9 Jul 1997 11:35:46 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA08193 for ; Wed, 9 Jul 1997 11:32:08 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 9 Jul 1997 11:26:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA07749 for ipp-outgoing; Wed, 9 Jul 1997 11:20:40 -0400 (EDT) From: Roger K Debry To: ipp@pwg.org, robert.herriot@eng.sun.com MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: IPP>PRO - comments on latest draft Message-Id: <5030100004535149000002L092*@MHS> Date: Wed, 9 Jul 1997 11:21:31 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Bob, you're too efficient. I haven't had the time to comment on your previous draft and already there is another one! The followng comments then are with respect to the version just posted: line 101: I'd suggest calling this the paremeter-part, which will simplify the text in line 103 and let you get rid of the single quotes, which I think are confusing. line 102: this says that data is an optional part ... is it really optional or just dependent upon the operation? line 103: I'd suggest calling parameters operation-parameters. Line 103, for example, would read "The parameter-part consists of a sequence of one or more operation-parameters. ... I'd also suggest introducing the notion of parameter groups here rather than in lines 115-117. line 108 - 118: I still don't like overloading the name-length field, but if no one else cares, I'll go along with this agreement. Do we reserve all negative lengths to have some meaning in the future? Is the concept of a signed binary integer machine and language independent, or do we need to back off to hex values and just say 0xFFFF and 0xFFFE (not -1 and -2)? line 109: Is there a semantic difference between sending an additional parameter value using the 0x0000 flag as opposed to sending a valid name-length, repeating the parameter-name, and then the additional value? I don't think there is, but if so it ought to be noted. lines 113 and 118: I'm just fussing with the words here I guess. You say that a parameter with the value 0xFFFF or 0xFFFE consists of only a name-length. I guess I'd say that these aren't parameters at all, but rather when encountering these values when inspecting what would normally be the next parameter name-length field, these "flags" signal end of parameters or end of parameter group. line 128: suggest using the term paremeter-part instead of parameters I'd suggest adding the names you've introduced here, e.g. END_PARAMETERS, to the text in lines 112-118 where you define these flags. line 165: what does the ellipsis denote? I assume it means other parameter-group 0xFFFE secquences, but coudl also be read as - more 0xFFFE sequences - something undefined between 0xFFFE and the next parameter group line 186: Isn't this really a diagram of a parameter-set? line 190: I suppose it's obvious, but rather than u bytes, should you say 'length-of-name' bytes? line 211-212: I'd either put this sentence after the first diagram describing the request operation, or actually include the response diagram. lines 217-218: Why are operations signed values? Would it be crisper if you used the capitalized term SIGNED-SHORT defined in the ABNF (or just deleted this sentence since it has been defined in the ABNF)? Is there value in showing the decimal value rather then the hex value in the encoding? Is there any logic behind the assignment of codes to the operations? Should there be? lines 221-222: same comment as above for lines 217-218. lines 231-239: This section seems redundant to me. I think all of this is clear from the previous section. lines 232-234: Probably don't need to say that the name-length is two-byte binary signed integer in big endian order twice here. Also see comments above on using the term two byte binary signed integer. line 243: You ought to say where the target URI is specified. lines 247-251: I can't find reason-phrase in the model doument (although I have to admit I didn't look very hard). If a reason phrase is included, why isn't it in it's own parameter group? line 253: I'd suggest rephrasing this to say "The remaining parameters are encoded in parameter-groups." lines 253-257: This may be a bit of a departure in the ABNF, but what if we defined the syntax of a a request to be version operation operation-parameters object-attributes [data]. and a response to be version status [reason phrase] object-attributes [data] You would still use the flags as defined to separate things as you have defined them, but to me it would really clarify things and you wouldn't need a lot of the complex language you have in this section. I don't think this changes the bits that flow over the wire, it just simplifies (I think) the description. You also don't need to even include the tables in lines 271-279 since this mapping is obvious from the ABNF notation. The only change with bits on the wire is that you might see extra 0xFFFE flags for empty groups (e.g. no operation-parameters). table following line 271: last-document should be last-document-flag. table following line 274: you show reason phrase in the second parameter group. This conflicts with the statement in lines 250-251 which says that reason phrase will be the first parameter in the first parameter group. Again, I think such confusion can be avoided by declaring this in the ABNF as in the above recommendation. table following line 285: Do we need signed integers? Is the notion of signed machine and language independent? lines 287-288: Is the notion of signed (negative values) machine and language independent enough or do we just reserve the hex values 0xFFFF and 0xFFFE? If the notion of negative numbers is machine and language independent, do we need to reserve all negative lengths for future extension? line 294: " .The dataSHALL" should read "The data Shall ..." lines 294-295: These lines seem more than is required (and therefore adds complexity) I think it would be simpler and would define the data sufficiently to say "The data part includes any data required by the operation. line 296: What does this mean? Why the use of the word "may"? lines 307-308: I don't know why you would put the URI in the operation layer? Why is this an issue? table following line 333: I think more text is required to describe some of the semantics of these headers. Perhaps it is obvious to one well versed in http, but, for example, I think the use of connection header could use more words than is available in the "values and Conditions" column. When MUST a connection be closed? Who MAY close a connection and under what conditions. lines 345-352: The security sub-group is working on wording for this section. Please do not send this document to the ietf until we complete -- by the end of this week. In particular, we will not define any application specific security mechanisms so most of what you have in this paragraph is incorrect. Since we assume http, I did not review the appendix. Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080   Received: from cnri by ietf.org id aa12960; 9 Jul 97 14:56 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid OAA11674 for ; Wed, 9 Jul 1997 14:55:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA08864 for ; Wed, 9 Jul 1997 14:51:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 9 Jul 1997 14:46:54 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA08442 for ipp-outgoing; Wed, 9 Jul 1997 14:40:47 -0400 (EDT) From: Roger K Debry To: cmanros@cp10.es.xerox.com MMDF-Warning: Parse error in original version of preceding line at ietf.org Cc: ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: IPP>REQ - comments for next draft of requirements document Message-Id: <5030100004544776000002L062*@MHS> Date: Wed, 9 Jul 1997 14:42:29 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Carl-Uno, per your request, I have reviewed the requirements document to see what we might change for the next ietf draft. One of the objectives I've taken is to simplify and shorten the document to only the essential information. My comments follow: Since there are no line numbers, I'll use sections, pages and paragraphs to identify suggested chnages. Section 1: Terminology Recommend changing the first sentence in this section to read "Internet Printing for the purposes of this document is the application of Internet tools, programs ..." Recommend the second sentence be changed to read "This could include, for example, the use of HTTP ..." Also remove the phrase static, dynamic, and intercative. Also in this sentence, since we do not support these as part of the IPP protocol, I recommend removing the following - printer locating services - user installation - configuration I suggest deleting the second paragraph. I don't think it adds any value and suggests that a Browser is a required element of an IPP implementation. Section 2: Requirements I suggest deleting the second sentence in the first paragraph. I am not sure what value it adds, and the distinction made for an application level protocol is not very good in my mind anyway. Section 2.1 End User I suggest eliminating the first sentence in the first paragraph. The second sentence seems sufficient to define the end user role. Section 2.1.1 Finding and Locating a Printer Since location is not part of the IPP protocol, I suggest adding the following at the end of this section. "Although we do not expect the Internet Printing Protocol itself to support this function, IPP must define a directory schema which will provide the necessary information for a directory implementation to consistently represent IPP printers." Section 2.1.2 Creating an instance of the Printer I'd suggest changing the last sentence in this paragraph to read The Internet Printing Protocol's role in this requirement is simply to enable the creation of the printer instance by providing information, such as where to locate a printer driver for this printer, as an attribute of an IPP Printer. Section 2.1.3 Viewing the status and capabilities of a printer Since I don't think that IPP currently supports the notion of loaded media, I'd suggest changing the first bullet after the first paragraph to read supported media, commonly paper, by size and type Section 2.1.4 Submitting a print job The last line of the first paragraph, change URL to URI (probably ought to do a global change since there are surely more instances of URL in the document. I think we could remove the second and third paragraphs, they seem redundant to me. In the bulleted list after the 4th paragraph, remove redirecting the print job or state that it is a future requirement. We currently do not provide redirection in IPP. Remove the second sentence ("Any application level Internet ...) in the 5th paragraph in the section. Section 2.2 Operator Although we say this (way in the last sentence of the section) I'd suggest perhaps putting right in the section heading that this is not a V1.0 requirement. For example, "Section 2.2 Operator (Not a V1.0 Requirement)" Section 2.3 Adminstrator ditto last comment Section 4 Objectives of the Protocol Delete the second and third sentence of the second paragrph of this section ("Any platform capable of ..."). This seems to be an implementation statement, not a protocol statement, and I'm not sure it is true. I recommend deleting the appendix (Section 8). Although it may have had some value in the past, I doubt that this level of detail is interesting to the casual reader. Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080   Received: from cnri by ietf.org id aa23172; 9 Jul 97 22:46 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid WAA16153 for ; Wed, 9 Jul 1997 22:44:48 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA10442 for ; Wed, 9 Jul 1997 22:41:10 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 9 Jul 1997 22:37:17 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA10020 for ipp-outgoing; Wed, 9 Jul 1997 22:31:09 -0400 (EDT) Date: Wed, 9 Jul 1997 19:32:08 -0700 From: Robert Herriot Message-Id: <199707100232.TAA27506@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO proposed tweak to protocol X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org In today's meeting we decided to propose one last small tweak to the IPP protocol. We decided that I would send out this proposal for all of you to read and comment on. I think that it is an improvement. I hope that you will agree. We are proposing the addition of a one byte tag in front of each parameter. With this change, we eliminate the need for the special negative lengths for both names and values. We also add the ability to specify the type of parameter/attribute values so that a value can be decoded and stored independently of the parameter/attribute name. Both of these seem like positive changes. The tag serves the following functions: o it marks the beginning of: o the parameter section o any attribute section o the data section o it specifies that a parameter/attribute value is a special 'out-of-band' value, e.g. unsupported o it specifies the type of a parameter/attribute value, e.g. integer. The rules for encoding and decoding remain nearly the same. The cost of the 1 extra byte per parameter/attribute is minimal. This change is explained in detail below by including what the syntax section would look like if this proposal were approved. Please email comments to ipp@pwg.org by Friday 7/9 afternoon. Thanks. Bob Herriot The new text for the protocol document follows: --------------------------------------------------------------- 1. Encoding of the Operation Layer The operation layer SHALL contain a single operation request or operation response. The encoding is defined using both a diagram and Augmented Backus-Naur Form (ABNF), as specified by draft-ietf-drums-abnf-02.txt [29] except that `strings of literals' SHALL be case sensitive. For example `A' means upper-case `A' and not lower case `a'. In addition, two-byte binary signed integer fields are represented as `%x' values which show their range of values. All binary integers in this encoding SHALL be transmitted in big-endian format (also known as 'network order' and 'most significant byte first') 1.1 Syntax of Encoding The encoding consists of: . version . operation (for a request) or status (for a response) . parameter-tag . parameter-sequence . attribute-tag . attribute-sequence . data-tag . data (absent for some operations) The parameter-sequence consists of a sequence of one or more parameters. The attributes-sequence consists of a sequence of one or more attributes. Each parameter or attribute consists of: . value-tag: a one byte value that specifies the type of the value, e.g. integer. . name-length: a two byte binary integer which is the length of the following `name' . name . value-length: a two byte binary integer which is the length of the following `value' . value A name-length of 0 has a special meaning. The parameter-tag and parameter-sequence may be omitted if the operation has no parameters. The attribute-tag and attribute-sequence may be omitted if the operation has no attributes or it may be replicated for an operation that contains attributes for multiple objects. The data-tag is present even when the data is omitted. A name-length of 0 has a special meaning and denotes an additional value for the preceding parameter or attribute. The following name is empty. That is, the `value-length' starts in the next octet. A sequence of parameters or attribures where all but the first have a name-length of 0 is called a compound-parameter or compound-attribute, respectively. From the standpoint of a parsing loop, the encoding consists of: . version . operation (for a request) or status (for a response) . zero or more: . tag . empty, parameter, or attribute . data-tag . data (which is optional) The value of the tag determines whether the bytes following the tag are: . parameters . attributes . data . a single parameter where the tag specifies the type of the value. The syntax for the operation layer below shows the structure created by the 3 special `name-length' values described above. ipp-message = ipp-request / ipp-response ipp-request = version operation parameter-sequence attribute-sequence DATA-TAG [ data ] ipp-response = version status parameter-sequence attribute-sequence DATA-TAG[ data ] version = major-version minor-version major-version = SIGNED-BYTE ; initially %d1 minor-version = SIGNED-BYTE ; initially %d0 operation = SIGNED-SHORT ; mapping from model defined below status = SIGNED-SHORT ; mapping from model defined below parameter-sequence = [PARAMETER-TAG *compound-parameter] attribute-sequence = *(ATTRIBUTE-TAG *compound-attribute) compound-parameter = parameter *(more-values) parameter = TYPE-TAG name-length name value-length value compound-attribute = attribute *(more-values) attribute = TYPE-TAG name-length name value-length value more-values = TYPE-TAG ZERO-NAME-LENGTH value-length value name-length = SIGNED-SHORT ; number of octets of `name' name = LALPHA *( LALPHA / DIGIT / "-" / "_" ) value-length = SIGNED-SHORT ; number of octets of `value' value = OCTET-STRING data = OCTET-STRING ZERO-NAME-LENGTH = %x00 %x00 ; name-length of 0 SIGNED-BYTE = %x0..%x7F SIGNED-SHORT = %x0.. %x7FFF DIGIT = "0".."9" LALPHA = "a".."z" BYTE = %x0..%xFF OCTET-STRING = *BYTE TYPE-TAG = %x10..%xFF PARAMETER-TAG = %x01 ; TYPE-TAG of 1 ATTRIBUTE-TAG = %x02 ; TYPE-TAG of 2 DATA-TAG = %x03 ; TYPE-TAG of 3 The following table specifies the allocation of values for the tag byte: Tag Range Meaning (Hex) 00-0F tags that identify portions of the encoding, e.g. DATA-TAG 01-1F a parameter/attribute with a special `out-of-band' value that is independent of its ordinary type, e.g. "unsupported". The value-length SHOULD be 0, and the value empty. 02-3F signed binary integer in big endian order 04-7F character string 80-FF reserved The following table specifies actual values for the tag byte: Tag Value Meaning (Hex) 00 reserved 01 start of parameters 02 start of attributes 03 start of data 04-0F reserved 10 unsupported 11 default 12-1F reserved 20 unspecified-integer 21 integer 22 boolean 23 seconds 24 milliseconds 25 enum ISSUE, should there be a separate type for each enum 26-3F reserved 40 unspecified-string 41 text 42 name 43 filename 44 keyword 45 uri 46 uriScheme 47 dateTime 48-7F reserved ISSUE: should we have unspecified-integer and unspecified-string for an implementation that doesn't want to be more specific about an integer or string. 1.2 Diagram of Encoding The following is a diagram of the encoding of a request and response operation. ---------------------------------------------- | major version | minor version | 2 bytes ---------------------------------------------- | operation (request) or status (response) | 2 bytes ----------------------------------------------------------- | 0x01 | 1 byte | ---------------------------------------------- |- optional | parameter-sequence | k bytes | ----------------------------------------------------------- | 0x02 | 1 byte | ---------------------------------------------- |- 0 or more | attribute-sequence | n bytes | ----------------------------------------------------------- | 0x03 | 1 byte ---------------------------------------------- | data | q bytes - optional ---------------------------------------------- The following is a diagram of the parameter-sequence which is 0 or more compound-parameters. ---------------------------------------------- | compound-parameter | r bytes - 0 or more ---------------------------------------------- The following is a diagram of the attribute-sequence which is 0 or more compound-attributes. ---------------------------------------------- | compound-attribute | s bytes - 0 or more ---------------------------------------------- The following is a diagram of a compound-parameter and a a compound- attribute. The optional fields are present only when a compound- parameter or compound-attribute has more than one value. ---------------------------------------------- | value-tag | 1 byte ---------------------------------------------- | name-length | 2 bytes ---------------------------------------------- | name | u bytes ---------------------------------------------- | value-length | 2 bytes ---------------------------------------------- | value | v bytes ----------------------------------------------------------- | value-tag | 1 bytes | ---------------------------------------------- | | 0x0000 | 2 bytes | ---------------------------------------------- |- 0 or more | value-length | 2 bytes | ---------------------------------------------- | | value | w bytes | -----------------------------------------------------------   Received: from cnri by ietf.org id aa27502; 9 Jul 97 23:09 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid XAA16189 for ; Wed, 9 Jul 1997 23:08:05 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA10989 for ; Wed, 9 Jul 1997 23:04:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 9 Jul 1997 23:01:22 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA10545 for ipp-outgoing; Wed, 9 Jul 1997 22:55:12 -0400 (EDT) Date: Wed, 9 Jul 1997 19:56:10 -0700 From: Robert Herriot Message-Id: <199707100256.TAA27528@woden.eng.sun.com> To: ipp@pwg.org, xriley@cp10.es.xerox.com Subject: Re: IPP> MOD - Questions on IPP Model and Protocol Document (model-issues-970623.pdf) X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > From xriley@cp10.es.xerox.com Wed Jul 9 01:33:27 1997 > > all, > Clarification on the following would be appreciated. I'm trying > to tie the new Protocol document (ipp970702.doc) to the Model > document. My comments are preceded by "XDR>". > > > 319 2.2.2 Parameters > 323 attributes, some do not. All parameters are defined in section 5. > XDR> Its not clear to me what are "parameters" in section 5. There are > XDR> not explicitly identified. The protocol document mentions > XDR> "parameter groups" which are not mentioned in the Model document. I am gradually tightening up the language in the protocol document. The version of 7/8.97 does a better job. Briefly, the model document names explicit parameters and collections of attribute for transmission within operations. We have tried to distinguish these two. Generally the parameter are most important for the operation and attribute provide additional information. > > > 723 5.1.2.1 Print Job Request > XDR> It is stated that the "document-name" is MANDATORY. Line 735 states > XDR> that the simplest Print-Job request consists of just the Document > XDR> Content and nothing else. Is this a conflict? I've noticed that contradiction. We intended that it is possible for a Print-Job to have no parameters/attributes -- just Document data. > > > 974 5.1.8 Cancel Job Operation > XDR> It is stated that only the job originator can cancel the job. How much > XDR> credibility are you placing in the validity of the > XDR> "job-originating-user" value. This validity should be tied into the > XDR> different security methods used and the differences should be stated. > XDR> In order to truly accomplish this, the user has to be authenticated, > XDR> which leads you down the path to talking about security issues. > Question, > XDR> should this be moved to the IPP Security document? > > > 1043 "The requested attributes of the object with their current valuesSHALL" > XDR> I'm not sure you meant to have "SHALL" at the end of this sentence. Yes. This is still a dangling issue and involves security. > > > 1051 A Printer MAY be configured, for security reasons, not > to return all attributes that a client requests. It may > 1052 even return none of the requested attributes. In such > cases, the status returned is the same as if the Printer > 1053 had returned all requested attributes. The client cannot > tell by such a response whether the requested > 1054 attribute was present or absent on the Printer. > XDR> What is the rationale behind this policy of not > XDR> guaranteeing a return? It would be nice to guarantee this > XDR> return so the client could dynamically build the UI querying > XDR> for all of the supported attributed on a printer. We cannot guarantee what attributes will be returned because some printer may consider the return of certain attributes to be a security violation. As a result a client may see different attributes coming from different printers or even different jobs on the same printer. > > > 1068 4. If the client supplies an attribute group keyword that is > not unsupported, ... > XDR> Did you really mean to use "not unsupported" ? > > > 1248 ... the "printer-job-template" group in order to get the > XDR> Should "printer-job-template" be printer "job-template" ? > > > ______________________________________________________________________ > Xavier Riley > Xerox Corp. Voice: 310-333-8329 / 8*823-8329 > Corp. Research & Tech. Fax: 310-333-6618 / 8*823-6618 > 701 S. Aviation Blvd ESAE-231 Email: xriley@cp10.es.xerox.com > El Segundo, California 90245 http://www.cp10.es.xerox.com/~xriley > ______________________________________________________________________ > > >   Received: from cnri by ietf.org id aa29057; 10 Jul 97 1:03 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid BAA16384 for ; Thu, 10 Jul 1997 01:02:36 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA12530 for ; Thu, 10 Jul 1997 00:58:58 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 10 Jul 1997 00:55:34 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA12094 for ipp-outgoing; Thu, 10 Jul 1997 00:49:23 -0400 (EDT) Message-Id: <3.0.1.32.19970709173732.00a07ab0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 9 Jul 1997 17:37:32 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Minutes from PWG IPP Phone Conference 970709 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Minutes from PWG IPP Phone Conference 970709 Attending: Carl-Uno Manros Steve Zilles Tom Hastings Roger deBry Bob Herriot Stan McConnell Lee Farrell Ira McDonald The main discussion topic was to get further reactions to Bob Herriot's latest draft for the Protocol document. The following points were discussed: - Clarify terminology to be able to clearly distinguish between parametrs that are attributes vs. the ones that are not. It was also suggested to have a separate naming convention for non-attribute parameters so they could be easily distiguished. - The subject of "private" operations came up. It was decided to reserv operation numbers up to 16K, which would allow experimental use of new operations using higher numbers. - The subject of an additional element in the encoding to express type was brought up for discussion again. Bob will be writing up an alternative text that includes the typing field and try to solicit input from other experts that were not in the call, to determine whether we should raise this subject for renewed discussion. - Bob will make further updates to the protocol draft. The plan is now to have a version ready as an I-D for early next week. A number of other home work assignments from Nassau were discussed: - Tom and Jay have discussed some further improvements on the IPP/RFC1179 mapping, and Steve and Bob gave some further verbal comments, which Tom will include in the document. Some discussion was held around the actual use of the RFC1179 parameters vs. the documented use in RFC1179. It was suggested that our document will point out common practise were it differs from the parameters in RFC1179, but will not go into discussing parameters which have been invented as extensions by various vendors. It was discussed how urgent it was to get this out as an I-D and the conclusion was that we should try to get it out ASAP, so we can get feedback before the Munich meeting. We expect to send the document to the IETF early next week. - Steve will take on the task to write up the "Why we decided to shoot ourselves in the foot" document as requested by Harald, but choose a more suitable title and explain our rationale for using HTTP 1.1 and other architectural choices. This should also be ready early next week, so it can be sent to IETF together with the Protocol I-D. - The Security subgroup will contribute texts to the Model, Directory, and Protocol documents by the end of this week. - Scott has promised to try to have a new version of the Model document out by July 14 containing the updates discussed in Nashua, plus any comments that have come in over the DL later. Bob will communicate updates to and issues discovered in the Protocol document directly to Scott by the end of this week. - Carl-Uno has taken on to update the Requirements document for a revised version in time for the Munich deadline. Comments have come from Peter Zehler and Roger deBry so far. Send any further comments to the DL and Carl-Uno. Some discussion was held on the IETF rules for last calls about consensus. It was suggested that we will not need to make any last calls for the WG until after Munich, but we should warn the DL particpants that we expect to make last calls for all the documents not too long after the Munich meeting. The next IPP Phone Conference will be held next Wednesday on July 16. Carl-Uno and Tom are unlikely to attend next week as we will be in a training course. Steve Zilles will therefore lead next week's phone conference. --- 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   Received: from cnri by ietf.org id aa15898; 10 Jul 97 14:09 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid OAA18677 for ; Thu, 10 Jul 1997 14:08:29 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA14090 for ; Thu, 10 Jul 1997 14:04:48 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 10 Jul 1997 13:55:56 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA13600 for ipp-outgoing; Thu, 10 Jul 1997 13:48:59 -0400 (EDT) From: Roger K Debry To: ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: IPP> Tweak to protocol - your note Message-Id: <5030100004593747000002L072*@MHS> Date: Thu, 10 Jul 1997 13:50:33 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org I agree with the new proposal! Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080   Received: from cnri by ietf.org id aa16010; 10 Jul 97 14:16 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid OAA18698 for ; Thu, 10 Jul 1997 14:15:16 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA14569 for ; Thu, 10 Jul 1997 14:11:38 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 10 Jul 1997 14:05:07 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA13615 for ipp-outgoing; Thu, 10 Jul 1997 13:54:24 -0400 (EDT) Message-Id: <9707101653.AA05112@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, 10 Jul 1997 09:51:06 PDT To: Robert Herriot From: Tom Hastings Subject: Re: IPP>PRO new version of protocol doc for Wed meeting Cc: ipp@pwg.org Sender: ipp-owner@pwg.org I've posted 3 versions of the .pdf file: black revisions, red revisions, and no revisions. ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ -rw-r--r-- 1 pwg pwg 86940 Jul 10 16:47 ipp970708-rev-red.pdf -rw-r--r-- 1 pwg pwg 91136 Jul 9 02:57 ipp970708-rev.doc -rw-r--r-- 1 pwg pwg 85064 Jul 10 16:47 ipp970708-rev.pdf -rw-r--r-- 1 pwg pwg 319415 Jul 9 02:58 ipp970708-rev.ps -rw-r--r-- 1 pwg pwg 78848 Jul 9 02:57 ipp970708.doc -rw-r--r-- 1 pwg pwg 70055 Jul 10 16:48 ipp970708.pdf -rw-r--r-- 1 pwg pwg 223414 Jul 9 02:57 ipp970708.ps Tom At 20:10 07/08/97 PDT, Robert Herriot wrote: > >I have made a few revisions to the IPP protocol document based on feedback. >The protocol has not changed -- only the explanation has. Hopefully >it is clearer now. > >The documents that I have downloaded are: > >Without revision marks: > >ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp970708.doc >ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp970708.ps > >With revision marks relative to the July 2 version. > >ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp970708-rev.doc >ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp970708-rev.ps > >Hopefully, enough of you will have looked over the changes >that we can review the new one without revisions marks. > >If someone can produce a pdf or txt version, I would appreciate it. >BTW, I forgot to change the date in the document. It still says July 2. > >Bob Herriot > >   Received: from cnri by ietf.org id aa16181; 10 Jul 97 14:25 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid OAA18735 for ; Thu, 10 Jul 1997 14:23:50 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA15107 for ; Thu, 10 Jul 1997 14:20:10 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 10 Jul 1997 14:13:26 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA13961 for ipp-outgoing; Thu, 10 Jul 1997 14:02:07 -0400 (EDT) Message-Id: <3.0.1.32.19970710095325.00a80c70@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 10 Jul 1997 09:53:25 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> PRO - Comment on latest encoding proposal Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org From Bob's text: 1.1 Syntax of Encoding The encoding consists of: . version . operation (for a request) or status (for a response) . parameter-tag . parameter-sequence . attribute-tag . attribute-sequence . data-tag . data (absent for some operations) Bob< I thought that the discussion in yesterday's phone conference indicated that the attribute sequence could also be omitted. Also, do we require the attribute-tag and data-tag to always be present even if the attribute-sequence or data are empty? 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   Received: from cnri by ietf.org id aa16393; 10 Jul 97 14:37 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid OAA18771 for ; Thu, 10 Jul 1997 14:35:56 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA15750 for ; Thu, 10 Jul 1997 14:32:17 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 10 Jul 1997 14:26:13 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA14649 for ipp-outgoing; Thu, 10 Jul 1997 14:13:20 -0400 (EDT) Message-ID: <33C524C5.5620B217@sharplabs.com> Date: Thu, 10 Jul 1997 11:07:02 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.01b6C [en] (X11; I; SunOS 4.1.4 sun4m) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> Tweak to protocol - your note X-Priority: 3 (Normal) References: <5030100004593747000002L072*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org I thought Steve Zilles' original proposal was just to add a type byte to the attribute/parameter value, and not to the 'name'? Do we need all of these new 'byte' fields or just one of them? Randy Roger K Debry wrote: > I agree with the new proposal! > > Roger K deBry > Senior Techncial Staff Member > Architecture and Technology > IBM Printing Systems > email: rdebry@us.ibm.com > phone: 1-303-924-4080 -- Randy Turner   Received: from cnri by ietf.org id aa16473; 10 Jul 97 14:39 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid OAA18789 for ; Thu, 10 Jul 1997 14:38:24 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA16108 for ; Thu, 10 Jul 1997 14:34:46 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 10 Jul 1997 14:30:31 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA15015 for ipp-outgoing; Thu, 10 Jul 1997 14:18:22 -0400 (EDT) Date: Thu, 10 Jul 1997 11:16:47 PST From: David_Kellerman@nls.com To: ipp@pwg.org Message-ID: <009B70AB.387025F2.9@nls.com> Subject: Re: IPP>PRO proposed tweak to protocol Sender: ipp-owner@pwg.org > In today's meeting we decided to propose one last small tweak to the > IPP protocol. We decided that I would send out this proposal for all > of you to read and comment on. > > I think that it is an improvement. I hope that you will agree. Please. I can't see where this change amounts to a hill of beans, one way or the other. I've decoded enough line encodings, with and without type tags, to be confident that, in the big picture, this doesn't matter. What's driving me crazy is to see "the protocol encoding discussion that wouldn't die." And each time we get a slightly different quorum, it takes off in a different direction. It's chewed up endless e-mail messages on the mailing list, it took a half day of the IPP meetings in Nashua, and I'm sure that's only a small sampling. Let me take another tack -- maybe this will be useful for future discussion. We've all been watching the Pathfinder mission (haven't we?), and we've gotten it drilled into us about how this is NASA's new way of doing space exploration -- "faster, better, cheaper" or something thereabouts. My impression is that, basically, they've tried to be smarter about what's important, and where they spend their hours and dollars -- stock components wherever possible; if a solution is good enough to do the job, move on to the next thing; which investment of effort is likely to have to greatest benefit. They're not wasting time debating what shape of nuts to use -- four sided, six sided; hey, they're some advantages to seven sided, you know. Haarrumph! :: David Kellerman Northlake Software 503-228-3383 :: david_kellerman@nls.com Portland, Oregon fax 503-228-5662   Received: from cnri by ietf.org id aa17130; 10 Jul 97 15:04 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid PAA18890 for ; Thu, 10 Jul 1997 15:03:28 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA16628 for ; Thu, 10 Jul 1997 14:59:50 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 10 Jul 1997 14:56:37 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA16196 for ipp-outgoing; Thu, 10 Jul 1997 14:50:27 -0400 (EDT) Date: Thu, 10 Jul 1997 14:50:30 -0400 (EDT) From: JK Martin Message-Id: <199707101850.OAA27094@uscore.underscore.com> To: ipp@pwg.org Subject: Re: IPP>PRO proposed tweak to protocol Cc: SBUTLER@hpbs2024.boi.hp.com, paulmo@microsoft.com X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I agree with David completely. Based on the content of Bob's submission, I just don't see the value in making this kind of change, particularly at this point in time. Perhaps Bob (or another proponent) can better illustrate the supposed advantages to this proposal? No matter what, we really need to (publicly) hear what Microsoft and Hewlett-Packard have to say on this matter. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- ----- Begin Included Message ----- From ipp-owner@pwg.org Thu Jul 10 14:32 EDT 1997 Date: Thu, 10 Jul 1997 11:16:47 PST From: David_Kellerman@nls.com To: ipp@pwg.org Subject: Re: IPP>PRO proposed tweak to protocol > In today's meeting we decided to propose one last small tweak to the > IPP protocol. We decided that I would send out this proposal for all > of you to read and comment on. > > I think that it is an improvement. I hope that you will agree. Please. I can't see where this change amounts to a hill of beans, one way or the other. I've decoded enough line encodings, with and without type tags, to be confident that, in the big picture, this doesn't matter. What's driving me crazy is to see "the protocol encoding discussion that wouldn't die." And each time we get a slightly different quorum, it takes off in a different direction. It's chewed up endless e-mail messages on the mailing list, it took a half day of the IPP meetings in Nashua, and I'm sure that's only a small sampling. Let me take another tack -- maybe this will be useful for future discussion. We've all been watching the Pathfinder mission (haven't we?), and we've gotten it drilled into us about how this is NASA's new way of doing space exploration -- "faster, better, cheaper" or something thereabouts. My impression is that, basically, they've tried to be smarter about what's important, and where they spend their hours and dollars -- stock components wherever possible; if a solution is good enough to do the job, move on to the next thing; which investment of effort is likely to have to greatest benefit. They're not wasting time debating what shape of nuts to use -- four sided, six sided; hey, they're some advantages to seven sided, you know. Haarrumph! :: David Kellerman Northlake Software 503-228-3383 :: david_kellerman@nls.com Portland, Oregon fax 503-228-5662 ----- End Included Message -----   Received: from cnri by ietf.org id aa20190; 10 Jul 97 17:22 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA21512 for ; Thu, 10 Jul 1997 17:20:55 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA17651 for ; Thu, 10 Jul 1997 17:17:19 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 10 Jul 1997 17:10:16 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA16799 for ipp-outgoing; Thu, 10 Jul 1997 16:59:27 -0400 (EDT) Date: Thu, 10 Jul 1997 14:00:09 -0700 From: Robert Herriot Message-Id: <199707102100.OAA28238@woden.eng.sun.com> To: ipp@pwg.org, jkm@underscore.com Subject: Re: IPP>PRO proposed tweak to protocol Cc: SBUTLER@hpbs2024.boi.hp.com, paulmo@microsoft.com X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I tried to indicate the advantages to the tag byte yesterday. I will try to give more information now. The advantage of the change is admittedly small, but nonetheless positive. There were two motivating factors: value-typing and elimination of negative lengths. Value-typing was the catalyst for the change and elimination negative lengths was a fortunate outcome. Value Typing: We have discussed typing at length. We have said that in version 1, implementations would hardcode typing along with localization. But some people have argued persuasively that an implementation may want to process values, at least into integer or character string internal representations before looking up an attribute to determine its type. This argues for typing of at least integer and character string without futher subdivision into booleans and enums for integers for keynames and dateTimes for character strings. It was also observed there is a long history of typing fields being useful and that PDF and TIFF have typing fields. Some people strongly believe that we will eventually need a typing field, so we should put it in now to avoid a major revision of the protocol, even if it distinguishes only integer and character string. These people believe that it is important for a decoder to be able to fully parse an encoding down to its constituent values without knowing the semantics. There is some merit to that view. Negative Lengths: Negative lengths are a reasonable solution to the problem and we certainly could continue to live with them. They work. But they need a careful explanation because negative lengths are unexpected and because the specification of representation of negative integers assumes 2's complement integer which may not yet be universal. Neither of these problems argues for eliminating negative lengths per se, but the solution with tags does seem slightly better. Summary At this point, I think we should ask whether there are strong arguments against this change from a technical view? For people who are concerned about constant change, I see this as the last change before we get experience from implementations which will hopefully verify that we have made good decisions. Bob Herriot   Received: from cnri by ietf.org id aa20197; 10 Jul 97 17:22 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA21518 for ; Thu, 10 Jul 1997 17:21:04 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA17667 for ; Thu, 10 Jul 1997 17:17:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 10 Jul 1997 17:12:25 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA16814 for ipp-outgoing; Thu, 10 Jul 1997 17:01:25 -0400 (EDT) Date: Thu, 10 Jul 1997 14:02:13 -0700 From: Robert Herriot Message-Id: <199707102102.OAA28244@woden.eng.sun.com> To: ipp@pwg.org Subject: Re: IPP> PRO - Comment on latest encoding proposal X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Perhaps you overlooked the following paragraph in the description I emailed out yesterday. The parameter-tag and parameter-sequence may be omitted if the operation has no parameters. The attribute-tag and attribute-sequence may be omitted if the operation has no attributes or it may be replicated for an operation that contains attributes for multiple objects. The data-tag is present even when the data is omitted. I believe that the mandatory data-tag makes it easier to decode because with the mandatory tag, there is only a check of the tag in each cycle. Without a mandatory data-tag, there would have to be a check for both some end-of data index and the contents of the next tag. Bob Herriot > From cmanros@cp10.es.xerox.com Thu Jul 10 11:17:15 1997 > X-Sender: cmanros@garfield > X-Mailer: Windows Eudora Pro Version 3.0.1 (32) > Date: Thu, 10 Jul 1997 09:53:25 PDT > To: ipp@pwg.org > From: Carl-Uno Manros > Subject: IPP> PRO - Comment on latest encoding proposal > Mime-Version: 1.0 > Sender: ipp-owner@pwg.org > X-Lines: 30 > > From Bob's text: > > 1.1 Syntax of Encoding > > The encoding consists of: > > . version > . operation (for a request) or status (for a response) > . parameter-tag > . parameter-sequence > . attribute-tag > . attribute-sequence > . data-tag > . data (absent for some operations) > > Bob< > > I thought that the discussion in yesterday's phone conference indicated > that the attribute sequence could also be omitted. Also, do we require the > attribute-tag and data-tag to always be present even if the > attribute-sequence or data are empty? > > 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 >   Received: from cnri by ietf.org id aa21889; 10 Jul 97 18:50 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid SAA21814 for ; Thu, 10 Jul 1997 18:48:56 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA18300 for ; Thu, 10 Jul 1997 18:45:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 10 Jul 1997 18:41:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA17869 for ipp-outgoing; Thu, 10 Jul 1997 18:35:41 -0400 (EDT) Date: Thu, 10 Jul 1997 18:35:41 -0400 (EDT) From: JK Martin Message-Id: <199707102235.SAA14789@uscore.underscore.com> To: Robert.Herriot@eng.sun.com Subject: Re: IPP>PRO proposed tweak to protocol Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org One of the problems I (and others) have had with much of the IPP verbage on the list is the lack of clear examples to back up the various proposals. This appears to be true for this new "tweak" proposal as well. One of the things I really liked about the SWP drafts is that the authors took the time to literally spell out real-world examples of the various encodings. Bob, can you post a couple of encoding examples, where each example is shown using the current agreed upon encoding *and* your new "tweaked" form? Your effort would be greatly appreciated by those of us who are currently inundated by work on other, related printer standards efforts. ...jay   Received: from cnri by ietf.org id aa24112; 10 Jul 97 21:14 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid VAA22195 for ; Thu, 10 Jul 1997 21:12:49 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA19151 for ; Thu, 10 Jul 1997 21:09:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 10 Jul 1997 21:06:02 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA18713 for ipp-outgoing; Thu, 10 Jul 1997 20:59:49 -0400 (EDT) Message-Id: <9707110056.AA24104@cabeza.cp10.es.xerox.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Robert Herriot Cc: ipp@pwg.org Subject: IPP> PRO - Security Considerations Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Jul 1997 17:56:11 PDT From: John Wenn Sender: ipp-owner@pwg.org As a member of the security subgroup, here's a first cut at a revision of the "Security Considerations" section of the Protocol document. /John ------------------- Security Considerations When utilizing HTTP 1.1 as a transport of IPP, the security considerations outlined in RFC 2068 apply. Specifically, IPP servers can generate a 401 "Unauthorized" response code to request client authentication and IPP clients should correctly respond with the proper "Authorization" header. Both Basic Authentication (RFC 2068) and Digest Authentication (RFC 2069) flavors of authentication should be supported. The server chooses which type(s) of authentication to accept. Digest Authentication is a more secure method, and is always preferred to Basic Authentication. For secure communication (privacy in particular), IPP should be run using a secure communications channel. Both Transport Layer Security - TLS (draft-ietf-tls-protocol-03) and IPSec (RFC 1825) provide necessary features for security. It is possible to combine the two techniques, HTTP 1.1 client authentication (either basic or digest) with secure communications channel (either TLS or IPSec). Together the two are more secure than client authentication and they perform user authentication. Complete discussion of IPP security considerations can be found in the IPP Security document   Received: from cnri by ietf.org id aa24389; 10 Jul 97 21:32 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid VAA22231 for ; Thu, 10 Jul 1997 21:31:14 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA19690 for ; Thu, 10 Jul 1997 21:27:36 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 10 Jul 1997 21:22:34 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA19234 for ipp-outgoing; Thu, 10 Jul 1997 21:16:17 -0400 (EDT) Date: Thu, 10 Jul 1997 18:16:38 -0700 From: Robert Herriot Message-Id: <199707110116.SAA28440@woden.eng.sun.com> To: Robert.Herriot@eng.sun.com, jkm@underscore.com Subject: IPP>PRO examples for proposed tweak to protocol Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Good idea Jay. > Bob, can you post a couple of encoding examples, where each example > is shown using the current agreed upon encoding *and* your new > "tweaked" form? Your effort would be greatly appreciated by those > of us who are currently inundated by work on other, related printer > standards efforts. > > ...jay > In the following examples, the 'agreed octets' column shows the agreed-on protocol. The 'new octets' columns shows the proposed protocol. Some rows in the 'agreed octets' column are empty where there are no bytes of that type in the protocol. I am keeping the typing simple by having only generic integer and generic string which I called unspecified integer and unspecified string in the proposal yesterday. These two value types are probably sufficient to satisfy the requirement states by advocates of the type byte. I have marked rows that differ between the two protocols with '|'. The additions and changes to the new protocol are: each name-length is preceded by a value-tag in hte new protocol there is a new parameter-tag before the parameter-sequence if there are parameters. the attribute-tag and data-tags are reduced to a single byte and have different values Here is an example of a Print-Job request. Agreed New Octets Octets Description 0x0100 0x0100 version 0x0002 0x0002 operation | 0xFFFE 0x02 attribute tag (no preceding parameters) | 0x40 value-tag (generic string) 0x0008 0x0008 name-length job-name job-name name 0x0006 0x0006 value-length foobar foobar value | 0x20 value-tag (generic integer) 0x0005 0x0005 name-length copies copies name 0x0001 0x0001 value-length 0x01 0x01 value | 0xFFFF 0x03 data-tag %!PS... %!PS... data Here is an example of Print-URI request with the same parameters as with Print-Job Agreed New Octets Octets Description 0x0100 0x0100 version 0x0003 0x0003 operation | 0x01 parameter tag 0x000A 0x000A name-length document-uri document-uri name 0x0011 0x11 value-length ftp://foo.com/foo ftp://foo.com/foo value | 0xFFFE 0x02 attribute tag | 0x40 value-tag (generic (unspecified) string) 0x0008 0x0008 name-length job-name job-name name 0x0006 0x0006 value-length foobar foobar value | 0x20 value-tag (generic (unspecified) integer) 0x0005 0x0005 name-length copies copies name 0x0001 0x0001 value-length 0x01 0x01 value | 0xFFFF 0x03 data-tag %!PS... %!PS... data Here is an example of Create-Job request with the no parameters and no attributes Agreed New Octets Octets Description 0x0100 0x0100 version 0x0005 0x0005 operation | 0xFFFF 0x03 data-tag %!PS... %!PS... data Here is an example of a Get-Jobs request with parameters but no attributes. Agreed New Octets Octets Description 0x0100 0x0100 version 0x000A 0x000A operation | 0x01 parameter-tag | 0x20 value-tag (generic integer) 0x0005 0x0005 name-length limit limit name 0x0001 0x0001 value-length 0x32 0x32 value | 0x40 value-tag (generic string) 0x0014 0x0014 name-length requested-attributes requested-attributes name 0x0007 0x0007 value-length job-uri job-uri value | 0x40 value-tag (generic string) 0x0000 0x0000 name-length (multi-valued) 0x0008 0x0008 value-length job-name job-name value | 0xFFFF 0x03 data-tag Here is an example of Get-Jobs response from previous request Agreed New Octets Octets Description 0x0100 0x0100 version 0x0000 0x0000 status | 0x01 parameter-tag | 0x40 value-tag (generic integer) 0x0005 0x0005 name-length reason-phrase reason-phrase name 0x0002 0x0002 value-length OK OK value | 0xFFFE 0x02 attribute-tag (1st object) | 0x40 value-tag (generic string) 0x0007 0x0007 name-length job-uri job-uri name 0x000E 0x000E value-length http://foo/123 http://foo/123 value | 0x40 value-tag (generic string) 0x0008 0x0008 name-length job-name job-name name 0x0003 0x0003 name-length foo foo name | 0xFFFE 0x02 attribute-tag (2nd object) | 0x40 value-tag (generic string) 0x0007 0x0007 name-length job-uri job-uri name 0x000E 0x000E value-length http://foo/124 http://foo/124 value | 0x40 value-tag (generic string) 0x0008 0x0008 name-length job-name job-name name 0x0003 0x0003 name-length bar bar name | 0xFFFF 0x03 data-tag   Received: from cnri by ietf.org id aa27043; 10 Jul 97 22:55 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid WAA22352 for ; Thu, 10 Jul 1997 22:54:40 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA20469 for ; Thu, 10 Jul 1997 22:51:01 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 10 Jul 1997 22:46:16 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA20024 for ipp-outgoing; Thu, 10 Jul 1997 22:39:58 -0400 (EDT) Message-Id: <3.0.1.32.19970710153026.009971a0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 10 Jul 1997 15:30:26 PDT To: David_Kellerman@nls.com, ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP>PRO proposed tweak to protocol In-Reply-To: <009B70AB.387025F2.9@nls.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 12:16 PM 7/10/97 PDT, David_Kellerman@nls.com wrote: >> In today's meeting we decided to propose one last small tweak to the >> IPP protocol. We decided that I would send out this proposal for all >> of you to read and comment on. >> >> I think that it is an improvement. I hope that you will agree. > >Please. I can't see where this change amounts to a hill of beans, one >way or the other. I've decoded enough line encodings, with and without >type tags, to be confident that, in the big picture, this doesn't >matter. What's driving me crazy is to see "the protocol encoding >discussion that wouldn't die." And each time we get a slightly >different quorum, it takes off in a different direction. It's chewed up >endless e-mail messages on the mailing list, it took a half day of the >IPP meetings in Nashua, and I'm sure that's only a small sampling. > >:: David Kellerman Northlake Software 503-228-3383 David, as chair of the group I would also like us to reach agreements more quickly and move on. On the other hand, the IETF process does not recognize metings such as the one we held in Nassua to be binding for the IETF WG, which means that recommendations from such meetings can still be questioned on the DL. The impression from our discussions in Nashua and earlier seem to indicate that there are several "good enough" solutions and that it boils down to which one is a particular expert's favorite. Even so, we need to get to a final consensus. I want to hear back, on the DL, as quickly as possible where people now stand, so that we can indeed put this particular part of our specification to bed and move on. I would like your responses back no later than Monday, July 13. 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   Received: from cnri by ietf.org id aa11252; 11 Jul 97 12:08 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid MAA23889 for ; Fri, 11 Jul 1997 12:07:21 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA22206 for ; Fri, 11 Jul 1997 12:03:42 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 11 Jul 1997 11:55:58 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA21753 for ipp-outgoing; Fri, 11 Jul 1997 11:49:43 -0400 (EDT) From: Peter Zehler To: "Redirector IPP (E-mail)" Subject: IPP> TES: prototype ping results Date: Fri, 11 Jul 1997 08:31:54 PDT X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Message-Id: <97Jul11.082949pdt."52669(2)"@alpha.xerox.com> Sender: ipp-owner@pwg.org All, Here is the list I have of "individuals" that have indicated they will be working on an IPP prototype. Bob Chansler (Adobe) Ashok Maniam (Byas Systems) Lee Farrell (Cannon) Dan Cogswell (IBM) Steve Gebert (IBM) Ted Tronson (Novell) Randy Turner (Sharp) Jay Martin (Underscore) Zhi-Hong Huang (Zenographics) Rick Yardumian (Xerox) Peter Zehler (Xerox) Jasper Wong (Xionics) We are still missing individuals who work for companies that provide certain well known operating systems. Also absent are some of the major printer vendors. I would hope that the IPP prototyping effort would include representatives from the Simple Web Printing camp to insure interoperability. Pete __________________________________ Email: pzehler@channels.mc.xerox.com US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. Webster NY, 14580-9701 Voice: (716) 265-8755 FAX: (716)265-8792 __________________________________ "I always wanted to be somebody, but I should have been more specific." Lily Tomlin __________________________________   Received: from cnri by ietf.org id aa12307; 11 Jul 97 13:02 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA24088 for ; Fri, 11 Jul 1997 13:01:28 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA22822 for ; Fri, 11 Jul 1997 12:57:50 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 11 Jul 1997 12:51:58 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA22344 for ipp-outgoing; Fri, 11 Jul 1997 12:45:46 -0400 (EDT) Date: Fri, 11 Jul 1997 12:42:15 -0400 (EDT) From: JK Martin Message-Id: <199707111642.MAA06930@uscore.underscore.com> To: cmanros@cp10.es.xerox.com Subject: Re: IPP>PRO proposed tweak to protocol Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > I want to hear back, on the DL, as quickly as possible where people now > stand, so that we can indeed put this particular part of our specification > to bed and move on. I would like your responses back no later than Monday, > July 13. I take it you mean "Monday, July 14" as the deadline. In any case, I don't think the proper consensus can be reached until we hear from the sponsors of the SWP proposal (Microsoft and HP). Hopefully they are monitoring this discussion and will post their "votes" by this Monday. After reviewing Bob Herriot's set of example encodings (nice job, Bob), I feel I understand the impact of the proposed "tweak", yet I still don't come away with a strong feeling that such a change is really needed. I realize that some folks (such as Steve Zilles and Roger deBry) have been lobbying for a Tag-Length-Value (TLV) approach for a while now, but the group had previously said NO to this approach (right?). Yet, the topic is once again being brought up for consideration. If the desire is to have a TLV mechanism, then why are we reinventing what has already been accomplished via ASN.1/BER? (This is precisely what several people had previously asked back when this topic was discussed on the DL...and the net consensus was "Don't Do It".) Personally (FWIW), I could live with this proposal if I had to. But as I keep saying, what really matters is whether the authors of SWP are willing to accept it. If accepting this proposal causes the SWP camp to revert to the position prior to the Nashua meetings (ie, two conformance levels, where Microsoft doesn't implement some of the absolutely key features for IPP), then this proposal is totally unacceptable. The greater good of IPP rests with pervasive deployment of a reasonable set of standard features. Anything that gets in the way of this simple goal--such as insisting on this "tweak" proposal--should be discarded out of hand, IMHO. Let's see what Microsoft and HP have to say about this proposal. ...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 -- ----------------------------------------------------------------------   Received: from cnri by ietf.org id aa12435; 11 Jul 97 13:09 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA24115 for ; Fri, 11 Jul 1997 13:08:01 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA23303 for ; Fri, 11 Jul 1997 13:04:22 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 11 Jul 1997 13:01:15 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA22405 for ipp-outgoing; Fri, 11 Jul 1997 12:52:18 -0400 (EDT) Date: Fri, 11 Jul 1997 12:48:48 -0400 (EDT) From: JK Martin Message-Id: <199707111648.MAA07390@uscore.underscore.com> To: pzehler@channels.mc.xerox.com Subject: Re: IPP> TES: prototype ping results Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Thanks for the updated list of early implemeters, Peter. Your comments about "missing individuals" raises an interesting question: Shouldn't those individuals who lobby long and hard for certain features also be the ones standing up to commit to developing an early implemention (ie, prototype) containing those features for which they have strong opinions? Kinda like the old saying, "Put up or shut up" (or something like that). Just a thought... I know I'm not alone in saying that we can't afford to start our prototype until the protocol encoding rules are firmly nailed down. ...jay ----- Begin Included Message ----- From ipp-owner@pwg.org Fri Jul 11 11:57 EDT 1997 From: Peter Zehler To: "Redirector IPP (E-mail)" Subject: IPP> TES: prototype ping results Date: Fri, 11 Jul 1997 08:31:54 PDT All, Here is the list I have of "individuals" that have indicated they will be working on an IPP prototype. Bob Chansler (Adobe) Ashok Maniam (Byas Systems) Lee Farrell (Cannon) Dan Cogswell (IBM) Steve Gebert (IBM) Ted Tronson (Novell) Randy Turner (Sharp) Jay Martin (Underscore) Zhi-Hong Huang (Zenographics) Rick Yardumian (Xerox) Peter Zehler (Xerox) Jasper Wong (Xionics) We are still missing individuals who work for companies that provide certain well known operating systems. Also absent are some of the major printer vendors. I would hope that the IPP prototyping effort would include representatives from the Simple Web Printing camp to insure interoperability. Pete __________________________________ Email: pzehler@channels.mc.xerox.com US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. Webster NY, 14580-9701 Voice: (716) 265-8755 FAX: (716)265-8792 __________________________________ "I always wanted to be somebody, but I should have been more specific." Lily Tomlin __________________________________ ----- End Included Message -----   Received: from cnri by ietf.org id aa15764; 11 Jul 97 15:38 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid PAA24750 for ; Fri, 11 Jul 1997 15:37:43 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA24136 for ; Fri, 11 Jul 1997 15:34:05 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 11 Jul 1997 15:30:20 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA23692 for ipp-outgoing; Fri, 11 Jul 1997 15:24:07 -0400 (EDT) Message-Id: <3.0.1.32.19970711105739.00bac3a0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 11 Jul 1997 10:57:39 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> MOD - Printer resolutions Cc: "Cancio,Vivian" , "McIntyre2,Lloyd" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org One of my home work assignments from Nashua was to try to find out about the resolutions used by fax machines. The simple answer in DPI is: res-100 (no mm equivalent) res-200x100 (note that x-resolution is higher than y-resolution) res-200 res-300 (no mm equivalent) res-400 However, this is only part of the truth. Most fax machines, as well as some printers, are natively based on lines/mm rather than DPI, which means that we also need to be able to express values in lines/mm if we want to be exact. Hence, we also need the following fax resolution values expressed in lines/mm: res-7.7x3.85 res-7.7 res-8x15.4 (no inch equivalent) res-15.4 There are two possible ways of doing this, either by adding this in the attribute value for resolution, or by adding a separate attribute for the native measuring system of the fax/printer. In the first case we would end up with values like: res-200x100-inch and res-7.7x3.85-mm In the second case we would skip the last part of the resolution value and instead have a new attribute called "printer-resolution-base" with the two values: "metric" and "inch". I suggest to use the second solution, which seems more extensible for the future and which would allow a client to quickly find out what the base is without having to read a potentially long list of resolution values. I would also encourage people in the WG that are working with metric based printers to come up with a list of the metric values that we would need to add for printers. Comments? Omissions? 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   Received: from cnri by ietf.org id aa17101; 11 Jul 97 16:20 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA24948 for ; Fri, 11 Jul 1997 16:19:16 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA24700 for ; Fri, 11 Jul 1997 16:15:38 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 11 Jul 1997 16:12:26 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA24261 for ipp-outgoing; Fri, 11 Jul 1997 16:06:13 -0400 (EDT) Message-ID: From: Sylvan Butler X-Real-Sender: SYLVAN Organization: Hewlett-Packard, Boise To: ipp@pwg.org Date: Fri, 11 Jul 1997 14:04:34 -0700 Subject: Re: IPP>PRO proposed tweak to protocol Priority: normal X-mailer: Pegasus Mail v3.41 (preview) Sender: ipp-owner@pwg.org Jay Martin wrote: >After reviewing Bob Herriot's set of example encodings (nice job, Bob), >I feel I understand the impact of the proposed "tweak", yet I still don't >come away with a strong feeling that such a change is really needed. I would concur. Bob asked for "strong arguments against" it and I really don't have any. I don't think it is that hard to implement. It just adds some additional error conditions that need to be clearly documented, implemented, and tested. Just one more straw for the camel's back... (Did anyone else have that game years ago??? A camel who was split in the middle with an elastic band connecting front with back half. You add "straws" to the basket on his back, whoever adds "the straw that breaks the camel's back" loses... They sit out the remainder.) >I realize that some folks (such as Steve Zilles and Roger deBry) have >been lobbying for a Tag-Length-Value (TLV) approach for a while now, AKA "triplets" That was actually far more "binary" than our current approach. It could, for example, eliminate attribute names (the 'tag' becomes the name). >but the group had previously said NO to this approach (right?). Yet, I thought so. >If the desire is to have a TLV mechanism, then why are we reinventing >what has already been accomplished via ASN.1/BER? (This is precisely ASN.1/BER is a very complex encoding mechanism for TLV. I don't believe that a TLV or triplet approach necesitates ASN.1/BER or even that that would be the best choice. >The greater good of IPP rests with pervasive deployment of a reasonable >set of standard features. Anything that gets in the way of this simple I agree. For my part, it is an unfortunate reality that schedule is becoming a driving force. :( [re. the HP and MS stand] For the summary of MY position re. 'types' aka 'tags', see my first paragraph above. sdb | Sylvan Butler | sbutler@boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 |   Received: from cnri by ietf.org id aa19439; 11 Jul 97 18:19 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid SAA25387 for ; Fri, 11 Jul 1997 18:18:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA25461 for ; Fri, 11 Jul 1997 18:14:38 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 11 Jul 1997 18:11:23 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA25026 for ipp-outgoing; Fri, 11 Jul 1997 18:05:10 -0400 (EDT) From: Keith Carter To: ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: IPP> MOD - Proposal to remove ValidateJob in IPP 1.0 Message-Id: <5040300003005509000002L092*@MHS> Date: Fri, 11 Jul 1997 18:06:16 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org In the spirit of simplification, I propose we remove VaildateJob from IPP 1.0 because (1) GetAttributes is now a mandatory operation on a Printer (2) an application can use GetAttributes to obtain valid attributes and values for a Printer BEFORE submitting a job to the Printer (3) removing ValidateJob is one less operation to implement and test i.e. we remove a straw from the IPP camel's back (as someone stated in the email, these straws do add up). I'll be out of the office through July 23 so I will not be able to correspond on this matter until then. However, I'll pick up the consensus at that time and proceed from there. Have fun, Keith   Received: from cnri by ietf.org id aa20619; 11 Jul 97 19:25 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid TAA25530 for ; Fri, 11 Jul 1997 19:24:43 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA26189 for ; Fri, 11 Jul 1997 19:21:07 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 11 Jul 1997 19:17:57 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA25589 for ipp-outgoing; Fri, 11 Jul 1997 19:10:18 -0400 (EDT) Date: Fri, 11 Jul 1997 09:41:20 PDT From: "McIntyre2,Lloyd" Subject: IPP> RE: MOD - Printer resolutions To: Carl-Uno Manros , ipp@pwg.org Cc: "Cancio,Vivian" , "McIntyre2,Lloyd" Message-id: <2B5FC633813E657C2B5FC633813E657C#064#X-PA-PAHV-MS4.XN@SMF> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Posting-date: Fri, 11 Jul 1997 12:38:12 -0400 Priority: normal Hop-count: 3 Sender: ipp-owner@pwg.org Carl, Allow me to make some comments to your note below ---------- From: Carl-Uno Manros To: ipp@pwg.org Cc: Cancio,Vivian; McIntyre2,Lloyd Subject: MOD - Printer resolutions Date: Friday, July 11, 1997 10:57AM One of my home work assignments from Nashua was to try to find out about the resolutions used by fax machines. The simple answer in DPI is: res-100 (no mm equivalent) >this resolution will be approved in Oct 97 to be used in color transmissions only res-200x100 (note that x-resolution is higher than y-resolution) res-200 res-300 (no mm equivalent) res-400 However, this is only part of the truth. Most fax machines, as well as some printers, are natively based on lines/mm rather than DPI, which means that we also need to be able to express values in lines/mm if we want to be exact. Hence, we also need the following fax resolution values expressed in lines/mm: >not that the lines/mm resolutions are not square res-7.7x3.85 >this should be 8x3.85 res-7.7 >this should be 8x7.7 res-8x15.4 (no inch equivalent) res-15.4 >this should be 16x15.4 There are two possible ways of doing this, either by adding this in the attribute value for resolution, or by adding a separate attribute for the native measuring system of the fax/printer. In the first case we would end up with values like: res-200x100-inch and res-7.7x3.85-mm >this should be 8x3.85-mm In the second case we would skip the last part of the resolution value and instead have a new attribute called "printer-resolution-base" with the two values: "metric" and "inch". I suggest to use the second solution, which seems more extensible for the future and which would allow a client to quickly find out what the base is without having to read a potentially long list of resolution values. >the second solution is also consistent with the solution used in fax I would also encourage people in the WG that are working with metric based printers to come up with a list of the metric values that we would need to add for printers. Comments? Omissions? 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   Received: from cnri by ietf.org id aa03397; 12 Jul 97 6:28 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid GAA26218 for ; Sat, 12 Jul 1997 06:26:50 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id GAA27156 for ; Sat, 12 Jul 1997 06:23:11 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 12 Jul 1997 06:20:29 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id GAA26982 for jmp-outgoing; Sat, 12 Jul 1997 06:19:34 -0400 (EDT) Message-Id: <9707121019.AA05738@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: Sat, 12 Jul 1997 03:17:20 PDT To: Scott Isaacson From: Tom Hastings Subject: JMP> MOD - Editorial comments on Model Cc: ipp@pwg.org, jmp@pwg.org Sender: jmp-owner@pwg.org Scott, I edited with revisions ipp-model-970623-rev.doc (after accepting revisions) and put back in: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ -rw-r--r-- 1 pwg pwg 311296 Jul 12 10:09 ipp-model-970623-th.doc I've included the new enum data type and the enums values for the five attributes that we agreed to be enums instead of keywords and which aligns with the Job Monitoring MIB: "finishings" "print-quality" "printer-resolution" "job-state" "document-format" I also copied in the "job-state" and "job-state-reasons" that we agreed to jointly between the JMP and IPP. NOTE: that going back to Printer MIB document-format enums means that PDF needs to get registered. Would be nice to include PDF in the Printer MIB textual-conventions that is due this week. Tom   Received: from cnri by ietf.org id aa07695; 13 Jul 97 13:24 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA27448 for ; Sun, 13 Jul 1997 13:23:26 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA29903 for ; Sun, 13 Jul 1997 13:19:47 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sun, 13 Jul 1997 13:13:22 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA29447 for ipp-outgoing; Sun, 13 Jul 1997 13:07:06 -0400 (EDT) Message-Id: <1.5.4.32.19970713170602.00670b98@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: Sun, 13 Jul 1997 10:06:02 -0700 To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> MOD - Use of "enums" Sender: ipp-owner@pwg.org At 03:17 AM 7/12/97 PDT, Tom wrote: >Scott, > >I edited with revisions ipp-model-970623-rev.doc (after accepting revisions) > >and put back in: >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ >-rw-r--r-- 1 pwg pwg 311296 Jul 12 10:09 ipp-model-970623-th.doc > >I've included the new enum data type and the enums values for the >five attributes that we agreed to be enums instead of keywords >and which aligns with the Job Monitoring MIB: > > "finishings" > "print-quality" > "printer-resolution" > "job-state" > "document-format" > >I also copied in the "job-state" and "job-state-reasons" that we agreed >to jointly between the JMP and IPP. > >NOTE: that going back to Printer MIB document-format enums means that >PDF needs to get registered. Would be nice to include PDF in the >Printer MIB textual-conventions that is due this week. > >Tom > Tom, are we sure that we know what we are doing here? The recommended solution from Nashua to use "enums" where they were already defined in other standards sounded good at the time, but does the Job Monitoring MIB really fall into that category - YET? I do not want the progression of IPP to be dependent and possibly delayed by the Job Monitoring MIB project. Are we convincened that the Job Monitoring work will proceed with at least the same speeed as IPP? Carl-Uno   Received: from cnri by ietf.org id aa01669; 14 Jul 97 4:17 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid EAA28391 for ; Mon, 14 Jul 1997 04:16:09 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id EAA01301 for ; Mon, 14 Jul 1997 04:12:33 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 14 Jul 1997 04:08:08 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA00852 for ipp-outgoing; Mon, 14 Jul 1997 04:01:42 -0400 (EDT) Message-Id: <9707140801.AA06070@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, 14 Jul 1997 00:59:08 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> PRO - Updated "Mapping between LPD and IPP Protocols" Sender: ipp-owner@pwg.org I've posted updated "Mapping between LPD and IPP Protocols" in: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ -rw-r--r-- 1 pwg pwg 69396 Jul 14 07:54 lpd-ipp-rev-black.pdf -rw-r--r-- 1 pwg pwg 72163 Jul 14 07:53 lpd-ipp-rev-red.pdf -rw-r--r-- 1 pwg pwg 62976 Jul 14 07:51 lpd-ipp.doc -rw-r--r-- 1 pwg pwg 41862 Jul 14 07:52 lpd-ipp.pdf -rw-r--r-- 1 pwg pwg 22915 Jul 14 07:52 lpd-ipp.txt The changes includes Jay Martin's comments, results of the IPP telecon, 7/9, Norm Jacob's comments, and Bob Herriot's comments. Norm and Bob have included more detail for mapping in both directions. Bob asks if it should be a standards track for LPD to IPP and IPP to LPD gateways? There are a few more issues listed in the document. Norm and Bob indicate that they have more work to do, including mapping error codes.   Received: from cnri by ietf.org id aa01845; 14 Jul 97 4:32 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid EAA28415 for ; Mon, 14 Jul 1997 04:31:25 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id EAA01823 for ; Mon, 14 Jul 1997 04:27:49 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 14 Jul 1997 04:24:31 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA01389 for ipp-outgoing; Mon, 14 Jul 1997 04:18:14 -0400 (EDT) Message-Id: <9707140818.AA06083@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, 14 Jul 1997 01:15:45 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - New enum data type and attributes text Cc: Steve Zilles Sender: ipp-owner@pwg.org I've posted the subset of the IPP Model document that deals with the new enum data type and the 5 attributes that are changed from type keyword to type enum: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ -rw-r--r-- 1 pwg pwg 43520 Jul 14 08:07 ipp-enum.doc -rw-r--r-- 1 pwg pwg 45379 Jul 14 08:07 ipp-enum.pdf This makes it easier for PWG people to review just that part which is new concerning enums as agreed to at Nashua affecting these attributes: "finishings" "print-quality" "printer-resolution" "job-state" "document-format" Send any comments ASAP, as Scott is incorporating this into the Model document. Thanks, Tom >Date: Sat, 12 Jul 1997 03:17:20 -0700 >To: scott >From: Tom Hastings >Subject: MOD - Editorial comments on Model >Cc: ipp, jmp > >Scott, > >I edited with revisions ipp-model-970623-rev.doc (after accepting revisions) > >and put back in: >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ >-rw-r--r-- 1 pwg pwg 311296 Jul 12 10:09 ipp-model-970623-th.doc > >I've included the new enum data type and the enums values for the >five attributes that we agreed to be enums instead of keywords >and which aligns with the Job Monitoring MIB: > > "finishings" > "print-quality" > "printer-resolution" > "job-state" > "document-format" > >I also copied in the "job-state" and "job-state-reasons" that we agreed >to jointly between the JMP and IPP. > >NOTE: that going back to Printer MIB document-format enums means that >PDF needs to get registered. Would be nice to include PDF in the >Printer MIB textual-conventions that is due this week. > >Tom >   Received: from cnri by ietf.org id aa04283; 14 Jul 97 7:45 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid HAA28616 for ; Mon, 14 Jul 1997 07:44:35 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id HAA02496 for ; Mon, 14 Jul 1997 07:40:58 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 14 Jul 1997 07:34:24 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA02039 for ipp-outgoing; Mon, 14 Jul 1997 07:28:09 -0400 (EDT) From: Peter Zehler To: "Redirector IPP (E-mail)" Subject: IPP> PRO proposed tweak to protocol Date: Mon, 14 Jul 1997 04:30:21 PDT X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Message-Id: <97Jul14.042813pdt."52584(4)"@alpha.xerox.com> Sender: ipp-owner@pwg.org All, I do not have a strong argument against the tweak. I do not see a strong argument for the tweak. I see no problem implementing the protocol as agreed. My position is not to make the tweak. Pete __________________________________ Email: pzehler@channels.mc.xerox.com US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. Webster NY, 14580-9701 Voice: (716) 265-8755 FAX: (716)265-8792 __________________________________ "I always wanted to be somebody, but I should have been more specific." Lily Tomlin __________________________________   Received: from cnri by ietf.org id aa05804; 14 Jul 97 9:24 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid JAA29891 for ; Mon, 14 Jul 1997 09:23:23 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA03088 for ; Mon, 14 Jul 1997 09:19:46 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 14 Jul 1997 09:16:25 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA02638 for ipp-outgoing; Mon, 14 Jul 1997 09:10:08 -0400 (EDT) From: Roger K Debry To: ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: IPP>MOD - Globally unique IDs Message-Id: <5030100004728405000002L052*@MHS> Date: Mon, 14 Jul 1997 09:11:58 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org AN IBM person reviewing the model document made the following observation -- comments anyone? On page 20 Section 4.6, it says "... have an identifier attribute whose value is globally unique ..." I think we have to say how this is done, don't we? Roger deBry   Received: from cnri by ietf.org id aa08154; 14 Jul 97 10:43 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid KAA00226 for ; Mon, 14 Jul 1997 10:41:39 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA03658 for ; Mon, 14 Jul 1997 10:38:02 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 14 Jul 1997 10:28:44 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA03219 for ipp-outgoing; Mon, 14 Jul 1997 10:22:28 -0400 (EDT) Message-ID: <33C9C89E.5225@byas.com> Date: Mon, 14 Jul 1997 06:35:10 +0000 From: AlBrahme X-Mailer: Mozilla 3.0 (Win95; U) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> ipp & tiff References: <97Jul14.042813pdt."52584(4)"@alpha.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org The tiff format currently accepted by ipp is too broad in scope for fax server applications. ie it has provisions for jpeg etc which are too complicated for a simple ipp fax server. Instead we would like to use TIFF-F which is currently an ietf draft. I would like to know how an ipp server which can accept only a TIFF-F format can convey this capability information to an ipp client. thank you /al   Received: from cnri by ietf.org id aa08784; 14 Jul 97 11:07 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid LAA00306 for ; Mon, 14 Jul 1997 11:06:18 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA04184 for ; Mon, 14 Jul 1997 11:02:40 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 14 Jul 1997 10:59:12 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA03752 for ipp-outgoing; Mon, 14 Jul 1997 10:52:56 -0400 (EDT) Date: Mon, 14 Jul 1997 07:56:11 PDT From: Ira Mcdonald x10962 Message-Id: <9707141456.AA12017@snorkel.eso.mc.xerox.com> To: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP>MOD - Globally unique IDs Sender: ipp-owner@pwg.org Hi Roger, Good catch! The IETF Job Mon MIB has some attempts at 'reasonably unique' client job submission ID formats (which can also be supplied in any of the defined formats by a helpful agent who notices that no client job id was submitted with the job). Xerox has over three years experience with some additional 'really unique' client job submission ID formats in our private Job Mon MIB work (we needed them for active job management - when you toss missiles it's nice to hit the right job...) Nearly every protocol at an application layer says things about 'global unique IDs', but not many define how to generate them (including issues of character sets - IPP w/ UTF-8 may not have that problem). Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 "Outside of a dog, a book is a man's best friend... Inside of a dog, it's too dark to read" - Groucho Marx   Received: from cnri by ietf.org id aa13066; 14 Jul 97 13:33 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA00861 for ; Mon, 14 Jul 1997 13:32:21 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA04948 for ; Mon, 14 Jul 1997 13:28:44 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 14 Jul 1997 13:25:15 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA04474 for ipp-outgoing; Mon, 14 Jul 1997 13:18:52 -0400 (EDT) From: Roger K Debry To: ipp@pwg.org, cmanros@cp10.es.xerox.com MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: IPP> IPP_SEC - New ietf draft Message-Id: <5030100004741647000002L072*@MHS> Date: Mon, 14 Jul 1997 13:20:39 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org A new version of the ietf-draft security document has been posted to the pwg web site. This new version includes: - additional references - the Get-Operations operation - a new section on firewalls - a replacement section on recommended security features The section on details of various security mechanisms was removed. The document is at ftp://ftp.pwg.org/pub/pwg/ipp/new_SEC/draft-ietf-ipp-security-01.txt This is the version that I'd like to send to the ietf, so please comment in the next couple of days. Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080   Received: from cnri by ietf.org id aa13402; 14 Jul 97 13:47 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA00945 for ; Mon, 14 Jul 1997 13:46:11 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA05466 for ; Mon, 14 Jul 1997 13:42:34 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 14 Jul 1997 13:39:17 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA05018 for ipp-outgoing; Mon, 14 Jul 1997 13:32:55 -0400 (EDT) From: Roger K Debry To: ipp@pwg.org, Sisaacson@novell.com MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: IPP>MOD - editorial comment Message-Id: <5030100004742571000002L012*@MHS> Date: Mon, 14 Jul 1997 13:34:47 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Scott, One of the IBM people reviewing the model document had the following observation: The list of optional operations on lines 708-710 (The June 23 version) has Submit-Docment and Submit-URI. These should be Send-Docment and Send-URI. He also thought that section 5 would be easier to read if the detailed discussion of operations were organized by operations on the Printer Object followed by operations on the Job Object. Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080   Received: from cnri by ietf.org id aa13833; 14 Jul 97 14:04 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid OAA01040 for ; Mon, 14 Jul 1997 14:02:58 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA06027 for ; Mon, 14 Jul 1997 13:59:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 14 Jul 1997 13:56:00 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA05568 for ipp-outgoing; Mon, 14 Jul 1997 13:49:40 -0400 (EDT) Message-ID: <33CA6532.1FB78563@sharplabs.com> Date: Mon, 14 Jul 1997 10:43:17 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.01b6C [en] (X11; I; SunOS 4.1.4 sun4m) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> MOD - Proposal to remove ValidateJob in IPP 1.0 X-Priority: 3 (Normal) References: <5040300003005509000002L092*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Did anyone else have any comments related to Keith's proposal. If his two predicates he mentions are true, wouldn't it make sense to remove it? By the way, I too would like to see us progress to prototyping as fast as possible, curtailing as few new tweaks as possible. But this is a simplification, something that seeks to enhance and speed up the availability of prototypes. Randy Keith Carter wrote: > In the spirit of simplification, I propose we remove VaildateJob from > IPP 1.0 > because (1) GetAttributes is now a mandatory operation on a Printer > (2) an > application can use GetAttributes to obtain valid attributes and > values for a > Printer BEFORE submitting a job to the Printer (3) removing > ValidateJob is one > less operation to implement and test i.e. we remove a straw from the > IPP > camel's back (as someone stated in the email, these straws do add up). > > I'll be out of the office through July 23 so I will not be able to > correspond > on this matter until then. However, I'll pick up the consensus at > that time > and proceed from there. > > Have fun, > > Keith -- Randy Turner   Received: from cnri by ietf.org id aa14513; 14 Jul 97 14:29 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid OAA01209 for ; Mon, 14 Jul 1997 14:27:58 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA06338 for ; Mon, 14 Jul 1997 14:24:15 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 14 Jul 1997 14:20:54 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA06161 for jmp-outgoing; Mon, 14 Jul 1997 14:19:37 -0400 (EDT) Message-Id: <9707141819.AA06263@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, 14 Jul 1997 11:17:20 PDT To: ipp@pwg.org, jmp@pwg.org, Carl-Uno Manros From: Tom Hastings Subject: JMP> Re: IPP> MOD - Editorial comments on Model Cc: scott_isaacson@novell.com Sender: jmp-owner@pwg.org Carl-Uno, The Job Monitoring MIB is ahead of IPP, so your concern that one would hold up the other is not a problem. Furthermore, if there are additional values that are added to, say IPP, for printer resolution that didn't make Job Mon MIB, there is no problem. These are type 2 enums that can be added to anytime and have all the validity as if they were in the standard. Our plan is to complete the next JMP draft this week and that will be the one that we forward to IESG this month. I also want to make sure that IPP people are happy with making these 5 attribute values enums, instead of keywords. If any of them change back to keywords, then the Job Monitoring MIB would want to change them to be OCTET STRING, instead of Integer32 as well. So its important to both JMP and IPP to reach agreement on these five attributes and their data types. Tom At 09:23 07/13/97 PDT, Carl-Uno Manros wrote: >At 03:17 AM 7/12/97 PDT, you wrote: >>Scott, >> >>I edited with revisions ipp-model-970623-rev.doc (after accepting revisions) >> >>and put back in: >>ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ >>-rw-r--r-- 1 pwg pwg 311296 Jul 12 10:09 ipp-model-970623-th.doc >> >>I've included the new enum data type and the enums values for the >>five attributes that we agreed to be enums instead of keywords >>and which aligns with the Job Monitoring MIB: >> >> "finishings" >> "print-quality" >> "printer-resolution" >> "job-state" >> "document-format" >> >>I also copied in the "job-state" and "job-state-reasons" that we agreed >>to jointly between the JMP and IPP. >> >>NOTE: that going back to Printer MIB document-format enums means that >>PDF needs to get registered. Would be nice to include PDF in the >>Printer MIB textual-conventions that is due this week. >> >>Tom >> > >Tom, > >are we sure that we know what we are doing here? The recommended solution from >Nashua to use "enums" where they were already defined in other standards sounded >good at the time, but does the Job Monitoring MIB really fall into that category > - YET? > >I do not want the progression of IPP to be dependent and possibly delayed by the >Job Monitoring MIB project. Are we convincened that the Job Monitoring work >will >proceed with at least the same speeed as IPP? > >Carl-Uno > > > >   Received: from cnri by ietf.org id aa14906; 14 Jul 97 14:43 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid OAA01289 for ; Mon, 14 Jul 1997 14:41:54 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA07044 for ; Mon, 14 Jul 1997 14:38:15 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 14 Jul 1997 14:29:15 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA06140 for ipp-outgoing; Mon, 14 Jul 1997 14:17:02 -0400 (EDT) Date: Mon, 14 Jul 1997 11:15:26 PST From: David_Kellerman@nls.com To: ipp@pwg.org Message-ID: <009B73CF.B19A1F92.6@nls.com> Subject: Re: IPP> MOD - Proposal to remove ValidateJob in IPP 1.0 Sender: ipp-owner@pwg.org > From: Keith Carter > Date: Fri, 11 Jul 1997 18:06:16 -0400 > > In the spirit of simplification, I propose we remove VaildateJob from IPP 1.0 > because (1) GetAttributes is now a mandatory operation on a Printer (2) an > application can use GetAttributes to obtain valid attributes and values for a > Printer BEFORE submitting a job to the Printer (3) removing ValidateJob is one > less operation to implement and test i.e. we remove a straw from the IPP > camel's back (as someone stated in the email, these straws do add up). (I haven't been following all the details of the ValidateJob discussion, so if these comments are off-track, someone please nudge things back in line.) I thought one of the things missing from GetAttributes was the ability to check for constraints that might make a particular COMBINATION of attributes impossible for the printer to implement. The key issue here is that, just because a printer some set of data types, media types, some set of finishing options, etc., doesn't mean all the combinations are supported. ("Sorry, I can't print duplex on card stock or A3.") Real-world devices don't have nice orthogonal feature sets. So, I thought the idea was that you could use ValidateJob job to check for problems before shipping off all the document data. :: David Kellerman Northlake Software 503-228-3383 :: david_kellerman@nls.com Portland, Oregon fax 503-228-5662   Received: from cnri by ietf.org id aa15141; 14 Jul 97 14:52 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid OAA01311 for ; Mon, 14 Jul 1997 14:50:58 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA07854 for ; Mon, 14 Jul 1997 14:47:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 14 Jul 1997 14:44:08 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA06466 for ipp-outgoing; Mon, 14 Jul 1997 14:30:54 -0400 (EDT) Date: Mon, 14 Jul 1997 11:32:01 PDT Message-Id: <3.0.16.19970714112836.3c572f8a@cayuga> X-Sender: stanmcc@cayuga X-Mailer: Windows Eudora Pro Version 3.0 (16) To: Hastings@cp10.es.xerox.com, Carl-Uno Manros , ipp@pwg.org From: Stan McConnell Subject: Re: IPP> MOD - Use of "enums" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I question whether the enum data type is the best choice for "printer-resolution". It would seem better to leave these values as keywords, since that would make it easier to manage, debug, and introduce new values promptly. There doesn't appear to be a localization issue here. The only issue I see would be the case where inches must be converted to mm, e.g., for fax purposes; but the situation here is the same whether the "printer-resolution" datatype is an enum or a keyword. Stan . . . At 10:06 AM 7/13/97 PDT, Carl-Uno Manros wrote: >At 03:17 AM 7/12/97 PDT, Tom wrote: >>Scott, >> >>I edited with revisions ipp-model-970623-rev.doc (after accepting revisions) >> >>and put back in: >>ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ >>-rw-r--r-- 1 pwg pwg 311296 Jul 12 10:09 ipp-model-970623-th.doc >> >>I've included the new enum data type and the enums values for the >>five attributes that we agreed to be enums instead of keywords >>and which aligns with the Job Monitoring MIB: >> >> "finishings" >> "print-quality" >> "printer-resolution" >> "job-state" >> "document-format" >> >>I also copied in the "job-state" and "job-state-reasons" that we agreed >>to jointly between the JMP and IPP. >> >>NOTE: that going back to Printer MIB document-format enums means that >>PDF needs to get registered. Would be nice to include PDF in the >>Printer MIB textual-conventions that is due this week. >> >>Tom >> > >Tom, > >are we sure that we know what we are doing here? The recommended solution from >Nashua to use "enums" where they were already defined in other standards sounded >good at the time, but does the Job Monitoring MIB really fall into that category > - YET? > >I do not want the progression of IPP to be dependent and possibly delayed by the >Job Monitoring MIB project. Are we convincened that the Job Monitoring work >will >proceed with at least the same speeed as IPP? > >Carl-Uno > > > >   Received: from cnri by ietf.org id aa19143; 14 Jul 97 17:11 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA02267 for ; Mon, 14 Jul 1997 17:10:14 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA08866 for ; Mon, 14 Jul 1997 17:06:33 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 14 Jul 1997 17:02:33 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA08415 for ipp-outgoing; Mon, 14 Jul 1997 16:56:11 -0400 (EDT) Date: Mon, 14 Jul 1997 13:56:58 -0700 From: Robert Herriot Message-Id: <199707142056.NAA01971@woden.eng.sun.com> To: ipp@pwg.org, hastings@cp10.es.xerox.com Subject: Re: IPP> MOD - New enum data type and attributes text Cc: szilles@adobe.com X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org For the most part, I think that it is good that we have changed some keywords to enums so that we line up with other standards. I have a few observations. It is a bit strange that IPP aligns for job-state, but not for job-state-reason, printer-state or printer-state-reasons. It would seem better if printer-state and job-state had the same type, either both enums or both keywords. I am also concerned about printer-resolution. I don't see the advantage of abitrary keywords over a value that gives the resolution explictly, either the keyword string we had or a pair integers with units. Both of these solutions allow a client and server to understand the values without some middleman registry. Just my 2 cents. Bob Herriot   Received: from cnri by ietf.org id aa23557; 14 Jul 97 19:20 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid TAA02746 for ; Mon, 14 Jul 1997 19:19:20 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA09827 for ; Mon, 14 Jul 1997 19:15:40 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 14 Jul 1997 19:08:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA09340 for ipp-outgoing; Mon, 14 Jul 1997 19:02:21 -0400 (EDT) Message-Id: <9707142302.AA06443@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, 14 Jul 1997 15:59:58 PDT To: Robert Herriot From: Tom Hastings Subject: Re: IPP> MOD - New enum data type and attributes text Cc: ipp@pwg.org, szilles@adobe.com Sender: ipp-owner@pwg.org At 13:56 07/14/97 PDT, Robert Herriot wrote: > >For the most part, I think that it is good that we have changed >some keywords to enums so that we line up with other standards. > >I have a few observations. > >It is a bit strange that IPP aligns for job-state, but not for >job-state-reason, printer-state or printer-state-reasons. It would >seem better if printer-state and job-state had the same type, either >both enums or both keywords. I agree. Lets change printer-state from keyword to enum. NOTE: the Job Monitoring MIB doesn't have printer-state, so this is only an IPP issue (that is why I didn't think of proposing printer-state as an enum. NOTE: also making printer-state an enum doesn't follow the rationale that we use enums from other standards. But maybe this is just the "exception that makes the rule". NOTE: the Printer MIB printer state enum(s) are all messed up, so we don't want to use them for sure in IPP. > >I am also concerned about printer-resolution. I don't see the advantage >of abitrary keywords over a value that gives the resolution explictly, >either the keyword string we had or a pair integers with units. Both >of these solutions allow a client and server to understand the values >without some middleman registry. NOTE: with keyword values, we still want/need a middleman registry, but the advantage is that the actual value can be parsed. Also the value can be displayed without localization problems, since they are decimal digits. Another argument in favor of NOT using enums for printer-resolution is that there were some omissions in the values: 1. res400 was omitted (though 400x800 and 800x400 is included) 2. res200x100 was omitted (though 100x200 is included). 3. res1600 is used by scanners and should be added. Talking with Scott, we agreed to put them in IPP and Job Monitoring MIB together with the same values. Since neither have been published widely, we put them into the proper enum sequence. After this however, new values will go at the end. We also decided to leave a gap between the values that are the same in both dimensions and the ones that are different. So res100x200 will start at res100x200(100). On the other hand, do implementors have to have an enum table internally of legal values, since they can't parse out any arbitrary value, but only certain values? So the advantage of enums is that the discrete values are standardized. Software conversion from one to another resolution is done with pair-wise algorithms. We will leave it as an issue whether to go back to keywords for "printer-resolution" or leave them as enums in this Internet-Draft for IPP. If we can decide in time for IPP, we can fix the Job Monitoring MIB to be keyword or enum. Tom > >Just my 2 cents. > >Bob Herriot > > >   Received: from cnri by ietf.org id aa25909; 14 Jul 97 21:16 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid VAA02949 for ; Mon, 14 Jul 1997 21:15:29 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA10728 for ; Mon, 14 Jul 1997 21:11:50 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 14 Jul 1997 21:07:45 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA10290 for ipp-outgoing; Mon, 14 Jul 1997 21:01:24 -0400 (EDT) From: Stephen Zilles Message-Id: <199707150101.SAA00843@bulletin> To: ipp@pwg.org Subject: IPP> Rational for IPP Arch or "Why We Shot ourselves in the foot" Phone: (408) 536-4766 Fax: (408) 537-4042 Office: W14-504 Cc: szilles@adobe.com Date: Mon, 14 Jul 1997 18:01:10 PDT Sender: ipp-owner@pwg.org As promised, the first draft of a document describing the Rational for the structure of IPP and its documents is appended below. It is appended because (a) it is short and (b) I do not have upload capability from Adobe to the outside world at this particular moment. Comments, of course, are in order. It is written as an I-D, but could be put in another document as well. Steve INTERNET DRAFT Stephen N. Zilles Adobe Systems Inc. July 14, 1997 Expires: Jan 14, 1998 Rational for the Structure of the Model and Protocol for the Internet Printing Protocol 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. There are multiple parts to IPP, but the primary architectural components are the Model, the Protocol and an interface to Directory Services. This document provides a high level overview of the architecture and provides the rational for the decisions made in structuring the architecture. The full set of IPP documents include: 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 1. ARCHITECTURAL OVERVIEW The Internet Printing Protocol (IPP) is an application level protocol that can be used for distributed printing on the Internet. This protocol defines interactions between a client and a server. The client is provided the capability to inquire about capabilities of a printer, to submit print jobs and to inquire about and cancel print jobs. The server for these requests is the Printer; the Printer is an abstraction a generic document output device and/or a print service provider. Thus, the Printer could be a real printing device, such as a computer printer or fax output device, or it could be a service that interfaced with output devices. The architecture for IPP defines (in the Model document) an abstract Model for the data which is used to control the printing process and to provide information about the process and the capabilities of the Printer. This abstract Model is hierarchical in nature and reflects the structure of the Printer and the Jobs that may be being processed by the Printer. The Internet provides a channel between the client and the server/Printer. Use of this channel requires flattening and sequencing the hierarchical Model data. Therefore, the IPP also defines (in the Protocol document) an encoding of the data in the model for transfer between the client and server. This transfer of data may be either a request or the response to a request. Finally, the IPP defines (in the Protocol document) a protocol for transfering the encoded request and response data between the client and the server/Printer. An example of a typical interaction would by a request from the client to create a print job. The client would assemble the Model data to be associated with that job, such as the name of the job, the media to use, the number of pages to place on each media instance, etc. This data would then be encoded according to the Protocol and would be transmitted according to the Protocol. The server/Printer would receive the encoded Model data, decode it into a form understood by the server/Printer and, based on that data, do one of two things: (1) accept the job or (2) reject the job. In either case, the server must construct a response in terms of the Model data, encode that response according to the Protocol and transmit that encoded Model data as the response to the request using the Protocol. Another part of the IPP architecture is the Directory Schema. The role of the Directory Schema is to provide a standard set of attributes which might be used to query a directory service for the URI of a Printer that is likely to meet the needs of the client. The IPP architecture also addresses security issues such as control of access to server/Printers and secure transmissions of requests, response and the data to be printed. 2. THE PRINTER Because the (abstract) server/Printer encompasses a wide range of implementations, it is necessary to make some assumptions about a minimal implementation. The most likely minimal implementation is one that is embedded in an output device running a specialized real time operating system and with limited processing, memory and storage capabilities. This Printer will be connected to the Internet and will have at least a TCP/IP capability with (likely) SNMP support for the Internet connection. In addition, it is likely the the Printer will be an HTML/HTTP server to allow direct user access to information about the printer. 3. RATIONAL FOR THE MODEL The Model is defined independently of any encoding of the Model data both to support the likely uses of IPP and to be robust with respect to the possibility of alternate encodings. It is expected that a client or server/Printer would represent the Model data in some data structure within the applications/servers that support IPP. Therefore, the Model was designed to make that representation straightforward. Typically, a parser or formatter would be used to convert from or to the encoded data format. Once in an internal form suitable to a product, the data can be manipulated by the product. For example, the data sent with a Print Job can be used to control the processing of that Print Job. The semantics of IPP are attached to the (abstract) Model. Therefore, the application/server is not dependent on the encoding of the Model data, and it is possible to consider alternative mechanisms and formats by which the data could be transmitted from a client to a server; for example, a server could have a direct, client-less GUI interface that might be used to accept some kinds of Print Jobs. This independence would also allow a different encoding and/or transmission mechanism to be used if the ones adopted here were shown to be overly limiting in the future. Such a change could be migrated into new products as an alternate protocol stack/parser for the Model data. Having an abstract Model also allow the Model data to be aligned with the (abstract) model used in the Printer, Job and Host Resources MIBs. This provides consistency in interpretation of the data obtained independently of how the data is accessed, whether via IPP or via SNMP and the Printer/Job MIBs. 4. RATIONAL FOR THE PROTOCOL There are two parts to the Protocol: (1) the encoding of the Model data and (2) the mechanism for transmitting the model data between client and server. 4.1 The Encoding To make it simpler to develop embedded printers, a very simple binary encoding has been chosen. This encoding is adequate to represent the kinds of data that occur within the Model. It has a simple structure consisting of name value pairs in which the names are length specified strings constrained to characters from a subset of ASCII and the values are either scalars or a sequence of scalars. Each scalar value has a length specification. A fully encoded request/response has a version number, an operation (for a request) or a status (for a response), associated parameters which are encoded Model data and, optionally, print data following the Model data. [ISSUE: what should be said about Parameters and Attributes] 4.2 The Transmission Mechanism The chosen mechanism for transmitting the encoded Model data is HTTP 1.1 Post (and associated response). No modifications to HTTP 1.1 are proposed or required. The sole role of the Transmission Mechanism is to provide a transfer of encoded Model data from/to the client to/from the server. This could be done using any data delivery mechanism. The key reasons why HTTP 1.1 Post is used are: 1. HTTP 1.0 is already widely deployed and, based on the recent evidence, HTTP 1.1 will be widely deployed as the manufactures release new products. The performance benefits of HTTP 1.1 have been shown and manufactures are reacting postively. Wide deployment has meant that many of the problems of making a protocol work in a wide range of environments from local net to intranet to internet have been solved and will stay solved with HTTP 1.1 deployment. 2. HTTP 1.1 solves most of the problems that might have required a new protocol to be developed. HTTP 1.1 allows persistent connections that make a multi-message protocol be more efficient; for example it is practical to have a separate CreatJob and SendJob messages. Chunking allows the transmission of large print files without having to prescan the file to determine the file length. The accept headers allow the client's protocol and localization desires to be transmitted with the IPP operations and data. The HTTP redirect response allows a client to be informed when a Job he is interested in is moved to another server/Printer for any reason. 3. Most network Printers will be implementing HTTP servers for reasons other than IPP. These network attached Printers want to provide information on how to use the printer, its current state, etc. in HTML. This requires having an HTTP server which would be available to do IPP functions as well. 4. Most of the complexity of HTTP 1.1 is concerned with the implementation of proxies and not the implementation of clients and/or servers. Work is proceding in the HTTP Working Group to help identify what must be done by a server. As the Protocol document shows, that is not very much. 5. An HTTP based solution fits will with the Internet security mechanism that are currently deployed or being deployed. HTTP will run over SSL/TLS. The digest authentication mechanism of HTTP 1.1 provides an adequate level of access control (at least for intranet usage). These solutions are deployed and in practical use; a new solution would require extensive use to have the same degree of confidence in its security. 5. RATIONAL FOR THE DIRECTORY SCHEMA Successful use of IPP depends on the client finding a suitable IPP enabled Printer to which to send a IPP requests, such as print a job. This task is simplified if there is a Directory Service which can be queried for a suitable Printer. The purpose of the Directory Schema is to have a standard description of Printer attributes that can be associated the the URI for the printer. These attributes are a subset of the Model attributes and can be encoded in the appropriate query syntax for the Directory Service being used by the client. 6. RATIONAL FOR SECURITY Security is an areas of active work on the Internet. Complete solutions to a wide range of security concerns are not yet available. Therefore, in the design of IPP, the focus has been on identifying a set of security protocols/features that are implemented (or currently implementable) and solve real problems with distributed printing. The two areas that seem appropriate to support are: (1) authorization to use a Printer and (2) secure interaction with a printer. The chosen mechanisms are the digest authentication mechanism of HTTP 1.1 and the SSL/TLS secure communication mechanism, which also includes authorization. 7. REFERENCES TBD... 8. AUTHORS ADDRESS Stephen Zilles Adobe Systems Incorporated 345 Park Avenue MailStop W14 San Jose, CA 95110-2704 Phone: +1 408 536-4766 Fax: +1 408 537-4042 Email: szilles@adobe.com   Received: from cnri by ietf.org id aa05172; 14 Jul 97 23:55 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid XAA03152 for ; Mon, 14 Jul 1997 23:54:25 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA11861 for ; Mon, 14 Jul 1997 23:50:44 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 14 Jul 1997 23:43:09 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA10897 for ipp-outgoing; Mon, 14 Jul 1997 23:31:39 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 14 Jul 1997 21:23:08 -0600 From: Scott Isaacson To: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP>MOD - Globally unique IDs Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Roger, Since these "globally unique identifiers" are really just URIs, I changed the document to get rid of the term "globally unique" and just explicitly state that the object's identifier is a URI. Therefore we are only as "globally unique" as URIs are and we don't have to say how or why, we let the URI people worry about that. Scott >>> Roger K Debry 07/14 7:11 AM >>> AN IBM person reviewing the model document made the following observation -- comments anyone? On page 20 Section 4.6, it says "... have an identifier attribute whose value is globally unique ..." I think we have to say how this is done, don't we? Roger deBry   Received: from cnri by ietf.org id aa05181; 14 Jul 97 23:55 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid XAA03155 for ; Mon, 14 Jul 1997 23:54:41 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA11884 for ; Mon, 14 Jul 1997 23:51:00 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 14 Jul 1997 23:43:40 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA10886 for ipp-outgoing; Mon, 14 Jul 1997 23:31:13 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 14 Jul 1997 21:17:07 -0600 From: Scott Isaacson To: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP>MOD - editorial comment Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Roger, I have fixed the typo. As far as reordering goes, I have not changed that. I reread the operations in the given order and personally felt that it "flows". (however I am sure that I am biased). Since "Create-Job" and the "Sends" (Send-Document and Sent-URI) go together I wouldn't want to break them up. Also I have fixed up Get-Attributes so that is is more segemented between Printer and Job (more than it was). So to reorder these, I'll need just a little more convincing. Thanks for the input. Scott >>> Roger K Debry 07/14 11:34 AM >>> Scott, One of the IBM people reviewing the model document had the following observation: The list of optional operations on lines 708-710 (The June 23 version) has Submit-Docment and Submit-URI. These should be Send-Docment and Send-URI. He also thought that section 5 would be easier to read if the detailed discussion of operations were organized by operations on the Printer Object followed by operations on the Job Object. Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080   Received: from cnri by ietf.org id aa05367; 15 Jul 97 0:04 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid AAA03168 for ; Tue, 15 Jul 1997 00:03:20 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA12437 for ; Mon, 14 Jul 1997 23:59:41 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 14 Jul 1997 23:56:30 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA11427 for ipp-outgoing; Mon, 14 Jul 1997 23:46:37 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 14 Jul 1997 21:45:55 -0600 From: Scott Isaacson To: ipp@pwg.org Cc: szilles@adobe.com Subject: Re: IPP> Rational for IPP Arch or "Why We Shot ourselves in the foot" Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Great job Steve! The way that it is written (covering Security, Model, Directory, and Protocol) makes me think that it is most definitely a stand alone document. If you had only done section 4 I would see that being wrapped into the Protocol document. It looks like a great FYI RFC. As per your request about attributes and parameters: You wrote: ----------------------- A fully encoded request/response has a version number, an operation (for a request) or a status (for a response), associated parameters which are encoded Model data and, optionally, print data following the Model data. [ISSUE: what should be said about Parameters and Attributes] ----------------------- I would change it to: ----------------------- A fully encoded request/response has a version number, an operation (for a request) or a status (for a response), an optional staus message, associated parameters which are encoded Model data (and, optionally), print data following the Model data. The operation requests contain input parameters and the responses contain output parameters. Some of the operation parameters contain sets if attributes and their values. ----------------------- I might have other comments later, but it looks great after a first cursory read. 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 ************************************************************   Received: from cnri by ietf.org id aa08851; 15 Jul 97 2:38 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid CAA03337 for ; Tue, 15 Jul 1997 02:36:53 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA13504 for ; Tue, 15 Jul 1997 02:33:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 15 Jul 1997 02:25:54 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA12887 for ipp-outgoing; Tue, 15 Jul 1997 02:16:31 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 15 Jul 1997 00:16:06 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - new model document Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org I have posted a new version of the model document: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970714-ms60.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970714-rev-ms60.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970714-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970714.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970714.txt ipp-model-970714-ms60.doc - A MS Word 6.0 doc with no revision marks ipp-model-970714-rev-ms60.doc - A MS Word 6.0 doc with revision marks ipp-model-970714-rev.pdf - A PDF line numbers and with revision marks ipp-model-970714.pdf - A PDF line numbers and with no revision marks ipp-model-970714.txt - A txt file with no line numbers (same as draft-ietf-ipp-model-03.txt) I have also sumbitted text file to the IETF as a new I-D: draft-ietf-ipp-model-03.txt I posted this at: ftp://ftp.pwg.org/pub/pwg/ipp/drafts/draft-ietf-ipp-model-03.txt I hope to make one more set of changes an issue a new I-D (draft-ietf-ipp-model-04.txt) before the 7/30 cutoff date. So, please review as quickly as possible. I might set up one more model telecon to review and collect comments if you think that might be useful. There are only about 5 issues left in the document. Major changes: 1. Removed Intro section 2. Moved terminology to the end (so that the reader gets to the meat of the document sooner) 3. Fixed all issues closed at June meeting (see Don W 6/25-26 notes) 4. Synchronized with post July 8 Protocol Spec 5. Added IANA registration section 6. Many wordsmithing edit changes 7. Added Roger d.'s propsed security attributes 8. Cleaned up status code and status message section 9. Added "pdl-override" and changed "best-effort" 10. Cleaned up language on "supported" and "parameters" 11. Cleaned up many "SHALLS" - still need to do more 12. Added keywords for operation parameters 13. Added reference to 1035 (DNS names and how to make private extensions) 14. Added language on querying Document Attributes (returns muti-valued attributes - one value for each document) 15. Added "enum" syntax type and changed finishings, printer-resolution, print-quality, printer-state, job-state, document format from keyword to enum 16. Finally added job-state and job-state-reasons that lines up withJMP ************************************************************ 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 ************************************************************   Received: from cnri by ietf.org id aa09018; 15 Jul 97 2:40 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid CAA03340 for ; Tue, 15 Jul 1997 02:39:38 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA13886 for ; Tue, 15 Jul 1997 02:35:59 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 15 Jul 1997 02:31:20 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA12923 for ipp-outgoing; Tue, 15 Jul 1997 02:20:40 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 15 Jul 1997 00:20:38 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - oops on new section 5.3.2 Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org I just noticed that I forgot to update the MANDATORY and OPTIONAL set of operations in the conformance section on operations. We all remember that they should be: ************* For a Printer object: Get-Operations (section 3.1.1) MANDATORY Print-Job (section 3.1.2) MANDATORY Print-URI (section 3.1.3) OPTIONAL Validate-Job (section 3.1.4) MANDATORY Create-Job (section 3.1.5) OPTIONAL Get-Jobs (section 3.1.8) MANDATORY Get-Attributes (section 3.1.9) MANDATORY For a Job object: Send-Document (section 3.1.6) OPTIONAL Send-URI (section 3.1.7) OPTIONAL Cancel-Job (section 3.1.8) MANDATORY Get-Attributes (section 3.1.9) MANDATORY ************************************************************ 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 ************************************************************   Received: from cnri by ietf.org id aa11781; 15 Jul 97 12:08 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid MAA04632 for ; Tue, 15 Jul 1997 12:07:20 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA15109 for ; Tue, 15 Jul 1997 12:03:43 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 15 Jul 1997 11:52:43 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA14638 for ipp-outgoing; Tue, 15 Jul 1997 11:46:19 -0400 (EDT) Mime-Version: 1.0 Date: Tue, 15 Jul 1997 11:39:53 -0400 Message-ID: <0001843B.3036@okidata.com> From: Philip Thambidurai Subject: IPP> Cancel Job operation 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 RE: The CancelJob operation, what was the basis for deciding to allow ONLY the job-originator to cancel? what if someone who is travelling submits a large job that is not printable for some reason and must be deleted in mid-job. Does IPP assume that there will be some other mechanism for canceling the job (by an administrator or operator)? Does IPP preclude vendor-specific operations on the Printer object (say for management)? I'm sure you have considered these issues before. Please bear with me!! Regards Philip Thambidurai Okidata   Received: from cnri by ietf.org id aa11943; 15 Jul 97 12:12 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid MAA04648 for ; Tue, 15 Jul 1997 12:11:14 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA15611 for ; Tue, 15 Jul 1997 12:07:37 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 15 Jul 1997 12:03:47 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA14838 for ipp-outgoing; Tue, 15 Jul 1997 11:55:39 -0400 (EDT) Mime-Version: 1.0 Date: Tue, 15 Jul 1997 09:02:36 -0400 Message-ID: <00018397.3036@okidata.com> From: Philip Thambidurai Subject: IPP> Firewalls and IPP 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 I would appreciate some comment on exactly how IPP will address issues that are likely to be raised by those who administer firewalls and such. If this has already been discussed before and settled, please so indicate (I can read the archives). Specifically: a) Does every "IPP printer" have to be made known to the firewall(s)? In a large company printers might be scatterred at various levels of the organization. It could be a headache for firewall admins. Or does the firewall only have to know about an IPP service (or protocol)? b) I did see (in the archives) that there was some discussion about a well-known-port for IPP. From a firewall admin perspective it might make sense to apply for a new port (although the protocol is http which uses 80 by default, mostly). It would be a LOT easier to set firewall policies/rules for IPP based on the port number. Such a port number might also make it simpler to go through an "IPP security proxy" --- all traffic into this port could be directed to the proxy. Packet-filtering firewalls (or routers) commonly make their decisions based on the port number. An application-level firewall (proxy) would be needed to distinguish between http intended for a web server and http intended for an ipp printer. The security policies for a typical web server and an ipp printer would normally be very different. For instance, many companies will not allow web access to machines "deep" in the organization. Machines that can be accessed from the web are usually "partioned" off in terms of security mechanisms from the rest of the systems/networks. c) How would we handle the case where a (small) business has only a PPP link to the Internet via some ISP. The web hosting is provided by the ISP and resides at the ISP's site. How exactly would a job be received in the IPP printer at this business? We could assume that the link is always up. This appears to place some requirement on the part of the ISP --- to route some of the http traffic (which contains IPP) to the client (business) site. Regards Philip Thambidurai Okidata   Received: from cnri by ietf.org id aa13136; 15 Jul 97 13:09 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA04858 for ; Tue, 15 Jul 1997 13:08:38 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA16239 for ; Tue, 15 Jul 1997 13:05:01 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 15 Jul 1997 12:59:00 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA15760 for ipp-outgoing; Tue, 15 Jul 1997 12:52:35 -0400 (EDT) Message-ID: From: Sylvan Butler X-Real-Sender: SYLVAN Organization: Hewlett-Packard, Boise To: ipp@pwg.org Date: Tue, 15 Jul 1997 10:52:09 -0700 Subject: Re: IPP> Firewalls and IPP CC: Philip Thambidurai Priority: normal X-mailer: Pegasus Mail v3.41 (preview) Sender: ipp-owner@pwg.org > a) Does every "IPP printer" have to be made known to the firewall(s)? I move we do not spend much time trying to address inbound (thru the firewall) issues. It is a very complex problem and companies and firewall vendors will all want to approach it differently. My approach would be either no internal printers visible to outside, or a special IPP relay outside the firewall that would appear to be the printer outside and either store and forward or actually talk to the printer in realtime on the inside. > b) I did see (in the archives) that there was some discussion about > decisions based on the port number. An application-level firewall > (proxy) would be needed to distinguish between http intended for a > web server and http intended for an ipp printer. The security Not necessarily. The URL and hence server for IPP could (should?) be entirely seperate from the normal web server the company uses for their "home page". > c) How would we handle the case where a (small) business has only a > PPP link to the Internet via some ISP. The web hosting is provided > by the ISP and resides at the ISP's site. How exactly would a job > be received in the IPP printer at this business? We could assume > that the link is always up. This appears to place some requirement > on the part of the ISP --- to route some of the http traffic > (which contains IPP) to the client (business) site. This is very interesting. If the link is up all the time then the printer (or print server) could have a URL of its own. Whomever is trying to print to that printer would be using the printer URL and not the general ISP URL. Sure, it may be an IP address if the printer doesn't appear in the DNS namespace, but that works fine. Another approach (which doesn't require a dedicated link) would be similar to that used by e-mail today. The ISP could receive and store print jobs for the small company and the company would connect periodically and suck down the jobs. sdb | Sylvan Butler | sbutler@boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 |   Received: from cnri by ietf.org id aa13284; 15 Jul 97 13:16 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA04920 for ; Tue, 15 Jul 1997 13:15:42 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA16731 for ; Tue, 15 Jul 1997 13:12:05 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 15 Jul 1997 13:08:56 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA15912 for ipp-outgoing; Tue, 15 Jul 1997 13:00:16 -0400 (EDT) Date: Tue, 15 Jul 1997 12:56:02 -0400 (EDT) From: JK Martin Message-Id: <199707151656.MAA25111@uscore.underscore.com> To: hastings@cp10.es.xerox.com Subject: Re: IPP> PRO - Updated "Mapping between LPD and IPP Protocols" Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Tom, I'm still reviewing the latest draft, but here are a few comments I'd like to submit now: > Bob asks if it should be a standards track for LPD to IPP and IPP to LPD > gateways? My opinion is "No", let's not start a standards track for such gateways. IMHO, there is not enough value here to incur the administrative effort. However, if others feel differently, then go for it. > There are a few more issues listed in the document. Given the nature of these issues, it might be best to extract them and post the list to the DL, particularly since some of these "issues" refer to IPP, rather than the mapping between LPD and IPP; for example, the issue on line 268: ISSUE: is IPP defined at this point to abort a job whose connection is closed before the job hass been fully received. If so, that is an alternate and simpler way to abort the job. This sounds like an IPP-only kind of issue, and not a mapping issue, right? Other comments: Line 101: "In LPD, this comment..." should be "In LPD, this command..." Line 251: "There are some major issues about setting the agent" Say what? Not sure what you mean here. Line 298: "...we need to map the LPD query format to IPP attributes." What is meant by the "LPD query format"? In LPD, the client asks for either the "short" or the "long" version of a query; no further granularity is available, right? I think all the LPD syntax stuff in the document is confusing (at best) and adds little to the overall value of the document. The syntax is described in a different form than that of RFC 1179 (which has no form, actually). All that is needed in this mapping document are references to the appropriate terms and section numbers of RFC 1179; it should be more than sufficient to assume the reader has knowledge of RFC 1179, and that this mapping document should not "spoon-feed" the reader. By the way, in the "Authors" section, you don't have all of the usual info listed for me. Please see my standard signature block below to fill in the blanks. Also, Norm Jacobs is not listed in the set of authors in the document footer. ...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 -- ----------------------------------------------------------------------   Received: from cnri by ietf.org id aa15446; 15 Jul 97 14:35 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid OAA05237 for ; Tue, 15 Jul 1997 14:33:47 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA17339 for ; Tue, 15 Jul 1997 14:30:10 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 15 Jul 1997 14:26:24 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA16892 for ipp-outgoing; Tue, 15 Jul 1997 14:20:01 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 15 Jul 1997 12:19:45 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - blind rev of the model documet Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org In order to fix my MANDATORY/OPTIONAL typo and at the request of Carl-Uno, I did a blind rev of the the following: drafts/draft-ietf-ipp-model-03.txt new_MOD/ipp-model-970714.pdf new_MOD/ipp-model-970714-rev.pdf new_MOD/ipp-model-970714.txt That is, I posted new files of the same name with the same version number that had the fix. Sorry for the confusion. I also tried to catch the one I sent to the IETF. I hope they post the new one, not the old one. Scott   Received: from cnri by ietf.org id aa16099; 15 Jul 97 15:01 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid PAA05337 for ; Tue, 15 Jul 1997 15:00:00 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA17857 for ; Tue, 15 Jul 1997 14:56:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 15 Jul 1997 14:53:15 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA17419 for ipp-outgoing; Tue, 15 Jul 1997 14:46:52 -0400 (EDT) Date: Tue, 15 Jul 1997 11:43:23 -0700 From: Robert Herriot Message-Id: <199707151843.LAA02943@woden.eng.sun.com> To: hastings@cp10.es.xerox.com, jkm@underscore.com Subject: Re: IPP> PRO - Updated "Mapping between LPD and IPP Protocols" Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > From jkm@underscore.com Tue Jul 15 10:11:10 1997 > Line 298: "...we need to map the LPD query format to IPP attributes." > What is meant by the "LPD query format"? In LPD, the client asks for > either the "short" or the "long" version of a query; no further > granularity is available, right? > > > I think all the LPD syntax stuff in the document is confusing (at best) > and adds little to the overall value of the document. The syntax is > described in a different form than that of RFC 1179 (which has no form, > actually). All that is needed in this mapping document are references > to the appropriate terms and section numbers of RFC 1179; it should be > more than sufficient to assume the reader has knowledge of RFC 1179, > and that this mapping document should not "spoon-feed" the reader. I was referring to the format of the long and short response which PSIS but not RFC 1179 specifies.   Received: from cnri by ietf.org id aa16527; 15 Jul 97 15:23 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid PAA05436 for ; Tue, 15 Jul 1997 15:21:59 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA18411 for ; Tue, 15 Jul 1997 15:18:22 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 15 Jul 1997 15:12:09 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA17953 for ipp-outgoing; Tue, 15 Jul 1997 15:05:46 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 15 Jul 1997 13:05:26 -0600 From: Scott Isaacson To: xriley@cp10.es.xerox.com, ipp@pwg.org Subject: Re: IPP> MOD - Questions on IPP Model and Protocol Document (model-issues-970623.pdf) Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Xavier, My responses are below prefixed by SAI>. Scott >>> "Xavier D. Riley" 07/08 8:12 AM >>> 319 2.2.2 Parameters 323 attributes, some do not. All parameters are defined in section 5. XDR> Its not clear to me what are "parameters" in section 5. There are XDR> not explicitly identified. The protocol document mentions XDR> "parameter groups" which are not mentioned in the Model document. SAI> The newest 970714 version of the model document does a better SAI> job of defining parameters. Operation request include input parameters SAI> and operation responses include output parameters. SAI> In the 970623 document parameters were introduced in section 2.2.2 723 5.1.2.1 Print Job Request XDR> It is stated that the "document-name" is MANDATORY. Line 735 states XDR> that the simplest Print-Job request consists of just the Document XDR> Content and nothing else. Is this a conflict? SAI> This is a conflict, we will have to resolve it. 974 5.1.8 Cancel Job Operation XDR> It is stated that only the job originator can cancel the job. How much XDR> credibility are you placing in the validity of the XDR> "job-originating-user" value. This validity should be tied into the XDR> different security methods used and the differences should be stated. XDR> In order to truly accomplish this, the user has to be authenticated, XDR> which leads you down the path to talking about security issues. Question, XDR> should this be moved to the IPP Security document? SAI> I am hoping the latest version of the security document should help to SAI> answer this. We are assuming that "job-orginating-user" is set by the SAI> system after authentication through the security protocols happen SAI> This is not settable by the end user. 1043 "The requested attributes of the object with their current valuesSHALL" XDR> I'm not sure you meant to have "SHALL" at the end of this sentence. SAI> This typo has been fixed 1051 A Printer MAY be configured, for security reasons, not to return all attributes that a client requests. It may 1052 even return none of the requested attributes. In such cases, the status returned is the same as if the Printer 1053 had returned all requested attributes. The client cannot tell by such a response whether the requested 1054 attribute was present or absent on the Printer. XDR> What is the rationale behind this policy of not XDR> guaranteeing a return? It would be nice to guarantee this XDR> return so the client could dynamically build the UI querying XDR> for all of the supported attributed on a printer. SAI> We guarantee a return (a response from the operation) but in a ultra SAI> secure environment we must allow for the fact that just returning SAI> the fact that a job exists might be revealing too much information. SAI> In most (many, all?) of the environements, all requested attributes will SAI> be returned. 1068 4. If the client supplies an attribute group keyword that is not unsupported, ... XDR> Did you really mean to use "not unsupported" ? SAI> This typo has been fixed. 1248 ... the "printer-job-template" group in order to get the XDR> Should "printer-job-template" be printer "job-template" ? SAI> This typo has been fixed.   Received: from cnri by ietf.org id aa16781; 15 Jul 97 15:36 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid PAA05489 for ; Tue, 15 Jul 1997 15:34:39 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA18964 for ; Tue, 15 Jul 1997 15:30:58 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 15 Jul 1997 15:24:28 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA18024 for ipp-outgoing; Tue, 15 Jul 1997 15:12:36 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 15 Jul 1997 13:12:07 -0600 From: Scott Isaacson To: albrahme@byas.com, ipp@pwg.org Subject: Re: IPP> ipp & tiff Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org When you say "The tiff format currently accepted by ipp is too broad" do you mean that one of the enums for the "document-format" attribute is " 'langTIFF': 40 - Tagged Image File Format (Aldus)"?? If so, please propose a new enum value and describe it (provide its semantics) and I am sure that it can be added to the list in the Printer MIB as well as the list in IPP since they are supposed to be the same list!! Once you do that, then an instance of an IPP Printer could implement the "document-formats-supported" attribute and set the value to this new value that you propose which is in the standard. This is how an "an ipp server which can accept only a TIFF-F format can convey this capability information to an ipp client." Scott >>> AlBrahme 07/14 12:35 AM >>> The tiff format currently accepted by ipp is too broad in scope for fax server applications. ie it has provisions for jpeg etc which are too complicated for a simple ipp fax server. Instead we would like to use TIFF-F which is currently an ietf draft. I would like to know how an ipp server which can accept only a TIFF-F format can convey this capability information to an ipp client. thank you /al   Received: from cnri by ietf.org id aa16856; 15 Jul 97 15:41 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid PAA05525 for ; Tue, 15 Jul 1997 15:40:00 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA19524 for ; Tue, 15 Jul 1997 15:36:22 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 15 Jul 1997 15:31:19 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA18494 for ipp-outgoing; Tue, 15 Jul 1997 15:19:46 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 15 Jul 1997 13:19:15 -0600 From: Scott Isaacson To: pthambid@okidata.com, ipp@pwg.org Subject: Re: IPP> Cancel Job operation Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Philip, One of the first discussion items for the scope of IPP included whether or not to include "operator", "manager", or "administrator" operations and semantics along with "end user" operations and semantics. The consensus within the first few days of dicssion was that IPP/1.0 only includes end user operations and semantics. >>> Philip Thambidurai 07/15 9:39 AM >>> > Does IPP preclude vendor-specific operations on the Printer object > (say for management)? SAI> No. There definitly is allow some administrative or SAI> operator interface to do this. SAI> SAI> Since IPP does introduce a cancel operation, a site could implement SAI> a policy that allowed authenticated operators rights to cancel all jobs SAI> We might have to change this statement in the model document to show SAI> what a reasonable policy might be and not try to force a policy in the SAI> standard itsef.   Received: from cnri by ietf.org id aa16992; 15 Jul 97 15:49 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid PAA05558 for ; Tue, 15 Jul 1997 15:48:39 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA20050 for ; Tue, 15 Jul 1997 15:45:02 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 15 Jul 1997 15:41:53 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA19309 for ipp-outgoing; Tue, 15 Jul 1997 15:33:44 -0400 (EDT) Date: Tue, 15 Jul 1997 15:32:41 -0400 (EDT) From: JK Martin Message-Id: <199707151932.PAA07234@uscore.underscore.com> To: Robert.Herriot@eng.sun.com Subject: Re: IPP> PRO - Updated "Mapping between LPD and IPP Protocols" Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I think we'd better be careful to scope the mapping document to *only* LPD (RFC 1179), rather than expanding it to cover PSIS, or even just parts of PSIS. If we need a mapping document between PSIS and IPP, then we should write one as needed. By the way, hasn't PSIS pretty much passed into relative oblivion? Also, you included my comments about removing the LPD syntax stuff from the mapping document. Do you agree or disagree (or don't care)? ...jay ----- Begin Included Message ----- From ipp-owner@pwg.org Tue Jul 15 14:54 EDT 1997 Date: Tue, 15 Jul 1997 11:43:23 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) To: hastings@cp10.es.xerox.com, jkm@underscore.com Subject: Re: IPP> PRO - Updated "Mapping between LPD and IPP Protocols" Cc: ipp@pwg.org > From jkm@underscore.com Tue Jul 15 10:11:10 1997 > Line 298: "...we need to map the LPD query format to IPP attributes." > What is meant by the "LPD query format"? In LPD, the client asks for > either the "short" or the "long" version of a query; no further > granularity is available, right? > > > I think all the LPD syntax stuff in the document is confusing (at best) > and adds little to the overall value of the document. The syntax is > described in a different form than that of RFC 1179 (which has no form, > actually). All that is needed in this mapping document are references > to the appropriate terms and section numbers of RFC 1179; it should be > more than sufficient to assume the reader has knowledge of RFC 1179, > and that this mapping document should not "spoon-feed" the reader. I was referring to the format of the long and short response which PSIS but not RFC 1179 specifies. ----- End Included Message -----   Received: from cnri by ietf.org id aa17739; 15 Jul 97 16:18 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA05722 for ; Tue, 15 Jul 1997 16:17:28 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA20678 for ; Tue, 15 Jul 1997 16:13:51 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 15 Jul 1997 16:10:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA20181 for ipp-outgoing; Tue, 15 Jul 1997 16:04:05 -0400 (EDT) Mime-Version: 1.0 Date: Tue, 15 Jul 1997 16:00:03 -0400 Message-ID: <0001851E.3036@okidata.com> From: Philip Thambidurai Subject: Re[2]: IPP> Firewalls and IPP To: ipp@pwg.org, Sylvan Butler Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: ipp-owner@pwg.org Steve, I agree that this is a non-trivial issue, but is VERY important. At the least, it may be advisable to provide some recommendations about how firewalls COULD handle in-bound requests --- this could be addressed in the Security spec. I tend to think that there could be a lot of questions in the Munich IETF meeting about this, and we should be prepared with some concrete answers. I also think that similar issues would have received good coverage in other protocol forums --- we could draw from. Regards Philip Thambidurai ______________________________ Reply Separator _________________________________ Subject: Re: IPP> Firewalls and IPP Author: "Sylvan Butler" at INTERNET Date: 7/15/97 10:52 AM > a) Does every "IPP printer" have to be made known to the firewall(s)? I move we do not spend much time trying to address inbound (thru the firewall) issues. It is a very complex problem and companies and firewall vendors will all want to approach it differently. My approach would be either no internal printers visible to outside, or a special IPP relay outside the firewall that would appear to be the printer outside and either store and forward or actually talk to the printer in realtime on the inside. > b) I did see (in the archives) that there was some discussion about > decisions based on the port number. An application-level firewall > (proxy) would be needed to distinguish between http intended for a > web server and http intended for an ipp printer. The security Not necessarily. The URL and hence server for IPP could (should?) be entirely seperate from the normal web server the company uses for their "home page". > c) How would we handle the case where a (small) business has only a > PPP link to the Internet via some ISP. The web hosting is provided > by the ISP and resides at the ISP's site. How exactly would a job > be received in the IPP printer at this business? We could assume > that the link is always up. This appears to place some requirement > on the part of the ISP --- to route some of the http traffic > (which contains IPP) to the client (business) site. This is very interesting. If the link is up all the time then the printer (or print server) could have a URL of its own. Whomever is trying to print to that printer would be using the printer URL and not the general ISP URL. Sure, it may be an IP address if the printer doesn't appear in the DNS namespace, but that works fine. Another approach (which doesn't require a dedicated link) would be similar to that used by e-mail today. The ISP could receive and store print jobs for the small company and the company would connect periodically and suck down the jobs. sdb | Sylvan Butler | sbutler@boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 |   Received: from cnri by ietf.org id aa19073; 15 Jul 97 17:06 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA05897 for ; Tue, 15 Jul 1997 17:05:28 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA21365 for ; Tue, 15 Jul 1997 17:01:50 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 15 Jul 1997 16:58:22 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA20895 for ipp-outgoing; Tue, 15 Jul 1997 16:51:53 -0400 (EDT) Date: Tue, 15 Jul 1997 13:50:15 PST From: David_Kellerman@nls.com To: IPP@pwg.org Message-ID: <009B74AE.7CF0E052.3@nls.com> Subject: Re: IPP> PRO proposed tweak to protocol Sender: ipp-owner@pwg.org Okay, so we've got a binary encoding for IPP. And now the suggestion is on the table to add a type field for each entity. So with a little shuffling, we could encode things like this: type-byte length-byte value-bytes And lets decide on some values for the type-byte (throw in a few extra values besides the character string and integer ones we need right now; you never know when they might come in handy): 01 boolean 02 integer 03 bit string 04 octet string 05 null 06 object identifier (uh, oh) 09 real 10 enumerated Let's use a zero byte to indicate the end of the sequence of values. And because it's a hot day, and I'm feeling feverish, let's just add these bytes to the front of the whole sequence: 30 80 Know what you've got? BER encoding! (Yes, the sequence is encoded using the indefinite form (an end-marker), and, yes, the pairs are "flattened" -- they don't have their own sequence wrappers.) Looking at this, I come up with at least two opposing conclusions: (1) if you're going to do a binary encoding, go ahead and use a simple BER subset (the extensibility and "off the shelf" arguments have already been made), or (2) we've aleady decided not to do BER, and the type fields are just a home-grown BER without most of the benefit, so stick with what we agreed to in Nashua. My personal (technical) bias has always been (1), but I think the answer that respects decisions already hammered out after much discussion is (2). :: David Kellerman Northlake Software 503-228-3383 :: david_kellerman@nls.com Portland, Oregon fax 503-228-5662   Received: from cnri by ietf.org id aa20864; 15 Jul 97 18:14 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid SAA06177 for ; Tue, 15 Jul 1997 18:13:24 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA22121 for ; Tue, 15 Jul 1997 18:08:58 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 15 Jul 1997 18:05:05 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA21624 for ipp-outgoing; Tue, 15 Jul 1997 17:58:36 -0400 (EDT) Date: Tue, 15 Jul 1997 14:59:26 -0700 From: Robert Herriot Message-Id: <199707152159.OAA03204@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO latest protocol document downloaded X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I have just downloaded the latest version of the protocol document, dated July 14, 1997. I have added the type byte the protocol. Otherwise, all changes to the document are for clarification. It is at: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-970714.doc MS Word V6.0 ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-970714.ps PostScript ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-970714-rev.doc with revisions I will download the text version in an hour or two. Bob Herriot   Received: from cnri by ietf.org id aa23804; 15 Jul 97 20:55 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid UAA06510 for ; Tue, 15 Jul 1997 20:53:54 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA23390 for ; Tue, 15 Jul 1997 20:50:18 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 15 Jul 1997 20:47:02 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA22737 for ipp-outgoing; Tue, 15 Jul 1997 20:39:07 -0400 (EDT) Date: Tue, 15 Jul 1997 17:39:55 -0700 From: Robert Herriot Message-Id: <199707160039.RAA03444@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO protocol document downloaded, text and new .doc file X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I just downloaded some files to the pwg site. When I was creating the text file, I found a small error in the examples section, so I downloaded a new .doc and .ps file and overwrote the old ones. The files are: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-970714.doc new copy of MS Word V6 ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-970714.ps new copy of PostScript ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-970714.txt text file for IETF   Received: from cnri by ietf.org id aa24026; 15 Jul 97 21:09 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid VAA06531 for ; Tue, 15 Jul 1997 21:08:43 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA23969 for ; Tue, 15 Jul 1997 21:05:05 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 15 Jul 1997 21:01:34 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA23477 for ipp-outgoing; Tue, 15 Jul 1997 20:55:01 -0400 (EDT) From: Stephen Zilles Message-Id: <199707160054.RAA23898@bulletin> To: ipp@pwg.org Subject: IPP> ADM - PWG IPP Phone Conference - July 16, 1997 Phone: (408) 536-4766 Fax: (408) 537-4042 Office: W14-504 Cc: szilles@adobe.com Date: Tue, 15 Jul 1997 17:54:54 PDT Sender: ipp-owner@pwg.org Agenda for Weekly IPP Phone Conference, July 16, 1997, 1-3PM PDT The weekly phone conference will occur as usual with Steve Zilles chairing the meeting in place of Carl-Uno. The phone call details are: Phone number: 1-423-523-7162 Access code: 190148 We have now reached the stage where it is critical to get the documents out for the Munich meeting. This week three new versions and one new document were distributed. These will be the main topics of dicussion. Agenda Rollcall 1. Identification of major open issues. I do not believe that there are any major open issues with the existing collection of documents, but if anyone believes that there are now is the time to identify them so they can be resolved before or no later than the Munich meeting. Here a major issue is more than a type or filling in missing text; it would typically mean a change of direction. Getting alignment/agreement among the documents is also NOT a major issue. 2. Discussion of Rational document. This is a new document which is intended to indicate (a) the IPP architecture and (b) why the architectural choices were made as they have been made. 3. Model Document 4. Protocol Document 5. LPD Mapping Document 6. Other business Adjourn at 3PM PDT promptly. Please read the documents and please only bring up issues that need group resolution or input; other issues can be sent to the author if small or the list. There is a lot to discuss and there is little time to do so. The Rational document was mailed to everyone and the other documents were posted as follows: Bob Herriot posted the latest version of the protocol document, dated July 14, 1997. He added the type byte the protocol. Otherwise, all changes to the document are for clarification. It is at: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-970714.doc MS Word V6.0 ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-970714.ps PostScript ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-970714-rev.doc with revisions Scott Issacson posted a new version of the model document: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970714-ms60.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970714-rev-ms60.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970714-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970714.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970714.txt ipp-model-970714-ms60.doc - A MS Word 6.0 doc with no revision marks ipp-model-970714-rev-ms60.doc - A MS Word 6.0 doc with revision marks ipp-model-970714-rev.pdf - A PDF line numbers and with revision marks ipp-model-970714.pdf - A PDF line numbers and with no revision marks ipp-model-970714.txt - A txt file with no line numbers (same as draft-ietf-ipp-model-03.txt) I have also sumbitted text file to the IETF as a new I-D: draft-ietf-ipp-model-03.txt I posted this at: ftp://ftp.pwg.org/pub/pwg/ipp/drafts/draft-ietf-ipp-model-03.txt Tom Hastings posted updated "Mapping between LPD and IPP Protocols" in: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ -rw-r--r-- 1 pwg pwg 69396 Jul 14 07:54 lpd-ipp-rev-black.pdf -rw-r--r-- 1 pwg pwg 72163 Jul 14 07:53 lpd-ipp-rev-red.pdf -rw-r--r-- 1 pwg pwg 62976 Jul 14 07:51 lpd-ipp.doc -rw-r--r-- 1 pwg pwg 41862 Jul 14 07:52 lpd-ipp.pdf -rw-r--r-- 1 pwg pwg 22915 Jul 14 07:52 lpd-ipp.txt   Received: from cnri by ietf.org id aa24867; 15 Jul 97 22:09 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid WAA06620 for ; Tue, 15 Jul 1997 22:07:52 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA24900 for ; Tue, 15 Jul 1997 22:04:16 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 15 Jul 1997 22:00:52 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA24409 for ipp-outgoing; Tue, 15 Jul 1997 21:54:13 -0400 (EDT) Message-Id: <3.0.1.32.19970715184518.00ad9860@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 15 Jul 1997 18:45:18 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Protocol Specification and LPD Mapping to IETF Cc: szilles@adobe.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Hi, I have been doing a bit of administrative work yesterday and today. I have sent off the latest versions of the Protocol Specification and the IPP to LPD Mapping documents to the IETF and the Area Directors. Expect them to show up on the official lists over the next couple of days. I expect to have a version for the Rationale document ready to send to IETF tomorrow. With that, we should have new I-Ds for all the documents at this stage, except the Requirements and the Directory Schema documents, which still require minor updates. We will try to have a whole new set out again before the Munich deadline on July 30, so give any remaining comments that you might have on the recently published drafts. I have added a PDF version of the Protocol Specification document to the PWG server. BTW, there will be an IPP phone conference tomorrow. Phone numbers are the same as last week, Steve Zilles is supposed to get the agenda together and lead the conference tomorrow as I am in training this week. Have fun - we are now getting there.... 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   Received: from cnri by ietf.org id aa25055; 15 Jul 97 22:21 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid WAA06649 for ; Tue, 15 Jul 1997 22:20:27 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA25437 for ; Tue, 15 Jul 1997 22:16:50 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 15 Jul 1997 22:13:15 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA24959 for ipp-outgoing; Tue, 15 Jul 1997 22:06:35 -0400 (EDT) Date: Tue, 15 Jul 1997 19:07:23 -0700 From: Robert Herriot Message-Id: <199707160207.TAA03551@woden.eng.sun.com> To: szilles@adobe.com Subject: Re: IPP> Rational for IPP Arch or "Why We Shot ourselves in the foot" Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org My comments all have RGH at the beginning of the line. Some of the comments are minor typos; others are more substantial. Bob Herriot > From szilles@Adobe.COM Mon Jul 14 18:10:34 1997 > > > INTERNET DRAFT Stephen N. Zilles > Adobe Systems Inc. > > July 14, 1997 Expires: Jan 14, 1998 > > > Rational for the Structure of the Model and Protocol RGH typo Rationale > for the Internet Printing Protocol > > > > 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. There are multiple parts > to IPP, but the primary architectural components are the Model, > the Protocol and an interface to Directory Services. This > document provides a high level overview of the architecture > and provides the rational for the decisions made in RGH typo rationale > structuring the architecture. > > The full set of IPP documents include: > > 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 > > > 1. ARCHITECTURAL OVERVIEW > > The Internet Printing Protocol (IPP) is an application level > protocol that can be used for distributed printing on the > Internet. This protocol defines interactions between a client > and a server. The client is provided the capability to inquire > about capabilities of a printer, to submit print jobs and to > inquire about and cancel print jobs. The server for these > requests is the Printer; the Printer is an abstraction a > generic document output device and/or a print service > provider. Thus, the Printer could be a real printing device, > such as a computer printer or fax output device, or it could > be a service that interfaced with output devices. > > The architecture for IPP defines (in the Model document) an > abstract Model for the data which is used to control the > printing process and to provide information about the process > and the capabilities of the Printer. This abstract Model is > hierarchical in nature and reflects the structure of the > Printer and the Jobs that may be being processed by the > Printer. > > The Internet provides a channel between the client and the > server/Printer. Use of this channel requires flattening and > sequencing the hierarchical Model data. Therefore, the IPP > also defines (in the Protocol document) an encoding of the > data in the model for transfer between the client and server. > This transfer of data may be either a request or the response > to a request. > > Finally, the IPP defines (in the Protocol document) a protocol > for transfering the encoded request and response data between > the client and the server/Printer. > > An example of a typical interaction would by a request from RGH typo be > the client to create a print job. The client would assemble > the Model data to be associated with that job, such as the > name of the job, the media to use, the number of pages to > place on each media instance, etc. This data would then be > encoded according to the Protocol and would be transmitted > according to the Protocol. The server/Printer would receive > the encoded Model data, decode it into a form understood by > the server/Printer and, based on that data, do one of two > things: (1) accept the job or (2) reject the job. In either > case, the server must construct a response in terms of the > Model data, encode that response according to the Protocol and > transmit that encoded Model data as the response to the > request using the Protocol. > > Another part of the IPP architecture is the Directory Schema. > The role of the Directory Schema is to provide a standard set > of attributes which might be used to query a directory service > for the URI of a Printer that is likely to meet the needs of > the client. > > The IPP architecture also addresses security issues such as > control of access to server/Printers and secure transmissions > of requests, response and the data to be printed. > > > 2. THE PRINTER > > Because the (abstract) server/Printer encompasses a wide range > of implementations, it is necessary to make some assumptions > about a minimal implementation. The most likely minimal > implementation is one that is embedded in an output device > running a specialized real time operating system and with > limited processing, memory and storage capabilities. This > Printer will be connected to the Internet and will have at > least a TCP/IP capability with (likely) SNMP support for the > Internet connection. In addition, it is likely the the Printer > will be an HTML/HTTP server to allow direct user access to > information about the printer. > > > 3. RATIONAL FOR THE MODEL RGH typo RATIONALE > > The Model is defined independently of any encoding of the > Model data both to support the likely uses of IPP and to be > robust with respect to the possibility of alternate > encodings. > > It is expected that a client or server/Printer would represent > the Model data in some data structure within the > applications/servers that support IPP. Therefore, the Model > was designed to make that representation > straightforward. Typically, a parser or formatter would be > used to convert from or to the encoded data format. Once in an > internal form suitable to a product, the data can be > manipulated by the product. For example, the data sent with a > Print Job can be used to control the processing of that Print > Job. > > The semantics of IPP are attached to the (abstract) > Model. Therefore, the application/server is not dependent on > the encoding of the Model data, and it is possible to consider > alternative mechanisms and formats by which the data could be > transmitted from a client to a server; for example, a server > could have a direct, client-less GUI interface that might be > used to accept some kinds of Print Jobs. This independence > would also allow a different encoding and/or transmission > mechanism to be used if the ones adopted here were shown to be > overly limiting in the future. Such a change could be migrated > into new products as an alternate protocol stack/parser for > the Model data. > > Having an abstract Model also allow the Model data to be RGH typo allows > aligned with the (abstract) model used in the Printer, Job and > Host Resources MIBs. This provides consistency in > interpretation of the data obtained independently of how the > data is accessed, whether via IPP or via SNMP and the > Printer/Job MIBs. > > 4. RATIONAL FOR THE PROTOCOL RGH typo RATIONALE > > There are two parts to the Protocol: (1) the encoding of the > Model data and (2) the mechanism for transmitting the model > data between client and server. > > 4.1 The Encoding > > To make it simpler to develop embedded printers, a very > simple binary encoding has been chosen. This encoding is > adequate to represent the kinds of data that occur within the > Model. It has a simple structure consisting of name value > pairs in which the names are length specified strings > constrained to characters from a subset of ASCII and the values > are either scalars or a sequence of scalars. Each scalar value > has a length specification. RGH: more specifically, each value type in the model is represented by RGH: either an integer or a character string in the encoding. > > A fully encoded request/response has a version number, an > operation (for a request) or a status (for a response), RGH new line: RGH operation parameters, attributes and, RGH delete following line > associated parameters which are encoded Model data and, > optionally, print data following the Model data. RGH new line: The model defines the operations, parameters and attributes. > > [ISSUE: what should be said about Parameters and Attributes] > > 4.2 The Transmission Mechanism > > The chosen mechanism for transmitting the encoded Model data > is HTTP 1.1 Post (and associated response). No modifications > to HTTP 1.1 are proposed or required. > > The sole role of the Transmission Mechanism is to provide a > transfer of encoded Model data from/to the client to/from the > server. This could be done using any data delivery mechanism. > The key reasons why HTTP 1.1 Post is used are: > > 1. HTTP 1.0 is already widely deployed and, based on the > recent evidence, HTTP 1.1 will be widely deployed as the > manufactures release new products. The performance RGH typo manufacturers > benefits of HTTP 1.1 have been shown and manufactures RGH typo manufacturers > are reacting postively. > > Wide deployment has meant that many of the problems of > making a protocol work in a wide range of environments > from local net to intranet to internet have been solved > and will stay solved with HTTP 1.1 deployment. > > 2. HTTP 1.1 solves most of the problems that might have > required a new protocol to be developed. HTTP 1.1 allows > persistent connections that make a multi-message > protocol be more efficient; for example it is practical > to have a separate CreatJob and SendJob RGH: Devil's advocate: RGH: Can't the same argument be used for a socket over TCP/IP? > messages. Chunking allows the transmission of large > print files without having to prescan the file to > determine the file length. The accept headers allow the RGH: Devil's advocate: RGH: As Appendix B in the protocol document shows, chunking is easy to RGH: achieve without HTTP. > client's protocol and localization desires to be > transmitted with the IPP operations and data. The HTTP > redirect response allows a client to be informed when a > Job he is interested in is moved to another > server/Printer for any reason. RGH though the model says (line 2433) that it does not support RGH redirect status-codes. The protocol supports only what the model RGH does > > 3. Most network Printers will be implementing HTTP servers > for reasons other than IPP. These network attached > Printers want to provide information on how to use the > printer, its current state, etc. in HTML. This requires > having an HTTP server which would be available to do IPP > functions as well. > > 4. Most of the complexity of HTTP 1.1 is concerned with the > implementation of proxies and not the implementation of > clients and/or servers. Work is proceding in the HTTP > Working Group to help identify what must be done by a > server. As the Protocol document shows, that is not very > much. > > 5. An HTTP based solution fits will with the Internet RGH typo well > security mechanism that are currently deployed or being > deployed. HTTP will run over SSL/TLS. The digest > authentication mechanism of HTTP 1.1 provides an > adequate level of access control (at least for intranet > usage). These solutions are deployed and in practical > use; a new solution would require extensive use to have > the same degree of confidence in its security. > > 5. RATIONAL FOR THE DIRECTORY SCHEMA > > Successful use of IPP depends on the client finding a > suitable IPP enabled Printer to which to send a IPP requests, > such as print a job. This task is simplified if there is a > Directory Service which can be queried for a suitable > Printer. The purpose of the Directory Schema is to have a > standard description of Printer attributes that can be > associated the the URI for the printer. These attributes are a > subset of the Model attributes and can be encoded in the > appropriate query syntax for the Directory Service being used > by the client. > > 6. RATIONAL FOR SECURITY > > Security is an areas of active work on the Internet. Complete > solutions to a wide range of security concerns are not yet > available. Therefore, in the design of IPP, the focus has been > on identifying a set of security protocols/features that are > implemented (or currently implementable) and solve real > problems with distributed printing. The two areas that seem > appropriate to support are: (1) authorization to use a Printer > and (2) secure interaction with a printer. The chosen > mechanisms are the digest authentication mechanism of HTTP 1.1 > and the SSL/TLS secure communication mechanism, which also > includes authorization. > > 7. REFERENCES > > TBD... > > 8. AUTHORS ADDRESS > > Stephen Zilles > Adobe Systems Incorporated > 345 Park Avenue > MailStop W14 > San Jose, CA 95110-2704 > > Phone: +1 408 536-4766 > Fax: +1 408 537-4042 > Email: szilles@adobe.com > > >   Received: from cnri by ietf.org id aa08338; 16 Jul 97 9:53 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid JAA07603 for ; Wed, 16 Jul 1997 09:52:37 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA29387 for ; Wed, 16 Jul 1997 09:49:00 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 16 Jul 1997 09:41:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA28862 for ipp-outgoing; Wed, 16 Jul 1997 09:35:10 -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-03.txt Date: Wed, 16 Jul 1997 09:39:44 -0400 Message-ID: <9707160939.aa06519@ietf.org> Sender: ipp-owner@pwg.org --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-03.txt Pages : 92 Date : 07/15/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-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-model-03.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-03.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: <19970715121418.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-model-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-model-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970715121418.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa08460; 16 Jul 97 9:59 EDT Received: from ietf.ietf.org by ietf.org id aa06501; 16 Jul 97 9:39 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ipp@pwg.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipp-lpd-ipp-map-00.txt Date: Wed, 16 Jul 1997 09:39:41 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9707160939.aa06501@ietf.org> --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 : Mapping between LPD and IPP Protocols Author(s) : T. Hasting, R. Herriot, N. Jacobs, J. Martin Filename : draft-ietf-ipp-lpd-ipp-map-00.txt Pages : 12 Date : 07/15/1997 This Internet-Draft specifies the mapping between (1) the commands and operands of the "Line Printer Daemon (LPD) Protocol" specified in RFC 1179 and (2) the operations and parameters of the Internet Printing Protocol (IPP). One of the purposes of this document is to compare the functionality of the two protocols. Another purpose is to facilitate implementation of gateways between LPD and IPP. WARNING: RFC 1179 was not on standards track. While RFC 1179 was intended to record existing practice, in some areas it fell short. However, this specification maps between (1) the actual current practice of RFC 1179 and (2) IPP. This document does not attempt to map the numerous divergent extensions to the LPD protocol that have been made by many implementors. 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-lpd-ipp-map-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-lpd-ipp-map-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-lpd-ipp-map-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: <19970715120415.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-lpd-ipp-map-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-lpd-ipp-map-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970715120415.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa12929; 16 Jul 97 13:16 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA08607 for ; Wed, 16 Jul 1997 13:15:16 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA01542 for ; Wed, 16 Jul 1997 13:11:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 16 Jul 1997 13:07:46 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA01071 for ipp-outgoing; Wed, 16 Jul 1997 13:01:11 -0400 (EDT) Date: Wed, 16 Jul 1997 13:01:31 -0400 (EDT) From: JK Martin Message-Id: <199707161701.NAA19473@uscore.underscore.com> To: ipp@pwg.org Subject: IPP> PRO - Resolving the issue of adding data type tags in the encoding X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org A relatively major change in the IPP encoding has been proposed to the list, yet very few people have voiced their opinions. The weekly IPP telecon will be held later today (1pm PDT, 4pm EDT), and this issue will surely arise. Would it be possible for all interested parties to state their "votes" on the list prior to the telecon so that we can grasp whether there is consensus PRO or CON to this issue? (Recall that IETF working group rules require that issues be resolved on the mailing list, and not in telecons or face-to-face meetings.) Thanks for posting your vote as quickly as possible. ...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 -- ----------------------------------------------------------------------   Received: from cnri by ietf.org id aa14326; 16 Jul 97 14:33 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid OAA08917 for ; Wed, 16 Jul 1997 14:32:24 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA02721 for ; Wed, 16 Jul 1997 14:28:47 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 16 Jul 1997 14:25:02 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA02255 for ipp-outgoing; Wed, 16 Jul 1997 14:18:26 -0400 (EDT) Date: Wed, 16 Jul 1997 14:18:33 -0400 (EDT) From: JK Martin Message-Id: <199707161818.OAA25660@uscore.underscore.com> To: pthambid@okidata.com Subject: Re: IPP> PRO - Resolving the issue of adding data type tags Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Philip, Ah, good question. I really don't think the question revolves around which encoding method to use for tagged types (ie, BER vs. homegrown). Rather, the issue is whether to introduce additional tokens in the encoding to denote the data type of the parameter/attribute...or not. ...jay ----- Begin Included Message ----- From pthambid@okidata.com Wed Jul 16 13:18 EDT 1997 Date: Wed, 16 Jul 1997 13:20:33 -0400 From: pthambid@okidata.com (Philip Thambidurai) Subject: Re: IPP> PRO - Resolving the issue of adding data type tags To: JK Martin Content-Transfer-Encoding: 7bit Hello, I am not sure what the options are ... did you mean whether to use data type tags, or whether to choose between BER and our own encoding. RSVP THanks Philip Thambidurai pthambid@okidata.com ______________________________ Reply Separator _________________________________ Subject: IPP> PRO - Resolving the issue of adding data type tags in t Author: JK Martin at INTERNET Date: 7/16/97 1:01 PM A relatively major change in the IPP encoding has been proposed to the list, yet very few people have voiced their opinions. The weekly IPP telecon will be held later today (1pm PDT, 4pm EDT), and this issue will surely arise. Would it be possible for all interested parties to state their "votes" on the list prior to the telecon so that we can grasp whether there is consensus PRO or CON to this issue? (Recall that IETF working group rules require that issues be resolved on the mailing list, and not in telecons or face-to-face meetings.) Thanks for posting your vote as quickly as possible. ...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 -- ---------------------------------------------------------------------- ----- End Included Message -----   Received: from cnri by ietf.org id aa20885; 16 Jul 97 20:27 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid UAA10092 for ; Wed, 16 Jul 1997 20:26:00 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA04723 for ; Wed, 16 Jul 1997 20:22:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 16 Jul 1997 20:18:18 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA04240 for ipp-outgoing; Wed, 16 Jul 1997 20:11:42 -0400 (EDT) Message-ID: <41135C785691CF11B73B00805FD4D2D7030F793B@RED-17-MSG.dns.microsoft.com> From: Paul Moore To: "'ipp@pwg.org'" Subject: IPP> Identifying jobs in requests Date: Wed, 16 Jul 1997 17:11:38 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: ipp-owner@pwg.org This is to propose a change to the model based on reviewing the protocol. At present the plan is that to cancel (for example) a job you send a cancel operation to the job's URL. Bob Herroitt and I propose that this be changed: you send a cancel operation to the printer URL giving a JobId as a parameter. This has the advantage that the client only needs to know one URL for all operations on a given printer. This then carries through into GetJobs returning a set of Jobids instead of a set of Job URLs. A jobid is just an opaque token, the client should not attempt to use it except as a way of identifying a job back to the server.   Received: from cnri by ietf.org id aa21118; 16 Jul 97 20:45 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid UAA10136 for ; Wed, 16 Jul 1997 20:44:14 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA05327 for ; Wed, 16 Jul 1997 20:40:36 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 16 Jul 1997 20:33:58 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA04805 for ipp-outgoing; Wed, 16 Jul 1997 20:25:09 -0400 (EDT) Message-ID: <41135C785691CF11B73B00805FD4D2D7030F793D@RED-17-MSG.dns.microsoft.com> From: Paul Moore To: "'ipp@pwg.org'" Subject: IPP> Job identification mandatory Date: Wed, 16 Jul 1997 17:25:27 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: ipp-owner@pwg.org Change to model following review of protocol. BobH and I propose that getjobs must always return a unique job identification (either jobid or job URL , see other recent mail) that can be used in subsequent requests. The reason is that most print API work this way and so most clients are structured on this assumption. (Specifcally in the MS world the EnumJobs API always returns a job identifier).   Received: from cnri by ietf.org id aa21173; 16 Jul 97 20:49 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid UAA10145 for ; Wed, 16 Jul 1997 20:48:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA05853 for ; Wed, 16 Jul 1997 20:44:31 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 16 Jul 1997 20:41:19 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA04833 for ipp-outgoing; Wed, 16 Jul 1997 20:29:57 -0400 (EDT) Message-ID: <33CD6789.28A8@parc.xerox.com> Date: Wed, 16 Jul 1997 17:30:01 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: Paul Moore CC: "'ipp@pwg.org'" Subject: Re: IPP> Identifying jobs in requests References: <41135C785691CF11B73B00805FD4D2D7030F793B@RED-17-MSG.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org > This has the advantage that the client only needs to know one URL for > all operations on a given printer. Why is it an advantage to have to know the Job ID instead of the Job URL? What is the nature of the advantage?   Received: from cnri by ietf.org id aa21555; 16 Jul 97 21:15 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid VAA10203 for ; Wed, 16 Jul 1997 21:13:50 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA06507 for ; Wed, 16 Jul 1997 21:10:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 16 Jul 1997 21:05:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA05976 for ipp-outgoing; Wed, 16 Jul 1997 20:59:04 -0400 (EDT) Date: Wed, 16 Jul 1997 17:59:53 -0700 From: Robert Herriot Message-Id: <199707170059.RAA04484@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO feedback on type byte X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I talked with Paul Moore of Microsoft today about the addition of the type byte to the protocol. He approves of the change. Bob Herriot   Received: from cnri by ietf.org id aa21783; 16 Jul 97 21:33 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid VAA10232 for ; Wed, 16 Jul 1997 21:32:15 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA07501 for ; Wed, 16 Jul 1997 21:28:38 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 16 Jul 1997 21:20:38 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA06310 for ipp-outgoing; Wed, 16 Jul 1997 21:07:51 -0400 (EDT) Message-Id: <3.0.1.32.19970716175854.00b2bd60@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 16 Jul 1997 17:58:54 PDT To: scott_isaacson@novell.com From: Carl-Uno Manros Subject: IPP> ADM - Name of the Requirements Document etc. Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Scott, as we now get closer to getting our "final" drafts in for Munich, I would like us to reach agreement on what we actually call the Requirements document. None of the other documents currently give the name that the Requirements document actually has, which is: Requirements for an Internet Printing Protocol I suppose that we can still change the title if we want to, as we will have a newer version out soon, but we need to be consistent. My propopsal is to keep the title (note this is the full title) and align the other documents. There are probably a few other things that we should align between the documents to ensure that they all have the same "touch and feel" and look like they come out of "one hand". As our chief editor, I ask you to call the shots for this. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com   Received: from cnri by ietf.org id aa21821; 16 Jul 97 21:35 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid VAA10238 for ; Wed, 16 Jul 1997 21:34:11 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA07784 for ; Wed, 16 Jul 1997 21:30:34 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 16 Jul 1997 21:24:00 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA06571 for ipp-outgoing; Wed, 16 Jul 1997 21:11:29 -0400 (EDT) From: Stephen Zilles Message-Id: <199707170111.SAA24623@bulletin> To: ipp@pwg.org Subject: IPP> ADM - Minutes of 7/16 IPP Phone Call Phone: (408) 536-4766 Fax: (408) 537-4042 Office: W14-504 Cc: szilles@adobe.com Date: Wed, 16 Jul 1997 18:11:13 PDT Sender: ipp-owner@pwg.org Minutes of 16 July 1997 IPP Phone Call By Steve Zilles Attendees Ira McDonald Dave Kellerman Roger deBry Jeff Copeland Peter Zehler Stan McConnell Bob Herriot Scott Isaacson Jay Martin Don Wright Steve Zilles 2. Rationale Document Discussion The list of HTTP reasons does not eliminate other solution mechansisms such as Sockets (but these need tweaking to be a full solution) the text will be revised to avoid claiming that HTTP is the only mechanism that would satisfy the reasons, but it is an already defined mechanism. There was discussion of how the Server implements things like Redirection and/or Localization using the Accept headers. Bob Herriot will investigate what the implications on the server (whether the server does the mapping or a CGI (or equivalent) script is required to do the handling of these functions. The discussion of Redirection will indicate that if the Model allow moving a job, then Redirection would help. 3. MODEL Document Document name attribute is currently mandatory; it is believed that we had agreed to make this be optional with the Printer generating a default name. Scott I will check out the past minutes to confirm this. What does Validate mean for a URI? Must the server try to fetch the URI at validate time. Answer, NO, but server is required to insure to the best of its ability that the URI is correctly formatted and is encouraged to test the URI. Validate job may be used for a PrintURI job as well as a PrintJob later. This needs to be indicated in the Validate. Change Locale and Originating User Locale to Language and add a Charset attribute for each of the Locales supported; refer to RFC2130 for Charset; 1766 for Language. Add dot to the characters allowed in the key word syntax to allow domain names to be expressed in this syntax. Re: format for device resolution value: use ASCII text to express three components, all SHALL be present. The three components are the resolution in the Feed direction, the resolution in the Cross feed direction and the units in which the units are expressed. The first two of these are numbers and the last is one of a fixed alphabetic spellings.(or the enum value from the SNMP Printer MIB units list. It was agreed that the description of resolution will be made to match the Printer MIB description. Agreed that this declaration does not tell the user which direction on the paper will have which resolution because the model (and SNMP ) does not provide an indication of how the paper is fed. Agreed that t Adobe must register PDF in the Printer Language Enum list 4. PROTOCOL Document Agreed that all integers will be 32 bit integers; this includes Enums Agreed the there will only be one type associated with each parameter or attribute Issue (still open) should requests with respect to a job be directed to the Printer (and contain the JOB URI) or be directed to the Job URI. The concern is the impact on the server to handle POSTs to all the Job URIs; is this too large a burden on the HTTP server. LPD Mapping Document Should the Mapping document disambiguate cases that are not fully specified in RFC 1179; for example should Agreed that the Mapping document (a) documents current practice; not necessarily 1179 and (b) may have clarification and/or additions to 1179 5. Other Business 5.1 Security Document Issue: whether an authenticated user (via basic, digest or TLS) can have different views/privileges with respect to the Printer. For example, can Cancel Job be limited to the user that submitted the Job. There is an attribute in the model for job-originating-user/ Action: fix the Model document to say that control of access for data or operations is not solely a funciton of the model, but is dependent on the security mechanisms used. IPP does not specify how the security level is integrated. 5.2 Meeting with Printer Analysts/Press to describe agreed IPP Roger deBry described a possible IPP to Analysts meeting in Boulder, one of Aug 20-22 IBM has analysts/press comming to Boulder for other purposes and is willing to devote one day of this period 6. Adjourn at 2:50 PDT   Received: from cnri by ietf.org id aa22128; 16 Jul 97 22:00 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid VAA10294 for ; Wed, 16 Jul 1997 21:59:31 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA08723 for ; Wed, 16 Jul 1997 21:55:54 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 16 Jul 1997 21:51:46 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA07919 for ipp-outgoing; Wed, 16 Jul 1997 21:44:15 -0400 (EDT) Message-ID: <41135C785691CF11B73B00805FD4D2D7030F793F@RED-17-MSG.dns.microsoft.com> From: Paul Moore To: 'Larry Masinter' Cc: "'ipp@pwg.org'" Subject: RE: IPP> Identifying jobs in requests Date: Wed, 16 Jul 1997 18:44:32 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: ipp-owner@pwg.org The transport layer part of the client side needs to know the URL. The application layer part needs to know the job IDs. These two layers should be kept separate. > -----Original Message----- > From: Larry Masinter [SMTP:masinter@parc.xerox.com] > Sent: Wednesday, July 16, 1997 5:30 PM > To: Paul Moore > Cc: 'ipp@pwg.org' > Subject: Re: IPP> Identifying jobs in requests > > > This has the advantage that the client only needs to know one URL > for > > all operations on a given printer. > > Why is it an advantage to have to know the Job ID instead of > the Job URL? What is the nature of the advantage?   Received: from cnri by ietf.org id aa23953; 16 Jul 97 22:29 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid WAA10336 for ; Wed, 16 Jul 1997 22:28:35 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA09425 for ; Wed, 16 Jul 1997 22:24:58 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 16 Jul 1997 22:18:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA08861 for ipp-outgoing; Wed, 16 Jul 1997 22:08:55 -0400 (EDT) Message-Id: <3.0.1.32.19970716190005.00a7b100@garfield> X-Sender: cmanros@garfield (Unverified) X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 16 Jul 1997 19:00:05 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Updated FAQ document Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Hi, I have just updated our FAQ document and replaced it for the old one on our server (under charter). The new version is automatically available also on the IPP web page. 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   Received: from cnri by ietf.org id aa24110; 16 Jul 97 22:33 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid WAA10339 for ; Wed, 16 Jul 1997 22:32:04 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA09887 for ; Wed, 16 Jul 1997 22:28:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 16 Jul 1997 22:24:44 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA08882 for ipp-outgoing; Wed, 16 Jul 1997 22:13:07 -0400 (EDT) Message-ID: <33CD80F7.C8319981@sharplabs.com> Date: Wed, 16 Jul 1997 19:18:32 -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: Paul Moore CC: 'Larry Masinter' , "'ipp@pwg.org'" Subject: Re: IPP> Identifying jobs in requests X-Priority: 3 (Normal) References: <41135C785691CF11B73B00805FD4D2D7030F793F@RED-17-MSG.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Paul Moore wrote: > The transport layer part of the client side needs to know the URL. The > > application layer part needs to know the job IDs. These two layers > should be kept separate. > > > -----Original Message----- > > From: Larry Masinter [SMTP:masinter@parc.xerox.com] > > Sent: Wednesday, July 16, 1997 5:30 PM > > To: Paul Moore > > Cc: 'ipp@pwg.org' > > Subject: Re: IPP> Identifying jobs in requests > > > > > This has the advantage that the client only needs to know one URL > > for > > > all operations on a given printer. > > > > Why is it an advantage to have to know the Job ID instead of > > the Job URL? What is the nature of the advantage? It would seem to be more sound for Job-IDs to be included, if URLs were basically out of band to the fundamental IPP model; but the last time I checked, the model document considers URLs to be the primary identifiers for IPP objects (or has this changed radically also?) Randy   Received: from cnri by ietf.org id aa08810; 17 Jul 97 10:39 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid KAA11662 for ; Thu, 17 Jul 1997 10:37:44 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA15636 for ; Thu, 17 Jul 1997 10:34:07 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 17 Jul 1997 10:26:40 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA15097 for ipp-outgoing; Thu, 17 Jul 1997 10:19:58 -0400 (EDT) Message-Id: <1.5.4.32.19970717142021.0069e55c@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: Thu, 17 Jul 1997 07:20:21 -0700 To: Paul Moore , "'ipp@pwg.org'" From: Carl-Uno Manros Subject: Re: IPP> Identifying jobs in requests Sender: ipp-owner@pwg.org At 05:11 PM 7/16/97 -0700, Paul Moore wrote: >This is to propose a change to the model based on reviewing the >protocol. > >At present the plan is that to cancel (for example) a job you send a >cancel operation to the job's URL. > >Bob Herroitt and I propose that this be changed: you send a cancel >operation to the printer URL giving a JobId as a parameter. > >This has the advantage that the client only needs to know one URL for >all operations on a given printer. > >This then carries through into GetJobs returning a set of Jobids instead >of a set of Job URLs. A jobid is just an opaque token, the client should >not attempt to use it except as a way of identifying a job back to the >server. > Paul, I am not too happy about this change. Going back to our earlier discussions, before you got involved, we determined to use URIs to identify Jobs because it gave us the flexibility to actually create the Jobs under a different server name (on the same or a different host), which might be useful in some bigger printing systems. Your solution seem to be optimized for the scenario where you have a generic Web server in combination with a Printer in the same host. Your solution seems to just complicate things a bit in scrnarios where you have an embedded or dedicated HTTP server that only does printing. In summary, I think your solution introduces new restrictions in our design, which are not particularly desirable. Is there any other way that you can solve your design problem? Carl-Uno   Received: from cnri by ietf.org id aa09676; 17 Jul 97 11:21 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid LAA11911 for ; Thu, 17 Jul 1997 11:20:34 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA16362 for ; Thu, 17 Jul 1997 11:16:57 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 17 Jul 1997 11:12:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA15861 for ipp-outgoing; Thu, 17 Jul 1997 11:06:10 -0400 (EDT) Date: Thu, 17 Jul 1997 11:06:25 -0400 (EDT) From: JK Martin Message-Id: <199707171506.LAA04915@uscore.underscore.com> To: paulmo@microsoft.com Subject: Re: IPP> Job identification mandatory Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Paul, Sorry, but I'm a bit confused by what you refer to as a "job identifier". Perhaps I'm incorrectly reading your text, but it sounds like "job identifier" is more of a "transaction identifier". The purpose of the GetJobs operation is to return one or more job identifiers from the target Printer (right?). Then exactly what are you and Bob proposing? So sorry if I'm being a bit dense here. ...jay ----- Begin Included Message ----- From ipp-owner@pwg.org Wed Jul 16 20:35 EDT 1997 From: Paul Moore To: "'ipp@pwg.org'" Subject: IPP> Job identification mandatory Date: Wed, 16 Jul 1997 17:25:27 -0700 Change to model following review of protocol. BobH and I propose that getjobs must always return a unique job identification (either jobid or job URL , see other recent mail) that can be used in subsequent requests. The reason is that most print API work this way and so most clients are structured on this assumption. (Specifcally in the MS world the EnumJobs API always returns a job identifier). ----- End Included Message -----   Received: from cnri by ietf.org id aa10433; 17 Jul 97 12:08 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid MAA12073 for ; Thu, 17 Jul 1997 12:06:49 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA17039 for ; Thu, 17 Jul 1997 12:03:11 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 17 Jul 1997 11:59:40 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA16573 for ipp-outgoing; Thu, 17 Jul 1997 11:52:58 -0400 (EDT) Date: Thu, 17 Jul 1997 11:49:47 -0400 (EDT) From: JK Martin Message-Id: <199707171549.LAA08437@uscore.underscore.com> To: hastings@cp10.es.xerox.com Subject: IPP> Re: PMP> ISSUE: OCTET STRING MUST be US-ASCII in 0-127; allow other sets in 128-255 Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Tom, You're right. You've really stepped into a mine field this time. I'm not the only one in the PMP group who grows weary of this last-minute attempt to change things. THESE ISSUES NEED TO BE RESOLVED QUICKLY BY THE GROUP NOW. This constant barrage of issues and justifications and "What If's" and "Maybe someone out there in the future may want to do something different" is totally inappropriate at this point in time, IMHO. Lloyd Young (Mr. Chairman): please see what you can do to draw consensus on these issues as quickly as possible, ok? All of us in the PMP group would like to see these discussions end as quickly as possible. Thanks. Tom, regarding your last message (to Dave Kellerman): > I should have separated my comments into separate e-mail messages more. Yes!!! This would certainly help each of us keep track of the issues. Please keep your email messages targeted on a SINGLE issue/proposal/etc. > Bottom line: ok with me to keep prtChannelInformation as NVT ASCII. Great! End of discussion, right? (Rhetorical question! No reply needed ;-) > 3. But why do we want to restrict our new object: prtGeneralPrinterName > to NVT ASCII? Can't system administrators define printer names in other > character sets (as long as ASCII is in 32-127)? I would suspect that > a printer that is using ISO Latin 1 or HP Roman 8 or JIS X0208 would allow the > accented letters to be part of printer names in Europe or Asia, wouldn't it? > > However, I see no reason for the prtGeneralPrinterName to be restricted > to NVT ASCII. Do you? Ok if we change prtGeneralPrinterName from > DisplayString to OCTET STRING? > > [...] > > 3. Change SYNTAX of prtGeneralPrinterName from DisplayString (NVT ASCII) > to OCTET STRING. OK with you? Look, I am the original author of the prtGeneralAdminName MIB object. The intent of this object is to provide a "binding mechanism" between an instance of the Printer MIB and a "printer" as defined on a host platform. So, it really comes down to this: if the host platform allows for internationalized names for "printer" objects defined in the local printing system, then fine, we'll probably need OCTET STRING instead of DisplayString. However, what platforms out there now (much less in the next 3 years) allow for such internationalized names? I can certainly be convinced of the need for OCTET STRING if someone can come forward with hard instances of such platforms. > 2. Change SYNTAX of prtChannelInformation from DisplayString (NVT ASCII) > to OCTET STRING. NOT OK with you. No, do not change prtChannelInformation to OCTET STRING. Leave it alone. We really must close up these discussions, pronto. Let's hear from the others on the PMP list asap, ok? I would particularly like to hear from Bob Pentecost (HP) and Harry Lewis (IBM), as well as the many other fine folks who have invested considerable time in developing the Printer MIB over the last four years. ...jay   Received: from cnri by ietf.org id aa10861; 17 Jul 97 12:27 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid MAA12165 for ; Thu, 17 Jul 1997 12:26:22 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA17819 for ; Thu, 17 Jul 1997 12:22:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 17 Jul 1997 12:19:36 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA17260 for ipp-outgoing; Thu, 17 Jul 1997 12:12:28 -0400 (EDT) Date: Thu, 17 Jul 1997 12:12:47 -0400 (EDT) From: JK Martin Message-Id: <199707171612.MAA10331@uscore.underscore.com> To: ipp@pwg.org Subject: Re: IPP> Re: PMP> ISSUE: OCTET STRING MUST be US-ASCII in 0-127; allow other sets in 128-255 X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I am terribly sorry, but I accidentally cc:'d the IPP list rather than the PMP list on that last message. Please disregard. Those of us who must simultaneously dance across no fewer than *three* PWG standards efforts sometimes get confused... ;-) ...jay   Received: from cnri by ietf.org id aa11815; 17 Jul 97 13:06 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA12312 for ; Thu, 17 Jul 1997 13:04:56 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA18480 for ; Thu, 17 Jul 1997 13:01:19 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 17 Jul 1997 12:58:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA18007 for ipp-outgoing; Thu, 17 Jul 1997 12:51:26 -0400 (EDT) From: Roger K Debry To: ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: Re: IPP> Job identification mandatory Message-Id: <5030100004919177000002L072*@MHS> Date: Thu, 17 Jul 1997 12:52:55 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Job URI is one of the attributes that Get-Attributes "can" return, are you just asking that it "must" be returned? 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 07/17/97 10:46 AM --------------------------- ipp-owner @ pwg.org 07/17/97 09:17 AM Please respond to ipp-owner@pwg.org @ internet To: paulmo @ microsoft.com @ internet cc: ipp @ pwg.org @ internet Subject: Re: IPP> Job identification mandatory Paul, Sorry, but I'm a bit confused by what you refer to as a "job identifier". Perhaps I'm incorrectly reading your text, but it sounds like "job identifier" is more of a "transaction identifier". The purpose of the GetJobs operation is to return one or more job identifiers from the target Printer (right?). Then exactly what are you and Bob proposing? So sorry if I'm being a bit dense here. ...jay ----- Begin Included Message ----- From ipp-owner@pwg.org Wed Jul 16 20:35 EDT 1997 From: Paul Moore To: "'ipp@pwg.org'" Subject: IPP> Job identification mandatory Date: Wed, 16 Jul 1997 17:25:27 -0700 Change to model following review of protocol. BobH and I propose that getjobs must always return a unique job identification (either jobid or job URL , see other recent mail) that can be used in subsequent requests. The reason is that most print API work this way and so most clients are structured on this assumption. (Specifcally in the MS world the EnumJobs API always returns a job identifier). ----- End Included Message -----   Received: from ietf.org by ietf.org id aa13232; 17 Jul 97 13:35 EDT Received: from ietf.ietf.org by ietf.org id aa12515; 17 Jul 97 13:23 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ipp@pwg.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipp-protocol-00.txt Date: Thu, 17 Jul 1997 13:23:46 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9707171323.aa12515@ietf.org> --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: Protocol Specification Author(s) : R. Herriot, S. Butler, P. Moore, R. Turner Filename : draft-ietf-ipp-protocol-00.txt Pages : 30 Date : 07/16/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-protocol-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-protocol-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-protocol-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: <19970716111452.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-protocol-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-protocol-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970716111452.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa15065; 17 Jul 97 14:57 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid OAA12868 for ; Thu, 17 Jul 1997 14:56:40 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA19996 for ; Thu, 17 Jul 1997 14:53:01 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 17 Jul 1997 14:43:52 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA18912 for ipp-outgoing; Thu, 17 Jul 1997 14:30:02 -0400 (EDT) Message-ID: <41135C785691CF11B73B00805FD4D2D7030F7944@RED-17-MSG.dns.microsoft.com> From: Paul Moore To: 'JK Martin' Cc: ipp@pwg.org Subject: RE: IPP> Job identification mandatory Date: Thu, 17 Jul 1997 11:30:15 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: ipp-owner@pwg.org No its not a transaction ID its a job ID. The point is that the current model allows a server to refuse to supply a job identification attribute - I am proposing that the server always return a job identification attribute if so requested. > -----Original Message----- > From: JK Martin [SMTP:jkm@underscore.com] > Sent: Thursday, July 17, 1997 8:06 AM > To: Paul Moore > Cc: ipp@pwg.org > Subject: Re: IPP> Job identification mandatory > > Paul, > > Sorry, but I'm a bit confused by what you refer to as a > "job identifier". Perhaps I'm incorrectly reading your > text, but it sounds like "job identifier" is more of a > "transaction identifier". > > The purpose of the GetJobs operation is to return one or > more job identifiers from the target Printer (right?). > Then exactly what are you and Bob proposing? > > So sorry if I'm being a bit dense here. > > ...jay > > ----- Begin Included Message ----- > > From ipp-owner@pwg.org Wed Jul 16 20:35 EDT 1997 > From: Paul Moore > To: "'ipp@pwg.org'" > Subject: IPP> Job identification mandatory > Date: Wed, 16 Jul 1997 17:25:27 -0700 > > Change to model following review of protocol. > > BobH and I propose that getjobs must always return a unique job > identification (either jobid or job URL , see other recent mail) that > can be used in subsequent requests. > > The reason is that most print API work this way and so most clients > are > structured on this assumption. (Specifcally in the MS world the > EnumJobs > API always returns a job identifier). > > > > ----- End Included Message -----   Received: from cnri by ietf.org id aa15317; 17 Jul 97 15:03 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid PAA12886 for ; Thu, 17 Jul 1997 15:02:24 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA20533 for ; Thu, 17 Jul 1997 14:58:46 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 17 Jul 1997 14:55:22 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA18969 for ipp-outgoing; Thu, 17 Jul 1997 14:40:08 -0400 (EDT) Date: Thu, 17 Jul 1997 14:40:10 -0400 (EDT) From: JK Martin Message-Id: <199707171840.OAA21880@uscore.underscore.com> To: paulmo@microsoft.com Subject: RE: IPP> Job identification mandatory Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Ah, I see. So Roger deBry was right, you're proposing that we mandate that an IPP server always return a job ID if requested. I certainly agree with your (and Bob's) proposal. ...jay ----- Begin Included Message ----- From paulmo@microsoft.com Thu Jul 17 14:30 EDT 1997 From: Paul Moore To: "'JK Martin'" Cc: ipp@pwg.org Subject: RE: IPP> Job identification mandatory Date: Thu, 17 Jul 1997 11:30:15 -0700 No its not a transaction ID its a job ID. The point is that the current model allows a server to refuse to supply a job identification attribute - I am proposing that the server always return a job identification attribute if so requested. > -----Original Message----- > From: JK Martin [SMTP:jkm@underscore.com] > Sent: Thursday, July 17, 1997 8:06 AM > To: Paul Moore > Cc: ipp@pwg.org > Subject: Re: IPP> Job identification mandatory > > Paul, > > Sorry, but I'm a bit confused by what you refer to as a > "job identifier". Perhaps I'm incorrectly reading your > text, but it sounds like "job identifier" is more of a > "transaction identifier". > > The purpose of the GetJobs operation is to return one or > more job identifiers from the target Printer (right?). > Then exactly what are you and Bob proposing? > > So sorry if I'm being a bit dense here. > > ...jay > > ----- Begin Included Message ----- > > From ipp-owner@pwg.org Wed Jul 16 20:35 EDT 1997 > From: Paul Moore > To: "'ipp@pwg.org'" > Subject: IPP> Job identification mandatory > Date: Wed, 16 Jul 1997 17:25:27 -0700 > > Change to model following review of protocol. > > BobH and I propose that getjobs must always return a unique job > identification (either jobid or job URL , see other recent mail) that > can be used in subsequent requests. > > The reason is that most print API work this way and so most clients > are > structured on this assumption. (Specifcally in the MS world the > EnumJobs > API always returns a job identifier). > > > > ----- End Included Message ----- ----- End Included Message -----   Received: from cnri by ietf.org id aa16840; 17 Jul 97 16:12 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA13231 for ; Thu, 17 Jul 1997 16:11:25 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA21850 for ; Thu, 17 Jul 1997 16:07:43 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 17 Jul 1997 15:54:25 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA20797 for ipp-outgoing; Thu, 17 Jul 1997 15:35:51 -0400 (EDT) Mime-Version: 1.0 Date: Thu, 17 Jul 1997 14:48:23 -0400 Message-ID: <00018A66.3036@okidata.com> From: Philip Thambidurai Subject: IPP> "Asynchronous Notification" 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 The Requirements document states that "clients must be able to request async notification for printer events such as ... job completion, ..." Is this REALLY provided in the protocol? To me, this appears to imply that when the job is completed, the printer will send a message to the client (ASYNCHRONOUSLY). While the GetJobs response could contain a completed job list, it is stricly SYNCHRONOUS ??? (relative to GetJobs request). Would it make sense to call it "Conditional notification" --- meaning that the client could find out about job completion by issuing the synchronous GetJobs, conditional on the printer still keeping track of the particular completed job status. Philip Thambidurai pthambid@okidata.com   Received: from cnri by ietf.org id aa16963; 17 Jul 97 16:17 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA13260 for ; Thu, 17 Jul 1997 16:15:44 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA22427 for ; Thu, 17 Jul 1997 16:12:00 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 17 Jul 1997 16:00:44 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA20816 for ipp-outgoing; Thu, 17 Jul 1997 15:37:57 -0400 (EDT) Mime-Version: 1.0 Date: Thu, 17 Jul 1997 15:11:12 -0400 Message-ID: <00018A68.3036@okidata.com> From: Philip Thambidurai Subject: IPP> RE: "Asynchronous Notification" 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 Please disregard my post on Async. notification --- the "notify-addresses" attribute of the job template certainly takes care of my concern. ______________________________ Forward Header __________________________________ >>Subject: "Asynchronous Notification" >>Author: Philip Thambidurai at ODA-ENG >>Date: 7/17/97 2:48 PM >>The Requirements document states that "clients must be able to >>request async notification for printer events such as ... job >>completion, ..." >> >>Is this REALLY provided in the protocol? To me, this appears to imply >>that when the job is completed, the printer will send a message to the >>client (ASYNCHRONOUSLY). >> >>While the GetJobs response could contain a completed job list, it is >>stricly SYNCHRONOUS ??? (relative to GetJobs request). >> >>Would it make sense to call it "Conditional notification" --- meaning >>that the client could find out about job completion by issuing the >>synchronous GetJobs, conditional on the printer still keeping track >>of the particular completed job status. >>   Received: from cnri by ietf.org id aa17001; 17 Jul 97 16:18 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA13266 for ; Thu, 17 Jul 1997 16:17:31 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA22676 for ; Thu, 17 Jul 1997 16:13:51 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 17 Jul 1997 16:03:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA20852 for ipp-outgoing; Thu, 17 Jul 1997 15:40:11 -0400 (EDT) Date: Thu, 17 Jul 1997 12:40:09 -0700 From: Robert Herriot Message-Id: <199707171940.MAA05214@woden.eng.sun.com> To: paulmo@microsoft.com, jkm@underscore.com Subject: RE: IPP> Job identification mandatory Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Here is some background for the proposal to make job-identification an attribute that a Printer must return with Get-Jobs, if requested to do so. Originally, we said that a paranoid Printer might choose to return no information about some jobs, but job-uri is special in that it uniquely identifies the job. So it seems reasonable that if a client asks for it, the Printer should return it. Paul and I discussed the possibility that a paranoid Printer might return a special job-uri for secure jobs. If a client used this job-uri in other operations, the Printer would recognize it as a special uri that doesn't really reference the job. This raises the issue as to whether such a special ("fake") job-uri is also unique or can the same special job-uri be returned for all secure jobs? Bob Herriot > From jkm@underscore.com Thu Jul 17 11:57:40 1997 > Date: Thu, 17 Jul 1997 14:40:10 -0400 (EDT) > From: JK Martin > To: paulmo@microsoft.com > Subject: RE: IPP> Job identification mandatory > Cc: ipp@pwg.org > X-Sun-Charset: US-ASCII > Sender: ipp-owner@pwg.org > Content-Length: 2097 > X-Lines: 70 > > Ah, I see. So Roger deBry was right, you're proposing that we mandate > that an IPP server always return a job ID if requested. > > I certainly agree with your (and Bob's) proposal. > > ...jay > > ----- Begin Included Message ----- > > From paulmo@microsoft.com Thu Jul 17 14:30 EDT 1997 > From: Paul Moore > To: "'JK Martin'" > Cc: ipp@pwg.org > Subject: RE: IPP> Job identification mandatory > Date: Thu, 17 Jul 1997 11:30:15 -0700 > > No its not a transaction ID its a job ID. The point is that the current > model allows a server to refuse to supply a job identification attribute > - I am proposing that the server always return a job identification > attribute if so requested. > > > -----Original Message----- > > From: JK Martin [SMTP:jkm@underscore.com] > > Sent: Thursday, July 17, 1997 8:06 AM > > To: Paul Moore > > Cc: ipp@pwg.org > > Subject: Re: IPP> Job identification mandatory > > > > Paul, > > > > Sorry, but I'm a bit confused by what you refer to as a > > "job identifier". Perhaps I'm incorrectly reading your > > text, but it sounds like "job identifier" is more of a > > "transaction identifier". > > > > The purpose of the GetJobs operation is to return one or > > more job identifiers from the target Printer (right?). > > Then exactly what are you and Bob proposing? > > > > So sorry if I'm being a bit dense here. > > > > ...jay > > > > ----- Begin Included Message ----- > > > > From ipp-owner@pwg.org Wed Jul 16 20:35 EDT 1997 > > From: Paul Moore > > To: "'ipp@pwg.org'" > > Subject: IPP> Job identification mandatory > > Date: Wed, 16 Jul 1997 17:25:27 -0700 > > > > Change to model following review of protocol. > > > > BobH and I propose that getjobs must always return a unique job > > identification (either jobid or job URL , see other recent mail) that > > can be used in subsequent requests. > > > > The reason is that most print API work this way and so most clients > > are > > structured on this assumption. (Specifcally in the MS world the > > EnumJobs > > API always returns a job identifier). > > > > > > > > ----- End Included Message ----- > > > ----- End Included Message ----- > >   Received: from cnri by ietf.org id aa17032; 17 Jul 97 16:21 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA13270 for ; Thu, 17 Jul 1997 16:19:53 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA22993 for ; Thu, 17 Jul 1997 16:16:11 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 17 Jul 1997 16:09:40 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA20894 for ipp-outgoing; Thu, 17 Jul 1997 15:45:44 -0400 (EDT) Message-ID: <41135C785691CF11B73B00805FD4D2D7030F7948@RED-17-MSG.dns.microsoft.com> From: Paul Moore To: 'Carl-Uno Manros' , "'ipp@pwg.org'" Subject: RE: IPP> Identifying jobs in requests Date: Thu, 17 Jul 1997 12:38:25 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: ipp-owner@pwg.org also using URLs to imply the job id means that we are tied to a specific transport - something we tried to avoid. If we were to use , say, raw IP then you would need to assign an IP port to each job or something like that. > -----Original Message----- > From: Carl-Uno Manros [SMTP:carl@manros.com] > Sent: Thursday, July 17, 1997 7:20 AM > To: Paul Moore; 'ipp@pwg.org' > Subject: Re: IPP> Identifying jobs in requests > > At 05:11 PM 7/16/97 -0700, Paul Moore wrote: > >This is to propose a change to the model based on reviewing the > >protocol. > > > >At present the plan is that to cancel (for example) a job you send a > >cancel operation to the job's URL. > > > >Bob Herroitt and I propose that this be changed: you send a cancel > >operation to the printer URL giving a JobId as a parameter. > > > >This has the advantage that the client only needs to know one URL for > >all operations on a given printer. > > > >This then carries through into GetJobs returning a set of Jobids > instead > >of a set of Job URLs. A jobid is just an opaque token, the client > should > >not attempt to use it except as a way of identifying a job back to > the > >server. > > > > Paul, > > I am not too happy about this change. Going back to our earlier > discussions, > before you got involved, we determined to use URIs to identify Jobs > because > it gave us the flexibility to actually create the Jobs under a > different > server name (on the same or a different host), which might be useful > in some > bigger printing systems. Your solution seem to be optimized for the > scenario > where you have a generic Web server in combination with a Printer in > the same > host. Your solution seems to just complicate things a bit in scrnarios > where > you have an embedded or dedicated HTTP server that only does printing. > > In summary, I think your solution introduces new restrictions in our > design, > which are not particularly desirable. Is there any other way that you > can > solve your design problem? > > Carl-Uno >   Received: from cnri by ietf.org id aa17837; 17 Jul 97 17:05 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA13442 for ; Thu, 17 Jul 1997 17:04:09 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA23813 for ; Thu, 17 Jul 1997 17:00:31 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 17 Jul 1997 16:53:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA23214 for ipp-outgoing; Thu, 17 Jul 1997 16:44:20 -0400 (EDT) Date: Thu, 17 Jul 1997 16:44:33 -0400 (EDT) From: JK Martin Message-Id: <199707172044.QAA01815@uscore.underscore.com> To: paulmo@microsoft.com Subject: RE: IPP> Identifying jobs in requests Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > also using URLs to imply the job id means that we are tied to a specific > transport - something we tried to avoid. If we were to use , say, raw IP > then you would need to assign an IP port to each job or something like > that. Is this really true? Do you mean we would be tying ourselves to HTTP by using a URL as a job ID? It would seem that just because we choose the use the syntax and semantics of a URL doesn't mean we necessarily tie ourselves to HTTP, right? ...jay   Received: from cnri by ietf.org id aa17947; 17 Jul 97 17:09 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA13462 for ; Thu, 17 Jul 1997 17:08:12 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA24349 for ; Thu, 17 Jul 1997 17:04:35 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 17 Jul 1997 17:00:48 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA23258 for ipp-outgoing; Thu, 17 Jul 1997 16:48:52 -0400 (EDT) Message-ID: <41135C785691CF11B73B00805FD4D2D7030F794A@RED-17-MSG.dns.microsoft.com> From: Paul Moore To: 'JK Martin' Cc: ipp@pwg.org Subject: RE: IPP> Identifying jobs in requests Date: Thu, 17 Jul 1997 13:49:05 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: ipp-owner@pwg.org I mean that not using jobids at all (which is what we do at present) ties us to HTTP. In the current model a cancel job is done by posting a cancel operation to the job URL. No job id is sent, it is implied in the transport endpoint. > -----Original Message----- > From: JK Martin [SMTP:jkm@underscore.com] > Sent: Thursday, July 17, 1997 1:45 PM > To: Paul Moore > Cc: ipp@pwg.org > Subject: RE: IPP> Identifying jobs in requests > > > also using URLs to imply the job id means that we are tied to a > specific > > transport - something we tried to avoid. If we were to use , say, > raw IP > > then you would need to assign an IP port to each job or something > like > > that. > > > Is this really true? Do you mean we would be tying ourselves to HTTP > by using a URL as a job ID? > > It would seem that just because we choose the use the syntax and > semantics of a URL doesn't mean we necessarily tie ourselves to HTTP, > right? > > ...jay   Received: from cnri by ietf.org id aa19483; 17 Jul 97 18:32 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid SAA13779 for ; Thu, 17 Jul 1997 18:30:46 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA25344 for ; Thu, 17 Jul 1997 18:27:09 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 17 Jul 1997 18:23:47 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA24849 for ipp-outgoing; Thu, 17 Jul 1997 18:17:01 -0400 (EDT) Message-ID: <33CE99ED.6B84@parc.xerox.com> Date: Thu, 17 Jul 1997 15:17:17 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: Paul Moore CC: 'Carl-Uno Manros' , "'ipp@pwg.org'" Subject: Re: IPP> Identifying jobs in requests References: <41135C785691CF11B73B00805FD4D2D7030F7948@RED-17-MSG.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org > also using URLs to imply the job id means that we are tied to a specific > transport - something we tried to avoid. If we were to use , say, raw IP > then you would need to assign an IP port to each job or something like > that. I thought it was the other way around: using URLs allows the protocol used for cancel job to be different than the protocol used for creating the job, because the URL scheme itself identifies the protocol. Larry   Received: from cnri by ietf.org id aa20907; 17 Jul 97 20:23 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid UAA14146 for ; Thu, 17 Jul 1997 20:22:35 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA27010 for ; Thu, 17 Jul 1997 20:18:56 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 17 Jul 1997 20:08:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA26434 for ipp-outgoing; Thu, 17 Jul 1997 20:00:01 -0400 (EDT) Message-ID: <33CEB339.D1EAE217@sharplabs.com> Date: Thu, 17 Jul 1997 17:05:13 -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: Paul Moore CC: 'JK Martin' , ipp@pwg.org Subject: Re: IPP> Identifying jobs in requests X-Priority: 3 (Normal) References: <41135C785691CF11B73B00805FD4D2D7030F794A@RED-17-MSG.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Paul Moore wrote: > I mean that not using jobids at all (which is what we do at present) > ties us to HTTP. In the model document, job identifiers are URLs. If we have pushed URLs out of themain body of the protocol up into the transport layer, then this is a mistake. Job identifiers belong within the application/ipp body, and, according to the model document, object identifiers are in URL format. Also, the use of URL/URI strings as object identifiers in and of itself does not tie us to any one transport mechanism. Randy > > > In the current model a cancel job is done by posting a cancel > operation > to the job URL. No job id is sent, it is implied in the transport > endpoint. > > > -----Original Message----- > > From: JK Martin [SMTP:jkm@underscore.com] > > Sent: Thursday, July 17, 1997 1:45 PM > > To: Paul Moore > > Cc: ipp@pwg.org > > Subject: RE: IPP> Identifying jobs in requests > > > > > also using URLs to imply the job id means that we are tied to a > > specific > > > transport - something we tried to avoid. If we were to use , say, > > raw IP > > > then you would need to assign an IP port to each job or something > > like > > > that. > > > > > > Is this really true? Do you mean we would be tying ourselves to > HTTP > > by using a URL as a job ID? > > > > It would seem that just because we choose the use the syntax and > > semantics of a URL doesn't mean we necessarily tie ourselves to > HTTP, > > right? > > > > ...jay   Received: from cnri by ietf.org id aa21126; 17 Jul 97 20:40 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid UAA14174 for ; Thu, 17 Jul 1997 20:38:59 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA28139 for ; Thu, 17 Jul 1997 20:35:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 17 Jul 1997 20:23:36 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA26475 for ipp-outgoing; Thu, 17 Jul 1997 20:05:09 -0400 (EDT) Message-ID: <41135C785691CF11B73B00805FD4D2D7030F7954@RED-17-MSG.dns.microsoft.com> From: Paul Moore To: "'rturner@sharplabs.com'" Cc: 'JK Martin' , ipp@pwg.org Subject: RE: IPP> Identifying jobs in requests Date: Thu, 17 Jul 1997 17:05:22 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: ipp-owner@pwg.org Not the issue. I do not object to using URI as job identifiers - I object to not giving the job identifier in a job specifc request. To restate - when I do a canceljob operation I do not supply a job identifier - the target job is implicit in the transport endpoint - this ties us to a transport. > -----Original Message----- > From: Randy Turner [SMTP:rturner@sharplabs.com] > Sent: Thursday, July 17, 1997 5:05 PM > To: Paul Moore > Cc: 'JK Martin'; ipp@pwg.org > Subject: Re: IPP> Identifying jobs in requests > > Paul Moore wrote: > > > I mean that not using jobids at all (which is what we do at present) > > ties us to HTTP. > > In the model document, job identifiers are URLs. If we have pushed > URLs > out of themain body of the protocol up into the transport layer, then > this is a mistake. Job identifiers > belong within the application/ipp body, and, according to the model > document, object > identifiers are in URL format. Also, the use of URL/URI strings as > object identifiers in > and of itself does not tie us to any one transport mechanism. > > Randy > > > > > > > > In the current model a cancel job is done by posting a cancel > > operation > > to the job URL. No job id is sent, it is implied in the transport > > endpoint. > > > > > -----Original Message----- > > > From: JK Martin [SMTP:jkm@underscore.com] > > > Sent: Thursday, July 17, 1997 1:45 PM > > > To: Paul Moore > > > Cc: ipp@pwg.org > > > Subject: RE: IPP> Identifying jobs in requests > > > > > > > also using URLs to imply the job id means that we are tied to a > > > specific > > > > transport - something we tried to avoid. If we were to use , > say, > > > raw IP > > > > then you would need to assign an IP port to each job or > something > > > like > > > > that. > > > > > > > > > Is this really true? Do you mean we would be tying ourselves to > > HTTP > > > by using a URL as a job ID? > > > > > > It would seem that just because we choose the use the syntax and > > > semantics of a URL doesn't mean we necessarily tie ourselves to > > HTTP, > > > right? > > > > > > ...jay > >   Received: from cnri by ietf.org id aa21186; 17 Jul 97 20:44 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid UAA14183 for ; Thu, 17 Jul 1997 20:43:13 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA28517 for ; Thu, 17 Jul 1997 20:39:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 17 Jul 1997 20:29:31 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA26502 for ipp-outgoing; Thu, 17 Jul 1997 20:08:54 -0400 (EDT) Message-ID: <33CEB554.5F7CF584@sharplabs.com> Date: Thu, 17 Jul 1997 17:14:12 -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: Paul Moore CC: 'JK Martin' , ipp@pwg.org Subject: Re: IPP> Identifying jobs in requests X-Priority: 3 (Normal) References: <41135C785691CF11B73B00805FD4D2D7030F7954@RED-17-MSG.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Paul Moore wrote: > Not the issue. I do not object to using URI as job identifiers - I > object to not giving the job identifier in a job specifc request. > > To restate - when I do a canceljob operation I do not supply a job > identifier - the target job is implicit in the transport endpoint - > this > ties us to a transport. Ok, I think we're in violent agreement here....I agree that the operandsof an IPP operation should not be implied by any transport-level information; especially if we plan on moving IPP to other transports... Randy > > > > -----Original Message----- > > From: Randy Turner [SMTP:rturner@sharplabs.com] > > Sent: Thursday, July 17, 1997 5:05 PM > > To: Paul Moore > > Cc: 'JK Martin'; ipp@pwg.org > > Subject: Re: IPP> Identifying jobs in requests > > > > Paul Moore wrote: > > > > > I mean that not using jobids at all (which is what we do at > present) > > > ties us to HTTP. > > > > In the model document, job identifiers are URLs. If we have pushed > > URLs > > out of themain body of the protocol up into the transport layer, > then > > this is a mistake. Job identifiers > > belong within the application/ipp body, and, according to the model > > document, object > > identifiers are in URL format. Also, the use of URL/URI strings as > > object identifiers in > > and of itself does not tie us to any one transport mechanism. > > > > Randy > > > > > > > > > > > > > In the current model a cancel job is done by posting a cancel > > > operation > > > to the job URL. No job id is sent, it is implied in the transport > > > endpoint. > > > > > > > -----Original Message----- > > > > From: JK Martin [SMTP:jkm@underscore.com] > > > > Sent: Thursday, July 17, 1997 1:45 PM > > > > To: Paul Moore > > > > Cc: ipp@pwg.org > > > > Subject: RE: IPP> Identifying jobs in requests > > > > > > > > > also using URLs to imply the job id means that we are tied to > a > > > > specific > > > > > transport - something we tried to avoid. If we were to use , > > say, > > > > raw IP > > > > > then you would need to assign an IP port to each job or > > something > > > > like > > > > > that. > > > > > > > > > > > > Is this really true? Do you mean we would be tying ourselves to > > > > HTTP > > > > by using a URL as a job ID? > > > > > > > > It would seem that just because we choose the use the syntax and > > > > > semantics of a URL doesn't mean we necessarily tie ourselves to > > > HTTP, > > > > right? > > > > > > > > ...jay > > > >   Received: from cnri by ietf.org id aa21241; 17 Jul 97 20:48 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid UAA14198 for ; Thu, 17 Jul 1997 20:47:43 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA28988 for ; Thu, 17 Jul 1997 20:44:06 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 17 Jul 1997 20:38:45 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA26997 for ipp-outgoing; Thu, 17 Jul 1997 20:18:41 -0400 (EDT) Message-Id: <3.0.1.32.19970717170927.00b6d8c0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 17 Jul 1997 17:09:27 PDT To: Keith Moore From: Carl-Uno Manros Subject: IPP> Re: Munich schedule Cc: ipp@pwg.org In-Reply-To: <199707171855.OAA24340@spot.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 11:55 AM 7/17/97 PDT, you wrote: >Hi. I'm trying to manage the APPS area track while Harald is off >on holiday. I'm trying to make sure I've got a complete list of all >of the outstanding WG and BOF requests. Would you please refresh my >memory, and resend any requests for BOF or WG meeting slots (or >requests for extra slots) that have not yet been confirmed or >appeared in the apps schedule? > >thanks, and sorry for the trouble, > >Keith > Keith, we have got one slot for IPP on Monday, but did ask to have two slots. If there is any chance to get a second slot we are still interested as we have a number of documents that we like to get comments back on. The original agenda was also laid out for two slots. If we only get one slot, we need to shorten the agenda and include the most important subjects from the earlier planned two slots. Regards, Carl-Uno 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   Received: from cnri by ietf.org id aa21363; 17 Jul 97 20:58 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid UAA14208 for ; Thu, 17 Jul 1997 20:57:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA29556 for ; Thu, 17 Jul 1997 20:53:30 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 17 Jul 1997 20:50:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA28829 for ipp-outgoing; Thu, 17 Jul 1997 20:41:47 -0400 (EDT) Message-Id: <3.0.1.32.19970717173241.009aaa10@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 17 Jul 1997 17:32:41 PDT To: Cynthia Clark From: Carl-Uno Manros Subject: IPP> Re: New Internet-Draft Internet Printing Protocol 1.0: Rationale Cc: Harald.T.Alvestrand@uninett.no, Keith Moore , ipp@pwg.org In-Reply-To: <9707171452.aa14906@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: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 11:52 AM 7/17/97 PDT, you wrote: > >Carl-Uno, > >Just for your information, I am currently working on your >Internet-Draft . > >I'll probably send an announcement to the entire IETF >regarding your I-D sometime tomorrow or the next day. > >Please do not hesitate to contact me directly if you have >any question/concern at > >Kind Regards, >Cynthia >------------------------------------------------------ >Cynthia Clark, IETF Internet-Drafts Administrator >E-mail Address preference: >------------------------------------------------------- > > Cynthia, thanks for the information. I understand that you must be very busy right now getting all the documents out before Munich. Unfortunately, we will need to give you newer versions of most of our documents one more time before the July 30 deadline, but as some of them are still in their first incarnation, we are trying to get at least some feedback on the newer documents before we send you the "final" ones towards the end of the month. Our biggest problem is to convert documents written in WinWord to the IETF ASCII format which is a non-trivial task. We are actually just now working on an informational RFC document, which describes the conversion process from WinWord to IETF format step-by-step. This might become one of your most popular documents once it is finished! I hope you realize that some 90 % of the world's desktops and portables have WinWord as an application, and that only UNIX "hackers" can produce the IETF format with relative ease. Time for a rethink in the IETF? Best regards, Carl-Uno 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   Received: from cnri by ietf.org id aa21707; 17 Jul 97 21:25 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid VAA14244 for ; Thu, 17 Jul 1997 21:23:59 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA00382 for ; Thu, 17 Jul 1997 21:20:22 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 17 Jul 1997 21:13:36 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA29753 for ipp-outgoing; Thu, 17 Jul 1997 21:05:52 -0400 (EDT) Message-Id: <3.0.1.32.19970717175648.009a0100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 17 Jul 1997 17:56:48 PDT To: Paul Moore , "'rturner@sharplabs.com'" From: Carl-Uno Manros Subject: RE: IPP> Identifying jobs in requests Cc: 'JK Martin' , ipp@pwg.org In-Reply-To: <41135C785691CF11B73B00805FD4D2D7030F7954@RED-17-MSG.dns.mi crosoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 05:05 PM 7/17/97 PDT, Paul Moore wrote: >Not the issue. I do not object to using URI as job identifiers - I >object to not giving the job identifier in a job specifc request. > >To restate - when I do a canceljob operation I do not supply a job >identifier - the target job is implicit in the transport endpoint - this >ties us to a transport. > Paul, it seems that a lot of this discussion has been people talking past each other, including myself. I fully support your proposal as stated above. On the more general issue that seems to have started up this whole thread of discussion, namely whether a server should be able to suppress certain attributes due to security restrictions, we seem to mix up general model issues with security issues. My take on that problem is the following: 1) Either the Printer is open (non-secure), in which case the server should return all the information. 2) Or the Printer is limiting access through some security restrictions, usually requiring authentication and authorization. In this case, a) the client is either accepted and gets all the information, b) or it does not pass the security check and does not get anything. In consequence, I suggest that there is no half-way house cases where the server would return some, but not all of the information and we should amend the model document to reflect this. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com   Received: from cnri by ietf.org id aa21801; 17 Jul 97 21:31 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid VAA14259 for ; Thu, 17 Jul 1997 21:29:57 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA00903 for ; Thu, 17 Jul 1997 21:26:16 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 17 Jul 1997 21:22:55 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA29828 for ipp-outgoing; Thu, 17 Jul 1997 21:12:08 -0400 (EDT) Date: Thu, 17 Jul 1997 18:11:41 -0700 From: Robert Herriot Message-Id: <199707180111.SAA05525@woden.eng.sun.com> To: paulmo@microsoft.com, rturner@sharplabs.com Subject: Re: IPP> Identifying jobs in requests Cc: jkm@underscore.com, ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I think that we are finally getting to the heart of this issue, namely that the protocol currently puts the URI of the operation's target object in the Request-Line of the HTTP operation, and it is not in the application/ipp message body. I think that I am hearing both Randy and Paul say that they think that the target job or printer URI should be a parameter in the application/ipp message body. Am I right in my understanding? Bob Herriot > From rturner@sharplabs.com Thu Jul 17 17:35:23 1997 > > Paul Moore wrote: > > > Not the issue. I do not object to using URI as job identifiers - I > > object to not giving the job identifier in a job specifc request. > > > > To restate - when I do a canceljob operation I do not supply a job > > identifier - the target job is implicit in the transport endpoint - > > this > > ties us to a transport. > > Ok, I think we're in violent agreement here....I agree that the > operandsof an IPP operation should not be implied by any transport-level > information; > especially if we plan on moving IPP to other transports... > > Randy > > > > > > > > > -----Original Message----- > > > From: Randy Turner [SMTP:rturner@sharplabs.com] > > > Sent: Thursday, July 17, 1997 5:05 PM > > > To: Paul Moore > > > Cc: 'JK Martin'; ipp@pwg.org > > > Subject: Re: IPP> Identifying jobs in requests > > > > > > Paul Moore wrote: > > > > > > > I mean that not using jobids at all (which is what we do at > > present) > > > > ties us to HTTP. > > > > > > In the model document, job identifiers are URLs. If we have pushed > > > URLs > > > out of themain body of the protocol up into the transport layer, > > then > > > this is a mistake. Job identifiers > > > belong within the application/ipp body, and, according to the model > > > document, object > > > identifiers are in URL format. Also, the use of URL/URI strings as > > > object identifiers in > > > and of itself does not tie us to any one transport mechanism. > > > > > > Randy > > > > > > > > > > > > > > > > > > In the current model a cancel job is done by posting a cancel > > > > operation > > > > to the job URL. No job id is sent, it is implied in the transport > > > > endpoint. > > > > > > > > > -----Original Message----- > > > > > From: JK Martin [SMTP:jkm@underscore.com] > > > > > Sent: Thursday, July 17, 1997 1:45 PM > > > > > To: Paul Moore > > > > > Cc: ipp@pwg.org > > > > > Subject: RE: IPP> Identifying jobs in requests > > > > > > > > > > > also using URLs to imply the job id means that we are tied to > > a > > > > > specific > > > > > > transport - something we tried to avoid. If we were to use , > > > say, > > > > > raw IP > > > > > > then you would need to assign an IP port to each job or > > > something > > > > > like > > > > > > that. > > > > > > > > > > > > > > > Is this really true? Do you mean we would be tying ourselves to > > > > > > HTTP > > > > > by using a URL as a job ID? > > > > > > > > > > It would seem that just because we choose the use the syntax and > > > > > > > semantics of a URL doesn't mean we necessarily tie ourselves to > > > > HTTP, > > > > > right? > > > > > > > > > > ...jay > > > > > > > > > >   Received: from cnri by ietf.org id aa22025; 17 Jul 97 21:52 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid VAA14276 for ; Thu, 17 Jul 1997 21:51:07 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA01535 for ; Thu, 17 Jul 1997 21:47:30 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 17 Jul 1997 21:44:13 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA01044 for ipp-outgoing; Thu, 17 Jul 1997 21:37:17 -0400 (EDT) Date: Thu, 17 Jul 1997 18:33:41 -0700 From: Robert Herriot Message-Id: <199707180133.SAA05546@woden.eng.sun.com> To: paulmo@microsoft.com, rturner@sharplabs.com, cmanros@cp10.es.xerox.com Subject: RE: IPP> Identifying jobs in requests Cc: jkm@underscore.com, ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > From cmanros@cp10.es.xerox.com Thu Jul 17 18:17:07 1997 > > 1) Either the Printer is open (non-secure), in which case the server > should return all the information. > > 2) Or the Printer is limiting access through some security restrictions, > usually requiring authentication and authorization. In this case, > > a) the client is either accepted and gets all the information, > b) or it does not pass the security check and does not get anything. > > In consequence, I suggest that there is no half-way house cases where the > server would return some, but not all of the information and we should > amend the model document to reflect this. > I disagree, a secure printer could reveal some but not all information about a job. We have left the degree of information purposely vague so that a Printer can return as little or as much information as it wants based on who is asking. What Paul proposed was that a Printer could not refuse to return a job-uri with Get-Jobs, though it could return a special job-uri that was different from what the job owner might get. Bob Herriot   Received: from cnri by ietf.org id aa22568; 17 Jul 97 22:23 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid WAA14324 for ; Thu, 17 Jul 1997 22:22:00 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA02453 for ; Thu, 17 Jul 1997 22:18:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 17 Jul 1997 22:14:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA01743 for ipp-outgoing; Thu, 17 Jul 1997 22:06:03 -0400 (EDT) Date: Thu, 17 Jul 1997 22:06:10 -0400 (EDT) From: JK Martin Message-Id: <199707180206.WAA27502@uscore.underscore.com> To: Robert.Herriot@eng.sun.com Subject: Re: IPP> Identifying jobs in requests Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Yes, it does appear that we have been in violent agreement all along, that everyone now believes the target job URI must be specified at the IPP protocol layer, regardless of the transport used. It also sounds like we have consensus in support of the proposal by Paul/Bob (that launched this interesting thread). If we could only resolve all IPP issues this quickly! ...jay ----- Begin Included Message ----- From Robert.Herriot@Eng.Sun.COM Thu Jul 17 21:12 EDT 1997 Date: Thu, 17 Jul 1997 18:11:41 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) To: paulmo@microsoft.com, rturner@sharplabs.com Subject: Re: IPP> Identifying jobs in requests Cc: jkm@underscore.com, ipp@pwg.org I think that we are finally getting to the heart of this issue, namely that the protocol currently puts the URI of the operation's target object in the Request-Line of the HTTP operation, and it is not in the application/ipp message body. I think that I am hearing both Randy and Paul say that they think that the target job or printer URI should be a parameter in the application/ipp message body. Am I right in my understanding? Bob Herriot > From rturner@sharplabs.com Thu Jul 17 17:35:23 1997 > > Paul Moore wrote: > > > Not the issue. I do not object to using URI as job identifiers - I > > object to not giving the job identifier in a job specifc request. > > > > To restate - when I do a canceljob operation I do not supply a job > > identifier - the target job is implicit in the transport endpoint - > > this > > ties us to a transport. > > Ok, I think we're in violent agreement here....I agree that the > operandsof an IPP operation should not be implied by any transport-level > information; > especially if we plan on moving IPP to other transports... > > Randy > > > > > > > > > -----Original Message----- > > > From: Randy Turner [SMTP:rturner@sharplabs.com] > > > Sent: Thursday, July 17, 1997 5:05 PM > > > To: Paul Moore > > > Cc: 'JK Martin'; ipp@pwg.org > > > Subject: Re: IPP> Identifying jobs in requests > > > > > > Paul Moore wrote: > > > > > > > I mean that not using jobids at all (which is what we do at > > present) > > > > ties us to HTTP. > > > > > > In the model document, job identifiers are URLs. If we have pushed > > > URLs > > > out of themain body of the protocol up into the transport layer, > > then > > > this is a mistake. Job identifiers > > > belong within the application/ipp body, and, according to the model > > > document, object > > > identifiers are in URL format. Also, the use of URL/URI strings as > > > object identifiers in > > > and of itself does not tie us to any one transport mechanism. > > > > > > Randy > > > > > > > > > > > > > > > > > > In the current model a cancel job is done by posting a cancel > > > > operation > > > > to the job URL. No job id is sent, it is implied in the transport > > > > endpoint. > > > > > > > > > -----Original Message----- > > > > > From: JK Martin [SMTP:jkm@underscore.com] > > > > > Sent: Thursday, July 17, 1997 1:45 PM > > > > > To: Paul Moore > > > > > Cc: ipp@pwg.org > > > > > Subject: RE: IPP> Identifying jobs in requests > > > > > > > > > > > also using URLs to imply the job id means that we are tied to > > a > > > > > specific > > > > > > transport - something we tried to avoid. If we were to use , > > > say, > > > > > raw IP > > > > > > then you would need to assign an IP port to each job or > > > something > > > > > like > > > > > > that. > > > > > > > > > > > > > > > Is this really true? Do you mean we would be tying ourselves to > > > > > > HTTP > > > > > by using a URL as a job ID? > > > > > > > > > > It would seem that just because we choose the use the syntax and > > > > > > > semantics of a URL doesn't mean we necessarily tie ourselves to > > > > HTTP, > > > > > right? > > > > > > > > > > ...jay > > > > > > > > > > ----- End Included Message -----   Received: from cnri by ietf.org id aa29381; 17 Jul 97 23:43 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid XAA14427 for ; Thu, 17 Jul 1997 23:42:40 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA03557 for ; Thu, 17 Jul 1997 23:39:03 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 17 Jul 1997 23:34:44 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA03033 for ipp-outgoing; Thu, 17 Jul 1997 23:27:48 -0400 (EDT) Message-Id: <1.5.4.32.19970718032722.006b0ca0@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: Thu, 17 Jul 1997 20:27:22 -0700 To: JK Martin , Robert.Herriot@eng.sun.com From: Carl-Uno Manros Subject: Re: IPP> Identifying jobs in requests Cc: ipp@pwg.org Sender: ipp-owner@pwg.org At 10:06 PM 7/17/97 -0400, JK Martin wrote: >Yes, it does appear that we have been in violent agreement all along, >that everyone now believes the target job URI must be specified at the >IPP protocol layer, regardless of the transport used. > >It also sounds like we have consensus in support of the proposal >by Paul/Bob (that launched this interesting thread). > >If we could only resolve all IPP issues this quickly! > > ...jay > Hating to spoil the party, but is everybody now clear on which address goes into the HTTP as server address? I am not! Carl-Uno   Received: from cnri by ietf.org id aa01679; 18 Jul 97 4:16 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid EAA14723 for ; Fri, 18 Jul 1997 04:14:42 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id EAA06334 for ; Fri, 18 Jul 1997 04:11:05 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 04:06:29 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA05868 for ipp-outgoing; Fri, 18 Jul 1997 03:59:34 -0400 (EDT) Message-ID: <33CF21B1.6E946DD4@sharplabs.com> Date: Fri, 18 Jul 1997 00:56:33 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.01 [en] (Win95; U) MIME-Version: 1.0 To: Carl-Uno Manros CC: JK Martin , Robert.Herriot@eng.sun.com, ipp@pwg.org Subject: Re: IPP> Identifying jobs in requests X-Priority: 3 (Normal) References: <1.5.4.32.19970718032722.006b0ca0@pop3.holonet.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Carl-Uno Manros wrote: > At 10:06 PM 7/17/97 -0400, JK Martin wrote: > >Yes, it does appear that we have been in violent agreement all along, > > >that everyone now believes the target job URI must be specified at > the > >IPP protocol layer, regardless of the transport used. > > > >It also sounds like we have consensus in support of the proposal > >by Paul/Bob (that launched this interesting thread). > > > >If we could only resolve all IPP issues this quickly! > > > > ...jay > > > > Hating to spoil the party, but is everybody now clear on which address > > goes into the HTTP as server address? I am not! Using URI strings as object identifiers within the application/ipp body does not meanwe cannot take advantage of the use of URI targets and parameters at the transport level. As in the current specification, the same URI specified within the application/ipp body, may or may not be the same URI as specified in the HTTP request and/or response. In the case of the original issue with the CANCEL operation, it could very well be the same URI at both the transport level and within the application/ipp message. IMHO, I think of the CANCEL operation as being applied to a JOB object, so it kinda makes sense to "send a CANCEL message to a JOB object". If we issue a CANCEL operation to the PRINTER object, it doesn't seem very easy to understand, given the object-oriented nature of the model document. Just my $0.02 Randy > > > Carl-Uno   Received: from cnri by ietf.org id aa02061; 18 Jul 97 4:48 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid EAA14771 for ; Fri, 18 Jul 1997 04:46:53 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id EAA07273 for ; Fri, 18 Jul 1997 04:43:14 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 04:37:07 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA06409 for ipp-outgoing; Fri, 18 Jul 1997 04:24:26 -0400 (EDT) Message-ID: <33CF27AE.4FD84514@sharplabs.com> Date: Fri, 18 Jul 1997 01:22:06 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.01 [en] (Win95; U) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> Identifying jobs in requests X-Priority: 3 (Normal) References: <199707180133.SAA05546@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org I agree that the 'getjobs' operation should, at a minimum, return the URI for any and all jobs. I think this statement pretty much stands on its own. The fact that a server may return a secured 'alias' for the actual job URI really wouldn't matter to the protocol or the end-user. I do agree that returning a secured alias would be an interesting way for servers to secure access to jobs from certain classes of end-users. Randy Robert Herriot wrote: > > From cmanros@cp10.es.xerox.com Thu Jul 17 18:17:07 1997 > > > > 1) Either the Printer is open (non-secure), in which case the > server > > should return all the information. > > > > 2) Or the Printer is limiting access through some security > restrictions, > > usually requiring authentication and authorization. In this case, > > > > a) the client is either accepted and gets all the information, > > b) or it does not pass the security check and does not get anything. > > > > > In consequence, I suggest that there is no half-way house cases > where the > > server would return some, but not all of the information and we > should > > amend the model document to reflect this. > > > I disagree, a secure printer could reveal some but not all information > about > a job. We have left the degree of information purposely vague so that > > a Printer can return as little or as much information as it wants > based > on who is asking. > > What Paul proposed was that a Printer could not refuse to return a > job-uri > with Get-Jobs, though it could return a special job-uri that was > different > from what the job owner might get. > > Bob Herriot   Received: from cnri by ietf.org id aa02081; 18 Jul 97 4:48 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid EAA14774 for ; Fri, 18 Jul 1997 04:47:23 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id EAA07336 for ; Fri, 18 Jul 1997 04:43:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 04:37:43 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA06420 for ipp-outgoing; Fri, 18 Jul 1997 04:25:45 -0400 (EDT) Message-ID: <33CF27F8.AADB7C70@sharplabs.com> Date: Fri, 18 Jul 1997 01:23:21 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.01 [en] (Win95; U) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> Identifying jobs in requests X-Priority: 3 (Normal) References: <199707180111.SAA05525@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Robert Herriot wrote: > I think that we are finally getting to the heart of this issue, namely > > that the protocol currently puts the URI of the operation's target > object > in the Request-Line of the HTTP operation, and it is not in the > application/ipp message body. > > I think that I am hearing both Randy and Paul say that they think that > > the target job or printer URI should be a parameter in the > application/ipp > message body. Am I right in my understanding? Yes, this is basically the idea I was agreeing with. > > > Bob Herriot > > > From rturner@sharplabs.com Thu Jul 17 17:35:23 1997 > > > > Paul Moore wrote: > > > > > Not the issue. I do not object to using URI as job identifiers - I > > > > object to not giving the job identifier in a job specifc request. > > > > > > To restate - when I do a canceljob operation I do not supply a job > > > > identifier - the target job is implicit in the transport endpoint > - > > > this > > > ties us to a transport. > > > > Ok, I think we're in violent agreement here....I agree that the > > operandsof an IPP operation should not be implied by any > transport-level > > information; > > especially if we plan on moving IPP to other transports... > > > > Randy > > > > > > > > > > > > > > -----Original Message----- > > > > From: Randy Turner [SMTP:rturner@sharplabs.com] > > > > Sent: Thursday, July 17, 1997 5:05 PM > > > > To: Paul Moore > > > > Cc: 'JK Martin'; ipp@pwg.org > > > > Subject: Re: IPP> Identifying jobs in requests > > > > > > > > Paul Moore wrote: > > > > > > > > > I mean that not using jobids at all (which is what we do at > > > present) > > > > > ties us to HTTP. > > > > > > > > In the model document, job identifiers are URLs. If we have > pushed > > > > URLs > > > > out of themain body of the protocol up into the transport layer, > > > > then > > > > this is a mistake. Job identifiers > > > > belong within the application/ipp body, and, according to the > model > > > > document, object > > > > identifiers are in URL format. Also, the use of URL/URI strings > as > > > > object identifiers in > > > > and of itself does not tie us to any one transport mechanism. > > > > > > > > Randy > > > > > > > > > > > > > > > > > > > > > > > In the current model a cancel job is done by posting a cancel > > > > > operation > > > > > to the job URL. No job id is sent, it is implied in the > transport > > > > > endpoint. > > > > > > > > > > > -----Original Message----- > > > > > > From: JK Martin [SMTP:jkm@underscore.com] > > > > > > Sent: Thursday, July 17, 1997 1:45 PM > > > > > > To: Paul Moore > > > > > > Cc: ipp@pwg.org > > > > > > Subject: RE: IPP> Identifying jobs in requests > > > > > > > > > > > > > also using URLs to imply the job id means that we are tied > to > > > a > > > > > > specific > > > > > > > transport - something we tried to avoid. If we were to use > , > > > > say, > > > > > > raw IP > > > > > > > then you would need to assign an IP port to each job or > > > > something > > > > > > like > > > > > > > that. > > > > > > > > > > > > > > > > > > Is this really true? Do you mean we would be tying > ourselves to > > > > > > > > HTTP > > > > > > by using a URL as a job ID? > > > > > > > > > > > > It would seem that just because we choose the use the syntax > and > > > > > > > > > semantics of a URL doesn't mean we necessarily tie ourselves > to > > > > > HTTP, > > > > > > right? > > > > > > > > > > > > ...jay > > > > > > > > > > > > > > > >   Received: from cnri by ietf.org id aa08096; 18 Jul 97 11:18 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid LAA15670 for ; Fri, 18 Jul 1997 11:17:07 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA08195 for ; Fri, 18 Jul 1997 11:13:30 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 11:05:45 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA07732 for ipp-outgoing; Fri, 18 Jul 1997 10:58:58 -0400 (EDT) Message-ID: <33CF16FB.2713@byas.com> Date: Fri, 18 Jul 1997 07:10:51 +0000 From: AlBrahme X-Mailer: Mozilla 3.0 (Win95; U) MIME-Version: 1.0 To: Scott Isaacson CC: ipp@pwg.org Subject: Re: IPP> ipp & tiff References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Scott Isaacson wrote: > > When you say "The tiff format currently accepted by ipp is too broad" do > you mean that one of the enums for the "document-format" attribute is " > 'langTIFF': 40 - Tagged Image File Format (Aldus)"?? > > If so, please propose a new enum value and describe it (provide its > semantics) and I am sure that it can be added to the list in the Printer MIB > as well as the list in IPP since they are supposed to be the same list!! > > Once you do that, then an instance of an IPP Printer could implement the > "document-formats-supported" attribute and set the value to this new value > that you propose which is in the standard. This is how an "an ipp > server which can accept only a TIFF-F format can convey > this capability information to an ipp client." > > Scott > Thanks for your reply. I propse the following enum for TIFF-F. langTIFF_F (47) -- the Tagged Image File Format adopted for fax (TIFF-F) by ietf_fax working group and specified in the ietf draft published by them thanks /al   Received: from cnri by ietf.org id aa08821; 18 Jul 97 12:02 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid MAA15850 for ; Fri, 18 Jul 1997 12:01:12 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA09760 for ; Fri, 18 Jul 1997 11:57:35 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 11:54:23 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA09314 for ipp-outgoing; Fri, 18 Jul 1997 11:47:33 -0400 (EDT) From: Roger K Debry To: ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: IPP> Review of Model Document - unsupported job template attribut Message-Id: <5030100004981212000002L022*@MHS> Date: Fri, 18 Jul 1997 11:48:56 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org In the latest (July 14th) version of the model document, lines 584- (PDF version w/o revision marks) - 594 read "The client supplies a Job Template attribute and the attribute value is not among the values supported by the Printer: This case depending on the value of the "best-effort" attribute (see section 4.2.8), tIf the client supplies a "best-effort" of 'false' (or supplies no "best-effort" attribute and the printer's default behavior attribute is set to 'false') the Printer SHALL reject the Job and return the 'client-error-attribute-unsupported" error code and the unsupported attribute in the "unsupported attributes" output parameter. If the client supplies a "best-effort" of 'true' (or supplies no "best-effort" attribute and the Printer's default behavior attribute is set to 'true') the printer SHALL accept the Job and substitute supported values for all unsupported values supplied by the client. In this case, if everything else is ok, the Printer returns a "successful-ok" status code. The client must query the newly create Job object to find out if any of the requested values have been modified." 1) When the job is rejected, shouldn't the error code say something like 'client-error-attribute-value-unsupported'? Otherwise it is not clear that the attribute itself is supported, but the supplied value is not. 2) Should the unsupported values be returned as parameters's? 3) As the text currently reads, when substitution occurs, the Printer may choose any supported attribute value that it chooses. Is this is what is intended? I would prefer that the default value be used and the text reflect the same processing as in case 5 (the value is not assigned at job creation, but at job processing time). 4) At one time, I thought we had a status code the said something like "ok-values substituted" for the case where "best-effort" was set to true. This alerts the end user that the ouput may not appear exactly as intended, but is printing anyway. Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080   Received: from cnri by ietf.org id aa09339; 18 Jul 97 12:28 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid MAA15965 for ; Fri, 18 Jul 1997 12:26:44 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA10880 for ; Fri, 18 Jul 1997 12:23:03 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 12:10:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA09848 for ipp-outgoing; Fri, 18 Jul 1997 12:01:37 -0400 (EDT) From: Roger K Debry To: ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: IPP> Validate-Job for print by reference Message-Id: <5030100004982182000002L022*@MHS> Date: Fri, 18 Jul 1997 12:03:01 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org On Wednesday's call there was some discussion of a proposal to add a new operation or a parameter to Validate-Job to handle print by reference. It is not clear to me that we need such an operation. Currently, I believe the function of Validate-Job is to validate the job parameters against Printer capabilities. This should be independent of whether or not the document will be passed or printed by reference. If one wants to test whether or not print-by reference is supported, then he would send a Get-Operations request. If the objective of this new operation is to test whether or not the given URI is valid, i.e. if the Printer can get it, then I am concerned that we are testing a time-dependent variable. I could try the URI at one instant and because of server or network load not be able to get to the document. Furthermore, I could find the document and report back okay only to have the document owner move or delete it before the Print-URI request was sent and operated upon by the Printer. Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080   Received: from cnri by ietf.org id aa09564; 18 Jul 97 12:43 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid MAA16043 for ; Fri, 18 Jul 1997 12:42:11 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA12106 for ; Fri, 18 Jul 1997 12:38:36 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 12:31:00 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA09867 for ipp-outgoing; Fri, 18 Jul 1997 12:07:02 -0400 (EDT) From: Roger K Debry To: ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: IPP>MOD - Job status on Send Document Message-Id: <5030100004982531000002L012*@MHS> Date: Fri, 18 Jul 1997 12:08:24 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Currently the model document says that job status is returned on every Send-Document. It would make more sense only to send this response when the "Last-Document-Flag" is set. I guess if it is simpler to send it every time it is okay, but it seems like a wasted effort. Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080   Received: from cnri by ietf.org id aa10790; 18 Jul 97 13:46 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA16301 for ; Fri, 18 Jul 1997 13:45:41 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA13739 for ; Fri, 18 Jul 1997 13:42:04 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 13:35:34 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA13042 for ipp-outgoing; Fri, 18 Jul 1997 13:24:25 -0400 (EDT) From: Roger K Debry To: ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: IPP>MOD - missing job template attributes Message-Id: <5030100004987715000002L052*@MHS> Date: Fri, 18 Jul 1997 13:25:49 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org As I have been reviewing the model document this morning, I looked to see what typical job properties we can associate with a job in some of our existing systems. There were a few that stood out. I don't recall if there has been discussion of these in our model work or not. If we discussed all of these and rejected them or handled them in some other manner please excuse my forgetfulness -- it's old age! Here are the attributes that I don't see in IPP: Orientation (portrait or landscape) Color (print black and white on a color printer) Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080   Received: from cnri by ietf.org id aa10847; 18 Jul 97 13:49 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA16313 for ; Fri, 18 Jul 1997 13:47:59 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA14055 for ; Fri, 18 Jul 1997 13:44:24 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 13:39:14 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA13053 for ipp-outgoing; Fri, 18 Jul 1997 13:27:24 -0400 (EDT) From: Roger K Debry To: don@lexmark.com MMDF-Warning: Parse error in original version of preceding line at ietf.org Cc: ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: IPP> PWG> Seattle PING Message-Id: <5030100004987943000002L032*@MHS> Date: Fri, 18 Jul 1997 13:28:44 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org I will be attending the IPP meetings. 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 07/18/97 11:23 AM --------------------------- IINUS1.SMTP3 @ D03AU017 07/18/97 10:32 AM Please respond to IINUS1.SMTP3 @ VM To: Roger K Debry/Boulder/IBM cc: Subject: PWG> Seattle PING Received: from lists.underscore.com by vnet.IBM.COM (IBM VM SMTP V2R3) with TCP; Fri, 18 Jul 97 12:30:18 EDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA11399; Fri, 18 Jul 1997 12:29:48 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 12:26:50 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA10332 for pwg-outgoing; Fri, 18 Jul 1997 12:16:08 -0400 (EDT) From: don@lexmark.com Message-Id: <199707181614.AA11348@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: Private_User@lexmark.com, Private_User@lexmark.com, Private_User@lexmark.com, Private_User@lexmark.com, pwg@pwg.org Date: Fri, 18 Jul 1997 12:14:51 -0400 Subject: PWG> Seattle PING Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pwg@pwg.org Blank lines to keep the reflector from rejecting this mail... -- -- -- -- -- Sorry for the cross post but there are still many who do not subscribe to the PWG administrative reflector. If you did not see this post off that reflector, please subscribe immediately. Please send me your PING for the Seattle/Redmond meetings including which meetings you will be attending. Those of you who have already done so, there is no need to re-PING. Don   Received: from ietf.org by ietf.org id aa11033; 18 Jul 97 13:58 EDT Received: from ietf.ietf.org by ietf.org id aa10895; 18 Jul 97 13:51 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ipp@pwg.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipp-rat-00.txt Date: Fri, 18 Jul 1997 13:51:17 -0400 X-Orig-Sender: scoya@ietf.org Message-ID: <9707181351.aa10895@ietf.org> --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 : Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol (IPP) Author(s) : S. Zilles Filename : draft-ietf-ipp-rat-00.txt Pages : 6 Date : 07/17/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. There are multiple parts to IPP, but the primary architectural components are the Model, the Protocol and an interface to Directory Services. This document provides a high level overview of the architecture and provides the rational for the decisions made in structuring the architecture. 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-rat-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-rat-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-rat-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: <19970718133820.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-rat-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-rat-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970718133820.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa12075; 18 Jul 97 14:34 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid OAA16478 for ; Fri, 18 Jul 1997 14:32:45 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA15704 for ; Fri, 18 Jul 1997 14:29:08 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 14:17:27 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA14152 for ipp-outgoing; Fri, 18 Jul 1997 13:52:56 -0400 (EDT) From: Roger K Debry To: ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: IPP>MOD - logfile Message-Id: <5030100004989543000002L032*@MHS> Date: Fri, 18 Jul 1997 13:54:20 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org job-state-reasons has two values that include the notion of a logfile (logfile-pending and logfile-transferring). Yet, I see no description of a logfile elsewhere in the document. Should we formalize the notion of a logfile (I vote no) or do we need to generalize these two values, or maybe remove them? Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080   Received: from cnri by ietf.org id aa12171; 18 Jul 97 14:38 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid OAA16501 for ; Fri, 18 Jul 1997 14:37:02 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA16173 for ; Fri, 18 Jul 1997 14:33:26 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 14:24:05 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA14187 for ipp-outgoing; Fri, 18 Jul 1997 13:57:21 -0400 (EDT) From: Roger K Debry To: ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: IPP>MOD - Mandatory job description attributes Message-Id: <5030100004989845000002L052*@MHS> Date: Fri, 18 Jul 1997 13:58:34 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org I would like to make the following attributes optional. Making these mandatory puts a significant burden on some legacy printing systems upon which we might implement IPP. Furthermore, it is not clear that the information provided in these attributes is of such a critical nature that they should be mandatory. Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080   Received: from cnri by ietf.org id aa12239; 18 Jul 97 14:41 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid OAA16510 for ; Fri, 18 Jul 1997 14:40:01 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA16610 for ; Fri, 18 Jul 1997 14:36:26 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 14:32:25 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA14576 for ipp-outgoing; Fri, 18 Jul 1997 14:09:32 -0400 (EDT) From: Roger K Debry To: ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: IPP>MOD - printe-uri-user and printer-more-info-site Message-Id: <5030100004990458000002L082*@MHS> Date: Fri, 18 Jul 1997 14:10:37 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Do we need both of these attributes, it seems like they do the same thing. If they are different, can someone add more description to the model document so that an implementor knows what to put in each case. The document says that printer-more-info-site can initially be populated by the printer mfgr. Seems odd for site specific information. Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080   Received: from cnri by ietf.org id aa13791; 18 Jul 97 16:04 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA16805 for ; Fri, 18 Jul 1997 16:03:01 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA17341 for ; Fri, 18 Jul 1997 15:59:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 15:50:58 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA16798 for ipp-outgoing; Fri, 18 Jul 1997 15:40:59 -0400 (EDT) Date: Fri, 18 Jul 1997 12:41:42 -0700 From: Robert Herriot Message-Id: <199707181941.MAA06258@woden.eng.sun.com> To: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP>MOD - missing job template attributes X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > From rdebry@us.ibm.com Fri Jul 18 10:39:24 1997 > > As I have been reviewing the model document this morning, > I looked to see what typical job properties we can associate > with a job in some of our existing systems. There were a > few that stood out. I don't recall if there has been discussion > of these in our model work or not. If we discussed all of these > and rejected them or handled them in some other manner > please excuse my forgetfulness -- it's old age! > > Here are the attributes that I don't see in IPP: > > Orientation (portrait or landscape) This is suitable for conversion, e.g. text to PostScript but not for printing PostScript directly. We dropped it when we dropped all text conversion attributes, under the assumption that we would not specify attributes that deal with conversion issues. > > Color (print black and white on a color printer) This is also a conversion issue and was a eliminated for the same reason. Bob Herriot > > >   Received: from cnri by ietf.org id aa13903; 18 Jul 97 16:10 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA16815 for ; Fri, 18 Jul 1997 16:09:29 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA17868 for ; Fri, 18 Jul 1997 16:05:53 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 15:59:04 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA16820 for ipp-outgoing; Fri, 18 Jul 1997 15:45:24 -0400 (EDT) Date: Fri, 18 Jul 1997 12:46:09 -0700 From: Robert Herriot Message-Id: <199707181946.MAA06267@woden.eng.sun.com> To: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP>MOD - Mandatory job description attributes X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Which job-description attributes do you want to be optional? > From rdebry@us.ibm.com Fri Jul 18 11:29:24 1997 > > I would like to make the following attributes optional. > Making these mandatory puts a significant burden on > some legacy printing systems upon which we might > implement IPP. Furthermore, it is not clear that the > information provided in these attributes is of such a > critical nature that they should be mandatory. >   Received: from cnri by ietf.org id aa14005; 18 Jul 97 16:17 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA16851 for ; Fri, 18 Jul 1997 16:16:37 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA18390 for ; Fri, 18 Jul 1997 16:13:01 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 16:07:55 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA17174 for ipp-outgoing; Fri, 18 Jul 1997 15:55:23 -0400 (EDT) Date: Fri, 18 Jul 1997 12:56:02 -0700 From: Robert Herriot Message-Id: <199707181956.MAA06294@woden.eng.sun.com> To: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP> Review of Model Document - unsupported job template attribut X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > From rdebry@us.ibm.com Fri Jul 18 08:58:03 1997 > > > 1) When the job is rejected, shouldn't the error code say something > like 'client-error-attribute-value-unsupported'? Otherwise it is not > clear that the attribute itself is supported, but the supplied value is not. We have one status-code for both 'attribute not supported' and 'attribute value not supported' because a job could be rejected because both problems exist. The collection of unsupported attributes returned specify that it is the attribute that is unsupported by returning the attribute in the response with a value of "unsupported". Note an implementation that rejects a job may return only the first attribute found, or all attributes found or something in between. > > 2) Should the unsupported values be returned as parameters's? > > 3) As the text currently reads, when substitution occurs, the Printer > may choose any supported attribute value that it chooses. Is this > is what is intended? I would prefer that the default value be used > and the text reflect the same processing as in case 5 (the value > is not assigned at job creation, but at job processing time). In an email about simplifying "best-effort" that I will send shortly I will propose that the Printer simply ignore (treat as if not included in the request) any 'attribute not supported' and 'attribute value not supported'. That effectively means the job gets the default value. This makes the solution very simple to implement. > > 4) At one time, I thought we had a status code the said something > like "ok-values substituted" for the case where "best-effort" was > set to true. This alerts the end user that the ouput may not appear > exactly as intended, but is printing anyway. That might be useful information. The Printer could also return an OK status-code with a list of the unsupported attributes as well to give more detail. Bob Herriot   Received: from cnri by ietf.org id aa14233; 18 Jul 97 16:35 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA16935 for ; Fri, 18 Jul 1997 16:34:13 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA18991 for ; Fri, 18 Jul 1997 16:30:37 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 16:21:03 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA18111 for ipp-outgoing; Fri, 18 Jul 1997 16:09:20 -0400 (EDT) Date: Fri, 18 Jul 1997 13:08:35 -0700 From: Robert Herriot Message-Id: <199707182008.NAA06316@woden.eng.sun.com> To: ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP> Identifying jobs in requests X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org So, I think that we are in agreement that the model and protocol documents should state that the operations whose target is a Printer shall include a parameter called printer-uri and operations whose target is a job shall include a parameter called job-uri. Randy suggests that the value of job-uri/printer-uri could differ from the request-uri on the HTTP Request-Line, but the model has no such concept. So unless there are strong arguments to the contrary, the protocol document will state that the request-uri has the same value as the printer-uri/job-uri in the operation. Bob Herriot > From rturner@sharplabs.com Fri Jul 18 01:40:49 1997 > > Robert Herriot wrote: > > > I think that we are finally getting to the heart of this issue, namely > > > > that the protocol currently puts the URI of the operation's target > > object > > in the Request-Line of the HTTP operation, and it is not in the > > application/ipp message body. > > > > I think that I am hearing both Randy and Paul say that they think that > > > > the target job or printer URI should be a parameter in the > > application/ipp > > message body. Am I right in my understanding? > > Yes, this is basically the idea I was agreeing with. > > > > > > > Bob Herriot > > > > > From rturner@sharplabs.com Thu Jul 17 17:35:23 1997 > > > > > > Paul Moore wrote: > > > > > > > Not the issue. I do not object to using URI as job identifiers - I > > > > > > object to not giving the job identifier in a job specifc request. > > > > > > > > To restate - when I do a canceljob operation I do not supply a job > > > > > > identifier - the target job is implicit in the transport endpoint > > - > > > > this > > > > ties us to a transport. > > > > > > Ok, I think we're in violent agreement here....I agree that the > > > operandsof an IPP operation should not be implied by any > > transport-level > > > information; > > > especially if we plan on moving IPP to other transports... > > > > > > Randy > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Randy Turner [SMTP:rturner@sharplabs.com] > > > > > Sent: Thursday, July 17, 1997 5:05 PM > > > > > To: Paul Moore > > > > > Cc: 'JK Martin'; ipp@pwg.org > > > > > Subject: Re: IPP> Identifying jobs in requests > > > > > > > > > > Paul Moore wrote: > > > > > > > > > > > I mean that not using jobids at all (which is what we do at > > > > present) > > > > > > ties us to HTTP. > > > > > > > > > > In the model document, job identifiers are URLs. If we have > > pushed > > > > > URLs > > > > > out of themain body of the protocol up into the transport layer, > > > > > > then > > > > > this is a mistake. Job identifiers > > > > > belong within the application/ipp body, and, according to the > > model > > > > > document, object > > > > > identifiers are in URL format. Also, the use of URL/URI strings > > as > > > > > object identifiers in > > > > > and of itself does not tie us to any one transport mechanism. > > > > > > > > > > Randy > > > > > > > > > > > > > > > > > > > > > > > > > > > > In the current model a cancel job is done by posting a cancel > > > > > > operation > > > > > > to the job URL. No job id is sent, it is implied in the > > transport > > > > > > endpoint. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: JK Martin [SMTP:jkm@underscore.com] > > > > > > > Sent: Thursday, July 17, 1997 1:45 PM > > > > > > > To: Paul Moore > > > > > > > Cc: ipp@pwg.org > > > > > > > Subject: RE: IPP> Identifying jobs in requests > > > > > > > > > > > > > > > also using URLs to imply the job id means that we are tied > > to > > > > a > > > > > > > specific > > > > > > > > transport - something we tried to avoid. If we were to use > > , > > > > > say, > > > > > > > raw IP > > > > > > > > then you would need to assign an IP port to each job or > > > > > something > > > > > > > like > > > > > > > > that. > > > > > > > > > > > > > > > > > > > > > Is this really true? Do you mean we would be tying > > ourselves to > > > > > > > > > > HTTP > > > > > > > by using a URL as a job ID? > > > > > > > > > > > > > > It would seem that just because we choose the use the syntax > > and > > > > > > > > > > > semantics of a URL doesn't mean we necessarily tie ourselves > > to > > > > > > HTTP, > > > > > > > right? > > > > > > > > > > > > > > ...jay > > > > > > > > > > > > > > > > > > > > > > > > > >   Received: from cnri by ietf.org id aa14396; 18 Jul 97 16:45 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA16967 for ; Fri, 18 Jul 1997 16:44:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA19905 for ; Fri, 18 Jul 1997 16:40:40 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 16:34:30 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA18479 for ipp-outgoing; Fri, 18 Jul 1997 16:16:44 -0400 (EDT) Date: Fri, 18 Jul 1997 12:59:05 -0700 From: Robert Herriot Message-Id: <199707181959.MAA06301@woden.eng.sun.com> To: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP> Validate-Job for print by reference X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I'm having second thoughts about this too. The most that the Printer is likely to do is verify that the URL is syntactically OK, but it doesn't verify that the PDL for Print-Job is syntactically OK. I agree with Roger, let's remove document-uri from Validate Job and have it validate attributes and not document-related stuff. > From rdebry@us.ibm.com Fri Jul 18 09:14:40 1997 > > On Wednesday's call there was some discussion of a proposal to add a new > operation > or a parameter to Validate-Job to handle print by reference. It is not clear > to me that we > need such an operation. > > Currently, I believe the function of Validate-Job is to validate the job > parameters against > Printer capabilities. This should be independent of whether or not the > document will be > passed or printed by reference. > > If one wants to test whether or not print-by reference is supported, then he > would send > a Get-Operations request. > > If the objective of this new operation is to test whether or not the given URI > is valid, > i.e. if the Printer can get it, then I am concerned that we are testing a > time-dependent > variable. I could try the URI at one instant and because of server or network > load > not be able to get to the document. Furthermore, I could find the document and > report > back okay only to have the document owner move or delete it before the Print-URI > request was sent and operated upon by the Printer. > > Roger K deBry > Senior Techncial Staff Member > Architecture and Technology > IBM Printing Systems > email: rdebry@us.ibm.com > phone: 1-303-924-4080 >   Received: from cnri by ietf.org id aa14423; 18 Jul 97 16:46 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA16973 for ; Fri, 18 Jul 1997 16:45:10 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA20022 for ; Fri, 18 Jul 1997 16:41:35 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 16:35:34 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA18497 for ipp-outgoing; Fri, 18 Jul 1997 16:18:07 -0400 (EDT) Message-Id: <3.0.1.32.19970718151728.00905360@mailhost.dazel.com> X-Sender: walker@mailhost.dazel.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 18 Jul 1997 15:17:28 -0500 To: Robert Herriot , rdebry@us.ibm.com From: Jim Walker Subject: Re: IPP>MOD - missing job template attributes Cc: ipp@pwg.org In-Reply-To: <199707181941.MAA06258@woden.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 12:41 PM 7/18/97 -0700, Robert Herriot wrote: > >> From rdebry@us.ibm.com Fri Jul 18 10:39:24 1997 >> >> ... >> >> Orientation (portrait or landscape) > >This is suitable for conversion, e.g. text to PostScript but not >for printing PostScript directly. We dropped it when we dropped >all text conversion attributes, under the assumption that we would >not specify attributes that deal with conversion issues. I disagree that `orientation' is not useful for printing PostScript directly... remember that we also support `number-up'. In the case of number-up > 1, orientation can be a very useful hint for ordering the logical pages on a physical page. If you do not believe me, then apply some naive number-up code to a portrait and a landscape document, and look at the results. This is admittably on the low 20% end of the solution scale, but it *is* important as a hint if you are really going to support number-up processing. ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX   Received: from cnri by ietf.org id aa14992; 18 Jul 97 17:17 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA17101 for ; Fri, 18 Jul 1997 17:16:33 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA20617 for ; Fri, 18 Jul 1997 17:12:57 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 17:09:40 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA20170 for ipp-outgoing; Fri, 18 Jul 1997 17:02:49 -0400 (EDT) Date: Fri, 18 Jul 1997 14:03:30 -0700 From: Robert Herriot Message-Id: <199707182103.OAA06373@woden.eng.sun.com> To: Robert.Herriot@eng.sun.com, rdebry@us.ibm.com, walker@dazel.com Subject: Re: IPP>MOD - missing job template attributes Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org If I understand your explanation, the orientation is not to specify that the desired layout of the output, but rather to state how existing pages are already laid out, and that this parameter is only used as a hint to number-up so that it does proper rotation for 2-up. If that is the case, why not just invent some more number-up values, e.g. 2-up-landscape. Then 2-up means 2-up-portrait. Bob Herriot > From walker@dazel.com Fri Jul 18 13:19:02 1997 > > At 12:41 PM 7/18/97 -0700, Robert Herriot wrote: > > > >> From rdebry@us.ibm.com Fri Jul 18 10:39:24 1997 > >> > >> ... > >> > >> Orientation (portrait or landscape) > > > >This is suitable for conversion, e.g. text to PostScript but not > >for printing PostScript directly. We dropped it when we dropped > >all text conversion attributes, under the assumption that we would > >not specify attributes that deal with conversion issues. > > I disagree that `orientation' is not useful for printing PostScript > directly... remember that we also support `number-up'. In the case > of number-up > 1, orientation can be a very useful hint for ordering > the logical pages on a physical page. If you do not believe me, then > apply some naive number-up code to a portrait and a landscape document, > and look at the results. > > This is admittably on the low 20% end of the solution scale, but it *is* > important as a hint if you are really going to support number-up processing. > > ...walker > > -- > Jim Walker > System Architect/DAZEL Wizard > DAZEL Corporation, Austin, TX > >   Received: from cnri by ietf.org id aa15628; 18 Jul 97 17:38 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA17164 for ; Fri, 18 Jul 1997 17:36:49 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA21393 for ; Fri, 18 Jul 1997 17:33:11 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 17:26:50 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA20703 for ipp-outgoing; Fri, 18 Jul 1997 17:15:17 -0400 (EDT) From: Roger K Debry To: ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: Re: IPP>MOD - Mandatory job description attributes Message-Id: <5030100005003436000002L062*@MHS> Date: Fri, 18 Jul 1997 17:16:38 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Woops, The attributes I am concerned with are: time-since-pending time-since-processing time-since-completed number-of-intervening jobs 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 07/18/97 03:10 PM --------------------------- jkm @ underscore.com 07/18/97 02:48 PM Please respond to jkm@underscore.com @ internet To: Roger K Debry/Boulder/IBM cc: Subject: Re: IPP>MOD - Mandatory job description attributes Hi Roger, Did your email message somehow get messed up? I don't see the list of attributes to which you refer in your message. ...jay ----- Begin Included Message ----- From ipp-owner@pwg.org Fri Jul 18 14:26 EDT 1997 From: Roger K Debry To: Subject: IPP>MOD - Mandatory job description attributes Date: Fri, 18 Jul 1997 13:58:34 -0400 I would like to make the following attributes optional. Making these mandatory puts a significant burden on some legacy printing systems upon which we might implement IPP. Furthermore, it is not clear that the information provided in these attributes is of such a critical nature that they should be mandatory. Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 ----- End Included Message -----   Received: from cnri by ietf.org id aa15682; 18 Jul 97 17:40 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA17179 for ; Fri, 18 Jul 1997 17:38:51 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA21705 for ; Fri, 18 Jul 1997 17:35:16 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 17:30:24 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA20722 for ipp-outgoing; Fri, 18 Jul 1997 17:18:12 -0400 (EDT) From: Roger K Debry To: ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: Re: IPP> Review of Model Document - unsupported job template Message-Id: <5030100005003499000002L092*@MHS> Date: Fri, 18 Jul 1997 17:19:32 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org > From rdebry@us.ibm.com Fri Jul 18 08:58:03 1997 > > > 1) When the job is rejected, shouldn't the error code say something > like 'client-error-attribute-value-unsupported'? Otherwise it is not > clear that the attribute itself is supported, but the supplied value is not. We have one status-code for both 'attribute not supported' and 'attribute value not supported' because a job could be rejected because both problems exist. The collection of unsupported attributes returned specify that it is the attribute that is unsupported by returning the attribute in the response with a value of "unsupported". So how do you know it is the value that is unsupported?   Received: from cnri by ietf.org id aa15970; 18 Jul 97 17:54 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA17244 for ; Fri, 18 Jul 1997 17:52:45 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA22245 for ; Fri, 18 Jul 1997 17:49:08 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 17:45:56 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA21775 for ipp-outgoing; Fri, 18 Jul 1997 17:38:57 -0400 (EDT) Message-ID: <33CFDD58.285D@parc.xerox.com> Date: Fri, 18 Jul 1997 14:17:12 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: AlBrahme CC: Scott Isaacson , ipp@pwg.org Subject: Re: IPP> ipp & tiff References: <33CF16FB.2713@byas.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org I suggest that IPP wait until IETF-FAX has actually resolved the TIFF-F vs TIFF-FX issue in a satisfactory manner before baking TIFF-F into IPP. Using enums instead of MIME types for describing media types in an internet protocol is a bit suspect, isn't it? Larry -- http://www.parc.xerox.com/masinter   Received: from cnri by ietf.org id aa16134; 18 Jul 97 18:04 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid SAA17264 for ; Fri, 18 Jul 1997 18:03:36 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA22825 for ; Fri, 18 Jul 1997 17:59:58 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 17:56:40 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA22328 for ipp-outgoing; Fri, 18 Jul 1997 17:49:36 -0400 (EDT) Date: Fri, 18 Jul 1997 14:50:18 -0700 From: Robert Herriot Message-Id: <199707182150.OAA06434@woden.eng.sun.com> To: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP> Review of Model Document - unsupported job template X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > From rdebry@us.ibm.com Fri Jul 18 14:33:31 1997 > > > From rdebry@us.ibm.com Fri Jul 18 08:58:03 1997 > > > > > > 1) When the job is rejected, shouldn't the error code say something > > like 'client-error-attribute-value-unsupported'? Otherwise it is not > > clear that the attribute itself is supported, but the supplied value is not. > > We have one status-code for both 'attribute not supported' and 'attribute value > not supported' because a job could be rejected because both problems exist. > The collection of unsupported attributes returned specify that it is > the attribute that is unsupported by returning the attribute in the _________________________________ > response with a value of "unsupported". ______________ > > So how do you know it is the value that is unsupported? Perhaps, I wasn't sufficiently clear. The 'unsupported attributes' output parameter contains a list of rejected attributes. The printer takes attributes with unsupported values and puts them into the response with no change. The printer takes attributes that are not supported and puts them into the response with their value set to "unsupported" which in the protocol is an "out-of-band" value that works for any type. A printer may put all such attributes in the response, or only some of them. In other words, a Printer can accumulate all unsupported attributes before it rejects the job or it can reject the job immediately after it finds the first bad attribute. > >   Received: from cnri by ietf.org id aa16870; 18 Jul 97 18:53 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid SAA17395 for ; Fri, 18 Jul 1997 18:51:57 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA24957 for ; Fri, 18 Jul 1997 18:48:20 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 18:45:12 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA24509 for ipp-outgoing; Fri, 18 Jul 1997 18:38:18 -0400 (EDT) Message-ID: <41135C785691CF11B73B00805FD4D2D7030F7962@RED-17-MSG.dns.microsoft.com> From: Paul Moore To: "'ipp@pwg.org'" Subject: IPP> Group dinner Date: Fri, 18 Jul 1997 15:38:35 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: ipp-owner@pwg.org Now for a really important topic. I will book tables / private room at 'daniels broiler' in Bellvue (if thats OK for people). One of the finest steak places in the world, on top of 21 floor building, so it has great views too. How about evening of the 6th? Its very popular so I would like to book in advance - so who wants to go? Just to get a rough idea.   Received: from cnri by ietf.org id aa17838; 18 Jul 97 20:12 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid UAA17553 for ; Fri, 18 Jul 1997 20:11:19 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA25940 for ; Fri, 18 Jul 1997 20:07:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 19:58:08 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA25426 for ipp-outgoing; Fri, 18 Jul 1997 19:49:37 -0400 (EDT) Message-Id: <3.0.1.32.19970718164026.00b79350@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 18 Jul 1997 16:40:26 PDT To: Larry Masinter From: Carl-Uno Manros Subject: Re: IPP> ipp & tiff Cc: ipp@pwg.org In-Reply-To: <33CFDD58.285D@parc.xerox.com> References: <33CF16FB.2713@byas.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 02:17 PM 7/18/97 PDT, Larry Masinter wrote: >I suggest that IPP wait until IETF-FAX has actually resolved the TIFF-F >vs TIFF-FX issue in a satisfactory manner before baking TIFF-F into IPP. > >Using enums instead of MIME types for describing media types in an >internet protocol is a bit suspect, isn't it? > >Larry >-- >http://www.parc.xerox.com/masinter Larry, in reply to your last comment, we are proposing to use the enums from the Printer MIB, which is already on the Internet standards track before IPP, using SNMP as protocol, so it is only a matter of which Internet standard we align with. The majority of the people active in the PWG and IPP has seen alignment with the Printer MIB and Job Monitoring MIB as more important than with MIME, which has led to the current proposal. 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   Received: from cnri by ietf.org id aa17985; 18 Jul 97 20:22 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid UAA17563 for ; Fri, 18 Jul 1997 20:21:23 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA26688 for ; Fri, 18 Jul 1997 20:17:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 20:11:45 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA25445 for ipp-outgoing; Fri, 18 Jul 1997 19:55:04 -0400 (EDT) Message-ID: <41135C785691CF11B73B00805FD4D2D7030F7964@RED-17-MSG.dns.microsoft.com> From: Paul Moore To: "'ipp@pwg.org'" Subject: IPP> Dinner Date: Fri, 18 Jul 1997 16:55:17 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: ipp-owner@pwg.org The largest group they can do is 18 - so I have booked that. So the first 17 (I get to go too!) that reply will get places.   Received: from cnri by ietf.org id aa18012; 18 Jul 97 20:24 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid UAA17575 for ; Fri, 18 Jul 1997 20:23:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA26971 for ; Fri, 18 Jul 1997 20:19:40 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 20:14:40 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA25503 for ipp-outgoing; Fri, 18 Jul 1997 19:58:53 -0400 (EDT) Message-Id: <3.0.1.32.19970718164937.00b6fb30@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 18 Jul 1997 16:49:37 PDT To: don@lexmark.com, ipp@pwg.org From: Carl-Uno Manros Subject: IPP> REQ - Final Editorial round for the Requirements document Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Hi, I am behind schedule with the editing of the Requirements documents. As I will be on vacation next week, Don has kindly offered to take back the editing so it gets done in time. If there are any further comments in addition to those earlier circulated on the list from Peter Zehler and Roger deBry, now is the time to submit them! FYI, I will be leading the phone conference on Wednesday. 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   Received: from cnri by ietf.org id aa18361; 18 Jul 97 20:51 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid UAA17639 for ; Fri, 18 Jul 1997 20:50:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA27528 for ; Fri, 18 Jul 1997 20:46:26 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 20:43:14 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA27072 for ipp-outgoing; Fri, 18 Jul 1997 20:36:19 -0400 (EDT) Message-Id: <3.0.1.32.19970718172703.00accb50@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 18 Jul 1997 17:27:03 PDT To: rdebry@us.ibm.com From: Carl-Uno Manros Subject: IPP> SEC - Some more editing comments on Security draft Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Roger, here are my additional comments as promissed: Editorial comments on the Security draft from July 15 ===================================================== TOC The lines for 5.9 and 5.10 are not aligned with the rest of the TOC. Section 5.10 - I already gave you some advice on how to get rid of the issue, by stating that a corresponding security level (but probably not identical) should be used as for the submission of the job. Section 6.0 - We need to add more references here for: TLS, PGP/MIME, S/MIME, SHHTP, IPSec. I would drop PEM and MOSS from this text, we do not seem to have any interest in them at all and they now seem to be only of historic value. Under IPSec, 4th line from the end, you have "use user". Cross out "use". 6.2 Firewall Considerations - add blank line after the heading. Change "posts" to "POSTs" 7.0 References - there are a number of unexplained underscores - delete. Fix "elkins" to "Elkins" in RFC2015 reference. Some reference names are capitalized and others are small letters, eg. we have "RFC" and sometimes "rfc" in reference names. Make consistent throughout the document. Use same style as the Model document (whichever that is). Find and add references for standards indicated above for section 6.0. --- 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   Received: from cnri by ietf.org id aa25192; 18 Jul 97 23:04 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid XAA17800 for ; Fri, 18 Jul 1997 23:03:11 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA28346 for ; Fri, 18 Jul 1997 22:59:32 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 22:46:22 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA27756 for ipp-outgoing; Fri, 18 Jul 1997 22:30:36 -0400 (EDT) Date: Fri, 18 Jul 1997 19:31:23 -0700 From: Robert Herriot Message-Id: <199707190231.TAA06663@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD Issue with Conditionally Mandatory X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I have a concern about the concept of conditionally-mandatory which applies to all job template attributes. I think it doesn't really help us understand what a conforming implementation must implement. After writing the paragraphs below, I have concluded that job-template attributes should all be optional, and we should drop the "conditionally mandatory" term. At the very least, they have to be optional for print servers. There may be some argument for making some of them conditionally mandatory in embedded printers, but the extra complexity of the explanation may not be worth the trouble. We all need to give this issue some more thought. As long as the explanation is so murky, I don't think any two people would come up with the same list of mandatory attributes for an implementation and that is no better than making them optional   Received: from cnri by ietf.org id aa25911; 18 Jul 97 23:13 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid XAA17806 for ; Fri, 18 Jul 1997 23:11:53 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA29469 for ; Fri, 18 Jul 1997 23:08:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 22:58:40 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA27771 for ipp-outgoing; Fri, 18 Jul 1997 22:34:13 -0400 (EDT) Date: Fri, 18 Jul 1997 19:34:58 -0700 From: Robert Herriot Message-Id: <199707190234.TAA06675@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD Issue with best-effort X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Scott and I have discussed the best-effort job attribute and we both agree that this doesn't fit as a Job- Template attribute. The printer attribute best-effort-supported doesn't fit the job template model very well. I suggest that it become an optional parameter to Print-Job, Print-URI, Create-Job, and Validate-Job and that it be renamed to `may-ignore-attributes' to reflect its new meaning. If it is omitted in these operations, it has a value of false. All implementations must support both values of this parameter. It seems to me that this is not much of a requirement because very implementation has to check if it supports an attribute and each value. If the answer is yes, the value of may-ignore-attributes doesn't matter. If it is no and may-ignore-attributes is false, the job is rejected and the offending attribute returned in the response ( the current required mechanism). If it is no and may-ignore-attributes is true, I propose that the Printer ignore the attribute not to add it to the job, which means the default behavior takes hold (the new very-simple mechanism). There should be an OPTIONAL job attribute may-ignore-attributes which is set by the parameter may- ignore-attributes. This attribute is MANDATORY if Create-Job is supported because Send-Document and Send-URI use the value set by Create-Job. Otherwise, I wouldn't expect it to be implemented. It would be useful in a future resubmit-job operation The following is the change in wording that I propose for rules 3 and 4 in section 3.1.2.1 Print-Job Request: 3. The client supplies a Job Template attribute and either the attribute is not supported by the Printer or the attribute value is not among the values supported by the Printer: The value of the "may-ignore- attributes" parameter determines the Printer's behavior. 3a. The client supplies no "may-ignore-attributes" parameter, or supplies a "may-ignore- attributes" parameter of 'false': the Printer SHALL reject the Job. It SHALL return the 'client- error-attribute-unsupported" error code and the unsupported attribute in the "unsupported attributes " output parameter. If it is the attribute value that is unsupported, the attribute in the unsupported attributes output parameter SHALL be exactly as received in the request. If it is the attribute itself that is unsupported, the attribute in the `unsupported attributes' output parameter SHALL have the name as received in the request, but its value SHALL be "unsupported". If a job contains more than one unsupported attribute or attribute value that cause a job to be rejected, a Printer may return all of them, some of them, or only one of them in the `unsupported attributes' output parameter. Note: in the Send-Document or Send-URI operation, the document and not the job is rejected, and if the last-document flag is true, it is treated as if it were false so that the client can resubmit the document. 3b. The client supplies a "may-ignore-attributes" of 'true': the Printer SHALL continue accepting the Job but ignore the attribute and not associate it with the new Job object. The Printer's default value effectively becomes the value of this attribute (see rule 4 below). In this case, if everything else is ok, the Printer SHALL return a "successful-attributes-ignored" status code along an optional complete list of ignored attributes in the `unsupported attributes' output parameter. Job-name Job-name, like best-effort, doesn't fit in the job-template section. For example, it alone is mandatory and it alone has no xxx-supported attribute. It also has special rules for setting its value because it has no default. I suggest that it become a parameter to Print-Job, Print-URI, Create-Job and Validate-Job and become a job-description attribute where there are several mandatory attributes. The description for the job attribute can contain all the rules for how a printer sets its value, i.e. from the parameter, or the document-name or from an implementation defined value, in that order of precedence.   Received: from cnri by ietf.org id aa25947; 18 Jul 97 23:14 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid XAA17809 for ; Fri, 18 Jul 1997 23:13:23 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA29711 for ; Fri, 18 Jul 1997 23:09:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 23:01:19 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA27791 for ipp-outgoing; Fri, 18 Jul 1997 22:35:48 -0400 (EDT) Date: Fri, 18 Jul 1997 19:36:25 -0700 From: Robert Herriot Message-Id: <199707190236.TAA06680@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD Issue with localization X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Should we a make statement about which attributes should be localized. I would expect the text attributes set by the manufacturer would be localized. They are: job-state-message , printer-more-info-manufacturer, printer-state-message, and printer-make-and-model. I would expect text attribute set by a site would not be localized. They are job-message-from-operator, printer-location, printer-description, printer-message- from-the-operator If we agree with the first paragraph, should there be a separate text type called localized-text for the 4 attributes mentioned in the previous issue that can be localized. The status-message parameter would also have this type, as would notification messages. Unless we do something, the localization issue is left very vague.   Received: from cnri by ietf.org id aa25974; 18 Jul 97 23:15 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid XAA17812 for ; Fri, 18 Jul 1997 23:14:18 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA29839 for ; Fri, 18 Jul 1997 23:10:41 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 23:02:26 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA27804 for ipp-outgoing; Fri, 18 Jul 1997 22:37:16 -0400 (EDT) Date: Fri, 18 Jul 1997 19:37:51 -0700 From: Robert Herriot Message-Id: <199707190237.TAA06686@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD Issue with conformance X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I have suggested adding the following paragraphs to the model document on conformance in various parts of the conformance section: A conforming client SHALL send operations that conform to the protocol defined in "Internet Printing Protocol/1.0: Protocol Specification" [23]. For each parameter or attribute included in an operation request, a conforming client SHALL send a value whose type and value syntax conforms to the requirement of this document Conforming Printer implementations SHALL support all request and response parameters and all values of such parameters, except for parameters which are collections of attributes. The following section on attributes specifies the support required for attributes. If a Printer implements an attribute, it SHALL support only those values specified in this document or through the extension mechanism described in the next section. It MAY support any non-empty subset of these values. That is, it SHALL support at least one of the specified values and at most all of them. A conforming printer SHALL send responses that conform to the protocol defined in "Internet Printing Protocol/1.0: Protocol Specification" [23]. For each parameter or attribute included in an operation response, a conforming printer SHALL send a value whose type and value syntax conforms to the requirement of this document   Received: from cnri by ietf.org id aa27200; 19 Jul 97 0:12 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid AAA17852 for ; Sat, 19 Jul 1997 00:11:29 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA00606 for ; Sat, 19 Jul 1997 00:07:52 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 19 Jul 1997 00:02:07 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA00081 for ipp-outgoing; Fri, 18 Jul 1997 23:55:08 -0400 (EDT) Message-ID: <33CFCCA4.66C9@byas.com> Date: Fri, 18 Jul 1997 20:05:57 +0000 From: AlBrahme X-Mailer: Mozilla 3.0 (Win95; U) MIME-Version: 1.0 To: Larry Masinter CC: Scott Isaacson , ipp@pwg.org Subject: Re: IPP> ipp & tiff References: <33CF16FB.2713@byas.com> <33CFDD58.285D@parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Larry Masinter wrote: > > I suggest that IPP wait until IETF-FAX has actually resolved the TIFF-F > vs TIFF-FX issue in a satisfactory manner before baking TIFF-F into IPP. > > Using enums instead of MIME types for describing media types in an > internet protocol is a bit suspect, isn't it? > > Larry I rather suggest that we put the enum for TIFF-F now and we can add another for TIFF-FX now, or later if it wins. I am in the process of implementing an IPP prototype and i think getting a product out now is more important than delaying. Since I think fax over internet is going to be major use of ipp (forget about Kinko's etc.. they will be nothing compared to fax over internet) it is important for IPP to get this fax friendly feature early. /al   Received: from cnri by ietf.org id aa11001; 19 Jul 97 15:36 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid PAA18487 for ; Sat, 19 Jul 1997 15:35:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA02729 for ; Sat, 19 Jul 1997 15:31:42 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 19 Jul 1997 15:25:27 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA02254 for ipp-outgoing; Sat, 19 Jul 1997 15:18:30 -0400 (EDT) Message-ID: <33D112FF.2AA7@parc.xerox.com> Date: Sat, 19 Jul 1997 12:18:23 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: AlBrahme CC: ipp@pwg.org Subject: IPP> ipp & tiff References: <33CF16FB.2713@byas.com> <33CFDD58.285D@parc.xerox.com> <33CFCCA4.66C9@byas.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org > Since I think fax over internet is going to be major use > of ipp (forget about Kinko's etc.. they will be nothing compared to fax > over internet) it is important for IPP to get this fax friendly feature > early. What leads you to believe that fax over Internet is going to be a major use of IPP? It's not part of the scenarios or rationale document.   Received: from cnri by ietf.org id aa11498; 19 Jul 97 16:23 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA18566 for ; Sat, 19 Jul 1997 16:22:09 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA03288 for ; Sat, 19 Jul 1997 16:18:34 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 19 Jul 1997 16:15:21 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA02837 for ipp-outgoing; Sat, 19 Jul 1997 16:08:23 -0400 (EDT) Date: Sat, 19 Jul 1997 13:11:41 PDT From: Ira Mcdonald x10962 Message-Id: <9707192011.AA13916@snorkel.eso.mc.xerox.com> To: Robert.Herriot@eng.sun.com, ipp@pwg.org Subject: Re: IPP>MOD Issue with localization Sender: ipp-owner@pwg.org Hi Bob, Why would you expect the values set by the site NOT to be localized (ie, to have their character set and language, while static from device install, declared and available to remote monitoring and client applications). Cheers, - Ira McDonald PS - This business of the declared 'cooperative' locale of management stations and on-system management agents (or IPP print servers) is what Tom Hastings, Angelo Caruso, and I have been trying to clarify since early April for the Printer MIB v2 - at present, all strings which are NOT localized are forced to 7-bit US-ASCII - in IPP they would be forced to UTF-8 (by default), but for environments where the ISO 8859-n or ISO 2020 (2022, oops) character sets are more appropriate, there is no reason to preclude in IPP having a printer attribute which is the declared 'cooperative' static locale for other text strings - or as Tom Hastings has suggested for the Job Mon MIB, the dynamic (usser specified) locale for remotely supplied strings in a job specification. ------------------------------------------------------------- From ipp-owner@pwg.org Fri Jul 18 23:13:43 1997 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA13815; Fri, 18 Jul 97 23:13:43 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA22669; Fri, 18 Jul 97 23:10:30 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <51920(3)>; Fri, 18 Jul 1997 20:10:36 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA29253 for ; Fri, 18 Jul 1997 23:06:43 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 23:01:19 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA27791 for ipp-outgoing; Fri, 18 Jul 1997 22:35:48 -0400 (EDT) Date: Fri, 18 Jul 1997 19:36:25 PDT From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199707190236.TAA06680@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD Issue with localization X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Status: R Should we a make statement about which attributes should be localized. I would expect the text attributes set by the manufacturer would be localized. They are: job-state-message , printer-more-info-manufacturer, printer-state-message, and printer-make-and-model. I would expect text attribute set by a site would not be localized. They are job-message-from-operator, printer-location, printer-description, printer-message- from-the-operator If we agree with the first paragraph, should there be a separate text type called localized-text for the 4 attributes mentioned in the previous issue that can be localized. The status-message parameter would also have this type, as would notification messages. Unless we do something, the localization issue is left very vague.   Received: from cnri by ietf.org id aa14234; 19 Jul 97 20:31 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid UAA18792 for ; Sat, 19 Jul 1997 20:29:54 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA04139 for ; Sat, 19 Jul 1997 20:26:18 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 19 Jul 1997 20:21:31 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA03671 for ipp-outgoing; Sat, 19 Jul 1997 20:14:33 -0400 (EDT) Date: Sat, 19 Jul 1997 20:14:44 -0400 (EDT) From: JK Martin Message-Id: <199707200014.UAA07138@uscore.underscore.com> To: Robert.Herriot@eng.sun.com Subject: Re: IPP>MOD Issue with best-effort Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Bob, Sometimes I get lost in a sea of words, at which point I drown before I fully grasp the point. Regarding "best-effort", are the following statements consistent with what you and Scott are proposing? 1) Conceptually, "best-effort" is the way for a client to tell the IPP server to print the document(s) "the best way that it can", given the specified job attributes. 2) When the client indicates "best-effort", the server is free to ignore any attribute it either does not recognize, or is invalid in some way. 3) When the client indicates "best-effort", the server is free to ignore any attribute having a value that is invalid in some way. 4) The "best-effort" parameter is used only during job submission; that is, it may only appear within a Print-Job, Print-URI, Create-Job or Validate-Job operation. 5) The "best-effort" parameter is always an optional parameter; if absent in the operation, the implied value is "false". Do these statements accurately sum up the proposal, or is something missing or incorrect? ...jay ----- Begin Included Message ----- From ipp-owner@pwg.org Fri Jul 18 23:01 EDT 1997 Date: Fri, 18 Jul 1997 19:34:58 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) To: ipp@pwg.org Subject: IPP>MOD Issue with best-effort Scott and I have discussed the best-effort job attribute and we both agree that this doesn't fit as a Job- Template attribute. The printer attribute best-effort-supported doesn't fit the job template model very well. I suggest that it become an optional parameter to Print-Job, Print-URI, Create-Job, and Validate-Job and that it be renamed to `may-ignore-attributes' to reflect its new meaning. If it is omitted in these operations, it has a value of false. All implementations must support both values of this parameter. It seems to me that this is not much of a requirement because very implementation has to check if it supports an attribute and each value. If the answer is yes, the value of may-ignore-attributes doesn't matter. If it is no and may-ignore-attributes is false, the job is rejected and the offending attribute returned in the response ( the current required mechanism). If it is no and may-ignore-attributes is true, I propose that the Printer ignore the attribute not to add it to the job, which means the default behavior takes hold (the new very-simple mechanism). There should be an OPTIONAL job attribute may-ignore-attributes which is set by the parameter may- ignore-attributes. This attribute is MANDATORY if Create-Job is supported because Send-Document and Send-URI use the value set by Create-Job. Otherwise, I wouldn't expect it to be implemented. It would be useful in a future resubmit-job operation The following is the change in wording that I propose for rules 3 and 4 in section 3.1.2.1 Print-Job Request: 3. The client supplies a Job Template attribute and either the attribute is not supported by the Printer or the attribute value is not among the values supported by the Printer: The value of the "may-ignore- attributes" parameter determines the Printer's behavior. 3a. The client supplies no "may-ignore-attributes" parameter, or supplies a "may-ignore- attributes" parameter of 'false': the Printer SHALL reject the Job. It SHALL return the 'client- error-attribute-unsupported" error code and the unsupported attribute in the "unsupported attributes " output parameter. If it is the attribute value that is unsupported, the attribute in the unsupported attributes output parameter SHALL be exactly as received in the request. If it is the attribute itself that is unsupported, the attribute in the `unsupported attributes' output parameter SHALL have the name as received in the request, but its value SHALL be "unsupported". If a job contains more than one unsupported attribute or attribute value that cause a job to be rejected, a Printer may return all of them, some of them, or only one of them in the `unsupported attributes' output parameter. Note: in the Send-Document or Send-URI operation, the document and not the job is rejected, and if the last-document flag is true, it is treated as if it were false so that the client can resubmit the document. 3b. The client supplies a "may-ignore-attributes" of 'true': the Printer SHALL continue accepting the Job but ignore the attribute and not associate it with the new Job object. The Printer's default value effectively becomes the value of this attribute (see rule 4 below). In this case, if everything else is ok, the Printer SHALL return a "successful-attributes-ignored" status code along an optional complete list of ignored attributes in the `unsupported attributes' output parameter. Job-name Job-name, like best-effort, doesn't fit in the job-template section. For example, it alone is mandatory and it alone has no xxx-supported attribute. It also has special rules for setting its value because it has no default. I suggest that it become a parameter to Print-Job, Print-URI, Create-Job and Validate-Job and become a job-description attribute where there are several mandatory attributes. The description for the job attribute can contain all the rules for how a printer sets its value, i.e. from the parameter, or the document-name or from an implementation defined value, in that order of precedence. ----- End Included Message -----   Received: from cnri by ietf.org id aa07594; 21 Jul 97 9:57 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid JAA20703 for ; Mon, 21 Jul 1997 09:56:20 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA08037 for ; Mon, 21 Jul 1997 09:52:42 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 21 Jul 1997 09:38:23 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA07581 for ipp-outgoing; Mon, 21 Jul 1997 09:31:20 -0400 (EDT) From: Roger K Debry To: ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: Re: IPP> Review of Model Document - unsupported job template Message-Id: <5030100005065696000002L062*@MHS> Date: Mon, 21 Jul 1997 09:33:01 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Perhaps, I wasn't sufficiently clear. The 'unsupported attributes' output parameter contains a list of rejected attributes. The printer takes attributes with unsupported values and puts them into the response with no change. The printer takes attributes that are not supported and puts them into the response with their value set to "unsupported" which in the protocol is an "out-of-band" value that works for any type. A printer may put all such attributes in the response, or only some of them. In other words, a Printer can accumulate all unsupported attributes before it rejects the job or it can reject the job immediately after it finds the first bad attribute. The document certainly does not say this! Let me be sure I understand. Lets say that two attributes are sent, one which is supported but its value is not, and one which is unsupported: o finishing = saddle-stitch (unsupported value) o number-up = two (unsupported attribute) If I understand correctly, the response would contain the following unsupported attributes: o finishing = saddle-stitch o number-up = unsupported Right? I don't agree with it being optional for the printer to return only a partial list of unsupported attributes as you suggest. How does the client know what's wrong if the Printer does not have to send back accurate error information? If everyone else agrees with this being optional then it should be made clear in the document ... currently I don't believe it makes this clear at all. I read it as saying the entire list is sent back.   Received: from cnri by ietf.org id aa08062; 21 Jul 97 10:08 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid KAA20767 for ; Mon, 21 Jul 1997 10:07:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA08563 for ; Mon, 21 Jul 1997 10:03:30 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 21 Jul 1997 10:00:18 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA08083 for ipp-outgoing; Mon, 21 Jul 1997 09:53:10 -0400 (EDT) From: Roger K Debry To: Ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: IPP>MOD - best effort Message-Id: <5030100005066621000002L012*@MHS> Date: Mon, 21 Jul 1997 09:54:56 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org >There should be an OPTIONAL job attribute may-ignore-attributes which >is set by the parameter may- ignore-attributes. This attribute is >MANDATORY if Create-Job is supported because Send-Document and Send-URI >use the value set by Create-Job. Otherwise, I wouldn't expect it to be >implemented. It would be useful in a future resubmit-job operation Now let me see, if I understand .... we don't like the concept of best-effort as an attribute, so we rename it, make it a parameter, then add an optional job attribute with the same name, and then have the parameter set the attribute, except sometimes the attribute (or is it the parameter) is mandatory. Did I get it right?????? Excuse me, but I think we just added a ton of confusion and didn't change things one bit!   Received: from cnri by ietf.org id aa08646; 21 Jul 97 10:33 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid KAA20873 for ; Mon, 21 Jul 1997 10:31:52 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA09138 for ; Mon, 21 Jul 1997 10:28:11 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 21 Jul 1997 10:24:59 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA08698 for ipp-outgoing; Mon, 21 Jul 1997 10:18:00 -0400 (EDT) From: jwong Message-Id: <199707211418.KAA07265@buzz.xionics.com> Subject: Re: IPP> Group dinner To: Paul Moore Date: Mon, 21 Jul 1997 10:18:05 -0400 (EDT) Cc: ipp@pwg.org In-Reply-To: <41135C785691CF11B73B00805FD4D2D7030F7962@RED-17-MSG.dns.microsoft.com> from "Paul Moore" at Jul 18, 97 03:38:35 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org > > Now for a really important topic. > > I will book tables / private room at 'daniels broiler' in Bellvue (if > thats OK for people). One of the finest steak places in the world, on > top of 21 floor building, so it has great views too. > > How about evening of the 6th? > > Its very popular so I would like to book in advance - so who wants to > go? Just to get a rough idea. > Sounds good, I would love to go. Jasper | Senior Software Engineer | Xionics Document Technologies, Inc. | Email: jwong@xionics.com | Phone: (617)229-7165   Received: from cnri by ietf.org id aa09721; 21 Jul 97 11:10 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid LAA21012 for ; Mon, 21 Jul 1997 11:08:43 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA09714 for ; Mon, 21 Jul 1997 11:05:05 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 21 Jul 1997 10:54:44 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA09236 for ipp-outgoing; Mon, 21 Jul 1997 10:47:45 -0400 (EDT) Date: Mon, 21 Jul 1997 10:48:01 -0400 (EDT) From: JK Martin Message-Id: <199707211448.KAA21353@uscore.underscore.com> To: ipp@pwg.org Subject: Re: IPP>MOD - best effort X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I completely agree with Roger. I just don't see the added value here...but I certainly see the additional complexity and resulting confusion. There is nothing wrong (semantically) with "best-effort". Let's leave it alone, but make the obvious clarifications in the Model document with regard to Job templates, etc. ...jay ----- Begin Included Message ----- From ipp-owner@pwg.org Mon Jul 21 10:01 EDT 1997 From: Roger K Debry To: Subject: IPP>MOD - best effort Date: Mon, 21 Jul 1997 09:54:56 -0400 >There should be an OPTIONAL job attribute may-ignore-attributes which >is set by the parameter may- ignore-attributes. This attribute is >MANDATORY if Create-Job is supported because Send-Document and Send-URI >use the value set by Create-Job. Otherwise, I wouldn't expect it to be >implemented. It would be useful in a future resubmit-job operation Now let me see, if I understand .... we don't like the concept of best-effort as an attribute, so we rename it, make it a parameter, then add an optional job attribute with the same name, and then have the parameter set the attribute, except sometimes the attribute (or is it the parameter) is mandatory. Did I get it right?????? Excuse me, but I think we just added a ton of confusion and didn't change things one bit! ----- End Included Message -----   Received: from cnri by ietf.org id aa22183; 21 Jul 97 17:28 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA21668 for ; Mon, 21 Jul 1997 17:26:43 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA13602 for ; Mon, 21 Jul 1997 16:47:33 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 21 Jul 1997 16:40:00 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA11954 for ipp-outgoing; Mon, 21 Jul 1997 16:23:54 -0400 (EDT) Mime-Version: 1.0 Date: Mon, 21 Jul 1997 16:22:59 -0400 Message-ID: <00019119.3036@okidata.com> From: Philip Thambidurai Subject: IPP> Appendix-B of Protocol document 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 Exactly why is Appendix-B "Reqmts. without HTTP 1.1 as a Transport Layer" necessary? Isn't it always assumed that HTTP/1.1 is the only transport layer that should be used? Philip Thambidurai   Received: from cnri by ietf.org id aa22236; 21 Jul 97 17:30 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA21697 for ; Mon, 21 Jul 1997 17:29:05 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA14262 for ; Mon, 21 Jul 1997 17:17:03 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 21 Jul 1997 17:10:13 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA13731 for ipp-outgoing; Mon, 21 Jul 1997 17:03:03 -0400 (EDT) Date: Mon, 21 Jul 1997 14:03:35 -0700 From: Robert Herriot Message-Id: <199707212103.OAA09139@woden.eng.sun.com> To: ipp@pwg.org, jkm@underscore.com, rdebry@us.ibm.com Subject: Re: IPP>MOD - best effort X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org There is plenty wrong with best-effort. Perhaps you didn't read the fine print in the current model document. It is currently defined as a job template attribute which means: o there is a job attribute "best-effort" for specifying what the client wants. o there is a printer default "best-effort" which says whether the printer defaults it behavior to best-effort or not if a client doesn't specify this attribute. o there is a printer "best-effort-supported" attribute which is unlike most xxx-supported attributes. It is not a set of possible values, namely "true" and "false" values. Instead, it is either "true" or "false" * "true" means that a client can specify either the value "true" or "false" or and the printer default "best-effort" can have the value of true or false" * "false" means that a client can specify only the value of "false" and the default "best-effort" can have only the value of "false". NOTE: it is believed that no implementation would support a "best-effort" job attribute of "true" only. o this attribute has to be processed before others are processed because it affects the processing of them, but it need not be the first attribute. o the "best-effort" substitution is somewhat undefined and potentially complex. Compare the above with what I proposed: o I replace 3 job-template attributes by a single parameter "may-ignored-attributes" which is either true, false or omitted (false is default). All printers support both values because it is easier to support "best-effort" as "ignore the attribute". o I make it easy to process the "may-ignore-attributes" value before any attributes are processed because the information is in the parameter section which precedes any attributes. Now I suggest that we forget about "may-ignore-attributes" job attribute, that I proposed. It really isn't necessary and deflects from the discussion. The single parameter is sufficient. Do you still believe that the "3 job-template attributes" proposal is simpler than the "single parameter" proposal? Bob Herriot > From jkm@underscore.com Mon Jul 21 07:58:51 1997 > > I completely agree with Roger. I just don't see the added value > here...but I certainly see the additional complexity and resulting > confusion. > > There is nothing wrong (semantically) with "best-effort". Let's > leave it alone, but make the obvious clarifications in the Model > document with regard to Job templates, etc. > > ...jay > > ----- Begin Included Message ----- > > From ipp-owner@pwg.org Mon Jul 21 10:01 EDT 1997 > From: Roger K Debry > To: > Subject: IPP>MOD - best effort > Date: Mon, 21 Jul 1997 09:54:56 -0400 > > >There should be an OPTIONAL job attribute may-ignore-attributes which > >is set by the parameter may- ignore-attributes. This attribute is > >MANDATORY if Create-Job is supported because Send-Document and Send-URI > >use the value set by Create-Job. Otherwise, I wouldn't expect it to be > >implemented. It would be useful in a future resubmit-job operation > > Now let me see, if I understand .... we don't like the concept of > best-effort as an attribute, so we rename it, make it a parameter, then > add an optional job attribute with the same name, and then have the > parameter set the attribute, except sometimes the attribute (or is it > the parameter) is mandatory. Did I get it right?????? > > Excuse me, but I think we just added a ton of confusion and didn't change > things one bit! > > > > > > ----- End Included Message ----- > >   Received: from cnri by ietf.org id aa22343; 21 Jul 97 17:30 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA21717 for ; Mon, 21 Jul 1997 17:29:25 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA12352 for ; Mon, 21 Jul 1997 16:31:48 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 21 Jul 1997 16:21:34 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA11651 for ipp-outgoing; Mon, 21 Jul 1997 16:13:23 -0400 (EDT) Date: Mon, 21 Jul 1997 13:09:58 -0700 From: Robert Herriot Message-Id: <199707212009.NAA09039@woden.eng.sun.com> To: imcdonal@eso.mc.xerox.com Subject: Re: IPP>MOD Issue with localization Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org No, the question is: Why would you expect the values set by the site to be localized? Printer vendors have good reasons to localize their messages, but there are few sites that have such a need. For example, I recently visited the Munich web page. Some parts come in English, but other parts, e.g. Bayerische Staatsoper are in German. It may to going too far to say that site specific text attributes could not be localized, but I expect few would. I expect that in most implementations, a user will receive text of printer vendor attributes in his language and text of site attributes in the language of the site. Bob Herriot > From imcdonal@eso.mc.xerox.com Sat Jul 19 13:09:15 1997 > > Hi Bob, > > Why would you expect the values set by the site NOT to be > localized (ie, to have their character set and language, > while static from device install, declared and available > to remote monitoring and client applications). > > Cheers, > - Ira McDonald > > PS - > This business of the declared 'cooperative' locale of > management stations and on-system management agents (or > IPP print servers) is what Tom Hastings, Angelo Caruso, > and I have been trying to clarify since early April > for the Printer MIB v2 - at present, all strings which > are NOT localized are forced to 7-bit US-ASCII - in > IPP they would be forced to UTF-8 (by default), but > for environments where the ISO 8859-n or ISO 2020 > (2022, oops) character sets are more appropriate, > there is no reason to preclude in IPP having a printer > attribute which is the declared 'cooperative' static > locale for other text strings - or as Tom Hastings > has suggested for the Job Mon MIB, the dynamic (usser > specified) locale for remotely supplied strings in a > job specification. > > ------------------------------------------------------------- > From ipp-owner@pwg.org Fri Jul 18 23:13:43 1997 > Return-Path: > Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) > id AA13815; Fri, 18 Jul 97 23:13:43 EDT > Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) > id AA22669; Fri, 18 Jul 97 23:10:30 EDT > Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <51920(3)>; Fri, 18 Jul 1997 20:10:36 PDT > Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA29253 for ; Fri, 18 Jul 1997 23:06:43 -0400 (EDT) > Received: by pwg.org (bulk_mailer v1.5); Fri, 18 Jul 1997 23:01:19 -0400 > Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA27791 for ipp-outgoing; Fri, 18 Jul 1997 22:35:48 -0400 (EDT) > Date: Fri, 18 Jul 1997 19:36:25 PDT > From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) > Message-Id: <199707190236.TAA06680@woden.eng.sun.com> > To: ipp@pwg.org > Subject: IPP>MOD Issue with localization > X-Sun-Charset: US-ASCII > Sender: ipp-owner@pwg.org > Status: R > > Should we a make statement about which attributes should be localized. > I would expect the text attributes set by the manufacturer would be > localized. They are: job-state-message , > printer-more-info-manufacturer, printer-state-message, and > printer-make-and-model. I would expect text attribute set by a site > would not be localized. They are job-message-from-operator, > printer-location, printer-description, printer-message- > from-the-operator > > If we agree with the first paragraph, should there be a separate text > type called localized-text for the 4 attributes mentioned in the > previous issue that can be localized. The status-message parameter > would also have this type, as would notification messages. > > Unless we do something, the localization issue is left very vague. > > >   Received: from cnri by ietf.org id aa22352; 21 Jul 97 17:30 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA21721 for ; Mon, 21 Jul 1997 17:29:28 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA13489 for ; Mon, 21 Jul 1997 16:46:41 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 21 Jul 1997 16:39:08 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA11718 for ipp-outgoing; Mon, 21 Jul 1997 16:21:32 -0400 (EDT) Date: Mon, 21 Jul 1997 13:20:13 -0700 From: Robert Herriot Message-Id: <199707212020.NAA09071@woden.eng.sun.com> To: ipp@pwg.org, Robert.Herriot@eng.sun.com Subject: IPP>MOD (with missing text) Issue with Conditionally Mandatory X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org [ somehow most of the paragraphs in the email I sent on Friday disappeared in transit, perhaps the period after "optional" which ended up in column 1 deleted all that followed. Here is the full text. ] I have a concern about the concept of conditionally-mandatory which applies to all job template attributes. I think it doesn't really help us understand what a conforming implementation must implement. After writing the paragraphs below, I have concluded that job-template attributes should all be optional, and we should drop the "conditionally mandatory" term. At the very least, they have to be optional for print servers. There may be some argument for making some of them conditionally mandatory in embedded printers, but the extra complexity of the explanation may not be worth the trouble. We all need to give this issue some more thought. As long as the explanation is so murky, I don't think any two people would come up with the same list of mandatory attributes for an implementation and that is no better than making them optional. Now for the details. Before discussing the issue, we should understand that there are two categories of attributes: o printer control (e.g. media or sides) o job control (e.g. job-priority, job-sheets or notify-events) And there are two types of implementations o embedded printer o print server We also need to look at the model document's definition of conditionally mandatory. The following is paraphrasing from 3 parts of the model document. It says an implementation must support the attribute if it knows about and is able to support it, and need not support the attribute that controls a feature that the output device does not implement or expose. It also says that if a certain implementation supports only one well-known value of some "xxx-supported" attribute, it is not required that that implementation support that attribute. This definition is somewhat reasonable for an embedded printer. It is easy to determine if an output device supports an IPP printer control attribute, though if the feature has only one value it may not be easy to determine if the value is "well-known". If a printer supports only letter paper, then the rules above say that support of "media" is not required. But suppose the size is B only. Is B "well-known" enough to qualify for the exclusion? If IPP has an exclusion for a known feature, the rule should exclude "non- selectable" features rather than "well-known" because "well-known" is subjective. This definition is somewhat more difficult for job control attributes in an embedded printer. There is no hardware associated with job-sheets or job-priority. So an output-device "knows" about such a feature only if its software implements it, in which case IPP likely supports it. This all seems rather circular. So the answer is that all job control attributes are optional for embedded printers. For print servers, the rule is quite inscrutable because a print server can potentially serve all types of printers with a variety of features. Are all printer-control attributes mandatory because a connected printer could have the feature or all printer-control attributes optional because the printer-server itself has none of the features? Because job-control attributes are normally implemented by a print servers and not output devices, the feature doesn't exist unless it is implemented, hence nothing is mandatory. So I am left not knowing what to do for a print server. Can I implement nothing or must I implement all to be conforming. I think everything is optional. When I look at the four combinations of the 2 types of implementations and 2 types of attributes, I conclude that only printer control attributes in embedded printer implementations could be conditionally mandatory. All job control attributes in embedded printers and all attributes in print servers must be optional.   Received: from cnri by ietf.org id aa22403; 21 Jul 97 17:31 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA21749 for ; Mon, 21 Jul 1997 17:29:47 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA11257 for ; Mon, 21 Jul 1997 13:38:33 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 21 Jul 1997 13:31:58 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA10609 for ipp-outgoing; Mon, 21 Jul 1997 13:23:08 -0400 (EDT) From: Roger K Debry To: ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: IPP>MOD - Job Identifier Message-Id: <5030100005081083000002L032*@MHS> Date: Mon, 21 Jul 1997 13:24:50 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org There has been a lot of discussion on the proposal made by Paul Moore on the use of Job URL. Unfortunately, there is no way to know if we really have consensus on the proposal. I'd like to see a re-statement of what we believe the agreed to changes are and some poll of the discussion list to see if we have a consensus. Would Bob and/or Paul be willing to do this? Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080   Received: from cnri by ietf.org id aa22441; 21 Jul 97 17:31 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA21805 for ; Mon, 21 Jul 1997 17:30:14 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA14869 for ; Mon, 21 Jul 1997 17:26:34 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 21 Jul 1997 17:20:41 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA13787 for ipp-outgoing; Mon, 21 Jul 1997 17:10:21 -0400 (EDT) Date: Mon, 21 Jul 1997 14:10:49 -0700 From: Robert Herriot Message-Id: <199707212110.OAA09151@woden.eng.sun.com> To: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP>MOD - Job Identifier X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I sent the following on Friday. I hope that we all agree the two paragraphs below. From rherriot Fri Jul 18 13:08:35 1997 So, I think that we are in agreement that the model and protocol documents should state that the operations whose target is a Printer shall include a parameter called printer-uri and operations whose target is a job shall include a parameter called job-uri. Randy suggests that the value of job-uri/printer-uri could differ from the request-uri on the HTTP Request-Line, but the model has no such concept. So unless there are strong arguments to the contrary, the protocol document will state that the request-uri has the same value as the printer-uri/job-uri in the operation. Bob Herriot > From rdebry@us.ibm.com Mon Jul 21 10:34:32 1997 > From: Roger K Debry > To: > Subject: IPP>MOD - Job Identifier > Date: Mon, 21 Jul 1997 13:24:50 -0400 > Mime-Version: 1.0 > Sender: ipp-owner@pwg.org > X-Lines: 16 > > There has been a lot of discussion on the proposal made by Paul Moore on the > use of Job URL. > Unfortunately, there is no way to know if we really have consensus on the > proposal. I'd like to > see a re-statement of what we believe the agreed to changes are and some poll > of the discussion > list to see if we have a consensus. Would Bob and/or Paul be willing to do > this? > > > Roger K deBry > Senior Techncial Staff Member > Architecture and Technology > IBM Printing Systems > email: rdebry@us.ibm.com > phone: 1-303-924-4080 >   Received: from cnri by ietf.org id aa23544; 21 Jul 97 17:54 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA22191 for ; Mon, 21 Jul 1997 17:53:27 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA15594 for ; Mon, 21 Jul 1997 17:49:46 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 21 Jul 1997 17:38:12 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA14442 for ipp-outgoing; Mon, 21 Jul 1997 17:21:26 -0400 (EDT) Date: Mon, 21 Jul 1997 14:20:56 -0700 From: Robert Herriot Message-Id: <199707212120.OAA09168@woden.eng.sun.com> To: Robert.Herriot@eng.sun.com, jkm@underscore.com Subject: Re: IPP>MOD Issue with best-effort Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Yes, you have accurately summed up the "best-effort" semantics which I have proposed calling it "may-ignore-attributes", except for your item 1. The client isn't quite asking the printer to do its best. Rather it is saying "do what you understand and ignore what you don't, but I want output". HTTP has a similar philosophy. This seems like good behavior for work-group printers. The higher standard of "do exactly what I asked or print nothing" is more suitable for production printing. Bob Herriot > From jkm@underscore.com Sat Jul 19 17:15:22 1997 > > Bob, > > Sometimes I get lost in a sea of words, at which point I drown > before I fully grasp the point. > > Regarding "best-effort", are the following statements consistent > with what you and Scott are proposing? > > 1) Conceptually, "best-effort" is the way for a client to tell the > IPP server to print the document(s) "the best way that it can", > given the specified job attributes. > > 2) When the client indicates "best-effort", the server is free to > ignore any attribute it either does not recognize, or is invalid > in some way. > > 3) When the client indicates "best-effort", the server is free to > ignore any attribute having a value that is invalid in some way. > > 4) The "best-effort" parameter is used only during job submission; > that is, it may only appear within a Print-Job, Print-URI, > Create-Job or Validate-Job operation. > > 5) The "best-effort" parameter is always an optional parameter; > if absent in the operation, the implied value is "false". > > Do these statements accurately sum up the proposal, or is something > missing or incorrect? > > ...jay > > ----- Begin Included Message ----- > > From ipp-owner@pwg.org Fri Jul 18 23:01 EDT 1997 > Date: Fri, 18 Jul 1997 19:34:58 -0700 > From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) > To: ipp@pwg.org > Subject: IPP>MOD Issue with best-effort > > > Scott and I have discussed the best-effort job attribute and we both > agree that this doesn't fit as a Job- Template attribute. The printer > attribute best-effort-supported doesn't fit the job template model very > well. > > I suggest that it become an optional parameter to Print-Job, Print-URI, > Create-Job, and Validate-Job and that it be renamed to > `may-ignore-attributes' to reflect its new meaning. > > If it is omitted in these operations, it has a value of false. All > implementations must support both values of this parameter. It seems > to me that this is not much of a requirement because very > implementation has to check if it supports an attribute and each value. > If the answer is yes, the value of may-ignore-attributes doesn't > matter. If it is no and may-ignore-attributes is false, the job is > rejected and the offending attribute returned in the response ( the > current required mechanism). If it is no and may-ignore-attributes is > true, I propose that the Printer ignore the attribute not to add it to > the job, which means the default behavior takes hold (the new > very-simple mechanism). > > There should be an OPTIONAL job attribute may-ignore-attributes which > is set by the parameter may- ignore-attributes. This attribute is > MANDATORY if Create-Job is supported because Send-Document and Send-URI > use the value set by Create-Job. Otherwise, I wouldn't expect it to be > implemented. It would be useful in a future resubmit-job operation > > The following is the change in wording that I propose for rules 3 and 4 > in section 3.1.2.1 Print-Job Request: > > 3. The client supplies a Job Template attribute and either the > attribute is not supported by the Printer or the attribute value is not > among the values supported by the Printer: The value of the > "may-ignore- attributes" parameter determines the Printer's behavior. > > 3a. The client supplies no "may-ignore-attributes" parameter, or > supplies a "may-ignore- attributes" parameter of 'false': the > Printer SHALL reject the Job. It SHALL return the 'client- > error-attribute-unsupported" error code and the unsupported attribute > in the "unsupported attributes " output parameter. If it is the > attribute value that is unsupported, the attribute in the unsupported > attributes output parameter SHALL be exactly as received in the > request. If it is the attribute itself that is unsupported, the > attribute in the `unsupported attributes' output parameter SHALL have > the name as received in the request, but its value SHALL be > "unsupported". If a job contains more than one unsupported attribute or > attribute value that cause a job to be rejected, a Printer may return > all of them, some of them, or only one of them in the `unsupported > attributes' output parameter. Note: in the Send-Document or Send-URI > operation, the document and not the job is rejected, and if the > last-document flag is true, it is treated as if it were false so that > the client can resubmit the document. > > 3b. The client supplies a "may-ignore-attributes" of 'true': the > Printer SHALL continue accepting the Job but ignore the attribute and > not associate it with the new Job object. The Printer's default value > effectively becomes the value of this attribute (see rule 4 below). In > this case, if everything else is ok, the Printer SHALL return a > "successful-attributes-ignored" status code along an optional complete > list of ignored attributes in the `unsupported attributes' output > parameter. > > Job-name > > Job-name, like best-effort, doesn't fit in the job-template section. > For example, it alone is mandatory and it alone has no xxx-supported > attribute. It also has special rules for setting its value because it > has no default. > > I suggest that it become a parameter to Print-Job, Print-URI, > Create-Job and Validate-Job and become a job-description attribute > where there are several mandatory attributes. The description for the > job attribute can contain all the rules for how a printer sets its > value, i.e. from the parameter, or the document-name or from an > implementation defined value, in that order of precedence. > > > > > ----- End Included Message ----- > >   Received: from cnri by ietf.org id aa23736; 21 Jul 97 18:01 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid SAA22271 for ; Mon, 21 Jul 1997 18:00:19 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA16120 for ; Mon, 21 Jul 1997 17:56:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 21 Jul 1997 17:45:35 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA14870 for ipp-outgoing; Mon, 21 Jul 1997 17:26:37 -0400 (EDT) Date: Mon, 21 Jul 1997 14:26:38 -0700 From: Robert Herriot Message-Id: <199707212126.OAA09186@woden.eng.sun.com> To: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP> Review of Model Document - unsupported job template X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org The issue is whether a server returns with a rejected job all of the attributes that caused the rejection or just the first one encountered. We left this choice to the implementation because it is easier for a server to reject a job when it first finds an error than to accumulate these errors and wait until the end to reject the job and return all errors. Some people felt strongly that we should not require an implementation to have the complexity of returning all. Clearly, a client can get all of them through an iterative process. We made this decision at the June 17th meeting. Bob Herriot > From rdebry@us.ibm.com Mon Jul 21 06:44:43 1997 > > Perhaps, I wasn't sufficiently clear. The 'unsupported attributes' > output parameter contains a list of rejected attributes. The printer > takes attributes with unsupported values and puts them into the > response with no change. The printer takes attributes that are not > supported and puts them into the response with their value set to > "unsupported" which in the protocol is an "out-of-band" value that > works for any type. A printer may put all such attributes in the > response, or only some of them. In other words, a Printer can > accumulate all unsupported attributes before it rejects the job or it > can reject the job immediately after it finds the first bad attribute. > > The document certainly does not say this! Let me > be sure I understand. Lets say that two attributes > are sent, one which is supported but its value is > not, and one which is unsupported: > o finishing = saddle-stitch (unsupported value) > o number-up = two (unsupported attribute) > > If I understand correctly, the response would contain > the following unsupported attributes: > o finishing = saddle-stitch > o number-up = unsupported > Right? > > I don't agree with it being optional for the printer > to return only a partial list of unsupported attributes > as you suggest. How does the client know what's wrong > if the Printer does not have to send back accurate > error information? If everyone else agrees with > this being optional then it should be made clear in > the document ... currently I don't believe it makes > this clear at all. I read it as saying the entire list > is sent back. > > > > >   Received: from cnri by ietf.org id aa23851; 21 Jul 97 18:06 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid SAA22323 for ; Mon, 21 Jul 1997 18:05:24 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA16530 for ; Mon, 21 Jul 1997 18:01:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 21 Jul 1997 17:54:03 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA14951 for ipp-outgoing; Mon, 21 Jul 1997 17:32:20 -0400 (EDT) Date: Mon, 21 Jul 1997 14:32:39 -0700 From: Robert Herriot Message-Id: <199707212132.OAA09200@woden.eng.sun.com> To: ipp@pwg.org Subject: Re: IPP> Appendix-B of Protocol document X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org It is in the document to show that the encoding works with something other than HTTP. In time, implementations may want to support the protocol over sockets. Bob Herriot > From pthambid@okidata.com Mon Jul 21 13:44:21 1997 > Mime-Version: 1.0 > Date: Mon, 21 Jul 1997 16:22:59 -0400 > From: pthambid@okidata.com (Philip Thambidurai) > Subject: IPP> Appendix-B of Protocol document > To: ipp@pwg.org > Content-Transfer-Encoding: 7bit > Sender: ipp-owner@pwg.org > X-Lines: 6 > > > Exactly why is Appendix-B "Reqmts. without HTTP 1.1 as a Transport > Layer" necessary? Isn't it always assumed that HTTP/1.1 is the only > transport layer that should be used? > > Philip Thambidurai >   Received: from cnri by ietf.org id aa24134; 21 Jul 97 18:13 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid SAA22376 for ; Mon, 21 Jul 1997 18:12:07 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA17073 for ; Mon, 21 Jul 1997 18:08:28 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 21 Jul 1997 18:01:52 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA15178 for ipp-outgoing; Mon, 21 Jul 1997 17:42:40 -0400 (EDT) Date: Mon, 21 Jul 1997 14:36:03 PDT From: "Caruso,Angelo" Subject: Re: IPP>MOD - Job Identifier To: ipp@pwg.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Posting-date: Mon, 21 Jul 1997 17:39:08 -0400 Priority: normal Hop-count: 3 Sender: ipp-owner@pwg.org Bob, I agree. Thanks, Angelo Caruso ---------- From: ipp-owner@pwg.org To: ipp@pwg.org; rdebry@us.ibm.com Subject: Re: IPP>MOD - Job Identifier Date: Monday, July 21, 1997 2:10PM I sent the following on Friday. I hope that we all agree the two paragraphs below. From rherriot Fri Jul 18 13:08:35 1997 So, I think that we are in agreement that the model and protocol documents should state that the operations whose target is a Printer shall include a parameter called printer-uri and operations whose target is a job shall include a parameter called job-uri. Randy suggests that the value of job-uri/printer-uri could differ from the request-uri on the HTTP Request-Line, but the model has no such concept. So unless there are strong arguments to the contrary, the protocol document will state that the request-uri has the same value as the printer-uri/job-uri in the operation. Bob Herriot   Received: from cnri by ietf.org id aa24589; 21 Jul 97 18:37 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid SAA22507 for ; Mon, 21 Jul 1997 18:36:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA18336 for ; Mon, 21 Jul 1997 18:32:19 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 21 Jul 1997 18:26:21 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA17674 for ipp-outgoing; Mon, 21 Jul 1997 18:17:46 -0400 (EDT) Message-Id: <199707212216.SAA20044@spot.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Carl-Uno Manros cc: Cynthia Clark , Harald.T.Alvestrand@uninett.no, Keith Moore , ipp@pwg.org Subject: IPP> Re: New Internet-Draft Internet Printing Protocol 1.0: Rationale In-reply-to: Your message of "Thu, 17 Jul 1997 17:32:41 PDT." <3.0.1.32.19970717173241.009aaa10@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Jul 1997 18:16:21 -0400 Sender: ipp-owner@pwg.org > Our biggest problem is to convert documents written in WinWord to the IETF > ASCII format which is a non-trivial task. We are actually just now working > on an informational RFC document, which describes the conversion process > from WinWord to IETF format step-by-step. This might become one of your > most popular documents once it is finished! At my request, someone from Microsoft has also recently produced such a document. I've asked the Internet-Drafts people and RFC Editor to make them available to people in the same way as similar documents describing how to generate RFCs using other word processors. (I'll forward you a copy of this document in a separate message.) > I hope you realize that some 90 % of the world's desktops and > portables have WinWord as an application, and that only UNIX > "hackers" can produce the IETF format with relative ease. Time for > a rethink in the IETF? IETF exists to allow network protocols to be implemented across all platforms, not to produce protocols for a single vendor's platforms. IETF documents need to be readable on all platforms and printable on all printers. Plain ASCII text is the only format which is so widely usable. Even if 90% of the world's desktops and portables have WinWord installed (which I doubt), this doesn't translate into 90% of the world's protocol developers. Besides, ASCII is usable on nearly 100% of the world's computing systems, and the other 10% is an important audience. I disagree that only UNIX hackers can easily produce the IETF format. All it takes to submit an internet-draft is an ordinary text editor. Last I knew, every DOS and Windows box came with one installed, and I know they're available for Macs as well. Lots of people seem to use them to write bare HTML (much to my surprise) because it gives them more flexibility than is available with HTML editors. The Internet-Draft format does require short lines and page breaks, but it's hardly necessary that these be done perfectly -- the RFC Editor generally has to do some minor editing anyway before the document can be published, and can easily take care of such cleanup. Lines can be broken by hitting the RETURN key at the end of each line, and page breaks can be inserted by a simple post-processor. (Even nroff requires post-processing to clean up page breaks, so UNIX hackers are no better off.) Text editors don't do section numbering either, but even though nroff does have section numbering, I've hardly ever used it when writing RFCs. I can understand how experienced WinWord users might feel cramped when using a text editor to write an RFC, which is the very reason that I asked people from Microsoft to provide some advice for using WinWord. But UNIX users also feel cramped. Much like WinWord, nroff has to be carefully tweaked to get the page length and margins right for RFCs Much like winword, nroff wants to produce overstrikes and add extra lines at the top of a page which much be removed in postprocessing. It's easy once you know the tricks and have the tools in place, but this is true for both nroff and WinWord. The only significant difference is that nroff users already know the tricks, while WinWord users are just now learning them. The RFC format is a compromise, deliberately chosen to be universally readable, at the expense of being somewhat difficult to produce. Even today, it seems to me that this is still the right tradeoff. Keith   Received: from cnri by ietf.org id aa25050; 21 Jul 97 19:06 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid TAA22659 for ; Mon, 21 Jul 1997 19:04:41 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA19320 for ; Mon, 21 Jul 1997 19:01:03 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 21 Jul 1997 18:57:40 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA18709 for ipp-outgoing; Mon, 21 Jul 1997 18:50:17 -0400 (EDT) Date: Mon, 21 Jul 1997 18:50:20 -0400 (EDT) From: JK Martin Message-Id: <199707212250.SAA11707@uscore.underscore.com> To: Robert.Herriot@eng.sun.com Subject: Re: IPP>MOD - best effort Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Sorry, but what I meant to say was that there was no obviously good reason to rename "best-effort" to "may-ignore-attributes". (I guess you've since withdrawn such renaming...thanks.) I do, however, like moving "best-effort" to a parameter where applicable. ...jay ----- Begin Included Message ----- From Robert.Herriot@Eng.Sun.COM Mon Jul 21 17:03 EDT 1997 Date: Mon, 21 Jul 1997 14:03:35 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) To: ipp@pwg.org, jkm@underscore.com, rdebry@us.ibm.com Subject: Re: IPP>MOD - best effort There is plenty wrong with best-effort. Perhaps you didn't read the fine print in the current model document. It is currently defined as a job template attribute which means: o there is a job attribute "best-effort" for specifying what the client wants. o there is a printer default "best-effort" which says whether the printer defaults it behavior to best-effort or not if a client doesn't specify this attribute. o there is a printer "best-effort-supported" attribute which is unlike most xxx-supported attributes. It is not a set of possible values, namely "true" and "false" values. Instead, it is either "true" or "false" * "true" means that a client can specify either the value "true" or "false" or and the printer default "best-effort" can have the value of true or false" * "false" means that a client can specify only the value of "false" and the default "best-effort" can have only the value of "false". NOTE: it is believed that no implementation would support a "best-effort" job attribute of "true" only. o this attribute has to be processed before others are processed because it affects the processing of them, but it need not be the first attribute. o the "best-effort" substitution is somewhat undefined and potentially complex. Compare the above with what I proposed: o I replace 3 job-template attributes by a single parameter "may-ignored-attributes" which is either true, false or omitted (false is default). All printers support both values because it is easier to support "best-effort" as "ignore the attribute". o I make it easy to process the "may-ignore-attributes" value before any attributes are processed because the information is in the parameter section which precedes any attributes. Now I suggest that we forget about "may-ignore-attributes" job attribute, that I proposed. It really isn't necessary and deflects from the discussion. The single parameter is sufficient. Do you still believe that the "3 job-template attributes" proposal is simpler than the "single parameter" proposal? Bob Herriot > From jkm@underscore.com Mon Jul 21 07:58:51 1997 > > I completely agree with Roger. I just don't see the added value > here...but I certainly see the additional complexity and resulting > confusion. > > There is nothing wrong (semantically) with "best-effort". Let's > leave it alone, but make the obvious clarifications in the Model > document with regard to Job templates, etc. > > ...jay > > ----- Begin Included Message ----- > > From ipp-owner@pwg.org Mon Jul 21 10:01 EDT 1997 > From: Roger K Debry > To: > Subject: IPP>MOD - best effort > Date: Mon, 21 Jul 1997 09:54:56 -0400 > > >There should be an OPTIONAL job attribute may-ignore-attributes which > >is set by the parameter may- ignore-attributes. This attribute is > >MANDATORY if Create-Job is supported because Send-Document and Send-URI > >use the value set by Create-Job. Otherwise, I wouldn't expect it to be > >implemented. It would be useful in a future resubmit-job operation > > Now let me see, if I understand .... we don't like the concept of > best-effort as an attribute, so we rename it, make it a parameter, then > add an optional job attribute with the same name, and then have the > parameter set the attribute, except sometimes the attribute (or is it > the parameter) is mandatory. Did I get it right?????? > > Excuse me, but I think we just added a ton of confusion and didn't change > things one bit! > > > > > > ----- End Included Message ----- > > ----- End Included Message -----   Received: from cnri by ietf.org id aa25402; 21 Jul 97 19:29 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid TAA22823 for ; Mon, 21 Jul 1997 19:28:13 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA19853 for ; Mon, 21 Jul 1997 19:24:31 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 21 Jul 1997 19:21:16 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA19408 for ipp-outgoing; Mon, 21 Jul 1997 19:14:06 -0400 (EDT) Date: Mon, 21 Jul 1997 16:13:20 -0700 From: Robert Herriot Message-Id: <199707212313.QAA09479@woden.eng.sun.com> To: Robert.Herriot@eng.sun.com, jkm@underscore.com Subject: Re: IPP>MOD - best effort Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org The semantics are more important to me than the name. If the group prefers "best-effort" to "may-ignore-attributes", that's OK with me. But what do you mean by "where applicable" below. I had in mind that "best-effort" would be a parameter and nothing else. It is behavior that occurs during receipt of a printer and has no existence past that point. Bob Herriot > From jkm@underscore.com Mon Jul 21 15:51:00 1997 > > Sorry, but what I meant to say was that there was no obviously > good reason to rename "best-effort" to "may-ignore-attributes". > (I guess you've since withdrawn such renaming...thanks.) > > I do, however, like moving "best-effort" to a parameter where > applicable. > > ...jay > > ----- Begin Included Message ----- > > From Robert.Herriot@Eng.Sun.COM Mon Jul 21 17:03 EDT 1997 > Date: Mon, 21 Jul 1997 14:03:35 -0700 > From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) > To: ipp@pwg.org, jkm@underscore.com, rdebry@us.ibm.com > Subject: Re: IPP>MOD - best effort > > There is plenty wrong with best-effort. Perhaps you didn't read the > fine print in the current model document. It is currently > defined as a job template attribute which means: > > o there is a job attribute "best-effort" for specifying what the > client wants. > o there is a printer default "best-effort" which says whether > the printer defaults it behavior to best-effort or not if a > client doesn't specify this attribute. > o there is a printer "best-effort-supported" attribute which is unlike > most xxx-supported attributes. It is not a set of possible > values, namely "true" and "false" values. Instead, it is either > "true" or "false" > * "true" means that a client can specify either the value > "true" or "false" or and the printer default "best-effort" > can have the value of true or false" > * "false" means that a client can specify only the value of > "false" and the default "best-effort" can have only the > value of "false". > NOTE: it is believed that no implementation would support > a "best-effort" job attribute of "true" only. > o this attribute has to be processed before others are processed > because it affects the processing of them, but it need not > be the first attribute. > o the "best-effort" substitution is somewhat undefined and > potentially complex. > > Compare the above with what I proposed: > > > o I replace 3 job-template attributes by a single parameter > "may-ignored-attributes" which is either true, false or omitted > (false is default). All printers support both values because > it is easier to support "best-effort" as "ignore the attribute". > > o I make it easy to process the "may-ignore-attributes" value before > any attributes are processed because the information is > in the parameter section which precedes any attributes. > > Now I suggest that we forget about "may-ignore-attributes" job > attribute, that I proposed. It really isn't necessary and deflects > from the discussion. The single parameter is sufficient. > > Do you still believe that the "3 job-template attributes" proposal is > simpler than the "single parameter" proposal? > > Bob Herriot > > > From jkm@underscore.com Mon Jul 21 07:58:51 1997 > > > > I completely agree with Roger. I just don't see the added value > > here...but I certainly see the additional complexity and resulting > > confusion. > > > > There is nothing wrong (semantically) with "best-effort". Let's > > leave it alone, but make the obvious clarifications in the Model > > document with regard to Job templates, etc. > > > > ...jay > > > > ----- Begin Included Message ----- > > > > From ipp-owner@pwg.org Mon Jul 21 10:01 EDT 1997 > > From: Roger K Debry > > To: > > Subject: IPP>MOD - best effort > > Date: Mon, 21 Jul 1997 09:54:56 -0400 > > > > >There should be an OPTIONAL job attribute may-ignore-attributes which > > >is set by the parameter may- ignore-attributes. This attribute is > > >MANDATORY if Create-Job is supported because Send-Document and Send-URI > > >use the value set by Create-Job. Otherwise, I wouldn't expect it to be > > >implemented. It would be useful in a future resubmit-job operation > > > > Now let me see, if I understand .... we don't like the concept of > > best-effort as an attribute, so we rename it, make it a parameter, then > > add an optional job attribute with the same name, and then have the > > parameter set the attribute, except sometimes the attribute (or is it > > the parameter) is mandatory. Did I get it right?????? > > > > Excuse me, but I think we just added a ton of confusion and didn't change > > things one bit! > > > > > > > > > > > > ----- End Included Message ----- > > > > > > > ----- End Included Message ----- > > >   Received: from cnri by ietf.org id aa27753; 21 Jul 97 22:21 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid WAA23210 for ; Mon, 21 Jul 1997 22:19:52 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA21353 for ; Mon, 21 Jul 1997 22:16:16 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 21 Jul 1997 22:12:27 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA20857 for ipp-outgoing; Mon, 21 Jul 1997 22:05:21 -0400 (EDT) Message-Id: <9707220155.AA08695@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, 21 Jul 1997 18:53:05 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> PRO - Need some value-tags reserved for private extensions Sender: ipp-owner@pwg.org In order to allow private attributes to be implemented, some implementors may need some additional value-tag data types. To be consistent with other codes in the protocol (such as operations), we need to reserve some space for private, experimental value-tags for data types. Thanks, Tom   Received: from cnri by ietf.org id aa06709; 22 Jul 97 9:44 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid JAA24353 for ; Tue, 22 Jul 1997 09:43:21 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA22608 for ; Tue, 22 Jul 1997 09:39:40 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 22 Jul 1997 09:32:25 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA22159 for ipp-outgoing; Tue, 22 Jul 1997 09:25:18 -0400 (EDT) From: Roger K Debry To: ipp@pwg.org, Robert.Herriot@eng.sun.com MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: Re: IPP>MOD - best effort Message-Id: <5030100005125145000002L052*@MHS> Date: Tue, 22 Jul 1997 09:26:53 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Bob, You've clearly simplified things by getting rid of the "may-ignore ..." job attribute. But, I still believe that a "best-effort" job template attribute is better than a new parameter. To me, whether or not I want the job to print, regardless of attribute errors, is itself an attribute of the job. Let's keep attributes attributes! o there is a job attribute "best-effort" for specifying what the client wants. This is straightforward and consistent with it being a job template attribute. I see no problem here. o there is a printer default "best-effort" which says whether the printer defaults it behavior to best-effort or not if a client doesn't specify this attribute. This is also simple and consistent. o there is a printer "best-effort-supported" attribute which is unlike most xxx-supported attributes. It is not a set of possible values, namely "true" and "false" values. Instead, it is either "true" or "false" As you have written it down here, the rules are not consistent with other job template atributes. However, it seems that this is an easy fix. If a Printer supports both "true" and "false" values, then the xxx-supported should in fact be a set of values, namely "true" and "false". This matches what you have written below. Furthermore, if the Printer only supports "false" then xxx-supported has only one value, and that is "false". This also matches what you have written below. Now I think xxx-supported for "best-effort" is consistent with other job template attributes. * "true" means that a client can specify either the value "true" or "false" or and the printer default "best-effort" can have the value of true or false" * "false" means that a client can specify only the value of "false" and the default "best-effort" can have only the value of "false". NOTE: it is believed that no implementation would support a "best-effort" job attribute of "true" only. o this attribute has to be processed before others are processed because it affects the processing of them, but it need not be the first attribute. It appears that you can fix this problem in two ways. Although it may require a little additional code to implement, it is surely possible for the Printer to handle the best-effort attribute in any place in the sequence of received attributes. If everyone thinks this is too hard, then you could mandate that if this attribute is used it MUST be the first in the list. Admittedly, this is a special rule for this attribute, but in effect that's all you've done by declaring it a parameter. o the "best-effort" substitution is somewhat undefined and potentially complex. Its not clear why you think this is somewhat undefined and potentially complex. Why is it different from any other attribute?   Received: from ietf.org by ietf.org id aa07741; 22 Jul 97 9:54 EDT Received: from ietf.ietf.org by ietf.org id aa06857; 22 Jul 97 9:49 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ippcp@external.cisco.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ippcp-protocol-00.txt Date: Tue, 22 Jul 1997 09:49:15 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9707220949.aa06857@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Payload Compression Protocol Working Group of the IETF. Title : IP Payload Compression Protocol (IPComp) Author(s) : A. Shacham Filename : draft-ietf-ippcp-protocol-00.txt Pages : 5 Date : 07/21/1997 This memo describes a protocol intended to provide compression services for IP datagrams in an Internet environment. 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-ippcp-protocol-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ippcp-protocol-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-ippcp-protocol-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: <19970721101837.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippcp-protocol-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippcp-protocol-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970721101837.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa08157; 22 Jul 97 9:57 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid JAA24465 for ; Tue, 22 Jul 1997 09:56:12 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA23190 for ; Tue, 22 Jul 1997 09:52:35 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 22 Jul 1997 09:48:05 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA22683 for ipp-outgoing; Tue, 22 Jul 1997 09:40:54 -0400 (EDT) From: Roger K Debry To: ipp@pwg.org, bob.herriot@eng.sun.com MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: Re: IPP> Review of Model Document - unsupported job template Message-Id: <5030100005125681000002L012*@MHS> Date: Tue, 22 Jul 1997 09:42:33 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org If indeed this is the agreement, then I believe that the model document needs to be fixed. In section 3.1.2.2 it clearly says that if there is an error, a SET of unsupported attributes is returned. While one could interpret this to mean the SET may contain just one attribute, I I interpreted it to mean the entire set must be returned. I hope there aren't too many more gotcha's like this one - - it could kill interoperability. By the way, I think returning just the first unsupported attribute is extremely unfriendly and not the right answer. 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 07/22/97 07:25 AM --------------------------- Robert.Herriot @ Eng.Sun.COM 07/21/97 08:20 PM Please respond to Robert.Herriot@Eng.Sun.COM @ internet To: Roger K Debry/Boulder/IBM, ipp @ pwg.org @ internet cc: Subject: Re: IPP> Review of Model Document - unsupported job template The issue is whether a server returns with a rejected job all of the attributes that caused the rejection or just the first one encountered. We left this choice to the implementation because it is easier for a server to reject a job when it first finds an error than to accumulate these errors and wait until the end to reject the job and return all errors. Some people felt strongly that we should not require an implementation to have the complexity of returning all. Clearly, a client can get all of them through an iterative process. We made this decision at the June 17th meeting. Bob Herriot > From rdebry@us.ibm.com Mon Jul 21 06:44:43 1997 > > Perhaps, I wasn't sufficiently clear. The 'unsupported attributes' > output parameter contains a list of rejected attributes. The printer > takes attributes with unsupported values and puts them into the > response with no change. The printer takes attributes that are not > supported and puts them into the response with their value set to > "unsupported" which in the protocol is an "out-of-band" value that > works for any type. A printer may put all such attributes in the > response, or only some of them. In other words, a Printer can > accumulate all unsupported attributes before it rejects the job or it > can reject the job immediately after it finds the first bad attribute. > > The document certainly does not say this! Let me > be sure I understand. Lets say that two attributes > are sent, one which is supported but its value is > not, and one which is unsupported: > o finishing = saddle-stitch (unsupported value) > o number-up = two (unsupported attribute) > > If I understand correctly, the response would contain > the following unsupported attributes: > o finishing = saddle-stitch > o number-up = unsupported > Right? > > I don't agree with it being optional for the printer > to return only a partial list of unsupported attributes > as you suggest. How does the client know what's wrong > if the Printer does not have to send back accurate > error information? If everyone else agrees with > this being optional then it should be made clear in > the document ... currently I don't believe it makes > this clear at all. I read it as saying the entire list > is sent back. > > > > >   Received: from cnri by ietf.org id aa08496; 22 Jul 97 10:10 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid KAA24549 for ; Tue, 22 Jul 1997 10:09:05 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA24096 for ; Tue, 22 Jul 1997 10:05:29 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 22 Jul 1997 10:02:20 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA23177 for ipp-outgoing; Tue, 22 Jul 1997 09:52:30 -0400 (EDT) From: Roger K Debry To: cmanros@cp10.es.xerox.com MMDF-Warning: Parse error in original version of preceding line at ietf.org Cc: ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Message-Id: <5030100005126077000002L072*@MHS> Date: Tue, 22 Jul 1997 09:54:02 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org A new version of the security draft has been posted to the pwg site. It is at pub/pwg/ipp/new_SEC/draft-ietf-ipp-security-01.txt Roger K deBry Senior Techncial Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080   Received: from cnri by ietf.org id aa10232; 22 Jul 97 10:56 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid KAA24809 for ; Tue, 22 Jul 1997 10:55:20 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA24998 for ; Tue, 22 Jul 1997 10:51:44 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 22 Jul 1997 10:48:12 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA24359 for ipp-outgoing; Tue, 22 Jul 1997 10:39:36 -0400 (EDT) Message-ID: <01BC9671.4BDF2F80.C.Tabor@bull.com> From: Chris Tabor Reply-To: "C.Tabor@bull.com" To: 'Roger K Debry' , "ipp@pwg.org" Subject: RE: IPP>MOD - best effort Date: Tue, 22 Jul 1997 07:31:40 -0700 Organization: Bull HN Information Systems X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org On Tuesday, July 22, 1997 6:27 AM, Roger K Debry [SMTP:rdebry@us.ibm.com] wrote: > Bob, You've clearly simplified things by > getting rid of the "may-ignore ..." job > attribute. But, I still believe that a > "best-effort" job template attribute is better > than a new parameter. To me, whether or not I want > the job to print, regardless of attribute errors, > is itself an attribute of the job. Let's keep > attributes attributes! Or is it a parameter that controls the selection of job attributes? > > o there is a job attribute "best-effort" for specifying what the > client wants. > > This is straightforward and consistent with it being > a job template attribute. I see no problem here. > <<>> --C ---------------------------------------------------------------------- Chris Tabor (602) 862-5806 Go Suns!!! C.Tabor@bull.com Fax (602) 862-4290 Std Disclaimer - The ideas, opinions, recommendations and views expressed in this message are my own and in no way represent those of my employer or Internet provider.   Received: from cnri by ietf.org id aa10627; 22 Jul 97 11:12 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid LAA24905 for ; Tue, 22 Jul 1997 11:11:35 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA25524 for ; Tue, 22 Jul 1997 11:07:59 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 22 Jul 1997 11:04:45 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA25074 for ipp-outgoing; Tue, 22 Jul 1997 10:57:36 -0400 (EDT) Message-Id: <1.5.4.32.19970722145717.006c9dcc@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, 22 Jul 1997 07:57:17 -0700 To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> PRO - I-D ACTION:draft-ietf-drums-abnf-03.txt Sender: ipp-owner@pwg.org A new version of the ABNF has just got published. We need to check that we are still in sunc. Carl-Uno >To: IETF-Announce@ietf.org >cc: drums@cs.utk.edu >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-ietf-drums-abnf-03.txt >Date: Tue, 22 Jul 1997 09:50:12 -0400 >Sender: cclark@ietf.org > > A Revised Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Detailed Revision/Update of > Message Standards Working Group of the IETF. > > Title : Augmented BNF for Syntax Specifications: ABNF > Author(s) : D. Crocker, P. Overell > Filename : draft-ietf-drums-abnf-03.txt > Pages : 9 > Date : 07/21/1997 > >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. > >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-drums-abnf-03.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-ietf-drums-abnf-03.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-drums-abnf-03.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. >Content-Type: text/plain >Content-ID: <19970721150848.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-drums-abnf-03.txt >Content-Type: text/plain >Content-ID: <19970721150848.I-D@ietf.org> >   Received: from cnri by ietf.org id aa11067; 22 Jul 97 11:28 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid LAA24996 for ; Tue, 22 Jul 1997 11:27:27 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA26047 for ; Tue, 22 Jul 1997 11:23:51 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 22 Jul 1997 11:20:24 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA25604 for ipp-outgoing; Tue, 22 Jul 1997 11:13:15 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 22 Jul 1997 09:12:51 -0600 From: Scott Isaacson To: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP> Review of Model Document - unsupported job template Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org >>> Roger K Debry 07/21 7:33 AM >>> If I understand correctly, the response would contain the following unsupported attributes: o finishing = saddle-stitch o number-up = unsupported Right? Yes, this is what I understand. I will try to fix the model document language. I don't agree with it being optional for the printer to return only a partial list of unsupported attributes as you suggest. The model document should say that if the Printer rejects the Job for one or more unsupported attribute or value, then it MUST return at least one of them in the 'unsupported attributes' output parameter. It is not optional to not return anything at all in addition to the error code. However, the notion of returning ALL unsupported attributes (if there are more than one) might be too burdensome for all implementations. The model document needs to say something like " the Printer SHOULD return all unsupported attributes and values but if it is unable to do so, the Printer MUST return at least one if there are more than one", How does the client know what's wrong if the Printer does not have to send back accurate error information? If everyone else agrees with this being optional then it should be made clear in the document ... currently I don't believe it makes this clear at all. I read it as saying the entire list is sent back. Thanks for the critical reading and feedback. Scott   Received: from cnri by ietf.org id aa11835; 22 Jul 97 12:09 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid MAA25217 for ; Tue, 22 Jul 1997 12:07:39 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA27014 for ; Tue, 22 Jul 1997 12:04:02 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 22 Jul 1997 11:58:43 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA26147 for ipp-outgoing; Tue, 22 Jul 1997 11:48:00 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 22 Jul 1997 09:47:47 -0600 From: Scott Isaacson To: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP> Validate-Job for print by reference Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Roger, My comments have an SAI> prefix >>> Roger K Debry 07/18 10:03 AM >>> On Wednesday's call there was some discussion of a proposal to add a new operation or a parameter to Validate-Job to handle print by reference. It is not clear to me that we need such an operation. SAI> The proposal to add an operation only lasted about 5 seconds. I agree SAI> with you - read my lips NO NEW OPERATION Currently, I believe the function of Validate-Job is to validate the job parameters against Printer capabilities. This should be independent of whether or not the document will be passed or printed by reference. If one wants to test whether or not print-by reference is supported, then he would send a Get-Operations request. SAI> The new parameter was not to "test whether or not print-by-reference SAI> is supported" but just the URI itself If the objective of this new operation is to test whether or not the given URI is valid, i.e. if the Printer can get it, then I am concerned that we are testing a time-dependent variable. I could try the URI at one instant and because of server or network load not be able to get to the document. Furthermore, I could find the document and report back okay only to have the document owner move or delete it before the Print-URI request was sent and operated upon by the Printer. SAI> The objective of the new parameter (attribute?) is as you describe above. SAI> I agree that even if you validated that the reference is good at submit SAI> time, the reference may be invalid at print time. We all agreed that we SAI> needed to add some error code to show that the reference was bad SAI> at print time therefore, if we already must include the new error code SAI> in the set implemented by some implementation that supports print-by SAI> reference, then why not be able to check at submission time as well. SAI> SAI> The final proposal was to add an optional "document-uri" to Validate- SAI> Job that would be checked for valid URI syntax only - the Printer would SAI> not try to follow the reference and see if the server was up, the document SAI> could be located, etc. SAI> SAI> However, if we"believe the function of Validate-Job is to validate the job SAI> parameters against Printer capabilities" then we should drop this SAI> new proposed parameter. I could go either way. What does the rest SAI> of the group think?   Received: from cnri by ietf.org id aa12035; 22 Jul 97 12:19 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid MAA25274 for ; Tue, 22 Jul 1997 12:18:28 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA27563 for ; Tue, 22 Jul 1997 12:14:52 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 22 Jul 1997 12:11:30 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA26980 for ipp-outgoing; Tue, 22 Jul 1997 12:03:24 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 22 Jul 1997 10:03:07 -0600 From: Scott Isaacson To: Robert.Herriot@eng.sun.com, ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP>MOD - Job Identifier Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org I am late to this discussion, but I too violently agree with the understanding I have of Bob's summary: 1. The model document needs to state that " the operations whose target is a Printer includes a parameter called printer-uri and operations whose target is a job shall include a parameter called job-uri" 2. Bob suggests that the protocol document should state (since the model implies) that the request-uri has the same value as the printer-uri/job-uri in the operation. (I agree with this - if they are different, how does the client get the two values - GetJobs and all the Creates return just one?) 3. The protocol document (except for appendix B) is a mapping of the model document to HTTP. If all that is true, can't we state in the Protocol document (mapping of IPP model to HTTP) that the way to encode the special parameters "job-uri" or "printer-uri" is in the request-uri itself therefore we don't need the redundancy in this mapping? Or are we expecting that payloads (user data) from one transport mapping with interperate with payloads mapped onto some other future transport mapping? In that case, I can see a need to include it twice - once in the request-uri and once in the "printer-uri" input parameter. Scott >>> Robert Herriot 07/21 3:10 PM >>> I sent the following on Friday. I hope that we all agree the two paragraphs below. From rherriot Fri Jul 18 13:08:35 1997 So, I think that we are in agreement that the model and protocol documents should state that the operations whose target is a Printer shall include a parameter called printer-uri and operations whose target is a job shall include a parameter called job-uri. Randy suggests that the value of job-uri/printer-uri could differ from the request-uri on the HTTP Request-Line, but the model has no such concept. So unless there are strong arguments to the contrary, the protocol document will state that the request-uri has the same value as the printer-uri/job-uri in the operation. Bob Herriot > From rdebry@us.ibm.com Mon Jul 21 10:34:32 1997 > From: Roger K Debry > To: > Subject: IPP>MOD - Job Identifier > Date: Mon, 21 Jul 1997 13:24:50 -0400 > Mime-Version: 1.0 > Sender: ipp-owner@pwg.org > X-Lines: 16 > > There has been a lot of discussion on the proposal made by Paul Moore on the > use of Job URL. > Unfortunately, there is no way to know if we really have consensus on the > proposal. I'd like to > see a re-statement of what we believe the agreed to changes are and some poll > of the discussion > list to see if we have a consensus. Would Bob and/or Paul be willing to do > this? > > > Roger K deBry > Senior Techncial Staff Member > Architecture and Technology > IBM Printing Systems > email: rdebry@us.ibm.com > phone: 1-303-924-4080 >   Received: from cnri by ietf.org id aa18649; 22 Jul 97 15:04 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid PAA25998 for ; Tue, 22 Jul 1997 15:03:11 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA00928 for ; Tue, 22 Jul 1997 14:46:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 22 Jul 1997 14:39:22 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA00465 for ipp-outgoing; Tue, 22 Jul 1997 14:32:11 -0400 (EDT) Date: Tue, 22 Jul 1997 14:31:50 -0400 (EDT) From: JK Martin Message-Id: <199707221831.OAA12123@uscore.underscore.com> To: Robert.Herriot@eng.sun.com Subject: Re: IPP>MOD - best effort Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Looks like we've been talking past each other, Bob. By "where applicable", I mean that the "best-effort" should be a an optional parameter for messages involving job submission. I believe we're saying the same thing. ...jay ----- Begin Included Message ----- From Robert.Herriot@Eng.Sun.COM Mon Jul 21 19:14 EDT 1997 Date: Mon, 21 Jul 1997 16:13:20 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) To: Robert.Herriot@Eng.Sun.COM, jkm@underscore.com Subject: Re: IPP>MOD - best effort Cc: ipp@pwg.org The semantics are more important to me than the name. If the group prefers "best-effort" to "may-ignore-attributes", that's OK with me. But what do you mean by "where applicable" below. I had in mind that "best-effort" would be a parameter and nothing else. It is behavior that occurs during receipt of a printer and has no existence past that point. Bob Herriot > From jkm@underscore.com Mon Jul 21 15:51:00 1997 > > Sorry, but what I meant to say was that there was no obviously > good reason to rename "best-effort" to "may-ignore-attributes". > (I guess you've since withdrawn such renaming...thanks.) > > I do, however, like moving "best-effort" to a parameter where > applicable. > > ...jay > > ----- Begin Included Message ----- > > From Robert.Herriot@Eng.Sun.COM Mon Jul 21 17:03 EDT 1997 > Date: Mon, 21 Jul 1997 14:03:35 -0700 > From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) > To: ipp@pwg.org, jkm@underscore.com, rdebry@us.ibm.com > Subject: Re: IPP>MOD - best effort > > There is plenty wrong with best-effort. Perhaps you didn't read the > fine print in the current model document. It is currently > defined as a job template attribute which means: > > o there is a job attribute "best-effort" for specifying what the > client wants. > o there is a printer default "best-effort" which says whether > the printer defaults it behavior to best-effort or not if a > client doesn't specify this attribute. > o there is a printer "best-effort-supported" attribute which is unlike > most xxx-supported attributes. It is not a set of possible > values, namely "true" and "false" values. Instead, it is either > "true" or "false" > * "true" means that a client can specify either the value > "true" or "false" or and the printer default "best-effort" > can have the value of true or false" > * "false" means that a client can specify only the value of > "false" and the default "best-effort" can have only the > value of "false". > NOTE: it is believed that no implementation would support > a "best-effort" job attribute of "true" only. > o this attribute has to be processed before others are processed > because it affects the processing of them, but it need not > be the first attribute. > o the "best-effort" substitution is somewhat undefined and > potentially complex. > > Compare the above with what I proposed: > > > o I replace 3 job-template attributes by a single parameter > "may-ignored-attributes" which is either true, false or omitted > (false is default). All printers support both values because > it is easier to support "best-effort" as "ignore the attribute". > > o I make it easy to process the "may-ignore-attributes" value before > any attributes are processed because the information is > in the parameter section which precedes any attributes. > > Now I suggest that we forget about "may-ignore-attributes" job > attribute, that I proposed. It really isn't necessary and deflects > from the discussion. The single parameter is sufficient. > > Do you still believe that the "3 job-template attributes" proposal is > simpler than the "single parameter" proposal? > > Bob Herriot > > > From jkm@underscore.com Mon Jul 21 07:58:51 1997 > > > > I completely agree with Roger. I just don't see the added value > > here...but I certainly see the additional complexity and resulting > > confusion. > > > > There is nothing wrong (semantically) with "best-effort". Let's > > leave it alone, but make the obvious clarifications in the Model > > document with regard to Job templates, etc. > > > > ...jay > > > > ----- Begin Included Message ----- > > > > From ipp-owner@pwg.org Mon Jul 21 10:01 EDT 1997 > > From: Roger K Debry > > To: > > Subject: IPP>MOD - best effort > > Date: Mon, 21 Jul 1997 09:54:56 -0400 > > > > >There should be an OPTIONAL job attribute may-ignore-attributes which > > >is set by the parameter may- ignore-attributes. This attribute is > > >MANDATORY if Create-Job is supported because Send-Document and Send-URI > > >use the value set by Create-Job. Otherwise, I wouldn't expect it to be > > >implemented. It would be useful in a future resubmit-job operation > > > > Now let me see, if I understand .... we don't like the concept of > > best-effort as an attribute, so we rename it, make it a parameter, then > > add an optional job attribute with the same name, and then have the > > parameter set the attribute, except sometimes the attribute (or is it > > the parameter) is mandatory. Did I get it right?????? > > > > Excuse me, but I think we just added a ton of confusion and didn't change > > things one bit! > > > > > > > > > > > > ----- End Included Message ----- > > > > > > > ----- End Included Message ----- > > > ----- End Included Message -----   Received: from cnri by ietf.org id aa21645; 22 Jul 97 16:09 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA26289 for ; Tue, 22 Jul 1997 16:08:16 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA01834 for ; Tue, 22 Jul 1997 16:04:36 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 22 Jul 1997 15:58:36 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA01377 for ipp-outgoing; Tue, 22 Jul 1997 15:51:25 -0400 (EDT) Date: Tue, 22 Jul 1997 12:51:50 -0700 From: Robert Herriot Message-Id: <199707221951.MAA10562@woden.eng.sun.com> To: rdebry@us.ibm.com Subject: Re: IPP>MOD - best effort Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I think that the sum total of your arguments in favor of keeping best-effort as a job-template parameter add up to an argument in favor of the single best-effort parameter. In each item below, you provide a workable solution, but each one is increasingly difficult to implement, especially the one that involves determining the value of best-effort before processing other attributes. But the bottom line question is, why do we need all of these implementation options for best-effort when all implementations have to deal with the issue of unsupported attributes and each of the two "best-effort" options is trivial to implement. That is, when a Printer encounters an unsupported attribute or value, it either rejects the job (best-effort=false) or ignores the attribute (best-effort=true). It seems like far more effort to implement, document and test the 3 best-effort job-template attributes (MANDATORY attributes with values that are OPTIONAL), than to fully support both values of a best-effort parameter. [ There is an additional comment about substitution at the end of this email. ] Bob Herriot > From rdebry@us.ibm.com Tue Jul 22 06:26:08 1997 > > Bob, You've clearly simplified things by > getting rid of the "may-ignore ..." job > attribute. But, I still believe that a > "best-effort" job template attribute is better > than a new parameter. To me, whether or not I want > the job to print, regardless of attribute errors, > is itself an attribute of the job. Let's keep > attributes attributes! > > o there is a job attribute "best-effort" for specifying what the > client wants. > > This is straightforward and consistent with it being > a job template attribute. I see no problem here. > > o there is a printer default "best-effort" which says whether > the printer defaults it behavior to best-effort or not if a > client doesn't specify this attribute. > > This is also simple and consistent. > > o there is a printer "best-effort-supported" attribute which is unlike > most xxx-supported attributes. It is not a set of possible > values, namely "true" and "false" values. Instead, it is either > "true" or "false" > > As you have written it down here, the rules are > not consistent with other job template atributes. > However, it seems that this is an easy fix. If a > Printer supports both "true" and "false" values, > then the xxx-supported should in fact be a set of > values, namely "true" and "false". This matches > what you have written below. Furthermore, if the > Printer only supports "false" then xxx-supported > has only one value, and that is "false". This also > matches what you have written below. Now I think > xxx-supported for "best-effort" is consistent with > other job template attributes. > > * "true" means that a client can specify either the value > "true" or "false" or and the printer default "best-effort" > can have the value of true or false" > * "false" means that a client can specify only the value of > "false" and the default "best-effort" can have only the > value of "false". > NOTE: it is believed that no implementation would support > a "best-effort" job attribute of "true" only. > > o this attribute has to be processed before others are processed > because it affects the processing of them, but it need not > be the first attribute. > > It appears that you can fix this problem in two ways. > Although it may require a little additional code to > implement, it is surely possible for the Printer to > handle the best-effort attribute in any place in the > sequence of received attributes. If everyone thinks > this is too hard, then you could mandate that if this > attribute is used it MUST be the first in the list. > Admittedly, this is a special rule for this attribute, > but in effect that's all you've done by declaring it > a parameter. > > o the "best-effort" substitution is somewhat undefined and > potentially complex. > > Its not clear why you think this is somewhat undefined > and potentially complex. Why is it different from any > other attribute? RGH: The model document uses the word "substitution" to (perhaps) RGH: mean that the Printer picks some value that may be other than RGH: the attribute's default value. For example, if a printer RGH: supports letter and B size paper with letter the default size, RGH: and if a client requests A3 paper, then B would be a good RGH: substitution using some undefined logic, and letter would RGH: be the simple substitution using the default. > >   Received: from cnri by ietf.org id aa22978; 22 Jul 97 16:34 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA26410 for ; Tue, 22 Jul 1997 16:33:32 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA02441 for ; Tue, 22 Jul 1997 16:29:51 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 22 Jul 1997 16:26:35 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA01998 for ipp-outgoing; Tue, 22 Jul 1997 16:19:22 -0400 (EDT) Message-Id: <3.0.1.32.19970722151935.00a134e0@mailhost.dazel.com> X-Sender: walker@mailhost.dazel.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 22 Jul 1997 15:19:35 -0500 To: Robert Herriot , rdebry@us.ibm.com From: Jim Walker Subject: Re: IPP>MOD - best effort Cc: ipp@pwg.org In-Reply-To: <199707221951.MAA10562@woden.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org One of the *negative* aspects of making best-effort a parameter of the operation instead of an attribute is that it would not be a persistent part of the job state. For example, if best-effort is not an attribute, I cannot query a job after it has been submitted, and find out whether it was submitted with best-effort or not. IMHO, this would be a bad thing; I would prefer that it stay an attribute. As for the xxx-supported feature of best-effort, I agree with Roger that it seems very simple to align a best-effort job template attribute with all of the other job template attributes. Finally, in terms of the placement of the best-effort attribute, I do not feel that it is burdensome to the implementation to allow it as an attribute, and allow it to occur anywhere in the sequence of job attributes. If anyone has a concrete example to the contrary, I would love to hear it. ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX   Received: from cnri by ietf.org id aa28980; 22 Jul 97 21:09 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid VAA27293 for ; Tue, 22 Jul 1997 21:08:09 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA05880 for ; Tue, 22 Jul 1997 21:04:29 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 22 Jul 1997 20:55:13 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA04918 for ipp-outgoing; Tue, 22 Jul 1997 20:42:04 -0400 (EDT) Date: Tue, 22 Jul 1997 17:42:44 -0700 From: Robert Herriot Message-Id: <199707230042.RAA10840@woden.eng.sun.com> To: Robert.Herriot@eng.sun.com, rdebry@us.ibm.com, walker@dazel.com Subject: Re: IPP>MOD - best effort Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > From walker@dazel.com Tue Jul 22 13:22:23 1997 > > Finally, in terms of the placement of the best-effort attribute, I do > not feel that it is burdensome to the implementation to allow it as an > attribute, and allow it to occur anywhere in the sequence of job > attributes. If anyone has a concrete example to the contrary, I > would love to hear it. RGH: Best-effort is the only attribute whose value affects the processing RGH: of other attributes while the Printer is acquiring the attributes RGH: from the operation. RGH: If best-effort remains an attribute, an implementation must acquire the RGH: value of best-effort before it validates any other attributes. This is RGH: a constraint which may or may not cause implementors a problem, but it RGH: does create a potential look-ahead problem. RGH: If best-effort becomes a parameter, it will always precede all RGH: attributes, leaving more flexibility for the implementor. I prefer a RGH: design that avoids look-ahead problems as much as possible. RGH: Bob Herriot > > ...walker > > -- > Jim Walker   Received: from cnri by ietf.org id aa28987; 22 Jul 97 21:09 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid VAA27296 for ; Tue, 22 Jul 1997 21:08:14 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA05886 for ; Tue, 22 Jul 1997 21:04:32 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 22 Jul 1997 20:56:55 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA04929 for ipp-outgoing; Tue, 22 Jul 1997 20:44:02 -0400 (EDT) Date: Tue, 22 Jul 1997 20:44:16 -0400 (EDT) From: JK Martin Message-Id: <199707230044.UAA18126@uscore.underscore.com> To: ipp@pwg.org Subject: IPP> SEC - SASL will soon go to IETF Wide (4 week) Last Call (fwd) X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org This should be of interest to the IPP Security subgroup. ...jay ----- Begin Included Message ----- From ietf-acap-request@andrew.cmu.edu Tue Jul 22 19:14 EDT 1997 Date: Tue, 22 Jul 1997 15:54:05 -0700 (PDT) From: Chris Newman Subject: SASL will soon go to IETF Wide (4 week) Last Call (fwd) To: Application Authentication/Authorization List , IETF ACAP Mailing List Originator-Info: login-id=chris; server=thor.innosoft.com I believe this is of interest to this mailing list. ---------- Forwarded message ---------- Date: Tue, 22 Jul 1997 17:53:54 -0400 From: "Jeffrey I. Schiller" Reply-To: ietf-tls@consensus.com To: ietf-tls@consensus.com Subject: SASL will soon go to IETF Wide (4 week) Last Call -----BEGIN PGP SIGNED MESSAGE----- I have just requested that the document: "Simple Authentication and Security Layer (SASL)" go to IETF wide last call. Because this document is not the product of an IETF working group, I have requested a 4 week last call. How TLS would interact with this proposal is articulated in an Appendix. -Jeff -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQCVAwUBM9UZnMUtR20Nv5BtAQF1ZQQAmjsS6lIdxmg9DvaHKATFAfgVP2tCQs0d OlkeSC5vzdoR9w0IRrghyZT1wae5dODJl1VD0cuqbvE4MqOqEA0Q/UI1Rks+nQt1 CSEoJqMmOUcNaePGP5LJTv/m71xrSolq4vJhIiXcCKlBrR/aB80k0rHr6LJArw9C HHTpdPgaDIM= =3zo6 -----END PGP SIGNATURE----- ----- End Included Message -----   Received: from cnri by ietf.org id aa02010; 22 Jul 97 22:51 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid WAA27477 for ; Tue, 22 Jul 1997 22:49:42 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA06740 for ; Tue, 22 Jul 1997 22:46:03 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 22 Jul 1997 22:42:20 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA06263 for ipp-outgoing; Tue, 22 Jul 1997 22:35:10 -0400 (EDT) Message-Id: <1.5.4.32.19970723023040.006c1004@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, 22 Jul 1997 19:30:40 -0700 To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Agenda for PWG IPP Phone Conference 970723 Sender: ipp-owner@pwg.org Hi, I do not have much of a specific agenda for tomorrow's conference, but suggest that we make our "best effort" :-} to resolve the remaining IPP issues, concerning the Model and Protocol documents in particular. We should also discuss the final editing round for all of our documents as input for Munich. Carl-Uno   Received: from cnri by ietf.org id aa11744; 23 Jul 97 11:33 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid LAA28902 for ; Wed, 23 Jul 1997 11:32:04 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA09089 for ; Wed, 23 Jul 1997 11:28:28 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 23 Jul 1997 11:19:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA08608 for ipp-outgoing; Wed, 23 Jul 1997 11:12:00 -0400 (EDT) From: Roger K Debry To: ipp@pwg.org, Robert.herriot@eng.sun.com MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: Re: IPP>MOD - best effort Message-Id: <5030100005189898000002L082*@MHS> Date: Wed, 23 Jul 1997 11:13:28 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Bob, I doubt that we will ever convince one aother! I've seen a couple of comments from others on the subject. Jim Walker made a good point on the persistence of parameters vs. attributes. Jay seemed to have moved in favor of your proposal based on getting rid of the corresponding job attribute. But, I don't know that we have a good resolution process in cases like this. I don't particulalrly want to debate the issue any longer, I'll go along with whatever consensus we reach as a group. However, I'm not willing to give in without some group resolution process being executed. 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 07/23/97 09:00 AM --------------------------- ipp-owner @ pwg.org 07/22/97 04:36 PM Please respond to ipp-owner@pwg.org @ internet To: Roger K Debry/Boulder/IBM cc: ipp @ pwg.org @ internet Subject: Re: IPP>MOD - best effort I think that the sum total of your arguments in favor of keeping best-effort as a job-template parameter add up to an argument in favor of the single best-effort parameter. In each item below, you provide a workable solution, but each one is increasingly difficult to implement, especially the one that involves determining the value of best-effort before processing other attributes. But the bottom line question is, why do we need all of these implementation options for best-effort when all implementations have to deal with the issue of unsupported attributes and each of the two "best-effort" options is trivial to implement. That is, when a Printer encounters an unsupported attribute or value, it either rejects the job (best-effort=false) or ignores the attribute (best-effort=true). It seems like far more effort to implement, document and test the 3 best-effort job-template attributes (MANDATORY attributes with values that are OPTIONAL), than to fully support both values of a best-effort parameter. [ There is an additional comment about substitution at the end of this email. ] Bob Herriot > From rdebry@us.ibm.com Tue Jul 22 06:26:08 1997 > > Bob, You've clearly simplified things by > getting rid of the "may-ignore ..." job > attribute. But, I still believe that a > "best-effort" job template attribute is better > than a new parameter. To me, whether or not I want > the job to print, regardless of attribute errors, > is itself an attribute of the job. Let's keep > attributes attributes! > > o there is a job attribute "best-effort" for specifying what the > client wants. > > This is straightforward and consistent with it being > a job template attribute. I see no problem here. > > o there is a printer default "best-effort" which says whether > the printer defaults it behavior to best-effort or not if a > client doesn't specify this attribute. > > This is also simple and consistent. > > o there is a printer "best-effort-supported" attribute which is unlike > most xxx-supported attributes. It is not a set of possible > values, namely "true" and "false" values. Instead, it is either > "true" or "false" > > As you have written it down here, the rules are > not consistent with other job template atributes. > However, it seems that this is an easy fix. If a > Printer supports both "true" and "false" values, > then the xxx-supported should in fact be a set of > values, namely "true" and "false". This matches > what you have written below. Furthermore, if the > Printer only supports "false" then xxx-supported > has only one value, and that is "false". This also > matches what you have written below. Now I think > xxx-supported for "best-effort" is consistent with > other job template attributes. > > * "true" means that a client can specify either the value > "true" or "false" or and the printer default "best-effort" > can have the value of true or false" > * "false" means that a client can specify only the value of > "false" and the default "best-effort" can have only the > value of "false". > NOTE: it is believed that no implementation would support > a "best-effort" job attribute of "true" only. > > o this attribute has to be processed before others are processed > because it affects the processing of them, but it need not > be the first attribute. > > It appears that you can fix this problem in two ways. > Although it may require a little additional code to > implement, it is surely possible for the Printer to > handle the best-effort attribute in any place in the > sequence of received attributes. If everyone thinks > this is too hard, then you could mandate that if this > attribute is used it MUST be the first in the list. > Admittedly, this is a special rule for this attribute, > but in effect that's all you've done by declaring it > a parameter. > > o the "best-effort" substitution is somewhat undefined and > potentially complex. > > Its not clear why you think this is somewhat undefined > and potentially complex. Why is it different from any > other attribute? RGH: The model document uses the word "substitution" to (perhaps) RGH: mean that the Printer picks some value that may be other than RGH: the attribute's default value. For example, if a printer RGH: supports letter and B size paper with letter the default size, RGH: and if a client requests A3 paper, then B would be a good RGH: substitution using some undefined logic, and letter would RGH: be the simple substitution using the default. > >   Received: from cnri by ietf.org id aa15384; 23 Jul 97 14:10 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid OAA29562 for ; Wed, 23 Jul 1997 14:09:23 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA11629 for ; Wed, 23 Jul 1997 14:05:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 23 Jul 1997 13:58:20 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA11090 for ipp-outgoing; Wed, 23 Jul 1997 13:50:15 -0400 (EDT) Date: Wed, 23 Jul 1997 13:50:31 -0400 (EDT) From: JK Martin Message-Id: <199707231750.NAA12580@uscore.underscore.com> To: ipp@pwg.org Subject: Re: IPP>MOD - best effort X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org After reading Jim Walker's comments on this issue, I find myself somewhat ambivalent on whether "best-effort" should be a parameter or a job attribute. Jim's made some good observations in support of the attribute approach, and Roger feels pretty strongly about having it as an attribute, too. I can go either way. Roger's right, though. Let's resolve this issue pronto and move on to other issues. ...jay ----- Begin Included Message ----- From ipp-owner@pwg.org Wed Jul 23 11:20 EDT 1997 From: Roger K Debry To: , Subject: Re: IPP>MOD - best effort Date: Wed, 23 Jul 1997 11:13:28 -0400 Bob, I doubt that we will ever convince one aother! I've seen a couple of comments from others on the subject. Jim Walker made a good point on the persistence of parameters vs. attributes. Jay seemed to have moved in favor of your proposal based on getting rid of the corresponding job attribute. But, I don't know that we have a good resolution process in cases like this. I don't particulalrly want to debate the issue any longer, I'll go along with whatever consensus we reach as a group. However, I'm not willing to give in without some group resolution process being executed. 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 07/23/97 09:00 AM --------------------------- ipp-owner @ pwg.org 07/22/97 04:36 PM Please respond to ipp-owner@pwg.org @ internet To: Roger K Debry/Boulder/IBM cc: ipp @ pwg.org @ internet Subject: Re: IPP>MOD - best effort I think that the sum total of your arguments in favor of keeping best-effort as a job-template parameter add up to an argument in favor of the single best-effort parameter. In each item below, you provide a workable solution, but each one is increasingly difficult to implement, especially the one that involves determining the value of best-effort before processing other attributes. But the bottom line question is, why do we need all of these implementation options for best-effort when all implementations have to deal with the issue of unsupported attributes and each of the two "best-effort" options is trivial to implement. That is, when a Printer encounters an unsupported attribute or value, it either rejects the job (best-effort=false) or ignores the attribute (best-effort=true). It seems like far more effort to implement, document and test the 3 best-effort job-template attributes (MANDATORY attributes with values that are OPTIONAL), than to fully support both values of a best-effort parameter. [ There is an additional comment about substitution at the end of this email. ] Bob Herriot > From rdebry@us.ibm.com Tue Jul 22 06:26:08 1997 > > Bob, You've clearly simplified things by > getting rid of the "may-ignore ..." job > attribute. But, I still believe that a > "best-effort" job template attribute is better > than a new parameter. To me, whether or not I want > the job to print, regardless of attribute errors, > is itself an attribute of the job. Let's keep > attributes attributes! > > o there is a job attribute "best-effort" for specifying what the > client wants. > > This is straightforward and consistent with it being > a job template attribute. I see no problem here. > > o there is a printer default "best-effort" which says whether > the printer defaults it behavior to best-effort or not if a > client doesn't specify this attribute. > > This is also simple and consistent. > > o there is a printer "best-effort-supported" attribute which is unlike > most xxx-supported attributes. It is not a set of possible > values, namely "true" and "false" values. Instead, it is either > "true" or "false" > > As you have written it down here, the rules are > not consistent with other job template atributes. > However, it seems that this is an easy fix. If a > Printer supports both "true" and "false" values, > then the xxx-supported should in fact be a set of > values, namely "true" and "false". This matches > what you have written below. Furthermore, if the > Printer only supports "false" then xxx-supported > has only one value, and that is "false". This also > matches what you have written below. Now I think > xxx-supported for "best-effort" is consistent with > other job template attributes. > > * "true" means that a client can specify either the value > "true" or "false" or and the printer default "best-effort" > can have the value of true or false" > * "false" means that a client can specify only the value of > "false" and the default "best-effort" can have only the > value of "false". > NOTE: it is believed that no implementation would support > a "best-effort" job attribute of "true" only. > > o this attribute has to be processed before others are processed > because it affects the processing of them, but it need not > be the first attribute. > > It appears that you can fix this problem in two ways. > Although it may require a little additional code to > implement, it is surely possible for the Printer to > handle the best-effort attribute in any place in the > sequence of received attributes. If everyone thinks > this is too hard, then you could mandate that if this > attribute is used it MUST be the first in the list. > Admittedly, this is a special rule for this attribute, > but in effect that's all you've done by declaring it > a parameter. > > o the "best-effort" substitution is somewhat undefined and > potentially complex. > > Its not clear why you think this is somewhat undefined > and potentially complex. Why is it different from any > other attribute? RGH: The model document uses the word "substitution" to (perhaps) RGH: mean that the Printer picks some value that may be other than RGH: the attribute's default value. For example, if a printer RGH: supports letter and B size paper with letter the default size, RGH: and if a client requests A3 paper, then B would be a good RGH: substitution using some undefined logic, and letter would RGH: be the simple substitution using the default. > > ----- End Included Message -----   Received: from cnri by ietf.org id aa15558; 23 Jul 97 14:16 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid OAA29595 for ; Wed, 23 Jul 1997 14:15:19 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA12156 for ; Wed, 23 Jul 1997 14:11:42 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 23 Jul 1997 14:08:12 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA11141 for ipp-outgoing; Wed, 23 Jul 1997 13:57:10 -0400 (EDT) Date: Wed, 23 Jul 1997 13:57:21 -0400 (EDT) From: JK Martin Message-Id: <199707231757.NAA13054@uscore.underscore.com> To: ipp@pwg.org Subject: IPP> MOD - Is "best-effort" a new printing system feature? X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org While trying to resolve the parameter-vs-attribute issue for "best-effort", no one (to my knowledge) has offered up any example of such a feature in any currently deployed printing system. That is, is the concept and mechanism of "best-effort" something NEW to the printing world? (It certainly doesn't seem specific to Web printing, by any means.) If there are no obvious reference implementations for handling "best-effort" in the world today, then it would appear that we are addressing a GENERIC printing system feature, and not something specific to the Web (ie, Internet Printing). Just an observation. However, if there are no printing systems today that deal with "best-effort", then we had best resolve this issue very, very quickly, as it adds no real value to the concept of Internet Printing. Best-effort is definitely a great feature, but we've spent far too many cycles on this one aspect of IPP, IMHO. ...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 -- ----------------------------------------------------------------------   Received: from cnri by ietf.org id aa20667; 23 Jul 97 17:32 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA00553 for ; Wed, 23 Jul 1997 17:30:45 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA14703 for ; Wed, 23 Jul 1997 17:27:09 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 23 Jul 1997 17:23:33 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA13738 for ipp-outgoing; Wed, 23 Jul 1997 17:12:22 -0400 (EDT) Message-ID: <33D673B0.1A1D@parc.xerox.com> Date: Wed, 23 Jul 1997 14:12:16 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> Using MIME types instead of enumerations for document formats Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org I asked about the difference between IPP's use of enumeration for describing document formats vs. IFAX (and other communication protocols using MIME) and I was told: > we are proposing to use the enums from the > Printer MIB, which is already on the Internet standards track before IPP, > using SNMP as protocol, so it is only a matter of which Internet standard > we align with. The majority of the people active in the PWG and IPP has > seen alignment with the Printer MIB and Job Monitoring MIB as more > important than with MIME, which has led to the current proposal. However, I believe alignment isn't made for philosophical or religious or affinity or historical reasons, it's made for engineering reasons. The MIBs for printers and job monitoring are used for monitoring the status and network failure of devices. However, IPP is not used primarily for monitoring, it's used for communication. MIME and Internet Media Types are used for communicating the types of messages used in communication, and seem like they're more appropriate to the intent of IPP, which is to communicate a printable job from a client to a printer. Having yet another registry of document formats just for printing doesn't seem like a great idea. Is this decision irrevokable? Larry   Received: from cnri by ietf.org id aa20982; 23 Jul 97 17:46 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA00618 for ; Wed, 23 Jul 1997 17:44:53 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA15277 for ; Wed, 23 Jul 1997 17:41:17 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 23 Jul 1997 17:38:01 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA14781 for ipp-outgoing; Wed, 23 Jul 1997 17:30:40 -0400 (EDT) From: THERESA_RHOADES@hp-boise-om8.om.hp.com X-Openmail-Hops: 1 Date: Wed, 23 Jul 97 15:30:48 -0600 Message-Id: Subject: IPP> JetSend To: ipp@pwg.org Sender: ipp-owner@pwg.org Item Subject: cc:Mail Text Greetings, Hewlett-Packard has just annouched a new protocol for peer-to- peer device interaction called JetSend. It might be of interest to this group. Please have a look at our web site which contains white papers as well as a complete protocol specification: http://www.jetsend.hp.com Thanks, Theresa Rhoades Inormation Appliance Operation Hewlett-Packard email: theresa_rhoades@hp.com   Received: from cnri by ietf.org id aa23836; 23 Jul 97 20:55 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid UAA01151 for ; Wed, 23 Jul 1997 20:54:33 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA17385 for ; Wed, 23 Jul 1997 20:50:57 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 23 Jul 1997 20:47:09 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA16895 for ipp-outgoing; Wed, 23 Jul 1997 20:39:54 -0400 (EDT) From: Stephen Zilles Message-Id: <199707240039.RAA26666@bulletin> To: ipp@pwg.org Subject: IPP> ADM - Issues List for Seattle Meeting Phone: (408) 536-4766 Fax: (408) 537-4042 Office: W14-504 Cc: szilles@adobe.com Date: Wed, 23 Jul 1997 17:39:33 PDT Sender: ipp-owner@pwg.org ACTION REQUIRED Would all document editors please collect the issues that are within their documents, extract these into a separate MS Word (.doc) file and place this file in the same directory as their document would go. Please name this file "ISSUESxx.doc" where xx is only needed to distinguish ISSUEs files when more than one document is in the same folder. Please do this by Wednesday, July 30 (This is the last date to submit an I-D to IETF for Munich). Tom Hastings has volunteered to assemble these collections into a single overall issues list and distribute this by the end of that week so that people will have time to review this list for the Seattle meeting. Steve Zilles   Received: from cnri by ietf.org id aa02053; 24 Jul 97 0:00 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid XAA01408 for ; Wed, 23 Jul 1997 23:59:13 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA18257 for ; Wed, 23 Jul 1997 23:55:32 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 23 Jul 1997 23:51:28 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA17758 for ipp-outgoing; Wed, 23 Jul 1997 23:44:10 -0400 (EDT) Message-Id: <3.0.1.32.19970723203519.00b72100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 23 Jul 1997 20:35:19 PDT To: JK Martin , ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> MOD - Is "best-effort" a new printing system feature? In-Reply-To: <199707231757.NAA13054@uscore.underscore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Jay, see my comment below. Carl-Uno At 10:57 AM 7/23/97 PDT, JK Martin wrote: >While trying to resolve the parameter-vs-attribute issue for >"best-effort", no one (to my knowledge) has offered up any >example of such a feature in any currently deployed printing >system. > >That is, is the concept and mechanism of "best-effort" something >NEW to the printing world? (It certainly doesn't seem specific >to Web printing, by any means.) > >If there are no obvious reference implementations for handling >"best-effort" in the world today, then it would appear that we >are addressing a GENERIC printing system feature, and not >something specific to the Web (ie, Internet Printing). > >Just an observation. However, if there are no printing systems >today that deal with "best-effort", then we had best resolve >this issue very, very quickly, as it adds no real value to >the concept of Internet Printing. In earlier discussions I have maintained that "best effort" is what most every printing system does today (think font substitution & media substitution for a start). In my view, the NEW feature is for a printing system to guarantee full fidelity and that that it will adhere to ALL attribute values asked for in a print request, or refuse the job. > >Best-effort is definitely a great feature, but we've spent far >too many cycles on this one aspect of IPP, IMHO. > > ...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 -- >---------------------------------------------------------------------- > > 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   Received: from cnri by ietf.org id aa05992; 24 Jul 97 9:30 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid JAA02028 for ; Thu, 24 Jul 1997 09:28:50 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA20214 for ; Thu, 24 Jul 1997 09:25:03 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 24 Jul 1997 09:14:56 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA19744 for ipp-outgoing; Thu, 24 Jul 1997 09:07:43 -0400 (EDT) From: don@lexmark.com Message-Id: <199707241308.AA11629@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Thu, 24 Jul 1997 09:07:58 -0400 Subject: IPP> Conference Calls (cancel 7/30 and add 8/20, 8/27) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org As a result of a decision on yesterday's conference call, I have cancelled the conference call for next week (July 30th.) While I was on the phone, I went ahead and scheduled the next two conference calls as follows: Dates 8/20 & 8/27 Call-in 1-423-523-7162 Access 190148 Time 4PM EDT, 1PM PDT I scheduled no conference calls for 8/6 and 8/13 since those are in the middle of the PWG IPP meetings and the IETF Munich meetings respectively. Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * **********************************************   Received: from cnri by ietf.org id aa12109; 24 Jul 97 13:33 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA03089 for ; Thu, 24 Jul 1997 13:32:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA22571 for ; Thu, 24 Jul 1997 13:28:32 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 24 Jul 1997 13:18:56 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA21765 for ipp-outgoing; Thu, 24 Jul 1997 13:09:53 -0400 (EDT) From: THERESA_RHOADES@hp-boise-om8.om.hp.com X-Openmail-Hops: 1 Date: Thu, 24 Jul 97 11:09:52 -0600 Message-Id: Subject: IPP> August Meeting Agenda Mime-Version: 1.0 To: ipp@pwg.org, p1394@pwg.org Content-Type: text/plain; charset=US-ASCII; name="cc:Mail" Content-Disposition: inline; filename="cc:Mail" Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org I would be interested in knowing the agenda items planned for the August p1394 and IPP meetings. Is there a detailed agenda available somewhere? Thanks, Theresa Rhoades Information Appliance Division Hewlett-Packard Theresa_Rhoades@hp.com   Received: from cnri by ietf.org id aa15669; 24 Jul 97 16:00 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid PAA04055 for ; Thu, 24 Jul 1997 15:58:52 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA25100 for ; Thu, 24 Jul 1997 15:55:16 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 24 Jul 1997 15:49:57 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA24625 for ipp-outgoing; Thu, 24 Jul 1997 15:42:43 -0400 (EDT) Message-Id: <1.5.4.32.19970724193948.006af930@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: Thu, 24 Jul 1997 12:39:48 -0700 To: THERESA_RHOADES@hp-boise-om8.om.hp.com, ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> August Meeting Agenda Sender: ipp-owner@pwg.org I have not yet sent out an agenda for the IPP meeting, but we will spend the meeting going over all our new documents in detail to check that we have consistency througout and to attempt to resolve any lingering issues that are not yet fully agreed. We will also discuss and prepare for the Munich IETF meeting. Carl-Uno At 11:09 AM 7/24/97 -0600, THERESA_RHOADES@HP-Boise-om8.om.hp.com wrote: > I would be interested in knowing the agenda items planned for the > August p1394 and IPP meetings. Is there a detailed agenda available > somewhere? > > > Thanks, > > Theresa Rhoades > > Information Appliance Division > Hewlett-Packard > Theresa_Rhoades@hp.com > > >   Received: from cnri by ietf.org id aa17328; 24 Jul 97 17:12 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA04381 for ; Thu, 24 Jul 1997 17:10:49 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA26493 for ; Thu, 24 Jul 1997 17:07:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 24 Jul 1997 17:01:43 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA25617 for ipp-outgoing; Thu, 24 Jul 1997 16:52:20 -0400 (EDT) Date: Thu, 24 Jul 1997 13:53:02 -0700 From: Robert Herriot Message-Id: <199707242053.NAA13117@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>ADM changes to ABNF notation -- editors: please note X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I have received a reply from drums about changes to ABNF. Some of these changes affect our documents. The changes are (for draft 3): 1) ranges are now specified with a hyphen, e.g. %x41-5A 2) ranges cannot be used with strings, e.g. ALPHA = "A"-"Z" is no longer allowed, instead one must use ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 3) the list notation with "#" no longer exists. Bob Herriot   Received: from cnri by ietf.org id aa19981; 24 Jul 97 19:19 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid TAA04814 for ; Thu, 24 Jul 1997 19:18:35 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA29147 for ; Thu, 24 Jul 1997 19:14:59 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 24 Jul 1997 19:11:29 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA28660 for ipp-outgoing; Thu, 24 Jul 1997 19:04:07 -0400 (EDT) X-Sender: szilles@elroy (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="============_-1342333354==_============" Date: Thu, 24 Jul 1997 16:05:30 -0800 To: ipp@pwg.org From: Steve Zilles Subject: IPP> ADM - Minutes from 7/23/97 Phone Conference Cc: szilles@adobe.com Sender: ipp-owner@pwg.org --============_-1342333354==_============ Content-Type: text/plain; charset="us-ascii" Attached are the minutes of the Phone conference on July 23. Would someone please post them to the correct place on the FTP/Web sites. Steve --============_-1342333354==_============ Content-Type: text/plain; name="phone.mtg.97.07.23.minutes.txt"; charset="us-ascii" Content-Disposition: attachment; filename="phone.mtg.97.07.23.minutes.txt" Minutes of IPP Phone Meeting, July 23, 1997 by S. Zilles Meeting commenced at 1PM PDT Attendees Carl-Uno Manros Tom Hastings Lee Farrell Jim Walker Jay Martin Steve Zilles Stan McConnell Bob Herriott Roger deBry (late) Don Wright (late) Revised drafts should be sent to Internet-Drafts@ietf.org All document authors should extract all the issues related to their document and post this collection in Word format (.doc) in the relevant section of the IPP FTP site; that is, in the same section that the version of the document sent to the IETF is put. Please do this by Wednesday, July 30 and Tom Hastings will then combine the issue list and post it to the working group so people will have time to review it before the Seattle meeting. All documents should refer to the "requirements document" as: "Requirements for an Internet Printing Protocol" Requirements document It was observed that some of the scenarios in the current I-D are out of date (w.r.t. the model); it was agreed that updating this document was not critical for Munich so that such updates would be delayed until an informational RFC can be prepared. LPD Mapping Document Bob Herriot is re-editing the document to fix errors, to shift the focus from how to what (exp w.r.t. Short and Long LPQ forms). Bob will provide this draft to Tom no later than July 29. Tom Hastings will prepare the .01 draft and send it to the IETF for publication for Munich. Architecture Doc Steve Zilles will produce a new draft and submit it by Tuesday, July 29. Protocol Doc Validate Agreed that agreement with Sylvan was that PrintJob, and Validate had the same syntax (and semantics) except for including the print data. Agreed that Validate only checks the parameters and attributes and not the content. Agreed that Validate is mainly there to allow checking of the parameters and attributes prior to doing a PrintJob. Because the PrintURI does not send any print data, a separate validate is not necessary for PrintURI Client Closing connection before data transfer is completed because processing of the print data can begin before all the data has arrived, it is necessary to specify what the printer does if the connection drops during data transmission. This is treated as if the job were cancel at the time the connection dropped. Handling a CreateJob for which data does not arrive Because the client may never receive the response or may fail to send documents, there should be a time out on resource reserving operations. This time out needs to be configurable (and probably the model should have a value to say what this time out is. Extending Tag values Agreed that no tag values were allocated for private extensions, in part because the tag value space is small and that providing extension values has often been abused in the past; e.g., there are plenty of MIME types that being "x-" and are in common usage. Issue: Should adding a new data type be a Type 1 or a Type 2 extension? (Some people on call were leaning toward it being Type 2.) It was agreed that if they were Type 2 the review process should have greater scrutiny than adding a new attribute. Inclusion of Appendix B Agreed that this appendix would be removed from the I-D, but the information would be retained in case it might be needed in the future. A possible reason for not using POST in IPP It has been pointed out that today POST is most often used for forms processing and that such processing is often done without doing authentication. If IPP uses POST and the same server is used to service both forms and print operations, then putting in authentication for one would require authentication for all POSTs (at least in some server architectures). This could add extra processing time for all POST and could in some case increase the processing of Forms. (Note that this only for HTTP authentication and not TLS authentication.) Model and Directory Status unknown, Scott believed to be working on getting an updated I-D to the IETF by July 30. Issue: how should the format of the content to be printed be identified: Printer MIB enum or MIME type. The current spec uses Printer MIB enum to insure that querying via the Printer MIB and via the IPP Model will give the same answers. Alternatively, identifying the content by the a MIME type means that any applications other than printing can also identify the format; for example an application that picked up already formatted print data and printed it would not have to translate from a MIME type description into a Printer MIB enum description. Issue was left open, but current model specifies that the Printer MIB enum shoud be used. Security Document Roger will update the security document and send off to the IETF by Tuesday, Drums has changed the handling of ranges, but has left an ambiguity as to whether a hyphen or a colon is used for range specs. Status of presentation of IPP to consultants in August This is an activity of either the PWG or the participating companies. targetted consultants: Gartner, IDC, Lyra, DataPro and MetaGroup planning to do it in Boston: there was a slight preference for the last week of August; Roger will test both the 20th and 27th of August. This meeting would be completely separate from any IBM announcements. Meeting adjourned at 3PM PDT. --============_-1342333354==_============--   Received: from cnri by ietf.org id aa20121; 24 Jul 97 19:31 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid TAA04843 for ; Thu, 24 Jul 1997 19:29:51 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA29759 for ; Thu, 24 Jul 1997 19:26:15 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 24 Jul 1997 19:22:48 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA29148 for ipp-outgoing; Thu, 24 Jul 1997 19:15:01 -0400 (EDT) Date: Thu, 24 Jul 1997 16:15:38 -0700 From: Robert Herriot Message-Id: <199707242315.QAA13230@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO best-effort and the LPD gateway X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Now that I have completed the first pass of fixing the LPD gateway document. I have some further reasons why ALL IMPLEMENTATIONS SHOULD SUPPORT BOTH VALUES OF BEST-EFFORT (which eliminates the need for a best-effort-supported). The current model document requires support for best-effort=false only. But for the LPD-to-IPP gateway, IPP support for best-effort=true makes things a whole lot easier because the gateway can translate LPD functions to IPP attributes knowing that the attributes will not cause the IPP operation to be rejected. Without such support, the gateway must perform a Get-Attributes to find out what the IPP printer supports and only send those attributes. The attributes that the gateway needs to send are: o job-name, o job-sheets (standard or none), o notification-events, o notification-method, o document-name and o document-format. All of these attributes, except job-name are optional, and none of them affect the final output. So rejection of a job because of attribute non-support would be very unfriendly. So this is my concrete reason why all implementations must support both values of best-effort and why it therefore should be a mandatory parameter rather than a job-template attribute with a fixed set of values that no client needs to query. Bob Herriot   Received: from cnri by ietf.org id aa20684; 24 Jul 97 20:12 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid UAA04954 for ; Thu, 24 Jul 1997 20:11:12 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA00869 for ; Thu, 24 Jul 1997 20:07:37 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 24 Jul 1997 20:04:21 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA00126 for ipp-outgoing; Thu, 24 Jul 1997 19:55:27 -0400 (EDT) Date: Thu, 24 Jul 1997 16:56:10 -0700 From: Robert Herriot Message-Id: <199707242356.QAA13307@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>SEC >MOD security and the LPD gateway X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org As I work on the LPD gateway document, I realize, once again, that the security documents don't deal with two attributes that we in the model have assumed would be handled at the security level. These attributes are: o job-originating-user o job-originating-host The LPD-to-IPP gateway receives these two values in the control file and the IPP-to-LPD gateway needs to put these into the control file. There may be work-arounds for the gateway. But that still leaves these two job attributes without any way to set them unless we make them explicit parameters in operations or create new HTTP headers. Comments? Bob Herriot   Received: from cnri by ietf.org id aa10747; 25 Jul 97 10:18 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid KAA06404 for ; Fri, 25 Jul 1997 10:17:15 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA04932 for ; Fri, 25 Jul 1997 10:13:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 25 Jul 1997 10:05:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA04445 for ipp-outgoing; Fri, 25 Jul 1997 09:57:42 -0400 (EDT) From: Roger K Debry To: ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: IPP>SEC >MOD security and the LPD gateway Message-Id: <5030100005308786000002L062*@MHS> Date: Fri, 25 Jul 1997 09:59:03 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Doesn't digest or http basic authentication handle this? It certainly can identify the user. 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 07/25/97 07:52 AM --------------------------- ipp-owner @ pwg.org 07/24/97 06:08 PM Please respond to ipp-owner@pwg.org @ internet To: ipp @ pwg.org @ internet cc: Subject: IPP>SEC >MOD security and the LPD gateway As I work on the LPD gateway document, I realize, once again, that the security documents don't deal with two attributes that we in the model have assumed would be handled at the security level. These attributes are: o job-originating-user o job-originating-host The LPD-to-IPP gateway receives these two values in the control file and the IPP-to-LPD gateway needs to put these into the control file. There may be work-arounds for the gateway. But that still leaves these two job attributes without any way to set them unless we make them explicit parameters in operations or create new HTTP headers. Comments? Bob Herriot   Received: from cnri by ietf.org id aa02320; 25 Jul 97 14:37 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid OAA07833 for ; Fri, 25 Jul 1997 14:36:23 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA06961 for ; Fri, 25 Jul 1997 14:32:47 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 25 Jul 1997 14:29:23 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA06499 for ipp-outgoing; Fri, 25 Jul 1997 14:22:05 -0400 (EDT) Date: Fri, 25 Jul 97 10:39:08 -0800 From: Peter Michalek Subject: IPP> IPP - current documents and implementation To: ipp@pwg.org X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <5030100005308786000002L062*@MHS> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org I just subscribed to this mailing list 2 days ago and would like some basic information: I read the documents: HTTP 1.1 as a Transport for the Internet Printing Protocol (draft-turner-ipp-trans-develop-00) Requirements for an Internet Printing Protocol: draft-ietf-ipp-req-00.txt Internet Printing Protocol - Level 1 (Simple Web Printing Protocol): Ipp-level1 PWG IPP Charter RFC1867: Form-based File Upload in HTML RFC1179: Line Printer Daemon Protocol RFC1759: Printer MIB and also the FAQ posted at www.pwg.org. --- I am thinking of starting to design and implement a basic version of IPP, but I am not sure if this is good timing (since the protocols design is not finished) or if maybe there already is a basic implementation that I could use. Could someone answer these questions for me: * Are there additional documents or information related to ipp other than those at www.pwg.org? * Do you hold any face-to-face meetings that I could attend in the Bay Area? * Are your phone conferences accessible for me? * Is there some reference implementation that is publicly available or that someone is selling? * Do you think it's worth-while starting to implement IPP at this stage? * What's ipp pwg's take on SWP from MS and HP? Would that perhaps be a good candidate for a first implementation of IPP since it's simple? * is ISO 10175 available on the Web? I'd be thankful for any info. Peter -------------------------------------------------------- Peter Michalek, ShineSoft Systems Voice, Fax: (408) 446-5040 10025 Crescent Rd. Cupertino, CA 95014 mailto:peterm@shinesoft.com http://www.shinesoft.com   Received: from cnri by ietf.org id aa02723; 25 Jul 97 14:53 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid OAA07920 for ; Fri, 25 Jul 1997 14:51:55 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA07706 for ; Fri, 25 Jul 1997 14:48:19 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 25 Jul 1997 14:44:58 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA07061 for ipp-outgoing; Fri, 25 Jul 1997 14:36:33 -0400 (EDT) Message-ID: <33D8F36F.B032952D@sharplabs.com> Date: Fri, 25 Jul 1997 11:41:51 -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: Peter Michalek CC: ipp@pwg.org Subject: Re: IPP> IPP - current documents and implementation X-Priority: 3 (Normal) References: <5030100005308786000002L062*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org There is a new protocol document available at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-protocol-00.txt this document supercedes the draft-turner-ipp-trans-develop-00 document. you can also access the main IETF page concerning IPP, with the latest "published" documents at: http://www.ietf.org/html.charters/ipp-charter.html and of course the PWG home page at http://www.pwg.org/ Randy Peter Michalek wrote: > I just subscribed to this mailing list 2 days ago and would like some > basic information: > > I read the documents: > HTTP 1.1 as a Transport for the Internet Printing Protocol > (draft-turner-ipp-trans-develop-00) > Requirements for an Internet Printing Protocol: > draft-ietf-ipp-req-00.txt > Internet Printing Protocol - Level 1 (Simple Web Printing Protocol): > Ipp-level1 > > PWG IPP Charter > RFC1867: Form-based File Upload in HTML > RFC1179: Line Printer Daemon Protocol > RFC1759: Printer MIB > > and also the FAQ posted at www.pwg.org. > > --- > I am thinking of starting to design and implement a basic version of > IPP, > but I am not sure if this is good timing (since the protocols design > is > not finished) or if maybe there already is a basic implementation that > I > could use. > > Could someone answer these questions for me: > > * Are there additional documents or information related to ipp other > than > those at www.pwg.org? > * Do you hold any face-to-face meetings that I could attend in the Bay > > Area? > * Are your phone conferences accessible for me? > * Is there some reference implementation that is publicly available or > > that someone is selling? > * Do you think it's worth-while starting to implement IPP at this > stage? > * What's ipp pwg's take on SWP from MS and HP? Would that perhaps be a > > good candidate for a first implementation of IPP since it's simple? > * is ISO 10175 available on the Web? > > I'd be thankful for any info. > > Peter > > -------------------------------------------------------- > Peter Michalek, ShineSoft Systems > Voice, Fax: (408) 446-5040 > 10025 Crescent Rd. > Cupertino, CA 95014 > mailto:peterm@shinesoft.com > http://www.shinesoft.com   Received: from cnri by ietf.org id aa05494; 25 Jul 97 16:29 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA08491 for ; Fri, 25 Jul 1997 16:28:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA11182 for ; Fri, 25 Jul 1997 16:24:31 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 25 Jul 1997 16:15:03 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA09320 for ipp-outgoing; Fri, 25 Jul 1997 15:54:37 -0400 (EDT) Date: Fri, 25 Jul 1997 12:55:16 -0700 From: Robert Herriot Message-Id: <199707251955.MAA14157@woden.eng.sun.com> To: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP>SEC >MOD security and the LPD gateway X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Roger, According to my reading of the RFC's, both basic authentication and digest pass along a user name, but neither passes the client's host. However, digest has the concept of realm which is the context of the user name, and that is essentially the purpose of host name in LPD. But I still stand by my original comment which stated that the security document does not address the issue of supporting job-originating-host or job-originating-user. Perhaps the model needs to abandon job-originating-host and replace it by 'realm'. In any case, the security document needs to state how to support the job security attributes, such as job-originating-user, for each security solution. Otherwise, we don't have interoperability. Bob Herriot > From rdebry@us.ibm.com Fri Jul 25 07:09:39 1997 > > Doesn't digest or http basic authentication handle this? It certainly can > identify the user. > > 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 07/25/97 07:52 > AM --------------------------- > > ipp-owner @ pwg.org > 07/24/97 06:08 PM > Please respond to ipp-owner@pwg.org @ internet > > To: ipp @ pwg.org @ internet > cc: > Subject: IPP>SEC >MOD security and the LPD gateway > > As I work on the LPD gateway document, I realize, once again, that the > security documents don't deal with two attributes that we in the model > have assumed would be handled at the security level. These attributes > are: > > o job-originating-user > o job-originating-host > > The LPD-to-IPP gateway receives these two values in the control file and > the IPP-to-LPD gateway needs to put these into the control file. > > There may be work-arounds for the gateway. But that still leaves > these two job attributes without any way to set them unless we make > them explicit parameters in operations or create new HTTP headers. > > Comments? > > Bob Herriot > > >   Received: from cnri by ietf.org id aa06516; 25 Jul 97 17:06 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA08714 for ; Fri, 25 Jul 1997 17:04:38 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA12974 for ; Fri, 25 Jul 1997 17:01:02 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 25 Jul 1997 16:56:21 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA11934 for ipp-outgoing; Fri, 25 Jul 1997 16:43:09 -0400 (EDT) Date: Fri, 25 Jul 1997 13:43:50 -0700 From: Robert Herriot Message-Id: <199707252043.NAA14208@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD missing attribute to map job-uri to printer-uri X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org As I am writing the LPD gateway document, I just realized that we have no way to determine the printer that a job is on. The problem occurs when the IPP-to-LPD mapper receives a Cancel-Job. The operation contains the job-uri only, but the LPD remove-jobs command requires a printer-name as the target and the job-number as a parameter. The mapping of the job-uri to a job-number is a separate difficult issue. Because the job-uri is opaque, the mapper cannot determine the corresponding printer from it. I see two possible solutions: o add a mandatory job description attribute called "printer-uri" which references the printer containing the job. o make all commands have the printer-uri as the target with the job-uri as a parameter for operations that currently go to a job. This eliminates the need to map from a job to a printer because all operations include the printer-uri from which jobs can be obtained.   Received: from cnri by ietf.org id aa08583; 25 Jul 97 18:32 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid SAA09069 for ; Fri, 25 Jul 1997 18:31:19 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA15045 for ; Fri, 25 Jul 1997 18:27:43 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 25 Jul 1997 18:23:46 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA14580 for ipp-outgoing; Fri, 25 Jul 1997 18:16:28 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 25 Jul 1997 16:15:50 -0600 From: Scott Isaacson To: ipp@pwg.org, peterm@shinesoft.com Subject: Re: IPP> IPP - current documents and implementation Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org The latested model document is at ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970714.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970714.txt This is the same as draft-ietf-ipp-model-03.txt I hope to distribute a new version (-04) prior to the Munich Meetings * Are there additional documents or information related to ipp other than those at www.pwg.org? See the I-Ds posted at ietf.org * Do you hold any face-to-face meetings that I could attend in the Bay Area? See the web page for planned meetings (dates and places) They are usually all over the US. * Are your phone conferences accessible for me? Yes, some are toll some are toll free. * Is there some reference implementation that is publicly available or that someone is selling? Contact Patrick Powell from SDSU. His contact info is in the latest Model document. He has been interested in this. * Do you think it's worth-while starting to implement IPP at this stage? Yes, many companies are starting to prototype. The key word is START. See mail messages starting with TES (for interop testing). * What's ipp pwg's take on SWP from MS and HP? Would that perhaps be a good candidate for a first implementation of IPP since it's simple? SWP and IPP have found common ground and is being documented in the latested protocol and model documents (and really all the rest) * is ISO 10175 available on the Web? ftp://ftp.pwg.org/pub/pwg/dpa/ Scott >>> Peter Michalek 07/25/97 12:39PM >>> I just subscribed to this mailing list 2 days ago and would like some basic information: I read the documents: HTTP 1.1 as a Transport for the Internet Printing Protocol (draft-turner-ipp-trans-develop-00) Requirements for an Internet Printing Protocol: draft-ietf-ipp-req-00.txt Internet Printing Protocol - Level 1 (Simple Web Printing Protocol): Ipp-level1 PWG IPP Charter RFC1867: Form-based File Upload in HTML RFC1179: Line Printer Daemon Protocol RFC1759: Printer MIB and also the FAQ posted at www.pwg.org. --- I am thinking of starting to design and implement a basic version of IPP, but I am not sure if this is good timing (since the protocols design is not finished) or if maybe there already is a basic implementation that I could use. Could someone answer these questions for me: * Are there additional documents or information related to ipp other than those at www.pwg.org? * Do you hold any face-to-face meetings that I could attend in the Bay Area? * Are your phone conferences accessible for me? * Is there some reference implementation that is publicly available or that someone is selling? * Do you think it's worth-while starting to implement IPP at this stage? * What's ipp pwg's take on SWP from MS and HP? Would that perhaps be a good candidate for a first implementation of IPP since it's simple? * is ISO 10175 available on the Web? I'd be thankful for any info. Peter -------------------------------------------------------- Peter Michalek, ShineSoft Systems Voice, Fax: (408) 446-5040 10025 Crescent Rd. Cupertino, CA 95014 mailto:peterm@shinesoft.com http://www.shinesoft.com   Received: from cnri by ietf.org id aa24611; 28 Jul 97 0:51 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid AAA15186 for ; Mon, 28 Jul 1997 00:49:43 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA19656 for ; Mon, 28 Jul 1997 00:46:08 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 28 Jul 1997 00:40:24 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA19200 for ipp-outgoing; Mon, 28 Jul 1997 00:33:05 -0400 (EDT) Message-Id: <3.0.1.32.19970727212358.009d6660@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sun, 27 Jul 1997 21:23:58 PDT To: ipp@pwg.org From: "Christopher W Apple by way of Carl-Uno Manros " Subject: IPP> DIR - draft-apple-schema-listing-rqmts-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org The IETF group working on Directory Schema Listings has come out with a first draft. We may need to take this into account for our Directory document. Carl-Uno -- INTERNET-DRAFT C. Apple AT&T Laboratories Expires: January 26, 1998 26 July 1997 Directory Schema Listing Requirements 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 memo documents requirements for listing directory services schemas in a centrally operated, administered, and maintained repository. This repository will be available as a resource to directory protocol and service implementors to facilitate schema discovery. 1.0 Introduction The fastest route to interoperable directory services is through standard object classes and attribute types. There is a growing number of places where schema for Internet Directory Services and Internet Operations are being defined, with varying degrees of documentation. This plethora of schemas is unavoidable in the light of the needs of different service communities, but it makes it difficult for directory service builders to find and make use of an existing schema that will serve their needs and increase interoperability with other systems. A listing service providing a single point of discovery for white-pages schema will promote schema Apple [Page 1] INTERNET-DRAFT Directory Schema Listing Requirements 26 July 1997 reuse, reduce duplication of effort, and thus promote directory service interoperability. This document contains requirements for various aspects of listing schemas. 2.0 Listing Service Requirements 2.1 Functional Requirements Schema are 'listed' rather than 'registered'. A list of available schemas MUST be maintained. Schema will be named according to the namespace defined in section 3. The listing service shall also maintain information about the schema, beyond its definition. This information is referred to as meta data and will include information about the following differentiating characteristics: + a globally unique identifier for the schema name + protocol and protocol version for which the schema is valid + name/title of schema + version information for the schema + date of creation or update + indication of listing status + indication of relationship to other schemas + originating organization or individual + name of contact person for schema + e-mail of contact person for schema + telephone of contact person for schema + postal address of contact person for schema 2.2 Operational Requirements The process of listing schema will be centralized for the initial deployment. The database which provides the listing store will be centrally administered. Listing files will be accessible via FTP and HTTP. Listing content and listing meta data will be stored in a file named in accordance with the file name syntax defined in section 5.0. Listing content and listing meta data will be stored in a file Apple [Page 2] INTERNET-DRAFT Directory Schema Listing Requirements 26 July 1997 formatted in accordance with section 5.0. 3.0 Listing Service Namespace The listing service namespace shall be protocol-independent. Names constructed using the listing service namespace shall be permanent, globally unique, and publicly available. 3.2 Listed Schema Name Syntax ::= '-' ::= ['v' ] ::= IANA-assigned directory service protocol identifier ::= a protocol version number string ::= protocol-specific information Consider the following example of a schema name for the vCard schema [VCARD] for use in LDAPv3 [LDAPV3]: ldapv3-vCardObject where: vCardObject is the name of the object class identified by the OID: 1.3.6.1.4.1.2309.1.1.1.1 [VCARD] An alternate, but still globally unique, name for this schema is: ldapv3-1.3.6.1.4.1.2309.1.1.1.1 4.0 Listing Requirements Schema listing content will be composed only of the information actually required to specify the schema. Schema listing meta data will be composed of other information as defined in paragraph 4.2. 4.1 Listing Content 4.1.1 Allowable Listing Content Syntaxes LDAP Data Interchange Format [LDIF] Abstract Syntax Notation One [ASN1] Apple [Page 3] INTERNET-DRAFT Directory Schema Listing Requirements 26 July 1997 BNF [RFC822] Augmented BNF [ABNF] TBR. Working group needs to achieve consensus on the list of allowable syntaxes. 4.1.2 Allowable Listing Content Character Sets As specified in references for allowable listing content syntaxes. Exceptions: TDB. Working group needs to achieve consensus on whether or not profiling of these syntaxes is necessary/appropriate. 4.2 Listing Meta Data 4.2.1 Listing Meta Data Syntax TBD. Working group needs to achieve consensus on which meta data elements are important enough to include (see paragraph 2.1). 4.2.2 Allowable Listing Meta Data Character Sets TBD. Working group needs to achieve consensus on allowable character sets. 5.0 Listing Storage Requirements Listing file names shall be permanent and publicly available. 5.1 Listing File Name Syntax The content and meta data for each listing shall be contained in a file named according to the following syntax: ::= "ietf-schema-directory-" ".txt" ::= ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' 5.2 Listing File Format Specification TBD. Dependent on resolution of TBDs for section 4.0. 6.0 Security Considerations Security requirements are not discussed in this memo. Apple [Page 4] INTERNET-DRAFT Directory Schema Listing Requirements 26 July 1997 7.0 Acknowledgements Leslie Daigle of Bunyip Information Systems and Chris Weider of Microsoft provided valuable comments on the pre-Internet-Draft- version of this document. 8.0 References [ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications", INTERNET-DRAFT , July 1997. [ASN1] ITU-T Recommendation X.680, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", 1994. [LDAPV3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (Version 3)", INTERNET-DRAFT , July 1997. [LDIF] G. Good, "The LDAP Data Interchange Format (LDIF) _ Technical Specification", INTERNET-DRAFT , July 1997. [RFC822] D. Crocker, "Standard of the Format of ARPA-Internet Text Messages", STD 11, RFC 822, August 1982. [VCARD] F. Dawson, M. O'Brien, "The vCard Schema For Use In LDAPv3", INTERNET-DRAFT , July 1997. 9.0 Author's Address Chris Apple AT&T Laboratories 600 - 700 Mountain Ave., Room 2F-165 Murray Hill, NJ 07974-0636 USA E-Mail: capple@att.com Phone: +1 908 582 2409 FAX: +1 908 582 6113 This INTERNET-DRAFT expires on January 26, 1998. Apple [Page 5]   Received: from cnri by ietf.org id aa13327; 29 Jul 97 13:29 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA21518 for ; Tue, 29 Jul 1997 13:27:46 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA28868 for ; Tue, 29 Jul 1997 13:24:09 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 29 Jul 1997 13:15:08 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA27377 for ipp-outgoing; Tue, 29 Jul 1997 13:00:15 -0400 (EDT) From: Jeff Copeland Message-Id: <9707291700.AA16676@boulder.qms.com> Subject: IPP> seeking volunteer To: ipp@pwg.org Date: Tue, 29 Jul 1997 11:00:30 -0600 (MDT) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: ipp-owner@pwg.org QMS has decided to get out of the standards business, and so I'll be leaving the company. My last day is this Friday, 8/1. Unfortunately, this leaves the IPP project without a web master. Are there any volunteers to take the job on? For what it's worth, things are stable enough with the project that the job only takes a few hours a week at this point. -- 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   Received: from cnri by ietf.org id aa13547; 29 Jul 97 13:39 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA21547 for ; Tue, 29 Jul 1997 13:38:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA29453 for ; Tue, 29 Jul 1997 13:34:14 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 29 Jul 1997 13:30:50 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA28546 for ipp-outgoing; Tue, 29 Jul 1997 13:20:49 -0400 (EDT) From: STUART@kei-ca.ccmail.compuserve.com Date: 29 Jul 97 13:03:36 EDT To: ipp@pwg.org, SISAACSON@novell.com MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: IPP>MOD Editorial Comments on Model Doc Message-ID: <970729170335_702420.204300_BHD48-37@CompuServe.COM> Sender: ipp-owner@pwg.org Scott, I hope you find some of the following comments useful. Section 3.1.2.1 I found the paragraph under Job Template Attributes confusing. "If the client supplies no Job Template attributes in the Create-Job Request, ..." Why is Create-Job specified? Doesn't this also apply to Print-Job and Print-URI? The next sentence is about Document Attributes. Should it be in this "Job Template Attributes" paragraph? Line 582 - response parameter Line 598 - output parameter these should be the same Paragraph starting on Line 600 "The client does not supply a Job Template attribute, but the Printer supports the attribute:" I had to read this several times... how about, "The client does not supply a Job Template attribute that is supported by the printer:" Following this is, "The attribute is accepted..." How can the attribute be accepted if not supplied? I suggest deleting that text. Non-Editorial Question: Why not allow the printer to associate the default attributes at job creation time? This seems to put an unnecessary burden on the printer. Why must it wait until processing the job to associate default attributes? Line 596 If you buy the above edit, then this line should be, "The client supplies a Job Template attribute that is not supported by the Printer". Line 609 And if you buy both of the above, then, "The client does not supply an attribute that is also unsupported by the Printer." Line 638 "If there is an error," seems too general. Should it be something like, "If the input parameters include any attributes which the Printer does not support," Section 3.1.4.2 I think it should say what is returned if there are no unsupported attributes. What does it return? Just the successful status code? Line 843 "This input parameter conditions the Printer attributes and values that might depend on the document format." I had to read this several times. I'm not sure this is any better, but how about, "This input parameter is useful for determining the set of supported attribute values which relate to the requested document format." Line 1527 "The Printer SHALL..." This makes it seem like a mandatory object. Line 1697 "Document-number"? I don't see any document-number attribute? Lines 1748 & 1749 and beyond You were looking for places to get rid of SHALLs... Do these SHALLs determine whether an administrator is a conforming IPP Administrator? :-) I don't think SHALL is appropriate for dictating administrator actions. If you buy this, then there are lots of SHALLs in the following sections which fall into the same category. Line 1752 'Similar to "printer-uri"' How is this similar to printer-uri? Do you mean job-uri-user? Table on pg 52 Does not include pdl-override Lines 1880 and 1883 SHALL seems inappropriate for optional attributes. Typos Line 874 - retrieve "the" list Line 586 - tIf -> If Line 900 - formatting error Line 1050 - SHOULD "use" values Line 1531 - optional -> optionally? Line 1997 - (section 3.1.8) should be 3.1.10 Also, a small item... If I'm not included in the list of Other Participants, my company might think I'm playing golf instead of attending the IPP meetings :-). Stuart Rowley Kyocera   Received: from cnri by ietf.org id aa16217; 29 Jul 97 15:18 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid PAA21854 for ; Tue, 29 Jul 1997 15:16:39 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA00517 for ; Tue, 29 Jul 1997 15:13:02 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 29 Jul 1997 15:08:46 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA29980 for ipp-outgoing; Tue, 29 Jul 1997 15:01:24 -0400 (EDT) Message-Id: <3.0.1.32.19970729115211.00998460@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 29 Jul 1997 11:52:11 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> MOD - New version will soon come Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Hi, I got a call from Scott who is currently on tour in Johannesburg, South Africa. He confirmed that he is still working on the latest draft for the Model document and will have it in to IETF before the deadline tomorrow. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com   Received: from cnri by ietf.org id aa17853; 29 Jul 97 16:14 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA22089 for ; Tue, 29 Jul 1997 16:13:26 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA01132 for ; Tue, 29 Jul 1997 16:09:49 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 29 Jul 1997 16:05:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA00657 for ipp-outgoing; Tue, 29 Jul 1997 15:58:26 -0400 (EDT) From: STUART@kei-ca.ccmail.compuserve.com Date: Tue, 29 Jul 1997 13:03:14 -0400 Subject: IPP>MOD Editorial Comments on Model Doc To: "INTERNET:ipp@pwg.org" , "INTERNET:SISAACSON@novell.com" Message-ID: <199707291303_MC2-1BB2-5CE@compuserve.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: ipp-owner@pwg.org Scott, I hope you find some of the following comments useful. Section 3.1.2.1 I found the paragraph under Job Template Attributes confusing. "If the client supplies no Job Template attributes in the Create-Job Request, ..." Why is Create-Job specified? Doesn't this also apply to Print-Job and Print-URI? The next sentence is about Document Attributes. Should it be in this "Job Template Attributes" paragraph? Line 582 - response parameter Line 598 - output parameter these should be the same Paragraph starting on Line 600 "The client does not supply a Job Template attribute, but the Printer supports the attribute:" I had to read this several times... how about, "The client does not supply a Job Template attribute that is supported by the printer:" Following this is, "The attribute is accepted..." How can the attribute be accepted if not supplied? I suggest deleting that text. Non-Editorial Question: Why not allow the printer to associate the default attributes at job creation time? This seems to put an unnecessary burden on the printer. Why must it wait until processing the job to associate default attributes? Line 596 If you buy the above edit, then this line should be, "The client supplies a Job Template attribute that is not supported by the Printer". Line 609 And if you buy both of the above, then, "The client does not supply an attribute that is also unsupported by the Printer." Line 638 "If there is an error," seems too general. Should it be something like, "If the input parameters include any attributes which the Printer does not support," Section 3.1.4.2 I think it should say what is returned if there are no unsupported attributes. What does it return? Just the successful status code? Line 843 "This input parameter conditions the Printer attributes and values that might depend on the document format." I had to read this several times. I'm not sure this is any better, but how about, "This input parameter is useful for determining the set of supported attribute values which relate to the requested document format." Line 1527 "The Printer SHALL..." This makes it seem like a mandatory object. Line 1697 "Document-number"? I don't see any document-number attribute? Lines 1748 & 1749 and beyond You were looking for places to get rid of SHALLs... Do these SHALLs determine whether an administrator is a conforming IPP Administrator? :-) I don't think SHALL is appropriate for dictating administrator actions. If you buy this, then there are lots of SHALLs in the following sections which fall into the same category. Line 1752 'Similar to "printer-uri"' How is this similar to printer-uri? Do you mean job-uri-user? Table on pg 52 Does not include pdl-override Lines 1880 and 1883 SHALL seems inappropriate for optional attributes. Typos Line 874 - retrieve "the" list Line 586 - tIf -> If Line 900 - formatting error Line 1050 - SHOULD "use" values Line 1531 - optional -> optionally? Line 1997 - (section 3.1.8) should be 3.1.10 Also, a small item... If I'm not included in the list of Other Participants, my company might think I'm playing golf instead of attending the IPP meetings :-). Stuart Rowley Kyocera   Received: from cnri by ietf.org id aa22581; 29 Jul 97 17:28 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA22402 for ; Tue, 29 Jul 1997 17:26:41 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA01977 for ; Tue, 29 Jul 1997 17:21:52 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 29 Jul 1997 17:18:12 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA01515 for ipp-outgoing; Tue, 29 Jul 1997 17:10:45 -0400 (EDT) From: Jeff Copeland Message-Id: <9707292111.AA17225@boulder.qms.com> Subject: IPP> Re: seeking volunteer ... addendum To: ipp@pwg.org Date: Tue, 29 Jul 1997 15:11:00 -0600 (MDT) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: ipp-owner@pwg.org Other readers of the IPP mailing list within QMS have pointed out that I somewhat overstated the case in my earlier message: Certainly QMS is intending to curtail its full-time participation in IPP at this time because it has other fish to fry in the technology arena. (For me, the live give-and-take of standards meetings are the fun part of doing standards, which is part of why I'm leaving.) However: this in no way means that the company's intending to stop tracking standards, or building its printers around relevant standards. In fact, we've been tracking IPP as closely as we have because we think it's a great idea, and are looking to build it into our printers as quickly as we can. You'll continue to see occasional activity from Mabry Dozier and Michael Bringman, as you have in the past, except that unlike me, standards work won't be their primary activity. Sorry for any confusion I may have left about the future directions of a company I'm about to leave. -- 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   Received: from cnri by ietf.org id aa27196; 29 Jul 97 20:24 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid UAA22941 for ; Tue, 29 Jul 1997 20:22:52 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA03612 for ; Tue, 29 Jul 1997 20:19:17 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 29 Jul 1997 20:15:21 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA03108 for ipp-outgoing; Tue, 29 Jul 1997 20:07:42 -0400 (EDT) From: Harry Lewis To: jkm@underscore.com MMDF-Warning: Parse error in original version of preceding line at ietf.org Cc: ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: IPP> MOD - Is "best-effort" a new printing system feature? Message-Id: <5030100005499680000002L002*@MHS> Date: Tue, 29 Jul 1997 20:09:13 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org While trying to keep (catch?) up with the mail I came across this question regarding "best effort"... >That is, is the concept and mechanism of "best-effort" something >NEW to the printing world? I don't know that it should have any bearing on the direction of IPP, but the answer to this question is NO... it's not new. IPDS addresses "best effort" or "fidelity" in several ways. Probably the best example is the Exception Handling Control command which specifies whether or not Alternate Exception Actions and/or Page Continuation Actions are taken when an error occurs. Page Continuation Actions are designed to keep the printer printing in a "best can do" manner when a data stream error occurs and there is a "reasonable" way to keep going (perhaps by substituting a parameter or skipping an object). If AEA & PCA are not requested in the XOA EHC command, the printer effectively runs in an "absolute fidelity mode". The printer driver gets to choose between absolute fidelity and several variations of best-can-do. XOA EHC also lets the printer driver turn on and off the reporting of certain kinds of errors and lets the printer driver control whether or not an error page is printed. Harry Lewis - IBM Printing Systems   Received: from cnri by ietf.org id aa00998; 29 Jul 97 22:40 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid WAA23165 for ; Tue, 29 Jul 1997 22:38:51 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA04225 for ; Tue, 29 Jul 1997 22:35:16 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 29 Jul 1997 22:31:25 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA03766 for ipp-outgoing; Tue, 29 Jul 1997 22:24:04 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 29 Jul 1997 20:20:32 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - new model document Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org I have posted the new model document. Look in new_MOD/ipp-model-970725.pdf new_MOD/ipp-model-970725-rev.pdf new_MOD/ipp-model-970725.rtf My machine is crashing trying to generate the .txt Could someone try it for me off of the rtf file? If I can't get the .txt version I can't send a new one to the IETF. It should be called draft-ietf-ipp-model-04.txt. Scott   Received: from cnri by ietf.org id aa09626; 30 Jul 97 2:46 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid CAA23466 for ; Wed, 30 Jul 1997 02:44:41 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA05282 for ; Wed, 30 Jul 1997 02:41:05 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 30 Jul 1997 02:37:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA04818 for ipp-outgoing; Wed, 30 Jul 1997 02:29:42 -0400 (EDT) Date: Tue, 29 Jul 1997 23:30:18 -0700 From: Robert Herriot Message-Id: <199707300630.XAA18360@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO new ietf drafts for protocol and lpd X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I have just downloaded the following documents. If you have read the protocol document before you won't find much new. The LPD document is mostly new and goes into great detail about existing practice. Please read this, especially if your company implements or uses LPD. all in ftp://ftp.pwg.org/pub/pwg/ipp/ Protocol documents: synchronized (hopefully) with Scott's document. new_PRO/ipp-pro-970730.doc MS Word v6 new_PRO/ipp-pro-970730-rev.doc revisions (not many) new_PRO/ipp-pro-970730.txt text drafts/draft-ietf-ipp-protocol-01.txt same as above LPD documents: new_PRO/lpd-ipp-970730.doc MS Word v6 new_PRO/lpd-ipp-970730-rev.doc revisions (too many to read) new_PRO/lpd-ipp-970730.txt text drafts/draft-ietf-ipp-lpd-ipp-map-01.txt same as above Bob Herriot   Received: from cnri by ietf.org id aa03164; 30 Jul 97 6:00 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid FAA23744 for ; Wed, 30 Jul 1997 05:59:09 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id FAA06082 for ; Wed, 30 Jul 1997 05:55:34 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 30 Jul 1997 05:50:53 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id FAA05623 for ipp-outgoing; Wed, 30 Jul 1997 05:43:32 -0400 (EDT) Message-Id: <9707300943.AA11830@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, 30 Jul 1997 02:41:17 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> PRO - Change to the JmPrinterResolutionTC Sender: ipp-owner@pwg.org >Return-Path: >X-Sender: hastings@zazen >Date: Tue, 29 Jul 1997 17:01:49 PDT >To: jmp@pwg.org >From: Tom Hastings >Subject: PMP> PRO - Change to the JmPrinterResolutionTC >Cc: pmp@pwg.org >Sender: pmp-owner@pwg.org > >In order to align JMP with IPP, I'm changing the JmPrinterResolutionTC to >the following: > > >JmPrinterResolutionTC ::= TEXTUAL-CONVENTION >STATUS current >DESCRIPTION >"Printer resolutions. > >Nine octets consisting of two 4-octet SIGNED-INTEGERs followed by a >SIGNED-BYTE. The values are the same as those specified in the Printer MIB >[printmib]. The first SIGNED-INTEGER contains the value of >prtMarkerAddressabilityXFeedDir. The second SIGNED-INTEGER contains the >value of prtMarkerAddressabilityFeedDir. The SIGNED-BYTE contains the value >of prtMarkerAddressabilityUnit. > >Note: the latter value is either 3 (tenThousandsOfInches) or 4 (micrometers) >and the addressability is in 10,000 units of measure. Thus the >SIGNED-INTEGERS represent integral values in either dots-per-inch or >dots-per-centimeter. > >The syntax is the same as the IPP 'printer-resolution' attribute. See >Section 3.6.1.2." >SYNTAX OCTET STRING (SIZE(9)) > > >and changing the two attribute affected to use OCTETS: > >printerResolutionRequested(72), JmPrinterResolutionTC >OCTETS: MULTI-ROW: The printer resolution requested for a document in the >job for printers that support resolution selection. > >printerResolutionUsed(73), JmPrinterResolutionTC >OCTETS: MULTI-ROW: The printer resolution actually used by a document in >the job for printers that support resolution selection. > > > >   Received: from cnri by ietf.org id aa19566; 30 Jul 97 12:39 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid MAA25203 for ; Wed, 30 Jul 1997 12:37:47 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA07717 for ; Wed, 30 Jul 1997 12:34:12 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 30 Jul 1997 12:26:53 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA06869 for ipp-outgoing; Wed, 30 Jul 1997 12:17:56 -0400 (EDT) Message-Id: <3.0.1.32.19970730090739.00b779a0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 30 Jul 1997 09:07:39 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Two Munich slots for IPP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org >Return-Path: >X-Uri: http://www.cs.utk.edu/~moore/ >From: Keith Moore >To: Carl-Uno Manros >Cc: moore@cs.utk.edu, szilles@adobe.com, manros@cp10.es.xerox.com >Subject: Re: Munich slots for IPP and Revised IPP Charter >Date: Tue, 29 Jul 1997 20:39:52 PDT >Sender: moore@cs.utk.edu > >I told them to give a second slot to IPP. You should have >received confirmation by email, but it's possible that they >forgot to send out that particular confirmation. It's been >quite hectic for them lately! > >The latest "unreleased" copy of the schedule I've seen has >IPP listed at Monday 1530 and Wednesday 1530. The times >are subject to change, but probably will not change. >At any rate, you've got two slots. > >best, > >Keith > > 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   Received: from cnri by ietf.org id aa22938; 30 Jul 97 15:21 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid PAA25962 for ; Wed, 30 Jul 1997 15:19:58 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA09817 for ; Wed, 30 Jul 1997 15:16:22 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 30 Jul 1997 15:09:56 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA08534 for ipp-outgoing; Wed, 30 Jul 1997 14:57:14 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 30 Jul 1997 12:49:41 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - new text version of model document Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org look for new_MOD/draft-ietf-ipp-model-04.txt This is the one that I sent off to the IETF. Scott   Received: from cnri by ietf.org id aa25913; 30 Jul 97 17:04 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA26541 for ; Wed, 30 Jul 1997 17:02:58 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA11038 for ; Wed, 30 Jul 1997 16:59:20 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 30 Jul 1997 16:55:17 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA10560 for ipp-outgoing; Wed, 30 Jul 1997 16:47:53 -0400 (EDT) X-Sender: szilles@elroy (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="============_-1341823130==_============" Date: Wed, 30 Jul 1997 13:49:22 -0800 To: internet-drafts@ietf.org From: Steve Zilles Subject: IPP> draft-ietf-ipp-rat-01.txt Cc: szilles@adobe.com, ipp@pwg.org Sender: ipp-owner@pwg.org --============_-1341823130==_============ Content-Type: text/plain; charset="us-ascii" Apologies for not being sure that I am getting the message right and for being so late in submitting the draft. Attached is the text of draft-ietf-ipp-rat-01.txt with it file name being the same. (An earlier submission had a different file name if it matters; the content of both submissions is identical) Steve Zilles Co-chair, IPP WG --============_-1341823130==_============ Content-Type: text/plain; name="draft-ietf-ipp-rat-01.txt"; charset="us-ascii" Content-Disposition: attachment; filename="draft-ietf-ipp-rat-01.txt" INTERNET DRAFT Stephen N. Zilles Adobe Systems Inc. July 30, 1997 Expires: Jan 30, 1998 Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol 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. There are multiple parts to IPP, but the primary architectural components are the Model, the Protocol and an interface to Directory Services. This document provides a high level overview of the architecture and provides the rationale for the decisions made in structuring the architecture. The full set of IPP documents include: Internet Printing Protocol/1.0: Requirements for an Internet Printing Protocol 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 Zilles draft-ietf-ipp-rat-01.txt [Page 1] Expires: Jan 30, 1998 INTERNET DRAFT Internet Printing Rationale July 30, 1997 1. ARCHITECTURAL OVERVIEW The Internet Printing Protocol (IPP) is an application level protocol that can be used for distributed printing on the Internet. This protocol defines interactions between a client and a server. The client is provided the capability to inquire about capabilities of a printer, to submit print jobs and to inquire about and cancel print jobs. The server for these requests is the Printer; the Printer is an abstraction a generic document output device and/or a print service provider. Thus, the Printer could be a real printing device, such as a computer printer or fax output device, or it could be a service that interfaced with output devices. The architecture for IPP defines (in the Model document) an abstract Model for the data which is used to control the printing process and to provide information about the process and the capabilities of the Printer. This abstract Model is hierarchical in nature and reflects the structure of the Printer and the Jobs that may be being processed by the Printer. The Internet provides a channel between the client and the server/Printer. Use of this channel requires flattening and sequencing the hierarchical Model data. Therefore, the IPP also defines (in the Protocol document) an encoding of the data in the model for transfer between the client and server. This transfer of data may be either a request or the response to a request. Finally, the IPP defines (in the Protocol document) a protocol for transfering the encoded request and response data between the client and the server/Printer. An example of a typical interaction would be a request from the client to create a print job. The client would assemble the Model data to be associated with that job, such as the name of the job, the media to use, the number of pages to place on each media instance, etc. This data would then be encoded according to the Protocol and would be transmitted according to the Protocol. The server/Printer would receive the encoded Model data, decode it into a form understood by the server/Printer and, based on that data, do one of two things: (1) accept the job or (2) reject the job. In either case, the server must construct a response in terms of the Model data, encode that response according to the Protocol and transmit that encoded Model data as the response to the request using the Protocol. Zilles draft-ietf-ipp-rat-01.txt [Page 2] Expires: Jan 30, 1998 INTERNET DRAFT Internet Printing Rationale July 30, 1997 Another part of the IPP architecture is the Directory Schema. The role of the Directory Schema is to provide a standard set of attributes which might be used to query a directory service for the URI of a Printer that is likely to meet the needs of the client. The IPP architecture also addresses security issues such as control of access to server/Printers and secure transmissions of requests, response and the data to be printed. 2. THE PRINTER Because the (abstract) server/Printer encompasses a wide range of implementations, it is necessary to make some assumptions about a minimal implementation. The most likely minimal implementation is one that is embedded in an output device running a specialized real time operating system and with limited processing, memory and storage capabilities. This Printer will be connected to the Internet and will have at least a TCP/IP capability with (likely) SNMP support for the Internet connection. In addition, it is likely the the Printer will be an HTML/HTTP server to allow direct user access to information about the printer. 3. RATIONALE FOR THE MODEL The Model is defined independently of any encoding of the Model data both to support the likely uses of IPP and to be robust with respect to the possibility of alternate encodings. It is expected that a client or server/Printer would represent the Model data in some data structure within the applications/servers that support IPP. Therefore, the Model was designed to make that representation straightforward. Typically, a parser or formatter would be used to convert from or to the encoded data format. Once in an internal form suitable to a product, the data can be manipulated by the product. For example, the data sent with a Print Job can be used to control the processing of that Print Job. The semantics of IPP are attached to the (abstract) Model. Therefore, the application/server is not dependent on the encoding of the Model data, and it is possible to consider alternative mechanisms and formats by which the data could be transmitted from a client to a server; for example, a server Zilles draft-ietf-ipp-rat-01.txt [Page 3] Expires: Jan 30, 1998 INTERNET DRAFT Internet Printing Rationale July 30, 1997 could have a direct, client-less GUI interface that might be used to accept some kinds of Print Jobs. This independence would also allow a different encoding and/or transmission mechanism to be used if the ones adopted here were shown to be overly limiting in the future. Such a change could be migrated into new products as an alternate protocol stack/parser for the Model data. Having an abstract Model also allows the Model data to be aligned with the (abstract) model used in the Printer, Job and Host Resources MIBs. This provides consistency in interpretation of the data obtained independently of how the data is accessed, whether via IPP or via SNMP and the Printer/Job MIBs. 4. RATIONALE FOR THE PROTOCOL There are two parts to the Protocol: (1) the encoding of the Model data and (2) the mechanism for transmitting the model data between client and server. 4.1 The Encoding To make it simpler to develop embedded printers, a very simple binary encoding has been chosen. This encoding is adequate to represent the kinds of data that occur within the Model. It has a simple structure consisting of name value pairs in which the names are length specified strings constrained to characters from a subset of ASCII and the values are either scalars or a sequence of scalars. Each scalar value has a length specification and is represented either as an 4 byte integer or a string. A fully encoded request/response has a version number, an operation (for a request) or a status and optionally a status message (for a response), associated parameters and attributes which are encoded Model data and, optionally (for a request), print data following the Model data. 4.2 The Transmission Mechanism The chosen mechanism for transmitting the encoded Model data is HTTP 1.1 Post (and associated response). No modifications to HTTP 1.1 are proposed or required. The sole role of the Transmission Mechanism is to provide a transfer of encoded Model data from/to the client to/from the server. This could be done using any data delivery mechanism. The key reasons why HTTP 1.1 Post is used are given below. The Zilles draft-ietf-ipp-rat-01.txt [Page 4] Expires: Jan 30, 1998 INTERNET DRAFT Internet Printing Rationale July 30, 1997 most important of these is the first. With perhaps this exception, these reasons could be satisfied by other mechanisms. There is no claim that this list uniquely determines a choice of mechanism. 1. HTTP 1.0 is already widely deployed and, based on the recent evidence, HTTP 1.1 will be widely deployed as the manufacturers release new products. The performance benefits of HTTP 1.1 have been shown and manufactures are reacting postively. Wide deployment has meant that many of the problems of making a protocol work in a wide range of environments from local net to intranet to internet have been solved and will stay solved with HTTP 1.1 deployment. 2. HTTP 1.1 solves most of the problems that might have required a new protocol to be developed. HTTP 1.1 allows persistent connections that make a multi-message protocol be more efficient; for example it is practical to have a separate CreatJob and SendJob messages. Chunking allows the transmission of large print files without having to prescan the file to determine the file length. The accept headers allow the client's protocol and localization desires to be transmitted with the IPP operations and data. If the Model were to provide for the redirection of Job requests, such as Cancel-Job, when a Job is moved, the HTTP redirect response allows a client to be informed when a Job he is interested in is moved to another server/Printer for any reason. 3. Most network Printers will be implementing HTTP servers for reasons other than IPP. These network attached Printers want to provide information on how to use the printer, its current state, etc. in HTML. This requires having an HTTP server which would be available to do IPP functions as well. 4. Most of the complexity of HTTP 1.1 is concerned with the implementation of proxies and not the implementation of clients and/or servers. Work is proceding in the HTTP Working Group to help identify what must be done by a server. As the Protocol document shows, that is not very much. 5. An HTTP based solution fits well with the Internet security mechanism that are currently deployed or being deployed. HTTP will run over SSL/TLS. The digest Zilles draft-ietf-ipp-rat-01.txt [Page 5] Expires: Jan 30, 1998 INTERNET DRAFT Internet Printing Rationale July 30, 1997 authentication mechanism of HTTP 1.1 provides an adequate level of access control (at least for intranet usage). These solutions are deployed and in practical use; a new solution would require extensive use to have the same degree of confidence in its security. 5. RATIONALE FOR THE DIRECTORY SCHEMA Successful use of IPP depends on the client finding a suitable IPP enabled Printer to which to send a IPP requests, such as print a job. This task is simplified if there is a Directory Service which can be queried for a suitable Printer. The purpose of the Directory Schema is to have a standard description of Printer attributes that can be associated the the URI for the printer. These attributes are a subset of the Model attributes and can be encoded in the appropriate query syntax for the Directory Service being used by the client. 6. RATIONALE FOR SECURITY Security is an areas of active work on the Internet. Complete solutions to a wide range of security concerns are not yet available. Therefore, in the design of IPP, the focus has been on identifying a set of security protocols/features that are implemented (or currently implementable) and solve real problems with distributed printing. The two areas that seem appropriate to support are: (1) authorization to use a Printer and (2) secure interaction with a printer. The chosen mechanisms are the digest authentication mechanism of HTTP 1.1 and the SSL/TLS secure communication mechanism, which also includes authorization. 7. REFERENCES [1] Wright, F. D., "Requirements for an Internet Printing Protocol:" [2] Isaacson, S, deBry, R, Hasting, T, Herriot, R, Powell, P, "Internet Printing Protocol/1.0: Model and Semantics" [3] Internet Printing Protocol/1.0: Security [4] Herriot, R, Butler, S, Moore, P, Turner, R, "Internet Printing Protocol/1.0: Protocol Specification" [5] Carter, K, Isaacson, S, "Internet Printing Protocol/1.0: Directory Schema" Zilles draft-ietf-ipp-rat-01.txt [Page 6] Expires: Jan 30, 1998 INTERNET DRAFT Internet Printing Rationale July 30, 1997 8. AUTHORS ADDRESS Stephen Zilles Adobe Systems Incorporated 345 Park Avenue MailStop W14 San Jose, CA 95110-2704 Phone: +1 408 536-4766 Fax: +1 408 537-4042 Email: szilles@adobe.com + Zilles draft-ietf-ipp-rat-01.txt [Page 7] Expires: Jan 30, 1998 --============_-1341823130==_============--   Received: from cnri by ietf.org id aa26587; 30 Jul 97 17:31 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA26625 for ; Wed, 30 Jul 1997 17:30:05 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA12023 for ; Wed, 30 Jul 1997 17:26:30 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 30 Jul 1997 17:20:05 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA11126 for ipp-outgoing; Wed, 30 Jul 1997 17:06:08 -0400 (EDT) Date: Wed, 30 Jul 1997 13:59:38 -0700 From: Robert Herriot Message-Id: <199707302059.NAA19074@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD just sent draft-ietf-ipp-model-4.txt to ietf X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I just did a quick conversion of Scott's ipp-mod-970725.doc .txt and submitted it just minutes before the deadline. Bob Herriot   Received: from cnri by ietf.org id aa26611; 30 Jul 97 17:32 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA26635 for ; Wed, 30 Jul 1997 17:30:51 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA12131 for ; Wed, 30 Jul 1997 17:27:15 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 30 Jul 1997 17:21:23 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA11142 for ipp-outgoing; Wed, 30 Jul 1997 17:07:53 -0400 (EDT) Message-Id: <3.0.1.32.19970730135828.0099f3b0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 30 Jul 1997 13:58:28 PDT To: Scott Isaacson , ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> MOD - new model document In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 07:20 PM 7/29/97 PDT, Scott Isaacson wrote: >I have posted the new model document. Look in > >new_MOD/ipp-model-970725.pdf >new_MOD/ipp-model-970725-rev.pdf >new_MOD/ipp-model-970725.rtf > >My machine is crashing trying to generate the .txt Could someone try it for >me >off of the rtf file? If I can't get the .txt version I can't send a new >one to the >IETF. It should be called draft-ietf-ipp-model-04.txt. > >Scott > Scott, Tom and I have spent the last few hours frenetically trying to generate the text file in IETF format. We succeeded in getting a version which has too few lines per page, but it least it has all the text in it. It was sent to the IETF just minutes before the deadline. 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   Received: from cnri by ietf.org id aa27494; 30 Jul 97 18:02 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid SAA26823 for ; Wed, 30 Jul 1997 18:00:42 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA12760 for ; Wed, 30 Jul 1997 17:57:08 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 30 Jul 1997 17:53:53 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA12295 for ipp-outgoing; Wed, 30 Jul 1997 17:46:24 -0400 (EDT) Message-Id: <3.0.1.32.19970730143704.00bbad10@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 30 Jul 1997 14:37:04 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - We got our drafts in Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org All, new draft for the following IPP documents have now been sent to the IETF: - Model & Semantics - Security - Protocol - Rationale - LPD Mapping There was some confusion about the Model & Semantics documents as both Scott and I submitted text versions, but I have asked the secretariat to ignore my version, which was not perfect. I have just put up a version of the Rationale document on the server under the name: draft-ietf-ipp-rat-01.txt in the new_PRO folder Jeff Copeland is just updating our web pages with pointers to the new versions. 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   Received: from cnri by ietf.org id aa03464; 1 Aug 97 6:33 EDT Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid GAA01865 for ; Fri, 1 Aug 1997 06:31:35 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id GAA16459 for ; Fri, 1 Aug 1997 06:28:00 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 1 Aug 1997 06:18:42 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id GAA15994 for ipp-outgoing; Fri, 1 Aug 1997 06:11:12 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 31 Jul 1997 03:38:21 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> text version of the model document Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Thanks to all who worked for "hours" trying to get the model document into text format for the IETF and making it just before the deadline. I eventually got a new machine set up and was able to make a text copy myself and get one sent in and so I think we are covered. Thanks for the last minute help. 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 ************************************************************